Message ID | 20191018125234.21825-1-linux@rasmusvillemoes.dk (mailing list archive) |
---|---|
Headers | show |
Series | towards QE support on ARM | expand |
> -----Original Message----- > From: Rasmus Villemoes <linux@rasmusvillemoes.dk> > Sent: Friday, October 18, 2019 7:52 AM > To: Qiang Zhao <qiang.zhao@nxp.com>; Leo Li <leoyang.li@nxp.com>; Greg > Kroah-Hartman <gregkh@linuxfoundation.org>; Jiri Slaby > <jslaby@suse.com>; Timur Tabi <timur@kernel.org>; linuxppc- > dev@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org; linux- > kernel@vger.kernel.org; linux-serial@vger.kernel.org > Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> > Subject: [PATCH 0/7] towards QE support on ARM > > 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. Can you give an example on how is it used on ARM system? > > Tested on an MPC8309-derived board. MPC8309 is also PPC based. > > Rasmus Villemoes (7): > soc: fsl: qe: remove space-before-tab > soc: fsl: qe: drop volatile qualifier of struct qe_ic::regs > soc: fsl: qe: avoid ppc-specific io accessors > soc: fsl: qe: replace spin_event_timeout by readx_poll_timeout_atomic > serial: make SERIAL_QE depend on PPC32 > serial: ucc_uart.c: explicitly include asm/cpm.h > soc/fsl/qe/qe.h: remove include of asm/cpm.h > > drivers/soc/fsl/qe/gpio.c | 30 ++++++++-------- > drivers/soc/fsl/qe/qe.c | 44 +++++++++++------------ > drivers/soc/fsl/qe/qe_ic.c | 8 ++--- > drivers/soc/fsl/qe/qe_ic.h | 2 +- > drivers/soc/fsl/qe/qe_io.c | 40 ++++++++++----------- > drivers/soc/fsl/qe/qe_tdm.c | 8 ++--- > drivers/soc/fsl/qe/ucc.c | 12 +++---- > drivers/soc/fsl/qe/ucc_fast.c | 66 ++++++++++++++++++----------------- > drivers/soc/fsl/qe/ucc_slow.c | 38 ++++++++++---------- > drivers/soc/fsl/qe/usb.c | 2 +- > drivers/tty/serial/Kconfig | 1 + > drivers/tty/serial/ucc_uart.c | 1 + > include/soc/fsl/qe/qe.h | 1 - > 13 files changed, 126 insertions(+), 127 deletions(-) > > -- > 2.20.1
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://lore.kernel.org/lkml/AM3PR04MB11857AE8D2B0BE56121B97D391C90@AM3PR04MB1185.eurprd04.prod.outlook.com/T/#u>? 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://www.nxp.com/products/processors-and-microcontrollers/arm-processors/layerscape-communication-process/qoriq-layerscape-1021a-dual-core-communications-processor-with-lcd-controller:LS1021A> The forks at https://github.com/qoriq-open-source/linux.git have various degrees of support (grep for commits saying stuff like "remove PPCisms" - some versions can be found on <https://lore.kernel.org/lkml/?q=remove+ppcisms>). 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. >> >> Tested on an MPC8309-derived board. > > MPC8309 is also PPC based. True, of course. 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. Rasmus
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://lore.kernel.org/lkml/AM3PR04MB11857AE8D2B0BE56121B97D391C90@AM3PR04MB1185.eurprd04.prod.outlook.com/T/#u>? 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://www.nxp.com/products/processors-and-microcontrollers/arm-processors/layerscape-communication-process/qoriq-layerscape-1021a-dual-core-communications-processor-with-lcd-controller:LS1021A> > > The forks at https://github.com/qoriq-open-source/linux.git have various > degrees of support (grep for commits saying stuff like "remove PPCisms" > - some versions can be found on > <https://lore.kernel.org/lkml/?q=remove+ppcisms>). 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. > > >> > >> Tested on an MPC8309-derived board. > > > > MPC8309 is also PPC based. > > True, of course. 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. Regards, Leo
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://lore.kernel.org/lkml/AM3PR04MB11857AE8D2B0BE56121B97D391C90@AM3PR04MB1185.eurprd04.prod.outlook.com/T/#u>? > > 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://www.nxp.com/products/processors-and-microcontrollers/arm-processors/layerscape-communication-process/qoriq-layerscape-1021a-dual-core-communications-processor-with-lcd-controller:LS1021A> >> >> The forks at https://github.com/qoriq-open-source/linux.git have various >> degrees of support (grep for commits saying stuff like "remove PPCisms" >> - some versions can be found on >> <https://lore.kernel.org/lkml/?q=remove+ppcisms>). 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://github.com/qoriq-open-source/linux.git, and identical to the 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). >> 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. Rasmus
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://lore.kernel.org/lkml/AM3PR04MB11857AE8D2B0BE56121B97D391C90@AM3PR04MB1185.eurprd04.prod.outlook.com/T/#u>? > > > > 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://www.nxp.com/products/processors-and-microcontrollers/arm-processors/layerscape-communication-process/qoriq-layerscape-1021a-dual-core-communications-processor-with-lcd-controller:LS1021A> > >> > >> The forks at https://github.com/qoriq-open-source/linux.git have various > >> degrees of support (grep for commits saying stuff like "remove PPCisms" > >> - some versions can be found on > >> <https://lore.kernel.org/lkml/?q=remove+ppcisms>). 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://github.com/qoriq-open-source/linux.git, 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://source.codeaurora.org/external/qoriq/qoriq-components/linux/ > 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? Regards, Leo
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&data=02%7 > C01%7Cqiang.zhao%40nxp.com%7C1ba8c50c2db14b22bef608d756739d82% > 7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6370729268771788 > 75&sdata=k4zM75OczXwZF%2Br9ec4RxiVR2a%2F8GhSZmK70JYddIck%3 > D&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&sdata=vqPYSZqEv6vCEIxJshLuA4gngh9J4IsFAQrTwJKMjm4%3D&r > es > > >> erved=0> > > >> > > >> The forks at > > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. > com%2Fqoriq-open-source%2Flinux.git&data=02%7C01%7Cqiang.zhao% > 40nxp.com%7C1ba8c50c2db14b22bef608d756739d82%7C686ea1d3bc2b4c6 > fa92cd99c5c301635%7C0%7C0%7C637072926877178875&sdata=v4eG > 4KqGTWQkQHp%2FYg2OHCKITLWaOgH64JYpY%2B1LilA%3D&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&data=02%7C0 > 1%7 > > >> > Cqiang.zhao%40nxp.com%7C1ba8c50c2db14b22bef608d756739d82%7C686e > a1d3 > > >> > bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637072926877178875&sdat > a=i2WdKNHLV68a1mTOMQ%2FoMr0y5ee8edS07xq61M8%2BvPU%3D&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&data=02%7C01%7Cqiang.zha > o%4 > > > 0nxp.com%7C1ba8c50c2db14b22bef608d756739d82%7C686ea1d3bc2b4c6f > a92cd99c > > > 5c301635%7C0%7C0%7C637072926877188868&sdata=vdm4qPoTzfIpXL > mRrv17EW > > noxG3n91qELMGqvRh9we4%3D&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& > ;data=02%7C01%7Cqiang.zhao%40nxp.com%7C1ba8c50c2db14b22bef608d7 > 56739d82%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6370729 > 26877188868&sdata=NooBFUWnceTG2OF24pCuP0AYgKfr0Df%2BtrcCY6 > X6Dog%3D&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
On 22/10/2019 00.11, Li Yang wrote: > On Mon, Oct 21, 2019 at 3:46 AM Rasmus Villemoes > <linux@rasmusvillemoes.dk> wrote: >> >>> 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://github.com/qoriq-open-source/linux.git, 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://source.codeaurora.org/external/qoriq/qoriq-components/linux/ Ah. FYI, googling "LSDK" gives https://lsdk.github.io as one of the first hits, and (apart from itself being a github url) that says on the front page "Disaggregated components of LSDK are available in github.". But yes, navigating to the Components tab and from there to lsdk linux one does get directed at codeaurora. >> 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. Again, we don't want to run off an NXP kernel, we want to get the necessary pieces upstream. For now, we have to live with a patched 4.19 kernel, but hopefully by the time we switch to 5.x (for some x >= 5) we don't need to supply anything other than our own .dts and defconfig. >> 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? Thanks, this is exactly what I was hoping for. Even just getting these first rather trivial patches (in that they don't attempt to build for ARM, or change functionality at all for PPC) merged for 5.5 would reduce the amount of out-of-tree patches that we (and NXP for that matter) would have to carry. I'll take the above as a go-ahead for me to try to post more patches working towards enabling some of the QE drivers for ARM. Rasmus
On 22/10/2019 04.24, Qiang Zhao wrote: > On Mon, Oct 22, 2019 at 6:11 AM Leo Li wrote >> 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. Yes, and I also plan to do that at some point. However, that's orthogonal to making the driver build on ARM, so I don't want to mix the two. Making it usable on ARM is my/our priority currently. I'd appreciate your input on my patches. Rasmus
On 10/18/2019 12:52 PM, Rasmus Villemoes 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. > > Tested on an MPC8309-derived board. > > Rasmus Villemoes (7): > soc: fsl: qe: remove space-before-tab > soc: fsl: qe: drop volatile qualifier of struct qe_ic::regs > soc: fsl: qe: avoid ppc-specific io accessors > soc: fsl: qe: replace spin_event_timeout by readx_poll_timeout_atomic > serial: make SERIAL_QE depend on PPC32 > serial: ucc_uart.c: explicitly include asm/cpm.h > soc/fsl/qe/qe.h: remove include of asm/cpm.h Please copy the entire series to linuxppc-dev list. We are missing 5/7 and 7/7 (see https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=137048) Christophe > > drivers/soc/fsl/qe/gpio.c | 30 ++++++++-------- > drivers/soc/fsl/qe/qe.c | 44 +++++++++++------------ > drivers/soc/fsl/qe/qe_ic.c | 8 ++--- > drivers/soc/fsl/qe/qe_ic.h | 2 +- > drivers/soc/fsl/qe/qe_io.c | 40 ++++++++++----------- > drivers/soc/fsl/qe/qe_tdm.c | 8 ++--- > drivers/soc/fsl/qe/ucc.c | 12 +++---- > drivers/soc/fsl/qe/ucc_fast.c | 66 ++++++++++++++++++----------------- > drivers/soc/fsl/qe/ucc_slow.c | 38 ++++++++++---------- > drivers/soc/fsl/qe/usb.c | 2 +- > drivers/tty/serial/Kconfig | 1 + > drivers/tty/serial/ucc_uart.c | 1 + > include/soc/fsl/qe/qe.h | 1 - > 13 files changed, 126 insertions(+), 127 deletions(-) >
On 22/10/2019 18:18, Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote: > -----Original Message----- > From: Rasmus Villemoes <linux@rasmusvillemoes.dk> > Sent: 2019年10月22日 18:18 > To: Qiang Zhao <qiang.zhao@nxp.com>; Leo Li <leoyang.li@nxp.com> > 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 > Subject: Re: [PATCH 0/7] towards QE support on ARM > > On 22/10/2019 04.24, Qiang Zhao wrote: > > On Mon, Oct 22, 2019 at 6:11 AM Leo Li wrote > > >> 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. > > Yes, and I also plan to do that at some point. However, that's orthogonal to > making the driver build on ARM, so I don't want to mix the two. Making it > usable on ARM is my/our priority currently. > > I'd appreciate your input on my patches. Yes, we can put this patchset in first place, ensure it can build and work on ARM, then push another patchset to move qe_ic. Best Regards, Qiang
On Tue, Oct 22, 2019 at 9:54 PM Qiang Zhao <qiang.zhao@nxp.com> wrote: > > On 22/10/2019 18:18, Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote: > > -----Original Message----- > > From: Rasmus Villemoes <linux@rasmusvillemoes.dk> > > Sent: 2019年10月22日 18:18 > > To: Qiang Zhao <qiang.zhao@nxp.com>; Leo Li <leoyang.li@nxp.com> > > 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 > > Subject: Re: [PATCH 0/7] towards QE support on ARM > > > > On 22/10/2019 04.24, Qiang Zhao wrote: > > > On Mon, Oct 22, 2019 at 6:11 AM Leo Li wrote > > > > >> 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. > > > > Yes, and I also plan to do that at some point. However, that's orthogonal to > > making the driver build on ARM, so I don't want to mix the two. Making it > > usable on ARM is my/our priority currently. > > > > I'd appreciate your input on my patches. > > Yes, we can put this patchset in first place, ensure it can build and work on ARM, then push another patchset to move qe_ic. Right. I would only accept a patch series that can really build and work on ARM. At least the current out-of-tree patches can make it work on ARM. If we accept partial changes, there is no way to make it work on the latest kernel on ARM then. Regards, Leo
There have been several attempts in the past few years to allow building the QUICC engine drivers for platforms other than PPC. This is yet another attempt. In v2, I've fixed a few style issues. But more importantly, it now contains enough to actually remove the PPC32 dependency from CONFIG_QUICC_ENGINE, so that's what the last patch does. I haven't found a way to address Christophe's concern over the performance impact of using the (on powerpc) out-of-line iowrite32be instead of out_be32. I could of course introduce some qe_ prefixed helpers (similar to the already added qe_clrsetbits ones) and make their definition dependent on PPC32 or not, but that seems to be a bit ugly. Rasmus Villemoes (23): soc: fsl: qe: remove space-before-tab soc: fsl: qe: drop volatile qualifier of struct qe_ic::regs soc: fsl: qe: avoid ppc-specific io accessors soc: fsl: qe: replace spin_event_timeout by readx_poll_timeout_atomic soc: fsl: qe: qe.c: guard use of pvr_version_is() with CONFIG_PPC32 soc: fsl: qe: avoid tail comments in qe_ic.h soc: fsl: qe: merge qe_ic.h into qe_ic.c soc: fsl: qe: drop unneeded #includes soc: fsl: qe: move qe_ic_cascade_* functions to qe_ic.c soc: fsl: qe: use qe_ic_cascade_{low,high}_mpic also on 83xx soc: fsl: qe: rename qe_ic_cascade_low_mpic -> qe_ic_cascade_low soc: fsl: qe: drop assign-only high_active in qe_ic_init soc: fsl: qe: remove pointless sysfs registration in qe_ic.c soc: fsl: qe: move calls of qe_ic_init out of arch/powerpc/ powerpc/83xx: remove mpc83xx_ipic_and_qe_init_IRQ powerpc/85xx: remove mostly pointless mpc85xx_qe_init() soc: fsl: qe: make qe_ic_cascade_* static soc: fsl: qe: remove unused qe_ic_set_* functions net: ethernet: freescale: make UCC_GETH explicitly depend on PPC32 serial: make SERIAL_QE depend on PPC32 serial: ucc_uart.c: explicitly include asm/cpm.h soc/fsl/qe/qe.h: remove include of asm/cpm.h soc: fsl: qe: remove PPC32 dependency from CONFIG_QUICC_ENGINE arch/powerpc/platforms/83xx/km83xx.c | 3 +- arch/powerpc/platforms/83xx/misc.c | 23 -- arch/powerpc/platforms/83xx/mpc832x_mds.c | 3 +- arch/powerpc/platforms/83xx/mpc832x_rdb.c | 3 +- arch/powerpc/platforms/83xx/mpc836x_mds.c | 3 +- arch/powerpc/platforms/83xx/mpc836x_rdk.c | 3 +- arch/powerpc/platforms/83xx/mpc83xx.h | 7 - arch/powerpc/platforms/85xx/common.c | 23 -- arch/powerpc/platforms/85xx/corenet_generic.c | 12 - arch/powerpc/platforms/85xx/mpc85xx.h | 2 - arch/powerpc/platforms/85xx/mpc85xx_mds.c | 28 -- arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 18 -- arch/powerpc/platforms/85xx/twr_p102x.c | 16 - drivers/net/ethernet/freescale/Kconfig | 1 + drivers/soc/fsl/qe/Kconfig | 2 +- drivers/soc/fsl/qe/gpio.c | 30 +- drivers/soc/fsl/qe/qe.c | 59 ++-- drivers/soc/fsl/qe/qe_ic.c | 289 ++++++++++-------- drivers/soc/fsl/qe/qe_ic.h | 99 ------ drivers/soc/fsl/qe/qe_io.c | 42 ++- drivers/soc/fsl/qe/qe_tdm.c | 8 +- drivers/soc/fsl/qe/ucc.c | 16 +- drivers/soc/fsl/qe/ucc_fast.c | 70 ++--- drivers/soc/fsl/qe/ucc_slow.c | 38 +-- drivers/soc/fsl/qe/usb.c | 2 +- drivers/tty/serial/Kconfig | 1 + drivers/tty/serial/ucc_uart.c | 1 + include/soc/fsl/qe/qe.h | 1 - include/soc/fsl/qe/qe_ic.h | 69 ----- 29 files changed, 299 insertions(+), 573 deletions(-) delete mode 100644 drivers/soc/fsl/qe/qe_ic.h
There have been several attempts in the past few years to allow building the QUICC engine drivers for platforms other than PPC. This is yet another attempt. Changes in v3: - Address the performance impact on ppc from replacing out_be32 by iowrite32be by instead introducing a qe_iowrite32be wrapper and using that - patches 3 and 4 in this series. - Extend the series so that both the QE core as well as ucc_uart builds for ARM - patches 26-33. - Reorganize things a bit to avoid touching code that gets killed anyway in a later patch. Also the patches are now better grouped: 1-5 are about replacing in_be32 etc. in the core QE code (drivers/soc/fsl/qe). 6-8 handle miscellaneous other ppcisms. 9-21 deal with qe_ic: Simplifying the driver significantly by removing unused code, and removing the platform-specific initialization from arch/powerpc/. 22-25 deal with raw access to devicetree properties in native endianness. 26-33 makes drivers/tty/serial/ucc_uart.c (CONFIG_SERIAL_QE) ready to build on arm. 34-36 remove the PPC32 dependency from QUICC_ENGINE. Two drivers that depend on QUICC_ENGINE get an explicit PPC32 dependency to prevent allmodconfig build failures. The series has been built and booted on both an mpc8309-based platform (ppc) as well as an ls1021a-based platform (arm). The core QE code is exercised on both, while I could only test the ucc_uart on arm, since the uarts are not wired up on our mpc8309 board. Rasmus Villemoes (36): soc: fsl: qe: remove space-before-tab soc: fsl: qe: drop volatile qualifier of struct qe_ic::regs soc: fsl: qe: rename qe_(clr/set/clrset)bit* helpers soc: fsl: qe: introduce qe_io{read,write}* wrappers soc: fsl: qe: avoid ppc-specific io accessors soc: fsl: qe: replace spin_event_timeout by readx_poll_timeout_atomic soc: fsl: qe: qe.c: guard use of pvr_version_is() with CONFIG_PPC32 soc: fsl: qe: drop unneeded #includes soc: fsl: qe: drop assign-only high_active in qe_ic_init soc: fsl: qe: remove pointless sysfs registration in qe_ic.c soc: fsl: qe: use qe_ic_cascade_{low,high}_mpic also on 83xx soc: fsl: qe: move calls of qe_ic_init out of arch/powerpc/ powerpc/83xx: remove mpc83xx_ipic_and_qe_init_IRQ powerpc/85xx: remove mostly pointless mpc85xx_qe_init() soc: fsl: qe: move qe_ic_cascade_* functions to qe_ic.c soc: fsl: qe: rename qe_ic_cascade_low_mpic -> qe_ic_cascade_low soc: fsl: qe: remove unused qe_ic_set_* functions soc: fsl: qe: don't use NO_IRQ in qe_ic.c soc: fsl: qe: make qe_ic_get_{low,high}_irq static soc: fsl: qe: simplify qe_ic_init() soc: fsl: qe: merge qe_ic.h headers into qe_ic.c soc: fsl: qe: qe.c: use of_property_read_* helpers soc: fsl: qe: qe_io.c: don't open-code of_parse_phandle() soc: fsl: qe: qe_io.c: access device tree property using be32_to_cpu soc: fsl: qe: qe_io.c: use of_property_read_u32() in par_io_init() soc: fsl: move cpm.h from powerpc/include/asm to include/soc/fsl soc/fsl/qe/qe.h: update include path for cpm.h serial: ucc_uart: explicitly include soc/fsl/cpm.h serial: ucc_uart: replace ppc-specific IO accessors serial: ucc_uart: factor out soft_uart initialization serial: ucc_uart: stub out soft_uart_init for !CONFIG_PPC32 serial: ucc_uart: use of_property_read_u32() in ucc_uart_probe() serial: ucc_uart: access __be32 field using be32_to_cpu net: ethernet: freescale: make UCC_GETH explicitly depend on PPC32 net/wan: make FSL_UCC_HDLC explicitly depend on PPC32 soc: fsl: qe: remove PPC32 dependency from CONFIG_QUICC_ENGINE arch/powerpc/include/asm/cpm.h | 172 +------- arch/powerpc/platforms/83xx/km83xx.c | 3 +- arch/powerpc/platforms/83xx/misc.c | 23 -- arch/powerpc/platforms/83xx/mpc832x_mds.c | 3 +- arch/powerpc/platforms/83xx/mpc832x_rdb.c | 3 +- arch/powerpc/platforms/83xx/mpc836x_mds.c | 3 +- arch/powerpc/platforms/83xx/mpc836x_rdk.c | 3 +- arch/powerpc/platforms/83xx/mpc83xx.h | 7 - arch/powerpc/platforms/85xx/common.c | 23 -- arch/powerpc/platforms/85xx/corenet_generic.c | 12 - arch/powerpc/platforms/85xx/mpc85xx.h | 2 - arch/powerpc/platforms/85xx/mpc85xx_mds.c | 28 -- arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 18 - arch/powerpc/platforms/85xx/twr_p102x.c | 16 - drivers/net/ethernet/freescale/Kconfig | 2 +- drivers/net/wan/Kconfig | 2 +- drivers/net/wan/fsl_ucc_hdlc.c | 4 +- drivers/soc/fsl/qe/Kconfig | 2 +- drivers/soc/fsl/qe/gpio.c | 34 +- drivers/soc/fsl/qe/qe.c | 95 ++--- drivers/soc/fsl/qe/qe_ic.c | 285 ++++++------- drivers/soc/fsl/qe/qe_ic.h | 99 ----- drivers/soc/fsl/qe/qe_io.c | 70 ++-- drivers/soc/fsl/qe/qe_tdm.c | 8 +- drivers/soc/fsl/qe/ucc.c | 26 +- drivers/soc/fsl/qe/ucc_fast.c | 71 ++-- drivers/soc/fsl/qe/ucc_slow.c | 38 +- drivers/soc/fsl/qe/usb.c | 2 +- drivers/tty/serial/ucc_uart.c | 383 +++++++++--------- include/soc/fsl/cpm.h | 171 ++++++++ include/soc/fsl/qe/qe.h | 42 +- include/soc/fsl/qe/qe_ic.h | 135 ------ 32 files changed, 701 insertions(+), 1084 deletions(-) delete mode 100644 drivers/soc/fsl/qe/qe_ic.h create mode 100644 include/soc/fsl/cpm.h delete mode 100644 include/soc/fsl/qe/qe_ic.h