Hi, Sergei Shtylyov <sergei.shtylyov@xxxxxxxxxxxxxxxxxx> writes: > On 2/19/2016 10:23 AM, Felipe Balbi wrote: > >>>>>>> This adds two functions to get DT properties "mentor,power" and "dr_mode": >>>>>>> musb_get_power() and musb_mode musb_get_mode() >>>>>>> >>>>>>> Signed-off-by: Petr Kulhavy <petr@xxxxxxxxx> >>>>>> seems like I don't have patch 1/5. After fixing Sergei's comments, >>>>>> please resend with his Acked-by already in place. >>>>>> >>>>>> thanks >>>>> Hi Felipe, >>>>> >>>>> I will do as soon as the patch 1/5 gets approved. >>>>> It seem to be a bit stuck at the moment as Rob Herring from the DT wants >>>>> the "mentor,power" >>>>> to be represented as a regulator, whereas Sergei and me want to stick to >>>>> the existing "mentor,power" integer property. >>>>> >>>>> As soon as this get clarified I will do the final updates and send the >>>>> patch again. >>>>> Maybe this is something you can help to clarify? >>>> >>>> I don't think that makes sense as a regulator. It's just a number which >>>> gets passed to USB Core as is. >>> >>> Well, in case of DaVinci's it's an external GPIO controlled >>> regulator indeed. >> >> oh, I see. Not controller by SetPortPower. That's a shame. >> >>>> However, it seems like everything in kernel right now is passing it as >>>> 500. So why don't you deprecate that property, hardcode it to 500 and >>>> avoid the problem altogether ? >>> >>> OMAP boards can only supply 100 mA, AFAIK. Isn't it too early for the >>> deprecation? :-) >> >> $ git --no-pager grep -e mentor,power > > Grep for "power =" in arch/arm/boot/dts/ instead. OMAP props didn't even > have "mentor," prefix. :-/ s**t! Okay, then we can't ignore the detail heh. Adding Bin here to see if he can patch those older devicetree files. -- balbi
Attachment:
signature.asc
Description: PGP signature
