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