* Hans de Goede <hdegoede@xxxxxxxxxx> [170816 10:38]: > Hi, > > On 16-08-17 17:54, Tony Lindgren wrote: > > * Hans de Goede <hdegoede@xxxxxxxxxx> [170815 13:06]: > > > On some devices the USB Type-C port power (USB PD 2.0) negotiation is > > > done by a separate port-controller IC, while the current limit is > > > controlled through another (charger) IC. > > > > > > It has been decided to model this by modelling the external Type-C > > > power brick (adapter/charger) as a power-supply class device which > > > supplies the charger-IC, with its voltage-now and current-max representing > > > the negotiated voltage and max current draw. > > > > > > This commit adds a power_supply_set_input_current_limit_from_supplier > > > helper function which charger power-supply drivers can call to get > > > the max-current from their supplier and have this applied > > > through their set_property call-back to their input-current-limit. > > > > Hmm so can this also be used for the USB gadget subsystem > > to tell charge controller when it's OK to enable 500mA > > charging after enumeration? > > I'm not sure that that would be best modeled this way. Perhaps > the phy-driver can directly control the gpio you have for that, > that seems better then trying to solve this with cross subsystem > calls which are always tricky. I don't think the phy driver knows either when the system has enumerated as a gadget.. > > FYI, that's controlled by the bq24190 pin named OTG that should > > be only set high after enumeration. Any ideas how that is wired > > on your device? Does it connect to the USB PHY or to a GPIO > > line? > > I believe it is just hardwired to be logical high all the time > on my board. OK thanks for checking. Tony _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
