On Tue, Mar 14, 2017 at 02:23:04PM -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
> interconnect target module hardware that manages the individual device IP
> blocks on various interconnects for TI SoCs. The resources managed for the
> child IP blocks are clocks, idlemodes and interconnect level resets.
>
> TI interconnect target module hardware is the same for modules, and 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 module, we need to
> use device tree configuration for the revision of the interconnect target
> module and things like supported master and slave idle modes.
>
> Note that the interconnect target module control registers for the whole
> module (including it's children) are always sprinked into the unused
> address space of the first device IP block that the interconnect target
> module manages.
>
> To avoid IO range conflicts, we can have the interconnect target module
> probe it's children and provide IO ranges for the children along with
> other services such as implementing runtime PM for the shared module
> clock.
>
> The reason for doing this is to simplify adding support for new devices.
> Currently we need to modify clock aliases, static hwmod data, device tree
> data and the driver even for simple devices.
>
> With the recently introduced clkctrl binding the need to modify clock
> aliases will go away. And when the interconnect target module can be
> configured using device tree, the need to modify static hwmod data goes
> away. So eventually we only need to modify the device tree and the
> driver.
>
> Also further changes for power management will be easier as the
> interconnect, power domain, and clock domain hierarcy can be made
> available in a standard way for Linux PM domains support via device
> tree.
>
> For a non-intrusive transition from static hwmod data to using device
> tree defined TI interconnect target module binding, we can keep things
> working the existing way if device tree property "ti,hwmods" is
> specified in the dtb.
Seems mostly reasonable...
> Cc: Benoît Cousson <bcousson@xxxxxxxxxxxx>
> Cc: Mark Rutland <mark.rutland@xxxxxxx>
> Cc: Nishanth Menon <nm@xxxxxx>
> Cc: Matthijs van Duin <matthijsvanduin@xxxxxxxxx>
> Cc: Paul Walmsley <paul@xxxxxxxxx>
> Cc: Peter Ujfalusi <peter.ujfalusi@xxxxxx>
> Cc: Rob Herring <robh+dt@xxxxxxxxxx>
> Cc: Tero Kristo <t-kristo@xxxxxx>
> Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx>
> ---
> .../devicetree/bindings/bus/ti-ipwrap.txt | 153 +++++++++++++++++++++
> 1 file changed, 153 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/ti-ipwrap.txt
>
> diff --git a/Documentation/devicetree/bindings/bus/ti-ipwrap.txt b/Documentation/devicetree/bindings/bus/ti-ipwrap.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/ti-ipwrap.txt
> @@ -0,0 +1,153 @@
> +Texas Instruments 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. Each interconnect target module has a single set of registers for
> +managing clocks, idle modes and interconnect level resets for the module
> +including all the child devices connected to it.
> +
> +The interconnect target module registers are sprinkled into the unused
> +register address space of the first device IP block managed by the
> +interconnect target module.
> +
> +As an interconnect target module can manage more than one child device,
> +the interconnect target module probes the child devices and implements
> +runtime PM for them. The child device drivers can access individual
> +device registers using register ranges provided by the interconnect
> +target module.
> +
> +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-omap3-sham"
> + "ti,sysc-omap-aes"
> + "ti,sysc-mcasp"
> + "ti,sysc-smartreflex"
> + "ti,sysc-usb-host-fs"
> +
> +- reg shall have register areas for the registers implemented
> + for the interconnect target module in question such as
> + revision, sysc and syss and ip0
> +
> +- reg-names shall contain the register names implemented for the
> + interconnect target module in question such as
> + "rev, "sysc", "syss" and "ip0"
> +
> +- ranges shall contain the register ranges 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
> +
> +- clocks shall contain the clocks managed by the interconnect target
> + module, typically at least the clkctrl clock of the module
Where do we document exactly how many clocks?
> +
> +- clock-names shall contain names of the clock managed by the interconnect
> + target module such as "clkctrl"
> +
> +Optional custom properties:
> +
> +- ti,sysc-has-clockactivity interconnect target module supports SYSCONFIG
> + register CLOCKACTIVITY feature, available for
> + "ti,sysc-type1" and "ti,sysc-type2"
> +
> +- ti,sysc-has-enawakeup interconnect target module supports SYSCONFIG
> + register ENAWAKEUP feature, available for
> + "ti,sysc-type1" and "ti,sysc-type2"
> +
> +- ti,sysc-has-softreset interconnect target module supports SYSCONFIG
> + register SOFTRESET feature, available for
> + "ti,sysc-type1" and "ti,sysc-type2"
> +
> +- ti,sysc-has-autoidle interconnect target module supports SYSCONFIG
> + register AUTOIDLE feature, available for
> + "ti,sysc-type1" and "ti,sysc-type2"
> +
> +- ti,sysc-has-dmadisable interconnect target module supports SYSCONFIG
> + DMADISABLE feature, only available for
> + "ti,sysc-type2"
> +
> +- ti,sysc-idlemodes-master list of master idle modes supported by the
> + interconnect target module as documented for
> + SYSCONFIG register MIDLEMODE bits, available on
> + "ti,sysc-type1", "ti,sysc-type2" and
> + "ti,sysc-type3"
> +
> +- ti,sysc-idlemodes-slave list of slave idle modes supported by the
> + interconnect target module as documented for
> + SYSCONFIG register SIDLEMODE bits, available on
> + "ti,sysc-type1", "ti,sysc-type2" and
> + "ti,sysc-type3"
> +
> +- ti,syss-has-reset-status interconnect target module supports SYSSTATUS
> + register RESETDONE feature
> +
> +- ti,quirk-swsup-slave-idle quirk to manually bring module out of idle,
> + rely on smart-idle to put it back to idle
> +
> +- ti,quirk-swsup-master-standby quirk to keep MIDLEMODE bits cleared so that
> + device is kept in force-standby mode
> +
> +Example: Single instance of MUSB controller on omap4 using interconnect ranges:
> +
> + target_module@2b000 { /* 0x4a0ab000, ap 84 12.0 */
target-module@
This unit address doesn't look right?
> + compatible = "ti,sysc-type1", "simple-bus";
Seems fairly complicated to claim "simple-bus"?
> + #address-cells = <2>;
The target module really needs 64-bits of address space?
> + #size-cells = <1>;
> + reg = <0x54 0x400 0x4
> + 0x54 0x404 0x4
> + 0x54 0x408 0x4
> + 0x54 0 0x001000>;
You have overlapping regions. Don't do that.
And for the first 3, if you have that much variation, maybe you need
more specific compatible strings?
> + reg-names = "rev", "sysc", "syss", "ip0";
> + ranges = <0 0 0x54 0 0x001000>;
> + clocks = <&cm_l3init_clkctrl OMAP4_OTG_CLKCTRL 0>;
> + clock-names = "clkctrl";
> +
> + ti,sysc-has-autoidle;
> + ti,sysc-has-enawakeup;
> + ti,sysc-has-softreset;
> + ti,sysc-idlemodes-master = <TI_SYSC_IDLE_FORCE
> + TI_SYSC_IDLE_NONE
> + TI_SYSC_IDLE_SMART>;
> + ti,sysc-idlemodes-slave = <TI_SYSC_IDLE_FORCE
> + TI_SYSC_IDLE_NONE
> + TI_SYSC_IDLE_SMART
> + TI_SYSC_IDLE_SMART_WKUP>;
> +
> + ti,syss-has-reset-status;
> +
> + ti,quirk-swsup-slave-idle;
> + ti,quirk-swsup-master-standby;
> +
> + usb_otg_hs: usb_otg_hs@0 {
> + compatible = "ti,omap4-musb";
> + reg = <0 0 0x7ff>;
> + interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 93 IRQ_TYPE_LEVEL_HIH>;
> + 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>;
> + };
> + };
> +
> +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 in a single interconnet target module.
> --
> 2.11.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
