[PATCH v4 0/6] Introducing the Alpine platform.

[PATCH v4 0/6] Introducing the Alpine platform.

[Tsahee Zidenberg]

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

-- 
1.9.1

[PATCH v4 0/6] Introducing the Alpine platform.

[Arnd Bergmann]

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

[PATCH v4 0/6] Introducing the Alpine platform.

[Tsahee Zidenberg]

Hi arnd!

On 3 February 2015 at 15:55, Arnd Bergmann <arnd@arndb.de> wrote:
> 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 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.

> * 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.

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.

> * 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!
>
>         Arnd

[PATCH v4 0/6] Introducing the Alpine platform.

[Arnd Bergmann]

On Wednesday 04 February 2015 13:19:04 Tsahee Zidenberg wrote:
> Hi arnd!
> 
> On 3 February 2015 at 15:55, Arnd Bergmann <arnd@arndb.de> wrote:
> > 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 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.

> > * 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.
> 
> 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

[PATCH v4 0/6] Introducing the Alpine platform.

[Ronen Shitrit]

On 4 February 2015 at 14:33, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wednesday 04 February 2015 13:19:04 Tsahee Zidenberg wrote:
> > Hi arnd!
> >
> > On 3 February 2015 at 15:55, Arnd Bergmann <arnd@arndb.de> wrote:
> > > 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 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.

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...

>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,

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.

>
> 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.
>
> > > * 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.
> >
> > 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




-- 
Ronen Shitrit

[PATCH v4 0/6] Introducing the Alpine platform.

[Arnd Bergmann]

On Thursday 05 February 2015 10:28:02 Ronen Shitrit wrote:
> On 4 February 2015 at 14:33, Arnd Bergmann <arnd@arndb.de> wrote:
> > 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. ;-)

> 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.

> >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,
> 
> 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

[PATCH v4 0/6] Introducing the Alpine platform.

[Ronen Shitrit]

On 5 February 2015 at 14:21, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thursday 05 February 2015 10:28:02 Ronen Shitrit wrote:
> > On 4 February 2015 at 14:33, Arnd Bergmann <arnd@arndb.de> wrote:
> > > 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. ;-)
Tnx for the tip :)

>
> > 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...

> 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.
>
> > >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,
> >
> > 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.
Understand, not sure if it can work out but we will give it a try...

>
> 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




-- 
Ronen Shitrit