diff for duplicates of <4F508CD0.20906@free-electrons.com> diff --git a/a/1.txt b/N1/1.txt index f752e90..920a6d2 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,32 +1,25 @@ -Le 29/02/2012 21:48, Russell King - ARM Linux a =E9crit : +Le 29/02/2012 21:48, Russell King - ARM Linux a ?crit : > 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 f= -rom ->>> Atmel for the at91_adc driver I previously posted, and I encounter = -some +>>> 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/industria= -lio-trigger.c?a=3Darm#L421) +>>> (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 defau= -lt +>>> 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 anymo= -re, ->>> and most importantly, it seems to be pretty-much arch-independant, = -while +>>> 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 ? @@ -47,10 +40,10 @@ while >> >> I also have a vague recollection that the problem goes away entirely >> with sparse irqs? ->=20 +> > 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. ->=20 +> > 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 @@ -65,10 +58,9 @@ because it has less interrupt sources. Anyway, I'm not sure about the augmenting the NR_IRQS fix. It seems to work pretty well, but might it have some weird side-effects ? -Should I send a patch for it, or should I find another way to fix this = -? +Should I send a patch for it, or should I find another way to fix this ? ---=20 +-- Maxime Ripard, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. diff --git a/a/content_digest b/N1/content_digest index 906d2cd..25e6199 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,47 +1,34 @@ "ref\04F4E36E6.1010704@free-electrons.com\0" "ref\04F4E8C0F.5090104@kernel.org\0" "ref\020120229204853.GE16999@n2100.arm.linux.org.uk\0" - "From\0Maxime Ripard <maxime.ripard@free-electrons.com>\0" - "Subject\0Re: IIO irq allocation fails on AT91SAM9G45\0" + "From\0maxime.ripard@free-electrons.com (Maxime Ripard)\0" + "Subject\0IIO irq allocation fails on AT91SAM9G45\0" "Date\0Fri, 02 Mar 2012 10:03:12 +0100\0" - "To\0Russell King - ARM Linux <linux@arm.linux.org.uk>\0" - "Cc\0Jonathan Cameron <jic23@kernel.org>" - linux-iio@vger.kernel.org - Hennerich - Michael <Michael.Hennerich@analog.com> - linux-arm-kernel@lists.infradead.org - " Nicolas Ferre <nicolas.ferre@atmel.com>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" - "Le 29/02/2012 21:48, Russell King - ARM Linux a =E9crit :\n" + "Le 29/02/2012 21:48, Russell King - ARM Linux a ?crit :\n" "> On Wed, Feb 29, 2012 at 08:35:27PM +0000, Jonathan Cameron wrote:\n" ">> On 02/29/2012 02:32 PM, Maxime Ripard wrote:\n" ">>> Hi everyone,\n" ">>>\n" - ">>> I'm working on adding the support for the AT91SAM9M10G45-EK board f=\n" - "rom\n" - ">>> Atmel for the at91_adc driver I previously posted, and I encounter =\n" - "some\n" + ">>> I'm working on adding the support for the AT91SAM9M10G45-EK board from\n" + ">>> Atmel for the at91_adc driver I previously posted, and I encounter some\n" ">>> weird issue here.\n" ">>>\n" ">>> When calling the iio_allocate_trigger\n" - ">>> (http://lxr.free-electrons.com/source/drivers/staging/iio/industria=\n" - "lio-trigger.c?a=3Darm#L421)\n" + ">>> (http://lxr.free-electrons.com/source/drivers/staging/iio/industrialio-trigger.c?a=arm#L421)\n" ">>> from my driver on the G45, it returns ENOMEM, while on the\n" ">>> AT91SAM9G20-EK board, it works perfectly.\n" ">>>\n" ">>> Digging a bit into it, it seems that the call to irq_alloc_descs is\n" - ">>> returning the error (the value of CONFIG_IIO_CONSUMERS_PER_TRIGGER =\n" - "is 2\n" - ">>> in my configuration, which seems pretty reasonable and is the defau=\n" - "lt\n" + ">>> returning the error (the value of CONFIG_IIO_CONSUMERS_PER_TRIGGER is 2\n" + ">>> in my configuration, which seems pretty reasonable and is the default\n" ">>> value anyway), which is itself getting that return value from\n" ">>> irq_expand_nr_irqs.\n" ">>>\n" - ">>> Here, I'm left confused, I don't know this part of the kernel anymo=\n" - "re,\n" - ">>> and most importantly, it seems to be pretty-much arch-independant, =\n" - "while\n" + ">>> Here, I'm left confused, I don't know this part of the kernel anymore,\n" + ">>> and most importantly, it seems to be pretty-much arch-independant, while\n" ">>> the nature of my issue seems really platform-dependant.\n" ">>>\n" ">>> Do you have any clue of what's going on here ?\n" @@ -62,10 +49,10 @@ ">>\n" ">> I also have a vague recollection that the problem goes away entirely\n" ">> with sparse irqs?\n" - ">=20\n" + "> \n" "> Yes, because IRQs will be allocated above the last figure on that\n" "> line, up to IRQ_BITMAP_BITS which happens to be 8192 above NR_IRQS.\n" - ">=20\n" + "> \n" "> There's an issue though: if your on-SoC IRQ controller is already\n" "> using irq_alloc_descs(), it will fail if you want it to grab IRQs\n" "> below the last figure on that line, because those will have already\n" @@ -80,13 +67,12 @@ "Anyway, I'm not sure about the augmenting the NR_IRQS fix. It seems to\n" "work pretty well, but might it have some weird side-effects ?\n" "\n" - "Should I send a patch for it, or should I find another way to fix this =\n" - "?\n" + "Should I send a patch for it, or should I find another way to fix this ?\n" "\n" - "--=20\n" + "-- \n" "Maxime Ripard, Free Electrons\n" "Kernel, drivers, real-time and embedded Linux\n" "development, consulting, training and support.\n" http://free-electrons.com -46c88c6639f15ec325092e8479cbd239c12f204f645e7af6cf5a6b59abc7d6e4 +1be4fc9e90e391e91325a0f28af3fca11ad8a1e57f17545e69656984acbe9108
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.