All of lore.kernel.org
 help / color / mirror / Atom feed
From: tglx@linutronix.de (Thomas Gleixner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 8/9] dma IPU: rework irq handling
Date: Fri, 20 May 2011 18:46:57 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.02.1105201823050.3078@ionos> (raw)
In-Reply-To: <20110520133022.GE10403@pengutronix.de>

On Fri, 20 May 2011, Sascha Hauer wrote:

> On Fri, May 20, 2011 at 03:16:42PM +0200, Thomas Gleixner wrote:
> > On Fri, 20 May 2011, Sascha Hauer wrote:
> > > @@ -354,48 +139,41 @@ static struct irq_chip ipu_irq_chip = {
> > >  /* Install the IRQ handler */
> > >  int __init ipu_irq_attach_irq(struct ipu *ipu, struct platform_device *dev)
> > >  {
> > > -	struct ipu_platform_data *pdata = dev->dev.platform_data;
> > > -	unsigned int irq, irq_base, i;
> > > +	unsigned int irq, irq_base;
> > >  
> > > -	irq_base = pdata->irq_base;
> > > +	irq_base = irq_alloc_descs(-1, 0, IPU_IRQ_NR_BANKS * 32, 0);
> > 
> >   	IPU_NUM_IRQS perhaps ?
> > 
> > > +	if (irq_base < 0)
> > > +		return irq_base;
> >   
> > So this allocates 160 interrupts. How many of them are actually going
> > to be used ?
> 
> One for the framebuffer and another one for the camera...
> 
> BTW often enough it's the same for the gpio interrupts. I have plenty of
> boards ending up with a single gpio interrupt out of 160 used for a
> external network controller.

We could actually be more clever about that by doing:

   irq_prealloc_irqs(from, cnt, setup_callback);

Which would return you the base nr of a linear range and at
request_irq() time we would detect the missing irq descriptor,
allocate it and call the setup_callback, which would fill in chip,
handler, data etc. That would make the few lines of init code for the
descriptor non __init, but we could avoid allocating 159 irq
descriptors for nothing.

The demux interrupt could still call generic_handle_irq() as we have a
sanity in place there now and a return value to let the demux irq know
that shite happened.

Thanks,

	tglx

  reply	other threads:[~2011-05-20 16:46 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-20  7:59 i.MX: switch to sparse irqs Sascha Hauer
2011-05-20  7:59 ` [PATCH 1/9] ARM i.MX tzic: do not depend on MXC_INTERNAL_IRQS Sascha Hauer
2011-05-20  7:59 ` [PATCH] mfd wm8350: allocate irq descs dynamically Sascha Hauer
2011-05-20 12:52   ` Thomas Gleixner
2011-05-20 13:07     ` Sascha Hauer
2011-05-20 13:19       ` Thomas Gleixner
2011-05-21 11:29         ` Mark Brown
2011-05-23  6:25           ` Sascha Hauer
2011-05-23 10:44             ` Mark Brown
2011-05-23 14:41               ` Sascha Hauer
2011-05-23 15:22                 ` Mark Brown
2011-05-23 16:46                   ` Sascha Hauer
2011-05-23 22:41                     ` Mark Brown
2011-05-24  7:28                       ` Sascha Hauer
2011-05-24  9:46                         ` Mark Brown
2011-05-24 11:52                           ` Sascha Hauer
2011-05-24 15:35                             ` Mark Brown
2011-05-25  8:13                               ` Sascha Hauer
2011-05-25  9:23                                 ` Mark Brown
2011-05-25 19:10                                   ` Sascha Hauer
2011-05-20  7:59 ` [PATCH 2/9] ARM i.MX avic: do not depend on MXC_INTERNAL_IRQS Sascha Hauer
2011-05-20  7:59 ` [PATCH 3/9] ARM i.MX: get rid of wrong MXC_INTERNAL_IRQ usage Sascha Hauer
2011-05-20  7:59 ` [PATCH 4/9] mfd wm8350: allocate irq descs dynamically Sascha Hauer
2011-05-20  7:59 ` [PATCH 5/9] ARM i.MX mx31ads: allocate irqs for expio dynamically Sascha Hauer
2011-05-20  7:59 ` [PATCH 6/9] ARM i.MX 3ds debugboard: allocate irqs dynamically Sascha Hauer
2011-05-20  7:59 ` [PATCH 7/9] ARM i.MX: use sparse irqs Sascha Hauer
2011-05-20  7:59 ` [PATCH 8/9] dma IPU: rework irq handling Sascha Hauer
2011-05-20 13:16   ` Thomas Gleixner
2011-05-20 13:30     ` Sascha Hauer
2011-05-20 16:46       ` Thomas Gleixner [this message]
2011-05-20 22:11         ` Benjamin Herrenschmidt
2011-05-20  7:59 ` [PATCH 9/9] ARM i.MX3: remove now useless ipu platform data from boards Sascha Hauer

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=alpine.LFD.2.02.1105201823050.3078@ionos \
    --to=tglx@linutronix.de \
    --cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.