Hello.
On 02/16/2016 10:53 PM, Rob Herring wrote:
This adds DT support for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
Signed-off-by: Petr Kulhavy <petr@xxxxxxxxx>
---
.../devicetree/bindings/usb/da8xx-usb.txt | 47
++++++++++++++++++++++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt
b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
new file mode 100644
index 0000000..62dcc51
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
@@ -0,0 +1,47 @@
+TI DA8xx MUSB
+~~~~~~~~~~~~~
+For DA830 and DA850 platforms.
+
+Required properties:
+~~~~~~~~~~~~~~~~~~~~
+ - compatible : Should be set to "ti,da830-musb".
+
+ - reg: Offset and length of the USB controller register set.
+
+ - interrupts: The USB interrupt number.
+
+ - interrupt-names: Should be set to "mc".
+
+ - dr_mode: The USB operation mode. Should be one of "host",
"peripheral" or "otg".
+
+ - mentor,power : Specifies the maximum current in milliamperes the
controller can
+ supply in host mode.
Still a no for me.
Note that it's been used twice already, for musb_dsps.c and omap2430.c
glues (in the latter case the prop was called just "power"). The
corresponding field is a part of the 'struct musb_hdrc_platform_data'.
Copied from platform_data is exactly what is wrong with this binding
Why? This is a usual way for the platform device to DT migration, no?..
and you already said those were bad examples.
No, I said that about the members of 'struct musb_hdrc_config' (referenced
from the MUSB platform data) that describes the MUSB hardware config. and
should have been filled based on the "compatible" prop instead of being
represented in the device tree props. I didn't complain about the "true"
platform data IIRC...
Looks like this just sets hcd->power_budget. This
property may not be a regulator, but ultimately the value depends on
some regulator supplying Vbus.
Yes.
Also, given this has nothing to do with MUSB h/w,
This regulator is controlled by the DRVVBUS signal from MUSB h/w!
How does a single signal control amount of current? What I should say
It controls the VBUS voltage (0/+5 V), not the current. The amount of
current that can be sourced by the bus seems to be an inherent feature of the
regualtor as far as I remember the corresponding chip datasheets...
is the max current has nothing to do with the MUSB controller. It is a
property of some regulator.
But it's not the current regulator...
however this is described should be generic.
You mean just "power", w/o the vendor prefix?
No. I mean generic in the sense of common for all USB host bindings,
OK, it's just that currently it's conveyed to the USB stack by each host
driver's individual platform data, not only MUSB's but also Chipidea's, etc.
not generic as in a meaningless, unclear name.
I'm seeing the generically named "hub-power-budget" prop parsed by the
FHCI driver though, maybe we should stick to that.
Rob
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
