[U-Boot] [PATCH V2 0/6] ARM: keystone: K2G: Add support for PMMC remoteproc load

Hi,
Here is the series for supporting TI's PMMC - a Power Management co-processor in TI's K2G SoC. TI's SoC architecture requires the microcontroller for power management functionality which is excersized by various operating systems running on ARM, DSP and other compute engines in a centralized manner.
Changes in V2: - Updated remoteproc driver to work with device tree - config env variable updates
Series based on: master 52dd704bf8ed Merge branch 'master' of http://git.denx.de/u-boot-sunxi
Test log: http://pastebin.ubuntu.com/15200102/
Nishanth Menon (6): ARM: keystone2: psc: redo doc in kernel-doc format ARM: keystone2: psc-defs: use adequate () for macros ARM: keystone2: psc: introduce function to hold and release module in reset. remoteproc: Add support for TI power processor ARM: dts: k2g: Add support for PMMC configs: k2g_evm: Add TI power processor support
arch/arm/dts/k2g.dtsi | 7 + arch/arm/mach-keystone/include/mach/psc_defs.h | 10 +- arch/arm/mach-keystone/psc.c | 200 +++++++++++++++++++------ configs/k2g_evm_defconfig | 2 + drivers/remoteproc/Kconfig | 10 ++ drivers/remoteproc/Makefile | 1 + drivers/remoteproc/ti_power_proc.c | 180 ++++++++++++++++++++++ include/configs/k2g_evm.h | 7 + include/configs/ti_armv7_keystone2.h | 14 ++ 9 files changed, 384 insertions(+), 47 deletions(-) create mode 100644 drivers/remoteproc/ti_power_proc.c

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 nm@ti.com --- V2: no change V1: https://patchwork.ozlabs.org/patch/510210/ arch/arm/mach-keystone/psc.c | 96 ++++++++++++++++++++++++-------------------- 1 file changed, 52 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-keystone/psc.c b/arch/arm/mach-keystone/psc.c index 237e776e8790..8991e237735e 100644 --- a/arch/arm/mach-keystone/psc.c +++ b/arch/arm/mach-keystone/psc.c @@ -13,24 +13,27 @@ #include <asm/processor.h> #include <asm/arch/psc_defs.h>
+/** + * psc_delay() - delay for psc + * + * Return: 10 + */ int psc_delay(void) { udelay(10); return 10; }
-/* - * FUNCTION PURPOSE: Wait for end of transitional state - * - * DESCRIPTION: Polls pstat for the selected domain and waits for transitions - * to be complete. +/** + * psc_wait() - Wait for end of transitional state + * @domain_num: GPSC domain number * - * Since this is boot loader code it is *ASSUMED* that interrupts - * are disabled and no other core is mucking around with the psc - * at the same time. + * Polls pstat for the selected domain and waits for transitions to be complete. + * Since this is boot loader code it is *ASSUMED* that interrupts are disabled + * and no other core is mucking around with the psc at the same time. * - * Returns 0 when the domain is free. Returns -1 if a timeout - * occurred waiting for the completion. + * Return: 0 when the domain is free. Returns -1 if a timeout occurred waiting + * for the completion. */ int psc_wait(u32 domain_num) { @@ -59,6 +62,10 @@ int psc_wait(u32 domain_num) return 0; }
+/** + * psc_get_domain_num() - Get the domain number + * @mod_num: LPSC module number + */ u32 psc_get_domain_num(u32 mod_num) { u32 domain_num; @@ -70,20 +77,19 @@ u32 psc_get_domain_num(u32 mod_num) return domain_num; }
-/* - * FUNCTION PURPOSE: Power up/down a module +/** + * psc_set_state() - powers up/down a module + * @mod_num: LPSC module number + * @state: 1 to enable, 0 to disable. * - * DESCRIPTION: Powers up/down the requested module and the associated power - * domain if required. No action is taken it the module is - * already powered up/down. + * Powers up/down the requested module and the associated power domain if + * required. No action is taken it the module is already powered up/down. + * This only controls modules. The domain in which the module resides will + * be left in the power on state. Multiple modules can exist in a power + * domain, so powering down the domain based on a single module is not done. * - * This only controls modules. The domain in which the module - * resides will be left in the power on state. Multiple modules - * can exist in a power domain, so powering down the domain based - * on a single module is not done. - * - * Returns 0 on success, -1 if the module can't be powered up, or - * if there is a timeout waiting for the transition. + * Return: 0 on success, -1 if the module can't be powered up, or if there is a + * timeout waiting for the transition. */ int psc_set_state(u32 mod_num, u32 state) { @@ -136,15 +142,16 @@ int psc_set_state(u32 mod_num, u32 state) return psc_wait(domain_num); }
-/* - * FUNCTION PURPOSE: Power up a module +/** + * psc_enable_module() - power up a module + * @mod_num: LPSC module number * - * DESCRIPTION: Powers up the requested module and the associated power domain - * if required. No action is taken it the module is already - * powered up. + * Powers up the requested module and the associated power domain + * if required. No action is taken it the module is already powered up. + * + * Return: 0 on success, -1 if the module can't be powered up, or + * if there is a timeout waiting for the transition. * - * Returns 0 on success, -1 if the module can't be powered up, or - * if there is a timeout waiting for the transition. */ int psc_enable_module(u32 mod_num) { @@ -158,12 +165,11 @@ int psc_enable_module(u32 mod_num) return psc_set_state(mod_num, PSC_REG_VAL_MDCTL_NEXT_ON); }
-/* - * FUNCTION PURPOSE: Power down a module +/** + * psc_disable_module() - Power down a module + * @mod_num: LPSC module number * - * DESCRIPTION: Powers down the requested module. - * - * Returns 0 on success, -1 on failure or timeout. + * Return: 0 on success, -1 on failure or timeout. */ int psc_disable_module(u32 mod_num) { @@ -179,13 +185,16 @@ int psc_disable_module(u32 mod_num) return psc_set_state(mod_num, PSC_REG_VAL_MDCTL_NEXT_SWRSTDISABLE); }
-/* - * FUNCTION PURPOSE: Set the reset isolation bit in mdctl +/** + * psc_set_reset_iso() - Set the reset isolation bit in mdctl + * @mod_num: LPSC module number * - * DESCRIPTION: The reset isolation enable bit is set. The state of the module - * is not changed. Returns 0 if the module config showed that - * reset isolation is supported. Returns 1 otherwise. This is not - * an error, but setting the bit in mdctl has no effect. + * The reset isolation enable bit is set. The state of the module is not + * changed. + * + * Return: 0 if the module config showed that reset isolation is supported. + * Returns 1 otherwise. This is not an error, but setting the bit in mdctl + * has no effect. */ int psc_set_reset_iso(u32 mod_num) { @@ -204,10 +213,9 @@ int psc_set_reset_iso(u32 mod_num) return 1; }
-/* - * FUNCTION PURPOSE: Disable a power domain - * - * DESCRIPTION: The power domain is disabled +/** + * psc_disable_domain() - Disable a power domain + * @domain_num: GPSC domain number */ int psc_disable_domain(u32 domain_num) {

On Thu, Feb 25, 2016 at 12:53:42PM -0600, Nishanth Menon wrote:
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 nm@ti.com
Reviewed-by: Tom Rini trini@konsulko.com

On Thu, Feb 25, 2016 at 12:53:42PM -0600, Nishanth Menon wrote:
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 nm@ti.com Reviewed-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!

'#define X a | b' is better defined as '#define X (a | b)' for obvious reasons.
Signed-off-by: Nishanth Menon nm@ti.com --- V2: No change V1: https://patchwork.ozlabs.org/patch/510211/ arch/arm/mach-keystone/include/mach/psc_defs.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-keystone/include/mach/psc_defs.h b/arch/arm/mach-keystone/include/mach/psc_defs.h index 70d22cf21787..2202946be5ea 100644 --- a/arch/arm/mach-keystone/include/mach/psc_defs.h +++ b/arch/arm/mach-keystone/include/mach/psc_defs.h @@ -30,9 +30,9 @@ #define BOOTBITMASK(x, y) ((((((u32)1 << (((u32)x) - ((u32)y) + (u32)1)) - \ (u32)1)) << ((u32)y)))
-#define BOOT_READ_BITFIELD(z, x, y) (((u32)z) & BOOTBITMASK(x, y)) >> (y) -#define BOOT_SET_BITFIELD(z, f, x, y) (((u32)z) & ~BOOTBITMASK(x, y)) | \ - ((((u32)f) << (y)) & BOOTBITMASK(x, y)) +#define BOOT_READ_BITFIELD(z, x, y) ((((u32)z) & BOOTBITMASK(x, y)) >> (y)) +#define BOOT_SET_BITFIELD(z, f, x, y) ((((u32)z) & ~BOOTBITMASK(x, y)) | \ + ((((u32)f) << (y)) & BOOTBITMASK(x, y)))
/* PDCTL */ #define PSC_REG_PDCTL_SET_NEXT(x, y) BOOT_SET_BITFIELD((x), (y), 0, 0)

On Thu, Feb 25, 2016 at 12:53:43PM -0600, Nishanth Menon wrote:
'#define X a | b' is better defined as '#define X (a | b)' for obvious reasons.
Signed-off-by: Nishanth Menon nm@ti.com
Reviewed-by: Tom Rini trini@konsulko.com
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.

On Fri, Feb 26, 2016 at 12:17 PM, Tom Rini trini@konsulko.com wrote:
On Thu, Feb 25, 2016 at 12:53:43PM -0600, Nishanth Menon wrote:
'#define X a | b' is better defined as '#define X (a | b)' for obvious reasons.
Signed-off-by: Nishanth Menon nm@ti.com
Reviewed-by: Tom Rini trini@konsulko.com
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.
I will try and give it a shot and repost - yeah - it was pretty convoluted in the first place might be changing it to a static inline might be a simpler approach..

On Thu, Feb 25, 2016 at 12:53:43PM -0600, Nishanth Menon wrote:
'#define X a | b' is better defined as '#define X (a | b)' for obvious reasons.
Signed-off-by: Nishanth Menon nm@ti.com Reviewed-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!

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 nm@ti.com --- V2: no change V1: https://patchwork.ozlabs.org/patch/510209/ arch/arm/mach-keystone/include/mach/psc_defs.h | 4 + arch/arm/mach-keystone/psc.c | 104 +++++++++++++++++++++++++ 2 files changed, 108 insertions(+)
diff --git a/arch/arm/mach-keystone/include/mach/psc_defs.h b/arch/arm/mach-keystone/include/mach/psc_defs.h index 2202946be5ea..6e6e7fd433a1 100644 --- a/arch/arm/mach-keystone/include/mach/psc_defs.h +++ b/arch/arm/mach-keystone/include/mach/psc_defs.h @@ -56,6 +56,8 @@ #define PSC_REG_MDSTAT_GET_STATUS(x) BOOT_READ_BITFIELD((x), 5, 0) #define PSC_REG_MDSTAT_GET_LRSTZ(x) BOOT_READ_BITFIELD((x), 8, 8) #define PSC_REG_MDSTAT_GET_LRSTDONE(x) BOOT_READ_BITFIELD((x), 9, 9) +#define PSC_REG_MDSTAT_GET_MRSTZ(x) BOOT_READ_BITFIELD((x), 10, 10) +#define PSC_REG_MDSTAT_GET_MRSTDONE(x) BOOT_READ_BITFIELD((x), 11, 11)
/* PDCTL states */ #define PSC_REG_VAL_PDCTL_NEXT_ON 1 @@ -86,5 +88,7 @@ u32 psc_get_domain_num(u32 mod_num); int psc_enable_module(u32 mod_num); int psc_disable_module(u32 mod_num); int psc_disable_domain(u32 domain_num); +int psc_module_keep_in_reset_enabled(u32 mod_num, bool gate_clocks); +int psc_module_release_from_reset(u32 mod_num);
#endif /* _PSC_DEFS_H_ */ diff --git a/arch/arm/mach-keystone/psc.c b/arch/arm/mach-keystone/psc.c index 8991e237735e..ff042a6db2dd 100644 --- a/arch/arm/mach-keystone/psc.c +++ b/arch/arm/mach-keystone/psc.c @@ -233,3 +233,107 @@ int psc_disable_domain(u32 domain_num)
return psc_wait(domain_num); } + +/** + * psc_module_keep_in_reset_enabled() - Keep module in enabled,in-reset state + * @mod_num: LPSC module number + * @gate_clocks: Can the clocks be gated on this module? + * + * Enable the module, but do not release the module from local reset. This is + * necessary for many processor systems on keystone SoCs to allow for system + * initialization from a master processor prior to releasing the processor + * from reset. + */ +int psc_module_keep_in_reset_enabled(u32 mod_num, bool gate_clocks) +{ + u32 mdctl, ptcmd, mdstat; + u32 next_state; + int domain_num = psc_get_domain_num(mod_num); + int timeout = 100000; + + /* Wait for any previous transitions to complete */ + psc_wait(domain_num); + mdctl = __raw_readl(KS2_PSC_BASE + PSC_REG_MDCTL(mod_num)); + /* Should be set 0 to assert Local reset */ + if ((mdctl & PSC_REG_MDCTL_SET_LRSTZ(mdctl, 1))) { + mdctl = PSC_REG_MDCTL_SET_LRSTZ(mdctl, 0); + __raw_writel(mdctl, KS2_PSC_BASE + PSC_REG_MDCTL(mod_num)); + /* Wait for transition to take place */ + psc_wait(domain_num); + } + + /* Clear Module reset */ + mdctl = __raw_readl(KS2_PSC_BASE + PSC_REG_MDCTL(mod_num)); + next_state = gate_clocks ? PSC_REG_VAL_MDCTL_NEXT_OFF : + PSC_REG_VAL_MDCTL_NEXT_ON; + mdctl = PSC_REG_MDCTL_SET_NEXT(mdctl, next_state); + __raw_writel(mdctl, KS2_PSC_BASE + PSC_REG_MDCTL(mod_num)); + /* Trigger PD transition */ + ptcmd = __raw_readl(KS2_PSC_BASE + PSC_REG_PTCMD); + ptcmd |= (u32)(1 << domain_num); + __raw_writel(ptcmd, KS2_PSC_BASE + PSC_REG_PTCMD); + psc_wait(domain_num); + + mdstat = __raw_readl(KS2_PSC_BASE + PSC_REG_MDSTAT(mod_num)); + while (timeout) { + mdstat = __raw_readl(KS2_PSC_BASE + PSC_REG_MDSTAT(mod_num)); + + if (!(PSC_REG_MDSTAT_GET_STATUS(mdstat) & 0x30) && + PSC_REG_MDSTAT_GET_MRSTDONE(mdstat) && + PSC_REG_MDSTAT_GET_LRSTDONE(mdstat)) + break; + timeout--; + } + + if (!timeout) { + printf("%s: Timedout waiting for mdstat(0x%08x) to change\n", + __func__, mdstat); + return -ETIMEDOUT; + } + return 0; +} + +/** + * psc_module_release_from_reset() - Release the module from reset + * @mod_num: LPSC module number + * + * This is the follow through for the command 'psc_module_keep_in_reset_enabled' + * Allowing the module to be released from reset once all required inits are + * complete for the module. Typically, this allows the processor module to start + * execution. + */ +int psc_module_release_from_reset(u32 mod_num) +{ + u32 mdctl, mdstat; + int domain_num = psc_get_domain_num(mod_num); + int timeout = 100000; + + /* Wait for any previous transitions to complete */ + psc_wait(domain_num); + mdctl = __raw_readl(KS2_PSC_BASE + PSC_REG_MDCTL(mod_num)); + /* Should be set to 1 to de-assert Local reset */ + if ((mdctl & PSC_REG_MDCTL_SET_LRSTZ(mdctl, 0))) { + mdctl = PSC_REG_MDCTL_SET_LRSTZ(mdctl, 1); + __raw_writel(mdctl, KS2_PSC_BASE + PSC_REG_MDCTL(mod_num)); + /* Wait for transition to take place */ + psc_wait(domain_num); + } + mdstat = __raw_readl(KS2_PSC_BASE + PSC_REG_MDSTAT(mod_num)); + while (timeout) { + mdstat = __raw_readl(KS2_PSC_BASE + PSC_REG_MDSTAT(mod_num)); + + if (!(PSC_REG_MDSTAT_GET_STATUS(mdstat) & 0x30) && + PSC_REG_MDSTAT_GET_MRSTDONE(mdstat) && + PSC_REG_MDSTAT_GET_LRSTDONE(mdstat)) + break; + timeout--; + } + + if (!timeout) { + printf("%s: Timedout waiting for mdstat(0x%08x) to change\n", + __func__, mdstat); + return -ETIMEDOUT; + } + + return 0; +}

On Thu, Feb 25, 2016 at 12:53:44PM -0600, Nishanth Menon wrote:
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 nm@ti.com
Reviewed-by: Tom Rini trini@konsulko.com

On Thu, Feb 25, 2016 at 12:53:44PM -0600, Nishanth Menon wrote:
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 nm@ti.com Reviewed-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!

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 nm@ti.com --- V2: - updated to be dt based and no support for older platform data style drivers. we dont need it anymore. - few minor functional bugfixes incorporated V1: https://patchwork.ozlabs.org/patch/510212/
drivers/remoteproc/Kconfig | 10 +++ drivers/remoteproc/Makefile | 1 + drivers/remoteproc/ti_power_proc.c | 180 +++++++++++++++++++++++++++++++++++++ 3 files changed, 191 insertions(+) create mode 100644 drivers/remoteproc/ti_power_proc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig index 437224b5491f..d0b76be1188e 100644 --- a/drivers/remoteproc/Kconfig +++ b/drivers/remoteproc/Kconfig @@ -21,4 +21,14 @@ config REMOTEPROC_SANDBOX help Say 'y' here to add support for test processor which does dummy operations for sandbox platform. + +config REMOTEPROC_TI_POWER + bool "Support for TI Power processor" + select REMOTEPROC + depends on DM + depends on ARCH_KEYSTONE + depends on OF_CONTROL + help + Say 'y' here to add support for TI power processors such as those + found on certain TI keystone and OMAP generation SoCs. endmenu diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile index 720aa6e64701..65fc0613de89 100644 --- a/drivers/remoteproc/Makefile +++ b/drivers/remoteproc/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_REMOTEPROC) += rproc-uclass.o
# Remote proc drivers - Please keep this list alphabetically sorted. obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o +obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o diff --git a/drivers/remoteproc/ti_power_proc.c b/drivers/remoteproc/ti_power_proc.c new file mode 100644 index 000000000000..76ac3be092e2 --- /dev/null +++ b/drivers/remoteproc/ti_power_proc.c @@ -0,0 +1,180 @@ +/* + * (C) Copyright 2015-2016 + * Texas Instruments Incorporated - http://www.ti.com/ + * SPDX-License-Identifier: GPL-2.0+ + */ +#define pr_fmt(fmt) "%s: " fmt, __func__ +#include <common.h> +#include <dm.h> +#include <errno.h> +#include <fdtdec.h> +#include <remoteproc.h> +#include <mach/psc_defs.h> + +DECLARE_GLOBAL_DATA_PTR; + +/** + * struct ti_powerproc_privdata - power processor private data + * @loadaddr: base address for loading the power processor + * @psc_module: psc module address. + */ +struct ti_powerproc_privdata { + phys_addr_t loadaddr; + u32 psc_module; +}; + +/** + * ti_of_to_priv() - generate private data from device tree + * @dev: corresponding ti remote processor device + * @priv: pointer to driver specific private data + * + * Return: 0 if all went ok, else corresponding -ve error + */ +static int ti_of_to_priv(struct udevice *dev, + struct ti_powerproc_privdata *priv) +{ + int node = dev->of_offset; + const void *blob = gd->fdt_blob; + int tmp; + + if (!blob) { + debug("'%s' no dt?\n", dev->name); + return -EINVAL; + } + + priv->loadaddr = fdtdec_get_addr(blob, node, "reg"); + if (priv->loadaddr == FDT_ADDR_T_NONE) { + debug("'%s': no 'reg' property\n", dev->name); + return -EINVAL; + } + + tmp = fdtdec_get_int(blob, node, "ti,lpsc_module", -EINVAL); + if (tmp < 0) { + debug("'%s': no 'ti,lpsc_module' property\n", dev->name); + return tmp; + } + priv->psc_module = tmp; + + return 0; +} + +/** + * ti_powerproc_probe() - Basic probe + * @dev: corresponding ti remote processor device + * + * Return: 0 if all went ok, else corresponding -ve error + */ +static int ti_powerproc_probe(struct udevice *dev) +{ + struct dm_rproc_uclass_pdata *uc_pdata; + struct ti_powerproc_privdata *priv; + int ret; + + uc_pdata = dev_get_uclass_platdata(dev); + priv = dev_get_priv(dev); + + ret = ti_of_to_priv(dev, priv); + + debug("%s probed with slave_addr=0x%08lX module=%d(%d)\n", + uc_pdata->name, priv->loadaddr, priv->psc_module, ret); + + return ret; +} + +/** + * ti_powerproc_load() - Loadup the TI remote processor + * @dev: corresponding ti remote processor device + * @addr: Address in memory where image binary is stored + * @size: Size in bytes of the image binary + * + * Return: 0 if all went ok, else corresponding -ve error + */ +static int ti_powerproc_load(struct udevice *dev, ulong addr, ulong size) +{ + struct dm_rproc_uclass_pdata *uc_pdata; + struct ti_powerproc_privdata *priv; + int ret; + + uc_pdata = dev_get_uclass_platdata(dev); + if (!uc_pdata) { + debug("%s: no uc pdata!\n", dev->name); + return -EINVAL; + } + + priv = dev_get_priv(dev); + ret = psc_module_keep_in_reset_enabled(priv->psc_module, false); + if (ret) { + debug("%s Unable to disable module '%d'(ret=%d)\n", + uc_pdata->name, priv->psc_module, ret); + return ret; + } + + debug("%s: Loading binary from 0x%08lX, size 0x%08lX to 0x%08lX\n", + uc_pdata->name, addr, size, priv->loadaddr); + + memcpy((void *)priv->loadaddr, (void *)addr, size); + + debug("%s: Complete!\n", uc_pdata->name); + return 0; +} + +/** + * ti_powerproc_start() - (replace: short desc) + * @dev: corresponding ti remote processor device + * + * Return: 0 if all went ok, else corresponding -ve error + */ +static int ti_powerproc_start(struct udevice *dev) +{ + struct dm_rproc_uclass_pdata *uc_pdata; + struct ti_powerproc_privdata *priv; + int ret; + + uc_pdata = dev_get_uclass_platdata(dev); + if (!uc_pdata) { + debug("%s: no uc pdata!\n", dev->name); + return -EINVAL; + } + + priv = dev_get_priv(dev); + ret = psc_disable_module(priv->psc_module); + if (ret) { + debug("%s Unable to disable module '%d'(ret=%d)\n", + uc_pdata->name, priv->psc_module, ret); + return ret; + } + + ret = psc_module_release_from_reset(priv->psc_module); + if (ret) { + debug("%s Failed to wait for module '%d'(ret=%d)\n", + uc_pdata->name, priv->psc_module, ret); + return ret; + } + ret = psc_enable_module(priv->psc_module); + if (ret) { + debug("%s Unable to disable module '%d'(ret=%d)\n", + uc_pdata->name, priv->psc_module, ret); + return ret; + } + + return 0; +} + +static const struct dm_rproc_ops ti_powerproc_ops = { + .load = ti_powerproc_load, + .start = ti_powerproc_start, +}; + +static const struct udevice_id ti_powerproc_ids[] = { + {.compatible = "ti,power-processor"}, + {} +}; + +U_BOOT_DRIVER(ti_powerproc) = { + .name = "ti_power_proc", + .of_match = ti_powerproc_ids, + .id = UCLASS_REMOTEPROC, + .ops = &ti_powerproc_ops, + .probe = ti_powerproc_probe, + .priv_auto_alloc_size = sizeof(struct ti_powerproc_privdata), +};

On Thu, Feb 25, 2016 at 12:53:45PM -0600, Nishanth Menon wrote:
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 nm@ti.com
Reviewed-by: Tom Rini trini@konsulko.com

On Thu, Feb 25, 2016 at 12:53:45PM -0600, Nishanth Menon wrote:
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 nm@ti.com Reviewed-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!

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(+)
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>; + }; + }; };

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?

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.

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

... adding in devicetree-spec, http://lists.denx.de/pipermail/u-boot/2016-February/246542.html for the first part of this
On Fri, Feb 26, 2016 at 07:10:23PM -0600, Nishanth Menon wrote:
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..
So, I would like to see this particular bit stay in the DT, and I would like to see this part of the DT not be only in the U-Boot tree but rather the authorative DT which today resides in the Linux kernel. But I'm not the person to make that final call, so adding in more people here.

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
Applied to u-boot/master, thanks!

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 nm@ti.com ---
V1: did not exist.
configs/k2g_evm_defconfig | 2 ++ include/configs/k2g_evm.h | 7 +++++++ include/configs/ti_armv7_keystone2.h | 14 ++++++++++++++ 3 files changed, 23 insertions(+)
diff --git a/configs/k2g_evm_defconfig b/configs/k2g_evm_defconfig index 7cebacd035c9..a66d75fde15a 100644 --- a/configs/k2g_evm_defconfig +++ b/configs/k2g_evm_defconfig @@ -4,6 +4,8 @@ CONFIG_TARGET_K2G_EVM=y CONFIG_DM_SERIAL=y CONFIG_DEFAULT_DEVICE_TREE="k2g-evm" CONFIG_SPL=y +CONFIG_CMD_REMOTEPROC=y +CONFIG_REMOTEPROC_TI_POWER=y # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set # CONFIG_CMD_SETEXPR is not set diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h index d9ad8cf4b4d8..ca1e368aa010 100644 --- a/include/configs/k2g_evm.h +++ b/include/configs/k2g_evm.h @@ -17,6 +17,7 @@ /* U-Boot general configuration */ #define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS \ DEFAULT_MMC_TI_ARGS \ + DEFAULT_PMMC_BOOT_ENV \ "console=ttyS0,115200n8\0" \ "bootpart=0:2\0" \ "bootdir=/boot\0" \ @@ -28,11 +29,17 @@ "name_ubi=k2g-evm-ubifs.ubi\0" \ "name_uboot=u-boot-spi-k2g-evm.gph\0" \ "init_mmc=run args_all args_mmc\0" \ + "soc_variant=k2g\0" \ "get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}\0"\ "get_kern_mmc=load mmc ${bootpart} ${loadaddr} " \ "${bootdir}/${name_kern}\0" \ "get_mon_mmc=load mmc ${bootpart} ${addr_mon} ${bootdir}/${name_mon}\0"\
+#define CONFIG_BOOTCOMMAND \ + "run set_name_pmmc init_${boot} get_pmmc_${boot} run_pmmc " \ + "get_fdt_${boot} get_mon_${boot} get_kern_${boot} " \ + "run_mon run_kern" + #include <configs/ti_armv7_keystone2.h>
/* SPL SPI Loader Configuration */ diff --git a/include/configs/ti_armv7_keystone2.h b/include/configs/ti_armv7_keystone2.h index a7206f4beab0..70a484e4222b 100644 --- a/include/configs/ti_armv7_keystone2.h +++ b/include/configs/ti_armv7_keystone2.h @@ -223,6 +223,18 @@ /* EDMA3 */ #define CONFIG_TI_EDMA3
+#define DEFAULT_PMMC_BOOT_ENV \ + "set_name_pmmc=setenv name_pmmc ti-sci-firmware-${soc_variant}.bin\0" \ + "dev_pmmc=0\0" \ + "get_pmmc_net=dhcp ${loadaddr} ${tftp_root}/${name_pmmc}\0" \ + "get_pmmc_ramfs=run get_pmmc_net\0" \ + "get_pmmc_mmc=load mmc ${bootpart} ${loadaddr} " \ + "${bootdir}/${name_pmmc}\0" \ + "get_pmmc_ubi=ubifsload ${loadaddr} ${bootdir}/${name_pmmc}\0" \ + "run_pmmc=rproc init; rproc list; " \ + "rproc load ${dev_pmmc} ${loadaddr} 0x${filesize}; " \ + "rproc start ${dev_pmmc}\0" \ + #define CONFIG_EXTRA_ENV_SETTINGS \ DEFAULT_LINUX_BOOT_ENV \ CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS \ @@ -271,9 +283,11 @@ "mtdparts=mtdparts=davinci_nand.0:" \ "1024k(bootloader)ro,512k(params)ro,-(ubifs)\0"
+#ifndef CONFIG_BOOTCOMMAND #define CONFIG_BOOTCOMMAND \ "run init_${boot} get_fdt_${boot} get_mon_${boot} " \ "get_kern_${boot} run_mon run_kern" +#endif
#define CONFIG_BOOTARGS \

On Thu, Feb 25, 2016 at 12:53:47PM -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.
Signed-off-by: Nishanth Menon nm@ti.com
Reviewed-by: Tom Rini trini@konsulko.com

On Thu, Feb 25, 2016 at 12:53:47PM -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.
Signed-off-by: Nishanth Menon nm@ti.com Reviewed-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
participants (2)
-
Nishanth Menon
-
Tom Rini