All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	"Hennerich, Michael" <Michael.Hennerich@analog.com>
Subject: Re: IIO irq allocation fails on AT91SAM9G45
Date: Wed, 29 Feb 2012 20:35:27 +0000	[thread overview]
Message-ID: <4F4E8C0F.5090104@kernel.org> (raw)
In-Reply-To: <4F4E36E6.1010704@free-electrons.com>

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?

Michael, you commented on this issue originally, can you remember
any more details than me? (It seemed like I wrote plenty at the
time but I can't for the life of me fill in the missing details!)


WARNING: multiple messages have this Message-ID (diff)
From: jic23@kernel.org (Jonathan Cameron)
To: linux-arm-kernel@lists.infradead.org
Subject: IIO irq allocation fails on AT91SAM9G45
Date: Wed, 29 Feb 2012 20:35:27 +0000	[thread overview]
Message-ID: <4F4E8C0F.5090104@kernel.org> (raw)
In-Reply-To: <4F4E36E6.1010704@free-electrons.com>

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?

Michael, you commented on this issue originally, can you remember
any more details than me? (It seemed like I wrote plenty at the
time but I can't for the life of me fill in the missing details!)

  reply	other threads:[~2012-02-29 20:34 UTC|newest]

Thread overview: 8+ 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 14:32 ` Maxime Ripard
2012-02-29 20:35 ` Jonathan Cameron [this message]
2012-02-29 20:35   ` Jonathan Cameron
2012-02-29 20:48   ` Russell King - ARM Linux
2012-02-29 20:48     ` Russell King - ARM Linux
2012-03-02  9:03     ` Maxime Ripard
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=4F4E8C0F.5090104@kernel.org \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=maxime.ripard@free-electrons.com \
    /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.