Russell King wrote:
>Would you mind discussing/forwarding your changes and bug fixes to the
>relevent maintainers at some point, rather than just overruling them
>snatching the maintainence from them? I find this extremely discourtious.
Once I'm happy that the changes are correct, yes. The only way for me to find
this out is to ask other people to try them. As you are so fond of pointing
out, your "official" kernel is supposed to be stable so it probably isn't
the best place to test experimental changes. In fact if you consult the
guidelines in the MAINTAINERS file, they explicitly suggest making patches
available for testing before bothering the maintainer.
As always, if you'd like to discuss the patches then I'd be glad to hear
your comments.
>(and you wonder why I jump down your throat from time to time).
Frankly I've long ago given up wondering about things like that.
>Have you tested it in the highest resolution?
No. If necessary I'd be happy to do what RISC OS appears to and turn off
video DMA in such modes during floppy access. (And since in the
highest-bandwidth modes the video DMA consumes over half the available bus
bandwidth it will be pretty hard to get any work done in such a mode anyway.)
>Hence I still don't believe that shaving an extra couple of cycles off the FIQ
>will give enough time to disable and enable FIQs, which is your main reason
>for implementing this change.
It was the main motivation for making the change in the first place, yes.
Regardless of whether it actually achieves this objective or not do you see
any reason not to install it?
Incidentally, remember that the ARM3 is of course cached and so it isn't
impacted as badly by bus latencies as naive calculations might show. And,
although there is indeed all this DMA going on in the background it happens in
many small chunks (after any of which the ARM can potentially get on the bus),
not in one large uninterruptible lump.
p.
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
