From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: linux-next: workqueues tree build failure Date: Fri, 27 Nov 2009 09:37:36 +0100 Message-ID: References: <20091126190050.3f9d7fef.sfr@canb.auug.org.au> <4B0E3677.6000603@kernel.org> <200911261016.58810.peter.ujfalusi@nokia.com> <4B0E467A.8080201@kernel.org> <1259239225.3062.16.camel@palomino.walls.org> <4B0F3331.3070107@kernel.org> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Return-path: Received: from cantor.suse.de ([195.135.220.2]:32927 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751512AbZK0Ihb (ORCPT ); Fri, 27 Nov 2009 03:37:31 -0500 In-Reply-To: <4B0F3331.3070107@kernel.org> Sender: linux-next-owner@vger.kernel.org List-ID: To: Tejun Heo Cc: Andy Walls , Peter Ujfalusi , Stephen Rothwell , "linux-next@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Mark Brown 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