Message-ID: <DB7PR04MB4618A3FB15E8095E2AE43B65E62E0@DB7PR04MB4618.eurprd04.prod.outlook.com>
Date:   Mon, 23 Dec 2019 11:11:35 +0000
From:   Joakim Zhang <qiangqing.zhang@....com>
To:     Lokesh Vutla <lokeshvutla@...com>, Marc Zyngier <maz@...nel.org>
CC:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "jason@...edaemon.net" <jason@...edaemon.net>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        Andy Duan <fugang.duan@....com>,
        "S.j. Wang" <shengjiu.wang@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH V3 2/2] drivers/irqchip: add NXP INTMUX interrupt
 multiplexer support


> -----Original Message-----
> From: Lokesh Vutla <lokeshvutla@...com>
> Sent: 2019年12月23日 18:11
> To: Joakim Zhang <qiangqing.zhang@....com>; Marc Zyngier
> <maz@...nel.org>
> Cc: tglx@...utronix.de; jason@...edaemon.net; robh+dt@...nel.org;
> mark.rutland@....com; shawnguo@...nel.org; s.hauer@...gutronix.de;
> Andy Duan <fugang.duan@....com>; S.j. Wang <shengjiu.wang@....com>;
> linux-kernel@...r.kernel.org; dl-linux-imx <linux-imx@....com>;
> kernel@...gutronix.de; linux-arm-kernel@...ts.infradead.org
> Subject: Re: [PATCH V3 2/2] drivers/irqchip: add NXP INTMUX interrupt
> multiplexer support
> 
> 
> 
> On 20/12/19 8:56 PM, Joakim Zhang wrote:
> >
> >> -----Original Message-----
> >> From: Marc Zyngier <maz@...nel.org>
> >> Sent: 2019年12月20日 22:20
> >> To: Joakim Zhang <qiangqing.zhang@....com>
> >> Cc: Lokesh Vutla <lokeshvutla@...com>; tglx@...utronix.de;
> >> jason@...edaemon.net; robh+dt@...nel.org; mark.rutland@....com;
> >> shawnguo@...nel.org; s.hauer@...gutronix.de; Andy Duan
> >> <fugang.duan@....com>; S.j. Wang <shengjiu.wang@....com>;
> >> linux-kernel@...r.kernel.org; dl-linux-imx <linux-imx@....com>;
> >> kernel@...gutronix.de; linux-arm-kernel@...ts.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@...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 supports 32 interrupt sources, you can unmask interrupt sources which you want generate via this channel, and other interrupt sources stay mask.

> > 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?
Yes, you just need unmask interrupt sources you want for each channel.

For intmux IP:
1) 8 output interrupts can connect to different cores (A core, M4, DSP, and so on), so this is 32-to-1.
2) 8 output interrupts can connect to one core, so this is 32-to-8

In our i.MX8 SoCs, intmux is integrated in M4 and 8 output interrupts all connected to GIC in A core.
Supposed that there are 4 devices actually request to intmux, so intmux has 4 interrupt sources.
We can assign these 4 interrupt sources via interrupt specifier to channel 0. This is 4-to-1.
We also can assign 4 interrupt sources via interrupt specifier to channel 0/1/2/3. This is 4-to4.

I think interrupts handing sequence could be more closed to interrupts generate sequence if one channel unmask less interrupts sources(i.e. enable less interrupt sources for that channel).
Since we always check interrupt pending status for onechannel from sources 0 to 31.

This should not be interrupt priority, sorry for my previous answer. 

Best Regards,
Joakim Zhang
> 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...

Powered by blists - more mailing lists