Joerg Dorchain (firstname.lastname@example.org)
Wed, 24 Feb 1999 11:07:53 +0100
On Wed, Feb 24, 1999 at 09:20:53AM +0000, Tim Waugh wrote:
> On Wed, 24 Feb 1999, Joerg Dorchain wrote:
> > I understand the idea. In this case weīd better remove the handler
> > completely (free_irq()) instead of brute-force disabling. I also donīt
> > like the idea of having a mid- or highlevel function caring about
> > hardware things like irqs. They donīt know about the specific hardware
> > (at least 4 different chip for different m68k parallel port types) and
> > do usually more harm than good when they try to play with the
> > hardware.
> In the -1284 tree I've got things like "wait for a nudge from the port (or
> a timeout)", which call parport_wait_event. parport_wait_event, however,
> is a single function, in parport_ieee1284.c, and it just waits on a
> wait_queue. It is woken up by the ieee1284 interrupt handler helper
> function parport_ieee1284_interrupt.
> Is that kind of thing okay?
Yes, as it doesnīt rely directly on specific hardware features. The
low-level driver calls the wake-up function somehow at the desired event,
thatīs all the ieee1284 driver needs to know.
> I must admit, I haven't looked at the irq changes in your patch yet. I'll
> take a look tonight.
Thank you :-)
> I think the intention is that port->ops->disable_irq is for telling the
> parallel port interrupt source to be quiet until further notice (i.e.
That is my understanding, too.
> That said, it's turning out to be a bit of a pain keeping the patches I
> have in step (and I admit I haven't actually _done_ anything with yours
> yet), so perhaps I should just bundle it together and learn to split
> patches up.
Would be a good idea to have some feedback (like a 'cvs update') too see
what others did and not to work at cross-purposes.
-- 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 24 Feb 1999 - 05:12:17 EST