lkml.org 
[lkml]   [2020]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [EXT] Re: [v2 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A external interrupt
Date


> -----Original Message-----
> From: Biwen Li (OSS) <biwen.li@oss.nxp.com>
> Sent: Monday, November 2, 2020 12:15 AM
> To: Leo Li <leoyang.li@nxp.com>; Rasmus Villemoes
> <linux@rasmusvillemoes.dk>; Biwen Li (OSS) <biwen.li@oss.nxp.com>;
> shawnguo@kernel.org; robh+dt@kernel.org; mark.rutland@arm.com; Z.q.
> Hou <zhiqiang.hou@nxp.com>; tglx@linutronix.de; jason@lakedaemon.net;
> maz@kernel.org
> Cc: devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Jiafei Pan
> <jiafei.pan@nxp.com>; Xiaobo Xie <xiaobo.xie@nxp.com>; linux-arm-
> kernel@lists.infradead.org
> Subject: RE: [EXT] Re: [v2 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A
> external interrupt
>
> > > >
> > > > Caution: EXT Email
> > > >
> > > > On 27/10/2020 05.46, Biwen Li wrote:
> > > > > From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> > > > >
> > > > > Add an new IRQ chip declaration for LS1043A and LS1088A
> > > > > - compatible "fsl,ls1043a-extirq" for LS1043A, LS1046A.
> > SCFG_INTPCR[31:0]
> > > > > of these SoCs is stored/read as SCFG_INTPCR[0:31] defaultly(bit
> > > > > reverse)
> > > >
> > > > s/defaultly/by default/ I suppose. But what does that mean? Is it
> > > > still configurable, just now through some undocumented register?
> > > > If that register still exists, does it now have a reset value of
> > > > all-ones as opposed to the ls1021 case? If it's not configurable,
> > > > then describing the situation as "by default" is confusing and
> > > > wrong, it should just say "On LS1043A, LS1046A, SCFG_INTPCR is
> > > > stored/read bit-
> > > reversed."
> > > Okay, got it. Will update it in v3. Thanks.
> >
> > Hi Biwen,
> >
> > Where did you get this information that the register on LS1043 and
> > LS1046 is bit reversed? I cannot find such information in the RM.
> > And does this mean all other SCFG registers are also bit reversed? If
> > this is some information that is not covered by the RM, we probably
> > should clarify it in the code and the commit message.
> Hi Leo,
>
> I directly use the same logic to write the bit(field IRQ0~11INTP) of the
> register SCFG_INTPCR in LS1043A and LS1046A.
> Such as,
> if I want to control the polarity of IRQ0(field IRQ0INTP, IRQ0 is active low) of
> LS1043A/LS1046A, then I just need write a value 1 << (31 - 0) to it.
> The logic depends on register's definition in LS1043A/LS1046A's RM.

Ok. The SCFG_SCFGREVCR seems to be a one-off fixup only existed on LS1021. And it is mandatory to be bit_reversed according to the RM which is already taken care of in the RCW. So the bit reversed case should be the only case supported otherwise a lot of other places for SCFG access should be failed.

I think we should remove the bit_reverse thing all together from the driver for good. This will prevent future confusion. Rasmus, what do you think?

Regards,
Leo

>
> Regards,
> Biwen
>
> >
> > Regards,
> > Leo
> >
> > > >
> > > >
> > > > > - compatible "fsl,ls1088a-extirq" for LS1088A, LS208xA, LX216xA
> > > > >
> > > > > Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> > > > > Signed-off-by: Biwen Li <biwen.li@nxp.com>
> > > > > ---
> > > > > Change in v2:
> > > > > - add despcription of bit reverse
> > > > > - update copyright
> > > > >
> > > > > drivers/irqchip/irq-ls-extirq.c | 10 +++++++++-
> > > > > 1 file changed, 9 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/irqchip/irq-ls-extirq.c
> > > > > b/drivers/irqchip/irq-ls-extirq.c index
> > > > > 4d1179fed77c..9587bc2607fc
> > > > > 100644
> > > > > --- a/drivers/irqchip/irq-ls-extirq.c
> > > > > +++ b/drivers/irqchip/irq-ls-extirq.c
> > > > > @@ -1,5 +1,8 @@
> > > > > // SPDX-License-Identifier: GPL-2.0
> > > > > -
> > > > > +/*
> > > > > + * Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> > > >
> > > > If I wanted my name splattered all over the files I touch or add,
> > > > I'd add it myself, TYVM. The git history is plenty fine for
> > > > recording authorship as far as I'm concerned, and I absolutely
> > > > abhor having to skip over any kind of legalese boilerplate when opening
> a file.
> > > Okay, got it. Will drop it in v3. Thanks.
> > > >
> > > > Rasmus

\
 
 \ /
  Last update: 2020-11-02 22:22    [W:0.102 / U:1.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site