* [PATCH 1/7] dt-bindings: bus: Minimal TI sysc interconnect target module binding
2017-09-29 22:34 ` Tony Lindgren
@ 2017-09-29 22:34 ` Tony Lindgren
-1 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-09-29 22:34 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Dave Gerlach, Laurent Pinchart, Liam Girdwood, Mark Brown,
Mark Rutland, Mauro Carvalho Chehab, Nishanth Menon,
Matthijs van Duin, Paul Walmsley, Peter Ujfalusi, Rob Herring,
Sakari Ailus, Suman Anna, Tero Kristo, Tomi Valkeinen
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-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
Cc: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Cc: Liam Girdwood <lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Mauro Carvalho Chehab <mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
Cc: Matthijs van Duin <matthijsvanduin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
Cc: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org>
Cc: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
Cc: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
Cc: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
Documentation/devicetree/bindings/bus/ti-sysc.txt | 93 +++++++++++++++++++++++
1 file changed, 93 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/ti-sysc.txt
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.
--
2.14.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 1/7] dt-bindings: bus: Minimal TI sysc interconnect target module binding
@ 2017-09-29 22:34 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-09-29 22:34 UTC (permalink / raw)
To: linux-arm-kernel
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
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 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
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH 1/7] dt-bindings: bus: Minimal TI sysc interconnect target module binding
2017-09-29 22:34 ` Tony Lindgren
@ 2017-10-01 13:11 ` Sebastian Reichel
-1 siblings, 0 replies; 46+ messages in thread
From: Sebastian Reichel @ 2017-10-01 13:11 UTC (permalink / raw)
To: Tony Lindgren
Cc: Mark Rutland, devicetree, Nishanth Menon, Mauro Carvalho Chehab,
Dave Gerlach, Tero Kristo, Tomi Valkeinen, Matthijs van Duin,
Liam Girdwood, Rob Herring, Mark Brown, Sakari Ailus,
Laurent Pinchart, Benoît Cousson, linux-omap, Paul Walmsley,
linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 2512 bytes --]
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
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 1/7] dt-bindings: bus: Minimal TI sysc interconnect target module binding
@ 2017-10-01 13:11 ` Sebastian Reichel
0 siblings, 0 replies; 46+ messages in thread
From: Sebastian Reichel @ 2017-10-01 13:11 UTC (permalink / raw)
To: linux-arm-kernel
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
-------------- 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>
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH 1/7] dt-bindings: bus: Minimal TI sysc interconnect target module binding
2017-10-01 13:11 ` Sebastian Reichel
@ 2017-10-01 17:14 ` Tony Lindgren
-1 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-10-01 17:14 UTC (permalink / raw)
To: Sebastian Reichel
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Dave Gerlach, Laurent Pinchart, Liam Girdwood, Mark Brown,
Mark Rutland, Mauro Carvalho Chehab, Nishanth Menon,
Matthijs van Duin, Paul Walmsley, Peter Ujfalusi, Rob Herring,
Sakari Ailus, Suman Anna, Tero Kristo, Tomi Valkeinen
* Sebastian Reichel <sre-GFxCN5SEZAc@public.gmane.org> [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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 1/7] dt-bindings: bus: Minimal TI sysc interconnect target module binding
@ 2017-10-01 17:14 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-10-01 17:14 UTC (permalink / raw)
To: linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 46+ messages in thread[parent not found: <20171001171406.GL4394-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]
* Re: [PATCH 1/7] dt-bindings: bus: Minimal TI sysc interconnect target module binding
2017-10-01 17:14 ` Tony Lindgren
@ 2017-10-01 20:48 ` Sebastian Reichel
-1 siblings, 0 replies; 46+ messages in thread
From: Sebastian Reichel @ 2017-10-01 20:48 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Dave Gerlach, Laurent Pinchart, Liam Girdwood, Mark Brown,
Mark Rutland, Mauro Carvalho Chehab, Nishanth Menon,
Matthijs van Duin, Paul Walmsley, Peter Ujfalusi, Rob Herring,
Sakari Ailus, Suman Anna, Tero Kristo, Tomi Valkeinen
[-- Attachment #1: Type: text/plain, Size: 2618 bytes --]
Hi,
On Sun, Oct 01, 2017 at 10:14:07AM -0700, Tony Lindgren wrote:
> * Sebastian Reichel <sre-GFxCN5SEZAc@public.gmane.org> [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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 1/7] dt-bindings: bus: Minimal TI sysc interconnect target module binding
@ 2017-10-01 20:48 ` Sebastian Reichel
0 siblings, 0 replies; 46+ messages in thread
From: Sebastian Reichel @ 2017-10-01 20:48 UTC (permalink / raw)
To: linux-arm-kernel
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
-------------- 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>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 1/7] dt-bindings: bus: Minimal TI sysc interconnect target module binding
2017-10-01 20:48 ` Sebastian Reichel
@ 2017-10-01 21:03 ` Tony Lindgren
-1 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-10-01 21:03 UTC (permalink / raw)
To: Sebastian Reichel
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Dave Gerlach, Laurent Pinchart, Liam Girdwood, Mark Brown,
Mark Rutland, Mauro Carvalho Chehab, Nishanth Menon,
Matthijs van Duin, Paul Walmsley, Peter Ujfalusi, Rob Herring,
Sakari Ailus, Suman Anna, Tero Kristo, Tomi Valkeinen
* Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [171001 13:49]:
> Hi,
>
> On Sun, Oct 01, 2017 at 10:14:07AM -0700, Tony Lindgren wrote:
> > * Sebastian Reichel <sre-GFxCN5SEZAc@public.gmane.org> [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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 1/7] dt-bindings: bus: Minimal TI sysc interconnect target module binding
@ 2017-10-01 21:03 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-10-01 21:03 UTC (permalink / raw)
To: linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <20170929223411.9691-2-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]
* Re: [PATCH 1/7] dt-bindings: bus: Minimal TI sysc interconnect target module binding
2017-09-29 22:34 ` Tony Lindgren
@ 2017-10-10 15:46 ` Rob Herring
-1 siblings, 0 replies; 46+ messages in thread
From: Rob Herring @ 2017-10-10 15:46 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Dave Gerlach, Laurent Pinchart, Liam Girdwood, Mark Brown,
Mark Rutland, Mauro Carvalho Chehab, Nishanth Menon,
Matthijs van Duin, Paul Walmsley, Peter Ujfalusi, Sakari Ailus,
Suman Anna, Tero Kristo, Tomi Valkeinen
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-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Cc: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
> Cc: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> Cc: Liam Girdwood <lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: Mauro Carvalho Chehab <mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
> Cc: Matthijs van Duin <matthijsvanduin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
> Cc: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org>
> Cc: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
> Cc: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
> Cc: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> ---
> 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 1/7] dt-bindings: bus: Minimal TI sysc interconnect target module binding
@ 2017-10-10 15:46 ` Rob Herring
0 siblings, 0 replies; 46+ messages in thread
From: Rob Herring @ 2017-10-10 15:46 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 1/7] dt-bindings: bus: Minimal TI sysc interconnect target module binding
2017-10-10 15:46 ` Rob Herring
@ 2017-10-10 16:45 ` Tony Lindgren
-1 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-10-10 16:45 UTC (permalink / raw)
To: Rob Herring
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Dave Gerlach, Laurent Pinchart, Liam Girdwood, Mark Brown,
Mark Rutland, Mauro Carvalho Chehab, Nishanth Menon,
Matthijs van Duin, Paul Walmsley, Peter Ujfalusi, Sakari Ailus,
Suman Anna, Tero Kristo, Tomi Valkeinen
* Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 1/7] dt-bindings: bus: Minimal TI sysc interconnect target module binding
@ 2017-10-10 16:45 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-10-10 16:45 UTC (permalink / raw)
To: linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 2/7] ARM: OMAP2+: Parse module IO range from dts for legacy "ti,hwmods" support
2017-09-29 22:34 ` Tony Lindgren
@ 2017-09-29 22:34 ` Tony Lindgren
-1 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-09-29 22:34 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Lokesh Vutla, Paul Walmsley, Tero Kristo
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.
Cc: "Benoît Cousson" <bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
Cc: Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
Cc: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/mach-omap2/omap_hwmod.c | 80 +++++++++++++++++++++++++++++++++++++++-
arch/arm/mach-omap2/omap_hwmod.h | 5 +++
2 files changed, 84 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -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);
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 2/7] ARM: OMAP2+: Parse module IO range from dts for legacy "ti, hwmods" support
@ 2017-09-29 22:34 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-09-29 22:34 UTC (permalink / raw)
To: linux-arm-kernel
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.
Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/omap_hwmod.c | 80 +++++++++++++++++++++++++++++++++++++++-
arch/arm/mach-omap2/omap_hwmod.h | 5 +++
2 files changed, 84 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -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);
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -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
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 3/7] ARM: OMAP2+: Populate legacy resources for dma and smartreflex
2017-09-29 22:34 ` Tony Lindgren
@ 2017-09-29 22:34 ` Tony Lindgren
-1 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-09-29 22:34 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Lokesh Vutla, Nishanth Menon, Paul Walmsley, Tero Kristo
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.
Cc: "Benoît Cousson" <bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
Cc: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
Cc: Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
Cc: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/mach-omap2/omap_device.c | 137 +++++++++++++++++++++++++++++---------
arch/arm/mach-omap2/omap_device.h | 4 --
2 files changed, 106 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -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;
diff --git a/arch/arm/mach-omap2/omap_device.h b/arch/arm/mach-omap2/omap_device.h
--- a/arch/arm/mach-omap2/omap_device.h
+++ b/arch/arm/mach-omap2/omap_device.h
@@ -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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 3/7] ARM: OMAP2+: Populate legacy resources for dma and smartreflex
@ 2017-09-29 22:34 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-09-29 22:34 UTC (permalink / raw)
To: linux-arm-kernel
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.
Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/omap_device.c | 137 +++++++++++++++++++++++++++++---------
arch/arm/mach-omap2/omap_device.h | 4 --
2 files changed, 106 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -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;
diff --git a/arch/arm/mach-omap2/omap_device.h b/arch/arm/mach-omap2/omap_device.h
--- a/arch/arm/mach-omap2/omap_device.h
+++ b/arch/arm/mach-omap2/omap_device.h
@@ -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
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 5/7] ARM: dts: Add nodes for missing omap4 interconnect target modules
2017-09-29 22:34 ` Tony Lindgren
@ 2017-09-29 22:34 ` Tony Lindgren
-1 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-09-29 22:34 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Laurent Pinchart, Liam Girdwood, Mark Brown, Mark Rutland,
Mauro Carvalho Chehab, Nishanth Menon, Matthijs van Duin,
Paul Walmsley, Peter Ujfalusi, Rob Herring, Sakari Ailus,
Tero Kristo, Tomi Valkeinen
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.
Cc: Benoît Cousson <bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Cc: Liam Girdwood <lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Mauro Carvalho Chehab <mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
Cc: Matthijs van Duin <matthijsvanduin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
Cc: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org>
Cc: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
Cc: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/omap4.dtsi | 159 +++++++++++++++++++++++++++++++++++++++----
1 file changed, 147 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -382,6 +382,19 @@
#interrupt-cells = <2>;
};
+ target-module@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@48078000 {
compatible = "ti,am3352-elm";
reg = <0x48078000 0x2000>;
@@ -442,25 +455,55 @@
clock-frequency = <48000000>;
};
- smartreflex_iva: smartreflex@4a0db000 {
- compatible = "ti,omap4-smartreflex-iva";
- reg = <0x4a0db000 0x80>;
- interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+ target-module@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@0 {
+ compatible = "ti,omap4-smartreflex-iva";
+ reg = <0 0x80>;
+ interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
- smartreflex_core: smartreflex@4a0dd000 {
- compatible = "ti,omap4-smartreflex-core";
- reg = <0x4a0dd000 0x80>;
- interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ target-module@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@0 {
+ compatible = "ti,omap4-smartreflex-core";
+ reg = <0 0x80>;
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
- smartreflex_mpu: smartreflex@4a0d9000 {
- compatible = "ti,omap4-smartreflex-mpu";
- reg = <0x4a0d9000 0x80>;
- interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+ target-module@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@0 {
+ compatible = "ti,omap4-smartreflex-mpu";
+ reg = <0 0x80>;
+ interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
hwspinlock: spinlock@4a0f6000 {
@@ -666,6 +709,19 @@
#iommu-cells = <0>;
};
+ target-module@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@55082000 {
compatible = "ti,omap4-iommu";
reg = <0x55082000 0x100>;
@@ -760,6 +816,56 @@
status = "disabled";
};
+ target-module@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@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@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@48096000 {
compatible = "ti,omap4-mcbsp";
reg = <0x48096000 0xff>; /* L4 Interconnect */
@@ -848,6 +954,19 @@
};
};
+ target-module@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@4a318000 {
compatible = "ti,omap3430-timer";
reg = <0x4a318000 0x80>;
@@ -1063,6 +1182,22 @@
status = "disabled";
};
+ target-module@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@58000000 {
compatible = "ti,omap4-dss";
reg = <0x58000000 0x80>;
--
2.14.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 5/7] ARM: dts: Add nodes for missing omap4 interconnect target modules
@ 2017-09-29 22:34 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-09-29 22:34 UTC (permalink / raw)
To: linux-arm-kernel
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.
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>
---
arch/arm/boot/dts/omap4.dtsi | 159 +++++++++++++++++++++++++++++++++++++++----
1 file changed, 147 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -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
^ permalink raw reply [flat|nested] 46+ messages in thread[parent not found: <20170929223411.9691-6-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]
* Re: [PATCH 5/7] ARM: dts: Add nodes for missing omap4 interconnect target modules
2017-09-29 22:34 ` Tony Lindgren
@ 2017-10-11 15:54 ` Peter Ujfalusi
-1 siblings, 0 replies; 46+ messages in thread
From: Peter Ujfalusi @ 2017-10-11 15:54 UTC (permalink / raw)
To: Tony Lindgren, linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Laurent Pinchart, Liam Girdwood, Mark Brown, Mark Rutland,
Mauro Carvalho Chehab, Nishanth Menon, Matthijs van Duin,
Paul Walmsley, Rob Herring, Sakari Ailus, Tero Kristo,
Tomi Valkeinen
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 09/30/2017 01:34 AM, Tony Lindgren wrote:
> 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.
RX path is disabled, TX is supposed to work.
...
> + target-module@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
s/TX/RX
> + * works with no I2S. See also old Android kernel
> + * omap-mcasp driver for more information.
I'll look at the schema of PandaBoard to see if I can route out the McASP
lines to somewhere then I can add support for this revision to davinci-mcasp
driver.
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 5/7] ARM: dts: Add nodes for missing omap4 interconnect target modules
@ 2017-10-11 15:54 ` Peter Ujfalusi
0 siblings, 0 replies; 46+ messages in thread
From: Peter Ujfalusi @ 2017-10-11 15:54 UTC (permalink / raw)
To: linux-arm-kernel
?
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 09/30/2017 01:34 AM, Tony Lindgren wrote:
> 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.
RX path is disabled, TX is supposed to work.
...
> + 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
s/TX/RX
> + * works with no I2S. See also old Android kernel
> + * omap-mcasp driver for more information.
I'll look at the schema of PandaBoard to see if I can route out the McASP
lines to somewhere then I can add support for this revision to davinci-mcasp
driver.
--
P?ter
^ permalink raw reply [flat|nested] 46+ messages in thread[parent not found: <f5c57f0b-1423-c362-0fda-4069b77a2e38-l0cyMroinI0@public.gmane.org>]
* Re: [PATCH 5/7] ARM: dts: Add nodes for missing omap4 interconnect target modules
2017-10-11 15:54 ` Peter Ujfalusi
@ 2017-10-11 16:58 ` Sebastian Reichel
-1 siblings, 0 replies; 46+ messages in thread
From: Sebastian Reichel @ 2017-10-11 16:58 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: Tony Lindgren, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Laurent Pinchart, Liam Girdwood, Mark Brown, Mark Rutland,
Mauro Carvalho Chehab, Nishanth Menon, Matthijs van Duin,
Paul Walmsley, Rob Herring, Sakari Ailus, Tero Kristo,
Tomi Valkeinen
[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]
Hi Peter,
On Wed, Oct 11, 2017 at 06:54:04PM +0300, Peter Ujfalusi wrote:
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
> On 09/30/2017 01:34 AM, Tony Lindgren wrote:
> > 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.
>
> RX path is disabled, TX is supposed to work.
>
> ...
>
> > + target-module@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
>
> s/TX/RX
>
> > + * works with no I2S. See also old Android kernel
> > + * omap-mcasp driver for more information.
>
> I'll look at the schema of PandaBoard to see if I can route out the McASP
> lines to somewhere then I can add support for this revision to davinci-mcasp
> driver.
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 5/7] ARM: dts: Add nodes for missing omap4 interconnect target modules
@ 2017-10-11 16:58 ` Sebastian Reichel
0 siblings, 0 replies; 46+ messages in thread
From: Sebastian Reichel @ 2017-10-11 16:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi Peter,
On Wed, Oct 11, 2017 at 06:54:04PM +0300, Peter Ujfalusi wrote:
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
> On 09/30/2017 01:34 AM, Tony Lindgren wrote:
> > 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.
>
> RX path is disabled, TX is supposed to work.
>
> ...
>
> > + 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
>
> s/TX/RX
>
> > + * works with no I2S. See also old Android kernel
> > + * omap-mcasp driver for more information.
>
> I'll look at the schema of PandaBoard to see if I can route out the McASP
> lines to somewhere then I can add support for this revision to davinci-mcasp
> driver.
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>
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH 5/7] ARM: dts: Add nodes for missing omap4 interconnect target modules
2017-10-11 16:58 ` Sebastian Reichel
@ 2017-10-12 6:07 ` Peter Ujfalusi
-1 siblings, 0 replies; 46+ messages in thread
From: Peter Ujfalusi @ 2017-10-12 6:07 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Mark Rutland, devicetree, Nishanth Menon, Mauro Carvalho Chehab,
Matthijs van Duin, Tony Lindgren, Tomi Valkeinen, Liam Girdwood,
Rob Herring, Tero Kristo, Mark Brown, Sakari Ailus,
Laurent Pinchart, Benoît Cousson, linux-omap, Paul Walmsley,
linux-arm-kernel
Hi Sebastian,
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 2017-10-11 19:58, Sebastian Reichel wrote:
>> I'll look at the schema of PandaBoard to see if I can route out the McASP
>> lines to somewhere then I can add support for this revision to davinci-mcasp
>> driver.
>
> 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
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.
> (*) My patches use McBSP instead of McASP, since McASP looked
> mostly unsupported. Motorola's kernel uses McASP.
If I have something I might ask you for testing, if it is OK.
>
> -- Sebastian
>
- Péter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 5/7] ARM: dts: Add nodes for missing omap4 interconnect target modules
@ 2017-10-12 6:07 ` Peter Ujfalusi
0 siblings, 0 replies; 46+ messages in thread
From: Peter Ujfalusi @ 2017-10-12 6:07 UTC (permalink / raw)
To: linux-arm-kernel
?Hi Sebastian,
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 2017-10-11 19:58, Sebastian Reichel wrote:
>> I'll look at the schema of PandaBoard to see if I can route out the McASP
>> lines to somewhere then I can add support for this revision to davinci-mcasp
>> driver.
>
> 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
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.
> (*) My patches use McBSP instead of McASP, since McASP looked
> mostly unsupported. Motorola's kernel uses McASP.
If I have something I might ask you for testing, if it is OK.
>
> -- Sebastian
>
- P?ter
^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <da8d1d7f-f16d-8d71-cf49-acff79614610-l0cyMroinI0@public.gmane.org>]
* Re: [PATCH 5/7] ARM: dts: Add nodes for missing omap4 interconnect target modules
2017-10-12 6:07 ` Peter Ujfalusi
@ 2017-10-12 8:40 ` Matthijs van Duin
-1 siblings, 0 replies; 46+ messages in thread
From: Matthijs van Duin @ 2017-10-12 8:40 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: Sebastian Reichel, Tony Lindgren,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Laurent Pinchart, Liam Girdwood, Mark Brown, Mark Rutland,
Mauro Carvalho Chehab, Nishanth Menon, Paul Walmsley,
Rob Herring, Sakari Ailus, Tero Kristo, Tomi Valkeinen
On Thu, Oct 12, 2017 at 09:07:55AM +0300, Peter Ujfalusi wrote:
> 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.
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?)
> I wonder how Motorola is using the McASP as the OMAP4 version
> (officially) does not support I2S.
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 5/7] ARM: dts: Add nodes for missing omap4 interconnect target modules
@ 2017-10-12 8:40 ` Matthijs van Duin
0 siblings, 0 replies; 46+ messages in thread
From: Matthijs van Duin @ 2017-10-12 8:40 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 12, 2017 at 09:07:55AM +0300, Peter Ujfalusi wrote:
> 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.
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?)
> I wonder how Motorola is using the McASP as the OMAP4 version
> (officially) does not support I2S.
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 5/7] ARM: dts: Add nodes for missing omap4 interconnect target modules
2017-10-12 8:40 ` Matthijs van Duin
@ 2017-10-12 9:10 ` Peter Ujfalusi
-1 siblings, 0 replies; 46+ messages in thread
From: Peter Ujfalusi @ 2017-10-12 9:10 UTC (permalink / raw)
To: Sebastian Reichel, Tony Lindgren, linux-omap, linux-arm-kernel,
Benoît Cousson, devicetree, Laurent Pinchart, Liam Girdwood,
Mark Brown, Mark Rutland, Mauro Carvalho Chehab, Nishanth Menon,
Paul Walmsley, Rob Herring, Sakari Ailus, Tero Kristo,
Tomi Valkeinen
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 2017-10-12 11:40, Matthijs van Duin wrote:
> On Thu, Oct 12, 2017 at 09:07:55AM +0300, Peter Ujfalusi wrote:
>> 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.
>
> 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?)
>
>> I wonder how Motorola is using the McASP as the OMAP4 version
>> (officially) does not support I2S.
>
> 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.
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.
>
> Matthijs
>
- Péter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 5/7] ARM: dts: Add nodes for missing omap4 interconnect target modules
@ 2017-10-12 9:10 ` Peter Ujfalusi
0 siblings, 0 replies; 46+ messages in thread
From: Peter Ujfalusi @ 2017-10-12 9:10 UTC (permalink / raw)
To: linux-arm-kernel
?
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 2017-10-12 11:40, Matthijs van Duin wrote:
> On Thu, Oct 12, 2017 at 09:07:55AM +0300, Peter Ujfalusi wrote:
>> 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.
>
> 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?)
>
>> I wonder how Motorola is using the McASP as the OMAP4 version
>> (officially) does not support I2S.
>
> 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.
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.
>
> Matthijs
>
- P?ter
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 5/7] ARM: dts: Add nodes for missing omap4 interconnect target modules
2017-10-11 15:54 ` Peter Ujfalusi
@ 2017-10-13 16:46 ` Tony Lindgren
-1 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-10-13 16:46 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Laurent Pinchart, Liam Girdwood, Mark Brown, Mark Rutland,
Mauro Carvalho Chehab, Nishanth Menon, Matthijs van Duin,
Paul Walmsley, Rob Herring, Sakari Ailus, Tero Kristo,
Tomi Valkeinen
Hi,
* Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org> [171011 08:56]:
> On 09/30/2017 01:34 AM, Tony Lindgren wrote:
> > + target-module@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
>
> s/TX/RX
>
> > + * works with no I2S. See also old Android kernel
> > + * omap-mcasp driver for more information.
Below is a fix for the RX comment.
Regards,
Tony
8< ------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
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 <peter.ujfalusi-l0cyMroinI0@public.gmane.org>, the rx path on macsp
is disabled and only tx is usable if the davinci-mcasp driver is updated for
it.
Reported-by: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/omap4.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 5/7] ARM: dts: Add nodes for missing omap4 interconnect target modules
@ 2017-10-13 16:46 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-10-13 16:46 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
* Peter Ujfalusi <peter.ujfalusi@ti.com> [171011 08:56]:
> On 09/30/2017 01:34 AM, Tony Lindgren wrote:
> > + 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
>
> s/TX/RX
>
> > + * works with no I2S. See also old Android kernel
> > + * omap-mcasp driver for more information.
Below is a fix for the RX comment.
Regards,
Tony
8< ------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
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 <peter.ujfalusi@ti.com>, the rx path on macsp
is disabled and only tx is usable if the davinci-mcasp driver is updated for
it.
Reported-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap4.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -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
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 6/7] ARM: dts: Configure SmartReflex only to idle the interconnect target module
2017-09-29 22:34 ` Tony Lindgren
@ 2017-09-29 22:34 ` Tony Lindgren
-1 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-09-29 22:34 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Lokesh Vutla, Nishanth Menon, Paul Walmsley, Rob Herring,
Tero Kristo
The TRM has marked dra7 SmartReflex as reserved and we should not
touch those registers as pointed out by Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>.
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.
Cc: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
Cc: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
Cc: Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/dra7.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1497,6 +1497,32 @@
};
};
+ target-module@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@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@48880000 {
compatible = "ti,dwc3";
ti,hwmods = "usb_otg_ss1";
--
2.14.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 6/7] ARM: dts: Configure SmartReflex only to idle the interconnect target module
@ 2017-09-29 22:34 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-09-29 22:34 UTC (permalink / raw)
To: linux-arm-kernel
The TRM has marked dra7 SmartReflex as reserved and we should not
touch those registers as pointed out by Nishanth Menon <nm@ti.com>.
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.
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/dra7.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -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
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 7/7] ARM: dts: Use ti-sysc module driver for omap4 musb
2017-09-29 22:34 ` Tony Lindgren
@ 2017-09-29 22:34 ` Tony Lindgren
-1 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-09-29 22:34 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA, Bin Liu
Let's make use of the generic ti-sysc module for musb to have
a child device with working runtime PM.
Cc: Bin Liu <b-liu-l0cyMroinI0@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/omap4.dtsi | 36 ++++++++++++++++++++++++------------
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -1105,19 +1105,31 @@
reg-names = "otghs_control";
};
- usb_otg_hs: usb_otg_hs@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@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@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@4b501000 {
--
2.14.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 7/7] ARM: dts: Use ti-sysc module driver for omap4 musb
@ 2017-09-29 22:34 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-09-29 22:34 UTC (permalink / raw)
To: linux-arm-kernel
Let's make use of the generic ti-sysc module for musb to have
a child device with working runtime PM.
Cc: Bin Liu <b-liu@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap4.dtsi | 36 ++++++++++++++++++++++++------------
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -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
^ permalink raw reply [flat|nested] 46+ messages in thread[parent not found: <20170929223411.9691-8-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]
* Re: [PATCH 7/7] ARM: dts: Use ti-sysc module driver for omap4 musb
2017-09-29 22:34 ` Tony Lindgren
@ 2017-10-10 17:01 ` Tony Lindgren
-1 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-10-10 17:01 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA, Bin Liu
* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [170929 15:35]:
> Let's make use of the generic ti-sysc module for musb to have
> a child device with working runtime PM.
...
> + target-module@4a0ab000 {
> + compatible = "ti,sysc-omap4";
> ti,hwmods = "usb_otg_hs";
And this should be compatible with "ti,sysc-omap2", I messed it up while
changing from type1 and 2 to omap2 and omap4. Will apply the updated
version below.
Regards,
Tony
8< ---------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
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.
Cc: Bin Liu <b-liu-l0cyMroinI0@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/omap4.dtsi | 36 ++++++++++++++++++++++++------------
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -1117,19 +1117,31 @@
reg-names = "otghs_control";
};
- usb_otg_hs: usb_otg_hs@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@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@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@4b501000 {
--
2.14.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 7/7] ARM: dts: Use ti-sysc module driver for omap4 musb
@ 2017-10-10 17:01 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2017-10-10 17:01 UTC (permalink / raw)
To: linux-arm-kernel
* Tony Lindgren <tony@atomide.com> [170929 15:35]:
> Let's make use of the generic ti-sysc module for musb to have
> a child device with working runtime PM.
...
> + target-module at 4a0ab000 {
> + compatible = "ti,sysc-omap4";
> ti,hwmods = "usb_otg_hs";
And this should be compatible with "ti,sysc-omap2", I messed it up while
changing from type1 and 2 to omap2 and omap4. Will apply the updated
version below.
Regards,
Tony
8< ---------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
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.
Cc: Bin Liu <b-liu@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap4.dtsi | 36 ++++++++++++++++++++++++------------
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -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
^ permalink raw reply [flat|nested] 46+ messages in thread