| Message ID | 1456426427-23166-6-git-send-email-nm@ti.com |
|---|---|
| State | Accepted |
| Commit | 606e4ac35ee398bfcf8a1b49a1b07bdfb1541185 |
| Headers | show |
On Fri, Feb 26, 2016 at 12:18 PM, Tom Rini <trini@konsulko.com> wrote: > On Thu, Feb 25, 2016 at 12:53:46PM -0600, Nishanth Menon wrote: > >> 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 <nm@ti.com> > > Reviewed-by: Tom Rini <trini@konsulko.com> > > ... 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. -- --- Regards, Nishanth Menon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Tom, On Fri, Feb 26, 2016 at 6:27 PM, Tom Rini <trini@konsulko.com> wrote: > On Fri, Feb 26, 2016 at 06:18:30PM -0600, Nishanth Menon wrote: >> On Fri, Feb 26, 2016 at 12:18 PM, Tom Rini <trini@konsulko.com> wrote: >> > On Thu, Feb 25, 2016 at 12:53:46PM -0600, Nishanth Menon wrote: [...] >> > >> > ... 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. > > 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.. --- Regards, Nishanth Menon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
diff --git a/arch/arm/dts/k2g.dtsi b/arch/arm/dts/k2g.dtsi index bbc2cf91b95f..a3ed444d3c31 100644 --- a/arch/arm/dts/k2g.dtsi +++ b/arch/arm/dts/k2g.dtsi @@ -81,5 +81,12 @@ }; #include "k2g-netcp.dtsi" + + pmmc: pmmc@2900000 { + compatible = "ti,power-processor"; + reg = <0x02900000 0x40000>; + ti,lpsc_module = <1>; + }; + }; };
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 <nm@ti.com> --- V1: did not exist arch/arm/dts/k2g.dtsi | 7 +++++++ 1 file changed, 7 insertions(+) -- 2.7.0 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot