| Message ID | 1579601912-27737-1-git-send-email-alex.nemirovsky@cortina-access.com |
|---|---|
| Headers | show |
| Series | Add Cortina Access basic DM drivers | expand |
On Tue, Jan 21, 2020 at 10:19:01AM +0000, Alex Nemirovsky wrote: > > Cortina Access management has decided that we want to add formal > upstream support of u-boot going forward for our line of SoCs > and evaluation boards. [snip] > MAINTAINERS | 18 +++ > arch/arm/Kconfig | 5 + > arch/arm/dts/Makefile | 2 + > arch/arm/dts/ca-presidio-engboard.dts | 69 +++++++++++ > arch/arm/include/asm/gpio.h | 2 +- > board/cortina/common/Kconfig | 5 + > board/cortina/common/armv8/ca7774_regs.h | 18 +++ > board/cortina/common/armv8/lowlevel_init.S | 87 ++++++++++++++ > board/cortina/presidio-asic/Kconfig | 20 ++++ > board/cortina/presidio-asic/MAINTAINERS | 6 + > board/cortina/presidio-asic/Makefile | 8 ++ > board/cortina/presidio-asic/presidio.c | 126 ++++++++++++++++++++ I should have spotted this sooner, sorry. Why are you doing board/cortina/common/armv8/ rather than arch/arm/mach-xxx/ (and related include directory) as is the norm?
We have many common features across ISAs and common ARM, MIPS, other ISA modification across SoCs. Looking at how this was addressed by other silicon vendors who support multiple ISAs, lead to this path. i.e. TI, freescale, and others. ./board/BuR/common ./board/xilinx/common ./board/atmel/common ./board/ti/common ./board/seco/common ./board/gdsys/common ./board/avionic-design/common ./board/LaCie/common ./board/cortina/common ./board/xes/common ./board/varisys/common ./board/engicam/common ./board/siemens/common ./board/mscc/common ./board/toradex/common ./board/compulab/common ./board/alliedtelesis/common ./board/freescale/common ./board/keymile/common ./board/samsung/common ./board/google/common ./board/ge/common On Jan 24, 2020, at 7:13 AM, Tom Rini <trini at konsulko.com<mailto:trini at konsulko.com>> wrote: On Tue, Jan 21, 2020 at 10:19:01AM +0000, Alex Nemirovsky wrote: Cortina Access management has decided that we want to add formal upstream support of u-boot going forward for our line of SoCs and evaluation boards. [snip] MAINTAINERS | 18 +++ arch/arm/Kconfig | 5 + arch/arm/dts/Makefile | 2 + arch/arm/dts/ca-presidio-engboard.dts | 69 +++++++++++ arch/arm/include/asm/gpio.h | 2 +- board/cortina/common/Kconfig | 5 + board/cortina/common/armv8/ca7774_regs.h | 18 +++ board/cortina/common/armv8/lowlevel_init.S | 87 ++++++++++++++ board/cortina/presidio-asic/Kconfig | 20 ++++ board/cortina/presidio-asic/MAINTAINERS | 6 + board/cortina/presidio-asic/Makefile | 8 ++ board/cortina/presidio-asic/presidio.c | 126 ++++++++++++++++++++ I should have spotted this sooner, sorry. Why are you doing board/cortina/common/armv8/ rather than arch/arm/mach-xxx/ (and related include directory) as is the norm? -- Tom
On Fri, Jan 24, 2020 at 05:22:50PM +0000, Alex Nemirovsky wrote: > We have many common features across ISAs and common ARM, MIPS, other ISA modification across SoCs. Looking at how this was addressed > by other silicon vendors who support multiple ISAs, lead to this path. i.e. TI, freescale, and others. > > > ./board/BuR/common > ./board/xilinx/common > ./board/atmel/common > ./board/ti/common > ./board/seco/common > ./board/gdsys/common > ./board/avionic-design/common > ./board/LaCie/common > ./board/cortina/common > ./board/xes/common > ./board/varisys/common > ./board/engicam/common > ./board/siemens/common > ./board/mscc/common > ./board/toradex/common > ./board/compulab/common > ./board/alliedtelesis/common > ./board/freescale/common > ./board/keymile/common > ./board/samsung/common > ./board/google/common > ./board/ge/common Yes. And in I believe all of the above cases there is also a relevant arch/*/mach-* directory. This can be a hard distinction to make sometimes, especially at first, but board/VENDOR/common is for the parts that are common but outside of a specific SoC. What you're putting in there that is common between your MIPS and ARM platforms for example. To use board/ti/common as an example there are platforms under arch/arm/mach-omap2/{am33xx,omap5} and arch/arm/mach-k3/ that all share that code. To use one of your examples, lowlevel_init.S is something that is for the SoC and would be shared by some other vendor that uses your platform, right? It's leveraging features of the SoC itself rather than the PCB design of the board. Does that help? Thanks!
Looking inside
grep -h CA board/cortina/common/armv8/lowlevel_init.S
#if defined(CONFIG_SOC_CA7774)
#if defined(CONFIG_SOC_CA8277B)
as we understand it, the alternative would lead to maintaining duplicate but slightly different code for each ARM based SoC in
arch/arm/mach-ca7774
arch/arm/mach-ca8277B
arch/arm/mach-ca7742
arch/arm/mach-ca8279
arch/arm/mach-caXnnn
correct? or should we simply create a arch/arm/mach-caxxxx, arch/mips/mach-caxxxx, arch/xtensa/mach-axxxx, arch/riscv/mach-caxxxx, etc to maintain similar
changes to each arch related custom code which varies slightly for each SoC variation within each architecture?
What’s best to avoid maintaining duplicate code across SoC variations within the same ISA family?
On Jan 24, 2020, at 9:37 AM, Tom Rini <trini at konsulko.com<mailto:trini at konsulko.com>> wrote:
On Fri, Jan 24, 2020 at 05:22:50PM +0000, Alex Nemirovsky wrote:
We have many common features across ISAs and common ARM, MIPS, other ISA modification across SoCs. Looking at how this was addressed
by other silicon vendors who support multiple ISAs, lead to this path. i.e. TI, freescale, and others.
./board/BuR/common
./board/xilinx/common
./board/atmel/common
./board/ti/common
./board/seco/common
./board/gdsys/common
./board/avionic-design/common
./board/LaCie/common
./board/cortina/common
./board/xes/common
./board/varisys/common
./board/engicam/common
./board/siemens/common
./board/mscc/common
./board/toradex/common
./board/compulab/common
./board/alliedtelesis/common
./board/freescale/common
./board/keymile/common
./board/samsung/common
./board/google/common
./board/ge/common
Yes. And in I believe all of the above cases there is also a relevant
arch/*/mach-* directory. This can be a hard distinction to make
sometimes, especially at first, but board/VENDOR/common is for the parts
that are common but outside of a specific SoC. What you're putting in
there that is common between your MIPS and ARM platforms for example.
To use board/ti/common as an example there are platforms under
arch/arm/mach-omap2/{am33xx,omap5} and arch/arm/mach-k3/ that all share
that code.
To use one of your examples, lowlevel_init.S is something that is for
the SoC and would be shared by some other vendor that uses your
platform, right? It's leveraging features of the SoC itself rather than
the PCB design of the board.
Does that help? Thanks!
--
Tom
On Fri, Jan 24, 2020 at 05:55:29PM +0000, Alex Nemirovsky wrote: > Looking inside > grep -h CA board/cortina/common/armv8/lowlevel_init.S > #if defined(CONFIG_SOC_CA7774) > #if defined(CONFIG_SOC_CA8277B) > > as we understand it, the alternative would lead to maintaining duplicate but slightly different code for each ARM based SoC in > arch/arm/mach-ca7774 > arch/arm/mach-ca8277B > arch/arm/mach-ca7742 > arch/arm/mach-ca8279 > arch/arm/mach-caXnnn > > correct? or should we simply create a arch/arm/mach-caxxxx, arch/mips/mach-caxxxx, arch/xtensa/mach-axxxx, arch/riscv/mach-caxxxx, etc to maintain similar > changes to each arch related custom code which varies slightly for each SoC variation within each architecture? > What’s best to avoid maintaining duplicate code across SoC variations within the same ISA family? I would hope we can get by with arch/arm/mach-caxxxx or so and board/cortina/common/. How are you handling common code in the linux kernel?
Sounds good Tom. We will send the next series with the ARMv8 low_level.S moved to arch/mach-caxxxx/ Thanks for you guidance. Did you see anything else in 2nd series that needs modified before we send series 3 or can we assume those are fine to avoid sending another series after this issues is fixed in series 3? > On Jan 24, 2020, at 10:30 AM, Tom Rini <trini at konsulko.com> wrote: > > On Fri, Jan 24, 2020 at 05:55:29PM +0000, Alex Nemirovsky wrote: >> Looking inside >> grep -h CA board/cortina/common/armv8/lowlevel_init.S >> #if defined(CONFIG_SOC_CA7774) >> #if defined(CONFIG_SOC_CA8277B) >> >> as we understand it, the alternative would lead to maintaining duplicate but slightly different code for each ARM based SoC in >> arch/arm/mach-ca7774 >> arch/arm/mach-ca8277B >> arch/arm/mach-ca7742 >> arch/arm/mach-ca8279 >> arch/arm/mach-caXnnn >> >> correct? or should we simply create a arch/arm/mach-caxxxx, arch/mips/mach-caxxxx, arch/xtensa/mach-axxxx, arch/riscv/mach-caxxxx, etc to maintain similar >> changes to each arch related custom code which varies slightly for each SoC variation within each architecture? >> What’s best to avoid maintaining duplicate code across SoC variations within the same ISA family? > > I would hope we can get by with arch/arm/mach-caxxxx or so and > board/cortina/common/. How are you handling common code in the linux > kernel? > > -- > Tom
On Fri, Jan 24, 2020 at 06:34:40PM +0000, Alex Nemirovsky wrote: > Sounds good Tom. We will send the next series with the ARMv8 low_level.S moved to arch/mach-caxxxx/ > Thanks for you guidance. Did you see anything else in 2nd series that needs modified before we send > series 3 or can we assume those are fine to avoid sending another series after this issues is fixed in series 3? That was all I noticed, thanks again. > > > On Jan 24, 2020, at 10:30 AM, Tom Rini <trini at konsulko.com> wrote: > > > > On Fri, Jan 24, 2020 at 05:55:29PM +0000, Alex Nemirovsky wrote: > >> Looking inside > >> grep -h CA board/cortina/common/armv8/lowlevel_init.S > >> #if defined(CONFIG_SOC_CA7774) > >> #if defined(CONFIG_SOC_CA8277B) > >> > >> as we understand it, the alternative would lead to maintaining duplicate but slightly different code for each ARM based SoC in > >> arch/arm/mach-ca7774 > >> arch/arm/mach-ca8277B > >> arch/arm/mach-ca7742 > >> arch/arm/mach-ca8279 > >> arch/arm/mach-caXnnn > >> > >> correct? or should we simply create a arch/arm/mach-caxxxx, arch/mips/mach-caxxxx, arch/xtensa/mach-axxxx, arch/riscv/mach-caxxxx, etc to maintain similar > >> changes to each arch related custom code which varies slightly for each SoC variation within each architecture? > >> What’s best to avoid maintaining duplicate code across SoC variations within the same ISA family? > > > > I would hope we can get by with arch/arm/mach-caxxxx or so and > > board/cortina/common/. How are you handling common code in the linux > > kernel? > > > > -- > > Tom >
one last thing, since we are moving SoC code out of the board tree. would you prefer each SoC specific header directly in top level include directory or within nclude/cortina subdirectory? i.e. include/ca7774.h vs include/cortina/ca7774.h? > On Jan 24, 2020, at 10:42 AM, Tom Rini <trini at konsulko.com> wrote: > > On Fri, Jan 24, 2020 at 06:34:40PM +0000, Alex Nemirovsky wrote: > >> Sounds good Tom. We will send the next series with the ARMv8 low_level.S moved to arch/mach-caxxxx/ >> Thanks for you guidance. Did you see anything else in 2nd series that needs modified before we send >> series 3 or can we assume those are fine to avoid sending another series after this issues is fixed in series 3? > > That was all I noticed, thanks again. > >> >>> On Jan 24, 2020, at 10:30 AM, Tom Rini <trini at konsulko.com> wrote: >>> >>> On Fri, Jan 24, 2020 at 05:55:29PM +0000, Alex Nemirovsky wrote: >>>> Looking inside >>>> grep -h CA board/cortina/common/armv8/lowlevel_init.S >>>> #if defined(CONFIG_SOC_CA7774) >>>> #if defined(CONFIG_SOC_CA8277B) >>>> >>>> as we understand it, the alternative would lead to maintaining duplicate but slightly different code for each ARM based SoC in >>>> arch/arm/mach-ca7774 >>>> arch/arm/mach-ca8277B >>>> arch/arm/mach-ca7742 >>>> arch/arm/mach-ca8279 >>>> arch/arm/mach-caXnnn >>>> >>>> correct? or should we simply create a arch/arm/mach-caxxxx, arch/mips/mach-caxxxx, arch/xtensa/mach-axxxx, arch/riscv/mach-caxxxx, etc to maintain similar >>>> changes to each arch related custom code which varies slightly for each SoC variation within each architecture? >>>> What’s best to avoid maintaining duplicate code across SoC variations within the same ISA family? >>> >>> I would hope we can get by with arch/arm/mach-caxxxx or so and >>> board/cortina/common/. How are you handling common code in the linux >>> kernel? >>> >>> -- >>> Tom >> > > -- > Tom
On Fri, Jan 24, 2020 at 06:58:13PM +0000, Alex Nemirovsky wrote: > one last thing, since we are moving SoC code out of the board tree. > would you prefer each SoC specific header directly in top level > include directory or within nclude/cortina subdirectory? i.e. > include/ca7774.h vs include/cortina/ca7774.h? Inside of arch/arm/include/asm/mach-caxxxx/ you can split things how you think makes the most sense. There's many other examples to look at here. > > > On Jan 24, 2020, at 10:42 AM, Tom Rini <trini at konsulko.com> wrote: > > > > On Fri, Jan 24, 2020 at 06:34:40PM +0000, Alex Nemirovsky wrote: > > > >> Sounds good Tom. We will send the next series with the ARMv8 low_level.S moved to arch/mach-caxxxx/ > >> Thanks for you guidance. Did you see anything else in 2nd series that needs modified before we send > >> series 3 or can we assume those are fine to avoid sending another series after this issues is fixed in series 3? > > > > That was all I noticed, thanks again. > > > >> > >>> On Jan 24, 2020, at 10:30 AM, Tom Rini <trini at konsulko.com> wrote: > >>> > >>> On Fri, Jan 24, 2020 at 05:55:29PM +0000, Alex Nemirovsky wrote: > >>>> Looking inside > >>>> grep -h CA board/cortina/common/armv8/lowlevel_init.S > >>>> #if defined(CONFIG_SOC_CA7774) > >>>> #if defined(CONFIG_SOC_CA8277B) > >>>> > >>>> as we understand it, the alternative would lead to maintaining duplicate but slightly different code for each ARM based SoC in > >>>> arch/arm/mach-ca7774 > >>>> arch/arm/mach-ca8277B > >>>> arch/arm/mach-ca7742 > >>>> arch/arm/mach-ca8279 > >>>> arch/arm/mach-caXnnn > >>>> > >>>> correct? or should we simply create a arch/arm/mach-caxxxx, arch/mips/mach-caxxxx, arch/xtensa/mach-axxxx, arch/riscv/mach-caxxxx, etc to maintain similar > >>>> changes to each arch related custom code which varies slightly for each SoC variation within each architecture? > >>>> What’s best to avoid maintaining duplicate code across SoC variations within the same ISA family? > >>> > >>> I would hope we can get by with arch/arm/mach-caxxxx or so and > >>> board/cortina/common/. How are you handling common code in the linux > >>> kernel? > >>> > >>> -- > >>> Tom > >> > > > > -- > > Tom >
Cortina Access management has decided that we want to add formal upstream support of u-boot going forward for our line of SoCs and evaluation boards. Our line of SoC’s all begin with the “CA” designation followed by 4 digits. i.e. CAxxxx. The CAxxxx series supports both ARM and MIPS ISA based custom cores. All our drivers have cross platform support for both CPU ISAs. They will be placed in the normal drivers tree in u-boot. In addition, our SoCs and development boards share common Cortina specific features which are not driver related. Those changes will be maintained in board/cortina/common. While specific development boards will be in board/cortina/board_name. We would like to have a git-mailrc alias of "cortina" to allow us to better maintain and support our boards and common features found in the board/cortina subtree. Changes in v2: - Modified filepath for CA ARM and MIPS per trini's recommendation - Rename driver in DT namespace for consistency between all CA drivers. - Remove blank line after SPDX identifier - Remove Authorship as it is already recorded within Git and is redundant - Replace printf() as debug() - Rename driver in DT namespace for consistency between all CA drivers. - Remove blank line after SPDX identifier - Remove authorship comment as it is already recorded within Git and is redundant - Use setbits_32() for read-modify-write operation. - Rename driver in DT namespace for consistency between all CA drivers. - Remove blank line after SPDX identifier - Remove authorship comment as it is already recorded within Git and is redundant - Merge serial_cortina.h reg defines into serial_cortina.c - Modify ca_serial_pending() and API to get resource. Alex Nemirovsky (3): MAINTAINERS, git-mailrc: cortina: add Custodian for Cortina Access Inc. cortina: common: armv8: add custom init for CA ARMv8 based SoCs board: presidio-asic: Add basic G3 engr. development board support Jason Li (4): gpio: do not include <asm/arch/gpio.h> for Cortina CAxxxx SoCs gpio: cortina_gpio: add DM_GPIO driver for CAxxxx SoCs watchdog: cortina_wdt: add support for HW WDT on CAxxxx SoCs serial: serial_cortina: add UART DM driver for CAxxxx SoCs MAINTAINERS | 18 +++ arch/arm/Kconfig | 5 + arch/arm/dts/Makefile | 2 + arch/arm/dts/ca-presidio-engboard.dts | 69 +++++++++++ arch/arm/include/asm/gpio.h | 2 +- board/cortina/common/Kconfig | 5 + board/cortina/common/armv8/ca7774_regs.h | 18 +++ board/cortina/common/armv8/lowlevel_init.S | 87 ++++++++++++++ board/cortina/presidio-asic/Kconfig | 20 ++++ board/cortina/presidio-asic/MAINTAINERS | 6 + board/cortina/presidio-asic/Makefile | 8 ++ board/cortina/presidio-asic/presidio.c | 126 ++++++++++++++++++++ configs/cortina_presidio-asic-base_defconfig | 45 ++++++++ doc/git-mailrc | 2 + drivers/gpio/Kconfig | 8 ++ drivers/gpio/Makefile | 1 + drivers/gpio/cortina_gpio.c | 111 ++++++++++++++++++ drivers/serial/Kconfig | 7 ++ drivers/serial/Makefile | 2 +- drivers/serial/serial_cortina.c | 164 +++++++++++++++++++++++++++ drivers/watchdog/Kconfig | 8 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/cortina_wdt.c | 138 ++++++++++++++++++++++ include/configs/presidio_asic.h | 123 ++++++++++++++++++++ 24 files changed, 974 insertions(+), 2 deletions(-) create mode 100644 arch/arm/dts/ca-presidio-engboard.dts create mode 100644 board/cortina/common/Kconfig create mode 100644 board/cortina/common/armv8/ca7774_regs.h create mode 100644 board/cortina/common/armv8/lowlevel_init.S create mode 100644 board/cortina/presidio-asic/Kconfig create mode 100644 board/cortina/presidio-asic/MAINTAINERS create mode 100644 board/cortina/presidio-asic/Makefile create mode 100644 board/cortina/presidio-asic/presidio.c create mode 100644 configs/cortina_presidio-asic-base_defconfig create mode 100644 drivers/gpio/cortina_gpio.c create mode 100644 drivers/serial/serial_cortina.c create mode 100644 drivers/watchdog/cortina_wdt.c create mode 100644 include/configs/presidio_asic.h