ARM: keystone: K2G: Add support for PMMC remoteproc load

u-boot coding style guidance in
http://www.denx.de/wiki/U-Boot/CodingStyle clearly mentions that the kernel doc style shall be followed for documentation in u-boot.

Current PSC documentation standard does not, so fix that.

Signed-off-by Nishanth Menon <[email protected]>

u-boot coding style guidance in
http://www.denx.de/wiki/U-Boot/CodingStyle clearly mentions that the kernel doc style shall be followed for documentation in u-boot.

Current PSC documentation standard does not, so fix that.

Signed-off-by Nishanth Menon <[email protected]>

Reviewed-by Tom Rini <[email protected]>

'#define X a | b' is better defined as '#define X (a | b)' for obvious reasons.

Signed-off-by Nishanth Menon <[email protected]>

Quoted 3 lines · Nishanth Menon

'#define X a | b' is better defined as '#define X (a | b)' for obvious reasons.

Quoted 1 line

Signed-off-by Nishanth Menon <[email protected]>

Reviewed-by Tom Rini <[email protected]>

But this makes my head hurt. Can we somehow do any of that with less parenthesis? Like, is this really something we must macro? Or can we re-factor it? I had to highlight every open/close to be happy it was correct, which is not a good sign.

'#define X a | b' is better defined as '#define X (a | b)' for obvious reasons.

Signed-off-by Nishanth Menon <[email protected]>

Reviewed-by Tom Rini <[email protected]>

These are useful for modules that need to be held in reset and are enabled for data to be loaded on to them. Typically these are microcontrollers or other processing entities in the system.

Signed-off-by Nishanth Menon <[email protected]>

These are useful for modules that need to be held in reset and are enabled for data to be loaded on to them. Typically these are microcontrollers or other processing entities in the system.

Signed-off-by Nishanth Menon <[email protected]>

Reviewed-by Tom Rini <[email protected]>

Many TI System on Chip (SoC) solutions do have a dedicated microcontroller for doing power management functionality. These include the AM335x, AM437x, Keystone K2G SoCs. The functionality provided by these microcontrollers and the communication mechanisms vary very widely. However, we are able to consolidate some basic functionality to be generic enough starting with K2G SoC family. Introduce a basic remote proc driver to support these microcontrollers. In fact, on SoCs starting with K2G, basic power management functions are primarily accessible for the High Level Operating Systems(HLOS) via these microcontroller solutions.

Hence, having these started at a bootloader level is pretty much mandatory.

Signed-off-by Nishanth Menon <[email protected]>

Many TI System on Chip (SoC) solutions do have a dedicated microcontroller for doing power management functionality. These include the AM335x, AM437x, Keystone K2G SoCs. The functionality provided by these microcontrollers and the communication mechanisms vary very widely. However, we are able to consolidate some basic functionality to be generic enough starting with K2G SoC family. Introduce a basic remote proc driver to support these microcontrollers. In fact, on SoCs starting with K2G, basic power management functions are primarily accessible for the High Level Operating Systems(HLOS) via these microcontroller solutions.

Hence, having these started at a bootloader level is pretty much mandatory.

Signed-off-by Nishanth Menon <[email protected]>

Reviewed-by Tom Rini <[email protected]>

Enable support for PMMC the TI power processor on K2G. This processor manages all power management related activities on the SoC and and allows the Operating Systems on compute processors such as ARM, DSP to offload the power logic away into the power processor. U-boot just has a load responsibility, hence the view of the hardware from a bootloader perspective is different from the view of hardware from a Operating System perspective. While bootloader just loads up the firmware, Operating Systems look at the resultant system as "hardware".

Signed-off-by Nishanth Menon <[email protected]>

Quoted 9 lines · Nishanth Menon

Enable support for PMMC the TI power processor on K2G. This processor manages all power management related activities on the SoC and and allows the Operating Systems on compute processors such as ARM, DSP to offload the power logic away into the power processor. U-boot just has a load responsibility, hence the view of the hardware from a bootloader perspective is different from the view of hardware from a Operating System perspective. While bootloader just loads up the firmware, Operating Systems look at the resultant system as "hardware".

Quoted 1 line

Signed-off-by Nishanth Menon <[email protected]>

Reviewed-by Tom Rini <[email protected]>

... and this will match whatever is in the kernel, right?

Quoted 11 lines · Tom Rini

Quoted 9 lines · Nishanth Menon

Enable support for PMMC the TI power processor on K2G. This processor manages all power management related activities on the SoC and and allows the Operating Systems on compute processors such as ARM, DSP to offload the power logic away into the power processor. U-boot just has a load responsibility, hence the view of the hardware from a bootloader perspective is different from the view of hardware from a Operating System perspective. While bootloader just loads up the firmware, Operating Systems look at the resultant system as "hardware".

Quoted 5 lines

Quoted 1 line

Signed-off-by Nishanth Menon <[email protected]>

Reviewed-by Tom Rini <[email protected]>

... and this will match whatever is in the kernel, right?

The Linux kernel will not need to access PMMC similar to how bootloader has to.

Bootloader looks to load up the peripheral - so, it's view of the hardware is as a programmable core (similar to how we'd look at a DSP/other remote proc), however, linux kernel only cares about the communication link (which is the message manager) and the protocol on top to communicate and does not need to access PMMC directly (it is only done once by bootloader).

So the the current u-boot dt binding will not even need to be send upstream kernel, instead a protocol level definition (similar to SCPI) will be exposed to linux kernel.

Quoted 2 lines · Nishanth Menon

Quoted 1 line · Tom Rini

On Thu, Feb 25, 2016 at 12:53:46PM -0600, Nishanth Menon wrote:

Quoted 12 lines

Quoted 2 lines

... and this will match whatever is in the kernel, right?

The Linux kernel will not need to access PMMC similar to how bootloader has to.

Bootloader looks to load up the peripheral - so, it's view of the hardware is as a programmable core (similar to how we'd look at a DSP/other remote proc), however, linux kernel only cares about the communication link (which is the message manager) and the protocol on top to communicate and does not need to access PMMC directly (it is only done once by bootloader).

Quoted 3 lines

So the the current u-boot dt binding will not even need to be send upstream kernel, instead a protocol level definition (similar to SCPI) will be exposed to linux kernel.

So is the kernel community going to be unhappy about getting what it might consider extraneous information in the device tree? The goal here is to be able to just copy in the DT files from $upstream and really really not have local changes without a good reason (and yes, we need to revisit u-boot,dm-pre-reloc at some point). Maybe a question for one of the higher level DT lists...

Tom,

Quoted 3 lines · Tom Rini

Quoted 2 lines · Nishanth Menon

Quoted 1 line · Tom Rini

On Thu, Feb 25, 2016 at 12:53:46PM -0600, Nishanth Menon wrote:

[...]

Quoted 16 lines

Quoted 12 lines

Quoted 2 lines

... and this will match whatever is in the kernel, right?

The Linux kernel will not need to access PMMC similar to how bootloader has to.

Bootloader looks to load up the peripheral - so, it's view of the hardware is as a programmable core (similar to how we'd look at a DSP/other remote proc), however, linux kernel only cares about the communication link (which is the message manager) and the protocol on top to communicate and does not need to access PMMC directly (it is only done once by bootloader).

Quoted 3 lines

So the the current u-boot dt binding will not even need to be send upstream kernel, instead a protocol level definition (similar to SCPI) will be exposed to linux kernel.

Quoted 6 lines

So is the kernel community going to be unhappy about getting what it might consider extraneous information in the device tree? The goal here is to be able to just copy in the DT files from $upstream and really really not have local changes without a good reason (and yes, we need to revisit u-boot,dm-pre-reloc at some point). Maybe a question for one of the higher level DT lists...

Hmmm... I can switch to platform data if maintenance is an concern. I dont think PMMC will be an unique experience for DT view of the hardware where every piece of software looks at things differently. For example: if we move DDR configuration to device tree (which dt is pretty capable of doing), then we are stuck with the same issue yet again. DDR configuration is not necessary for kernel device tree since it has nothing to do there - and we dont provide that information (since it becomes a maintenance pain in kernel world as well), but u-boot SPL will need to have that information.

Device tree is a representation of hardware is exactly what we do, except that view depends on what we need to expose to each software solution. Even in Linux, in a hypervisor world, a guest OS may only have access to certain peripherals of the SoC - we dont expose all the peripherals to the OS via dt, instead a custom guest OS dt view of the world is created. This is one problem we all have with DT -> the extent to which we "describe hardware" - there is no objective rules for the same that can get blindly applied..

Do let me know if I need to bring this device outside of dt into platform data world. It wont be my first preference, but if it does create a severe maintenance burden, then maybe that is what needs to happen -> only resources that are shared between kernel and bootloader can reside in dt... just my 2 cents..

Enable support for PMMC the TI power processor on K2G. This processor manages all power management related activities on the SoC and and allows the Operating Systems on compute processors such as ARM, DSP to offload the power logic away into the power processor. U-boot just has a load responsibility, hence the view of the hardware from a bootloader perspective is different from the view of hardware from a Operating System perspective. While bootloader just loads up the firmware, Operating Systems look at the resultant system as "hardware".

Signed-off-by Nishanth Menon <[email protected]>

Reviewed-by Tom Rini <[email protected]>

Enable support for PMMC the TI power processor on K2G. This processor manages all power management related activities on the SoC and and allows the Operating Systems on compute processors such as ARM, DSP to offload the power logic away into the power processor.

Signed-off-by Nishanth Menon <[email protected]>

Enable support for PMMC the TI power processor on K2G. This processor manages all power management related activities on the SoC and and allows the Operating Systems on compute processors such as ARM, DSP to offload the power logic away into the power processor.

Signed-off-by Nishanth Menon <[email protected]>

Reviewed-by Tom Rini <[email protected]>