[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c79b28ba-df48-ce61-9b59-ed4c892ff5d7@lechnology.com>
Date: Tue, 7 Feb 2017 13:42:55 -0600
From: David Lechner <david@...hnology.com>
To: Sekhar Nori <nsekhar@...com>, linux-arm-kernel@...ts.infradead.org
Cc: Kevin Hilman <khilman@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] ARM: davinci: Allocate extra interrupts
On 02/02/2017 09:06 AM, Sekhar Nori wrote:
> On Friday 20 January 2017 11:47 PM, David Lechner wrote:
>> On 01/20/2017 05:50 AM, Sekhar Nori wrote:
>>> On Wednesday 18 January 2017 10:27 PM, David Lechner wrote:
>>>> On 01/18/2017 03:50 AM, Sekhar Nori wrote:
>>>>> On Saturday 14 January 2017 01:30 AM, David Lechner wrote:
>>>>>> This allocates extra interrupts for mach-davinci. These extra
>>>>>> interrupts
>>>>>> are need for things like IIO triggers.
>>>>>
>>>>> I am not really familiar with IIO triggers. Can you give some more
>>>>> detail on what fails without this patch?
>>>>
>>>> A trigger is used to initiate the reading of an iio device. For example,
>>>> there is a mechanism for a sysfs trigger. When you write 1 to the sysfs
>>>> attribute, it triggers an interrupt that is handled by the iio device.
>>>>
>>>> Since these triggers use interrupts, you need to allocate spare
>>>> interrupts in order to set up the trigger. Otherwise, setting up the
>>>> trigger will fail with an error code (I forgot which one exactly)
>>>> because all of the allocated irqs have already been assigned to hardware
>>>> irqs and are not available.
>>>>
>>>> Here is where the iio subsytem actually allocates the irq:
>>>> http://lxr.free-electrons.com/source/drivers/iio/industrialio-trigger.c#L525
>>>>
>>>
>>> Alright, I will take a look. Do note that this may not get included in
>>> the first batch of v4.11 changes I queue. But I promise to come back to
>>> it soon afterwards.
>>>
>>
>> It is not critical at this point, so it is fine to wait a bit.
>
> So, I think instead of increasing NR_IRQS by a small number, we should
> instead shift to use SPARSE_IRQ.
Sounds good. However, this is a bit beyond my expertise. Maybe if I can
find a "Sparse IRQ for Dummies" book I could attempt this some time.
I looked at some patches from Tony
> Lindgren converting OMAP1 to use SPARSE_IRQ. There is some work
> involved, but it does not look to be too huge a change to me.
>
> 685e2d08c54b ARM: OMAP1: Change interrupt numbering for sparse IRQ
> b694331cfb2e ARM: omap1: Switch to use MULTI_IRQ
> 55b447744389 ARM: OMAP1: Switch to use generic irqchip in preparation for sparse IRQ
> 928f81aa619d ARM: OMAP1: Move UART defines to prepare for sparse IRQ
>
> Thanks,
> Sekhar
>
Powered by blists - more mailing lists