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, 24 Feb 2016 17:07:43 +0300 Message-ID: <56CDB92F.1080507@cogentembedded.com> References: <1455188466-10879-1-git-send-email-petr@barix.com> <20160212162110.GA21833@rob-hp-laptop> <56BE1531.8060800@barix.com> <56C4B870.2070707@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. Sorry about late reply, I kept forgetting about this mail. On 02/17/2016 09:51 PM, Rob Herring wrote: >>>>>> + - mentor,power : Specifies the maximum current in milliamperes the >>>>>> controller can >>>>>> + supply in host mode. >>>>> >>>>> >>>>> Still a no for me. 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. Also, given this has nothing to do with >>>>> MUSB h/w, however this is described should be generic. >>>> >>>> >>>> >>>> I understand your point that the description should be generic. >>>> However the USB 2.0 specification does not define any relation between >>>> the >>>> bMaxPower provided by the device and the actual power control. >>>> As far as I understand the value just serves the purpose to raise a flag >>>> to >>>> the user if the attached device would draw too much power, and not to >>>> enable >>>> it at all. >>> >>> >>> That won't really work given devices lie. My bus powered USB disk >>> enclosure reports something like 10mA. That's pretty good considering >>> I have a 5W drive in it. >> >> >>>> Further, the value used by the protocol is not necessarily related to the >>>> real current that can be supported. The maximum current supported by the >>>> protocol is 510mA. >>>> >>>> For instance on my development board the real maximum current is limited >>>> only by the mains power-supply used. >>>> So it cannot even be modelled in the DT as a regulator because the >>>> power-supply is not part of the HW and >>>> everybody can take a different one. >>> >>> Not part of which h/w? Different for everyone is exactly why Vbus >>> supply should be described in DT. >> >> I'm afraid you're misunderstanding the nature of VBUS regulator still. >> It's a voltage regulator with some maximum value of the current that can be >> sourced from it when it's powered (+5 V). The power chip can typically >> detect and report the over-current condition inj which case VBUS will be >> turned off). > > Yes, I understand that exactly. I've seen and reviewed a USB circuit > or two. You're describing a regulator, I'm saying describe the > regulator in DT and Petr is saying that's too complex. The why ask about the Vbus current regulation if you know it's a voltage regulator? :-) >>>> So defining a regulator just to store this arbitrary USB 2.0 value is a >>>> bit >>>> overkill for me. >>> >>> If it is just arbitrary, then put it into the driver. I would do 500mA >> >> You clearly misunderstand things. The regulator used depends on the board >> design, the driver (or glue in this case) doesn't, it's just SoC specific. >> That's why this power budget thing ended up in the platform data in the >> first place... > > The driver needs to be able to query the supply and get the current > limit. We have the technology. Looking at the docs, I guess you mean the "regulator-input-current-limit-microamp" prop... >>> and be done with it. I'd guess there is nothing real behind the >>> current default of 250mA. >> >> >> 500 mA actually, it's multiplied by 2. > > Ok. For 2 ports? No, MUSB has only a single port, the unit was 2 mA. > In any case, if there is effectively no limit (Vbus comes from the > wall), then yes a regulator is probably an overkill. So make the case > with no Vbus regulator (or regulator with no limit set) in DT be the > max current. However, if the controller has a signal to turn on/off > Vbus, then that should be modeled as a regulator. Well, actually DRVVBUS controls the VBUS charge-pump in the TI MUSB implementations, it's not something described by the Mentor's docs... > 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