Russell King wrote:
>Philip Blundell writes:
>> guidelines in the MAINTAINERS file, they explicitly suggest making patches
>> available for testing before bothering the maintainer.
>
>I'm sorry - I can't find this in the Maintainers file. Could you please
>give me a line number?
About lines 7 to 40. Firstly one is exhorted to "release a few alpha test
versions to the net", then to make the patch "generally available for
testing", and only after that to send it to the maintainer in a form ready for
merging.
>> 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.
>
>Oh well, maybe we ought to ensure that nothing above 320x256 works for anyone.
>Then we'll have lots of bandwidth to play with.
If you want to continue this discussion in a constructive manner, fine. If
you don't want to continue it at all, that's also fine. This sort of comment
just wastes everybody's time.
>Cache or no cache, the floppy DMA still has to move data, which will require
>the bus. I don't think that the cache will have much effect on the timings.
Why don't you analyse the actual code sequences, figure out whether the
latency *would* in fact be too long, and then report back your findings? I
don't see much benefit in speculation.
If the answer is that disabling FIQs while updating the IRQ mask is
unacceptable, do you have any alternative suggestions for solving the actual
problem at hand (ie preventing contention on the IRQ mask registers betweeen
two threads)?
p.
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
