From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergei Shtylyov Subject: Re: [PATCH 1/5] dt/bindings: Add binding for the DA8xx MUSB driver Date: Wed, 17 Feb 2016 20:29:02 +0300 Message-ID: <56C4ADDE.50708@cogentembedded.com> References: <1455188466-10879-1-git-send-email-petr@barix.com> <20160212162110.GA21833@rob-hp-laptop> <56BE15D8.3020303@cogentembedded.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Rob Herring Cc: Petr Kulhavy , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Linux USB List List-Id: devicetree@vger.kernel.org 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 >>>> --- >>>> .../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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html