Re: [PATCH 1/5] dt/bindings: Add binding for the DA8xx MUSB driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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 devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux