Introducing the Alpine platform.
v4 cover Introducing the Alpine platform.
If possible to introduce this into 3.20 - I would really appreciate it. If any action by me can make it happen - please let me know.
Thank you!
---
Annapurna Labs(TM) is a technology company providing innovative solutions including chips, software, and systems for the datacenter and enterprise infrastructure.
Alpine(TM) is one of Annapurna Labs? chip products targeting storage and networking applications. It is a complete Platform-On-Chip, integrating 2-4 cortex-A15 cores and multiple innovations to provide a seamless networking and storage fabric for enterprise and datacenter equipment.
This patchset provides initial support for the Alpine platform.
Patch #1 contains minimal, single-cpu architecture support.
Patch #2 adds early-debug capabilities via Alpine UART 0.
Patch #3 adds smp-support and a secondary cpu enable-method for the platform.
Patch #4 provides documentation for the available device-tree nodes.
Patch #5 provides a device-tree for Alpine soc and development board.
Patch #6 adds an entry to MAINTAINERS file.
The patchset was tested with multi_v7_defconfig, adding CONFIG_ARCH_ALPINE
---
V2:
* map physical cpu-id from logical on cpu wakeup
* use syscon/regmap for sysfabric_service implementation
* devicetree format:
** split between .dtsi and dts ** dual license ** node and manufacturer naming
* intoduce devicetree in two separate patches
* multiple format fixes
* rebased on d932006 (for-next)
---
V3:
* small format changes
* rebased on f9db7e2 (for-next)
---
V4:
* removed unnecessary "compatible" property
* added entry to MAINTAINERS file, in a separate patch.
Tsahee Zidenberg (6):
ARM: Alpine: Initial support for Alpine platform
ARM: Alpine: early-debug print support
ARM: Alpine: smp support
ARM: dts: Alpine platform binding documentation
ARM: dts: Alpine platform devicetree
MAINTAINERS: add maintainer for Alpine Arm machine
.../devicetree/bindings/arm/al,alpine.txt | 88 +++++++++++++ .../bindings/arm/cpu-enable-method/al,alpine-smp | 52 ++++++++ .../devicetree/bindings/vendor-prefixes.txt | 1 + MAINTAINERS | 5 + arch/arm/Kconfig | 2 + arch/arm/Kconfig.debug | 12 +- arch/arm/Makefile | 1 + arch/arm/boot/dts/Makefile | 4 + arch/arm/boot/dts/alpine-db.dts | 35 +++++ arch/arm/boot/dts/alpine.dtsi | 141 +++++++++++++++++++++ arch/arm/mach-alpine/Kconfig | 10 ++ arch/arm/mach-alpine/Makefile | 6 + arch/arm/mach-alpine/alpine_cpu_pm.c | 70 ++++++++++ arch/arm/mach-alpine/alpine_cpu_pm.h | 26 ++++ arch/arm/mach-alpine/alpine_cpu_resume.h | 38 ++++++ arch/arm/mach-alpine/alpine_machine.c | 28 ++++ arch/arm/mach-alpine/platsmp.c | 49 +++++++ 17 files changed, 567 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/arm/al,alpine.txt create mode 100644 Documentation/devicetree/bindings/arm/cpu-enable-method/al,alpine-smp create mode 100644 arch/arm/boot/dts/alpine-db.dts create mode 100644 arch/arm/boot/dts/alpine.dtsi create mode 100644 arch/arm/mach-alpine/Kconfig create mode 100644 arch/arm/mach-alpine/Makefile create mode 100644 arch/arm/mach-alpine/alpine_cpu_pm.c create mode 100644 arch/arm/mach-alpine/alpine_cpu_pm.h create mode 100644 arch/arm/mach-alpine/alpine_cpu_resume.h create mode 100644 arch/arm/mach-alpine/alpine_machine.c create mode 100644 arch/arm/mach-alpine/platsmp.c
Signature · 1 line
1.9.1
v4 cover Introducing the Alpine platform.
Quoted 3 lines · On Tuesday 03 February 2015 15:29:05 Tsahee Zidenberg wrote:
If possible to introduce this into 3.20 - I would really appreciate it. If any action by me can make it happen - please let me know.
Hi Tsahee,
This is not directly related to your patches, but since I got curious I looked at the source code published by Synology. I don't know how far you've come in modernizing this, but this is what I found:
* The hardware looked really nice
* You only have a couple of custom drivers, but they all have the same mistake in using a private 'hardware abstraction layer'. Don't do this, and use the kernel's interfaces directly
* The serdes driver should register as a generic PHY driver
* If possible, move the PCI initialization into the boot loader and use drivers/pci/pci_host_generic.c to avoid having your own driver.
* the memory controller driver should live in drivers/memory
* the baseidx addition to the pl061 driver is not going in, use the new devm_gpiod_* interfaces to avoid relying on particular gpio numbers.
* The spi driver already has a binding, which is incompatible to the one you use.
Arnd
v4 cover Introducing the Alpine platform.
Hi arnd!
Quoted 7 lines · Arnd Bergmann
Quoted 3 lines · On Tuesday 03 February 2015 15:29:05 Tsahee Zidenberg wrote:
If possible to introduce this into 3.20 - I would really appreciate it. If any action by me can make it happen - please let me know.
Hi Tsahee,
Quoted 8 lines
This is not directly related to your patches, but since I got curious I looked at the source code published by Synology. I don't know how far you've come in modernizing this, but this is what I found:
* The hardware looked really nice
* You only have a couple of custom drivers, but they all have the same mistake in using a private 'hardware abstraction layer'. Don't do this, and use the kernel's interfaces directly
The main motivations for adding a HAL:
* re-using code between linux kernel and other systems.
* re-using common code between different drivers (e.g. - different hardware units use the same DMA engine)
* a basic approach that states our HAL is in-fact part of the chip's API I believe we will find a middle ground that will allow keeping these benefits without compromise of the kernel coding style. The HALs were written from day 1 with kernel coding-style in mind, and we do realize there may be some more changes required in the process.
Quoted 4 lines
* The serdes driver should register as a generic PHY driver
* If possible, move the PCI initialization into the boot loader and usedrivers/pci/pci_host_generic.cto avoid having your own driver.
PCI support will probably be the next topic for Alpine merging. I am working on the patchset, and it will use the generic pci driver and device-tree node.
Quoted 6 lines
* the memory controller driver should live in
drivers/memory
* the baseidx addition to the pl061 driver is not going in, use the new devm_gpiod_* interfaces to avoid relying on particular gpio numbers.
* The spi driver already has a binding, which is incompatible to the one you use.
Thank you! We will take these into consideration!
Quoted 2 lines
Arnd
v4 cover Introducing the Alpine platform.
Quoted 19 lines · On Wednesday 04 February 2015 13:19:04 Tsahee Zidenberg wrote:
Hi arnd!
Quoted 7 lines · Arnd Bergmann
Quoted 3 lines · On Tuesday 03 February 2015 15:29:05 Tsahee Zidenberg wrote:
If possible to introduce this into 3.20 - I would really appreciate it. If any action by me can make it happen - please let me know.
Hi Tsahee,
Quoted 8 lines
This is not directly related to your patches, but since I got curious I looked at the source code published by Synology. I don't know how far you've come in modernizing this, but this is what I found:
* The hardware looked really nice
* You only have a couple of custom drivers, but they all have the same mistake in using a private 'hardware abstraction layer'. Don't do this, and use the kernel's interfaces directly
Quoted 9 lines
The main motivations for adding a HAL:
* re-using code between linux kernel and other systems.
* re-using common code between different drivers (e.g. - different hardware units use the same DMA engine)
* a basic approach that states our HAL is in-fact part of the chip's API I believe we will find a middle ground that will allow keeping these benefits without compromise of the kernel coding style. The HALs were written from day 1 with kernel coding-style in mind, and we do realize there may be some more changes required in the process.
I understand where you are coming from, as this is something that everyone gets wrong at first. However, you will not be able to merge the drivers with a HAL like this. The kernel abstracts all the components of typical SoCs already and I suspect you just did not use the right abstraction because you either didn't find it, or it was not there at the time you started the work.
For example, a DMA subsystem that is used by multiple slave drivers should use a driver in drivers/dma that registers to the slave-dma API, and a clock driver should register in drivers/clk, and the smmu belongs into drivers/iommu.
I expect that for each exported function of your HAL, we already have a subsystem that lets you express the same functionality in a more general way. I can help you find the right place if you are unsure about some of them.
If there is some code that does not have a proper subsystem it can be moved into, we should discuss about adding a subsystem with soc-independent interfaces, but I don't think we need this for a chip like yours that uses fairly standard components.
Quoted 8 lines
Quoted 4 lines
* The serdes driver should register as a generic PHY driver
* If possible, move the PCI initialization into the boot loader and usedrivers/pci/pci_host_generic.cto avoid having your own driver.PCI support will probably be the next topic for Alpine merging. I am working on the patchset, and it will use the generic pci driver and device-tree node.
Ok, sounds good.
Arnd
v4 cover Introducing the Alpine platform.
Quoted 31 lines · Arnd Bergmann
Quoted 19 lines · On Wednesday 04 February 2015 13:19:04 Tsahee Zidenberg wrote:
Hi arnd!
Quoted 7 lines · Arnd Bergmann
Quoted 3 lines · On Tuesday 03 February 2015 15:29:05 Tsahee Zidenberg wrote:
If possible to introduce this into 3.20 - I would really appreciate it. If any action by me can make it happen - please let me know.
Hi Tsahee,
Quoted 8 lines
This is not directly related to your patches, but since I got curious I looked at the source code published by Synology. I don't know how far you've come in modernizing this, but this is what I found:
* The hardware looked really nice
* You only have a couple of custom drivers, but they all have the same mistake in using a private 'hardware abstraction layer'. Don't do this, and use the kernel's interfaces directlyQuoted 9 lines
The main motivations for adding a HAL:
* re-using code between linux kernel and other systems.
* re-using common code between different drivers (e.g. - different hardware units use the same DMA engine)
* a basic approach that states our HAL is in-fact part of the chip's API I believe we will find a middle ground that will allow keeping these benefits without compromise of the kernel coding style. The HALs were written from day 1 with kernel coding-style in mind, and we do realize there may be some more changes required in the process.
Quoted 2 lines
I understand where you are coming from, as this is something that everyone gets wrong at first.
In order to bring up a completely new silicon with lots of technologies challenges in such short time and take it to production, with multi discipline environments, few OSs support and small software group, we had to share code as much as possible == hal.
We were aware from first day of the obstacles of merging hal code to the mainline, that why we implemented it using linux coding style, trying to minimize the "resistance", and we hoped (and still are :) to find a path to keep part of our low level code into the mainline. If it wont work out, we will rewrite it...
Quoted 8 lines
However, you will not be able to merge
the drivers with a HAL like this. The kernel abstracts all the components of typical SoCs already and I suspect you just did not use the right abstraction because you either didn't find it, or it was not there at the time you started the work.For example, a DMA subsystem that is used by multiple slave drivers should use a driver in
drivers/dmathat registers to the slave-dma API,
If you are referring to the dma-engine api, than this is a good example where we don't want to use the generic framework as its overhead on performance is unacceptable.
In any case we would love to dive into details and get more feedback of how to merge our eth, storage and crypto acceleration dma based drivers, I hope we will start this task soon... Tnx for all your comments and guidelines so far.
Quoted 26 lines
and a clock driver should register in
drivers/clk, and the smmu belongs intodrivers/iommu.I expect that for each exported function of your HAL, we already have a subsystem that lets you express the same functionality in a more general way. I can help you find the right place if you are unsure about some of them.
If there is some code that does not have a proper subsystem it can be moved into, we should discuss about adding a subsystem with soc-independent interfaces, but I don't think we need this for a chip like yours that uses fairly standard components.
Quoted 8 lines
Quoted 4 lines
* The serdes driver should register as a generic PHY driver
* If possible, move the PCI initialization into the boot loader and usedrivers/pci/pci_host_generic.cto avoid having your own driver.PCI support will probably be the next topic for Alpine merging. I am working on the patchset, and it will use the generic pci driver and device-tree node.
Ok, sounds good.
Arnd
Signature · 1 line
Ronen Shitrit
v4 cover Introducing the Alpine platform.
Quoted 10 lines · On Thursday 05 February 2015 10:28:02 Ronen Shitrit wrote:
Quoted 4 lines · Arnd Bergmann
On Wednesday 04 February 2015 13:19:04 Tsahee Zidenberg wrote:
I understand where you are coming from, as this is something that everyone gets wrong at first.
In order to bring up a completely new silicon with lots of technologies challenges in such short time and take it to production, with multi discipline environments, few OSs support and small software group, we had to share code as much as possible == hal.
I think the most important part for you to understand is not to call something a hal (or os abstraction, which would be worse), as that is universally hated. ;-)
Quoted 5 lines
We were aware from first day of the obstacles of merging hal code to the mainline, that why we implemented it using linux coding style, trying to minimize the "resistance", and we hoped (and still are :) to find a path to keep part of our low level code into the mainline. If it wont work out, we will rewrite it...
It's not as bad if something is contained within one driver: if you have e.g. a network driver that consists of a low-level part that talks to the hardware and a high-level part that talks to linux, that can be ok. What you should avoid is having interfaces that span across multiple driver components and use a global header file for the interface but are specific to one SoC family.
Quoted 6 lines
Quoted 6 lines
However, you will not be able to merge
the drivers with a HAL like this. The kernel abstracts all the components of typical SoCs already and I suspect you just did not use the right abstraction because you either didn't find it, or it was not there at the time you started the work.
Quoted 6 lines
Quoted 2 lines
For example, a DMA subsystem that is used by multiple slave drivers should use a driver in
drivers/dmathat registers to the slave-dma API,If you are referring to the dma-engine api, than this is a good example where we don't want to use the generic framework as its overhead on performance is unacceptable.
It also illustrates my point: When we introduce a second interface in parallel to the existing one, this puts a burden on us upstream maintainers which now have to understand and maintain both. We used to have all sorts of interfaces per SoC and are almost done consolidating them to all use dmaengine for this reason.
I do realize that the dmaengine API is not perfect though, so if you have specific problems with it, we expect you to help figure out what they are and what we can do about them so that everybody benefits.
To a certain extent, this is how we make progress in the kernel with generic interfaces: someone has a particular need and it's up to them to implement the groundwork. In return they get all the features of the kernel that someone else needed and implemented already.
Arnd
v4 cover Introducing the Alpine platform.
Quoted 8 lines · Arnd Bergmann
Quoted 6 lines · On Thursday 05 February 2015 10:28:02 Ronen Shitrit wrote:
Quoted 4 lines · Arnd Bergmann
On Wednesday 04 February 2015 13:19:04 Tsahee Zidenberg wrote:
I understand where you are coming from, as this is something that everyone gets wrong at first.
Quoted 8 lines
Quoted 4 lines
In order to bring up a completely new silicon with lots of technologies challenges in such short time and take it to production, with multi discipline environments, few OSs support and small software group, we had to share code as much as possible == hal.
I think the most important part for you to understand is not to call something a hal (or os abstraction, which would be worse), as that is universally hated. ;-)
Tnx for the tip :)
Quoted 8 lines
Quoted 6 lines
We were aware from first day of the obstacles of merging hal code to the mainline, that why we implemented it using linux coding style, trying to minimize the "resistance", and we hoped (and still are :) to find a path to keep part of our low level code into the mainline. If it wont work out, we will rewrite it...
It's not as bad if something is contained within one driver:
We tried to keep this concept across our low level drivers...
Quoted 20 lines
if you have
e.g. a network driver that consists of a low-level part that talks to the hardware and a high-level part that talks to linux, that can be ok. What you should avoid is having interfaces that span across multiple driver components and use a global header file for the interface but are specific to one SoC family.Quoted 6 lines
Quoted 6 lines
However, you will not be able to merge
the drivers with a HAL like this. The kernel abstracts all the components of typical SoCs already and I suspect you just did not use the right abstraction because you either didn't find it, or it was not there at the time you started the work.Quoted 6 lines
Quoted 2 lines
For example, a DMA subsystem that is used by multiple slave drivers should use a driver in
drivers/dmathat registers to the slave-dma API,If you are referring to the dma-engine api, than this is a good example where we don't want to use the generic framework as its overhead on performance is unacceptable.
Quoted 8 lines
It also illustrates my point: When we introduce a second interface in parallel to the existing one, this puts a burden on us upstream maintainers which now have to understand and maintain both. We used to have all sorts of interfaces per SoC and are almost done consolidating them to all use dmaengine for this reason.
I do realize that the dmaengine API is not perfect though, so if you have specific problems with it, we expect you to help figure out what they are and what we can do about them so that everybody benefits.
Understand, not sure if it can work out but we will give it a try...
Quoted 7 lines
To a certain extent, this is how we make progress in the kernel with generic interfaces: someone has a particular need and it's up to them to implement the groundwork. In return they get all the features of the kernel that someone else needed and implemented already.
Arnd
Signature · 1 line
Ronen Shitrit