Andrea Arcangeli (firstname.lastname@example.org)
Sat, 29 Aug 1998 15:31:21 +0200 (CEST)
On Fri, 28 Aug 1998, Philip Blundell wrote:
>>> >+#if !defined(__sparc__) && !defined(__mc68000__)
>>> I wonder if there's any reason not to remove this #if altogether. We
>>> shouldn't do it for 2.2 now just in case it does break something, but
>>If my machine, I noticed the effect of losing characters without a
>I actually meant we should probably use udelay() for all platforms, not just
>SPARC and m68k.
Or _at_least_ increase the default wait counter. The default should be set
realiable at first. Everybody can tune things with tunelp then with -w
if I remeber well... We really need to increase the loop cycles at least
to a default 20/30 instead of 0.
>Ah. The way parport interrupt handlers work at the moment, the high-level
>driver (lp, etc) provides the handler function directly. The grot in
>parport_share is there to switch the interrupt between different handlers.
Only when there is a parport_sharing in act and so it won' t hurt so
much... People that uses only lp with parport, will run a request_irq per
>Arguably a better way to do this would be to have the parport code claim the
>interrupt directly, and just call the function for the appropriate driver.
Yes agreed, this would be a cleaner and more efficient way but I am not
sure how much it would it improve performance due the fact we are just
very clever avoiding not needed parport_sharing switch so I agree that is
not a change _needed_ for 2.2.
>Again this probably isn't a change for 2.2. I'm not quite sure where your
>interrupt acknowledgement should fit in - probably in examine_irq() actually,
>since the idea is that this function gets called to see if it's a parallel
I can' t find the first email of this thread...
-- To unsubscribe, send mail to: email@example.com --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:09 EST