Thread (50 messages) 50 messages, 3 authors, 2015-06-24

Re: [PATCH 17/17] ARM: dts: omap4: Use "syscon-otghs" instead of "ctrl-module" in USB node

From: Tony Lindgren <hidden>
Date: 2015-06-24 11:46:20
Also in: linux-arm-kernel, linux-omap, lkml

* Kishon Vijay Abraham I [off-list ref] [150624 04:23]:
On Wednesday 24 June 2015 04:11 PM, Tony Lindgren wrote:
quoted
* Kishon Vijay Abraham I [off-list ref] [150623 05:02]:
quoted
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -852,12 +852,6 @@
 			};
 		};

-		omap_control_usbotg: control-phy@4a00233c {
-			compatible = "ti,control-phy-otghs";
-			reg = <0x4a00233c 0x4>;
-			reg-names = "otghs_control";
-		};
-
 		usb_otg_hs: usb_otg_hs@4a0ab000 {
 			compatible = "ti,omap4-musb";
 			reg = <0x4a0ab000 0x7ff>;
@@ -870,7 +864,7 @@
 			multipoint = <1>;
 			num-eps = <16>;
 			ram-bits = <12>;
-			ctrl-module = <&omap_control_usbotg>;
+			syscon-otghs = <&scm_conf 0x33c>;
 		};

 		aes: aes@4b501000 {
We should still keep a separate entry for the phy in the dtsi
files. And the phy should be a child of the scm_conf area in the
dtsi file.

This is because the scm and usb_otg_hs are separate devices and
can be clocked separately. So the phy driver needs to be a
separate driver to avoid spaghetti code and issues with clocking.
AFAIK SCM is clocked by L4CFG_L4_GICLK which is either free running or is
managed automatically by the HW i.e gated when there is no access to the
CTRL_MODULE_CORE registers.
The point is they are separate devices on the interconnect. And we
don't want to add dependencies between separate devices. And there
is nothing stopping us from starting to idle the SCM module.
 
Having a separate control-PHY driver only to do a regmap update to SCM is
unnecessary IMHO.
Not true. The phy driver can be generic and used by multiple platforms.

And the phy driver should be capable of idling the phy separately
independent of the USB module. And the phy driver should be able to
tell the system things like ID pin status, VBUS status and so on.

So to summarize, we are _not_ going to start tinkering with the sycon
registers directly from random device drivers in a separate IO space.

Anything using the syscon registers must implement a driver for some
Linux generic framework such as phy, clock, or regulator framework.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help