linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Tejun Heo <tj@kernel.org>
Cc: Andy Walls <awalls@radix.net>,
	Peter Ujfalusi <peter.ujfalusi@nokia.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Re: linux-next: workqueues tree build failure
Date: Fri, 27 Nov 2009 09:37:36 +0100	[thread overview]
Message-ID: <s5h3a40pdm7.wl%tiwai@suse.de> (raw)
In-Reply-To: <4B0F3331.3070107@kernel.org>

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

  reply	other threads:[~2009-11-27  8:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-26  8:00 linux-next: workqueues tree build failure Stephen Rothwell
2009-11-26  8:04 ` Tejun Heo
2009-11-26  8:16   ` Peter Ujfalusi
2009-11-26  9:12     ` Tejun Heo
2009-11-26  9:24       ` Takashi Iwai
2009-11-26  9:31       ` Peter Ujfalusi
2009-11-26 10:18         ` Mark Brown
2009-11-26 11:44           ` Peter Ujfalusi
2009-11-26 12:49             ` Andy Walls
2009-11-26 13:23               ` Peter Ujfalusi
2009-11-26 12:40       ` Andy Walls
2009-11-26 12:56         ` Mark Brown
2009-11-27  2:02         ` Tejun Heo
2009-11-27  8:37           ` Takashi Iwai [this message]
2009-11-27  8:42             ` Tejun Heo
2009-11-27 10:09               ` Peter Ujfalusi
2009-11-27 11:38                 ` Mark Brown
2009-11-27 13:50           ` Andy Walls

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5h3a40pdm7.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=awalls@radix.net \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=peter.ujfalusi@nokia.com \
    --cc=sfr@canb.auug.org.au \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).