[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5h3a40pdm7.wl%tiwai@suse.de>
Date: Fri, 27 Nov 2009 09:37:36 +0100
From: Takashi Iwai <tiwai@...e.de>
To: Tejun Heo <tj@...nel.org>
Cc: Andy Walls <awalls@...ix.net>,
Peter Ujfalusi <peter.ujfalusi@...ia.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>
Subject: Re: linux-next: workqueues tree build failure
At Fri, 27 Nov 2009 11:02:25 +0900,
Tejun Heo wrote:
>
> Hello,
>
> 11/26/2009 09:40 PM, Andy Walls wrote:
> >> * If you need to respond fast, wouldn't you be doing that from IRQ
> >> handler or softirq? Do you need task context?
> >
> > I'm not sure doing things like I2C transactions in the in the top half
> > of the IRQ handler is generally viable. On shared IRQ lines, wouldn't
> > this hold off the interrupt for another device for too long?
> >
> > For example, I already ran across the case of an error path in the ahci
> > disk controller driver interrupt handler holding off interrupts from the
> > cx18 driver longer than the CX23418 firmware would tolerate on a shared
> > interrupt line.
>
> Sounds like it should be using bottom half tasklet not workqueue.
> Tasklet is exactly designed to handle situations like this. Is there
> any reason tasklet can't be used?
Right now the h/w accessing code is using mutex. I'm not sure whether
the deeper part might sleep, though...
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists