From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: IIO irq allocation fails on AT91SAM9G45
Date: Wed, 29 Feb 2012 20:48:53 +0000 [thread overview]
Message-ID: <20120229204853.GE16999@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <4F4E8C0F.5090104@kernel.org>
On Wed, Feb 29, 2012 at 08:35:27PM +0000, Jonathan Cameron wrote:
> On 02/29/2012 02:32 PM, Maxime Ripard wrote:
> > Hi everyone,
> >
> > I'm working on adding the support for the AT91SAM9M10G45-EK board from
> > Atmel for the at91_adc driver I previously posted, and I encounter some
> > weird issue here.
> >
> > When calling the iio_allocate_trigger
> > (http://lxr.free-electrons.com/source/drivers/staging/iio/industrialio-trigger.c?a=arm#L421)
> > from my driver on the G45, it returns ENOMEM, while on the
> > AT91SAM9G20-EK board, it works perfectly.
> >
> > Digging a bit into it, it seems that the call to irq_alloc_descs is
> > returning the error (the value of CONFIG_IIO_CONSUMERS_PER_TRIGGER is 2
> > in my configuration, which seems pretty reasonable and is the default
> > value anyway), which is itself getting that return value from
> > irq_expand_nr_irqs.
> >
> > Here, I'm left confused, I don't know this part of the kernel anymore,
> > and most importantly, it seems to be pretty-much arch-independant, while
> > the nature of my issue seems really platform-dependant.
> >
> > Do you have any clue of what's going on here ?
> We ran into this originally on the pxa as well. My guess is that
> nr_irqs is not set high enough for that particular board.
>
> Looking back I can find some mention of a nasty bit of code that
> just adds a bit of padding but I can't find it now.
>
> Anyhow, you probably have a line somewhere in the kernel log
> saying something like:
>
> [ 0.000000] NR_IRQS:288 nr_irqs:296 296
>
> NR_IRQS is typically the number of the SoC
> nr_irqs should be large enough to accomodate those provided by
> other peripherals.
>
> I also have a vague recollection that the problem goes away entirely
> with sparse irqs?
Yes, because IRQs will be allocated above the last figure on that
line, up to IRQ_BITMAP_BITS which happens to be 8192 above NR_IRQS.
There's an issue though: if your on-SoC IRQ controller is already
using irq_alloc_descs(), it will fail if you want it to grab IRQs
below the last figure on that line, because those will have already
been allocated for you.
next prev parent reply other threads:[~2012-02-29 20:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-29 14:32 IIO irq allocation fails on AT91SAM9G45 Maxime Ripard
2012-02-29 20:35 ` Jonathan Cameron
2012-02-29 20:48 ` Russell King - ARM Linux [this message]
2012-03-02 9:03 ` Maxime Ripard
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=20120229204853.GE16999@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--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).