Re: [PATCH V3 2/2] drivers/irqchip: add NXP INTMUX interrupt multiplexer support

[Lokesh Vutla <lokeshvutla@ti.com>]

On 20/12/19 8:56 PM, Joakim Zhang wrote:
> 
>> -----Original Message-----
>> From: Marc Zyngier <maz@kernel.org>
>> Sent: 2019年12月20日 22:20
>> To: Joakim Zhang <qiangqing.zhang@nxp.com>
>> Cc: Lokesh Vutla <lokeshvutla@ti.com>; tglx@linutronix.de;
>> jason@lakedaemon.net; robh+dt@kernel.org; mark.rutland@arm.com;
>> shawnguo@kernel.org; s.hauer@pengutronix.de; Andy Duan
>> <fugang.duan@nxp.com>; S.j. Wang <shengjiu.wang@nxp.com>;
>> linux-kernel@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>;
>> kernel@pengutronix.de; linux-arm-kernel@lists.infradead.org
>> Subject: RE: [PATCH V3 2/2] drivers/irqchip: add NXP INTMUX interrupt
>> multiplexer support
>>
>> On 2019-12-20 14:10, Joakim Zhang wrote:
>>>> -----Original Message-----
>>>> From: Lokesh Vutla <lokeshvutla@ti.com>
>>
>> [...]
>>
>>>> Does the user care to which channel does the interrupt source goes
>>>> to? If not, interrupt-cells in DT can just be a single entry and the
>>>> channel selection can be controlled by the driver no? I am trying to
>>>> understand why user should specify the channel no.
>>> Hi Lokesh,
>>>
>>> If a fixed channel is specified in the driver, all interrupt sources
>>> will be connected to this channel, affecting the interrupt priority to
>>> some extent.
>>>
>>> From my point of view, a fixed channel could be enough if don't care
>>> interrupt priority.
>>
>> Hold on a sec:
>>
>> Is the channel to which an interrupt is routed to programmable? What has the
>> priority of the interrupt to do with this? How does this affect interrupt
>> delivery?
>>
>> It looks like this HW does more that you initially explained...
> Hi Marc,
> 
> The channel to which an interrupt is routed to is not programmable. Each channel has the same 32 interrupt sources.

But the interrupt source to channel is programmable right? I guess you are
worried about the affinity for each interrupt. You can bring the logic inside
the driver to assign the channel to each interrupt source and can maintain the
affinity to some extent..

> Each channel has mask, unmask and status register.
> If use 1 channel, 32 interrupt sources input and 1 interrupt output.
> If use 2 channels, 32 interrupt sources input and 2 interrupts output.
> And so on. You can see above INTMUX block diagram. This is how HW works.
> 
> For example:
> 1) use 1 channel:
> We can enable 0~31 interrupt in channel 0. And 1 interrupt output. If generate interrupt, we cannot figure out which half happened first.

Hmm...does this mean that each channel is capable of handling only 15 interrupt
sources or did I missunderstood the hardware?

Thanks and regards,
Lokesh

> 2)use 2 channels:
> We can enable 0~15 interrupt in channel 0, and enable 16~31 in channel 1. And 2 interrupts output. If generate interrupt, at least we can find channel 0 or channel 1 first. Then find 0~15 or 16~31 first.
> 
> This is my understanding of the interrupt priority from this intmux, I don't know if it is my misunderstanding.
> 
> Best Regards,
> Joakim Zhang
>>          M.
>> --
>> Jazz is not dead. It just smells funny...