| Message ID | 1506109046-11527-1-git-send-email-leoyang.li@nxp.com |
|---|---|
| State | New |
| Headers | show |
| Series | [GIT,PULL] updates to soc/fsl drivers for v4.14 | expand |
Hi Leo, Should we include the Reviewed-by tags in the pull request commits logs? Madalin > -----Original Message----- > From: Li Yang [mailto:leoyang.li@nxp.com] > Sent: Friday, September 22, 2017 10:37 PM > To: arm@kernel.org > Cc: linux-arm-kernel@lists.infradead.org; Catalin Marinas > <catalin.marinas@arm.com>; Roy Pledge <roy.pledge@nxp.com>; Arnd Bergmann > <arnd@arndb.de>; Madalin-cristian Bucur <madalin.bucur@nxp.com> > Subject: [GIT PULL] updates to soc/fsl drivers for v4.14 > > Hi arm-soc maintainers, > > This pull request includes updates to the QMAN/BMAN drivers to make > them work on the arm/arm64 architectures in addition to the power > architecture and a few minor update/bug-fix to the soc/fsl drivers. > > We got the Reviewed-by from Catalin on the ARM architecture side. > > DPAA (Data Path Acceleration Architecture) is a set of hardware > components used on some FSL/NXP QorIQ Networking SoCs, it provides the > infrastructure to support simplified sharing of networking interfaces > and accelerators by multiple CPU cores, and the accelerators > themselves. The QMan(Queue Manager) and BMan(Buffer Manager) are > infrastructural components within the DPAA framework. They are used to > manage queues and buffers for various I/O interfaces, hardware > accelerators. > > More information can be found via link: > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nxp. > com%2Fproducts%2Fmicrocontrollers-and-processors%2Fpower-architecture- > processors%2Fqoriq-platforms%2Fdata-path- > acceleration%3AQORIQ_DPAA&data=01%7C01%7Cmadalin.bucur%40nxp.com%7Ca384d00 > a91714cf5710808d501f161da%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=e2a > XiPCt%2FwQbTr6JafKqGzTjSdDv4qNUizPVDKPcRQw%3D&reserved=0 > > Regards, > Leo > > > The following changes since commit > 0a8abd97dcda50e5d2c893a51733416534e95706: > > Merge tag 'for-linus-4.14b-rc2-tag' of > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip (2017-09-22 06:40:47 > -1000) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git tags/soc- > fsl-for-4.14 > > for you to fetch changes up to e868adf21c0a25634d5dfa5b1e6dbf839306d8fa: > > soc/fsl/qbman: Enable FSL_LAYERSCAPE config on ARM (2017-09-22 13:33:07 > -0500) > > ---------------------------------------------------------------- > FSL/NXP ARM SoC drivers updates for 4.14 > > This adds the DPAA QBMan support for ARM SoCs and a few minor > fixes/updates. > > ---------------------------------------------------------------- > Claudiu Manoil (2): > soc/fsl/qbman: Drop L1_CACHE_BYTES compile time check > soc/fsl/qbman: Add missing headers on ARM > > Karim Eshapa (1): > soc/fsl/qman: Sleep instead of stuck hacking jiffies > > Madalin Bucur (4): > soc/fsl/qbman: Drop set/clear_bits usage > soc/fsl/qbman: add QMAN_REV32 > soc/fsl/qbman: different register offsets on ARM > soc/fsl/qbman: Enable FSL_LAYERSCAPE config on ARM > > Roy Pledge (5): > soc/fsl/qbman: Add common routine for QBMan private allocations > soc/fsl/qbman: Use shared-dma-pool for BMan private memory > allocations > soc/fsl/qbman: Use shared-dma-pool for QMan private memory > allocations > dt-bindings: soc/fsl: Update reserved memory binding for QBMan > soc/fsl/qbman: Rework portal mapping calls for ARM/PPC > > Valentin Rothberg (1): > soc/fsl/qbman: Fix ARM32 typo > > ashish kumar (1): > soc/fsl/guts: Add compatible string for LS1088 > > Documentation/devicetree/bindings/soc/fsl/bman.txt | 12 +-- > Documentation/devicetree/bindings/soc/fsl/qman.txt | 26 ++++-- > drivers/soc/fsl/guts.c | 1 + > drivers/soc/fsl/qbman/Kconfig | 2 +- > drivers/soc/fsl/qbman/Makefile | 2 +- > drivers/soc/fsl/qbman/bman.c | 42 ++++++++-- > drivers/soc/fsl/qbman/bman_ccsr.c | 15 ++++ > drivers/soc/fsl/qbman/bman_portal.c | 23 +++--- > drivers/soc/fsl/qbman/bman_priv.h | 8 +- > drivers/soc/fsl/qbman/dpaa_sys.c | 78 > ++++++++++++++++++ > drivers/soc/fsl/qbman/dpaa_sys.h | 25 ++++-- > drivers/soc/fsl/qbman/qman.c | 83 +++++++++++++---- > -- > drivers/soc/fsl/qbman/qman_ccsr.c | 95 +++++++++++++++-- > ----- > drivers/soc/fsl/qbman/qman_portal.c | 23 +++--- > drivers/soc/fsl/qbman/qman_priv.h | 11 +-- > drivers/soc/fsl/qbman/qman_test.h | 2 - > 16 files changed, 320 insertions(+), 128 deletions(-) > create mode 100644 drivers/soc/fsl/qbman/dpaa_sys.c
> -----Original Message----- > From: Madalin-cristian Bucur > Sent: Tuesday, October 03, 2017 4:55 AM > To: Leo Li <leoyang.li@nxp.com> > Cc: arm@kernel.org; linux-arm-kernel@lists.infradead.org; Catalin Marinas > <catalin.marinas@arm.com>; Roy Pledge <roy.pledge@nxp.com>; Arnd > Bergmann <arnd@arndb.de> > Subject: RE: [GIT PULL] updates to soc/fsl drivers for v4.14 > > Hi Leo, > > Should we include the Reviewed-by tags in the pull request commits logs? I have already included Catalin's Reviewed-by in the git log for patches he replied with a Reviewed-by. There are a few patches that are not related to ARM architecture don't have his reviewed-by, which I think is fine. Leo > > Madalin > > > -----Original Message----- > > From: Li Yang [mailto:leoyang.li@nxp.com] > > Sent: Friday, September 22, 2017 10:37 PM > > To: arm@kernel.org > > Cc: linux-arm-kernel@lists.infradead.org; Catalin Marinas > > <catalin.marinas@arm.com>; Roy Pledge <roy.pledge@nxp.com>; Arnd > > Bergmann <arnd@arndb.de>; Madalin-cristian Bucur > > <madalin.bucur@nxp.com> > > Subject: [GIT PULL] updates to soc/fsl drivers for v4.14 > > > > Hi arm-soc maintainers, > > > > This pull request includes updates to the QMAN/BMAN drivers to make > > them work on the arm/arm64 architectures in addition to the power > > architecture and a few minor update/bug-fix to the soc/fsl drivers. > > > > We got the Reviewed-by from Catalin on the ARM architecture side. > > > > DPAA (Data Path Acceleration Architecture) is a set of hardware > > components used on some FSL/NXP QorIQ Networking SoCs, it provides the > > infrastructure to support simplified sharing of networking interfaces > > and accelerators by multiple CPU cores, and the accelerators > > themselves. The QMan(Queue Manager) and BMan(Buffer Manager) are > > infrastructural components within the DPAA framework. They are used > > to manage queues and buffers for various I/O interfaces, hardware > > accelerators. > > > > More information can be found via link: > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.n > xp. > > com%2Fproducts%2Fmicrocontrollers-and-processors%2Fpower-architecture- > > processors%2Fqoriq-platforms%2Fdata-path- > > > acceleration%3AQORIQ_DPAA&data=01%7C01%7Cmadalin.bucur%40nxp.com% > 7Ca38 > > 4d00 > > > a91714cf5710808d501f161da%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0& > sdata > > =e2a > > XiPCt%2FwQbTr6JafKqGzTjSdDv4qNUizPVDKPcRQw%3D&reserved=0 > > > > Regards, > > Leo > > > > > > The following changes since commit > > 0a8abd97dcda50e5d2c893a51733416534e95706: > > > > Merge tag 'for-linus-4.14b-rc2-tag' of > > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip (2017-09-22 > > 06:40:47 > > -1000) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git > > tags/soc- > > fsl-for-4.14 > > > > for you to fetch changes up to e868adf21c0a25634d5dfa5b1e6dbf839306d8fa: > > > > soc/fsl/qbman: Enable FSL_LAYERSCAPE config on ARM (2017-09-22 > > 13:33:07 > > -0500) > > > > ---------------------------------------------------------------- > > FSL/NXP ARM SoC drivers updates for 4.14 > > > > This adds the DPAA QBMan support for ARM SoCs and a few minor > > fixes/updates. > > > > ---------------------------------------------------------------- > > Claudiu Manoil (2): > > soc/fsl/qbman: Drop L1_CACHE_BYTES compile time check > > soc/fsl/qbman: Add missing headers on ARM > > > > Karim Eshapa (1): > > soc/fsl/qman: Sleep instead of stuck hacking jiffies > > > > Madalin Bucur (4): > > soc/fsl/qbman: Drop set/clear_bits usage > > soc/fsl/qbman: add QMAN_REV32 > > soc/fsl/qbman: different register offsets on ARM > > soc/fsl/qbman: Enable FSL_LAYERSCAPE config on ARM > > > > Roy Pledge (5): > > soc/fsl/qbman: Add common routine for QBMan private allocations > > soc/fsl/qbman: Use shared-dma-pool for BMan private memory > > allocations > > soc/fsl/qbman: Use shared-dma-pool for QMan private memory > > allocations > > dt-bindings: soc/fsl: Update reserved memory binding for QBMan > > soc/fsl/qbman: Rework portal mapping calls for ARM/PPC > > > > Valentin Rothberg (1): > > soc/fsl/qbman: Fix ARM32 typo > > > > ashish kumar (1): > > soc/fsl/guts: Add compatible string for LS1088 > > > > Documentation/devicetree/bindings/soc/fsl/bman.txt | 12 +-- > > Documentation/devicetree/bindings/soc/fsl/qman.txt | 26 ++++-- > > drivers/soc/fsl/guts.c | 1 + > > drivers/soc/fsl/qbman/Kconfig | 2 +- > > drivers/soc/fsl/qbman/Makefile | 2 +- > > drivers/soc/fsl/qbman/bman.c | 42 ++++++++-- > > drivers/soc/fsl/qbman/bman_ccsr.c | 15 ++++ > > drivers/soc/fsl/qbman/bman_portal.c | 23 +++--- > > drivers/soc/fsl/qbman/bman_priv.h | 8 +- > > drivers/soc/fsl/qbman/dpaa_sys.c | 78 > > ++++++++++++++++++ > > drivers/soc/fsl/qbman/dpaa_sys.h | 25 ++++-- > > drivers/soc/fsl/qbman/qman.c | 83 +++++++++++++---- > > -- > > drivers/soc/fsl/qbman/qman_ccsr.c | 95 +++++++++++++++-- > > ----- > > drivers/soc/fsl/qbman/qman_portal.c | 23 +++--- > > drivers/soc/fsl/qbman/qman_priv.h | 11 +-- > > drivers/soc/fsl/qbman/qman_test.h | 2 - > > 16 files changed, 320 insertions(+), 128 deletions(-) create mode > > 100644 drivers/soc/fsl/qbman/dpaa_sys.c
On Fri, Sep 22, 2017 at 9:37 PM, Li Yang <leoyang.li@nxp.com> wrote: > Hi arm-soc maintainers, > > This pull request includes updates to the QMAN/BMAN drivers to make > them work on the arm/arm64 architectures in addition to the power > architecture and a few minor update/bug-fix to the soc/fsl drivers. > > We got the Reviewed-by from Catalin on the ARM architecture side. > > DPAA (Data Path Acceleration Architecture) is a set of hardware > components used on some FSL/NXP QorIQ Networking SoCs, it provides the > infrastructure to support simplified sharing of networking interfaces > and accelerators by multiple CPU cores, and the accelerators > themselves. The QMan(Queue Manager) and BMan(Buffer Manager) are > infrastructural components within the DPAA framework. They are used to > manage queues and buffers for various I/O interfaces, hardware > accelerators. > > More information can be found via link: > http://www.nxp.com/products/microcontrollers-and-processors/power-architecture-processors/qoriq-platforms/data-path-acceleration:QORIQ_DPAA Hi Leo, Sorry for the long delay in processing this. I've pulled the branch into our next/drivers branch now, after taking another look at the contents. The code looks fine to me in this version, but I have a couple of comments about the submission: - We should come to an agreement on how we do these in the future. Usually I expect any Freescale/NXP/ARM changes to come through the i.MX maintainers (Shawn and Sascha), not directly from other developers. There is usually some degree of coordination required between the SoC drivers and the DT files and platform code, so it's really best to have someone be aware of all the components, and I prefer to have a smaller number of people sending me pull requests. If you already talked to Shawn about it and he prefers you to send the pull request to us directly, that's fine too, but please at least keep him on Cc. - You have a very nice detailed description of the contents above, but the signed tag only has a single line saying 'This adds the DPAA QBMan support for ARM SoCs and a few minor fixes/updates'. I decided to just take your long description as the merge commit since it explains the contents better. It would be good to have a long description like that in the tag next time to keep it in the git history. Arnd
> -----Original Message----- > From: arndbergmann@gmail.com [mailto:arndbergmann@gmail.com] On > Behalf Of Arnd Bergmann > Sent: Friday, October 20, 2017 4:02 PM > To: Leo Li <leoyang.li@nxp.com> > Cc: arm-soc <arm@kernel.org>; Linux ARM <linux-arm- > kernel@lists.infradead.org>; Catalin Marinas <catalin.marinas@arm.com>; Roy > Pledge <roy.pledge@nxp.com>; Madalin-cristian Bucur > <madalin.bucur@nxp.com>; Shawn Guo <shawnguo@kernel.org>; Sascha Hauer > <kernel@pengutronix.de>; Fabio Estevam <fabio.estevam@nxp.com> > Subject: Re: [GIT PULL] updates to soc/fsl drivers for v4.14 > > On Fri, Sep 22, 2017 at 9:37 PM, Li Yang <leoyang.li@nxp.com> wrote: > > Hi arm-soc maintainers, > > > > This pull request includes updates to the QMAN/BMAN drivers to make > > them work on the arm/arm64 architectures in addition to the power > > architecture and a few minor update/bug-fix to the soc/fsl drivers. > > > > We got the Reviewed-by from Catalin on the ARM architecture side. > > > > DPAA (Data Path Acceleration Architecture) is a set of hardware > > components used on some FSL/NXP QorIQ Networking SoCs, it provides the > > infrastructure to support simplified sharing of networking interfaces > > and accelerators by multiple CPU cores, and the accelerators > > themselves. The QMan(Queue Manager) and BMan(Buffer Manager) are > > infrastructural components within the DPAA framework. They are used > > to manage queues and buffers for various I/O interfaces, hardware > > accelerators. > > > > More information can be found via link: > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. > > nxp.com%2Fproducts%2Fmicrocontrollers-and-processors%2Fpower-architect > > ure-processors%2Fqoriq-platforms%2Fdata-path- > acceleration%3AQORIQ_DPAA > > > &data=01%7C01%7Cleoyang.li%40nxp.com%7Cf061078c92744067077808d517f > dcb6 > > > 2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=ffs5czr8VeyjFb6PFnIAc > iZ > > W0S4GWvk7G9YeB0oJ404%3D&reserved=0 > > Hi Leo, > > Sorry for the long delay in processing this. I've pulled the branch into our > next/drivers branch now, after taking another look at the contents. > The code looks fine to me in this version, but I have a couple of comments > about the submission: Hi Arnd, Thanks for the effort for reviewing the patches and merge them. > > - We should come to an agreement on how we do these in the future. > Usually I expect any Freescale/NXP/ARM changes to come through the > i.MX maintainers (Shawn and Sascha), not directly from other developers. > There is usually some degree of coordination required between the > SoC drivers and the DT files and platform code, so it's really best to > have someone be aware of all the components, and I prefer to have > a smaller number of people sending me pull requests. If you already > talked to Shawn about it and he prefers you to send the pull request > to us directly, that's fine too, but please at least keep him on Cc. I would like to share some more background information on this. The microcontroller business(produces i.mx product line) and the networking business(produces qoriq product line) are completely two different business units within Freescale/NXP. There are separate hardware design teams and software development teams due to the different targeting markets. The hardware design are almost completely different. Historically, the microcontroller product line focused on m68k and armv7 architectures while the networking product line focused on PowerPC architecture and recently moved to ARMv8 architecture. There are surely some IP sharing but only on basic peripheral devices such as i2c, usb and etc. But due to the different targeting markets most of the peripheral devices are very different. For example this DPAA framework, network interfaces and a lot of other accelerators will never be used in the i.mx products. On the core architecture side we are working on SBSA compliance hardware and SBBA compliance software with UEFI and ACPI in the picture, which would be a overkill for microcontrollers. In my opinion, the differences between i.MX and QorIQ products could be even bigger than the difference between QorIQ products and some server focused ARMv8 SoCs from other vendors. The synergy for combining these two will be very limited. > > - You have a very nice detailed description of the contents above, > but the signed tag only has a single line saying 'This adds the > DPAA QBMan support for ARM SoCs and a few minor fixes/updates'. > I decided to just take your long description as the merge commit > since it explains the contents better. It would be good to have > a long description like that in the tag next time to keep it in the > git history. Thanks for extra effort. I will keep the long description also in the pull request next time. Regards, Leo
Hi Leo, On Fri, Oct 20, 2017 at 10:04:07PM +0000, Leo Li wrote: > > - We should come to an agreement on how we do these in the future. > > Usually I expect any Freescale/NXP/ARM changes to come through the > > i.MX maintainers (Shawn and Sascha), not directly from other developers. > > There is usually some degree of coordination required between the > > SoC drivers and the DT files and platform code, so it's really best to > > have someone be aware of all the components, and I prefer to have > > a smaller number of people sending me pull requests. If you already > > talked to Shawn about it and he prefers you to send the pull request > > to us directly, that's fine too, but please at least keep him on Cc. > > I would like to share some more background information on this. The microcontroller business(produces i.mx product line) and the networking business(produces qoriq product line) are completely two different business units within Freescale/NXP. There are separate hardware design teams and software development teams due to the different targeting markets. The hardware design are almost completely different. Historically, the microcontroller product line focused on m68k and armv7 architectures while the networking product line focused on PowerPC architecture and recently moved to ARMv8 architecture. There are surely some IP sharing but only on basic peripheral devices such as i2c, usb and etc. But due to the different targeting markets most of the peripheral devices are very different. For example this DPAA framework, network interfaces and a lot of other accelerators will never be used in the i.mx products. On the core architecture side we are working on SBSA compliance hardware and SBBA compliance software with UEFI and ACPI in the picture, which would be a overkill for microcontrollers. In my opinion, the differences between i.MX and QorIQ products could be even bigger than the difference between QorIQ products and some server focused ARMv8 SoCs from other vendors. The synergy for combining these two will be very limited. > I'm fine with you send drivers/soc/fsl changes to Arnd directly, since we already have separate folders (drivers/soc/imx vs. drivers/soc/fsl) for i.MX and QorIQ. But as Arnd suggested, please keep me on copy, so that I can be aware of the changes which might be somehow related to arch/arm64/boot/dts/freescale/ changes that I'm currently taking care of. Thanks. Shawn
> -----Original Message----- > From: Shawn Guo [mailto:shawnguo@kernel.org] > Sent: Sunday, October 22, 2017 8:11 PM > To: Leo Li <leoyang.li@nxp.com> > Cc: Arnd Bergmann <arnd@arndb.de>; Madalin-cristian Bucur > <madalin.bucur@nxp.com>; Catalin Marinas <catalin.marinas@arm.com>; Roy > Pledge <roy.pledge@nxp.com>; arm-soc <arm@kernel.org>; Sascha Hauer > <kernel@pengutronix.de>; Fabio Estevam <fabio.estevam@nxp.com>; Linux > ARM <linux-arm-kernel@lists.infradead.org> > Subject: Re: [GIT PULL] updates to soc/fsl drivers for v4.14 > > Hi Leo, > > On Fri, Oct 20, 2017 at 10:04:07PM +0000, Leo Li wrote: > > > - We should come to an agreement on how we do these in the future. > > > Usually I expect any Freescale/NXP/ARM changes to come through the > > > i.MX maintainers (Shawn and Sascha), not directly from other developers. > > > There is usually some degree of coordination required between the > > > SoC drivers and the DT files and platform code, so it's really best to > > > have someone be aware of all the components, and I prefer to have > > > a smaller number of people sending me pull requests. If you already > > > talked to Shawn about it and he prefers you to send the pull request > > > to us directly, that's fine too, but please at least keep him on Cc. > > > > I would like to share some more background information on this. The > microcontroller business(produces i.mx product line) and the networking > business(produces qoriq product line) are completely two different business > units within Freescale/NXP. There are separate hardware design teams and > software development teams due to the different targeting markets. The > hardware design are almost completely different. Historically, the > microcontroller product line focused on m68k and armv7 architectures while the > networking product line focused on PowerPC architecture and recently moved > to ARMv8 architecture. There are surely some IP sharing but only on basic > peripheral devices such as i2c, usb and etc. But due to the different targeting > markets most of the peripheral devices are very different. For example this > DPAA framework, network interfaces and a lot of other accelerators will never > be used in the i.mx products. On the core architecture side we are working on > SBSA compliance hardware and SBBA compliance software with UEFI and ACPI > in the picture, which would be a overkill for microcontrollers. In my opinion, > the differences between i.MX and QorIQ products could be even bigger than the > difference between QorIQ products and some server focused ARMv8 SoCs from > other vendors. The synergy for combining these two will be very limited. > > > > I'm fine with you send drivers/soc/fsl changes to Arnd directly, since we already > have separate folders (drivers/soc/imx vs. drivers/soc/fsl) for i.MX and QorIQ. > But as Arnd suggested, please keep me on copy, so that I can be aware of the > changes which might be somehow related to arch/arm64/boot/dts/freescale/ > changes that I'm currently taking care of. Thanks. Hi Shawn, Sure. I will keep you copied. Thanks for the understanding. Regards, Leo
On Mon, Oct 23, 2017 at 1:11 AM, Shawn Guo <shawnguo@kernel.org> wrote: > Hi Leo, > > On Fri, Oct 20, 2017 at 10:04:07PM +0000, Leo Li wrote: >> > - We should come to an agreement on how we do these in the future. >> > Usually I expect any Freescale/NXP/ARM changes to come through the >> > i.MX maintainers (Shawn and Sascha), not directly from other developers. >> > There is usually some degree of coordination required between the >> > SoC drivers and the DT files and platform code, so it's really best to >> > have someone be aware of all the components, and I prefer to have >> > a smaller number of people sending me pull requests. If you already >> > talked to Shawn about it and he prefers you to send the pull request >> > to us directly, that's fine too, but please at least keep him on Cc. >> >> I would like to share some more background information on this. The microcontroller business(produces i.mx product line) and the networking business(produces qoriq product line) are completely two different business units within Freescale/NXP. There are separate hardware design teams and software development teams due to the different targeting markets. The hardware design are almost completely different. Historically, the microcontroller product line focused on m68k and armv7 architectures while the networking product line focused on PowerPC architecture and recently moved to ARMv8 architecture. There are surely some IP sharing but only on basic peripheral devices such as i2c, usb and etc. But due to the different targeting markets most of the peripheral devices are very different. For example this DPAA framework, network interfaces and a lot of other accelerators will never be used in the i.mx products. On the core architecture side we are working on SBSA compliance hardware and SBBA compliance software with UEFI and ACPI in the picture, which would be a overkill for microcontrollers. In my opinion, the differences between i.MX and QorIQ products could be even bigger than the difference between QorIQ products and some server focused ARMv8 SoCs from other vendors. The synergy for combining these two will be very limited. I'm obviously aware of your product lines and the differences, it was just a bit surprising to get the pull request from you after we had earlier agreed that Shawn would help you handle the pull requests for all NXP products, as he did with the changes to arch/arm/ (LS1021A) and arch/arm64 for various Layerscape products we support (LS1012a, LS1043a, LS1088a, and LS2XXXa so far). Again, this is mostly about clear communication about what I should expect and when things change, as long as everybody is ok with the way we do it. > I'm fine with you send drivers/soc/fsl changes to Arnd directly, since > we already have separate folders (drivers/soc/imx vs. drivers/soc/fsl) > for i.MX and QorIQ. But as Arnd suggested, please keep me on copy, so > that I can be aware of the changes which might be somehow related to > arch/arm64/boot/dts/freescale/ changes that I'm currently taking care > of. Thanks. Sounds good to me, thanks. Arnd
> -----Original Message----- > From: arndbergmann@gmail.com [mailto:arndbergmann@gmail.com] On > Behalf Of Arnd Bergmann > Sent: Friday, October 27, 2017 2:48 AM > To: Shawn Guo <shawnguo@kernel.org> > Cc: Leo Li <leoyang.li@nxp.com>; Madalin-cristian Bucur > <madalin.bucur@nxp.com>; Catalin Marinas <catalin.marinas@arm.com>; Roy > Pledge <roy.pledge@nxp.com>; arm-soc <arm@kernel.org>; Sascha Hauer > <kernel@pengutronix.de>; Fabio Estevam <fabio.estevam@nxp.com>; Linux > ARM <linux-arm-kernel@lists.infradead.org> > Subject: Re: [GIT PULL] updates to soc/fsl drivers for v4.14 > > On Mon, Oct 23, 2017 at 1:11 AM, Shawn Guo <shawnguo@kernel.org> wrote: > > Hi Leo, > > > > On Fri, Oct 20, 2017 at 10:04:07PM +0000, Leo Li wrote: > >> > - We should come to an agreement on how we do these in the future. > >> > Usually I expect any Freescale/NXP/ARM changes to come through the > >> > i.MX maintainers (Shawn and Sascha), not directly from other developers. > >> > There is usually some degree of coordination required between the > >> > SoC drivers and the DT files and platform code, so it's really best to > >> > have someone be aware of all the components, and I prefer to have > >> > a smaller number of people sending me pull requests. If you already > >> > talked to Shawn about it and he prefers you to send the pull request > >> > to us directly, that's fine too, but please at least keep him on Cc. > >> > >> I would like to share some more background information on this. The > microcontroller business(produces i.mx product line) and the networking > business(produces qoriq product line) are completely two different business > units within Freescale/NXP. There are separate hardware design teams and > software development teams due to the different targeting markets. The > hardware design are almost completely different. Historically, the > microcontroller product line focused on m68k and armv7 architectures while the > networking product line focused on PowerPC architecture and recently moved > to ARMv8 architecture. There are surely some IP sharing but only on basic > peripheral devices such as i2c, usb and etc. But due to the different targeting > markets most of the peripheral devices are very different. For example this > DPAA framework, network interfaces and a lot of other accelerators will never > be used in the i.mx products. On the core architecture side we are working on > SBSA compliance hardware and SBBA compliance software with UEFI and ACPI > in the picture, which would be a overkill for microcontrollers. In my opinion, > the differences between i.MX and QorIQ products could be even bigger than the > difference between QorIQ products and some server focused ARMv8 SoCs from > other vendors. The synergy for combining these two will be very limited. > > I'm obviously aware of your product lines and the differences, it was just a bit > surprising to get the pull request from you after we had earlier agreed that > Shawn would help you handle the pull requests for all NXP products, as he did > with the changes to arch/arm/ (LS1021A) and arch/arm64 for various > Layerscape products we support (LS1012a, LS1043a, LS1088a, and LS2XXXa so > far). My understanding of the previous agreement was that it only covers device tree patches which doesn't need too much detail knowledge of the device itself as long as it follows the existing bindings; while the drivers for on-chip devices are still handled by us (previously Scott Wood) as it requires a lot more knowledge about the device internal. > > Again, this is mostly about clear communication about what I should expect and > when things change, as long as everybody is ok with the way we do it. This does help to make it clear, thanks. - Leo
On Fri, Oct 27, 2017 at 7:33 PM, Leo Li <leoyang.li@nxp.com> wrote: >> I'm obviously aware of your product lines and the differences, it was just a bit >> surprising to get the pull request from you after we had earlier agreed that >> Shawn would help you handle the pull requests for all NXP products, as he did >> with the changes to arch/arm/ (LS1021A) and arch/arm64 for various >> Layerscape products we support (LS1012a, LS1043a, LS1088a, and LS2XXXa so >> far). > > My understanding of the previous agreement was that it only covers device tree > patches which doesn't need too much detail knowledge of the device itself as long > as it follows the existing bindings; while the drivers for on-chip devices are still > handled by us (previously Scott Wood) as it requires a lot more knowledge about > the device internal. We probably just didn't make it clear enough and were making different assumptions. With the other platforms in arm-soc, I always get all changes concerning one platform from a single person, who will then make sure things get merged in the correct order. OTOH, having two separate downstream maintainers does have an advantage that it makes it harder to run into incompatible DT binding changes, as each tree will get more testing by itself. Arnd
Hi arm-soc maintainers, This pull request includes updates to the QMAN/BMAN drivers to make them work on the arm/arm64 architectures in addition to the power architecture and a few minor update/bug-fix to the soc/fsl drivers. We got the Reviewed-by from Catalin on the ARM architecture side. DPAA (Data Path Acceleration Architecture) is a set of hardware components used on some FSL/NXP QorIQ Networking SoCs, it provides the infrastructure to support simplified sharing of networking interfaces and accelerators by multiple CPU cores, and the accelerators themselves. The QMan(Queue Manager) and BMan(Buffer Manager) are infrastructural components within the DPAA framework. They are used to manage queues and buffers for various I/O interfaces, hardware accelerators. More information can be found via link: http://www.nxp.com/products/microcontrollers-and-processors/power-architecture-processors/qoriq-platforms/data-path-acceleration:QORIQ_DPAA Regards, Leo The following changes since commit 0a8abd97dcda50e5d2c893a51733416534e95706: Merge tag 'for-linus-4.14b-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip (2017-09-22 06:40:47 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git tags/soc-fsl-for-4.14 for you to fetch changes up to e868adf21c0a25634d5dfa5b1e6dbf839306d8fa: soc/fsl/qbman: Enable FSL_LAYERSCAPE config on ARM (2017-09-22 13:33:07 -0500) ---------------------------------------------------------------- FSL/NXP ARM SoC drivers updates for 4.14 This adds the DPAA QBMan support for ARM SoCs and a few minor fixes/updates. ---------------------------------------------------------------- Claudiu Manoil (2): soc/fsl/qbman: Drop L1_CACHE_BYTES compile time check soc/fsl/qbman: Add missing headers on ARM Karim Eshapa (1): soc/fsl/qman: Sleep instead of stuck hacking jiffies Madalin Bucur (4): soc/fsl/qbman: Drop set/clear_bits usage soc/fsl/qbman: add QMAN_REV32 soc/fsl/qbman: different register offsets on ARM soc/fsl/qbman: Enable FSL_LAYERSCAPE config on ARM Roy Pledge (5): soc/fsl/qbman: Add common routine for QBMan private allocations soc/fsl/qbman: Use shared-dma-pool for BMan private memory allocations soc/fsl/qbman: Use shared-dma-pool for QMan private memory allocations dt-bindings: soc/fsl: Update reserved memory binding for QBMan soc/fsl/qbman: Rework portal mapping calls for ARM/PPC Valentin Rothberg (1): soc/fsl/qbman: Fix ARM32 typo ashish kumar (1): soc/fsl/guts: Add compatible string for LS1088 Documentation/devicetree/bindings/soc/fsl/bman.txt | 12 +-- Documentation/devicetree/bindings/soc/fsl/qman.txt | 26 ++++-- drivers/soc/fsl/guts.c | 1 + drivers/soc/fsl/qbman/Kconfig | 2 +- drivers/soc/fsl/qbman/Makefile | 2 +- drivers/soc/fsl/qbman/bman.c | 42 ++++++++-- drivers/soc/fsl/qbman/bman_ccsr.c | 15 ++++ drivers/soc/fsl/qbman/bman_portal.c | 23 +++--- drivers/soc/fsl/qbman/bman_priv.h | 8 +- drivers/soc/fsl/qbman/dpaa_sys.c | 78 ++++++++++++++++++ drivers/soc/fsl/qbman/dpaa_sys.h | 25 ++++-- drivers/soc/fsl/qbman/qman.c | 83 +++++++++++++------ drivers/soc/fsl/qbman/qman_ccsr.c | 95 +++++++++++++++------- drivers/soc/fsl/qbman/qman_portal.c | 23 +++--- drivers/soc/fsl/qbman/qman_priv.h | 11 +-- drivers/soc/fsl/qbman/qman_test.h | 2 - 16 files changed, 320 insertions(+), 128 deletions(-) create mode 100644 drivers/soc/fsl/qbman/dpaa_sys.c