diff mbox series

[01/10] dt-bindings: bus: Minimal TI sysc interconnect target module binding

Message ID 20170920224621.16236-2-tony@atomide.com
State New
Headers show
Series Fix remaining issues to drop more omap platform data | expand

Commit Message

Tony Lindgren Sept. 20, 2017, 10:46 p.m. UTC 
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).

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: 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: 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 | 88 +++++++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/ti-sysc.txt

Comments

Matthijs van Duin Sept. 25, 2017, 6:35 a.m. UTC | #1 
On Wed, Sep 20, 2017 at 03:46:12PM -0700, Tony Lindgren wrote:
> +- compatible	shall be one of the following generic types:
> +
> +		"ti,sysc-type1"
> +		"ti,sysc-type2"
> +		"ti,sysc-type3"

Is the meaning of these documented anywhere?  I'm assuming one of them
corresponds to the standard omap2/3 sysconfig/sysstatus:

	sysconfig:
	bit   0     rw  auto-idle / auto-gating
	bit   1     -x  soft-reset
	bit   2     rw  wakeup enabled
	bits  3- 4  rw  (slave) idle mode
	bit   5     rw  emu-free
	bits  6- 7  z-
	bit   8     rw  interface clock not gated when module in idle
	bit   9     rw  functional clock not gated when module in idle
	bits 10-11  z-
	bits 12-13  rw  standby mode (master idle mode)
	sysstatus:
	bit   0     r-  reset done

and one to the standard omap4/5 sysconfig:

	bit   0     rx  soft-reset
	bit   1     rw  emu-free
	bits  2- 3  rw  (slave) idle mode
	bits  4- 5  rw  standby mode (master idle mode)
	bits  6- 7  z-
	bits  8-15  rw  auxiliary clocks (rare)

What's the third?  I'm not really aware of any other standard layout,
just a whole bunch of non-standard ones.

> +		or one of the following derivative types for hardware
> +		needing special workarounds:

To add to the collection: omap4/5 isp5 (part of iss) has:
	bit   0     r-  auto-idle / auto-gating
	bit   1     rx  soft-reset (requires special procedure)
	bits  2- 3  z-
	bits  4- 5  rw  standby mode (master idle mode)

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

ISS (omap4/5, dm814x) is also fun since it has top-level sysconfig, but
most of the child modules (e.g. isp5 and simcop) also have their own
sysconfig, and some child modules of simcop again have sysconfig.

Matthijs
Matthijs van Duin Sept. 25, 2017, 7:03 a.m. UTC | #2 
On Wed, Sep 20, 2017 at 03:46:12PM -0700, Tony Lindgren wrote:
> 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).

This is because the interface between interconnect and module is
standardized (Open Core Protocol), so it doesn't really matter which
interconnect technology is used.

Also, afaik sysc mostly just concerns the interaction between module and
PRCM.  The only role the interconnect plays here is that it participates
in the OCP Disconnect Protocol to allow the module to safely disconnect
itself when it or the interconnect enters idle state.

Matthijs
Tony Lindgren Sept. 25, 2017, 2:25 p.m. UTC | #3 
* Matthijs van Duin <matthijsvanduin@gmail.com> [170924 23:36]:
> On Wed, Sep 20, 2017 at 03:46:12PM -0700, Tony Lindgren wrote:
> > +- compatible	shall be one of the following generic types:
> > +
> > +		"ti,sysc-type1"
> > +		"ti,sysc-type2"
> > +		"ti,sysc-type3"
> 
> Is the meaning of these documented anywhere?  I'm assuming one of them
> corresponds to the standard omap2/3 sysconfig/sysstatus:

Yes that's the type1 sysc. Pretty much the only documentation is what
we already have defined in the kernel, see:

$ grep "#define SYSC_TYPE" arch/arm/mach-omap2/omap_hwmod.h

> 	sysconfig:
> 	bit   0     rw  auto-idle / auto-gating
> 	bit   1     -x  soft-reset
> 	bit   2     rw  wakeup enabled
> 	bits  3- 4  rw  (slave) idle mode
> 	bit   5     rw  emu-free
> 	bits  6- 7  z-
> 	bit   8     rw  interface clock not gated when module in idle
> 	bit   9     rw  functional clock not gated when module in idle
> 	bits 10-11  z-
> 	bits 12-13  rw  standby mode (master idle mode)
> 	sysstatus:
> 	bit   0     r-  reset done
> 
> and one to the standard omap4/5 sysconfig:
> 
> 	bit   0     rx  soft-reset
> 	bit   1     rw  emu-free
> 	bits  2- 3  rw  (slave) idle mode
> 	bits  4- 5  rw  standby mode (master idle mode)
> 	bits  6- 7  z-
> 	bits  8-15  rw  auxiliary clocks (rare)

Yeah and that's what we call sysc type 2 in the kernel.

> What's the third?  I'm not really aware of any other standard layout,
> just a whole bunch of non-standard ones.

The sysc type3 is what we have on am335x/ti81xx, see:

$ git grep -B10 -A1 "&omap_hwmod_sysc_type3" arch/arm/mach-omap2

> > +		or one of the following derivative types for hardware
> > +		needing special workarounds:
> 
> To add to the collection: omap4/5 isp5 (part of iss) has:
> 	bit   0     r-  auto-idle / auto-gating
> 	bit   1     rx  soft-reset (requires special procedure)
> 	bits  2- 3  z-
> 	bits  4- 5  rw  standby mode (master idle mode)

OK, I don't think we have that yet.

> > +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.
> 
> ISS (omap4/5, dm814x) is also fun since it has top-level sysconfig, but
> most of the child modules (e.g. isp5 and simcop) also have their own
> sysconfig, and some child modules of simcop again have sysconfig.

Interesting. Sounds like there's yet another interconnect instance
lurking there similar to L4 ABE?

Regards,

Tony
Tony Lindgren Sept. 25, 2017, 2:37 p.m. UTC | #4 
* Matthijs van Duin <matthijsvanduin@gmail.com> [170925 00:04]:
> On Wed, Sep 20, 2017 at 03:46:12PM -0700, Tony Lindgren wrote:
> > 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).
> 
> This is because the interface between interconnect and module is
> standardized (Open Core Protocol), so it doesn't really matter which
> interconnect technology is used.
> 
> Also, afaik sysc mostly just concerns the interaction between module and
> PRCM.  The only role the interconnect plays here is that it participates
> in the OCP Disconnect Protocol to allow the module to safely disconnect
> itself when it or the interconnect enters idle state.

OK thanks for clarifying it, I'll add a note regarding OCP there.

Regards,

Tony
Matthijs van Duin Sept. 25, 2017, 5:21 p.m. UTC | #5 
On Mon, Sep 25, 2017 at 07:25:20AM -0700, Tony Lindgren wrote:
> * Matthijs van Duin <matthijsvanduin@gmail.com> [170924 23:36]:
> > Is the meaning of these documented anywhere?  I'm assuming one of them
> > corresponds to the standard omap2/3 sysconfig/sysstatus
>
> Yes that's the type1 sysc.
>
> > and one to the standard omap4/5 sysconfig
>
> Yeah and that's what we call sysc type 2 in the kernel.

Might it then not make more sense to call those something like
ti,omap2-sysc and ti,omap4-sysc respectively?

> The sysc type3 is what we have on am335x/ti81xx, see:
>
> $ git grep -B10 -A1 "&omap_hwmod_sysc_type3" arch/arm/mach-omap2

Ah... three "foreign" modules with an idlemode carelessly thrown into a
register without care for existing layouts.  I think these are more just
exceptional cases which happen to agree by coincidence since they all
just added idlemode in the simplest way possible, but I can understand
how it came to be viewed as a standard type.

> > ISS (omap4/5, dm814x) is also fun since it has top-level sysconfig, but
> > most of the child modules (e.g. isp5 and simcop) also have their own
> > sysconfig, and some child modules of simcop again have sysconfig.
>
> Interesting. Sounds like there's yet another interconnect instance
> lurking there similar to L4 ABE?

ISS has a 32-bit configuration interconnect and a 64/128-bit data
interconnect:
      .......................................
     :              ISS                      :
     :                                       :
L3 --:--> configuration interconnect <-------:-- Cortex-M3/M4 subsystem
     :      ||||||||||        |   |          :
     :      vvvvvvvvvv        |   |          :
     :      submodules        |   '---.      :
     :       ||||||||         |       |      :
     :       vvvvvvvv         v       v      :
     : data interconnect --> BTE --> CBUFF --:--> L3
     '.......................................'

It also has a local prcm controller to manage all this, and an irq
combiner.  See the section "ISS Power Management" (8.1.2.4 in the public
omap5 TRM, SWPU249AF) for a better diagram of all this.  The various
versions of ISS differ somewhat in the submodules but all share the same
overall structure.

One of the ISS submodules, SIMCOP, is itself again a fairly complicated
subsystem with two local interconnects, of which you can find a block
diagram in the "ISS Still Image Coprocessor" chapter (8.4).

Having a local interconnect is itself not a particularly rare thing (you
can find one in ABE, DSS, CPSW, PRUSS, PWMSS, etc), but ISS does have
unusual complexity with its multiple interconnects and nested subsystems.

Matthijs
Tony Lindgren Sept. 25, 2017, 5:44 p.m. UTC | #6 
* Matthijs van Duin <matthijsvanduin@gmail.com> [170925 10:22]:
> On Mon, Sep 25, 2017 at 07:25:20AM -0700, Tony Lindgren wrote:
> > * Matthijs van Duin <matthijsvanduin@gmail.com> [170924 23:36]:
> > > Is the meaning of these documented anywhere?  I'm assuming one of them
> > > corresponds to the standard omap2/3 sysconfig/sysstatus
> >
> > Yes that's the type1 sysc.
> >
> > > and one to the standard omap4/5 sysconfig
> >
> > Yeah and that's what we call sysc type 2 in the kernel.
> 
> Might it then not make more sense to call those something like
> ti,omap2-sysc and ti,omap4-sysc respectively?

OK that's a good idea.

> > The sysc type3 is what we have on am335x/ti81xx, see:
> >
> > $ git grep -B10 -A1 "&omap_hwmod_sysc_type3" arch/arm/mach-omap2
> 
> Ah... three "foreign" modules with an idlemode carelessly thrown into a
> register without care for existing layouts.  I think these are more just
> exceptional cases which happen to agree by coincidence since they all
> just added idlemode in the simplest way possible, but I can understand
> how it came to be viewed as a standard type.

So we shall then name this fine centauroid sysc ti,81xx-sysc?

> > > ISS (omap4/5, dm814x) is also fun since it has top-level sysconfig, but
> > > most of the child modules (e.g. isp5 and simcop) also have their own
> > > sysconfig, and some child modules of simcop again have sysconfig.
> >
> > Interesting. Sounds like there's yet another interconnect instance
> > lurking there similar to L4 ABE?
> 
> ISS has a 32-bit configuration interconnect and a 64/128-bit data
> interconnect:
>       .......................................
>      :              ISS                      :
>      :                                       :
> L3 --:--> configuration interconnect <-------:-- Cortex-M3/M4 subsystem
>      :      ||||||||||        |   |          :
>      :      vvvvvvvvvv        |   |          :
>      :      submodules        |   '---.      :
>      :       ||||||||         |       |      :
>      :       vvvvvvvv         v       v      :
>      : data interconnect --> BTE --> CBUFF --:--> L3
>      '.......................................'
> 
> It also has a local prcm controller to manage all this, and an irq
> combiner.  See the section "ISS Power Management" (8.1.2.4 in the public
> omap5 TRM, SWPU249AF) for a better diagram of all this.  The various
> versions of ISS differ somewhat in the submodules but all share the same
> overall structure.

OK thanks for the pointer.

> One of the ISS submodules, SIMCOP, is itself again a fairly complicated
> subsystem with two local interconnects, of which you can find a block
> diagram in the "ISS Still Image Coprocessor" chapter (8.4).

OK

> Having a local interconnect is itself not a particularly rare thing (you
> can find one in ABE, DSS, CPSW, PRUSS, PWMSS, etc), but ISS does have
> unusual complexity with its multiple interconnects and nested subsystems.

OK

Regards,

Tony
Matthijs van Duin Sept. 27, 2017, 9:56 a.m. UTC | #7 
On Mon, Sep 25, 2017 at 10:44:14AM -0700, Tony Lindgren wrote:
> * Matthijs van Duin <matthijsvanduin@gmail.com> [170925 10:22]:
> > Ah... three "foreign" modules with an idlemode carelessly thrown into a
> > register without care for existing layouts.  I think these are more just
> > exceptional cases which happen to agree by coincidence since they all
> > just added idlemode in the simplest way possible, but I can understand
> > how it came to be viewed as a standard type.
> 
> So we shall then name this fine centauroid sysc ti,81xx-sysc?

There's nothing centauroid specific about this, mcasp on omap4 has it too.

Matthijs
Tony Lindgren Sept. 29, 2017, 5:51 p.m. UTC | #8 
* Matthijs van Duin <matthijsvanduin@gmail.com> [170927 02:57]:
> On Mon, Sep 25, 2017 at 10:44:14AM -0700, Tony Lindgren wrote:
> > * Matthijs van Duin <matthijsvanduin@gmail.com> [170925 10:22]:
> > > Ah... three "foreign" modules with an idlemode carelessly thrown into a
> > > register without care for existing layouts.  I think these are more just
> > > exceptional cases which happen to agree by coincidence since they all
> > > just added idlemode in the simplest way possible, but I can understand
> > > how it came to be viewed as a standard type.
> > 
> > So we shall then name this fine centauroid sysc ti,81xx-sysc?
> 
> There's nothing centauroid specific about this, mcasp on omap4 has it too.

OK and for that we have ti,sysc-mcasp. We can call the generic one
ti,sysc-omap4-simple.

Regards,

Tony
diff mbox series

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,88 @@ 
+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).
+
+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-type1"
+		"ti,sysc-type2"
+		"ti,sysc-type3"
+
+		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 "clkctrl"
+
+- 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-type1";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0x2b400 0x4>,
+		      <0x2b404 0x4>,
+		      <0x2b408 0x4>;
+		reg-names = "rev", "sysc", "syss";
+		ranges = <0 0x2b000 0x1000>;
+		clocks = <&l3_init_clkctrl OMAP4_USB_OTG_HS_CLKCTRL 0>;
+		clock-names = "clkctrl";
+
+		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.