From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mfd wm8350: allocate irq descs dynamically
Date: Tue, 24 May 2011 06:41:00 +0800 [thread overview]
Message-ID: <20110523224045.GA19533@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20110523164601.GG20715@pengutronix.de>
On Mon, May 23, 2011 at 06:46:01PM +0200, Sascha Hauer wrote:
> On Mon, May 23, 2011 at 04:22:48PM +0100, Mark Brown wrote:
> > With platform data it has a default value, and indeed when the chip
> > powers on it has a default.
> Ok, what should be the default for irq_high then if we do not have
> platform data?
Off - the default value for platform data is all zeros.
> > You're missing my point here. The platform not only has to allocate the
> > base number, it also has to do the allocation of the descriptors. That
> > seems less than ideal as it means that any platform using the driver
> > has to replicate the code for allocating the IRQ range that was
> > assigned.
> We can do the irq_alloc_descs unconditionally then. If irq_base is
> not given, we are happy with any irq irq_alloc_descs returns. If
> irq_base is given, we check the return value of irq_alloc_descs for
> exactly irq_base.
That's what I'm suggesting, but like I say I'm not convinced that's
actually going to do the right thing currently on non-sparse systems or
on systems that do actually have the IRQ range allocated for some other
reason.
> > We normally instantiate drivers following the control bus heirachy, not
> > the interrupt controller heirachy...
> I assumed that drivers using the irqs from the wm8350 are usually
> children of the wm8350, like the watchdog, rtc, regulator drivers already are.
> This may not be true for the gpio interrupts, but you can calculate the
> irq from the gpio number.
You can only do that if the device is using the GPIO as a GPIO as well
as using it as an interrupt. If the device is just using the GPIO on
the PMIC as an interrupt then it doesn't help as the driver isn't using
the GPIO API at all.
next prev parent reply other threads:[~2011-05-23 22:41 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 [this message]
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
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=20110523224045.GA19533@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--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 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).