RE: [PATCH 0/7] towards QE support on ARM

From: Qiang Zhao <qiang.zhao@nxp.com>
To: Leo Li <leoyang.li@nxp.com>, Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Timur Tabi <timur@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
	Jiri Slaby <jslaby@suse.com>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH 0/7] towards QE support on ARM
Date: Tue, 22 Oct 2019 02:24:17 +0000	[thread overview]
Message-ID: <VE1PR04MB676825D5709839AEF75ED44C91680@VE1PR04MB6768.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <CADRPPNSiMUy77Dhxjg03sHDxyZzWf_BP8a5+fCncbynyO_cNGg@mail.gmail.com>

On Mon, Oct 22, 2019 at 6:11 AM Leo Li wrote
> -----Original Message-----
> From: Li Yang <leoyang.li@nxp.com>
> Sent: 2019年10月22日 6:11
> To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> Cc: Timur Tabi <timur@kernel.org>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; linux-kernel@vger.kernel.org;
> linux-serial@vger.kernel.org; Jiri Slaby <jslaby@suse.com>;
> linuxppc-dev@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org; Qiang
> Zhao <qiang.zhao@nxp.com>
> Subject: Re: [PATCH 0/7] towards QE support on ARM
> 
> On Mon, Oct 21, 2019 at 3:46 AM Rasmus Villemoes
> <linux@rasmusvillemoes.dk> wrote:
> >
> > On 18/10/2019 23.52, Li Yang wrote:
> > > On Fri, Oct 18, 2019 at 3:54 PM Rasmus Villemoes
> > > <linux@rasmusvillemoes.dk> wrote:
> > >>
> > >> On 18/10/2019 22.16, Leo Li wrote:
> > >>>
> > >>>>
> > >>>> There have been several attempts in the past few years to allow
> > >>>> building the QUICC engine drivers for platforms other than PPC.
> > >>>> This is (the beginning of) yet another attempt. I hope I can get
> > >>>> someone to pick up these relatively trivial patches (I _think_
> > >>>> they shouldn't change functionality at all), and then I'll
> > >>>> continue slowly working towards removing the PPC32 dependency for
> CONFIG_QUICC_ENGINE.
> > >>>
> > >>> Hi Rasmus,
> > >>>
> > >>> I don't fully understand the motivation of this work.  As far as I know
> the QUICC ENGINE is only used on PowerPC based SoCs.
> > >>
> > >> Hm, you're not the Leo Li that participated in this thread
> > >>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> rnel.org%2Flkml%2FAM3PR04MB11857AE8D2B0BE56121B97D391C90%40A
> M3PR04MB1185.eurprd04.prod.outlook.com%2FT%2F%23u&amp;data=02%7
> C01%7Cqiang.zhao%40nxp.com%7C1ba8c50c2db14b22bef608d756739d82%
> 7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6370729268771788
> 75&amp;sdata=k4zM75OczXwZF%2Br9ec4RxiVR2a%2F8GhSZmK70JYddIck%3
> D&amp;reserved=0>?
> > >
> > > Oops, I totally forgot about this discussion which is just three
> > > years ago.  :)  The QE-HDLC on LS1021a is kind of a special case.
> > >
> > >>
> > >>
> > >>  Can you give an example on how is it used on ARM system?
> > >>
> > >> LS1021A, for example, which is the one I'm aiming for getting fully
> > >> supported in mainline.
> > >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > >>
> www.nxp.com%2Fproducts%2Fprocessors-and-microcontrollers%2Farm-proc
> > >> essors%2Flayerscape-communication-process%2Fqoriq-layerscape-1021a-
> > >>
> dual-core-communications-processor-with-lcd-controller%3ALS1021A&am
> > >>
> p;data=02%7C01%7Cqiang.zhao%40nxp.com%7C1ba8c50c2db14b22bef608d
> 7567
> > >>
> 39d82%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6370729268
> 771788
> > >>
> 75&amp;sdata=vqPYSZqEv6vCEIxJshLuA4gngh9J4IsFAQrTwJKMjm4%3D&amp;r
> es
> > >> erved=0>
> > >>
> > >> The forks at
> > >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> com%2Fqoriq-open-source%2Flinux.git&amp;data=02%7C01%7Cqiang.zhao%
> 40nxp.com%7C1ba8c50c2db14b22bef608d756739d82%7C686ea1d3bc2b4c6
> fa92cd99c5c301635%7C0%7C0%7C637072926877178875&amp;sdata=v4eG
> 4KqGTWQkQHp%2FYg2OHCKITLWaOgH64JYpY%2B1LilA%3D&amp;reserved=0
> have various degrees of support (grep for commits saying stuff like "remove
> PPCisms"
> > >> - some versions can be found on
> > >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > >>
> lore.kernel.org%2Flkml%2F%3Fq%3Dremove%2Bppcisms&amp;data=02%7C0
> 1%7
> > >>
> Cqiang.zhao%40nxp.com%7C1ba8c50c2db14b22bef608d756739d82%7C686e
> a1d3
> > >>
> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637072926877178875&amp;sdat
> a=i2WdKNHLV68a1mTOMQ%2FoMr0y5ee8edS07xq61M8%2BvPU%3D&amp;r
> eserved=0>). Our current kernel is based on commits from the now-vanished
> 4.1 branch, and unfortunately at least the 4.14 branch (LSDK-18.06-V4.14)
> trivially doesn't build on ARM, despite the PPC32 dependency having been
> removed from CONFIG_QUICC_ENGINE.
> > >
> > > Can you try the 4.14 branch from a newer LSDK release?  LS1021a
> > > should be supported platform on LSDK.  If it is broken, something is
> wrong.
> >
> > What newer release? LSDK-18.06-V4.14 is the latest -V4.14 tag at
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >
> ub.com%2Fqoriq-open-source%2Flinux.git&amp;data=02%7C01%7Cqiang.zha
> o%4
> >
> 0nxp.com%7C1ba8c50c2db14b22bef608d756739d82%7C686ea1d3bc2b4c6f
> a92cd99c
> >
> 5c301635%7C0%7C0%7C637072926877188868&amp;sdata=vdm4qPoTzfIpXL
> mRrv17EW
> > noxG3n91qELMGqvRh9we4%3D&amp;reserved=0, and identical to the
> 
> That tree has been abandoned for a while, we probably should state that in the
> github.  The latest tree can be found at
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.
> codeaurora.org%2Fexternal%2Fqoriq%2Fqoriq-components%2Flinux%2F&amp
> ;data=02%7C01%7Cqiang.zhao%40nxp.com%7C1ba8c50c2db14b22bef608d7
> 56739d82%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6370729
> 26877188868&amp;sdata=NooBFUWnceTG2OF24pCuP0AYgKfr0Df%2BtrcCY6
> X6Dog%3D&amp;reserved=0
> 
> > linux-4.14 branch. And despite commit 4c33e2d0576b removing the PPC32
> > dependency from QUICC_ENGINE, it clearly hasn't been built on arm,
> > since back around v4.12, mainline's qe.c grew a call to pvr_version_is
> > which is ppc-only. So from that I sort of assumed that NXP had dropped
> > trying to support the LS1021A even in their own kernels.
> >
> > In any case, we have zero interest in running an NXP kernel. Maybe I
> > should clarify what I meant by "based on commits from" above: We're
> > currently running a mainline 4.14 kernel on LS1021A, with a few
> > patches inspired from the NXP 4.1 branch applied on top - but also
> > with some manual fixes for e.g. the pvr_version_is() issue. Now we
> > want to move that to a 4.19-based kernel (so that it aligns with our
> MPC8309 platform).
> 
> We also provide 4.19 based kernel in the codeaurora repo.  I think it will be
> helpful to reuse patches there if you want to make your own tree.
> 
> >
> > >> This is just some first few steps, and I'm not claiming that this
> > >> is sufficient to make the QE drivers build on ARM yet. But I have a
> > >> customer with both mpc8309-based and ls1021a-based platforms, and
> > >> they want to run the same, as-close-to-mainline-as-possible, kernel
> > >> on both. So I will take a piecemeal approach, and try to make sure
> > >> I don't break the ppc boards in the process (just building and
> > >> booting one board is of course not sufficient, but better than
> > >> nothing). Once I get to actually build some of the QE drivers for
> > >> ARM, I'll of course also test them.
> > >
> > > Understood.  Zhao Qiang also maintains some patches similar to your
> > > patchset and I think they are tested on ARM.  But the review of
> > > these patches from last submission didn't finish.  It looks like
> > > your patches are better divided but not really verified on ARM.
> > > Zhao Qiang's patches are tested but maybe need some final touch for
> > > cleaning up.  I will let you guys decide what is the best approach
> > > to make this upstreamed.
> >
> > Yes, as I said, I wanted to try a fresh approach since Zhao Qiang's
> > patches seemed to be getting nowhere. Splitting the patches into
> > smaller pieces is definitely part of that - for example, the
> > completely trivial whitespace fix in patch 1 is to make sure the later
> > coccinelle generated patch is precisely that (i.e., a later respin can
> > just rerun the coccinelle script, with zero manual fixups). I also
> > want to avoid mixing the ppcism cleanups with other things (e.g.
> > replacing some
> > of_get_property() by of_property_read_u32()). And the "testing on ARM"
> > part comes once I get to actually building on ARM. But there's not
> > much point doing all that unless there's some indication that this can
> > be applied to some tree that actually feeds into Linus', which is why
> > I started with a few trivial patches and precisely to start this discussion.
> 
> Right.  I'm really interested in getting this applied to my tree and make it
> upstream.  Zhao Qiang, can you help to review Rasmus's patches and
> comment?

As you know, I maintained a similar patchset removing PPC, and someone told me qe_ic should moved into drivers/irqchip/.
I also thought qe_ic is a interrupt control driver, should be moved into dir irqchip.

Regards,
Qiang