[1/7] dt-bindings: bus: Minimal TI sysc interconnect target module binding

Message ID 20170929223411.9691-2-tony@atomide.com
State New
Headers show
Series
  • Fix remaining issues to drop more omap platform data
Related show

Commit Message

Tony Lindgren Sept. 29, 2017, 10:34 p.m.
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.

Cc: Benoît Cousson <bcousson@baylibre.com>
Cc: Dave Gerlach <d-gerlach@ti.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Nishanth Menon <nm@ti.com>
Cc: Matthijs van Duin <matthijsvanduin@gmail.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Suman Anna <s-anna@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 Documentation/devicetree/bindings/bus/ti-sysc.txt | 93 +++++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/ti-sysc.txt

Comments

Sebastian Reichel Oct. 1, 2017, 1:11 p.m. | #1
Hi,

On Fri, Sep 29, 2017 at 03:34:05PM -0700, Tony Lindgren wrote:
> 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.

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
Tony Lindgren Oct. 1, 2017, 5:14 p.m. | #2
* Sebastian Reichel <sre@ring0.de> [171001 06:12]:
> On Fri, Sep 29, 2017 at 03:34:05PM -0700, Tony Lindgren wrote:
> > 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.
> 
> 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.

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

> 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!").

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

Regards,

Tony
Sebastian Reichel Oct. 1, 2017, 8:48 p.m. | #3
Hi,

On Sun, Oct 01, 2017 at 10:14:07AM -0700, Tony Lindgren wrote:
> * Sebastian Reichel <sre@ring0.de> [171001 06:12]:
> > On Fri, Sep 29, 2017 at 03:34:05PM -0700, Tony Lindgren wrote:
> > > 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.
> > 
> > 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.
> 
> 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

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
Tony Lindgren Oct. 1, 2017, 9:03 p.m. | #4
* Sebastian Reichel <sre@kernel.org> [171001 13:49]:
> Hi,
> 
> On Sun, Oct 01, 2017 at 10:14:07AM -0700, Tony Lindgren wrote:
> > * Sebastian Reichel <sre@ring0.de> [171001 06:12]:
> > > On Fri, Sep 29, 2017 at 03:34:05PM -0700, Tony Lindgren wrote:
> > > > 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.
> > > 
> > > 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.
> > 
> > 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
> 
> 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.

OK

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

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

Regards,

Tony
Rob Herring Oct. 10, 2017, 3:46 p.m. | #5
On Fri, Sep 29, 2017 at 03:34:05PM -0700, Tony Lindgren wrote:
> 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.
> 
> Cc: Benoît Cousson <bcousson@baylibre.com>
> Cc: Dave Gerlach <d-gerlach@ti.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Matthijs van Duin <matthijsvanduin@gmail.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Sakari Ailus <sakari.ailus@iki.fi>
> Cc: Suman Anna <s-anna@ti.com>
> Cc: Tero Kristo <t-kristo@ti.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  Documentation/devicetree/bindings/bus/ti-sysc.txt | 93 +++++++++++++++++++++++
>  1 file changed, 93 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/bus/ti-sysc.txt

One typo below, otherwise:

Reviewed-by: Rob Herring <robh@kernel.org>

> diff --git a/Documentation/devicetree/bindings/bus/ti-sysc.txt b/Documentation/devicetree/bindings/bus/ti-sysc.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/ti-sysc.txt
> @@ -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

s/indepenent/independent/

> +of the interconnect.
Tony Lindgren Oct. 10, 2017, 4:45 p.m. | #6
* Rob Herring <robh@kernel.org> [171010 08:47]:
> On Fri, Sep 29, 2017 at 03:34:05PM -0700, Tony Lindgren wrote:
> >  Documentation/devicetree/bindings/bus/ti-sysc.txt | 93 +++++++++++++++++++++++
> >  1 file changed, 93 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/bus/ti-sysc.txt
> 
> One typo below, otherwise:
> 
> Reviewed-by: Rob Herring <robh@kernel.org>
> 
> > diff --git a/Documentation/devicetree/bindings/bus/ti-sysc.txt b/Documentation/devicetree/bindings/bus/ti-sysc.txt
> > new file mode 100644
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/bus/ti-sysc.txt
> > @@ -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
> 
> s/indepenent/independent/
> 
> > +of the interconnect.

OK thanks for looking, will fix before applying.

Regards,

Tony

Patch

diff --git a/Documentation/devicetree/bindings/bus/ti-sysc.txt b/Documentation/devicetree/bindings/bus/ti-sysc.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti-sysc.txt
@@ -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@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@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.