Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1572451 > unrolled thread

Re: [PATCH v2 1/2] ARM: davinci: Allocate extra interrupts

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 1/2] ARM: davinci: Allocate extra interrupts Sekhar Nori <nsekhar@ti.com> - 2017-02-02 16:10 +0100
    Re: [PATCH v2 1/2] ARM: davinci: Allocate extra interrupts David Lechner <david@lechnology.com> - 2017-02-07 20:50 +0100

#1572451 — Re: [PATCH v2 1/2] ARM: davinci: Allocate extra interrupts

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. 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

[toc] | [next] | [standalone]

#1575990

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
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web