On 2002.05.30 01:13 Leif Delgass wrote:
> Jose,
>
> It's taking me a little longer than expected to finish the changes I
> mentioned. I'm trying to set this up so that it will be possible to test
> emitting buffers to the ring as they come in, but keep the original code
> in place, while sharing as much code as possible. I'm borrowing some
> code
> from the r128 driver, and alomst have this working, but I've got bugs and
> regressions to fix still. I saw your commit and wanted to get this to you
> so you can see what I had in mind before you get too far along. Let me
> know what you think.
I gave a quick look. Most changes are renaming and code moving. I didn't
looked in too much detail (I'm just answering these email before going to
bed), but here are some notes:
- the descriptor table buffer will have to be allocated by the
pci_consistent, and not pci_pool*, as it's just one, and we might want to
use bigger buffers.
- the RING macros look a very neat way to organize the things we gonna
need to do. It will probably even allow to easily try different ways.
I'll surely wait for you to commit this stuff, before doing anything else.
Tomorrow I'll take a look more carefully to see if I find anything
suspicious. Anyway, if you fail to solve the regressions, commit and
explain the problems, so that I can help fix it.
> BTW, regarding your last change: you're right that the register resets
> for
> BUS_CNTL and SRC_CNTL are _not_ required to stop the DMA transfer. The
> card won't act on the changes made to these registers, but the values are
> changed. It's more of a security thing to leave things in a sane state
> between dispatches. Anyway, if you look at my diff, I have a separate
My comment concerned BUS_CNTL alone. I don't know if you have it, buthere
is the snippet from the SDK sample code (CHAP8/BMGUI/BMGUI.C):
// restore previous SRC_CNTL to disable busmastering
...
regw (SRC_CNTL, 0);
...
// disable the multimedia register block
regw (BUS_CNTL, (regr (BUS_CNTL)) & 0xF7FFFFFF );
Notice, this last one is exactly the opposite of what we do now.
> macro for emitting buffers to the ring -- I'd like to keep the existing
> queue and dispatch functions around (plus the cosmetic changes) until we
> see how the new approach goes. That way we'll have a basis for
> comparison
> and a working fallback. I know the code gets a bit ugly with all the
> preprocessor switches, but we can remove those and clean up down the road
> when we find the best option.
That's no problem, as long as bugs don't result from that.
> The biggest problem with emitting to the
> ring right away is handling restarting DMA when the card goes idle. You
> don't want to do it right away or it will go idle again. You need to
> allow a resonable amount of buffers to queue up on the card before
> restarting it.
In the last thread concerning the security I've realized that we don't
need really to wait for idle. After queueing the buffer just see if _it's_
idle or not. If it's not we just forget about it, and in the next commit
we restarted from where it stopped. This idea still has some rough edges,
but I'm sure is doable. This way, when the card is processing stuff fast
(which means the CPU is full), we don't loose CPU cycles waiting for the
card to go idle. In sum, we manage to always optimize for the end where
the bottleneck is.
José Fonseca
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
