Re: [Dri-devel] Utah-GLX DMA on Mach64 and other DMA ideas.

[Frank E. <fe...@ai...>]

On Thursday 30 August 2001 13:23, James Jones wrote:

> When I read over the programmers guide, it states the registers must be
> specified as their offset from the primary apperture offset (bank 0)
> using their MM offset format.

Yes.  That is correct- the data described in the 4k data blocks must be in 
the MM offset format.  The engine does the right thing with the offsets while 
it's iterating over the blocks in gui-mastering mode.

> The Utah GLX code doesn't use either of these, it has APERTURE_OFFSET
> pointing to the second bank of registers, (bank 1), and the registers
> are specified in another format, yet the code obviously works.

Yes, that's because the documentation's "confused" for that one piece.  Read 
a little closer to the passage in the middle of 8-18 of the programmer's 
guide; it refers to an offset of 0x7FFC00 from the beginning of an 8Mb 
aperture, which is the _byte_ offset of the primary register mapping per the 
rest of the documentation, not a dword MM type offset.  Reading further on 
page 8-16, about setting up descriptors, "...if you're writing to one memory 
address..." indicates that it's probably looking for a byte offset for the 
target address, even in a GUI master operation.

> I tried changing the values in the DRI code to comply with the docs, and
> it still wasn't functional, so no luck there, but what really has me
> perplexed is why the Utah-GLX code works at all.  Is there something I'm
> missing?

Since it works, the documentation's wrong on some part.

> Also, I read a while back about a message from someone [Frank Earl I
> think?] claiming that bit 4 must be cleared in BUS_CNTL in order for DMA
> to work.  This is incorrect.  This bit only refers to DMA transfers
> where data is being read into the framebuffer, not DMA register access.

Read page 4-4 of the register reference again...

Bit 4 is titled, BUS_APER_REG_DIS.  The description indicates that it is to 
enable/disable the register decoding in the linear aperture- set off by 
default (Meaning map the registers into the linear aperture). 

> They also mentioned something about DRI passing us the secondary
> apperture as opposed to the primary one.  I assume you're refering to
> the APPERTURE_OFFSET definition I was talking about earlier, which can
> easily be fixed (although it doesn't help anything) by changing the
> define in mach64_drv.h to 0x007ffc00.  You are incorrect in assuming the
> Utah-GLX project uses this aperture though, it uses the exact same
> #define's as the DRI driver does.

I was in error in that regard- it was tickling the secondary aperture for the 
basic direct register commands.  However, if Utah-GLX's code is to be 
believed (Which, I do happen to believe it- I am one of the people that 
worked on it at some point in time...), the bus-master pass pushes to the 
primary aperture as it references a byte offset from the base of the linear 
aperture for it to work.  I believe the bus-mastering engine is only capable 
two types of operations- system memory to aperture and aperture to system 
memory.  This is based off of careful reading of page 8-10 of the register 
reference.  Since the secondary aperture and the VGA one aren't in the linear 
aperture, you can't do gui-mastering operations through them alone.

> This is becomming a long email, one more thing...

Long e-mails full of suppositions are more than welcome.  It gets ideas out 
in the open and brings up (hopefully) useful discourse that will end up with 
a working driver.  You bring up a possibility that might be the cause of most 
of our grief in this one...

> I've found that after starting X 4.1.0, with DRI/DRM dissabled, then
> trying to start X 3.3.6 with Utah-GLX enabled, it locks X.  I assume
> this is related to a note Gareth made in the Utah code that once you
> mess up DMA, you don't get it back until you do a cold boot.  So X 4 is
> messing up DMA before we get a chance to even use it I assume.  Does
> anyone know if and where the mach64 driver (not the DRI one, the
> standard mach64 accelerated server) in X4 uses DMA or anything that
> would mess it up?  I can't follow the X 4 source yet, I haven't spent
> enough time reading it (I've been pouring over the mach64 DRI and Utah
> code for about a month now, and this is all I've come up with, looks
> like another month of reading X 4 code :( ).

Hm...  Interesting possibility- might even be a _big_ part of the cause.  

However, let me toss out again some of the observations I've had with my 
tinkerings with the code- I'd like to hear what you think of it...

I've added a direct register call version of the draw test from Utah-GLX to 
the codebase I've got (I'm taking Manuel's latest attempt and weaving my 
attempts into that code over the next couple of days and making that 
available to anyone that's interested...) and ran the test in the DMA init 
code.  The code hangs my box but good- just like the DMA test does.
If I move the calls to the draw and dma tests to the cleanup code called at 
shutdown, the draw test works _well_ and the DMA test does nothing at all.

It's almost as if there's some stage at which the draw engine (which the 
bus-mastering is part of...) isn't all set up- and we're getting called for 
init at that point.  Maybe we could go further and say that it's hosing the 
DMA at a point before that as well (If it were just card state issues, I'm 
pretty sure it would have worked in the cleanup call, just like the draw 
test...). 

Setting Option "no_accel" seems to kill all accel support, including DRI 
calls, so I guess we need to look at the code through each of the stages 
leading up to the dma init call against the DRM driver.

> Anyone who knows anything about what I'm talking about, I'd love to talk
> to you.  Sorry for the huge post.

Don't apologize.  This sort of thing is about the only way we're going 
to get a disparate group of developers and potential developers working 
towards a common goal- the writing of a working DRI driver for the RagePRO.

-- 
Frank Earl