Fix remaining issues to drop more omap platform data

Hi all,

Here's v4 of the remaining fixes needed before we can drop omap hwmod platform data for interrupts, dma channels and IO ranges.

I've dropped the clockctrl clock nodes and dts patches to avoid a dependency to Tero's pending clock patches. As we are still relying on "ti,hwmods" property this is just fine, and can be patched later once the dependencies have cleared.

These patches are based on current Linux next.

Regards,

Tony

Changes since v3:

- Use sysc compatible names based on the SoC name where they are first seen instead of type1/2/3 as suggested by Matthijs

- Use "fck" and "ick" naming instead of "clkctrl" for clocks as we will need the interface clock too in many cases, and udpate the ti-sysc driver accordingly

- Drop the clock nodes for now to avoid a dependency to pending clock patches, the clock nodes can be added later on after the dependencies have cleared

Changes since v2:

- Drop attempted bindings for devices with no drivers and start using generic ti sysc interconnect target module binding, the bindings for the child devices can be sent separately as needed

- Add Tero's pathces for omap4 clkctrl nodes as we need those

- Add support for parsing IO ranges from dts if "ti,hwmods" is set and fix-up omap device code to work without platform data for legacy dma and smartreflex

- Add minimal ti-sysc driver

Changes since v1:

- Updated hsi, iss, fdif, gpu, and smartreflex patches based on the subsystem maintainer comments

- Added Rob and Mark in Cc for the patches touching binding documentation

Tony Lindgren (7):
dt-bindings: bus: Minimal TI sysc interconnect target module binding
ARM: OMAP2+: Parse module IO range from dts for legacy "ti,hwmods"
support
ARM: OMAP2+: Populate legacy resources for dma and smartreflex
bus: ti-sysc: Add minimal TI sysc interconnect target driver
ARM: dts: Add nodes for missing omap4 interconnect target modules
ARM: dts: Configure SmartReflex only to idle the interconnect target
module
ARM: dts: Use ti-sysc module driver for omap4 musb

 Documentation/devicetree/bindings/bus/ti-sysc.txt |  93 ++++
 arch/arm/boot/dts/dra7.dtsi                       |  26 +
 arch/arm/boot/dts/omap4.dtsi                      | 195 +++++++-
 arch/arm/mach-omap2/Kconfig                       |   1 +
 arch/arm/mach-omap2/omap_device.c                 | 137 ++++--
 arch/arm/mach-omap2/omap_device.h                 |   4 -
 arch/arm/mach-omap2/omap_hwmod.c                  |  80 +++-
 arch/arm/mach-omap2/omap_hwmod.h                  |   5 +
 drivers/bus/Kconfig                               |   7 +
 drivers/bus/Makefile                              |   1 +
 drivers/bus/ti-sysc.c                             | 558 ++++++++++++++++++++++
 11 files changed, 1047 insertions(+), 60 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/bus/ti-sysc.txt
 create mode 100644 drivers/bus/ti-sysc.c

2.14.2

With the recently introduced omap clkctrl module binding, we can start moving omap hwmod data to device tree and drivers from arch/arm/mach-omap2.

To start doing this, let's introduce a device tree binding for TI sysc interconnect target module hardware. The sysc manages module clocks, idlemodes and interconnect level resets. Each interconnect target module can have one or more child devices connected to it.

TI sysc interconnect target module hardware is independent of the interconnect. It is used at least with TI L3 interconnect (Arteris NoC) and TI L4 interconnect (Sonics s3220). The sysc is mostly used for interaction between module and PRCM. It participates in the OCP Disconnect Protocol but other than that is mostly indepenent of the interconnect.

As all the features may not be supported for a given sysc module, we need to use device tree configuration for the revision of the interconnect target module.

Note that the interconnect target module control registers are always sprinked at varying locations in the unused address space of the first child device IP block. To avoid device tree reg conflicts, the sysc device provides ranges for it's children.

For a non-intrusive transition from static hwmod data to using device tree defined TI interconnect target module binding, we can keep things working with static hwmod data if device tree property "ti,hwmods" is specified for the the interconnect target module.

Note that additional properties for sysc capabilities will be added later on. For now, we can already use this binding for interconnect target modules that do not have any child device drivers available. This allows us to idle the unused interconnect target modules during init without the need for legacy hwmod platform data for doing it.

---
 Documentation/devicetree/bindings/bus/ti-sysc.txt | 93 +++++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/ti-sysc.txt

new file mode 100644
@@ -0,0 +1,93 @@
+Texas Instruments sysc interconnect target module wrapper binding
+
+Texas Instruments SoCs can have a generic interconnect target module
+hardware for devices connected to various interconnects such as L3
+interconnect (Arteris NoC) and L4 interconnect (Sonics s3220). The sysc
+is mostly used for interaction between module and PRCM. It participates
+in the OCP Disconnect Protocol but other than that is mostly indepenent
+of the interconnect.
+
+Each interconnect target module can have one or more devices connected to
+it. There is a set of control registers for managing interconnect target
+module clocks, idle modes and interconnect level resets for the module.
+
+These control registers are sprinkled into the unused register address
+space of the first child device IP block managed by the interconnect
+target module and typically are named REVISION, SYSCONFIG and SYSSTATUS.
+
+Required standard properties:
+
+- compatible	shall be one of the following generic types:
+
+		"ti,sysc-omap2"
+		"ti,sysc-omap4"
+		"ti,sysc-omap4-simple"
+
+		or one of the following derivative types for hardware
+		needing special workarounds:
+
+		"ti,sysc-omap3430-sr"
+		"ti,sysc-omap3630-sr"
+		"ti,sysc-omap4-sr"
+		"ti,sysc-omap3-sham"
+		"ti,sysc-omap-aes"
+		"ti,sysc-mcasp"
+		"ti,sysc-usb-host-fs"
+
+- reg		shall have register areas implemented for the interconnect
+		target module in question such as revision, sysc and syss
+
+- reg-names	shall contain the register names implemented for the
+		interconnect target module in question such as
+		"rev, "sysc", and "syss"
+
+- ranges	shall contain the interconnect target module IO range
+		available for one or more child device IP blocks managed
+		by the interconnect target module, the ranges may include
+		multiple ranges such as device L4 range for control and
+		parent L3 range for DMA access
+
+Optional properties:
+
+- clocks	clock specifier for each name in the clock-names as
+		specified in the binding documentation for ti-clkctrl,
+		typically available for all interconnect targets on TI SoCs
+		based on omap4 except if it's read-only register in hwauto
+		mode as for example omap4 L4_CFG_CLKCTRL
+
+- clock-names	should contain at least "fck", and optionally also "ick"
+		depending on the SoC and the interconnect target module
+
+- ti,hwmods	optional TI interconnect module name to use legacy
+		hwmod platform data
+
+
+Example: Single instance of MUSB controller on omap4 using interconnect ranges
+using offsets from l4_cfg second segment (0x4a000000 + 0x80000 = 0x4a0ab000):
+
+	target-module at 2b000 {		/* 0x4a0ab000, ap 84 12.0 */
+		compatible = "ti,sysc-omap2";
+		ti,hwmods = "usb_otg_hs";
+		reg = <0x2b400 0x4>,
+		      <0x2b404 0x4>,
+		      <0x2b408 0x4>;
+		reg-names = "rev", "sysc", "syss";
+		clocks = <&l3_init_clkctrl OMAP4_USB_OTG_HS_CLKCTRL 0>;
+		clock-names = "fck";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0x2b000 0x1000>;
+
+		usb_otg_hs: otg at 0 {
+			compatible = "ti,omap4-musb";
+			reg = <0x0 0x7ff>;
+			interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
+			usb-phy = <&usb2_phy>;
+			...
+		};
+	};
+
+Note that other SoCs, such as am335x can have multipe child devices. On am335x
+there are two MUSB instances, two USB PHY instances, and a single CPPI41 DMA
+instance as children of a single interconnet target module.

2.14.2

Hi,

DT backwards compatibility is about booting an old DT file with a newer kernel. Since old DT file does not contain a "ti,sysc-omap*" node you don't need to add "ti,hwmod = *" support to it. Instead a DT file, that uses ti,hwmod in the device node and does not have a "ti,sysc-omap*" at all should still work.

IMHO we should break DT ABI for OMAP at some point, so that we can get rid of the hwmod database. My suggestion would be, that simple-bus checks if any child device is != "ti,omap-sysc*" and does panic("please update DT!").

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171001/ddc1f844/attachment.sig>

Not sure if I parse that right, but I'm assuming you suggest leaving out ti,hwmod to start with. Well I considered that, but it causes the "waiting for a magical flip issue". So initially we need to use both ti,sysc and ti,hwmod until ti,sysc alone has the equal functionality. That's because then we can do the following steps:

1. We want to add compatible = ti,sysc so we can define the nodes and get the parent-children hierarhcy right. We can already use the parent-child features even with ti,hwmods before we have complete dts based data. We are currently missing that capability without doing device specific parent drivers like we do with drivers/usb/musb/musb_am335x.c. Note that in this step we are moving the ti,hwmod to the parent node

2. When ti,sysc can configure things based on dts data alone the same way as the legacy platform data, we can just drop the ti,hwmod property. We also want to be able to test one driver at a time between ti,sysc + ti,hwmod vs ti,sysc only

3. Once ti,hwmod properties have been removed from the mainline kernel, we can add a warning about ti,hwmod properties being deprecated

4. Then later on, we can also drop the hwmod platform data and continue produce warnings if ti,hwmod is seen

Yes we can eventually drop the static data and ti,hwmod while providing helpful information to the users.

Regards,

Tony

Hi,

Ok, I misunderstood the reason for keeping/adding "ti,hwmod". I thought it was only about keeping backwards compatibility, but it's still required since hwmod is only partially converted to DT by this patchset.

That basically means, that this patchset breaks DT ABI *now*, since old DT has no ti,sysc node?

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171001/f2fa2027/attachment.sig>

OK

Nope, things still keep working as they are with and without ti,sysc :)

Regards,

Tony

One typo below, otherwise:

OK thanks for looking, will fix before applying.

Regards,

Tony

When removing legacy platform data for IO ranges for the hwmod interconnect code, we still need to support the "ti,hwmods" property.

And as we're going to use a generic sysc device driver to handle the interconnect target instances, we can parse the information needed for legacy "ti,hwmods" IO range from the dts. It's always the first range the interconnect target module provides.

Note that we want to parse the range instead of the first child device IO regs as the child device may not always be defined.

The child IP device node may not exist in cases where there is no driver binding for the device, or when the child IP block may not even be functional for some SoC revisions. But the IO range of the interconnect target module is always known.

---
 arch/arm/mach-omap2/omap_hwmod.c | 80 +++++++++++++++++++++++++++++++++++++++-
 arch/arm/mach-omap2/omap_hwmod.h |  5 +++
 2 files changed, 84 insertions(+), 1 deletion(-)

@@ -2395,6 +2395,75 @@ static int of_dev_hwmod_lookup(struct device_node *np,
 	return -ENODEV;
 }
 
+/**
+ * omap_hwmod_parse_module_range - map module IO range from device tree
+ * @oh: struct omap_hwmod *
+ * @np: struct device_node *
+ *
+ * Parse the device tree range an interconnect target module provides
+ * for it's child device IP blocks. This way we can support the old
+ * "ti,hwmods" property with just dts data without a need for platform
+ * data for IO resources. And we don't need all the child IP device
+ * nodes available in the dts.
+ */
+int omap_hwmod_parse_module_range(struct omap_hwmod *oh,
+				  struct device_node *np,
+				  struct resource *res)
+{
+	struct property *prop;
+	const __be32 *ranges;
+	const char *name;
+	u32 nr_addr, nr_size;
+	u64 base, size;
+	int len, error;
+
+	if (!res)
+		return -EINVAL;
+
+	ranges = of_get_property(np, "ranges", &len);
+	if (!ranges)
+		return -ENOENT;
+
+	len /= sizeof(*ranges);
+
+	if (len < 3)
+		return -EINVAL;
+
+	of_property_for_each_string(np, "compatible", prop, name)
+		if (!strncmp("ti,sysc-", name, 8))
+			break;
+
+	if (!name)
+		return -ENOENT;
+
+	error = of_property_read_u32(np, "#address-cells", &nr_addr);
+	if (error)
+		return -ENOENT;
+
+	error = of_property_read_u32(np, "#size-cells", &nr_size);
+	if (error)
+		return -ENOENT;
+
+	if (nr_addr != 1 || nr_size != 1) {
+		pr_err("%s: invalid range for %s->%s\n", __func__,
+		       oh->name, np->name);
+		return -EINVAL;
+	}
+
+	ranges++;
+	base = of_translate_address(np, ranges++);
+	size = be32_to_cpup(ranges);
+
+	pr_debug("omap_hwmod: %s %s at 0x%llx size 0x%llx\n",
+		 oh->name, np->name, base, size);
+
+	res->start = base;
+	res->end = base + size - 1;
+	res->flags = IORESOURCE_MEM;
+
+	return 0;
+}
+
 /**
  * _init_mpu_rt_base - populate the virtual address for a hwmod
  * @oh: struct omap_hwmod * to locate the virtual address

@@ -2417,6 +2486,8 @@ static int __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data,
 {
 	struct omap_hwmod_addr_space *mem;
 	void __iomem *va_start = NULL;
+	struct resource res;
+	int error;
 
 	if (!oh)
 		return -EINVAL;

@@ -2442,7 +2513,14 @@ static int __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data,
 			return -ENXIO;
 		}
 
-		va_start = of_iomap(np, index + oh->mpu_rt_idx);
+		/* Do we have a dts range for the interconnect target module? */
+		error = omap_hwmod_parse_module_range(oh, np, &res);
+		if (!error)
+			va_start = ioremap(res.start, resource_size(&res));
+
+		/* No ranges, rely on device reg entry */
+		if (!va_start)
+			va_start = of_iomap(np, index + oh->mpu_rt_idx);
 	} else {
 		va_start = ioremap(mem->pa_start, mem->pa_end - mem->pa_start);
 	}

@@ -690,11 +690,16 @@ struct omap_hwmod {
 	struct omap_hwmod		*parent_hwmod;
 };
 
+struct device_node;
+
 struct omap_hwmod *omap_hwmod_lookup(const char *name);
 int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh, void *data),
 			void *data);
 
 int __init omap_hwmod_setup_one(const char *name);
+int omap_hwmod_parse_module_range(struct omap_hwmod *oh,
+				  struct device_node *np,
+				  struct resource *res);
 
 int omap_hwmod_enable(struct omap_hwmod *oh);
 int omap_hwmod_idle(struct omap_hwmod *oh);

2.14.2

We can populate the legacy resources needed by dma and smartreflex from device tree in omap_device_build().

There should be no need to do this for other devices, and eventually these two remaining users will be gone too. The legacy dma will be dropped when the remaining users have been converted to use the dmaengine driver, and smartreflex can now become just a regular device driver with a few pdata callbacks.

This is needed in order to remove remaining device dma, irq and io resources from the interconnect code.

And while at it, let's simplify things by removing otherwise unused omap_device_build_ss() as we will never call it for more than one hwmod.

---
 arch/arm/mach-omap2/omap_device.c | 137 +++++++++++++++++++++++++++++---------
 arch/arm/mach-omap2/omap_device.h |   4 --
 2 files changed, 106 insertions(+), 35 deletions(-)

@@ -35,6 +35,8 @@
 #include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
 #include <linux/notifier.h>
 
 #include "common.h"

@@ -521,6 +523,91 @@ void omap_device_delete(struct omap_device *od)
 	kfree(od);
 }
 
+/**
+ * omap_device_copy_resources - Add legacy IO and IRQ resources
+ * @oh: interconnect target module
+ * @pdev: platform device to copy resources to
+ *
+ * We still have legacy DMA and smartreflex needing resources.
+ * Let's populate what they need until we can eventually just
+ * remove this function. Note that there should be no need to
+ * call this from omap_device_build_from_dt(), nor should there
+ * be any need to call it for other devices.
+ */
+static int
+omap_device_copy_resources(struct omap_hwmod *oh,
+			   struct platform_device *pdev)
+{
+	struct device_node *np, *child;
+	struct property *prop;
+	struct resource *res;
+	const char *name;
+	int error, irq = 0;
+
+	if (!oh || !oh->od || !oh->od->pdev) {
+		error = -EINVAL;
+		goto error;
+	}
+
+	np = oh->od->pdev->dev.of_node;
+	if (!np) {
+		error = -ENODEV;
+		goto error;
+	}
+
+	res = kzalloc(sizeof(*res) * 2, GFP_KERNEL);
+	if (!res)
+		return -ENOMEM;
+
+	/* Do we have a dts range for the interconnect target module? */
+	error = omap_hwmod_parse_module_range(oh, np, res);
+
+	/* No ranges, rely on device reg entry */
+	if (error)
+		error = of_address_to_resource(np, 0, res);
+	if (error)
+		goto free;
+
+	/* SmartReflex needs first IO resource name to be "mpu" */
+	res[0].name = "mpu";
+
+	/*
+	 * We may have a configured "ti,sysc" interconnect target with a
+	 * dts child with the interrupt. If so use the first child's
+	 * first interrupt for "ti-hwmods" legacy support.
+	 */
+	of_property_for_each_string(np, "compatible", prop, name)
+		if (!strncmp("ti,sysc-", name, 8))
+			break;
+
+	child = of_get_next_available_child(np, NULL);
+
+	if (name)
+		irq = irq_of_parse_and_map(child, 0);
+	if (!irq)
+		irq = irq_of_parse_and_map(np, 0);
+	if (!irq)
+		goto free;
+
+	/* Legacy DMA code needs interrupt name to be "0" */
+	res[1].start = irq;
+	res[1].end = irq;
+	res[1].flags = IORESOURCE_IRQ;
+	res[1].name = "0";
+
+	error = platform_device_add_resources(pdev, res, 2);
+
+free:
+	kfree(res);
+
+error:
+	WARN(error, "%s: %s device %s failed: %i\n",
+	     __func__, oh->name, dev_name(&pdev->dev),
+	     error);
+
+	return error;
+}
+
 /**
  * omap_device_build - build and register an omap_device with one omap_hwmod
  * @pdev_name: name of the platform_device driver to use

@@ -539,46 +626,25 @@ struct platform_device __init *omap_device_build(const char *pdev_name,
 						 int pdev_id,
 						 struct omap_hwmod *oh,
 						 void *pdata, int pdata_len)
-{
-	struct omap_hwmod *ohs[] = { oh };
-
-	if (!oh)
-		return ERR_PTR(-EINVAL);
-
-	return omap_device_build_ss(pdev_name, pdev_id, ohs, 1, pdata,
-				    pdata_len);
-}
-
-/**
- * omap_device_build_ss - build and register an omap_device with multiple hwmods
- * @pdev_name: name of the platform_device driver to use
- * @pdev_id: this platform_device's connection ID
- * @oh: ptr to the single omap_hwmod that backs this omap_device
- * @pdata: platform_data ptr to associate with the platform_device
- * @pdata_len: amount of memory pointed to by @pdata
- *
- * Convenience function for building and registering an omap_device
- * subsystem record.  Subsystem records consist of multiple
- * omap_hwmods.  This function in turn builds and registers a
- * platform_device record.  Returns an ERR_PTR() on error, or passes
- * along the return value of omap_device_register().
- */
-struct platform_device __init *omap_device_build_ss(const char *pdev_name,
-						    int pdev_id,
-						    struct omap_hwmod **ohs,
-						    int oh_cnt, void *pdata,
-						    int pdata_len)
 {
 	int ret = -ENOMEM;
 	struct platform_device *pdev;
 	struct omap_device *od;
 
-	if (!ohs || oh_cnt == 0 || !pdev_name)
+	if (!oh || !pdev_name)
 		return ERR_PTR(-EINVAL);
 
 	if (!pdata && pdata_len > 0)
 		return ERR_PTR(-EINVAL);
 
+	if (strncmp(oh->name, "smartreflex", 11) &&
+	    strncmp(oh->name, "dma", 3)) {
+		pr_warn("%s need to update %s to probe with dt\na",
+			__func__, pdev_name);
+		ret = -ENODEV;
+		goto odbs_exit;
+	}
+
 	pdev = platform_device_alloc(pdev_name, pdev_id);
 	if (!pdev) {
 		ret = -ENOMEM;

@@ -591,7 +657,16 @@ struct platform_device __init *omap_device_build_ss(const char *pdev_name,
 	else
 		dev_set_name(&pdev->dev, "%s", pdev->name);
 
-	od = omap_device_alloc(pdev, ohs, oh_cnt);
+	/*
+	 * Must be called before omap_device_alloc() as oh->od
+	 * only contains the currently registered omap_device
+	 * and will get overwritten by omap_device_alloc().
+	 */
+	ret = omap_device_copy_resources(oh, pdev);
+	if (ret)
+		goto odbs_exit1;
+
+	od = omap_device_alloc(pdev, &oh, 1);
 	if (IS_ERR(od))
 		goto odbs_exit1;
 

@@ -75,10 +75,6 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
 					  struct omap_hwmod *oh, void *pdata,
 					  int pdata_len);
 
-struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
-					 struct omap_hwmod **oh, int oh_cnt,
-					 void *pdata, int pdata_len);
-
 struct omap_device *omap_device_alloc(struct platform_device *pdev,
 				      struct omap_hwmod **ohs, int oh_cnt);
 void omap_device_delete(struct omap_device *od);

2.14.2

We can handle the sysc interconnect target module in a generic way for many TI SoCs. Initially let's just enable runtime PM with autosuspend, and probe the children. This can already be used for idling interconnect target modules that don't have any device driver available for the child devices.

For now, the "ti,hwmods" custom binding is still required. That will be eventually deprecated in later patches. And more features will be added, such as parsing for sysc capabilities so we can continue removing the legacy platform data.

---
 arch/arm/mach-omap2/Kconfig |   1 +
 drivers/bus/Kconfig         |   7 +
 drivers/bus/Makefile        |   1 +
 drivers/bus/ti-sysc.c       | 558 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 567 insertions(+)
 create mode 100644 drivers/bus/ti-sysc.c

@@ -104,6 +104,7 @@ config ARCH_OMAP2PLUS
 	select OMAP_GPMC
 	select PINCTRL
 	select SOC_BUS
+	select TI_SYSC
 	select OMAP_IRQCHIP
 	select CLKSRC_TI_32K
 	help

@@ -157,6 +157,13 @@ config TEGRA_GMI
 	  Driver for the Tegra Generic Memory Interface bus which can be used
 	  to attach devices such as NOR, UART, FPGA and more.
 
+config TI_SYSC
+	bool "TI sysc interconnect target module driver"
+	depends on ARCH_OMAP2PLUS
+	help
+	  Generic driver for Texas Instruments interconnect target module
+	  found on many TI SoCs.
+
 config UNIPHIER_SYSTEM_BUS
 	tristate "UniPhier System Bus driver"
 	depends on ARCH_UNIPHIER && OF

@@ -20,6 +20,7 @@ obj-$(CONFIG_SUNXI_RSB)		+= sunxi-rsb.o
 obj-$(CONFIG_SIMPLE_PM_BUS)	+= simple-pm-bus.o
 obj-$(CONFIG_TEGRA_ACONNECT)	+= tegra-aconnect.o
 obj-$(CONFIG_TEGRA_GMI)		+= tegra-gmi.o
+obj-$(CONFIG_TI_SYSC)		+= ti-sysc.o
 obj-$(CONFIG_UNIPHIER_SYSTEM_BUS)	+= uniphier-system-bus.o
 obj-$(CONFIG_VEXPRESS_CONFIG)	+= vexpress-config.o
 

2.14.2

From: Tony Lindgren <[email protected]>
Date: Fri, 13 Oct 2017 10:48:40 -0700
Subject: [PATCH] bus: ti-sysc: Fix unbalanced pm_runtime_enable by adding
remove

Looks like we're missing remove() that's needed if a driver instance rebound. Otherwise we will get "Unbalanced pm_runtime_enable!".

---
 drivers/bus/ti-sysc.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

@@ -529,6 +529,30 @@ static int sysc_probe(struct platform_device *pdev)
 	return error;
 }
 
+static int sysc_remove(struct platform_device *pdev)
+{
+	struct sysc *ddata = platform_get_drvdata(pdev);
+	int error;
+
+	error = pm_runtime_get_sync(ddata->dev);
+	if (error < 0) {
+		pm_runtime_put_noidle(ddata->dev);
+		pm_runtime_disable(ddata->dev);
+		goto unprepare;
+	}
+
+	of_platform_depopulate(&pdev->dev);
+
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+
+unprepare:
+	sysc_unprepare(ddata);
+
+	return 0;
+}
+
 static const struct of_device_id sysc_match[] = {
 	{ .compatible = "ti,sysc-omap2" },
 	{ .compatible = "ti,sysc-omap4" },

@@ -546,6 +570,7 @@ MODULE_DEVICE_TABLE(of, sysc_match);
 
 static struct platform_driver sysc_driver = {
 	.probe		= sysc_probe,
+	.remove		= sysc_remove,
 	.driver         = {
 		.name   = "ti-sysc",
 		.of_match_table	= sysc_match,

2.14.2

On omap4 we are missing dts nodes for several interconnect target modules that we are idling on init. This currently works with the legacy platform data still around.

To fix this, let's add the interconnect target modules so we can idle the unused interconnect target module on init.

Also note that adding the interconnect target module node does not necessarily mean that there is a driver available for the child IP block, or that the child IP block is even functional.

In the SGX case, the PowerVR driver is closed source. And McASP on omap4 has at least the TX path disabled and is not supported by the davinci-mcasp driver. For AESS there is old Android 3.4 kernel driver available.

For smarflex, we are still probing with platform data and the driver needs more work before we can add the device ip child nodes.

And finally, we're not yet using the interconnet ranges. I will be posting separate patches for those later on.

---
 arch/arm/boot/dts/omap4.dtsi | 159 +++++++++++++++++++++++++++++++++++++++----
 1 file changed, 147 insertions(+), 12 deletions(-)

@@ -382,6 +382,19 @@
 			#interrupt-cells = <2>;
 		};
 
+		target-module at 48076000 {
+			compatible = "ti,sysc-omap4";
+			ti,hwmods = "slimbus2";
+			reg = <0x48076000 0x4>,
+			      <0x48076010 0x4>;
+			reg-names = "rev", "sysc";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 0x48076000 0x001000>;
+
+			/* No child device binding or driver in mainline */
+		};
+
 		elm: elm at 48078000 {
 			compatible = "ti,am3352-elm";
 			reg = <0x48078000 0x2000>;

@@ -442,25 +455,55 @@
 			clock-frequency = <48000000>;
 		};
 
-		smartreflex_iva: smartreflex at 4a0db000 {
-			compatible = "ti,omap4-smartreflex-iva";
-			reg = <0x4a0db000 0x80>;
-			interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+		target-module at 4a0db000 {
+			compatible = "ti,sysc-sr";
 			ti,hwmods = "smartreflex_iva";
+			reg = <0x4a0db000 0x4>,
+			      <0x4a0db008 0x4>;
+			reg-names = "rev", "sysc";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 0x4a0db000 0x001000>;
+
+			smartreflex_iva: smartreflex at 0 {
+				compatible = "ti,omap4-smartreflex-iva";
+				reg = <0 0x80>;
+				interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+			};
 		};
 
-		smartreflex_core: smartreflex at 4a0dd000 {
-			compatible = "ti,omap4-smartreflex-core";
-			reg = <0x4a0dd000 0x80>;
-			interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+		target-module at 4a0dd000 {
+			compatible = "ti,sysc-sr";
 			ti,hwmods = "smartreflex_core";
+			reg = <0x4a0dd000 0x4>,
+			      <0x4a0dd008 0x4>;
+			reg-names = "rev", "sysc";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 0x4a0dd000 0x001000>;
+
+			smartreflex_core: smartreflex at 0 {
+				compatible = "ti,omap4-smartreflex-core";
+				reg = <0 0x80>;
+				interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+			};
 		};
 
-		smartreflex_mpu: smartreflex at 4a0d9000 {
-			compatible = "ti,omap4-smartreflex-mpu";
-			reg = <0x4a0d9000 0x80>;
-			interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+		target-module at 4a0d9000 {
+			compatible = "ti,sysc-sr";
 			ti,hwmods = "smartreflex_mpu";
+			reg = <0x4a0d9000 0x4>,
+			      <0x4a0d9008 0x4>;
+			reg-names = "rev", "sysc";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 0x4a0d9000 0x001000>;
+
+			smartreflex_mpu: smartreflex at 0 {
+				compatible = "ti,omap4-smartreflex-mpu";
+				reg = <0 0x80>;
+				interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+			};
 		};
 
 		hwspinlock: spinlock at 4a0f6000 {

@@ -666,6 +709,19 @@
 			#iommu-cells = <0>;
 		};
 
+		target-module at 52000000 {
+			compatible = "ti,sysc-omap4";
+			ti,hwmods = "iss";
+			reg = <0x52000000 0x4>,
+			      <0x52000010 0x4>;
+			reg-names = "rev", "sysc";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 0x52000000 0x1000000>;
+
+			/* No child device binding, driver in staging */
+		};
+
 		mmu_ipu: mmu at 55082000 {
 			compatible = "ti,omap4-iommu";
 			reg = <0x55082000 0x100>;

@@ -760,6 +816,56 @@
 			status = "disabled";
 		};
 
+		target-module at 40128000 {
+			compatible = "ti,sysc-mcasp";
+			ti,hwmods = "mcasp";
+			reg = <0x40128004 0x4>;
+			reg-names = "sysc";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0x00000000 0x40128000 0x1000>, /* MPU */
+				 <0x49028000 0x49028000 0x1000>; /* L3 */
+
+			/*
+			 * Child device unsupported by davinci-mcasp. At least
+			 * TX path is disabled for omap4, and only DIT mode
+			 * works with no I2S. See also old Android kernel
+			 * omap-mcasp driver for more information.
+			 */
+		};
+
+		target-module at 4012c000 {
+			compatible = "ti,sysc-omap4";
+			ti,hwmods = "slimbus1";
+			reg = <0x4012c000 0x4>,
+			      <0x4012c010 0x4>;
+			reg-names = "rev", "sysc";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0x00000000 0x4012c000 0x1000>, /* MPU */
+				 <0x4902c000 0x4902c000 0x1000>; /* L3 */
+
+			/* No child device binding or driver in mainline */
+		};
+
+		target-module at 401f1000 {
+			compatible = "ti,sysc-omap4";
+			ti,hwmods = "aess";
+			reg = <0x401f1000 0x4>,
+			      <0x401f1010 0x4>;
+			reg-names = "rev", "sysc";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0x00000000 0x401f1000 0x1000>, /* MPU */
+				 <0x490f1000 0x490f1000 0x1000>; /* L3 */
+
+			/*
+			 * No child device binding or driver in mainline.
+			 * See Android tree and related upstreaming efforts
+			 * for the old driver.
+			 */
+		};
+
 		mcbsp4: mcbsp at 48096000 {
 			compatible = "ti,omap4-mcbsp";
 			reg = <0x48096000 0xff>; /* L4 Interconnect */

@@ -848,6 +954,19 @@
 			};
 		};
 
+		target-module at 4a10a000 {
+			compatible = "ti,sysc-omap4";
+			ti,hwmods = "fdif";
+			reg = <0x4a10a000 0x4>,
+			      <0x4a10a010 0x4>;
+			reg-names = "rev", "sysc";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 0x4a10a000 0x1000>;
+
+			/* No child device binding or driver in mainline */
+		};
+
 		timer1: timer at 4a318000 {
 			compatible = "ti,omap3430-timer";
 			reg = <0x4a318000 0x80>;

@@ -1063,6 +1182,22 @@
 			status = "disabled";
 		};
 
+		target-module at 56000000 {
+			compatible = "ti,sysc-omap4";
+			ti,hwmods = "gpu";
+			reg = <0x5601fc00 0x4>,
+			      <0x5601fc10 0x4>;
+			reg-names = "rev", "sysc";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 0x56000000 0x2000000>;
+
+			/*
+			 * Closed source PowerVR driver, no child device
+			 * binding or driver in mainline
+			 */
+		};
+
 		dss: dss at 58000000 {
 			compatible = "ti,omap4-dss";
 			reg = <0x58000000 0x80>;

2.14.2

?
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

RX path is disabled, TX is supposed to work.

...

P?ter

Hi Peter,

Not sure if this is helpful information:

Motorola Droid 4 is OMAP4430 based and has McASP lines routed to the audio codec (either McASP or McBSP can be used). Codec is a custom one, which is not yet supported mainline, but patches are WIP (*):

https://lkml.org/lkml/2017/7/12/368

(*) My patches use McBSP instead of McASP, since McASP looked mostly unsupported. Motorola's kernel uses McASP.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171011/6db17987/attachment.sig>

?Hi Sebastian,

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Really cool!
I don't see much benefit of using McASP on OMAP4, only drawbacks... It lacks AFIFO so it is prone to underrun and if it underruns you need to reset McASP. Been there with the Samsung Galaxy Nexus.

I wonder how Motorola is using the McASP as the OMAP4 version (officially) does not support I2S. It might work, I have not tried it.

I do have one Galaxy Nexus, but there the McASP is used for the S/PIDIF on the dock (the three pins on the side). Yes, I do not have the dock and my Galaxy Nexus is still in active use -> not rooted, and never run mainline Linux.

If I have something I might ask you for testing, if it is OK.

- P?ter

AESS/ATC isn't able to consistently respond to a DMA request within 20 us ? Strange.. I would have expected it to have no trouble with that. (And presumably so did TI, or they would have included AFIFO?)

Hmm? I checked the omap4430 TRM and I don't see that mentioned. It seems to have pins for i2s transmit:

	abe_mcasp_axr              O     Audio transmit data
	abe_mcasp_aclkx            O     Transmit bit clock
	abe_mcasp_ahclkx           O     Transmit high-frequency master clock
	abe_mcasp_afsx             O     Transmit frame synchronization
	abe_mcasp_amute            O     Mute out to external
	abe_mcasp_amutein          I     Mute in from external

If it supported s/pdif tx only, then all of these except axr would be useless.

Matthijs

?

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

The McASP transmit section uses the S/PDIF industry format, which is supported by the DIT transfer mode of the module.

And look for Transfer Modes chapter of McSSP in the OMAP4 TRM.

It is DIT only.

- P?ter

Hi,

Below is a fix for the RX comment.

Regards,

Tony

8< ------------------

From: Tony Lindgren <[email protected]>
Date: Fri, 13 Oct 2017 09:43:22 -0700
Subject: [PATCH] ARM: dts: Fix typo for omap4 mcasp rx path

As reported by Peter Ujfalusi <[email protected]>, the rx path on macsp is disabled and only tx is usable if the davinci-mcasp driver is updated for it.

---
 arch/arm/boot/dts/omap4.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

@@ -828,7 +828,7 @@
 
 			/*
 			 * Child device unsupported by davinci-mcasp. At least
-			 * TX path is disabled for omap4, and only DIT mode
+			 * RX path is disabled for omap4, and only DIT mode
 			 * works with no I2S. See also old Android kernel
 			 * omap-mcasp driver for more information.
 			 */

2.14.2

The TRM has marked dra7 SmartReflex as reserved and we should not touch those registers as pointed out by Nishanth Menon <[email protected]>. We do still want to idle the related interconnect target modules on init though.

Let's do this by only configuring the generic interconnect target modules and not add the child SmartReflex devices.

---
 arch/arm/boot/dts/dra7.dtsi | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

@@ -1497,6 +1497,32 @@
 			};
 		};
 
+		target-module at 4a0dd000 {
+			compatible = "ti,sysc-omap4-sr";
+			ti,hwmods = "smartreflex_core";
+			reg = <0x4a0dd000 0x4>,
+			      <0x4a0dd008 0x4>;
+			reg-names = "rev", "sysc";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 0x4a0dd000 0x001000>;
+
+			/* SmartReflex child device marked reserved in TRM */
+		};
+
+		target-module at 4a0d9000 {
+			compatible = "ti,sysc-omap4-sr";
+			ti,hwmods = "smartreflex_mpu";
+			reg = <0x4a0d9000 0x4>,
+			      <0x4a0d9008 0x4>;
+			reg-names = "rev", "sysc";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 0x4a0d9000 0x001000>;
+
+			/* SmartReflex child device marked reserved in TRM */
+		};
+
 		omap_dwc3_1: omap_dwc3_1 at 48880000 {
 			compatible = "ti,dwc3";
 			ti,hwmods = "usb_otg_ss1";

2.14.2

Let's make use of the generic ti-sysc module for musb to have a child device with working runtime PM.

---
 arch/arm/boot/dts/omap4.dtsi | 36 ++++++++++++++++++++++++------------
 1 file changed, 24 insertions(+), 12 deletions(-)

@@ -1105,19 +1105,31 @@
 			reg-names = "otghs_control";
 		};
 
-		usb_otg_hs: usb_otg_hs at 4a0ab000 {
-			compatible = "ti,omap4-musb";
-			reg = <0x4a0ab000 0x7ff>;
-			interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "mc", "dma";
+		target-module at 4a0ab000 {
+			compatible = "ti,sysc-omap4";
 			ti,hwmods = "usb_otg_hs";
-			usb-phy = <&usb2_phy>;
-			phys = <&usb2_phy>;
-			phy-names = "usb2-phy";
-			multipoint = <1>;
-			num-eps = <16>;
-			ram-bits = <12>;
-			ctrl-module = <&omap_control_usbotg>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0x4a0ab000 0x4>,
+			      <0x4a0ab004 0x4>,
+			      <0x4a0ab008 0x4>;
+			reg-names = "rev", "sysc", "syss";
+			ranges = <0 0x4a0ab000 0x1000>;
+
+			usb_otg_hs: otg at 0 {
+				compatible = "ti,omap4-musb";
+				reg = <0x0 0x7ff>;
+				interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "mc", "dma";
+				usb-phy = <&usb2_phy>;
+				phys = <&usb2_phy>;
+				phy-names = "usb2-phy";
+				multipoint = <1>;
+				num-eps = <16>;
+				ram-bits = <12>;
+				ctrl-module = <&omap_control_usbotg>;
+			};
 		};
 
 		aes1: aes at 4b501000 {

2.14.2

...

From: Tony Lindgren <[email protected]>
Date: Fri, 29 Sep 2017 08:20:50 -0700
Subject: [PATCH] ARM: dts: Use ti-sysc module driver for omap4 musb

Let's make use of the generic ti-sysc module for musb to have a child device with working runtime PM.

---
 arch/arm/boot/dts/omap4.dtsi | 36 ++++++++++++++++++++++++------------
 1 file changed, 24 insertions(+), 12 deletions(-)

@@ -1117,19 +1117,31 @@
 			reg-names = "otghs_control";
 		};
 
-		usb_otg_hs: usb_otg_hs at 4a0ab000 {
-			compatible = "ti,omap4-musb";
-			reg = <0x4a0ab000 0x7ff>;
-			interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "mc", "dma";
+		target-module at 4a0ab000 {
+			compatible = "ti,sysc-omap2";
 			ti,hwmods = "usb_otg_hs";
-			usb-phy = <&usb2_phy>;
-			phys = <&usb2_phy>;
-			phy-names = "usb2-phy";
-			multipoint = <1>;
-			num-eps = <16>;
-			ram-bits = <12>;
-			ctrl-module = <&omap_control_usbotg>;
+			reg = <0x4a0ab000 0x4>,
+			      <0x4a0ab004 0x4>,
+			      <0x4a0ab008 0x4>;
+			reg-names = "rev", "sysc", "syss";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 0x4a0ab000 0x1000>;
+
+			usb_otg_hs: otg at 0 {
+				compatible = "ti,omap2-musb";
+				reg = <0x0 0x7ff>;
+				interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "mc", "dma";
+				usb-phy = <&usb2_phy>;
+				phys = <&usb2_phy>;
+				phy-names = "usb2-phy";
+				multipoint = <1>;
+				num-eps = <16>;
+				ram-bits = <12>;
+				ctrl-module = <&omap_control_usbotg>;
+			};
 		};
 
 		aes1: aes at 4b501000 {

2.14.2