lkml.org 
[lkml]   [2019]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH V3 2/2] drivers/irqchip: add NXP INTMUX interrupt multiplexer support
Date

> -----Original Message-----
> From: Joakim Zhang
> Sent: 2019年12月20日 23:26
> To: 'Marc Zyngier' <maz@kernel.org>
> 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
>
>
> > -----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.
> 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.
> 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.

So assign interrupt sources to multi-channels will generate multi-interrupt output. And these output interrupts are sequential. Could this be interpreted as interrupt priority?

Best Regards,
Joakim Zhang
> Best Regards,
> Joakim Zhang
> > M.
> > --
> > Jazz is not dead. It just smells funny...
\
 
 \ /
  Last update: 2019-12-20 16:36    [W:0.058 / U:7.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site