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

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

[Nishanth Menon]

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

-- 
2.7.0

[U-Boot] [PATCH V2 1/6] ARM: keystone2: psc: redo doc in kernel-doc format

[Nishanth Menon]

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)
 {
-- 
2.7.0

[U-Boot] [PATCH V2 2/6] ARM: keystone2: psc-defs: use adequate () for macros

[Nishanth Menon]

'#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)
-- 
2.7.0

[U-Boot] [PATCH V2 3/6] ARM: keystone2: psc: introduce function to hold and release module in reset.

[Nishanth Menon]

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;
+}
-- 
2.7.0

[U-Boot] [PATCH V2 4/6] remoteproc: Add support for TI power processor

[Nishanth Menon]

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

[U-Boot] [PATCH V2 5/6] ARM: dts: k2g: Add support for PMMC

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

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 at 2900000 {
+			compatible = "ti,power-processor";
+			reg = <0x02900000 0x40000>;
+			ti,lpsc_module = <1>;
+		};
+
 	};
 };
-- 
2.7.0

[U-Boot] [PATCH V2 6/6] configs: k2g_evm: Add TI power processor support

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

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

[U-Boot] [PATCH V2 1/6] ARM: keystone2: psc: redo doc in kernel-doc format

[Tom Rini]

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>

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160226/6c4456c7/attachment.sig>

[U-Boot] [PATCH V2 2/6] ARM: keystone2: psc-defs: use adequate () for macros

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160226/1ee2f705/attachment.sig>

[U-Boot] [PATCH V2 3/6] ARM: keystone2: psc: introduce function to hold and release module in reset.

[Tom Rini]

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>

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160226/5b7fc4e6/attachment.sig>

[U-Boot] [PATCH V2 4/6] remoteproc: Add support for TI power processor

[Tom Rini]

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>

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160226/c94bbcea/attachment.sig>

[U-Boot] [PATCH V2 5/6] ARM: dts: k2g: Add support for PMMC

[Tom Rini]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160226/a1db3cd9/attachment.sig>

[U-Boot] [PATCH V2 6/6] configs: k2g_evm: Add TI power processor support

[Tom Rini]

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>

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160226/39a6296a/attachment.sig>

[U-Boot] [PATCH V2 2/6] ARM: keystone2: psc-defs: use adequate () for macros

[Nishanth Menon]

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


-- 
---
Regards,
Nishanth Menon

[U-Boot] [PATCH V2 5/6] ARM: dts: k2g: Add support for PMMC

[Nishanth Menon]

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] [PATCH V2 5/6] ARM: dts: k2g: Add support for PMMC

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160226/c795b034/attachment.sig>

[U-Boot] [PATCH V2 5/6] ARM: dts: k2g: Add support for PMMC

[Nishanth Menon]

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] [PATCH V2 5/6] ARM: dts: k2g: Add support for PMMC

[Tom Rini]

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

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160304/28ea72d1/attachment.sig>

Re: [U-Boot] [PATCH V2 5/6] ARM: dts: k2g: Add support for PMMC

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3563 bytes --]

... 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-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 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-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 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.

-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[U-Boot] [U-Boot, V2, 1/6] ARM: keystone2: psc: redo doc in kernel-doc format

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160315/667cd702/attachment.sig>

[U-Boot] [U-Boot, V2, 2/6] ARM: keystone2: psc-defs: use adequate () for macros

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160315/e8acea6a/attachment.sig>

[U-Boot] [U-Boot, V2, 3/6] ARM: keystone2: psc: introduce function to hold and release module in reset.

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160315/6af3d53b/attachment.sig>

[U-Boot] [U-Boot, V2, 4/6] remoteproc: Add support for TI power processor

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160315/b8d7bf8b/attachment.sig>

[U-Boot] [U-Boot,V2,5/6] ARM: dts: k2g: Add support for PMMC

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160315/3997ea21/attachment.sig>

[U-Boot] [U-Boot, V2, 6/6] configs: k2g_evm: Add TI power processor support

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160315/fb5360fe/attachment.sig>