Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2016-04-06 Thread Mark Brown 
On Wed, Apr 06, 2016 at 09:15:26AM +0800, Peter Chen wrote:

> > > No, this comment is common one, but only for SW detection. Eg, when
> > > the PMIC tells you it is a SDP, you can't notify to charger IC about
> > > 500mA at once, you need to do it after host allows you to do it.

> > Note that this isn't just the charger device that needs to constrain
> > current consumption - it's the entire system.  You can't charge to the
> > limit for system power draw if the USB controller is supplying the main
> > system rail.

> Sorry, I can't catch up you. USB Host (SDP or CDP) supplies power for
> USB device (not only USB controller, it is the whole system), it can
> supply more power after set configuration. See 1.4.13 from BC 1.2.

You're saying we need to notify the charger.  The charger does not in
general control the overall system current draw.


signature.asc
Description: PGP signature

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2016-04-05 Thread Peter Chen 
On Tue, Apr 05, 2016 at 09:53:05AM -0700, Mark Brown wrote:
> 
> > > The framework does not want to focus on charger detection too much,
> > > and just supplies one callback '->charger_detect()' for user to be
> > > implemented if they ensure they need to do the SW charger detection
> > > manually (Note: must at the right time to do the SW detection.). So
> > > the usb charger just focus on dealing with the usb gadget power
> > > negotiation, and it does not need to care much how to do charger
> > > detection on your platform.
> 
> > No, this comment is common one, but only for SW detection. Eg, when
> > the PMIC tells you it is a SDP, you can't notify to charger IC about
> > 500mA at once, you need to do it after host allows you to do it.
> 
> Note that this isn't just the charger device that needs to constrain
> current consumption - it's the entire system.  You can't charge to the
> limit for system power draw if the USB controller is supplying the main
> system rail.

Sorry, I can't catch up you. USB Host (SDP or CDP) supplies power for
USB device (not only USB controller, it is the whole system), it can
supply more power after set configuration. See 1.4.13 from BC 1.2.

An SDP expects a downstream device with a good battery to draw less than
2.5mA average when unconnected or suspended, up to 100mA maximum when
connected and not configured and not suspended, and up to 500mA maximum
if so configured and not suspended.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2016-04-05 Thread Mark Brown 
On Tue, Apr 05, 2016 at 05:43:20PM +0800, Peter Chen wrote:
> On Tue, Apr 05, 2016 at 05:34:02PM +0800, Baolin Wang wrote:

> > Mark, could you please address Peter's comments about if the the
> > wm831x can charge more than 1500mA for DCP? (I have no environment to
> > test wm831x) Thanks.

> I don't want you or Mark to test at hardware, I just would like to see
> some code that how PMIC, wm831x, and USB gadget driver work together.

If you want to see this running it's going to be easier for you to just
write an equivalent driver that just does a print instead of writing to
a register (which is all that the wm831x driver boils down to) and test
on hardware you have in front of you.


signature.asc
Description: PGP signature

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2016-04-05 Thread Mark Brown 
On Tue, Apr 05, 2016 at 04:12:22PM +0800, Peter Chen wrote:
> On Tue, Apr 05, 2016 at 03:54:31PM +0800, Baolin Wang wrote:
> > Hi Peter,

> > Yeah, this patchset did not give an example to read charger type from
> > PMIC registers. (Cause now the user 'wm831x_power' don't need this.)
> > But I think user can get it easily by implementing below callbacks.
> > (1) gadget->ops->get_charger_type();
> > (2) power_supply_get_property(uchger->psy, POWER_SUPPLY_PROP_CHARGE_TYPE, 
> > );
> > (3) uchger->get_charger_type();

> I just would like if you can have this, then, we (you) can test it, eg,
> you can test if the wm831x can charge more than 1500mA for DCP.

The hardware in the wm831x is extremely simple here - all it does is
take in the power rail from USB, apply a current limit to it and feed
it into the power source selection circuitry it has.  It doesn't see any
of the USB data signals, it relies on the rest of the system to identify
and configure the limit by writing a register.  The highest limit it
supports is 1.8A.

> > The framework does not want to focus on charger detection too much,
> > and just supplies one callback '->charger_detect()' for user to be
> > implemented if they ensure they need to do the SW charger detection
> > manually (Note: must at the right time to do the SW detection.). So
> > the usb charger just focus on dealing with the usb gadget power
> > negotiation, and it does not need to care much how to do charger
> > detection on your platform.

> No, this comment is common one, but only for SW detection. Eg, when
> the PMIC tells you it is a SDP, you can't notify to charger IC about
> 500mA at once, you need to do it after host allows you to do it.

Note that this isn't just the charger device that needs to constrain
current consumption - it's the entire system.  You can't charge to the
limit for system power draw if the USB controller is supplying the main
system rail.


signature.asc
Description: PGP signature

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2016-04-05 Thread Baolin Wang 
On 5 April 2016 at 17:43, Peter Chen  wrote:
> On Tue, Apr 05, 2016 at 05:34:02PM +0800, Baolin Wang wrote:
>> On 5 April 2016 at 16:12, Peter Chen  wrote:
>> > On Tue, Apr 05, 2016 at 03:54:31PM +0800, Baolin Wang wrote:
>> >> Hi Peter,
>> >>
>> >> On 5 April 2016 at 14:46, Peter Chen  wrote:
>> >> >
>> >> > We are thinking USB charger framework for Freescale i.mx SoC series,
>> >> > since our internal framework is not good enough.
>> >> > So I have more questions for your framework since there are many
>> >> > different USB charger designs, and I hope it is universal.
>> >>
>> >> Great, thanks for your attention and suggestions.
>> >>
>> >> >
>> >> > - I would like to see your all code to let the charger work, eg
>> >> > you have said the charger detection is done by PMIC automatically,
>> >> > but I did not find your PMIC code to read charger type.
>> >>
>> >> Yeah, this patchset did not give an example to read charger type from
>> >> PMIC registers. (Cause now the user 'wm831x_power' don't need this.)
>> >> But I think user can get it easily by implementing below callbacks.
>> >> (1) gadget->ops->get_charger_type();
>> >> (2) power_supply_get_property(uchger->psy, POWER_SUPPLY_PROP_CHARGE_TYPE, 
>> >> );
>> >> (3) uchger->get_charger_type();
>> >>
>> >
>> > I just would like if you can have this, then, we (you) can test it, eg,
>> > you can test if the wm831x can charge more than 1500mA for DCP.
>>
>> Mark, could you please address Peter's comments about if the the
>> wm831x can charge more than 1500mA for DCP? (I have no environment to
>> test wm831x) Thanks.
>>
>
> I don't want you or Mark to test at hardware, I just would like to see
> some code that how PMIC, wm831x, and USB gadget driver work together.

The whole code are in this patchset.

>
>> >> >
>> >> > Besides, how you can make sure the charger detection has finished
>> >> > before the framework handles USB_CHARGER_PRESENT event?
>> >>
>> >> I think we don't need to care about this situation. If the charger
>> >> type is 'UNKNOWN_TYPE' (maybe charger detection is not finished yet),
>> >> the charger framework will not set current (current is 0) for power
>> >> driver.
>> >
>> > Then, when we notify the charger IC for larger current, eg, for DCP.
>>
>> I suppose If the usb charger framework gets the charger type, then
>> notify the charger IC for larger current.
>
> It is no problem for software detection, but for hardware one, it must
> make sure it sends "USB_CHARGER_PRESENT" event after detection has
> finished, otherwise no one will notify charger framework for DCP.

Yeah, the hardware detection should guarantee charger detection will
be finished firstly.

>
>>
>> >
>> >>
>> >> >
>> >> > - I commented the current limit at different situations for USB
>> >> > charger last time, but I have not seen your further comments.
>> >> > I would like give it again. For DCP, you can notify charger IC
>> >> > once you get the charger type. But for CDP/SDP, you need to
>> >> > notify charger IC after set configuration has finished, since
>> >> > the host may still not be ready to give high current.
>> >>
>> >> As my understanding, if the usb charger framework get the charger
>> >> type, it means we can notify the power driver to set the current. If
>> >> you don't ready for setting current, please don't give the charger
>> >> type to usb charger framework.
>> >>
>> >> The framework does not want to focus on charger detection too much,
>> >> and just supplies one callback '->charger_detect()' for user to be
>> >> implemented if they ensure they need to do the SW charger detection
>> >> manually (Note: must at the right time to do the SW detection.). So
>> >> the usb charger just focus on dealing with the usb gadget power
>> >> negotiation, and it does not need to care much how to do charger
>> >> detection on your platform.
>> >
>> > No, this comment is common one, but only for SW detection. Eg, when
>> > the PMIC tells you it is a SDP, you can't notify to charger IC about
>> > 500mA at once, you need to do it after host allows you to do it.
>>
>> Well. Sounds reasonable. I just give an ugly example to implement the
>> 'gadget->ops->get_charger_type()' method to get the charger type.
>>
>> enum usb_charger_type get_charger_type(struct usb_gadget *gadget)
>> {
>> if (host is allowed)
>> read charger type from PMIC;
>> else
>> return UNKNOWN_TYPE;
>> }
>>
>> So that will makes usb charger do not need to care about too much to
>> make things more complicated. Or do you have any other good
>> suggestions? Thanks.
>>
>
> Since it is a USB charger, you had to be involved with USB stuffs:).

OK. Maybe I need to do some investigation about that. Thanks.

>
> --
>
> Best Regards,
> Peter Chen



-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2016-04-05 Thread Peter Chen 
On Tue, Apr 05, 2016 at 05:34:02PM +0800, Baolin Wang wrote:
> On 5 April 2016 at 16:12, Peter Chen  wrote:
> > On Tue, Apr 05, 2016 at 03:54:31PM +0800, Baolin Wang wrote:
> >> Hi Peter,
> >>
> >> On 5 April 2016 at 14:46, Peter Chen  wrote:
> >> >
> >> > We are thinking USB charger framework for Freescale i.mx SoC series,
> >> > since our internal framework is not good enough.
> >> > So I have more questions for your framework since there are many
> >> > different USB charger designs, and I hope it is universal.
> >>
> >> Great, thanks for your attention and suggestions.
> >>
> >> >
> >> > - I would like to see your all code to let the charger work, eg
> >> > you have said the charger detection is done by PMIC automatically,
> >> > but I did not find your PMIC code to read charger type.
> >>
> >> Yeah, this patchset did not give an example to read charger type from
> >> PMIC registers. (Cause now the user 'wm831x_power' don't need this.)
> >> But I think user can get it easily by implementing below callbacks.
> >> (1) gadget->ops->get_charger_type();
> >> (2) power_supply_get_property(uchger->psy, POWER_SUPPLY_PROP_CHARGE_TYPE, 
> >> );
> >> (3) uchger->get_charger_type();
> >>
> >
> > I just would like if you can have this, then, we (you) can test it, eg,
> > you can test if the wm831x can charge more than 1500mA for DCP.
> 
> Mark, could you please address Peter's comments about if the the
> wm831x can charge more than 1500mA for DCP? (I have no environment to
> test wm831x) Thanks.
> 

I don't want you or Mark to test at hardware, I just would like to see
some code that how PMIC, wm831x, and USB gadget driver work together.

> >> >
> >> > Besides, how you can make sure the charger detection has finished
> >> > before the framework handles USB_CHARGER_PRESENT event?
> >>
> >> I think we don't need to care about this situation. If the charger
> >> type is 'UNKNOWN_TYPE' (maybe charger detection is not finished yet),
> >> the charger framework will not set current (current is 0) for power
> >> driver.
> >
> > Then, when we notify the charger IC for larger current, eg, for DCP.
> 
> I suppose If the usb charger framework gets the charger type, then
> notify the charger IC for larger current.

It is no problem for software detection, but for hardware one, it must
make sure it sends "USB_CHARGER_PRESENT" event after detection has
finished, otherwise no one will notify charger framework for DCP.

> 
> >
> >>
> >> >
> >> > - I commented the current limit at different situations for USB
> >> > charger last time, but I have not seen your further comments.
> >> > I would like give it again. For DCP, you can notify charger IC
> >> > once you get the charger type. But for CDP/SDP, you need to
> >> > notify charger IC after set configuration has finished, since
> >> > the host may still not be ready to give high current.
> >>
> >> As my understanding, if the usb charger framework get the charger
> >> type, it means we can notify the power driver to set the current. If
> >> you don't ready for setting current, please don't give the charger
> >> type to usb charger framework.
> >>
> >> The framework does not want to focus on charger detection too much,
> >> and just supplies one callback '->charger_detect()' for user to be
> >> implemented if they ensure they need to do the SW charger detection
> >> manually (Note: must at the right time to do the SW detection.). So
> >> the usb charger just focus on dealing with the usb gadget power
> >> negotiation, and it does not need to care much how to do charger
> >> detection on your platform.
> >
> > No, this comment is common one, but only for SW detection. Eg, when
> > the PMIC tells you it is a SDP, you can't notify to charger IC about
> > 500mA at once, you need to do it after host allows you to do it.
> 
> Well. Sounds reasonable. I just give an ugly example to implement the
> 'gadget->ops->get_charger_type()' method to get the charger type.
> 
> enum usb_charger_type get_charger_type(struct usb_gadget *gadget)
> {
> if (host is allowed)
> read charger type from PMIC;
> else
> return UNKNOWN_TYPE;
> }
> 
> So that will makes usb charger do not need to care about too much to
> make things more complicated. Or do you have any other good
> suggestions? Thanks.
> 

Since it is a USB charger, you had to be involved with USB stuffs:).

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2016-04-05 Thread Baolin Wang 
On 5 April 2016 at 16:12, Peter Chen  wrote:
> On Tue, Apr 05, 2016 at 03:54:31PM +0800, Baolin Wang wrote:
>> Hi Peter,
>>
>> On 5 April 2016 at 14:46, Peter Chen  wrote:
>> >
>> > We are thinking USB charger framework for Freescale i.mx SoC series,
>> > since our internal framework is not good enough.
>> > So I have more questions for your framework since there are many
>> > different USB charger designs, and I hope it is universal.
>>
>> Great, thanks for your attention and suggestions.
>>
>> >
>> > - I would like to see your all code to let the charger work, eg
>> > you have said the charger detection is done by PMIC automatically,
>> > but I did not find your PMIC code to read charger type.
>>
>> Yeah, this patchset did not give an example to read charger type from
>> PMIC registers. (Cause now the user 'wm831x_power' don't need this.)
>> But I think user can get it easily by implementing below callbacks.
>> (1) gadget->ops->get_charger_type();
>> (2) power_supply_get_property(uchger->psy, POWER_SUPPLY_PROP_CHARGE_TYPE, 
>> );
>> (3) uchger->get_charger_type();
>>
>
> I just would like if you can have this, then, we (you) can test it, eg,
> you can test if the wm831x can charge more than 1500mA for DCP.

Mark, could you please address Peter's comments about if the the
wm831x can charge more than 1500mA for DCP? (I have no environment to
test wm831x) Thanks.

>
>> In some solutions, when one cable is plugin, the PMIC will detect the
>> charger type automatically and you can read it from PMIC registers
>> then. Then maybe one interrupt or other ways to report to gadget to do
>> enumeration. So user can read the PMIC registers to get charger type
>> by implementing any above methods.
>>
>
> Wait. When the USB cable is plugging in, which module will get
> interrupt? Only PMIC or Both PMIC and USB (or extcon)? If PMIC
> can trigger USB "connect" interrupt, then it is ok.

Sorry for confusing you. What I mean is this is one hardware design,
when USB cable is plugging in, the PMIC will detect the charger type
automatically and the gadget does not know any plugin event at the
same time. Then after the hardware detection, system will create one
VBUS interrupt to gadget to do enumeration. Anyway, no matter how you
design your hardware detection method, it should guarantee the charger
detection action safely.

>
>> >
>> > Besides, how you can make sure the charger detection has finished
>> > before the framework handles USB_CHARGER_PRESENT event?
>>
>> I think we don't need to care about this situation. If the charger
>> type is 'UNKNOWN_TYPE' (maybe charger detection is not finished yet),
>> the charger framework will not set current (current is 0) for power
>> driver.
>
> Then, when we notify the charger IC for larger current, eg, for DCP.

I suppose If the usb charger framework gets the charger type, then
notify the charger IC for larger current.

>
>>
>> >
>> > - I commented the current limit at different situations for USB
>> > charger last time, but I have not seen your further comments.
>> > I would like give it again. For DCP, you can notify charger IC
>> > once you get the charger type. But for CDP/SDP, you need to
>> > notify charger IC after set configuration has finished, since
>> > the host may still not be ready to give high current.
>>
>> As my understanding, if the usb charger framework get the charger
>> type, it means we can notify the power driver to set the current. If
>> you don't ready for setting current, please don't give the charger
>> type to usb charger framework.
>>
>> The framework does not want to focus on charger detection too much,
>> and just supplies one callback '->charger_detect()' for user to be
>> implemented if they ensure they need to do the SW charger detection
>> manually (Note: must at the right time to do the SW detection.). So
>> the usb charger just focus on dealing with the usb gadget power
>> negotiation, and it does not need to care much how to do charger
>> detection on your platform.
>
> No, this comment is common one, but only for SW detection. Eg, when
> the PMIC tells you it is a SDP, you can't notify to charger IC about
> 500mA at once, you need to do it after host allows you to do it.

Well. Sounds reasonable. I just give an ugly example to implement the
'gadget->ops->get_charger_type()' method to get the charger type.

enum usb_charger_type get_charger_type(struct usb_gadget *gadget)
{
if (host is allowed)
read charger type from PMIC;
else
return UNKNOWN_TYPE;
}

So that will makes usb charger do not need to care about too much to
make things more complicated. Or do you have any other good
suggestions? Thanks.

>
> --
>
> Best Regards,
> Peter Chen



-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2016-04-05 Thread Peter Chen 
On Tue, Apr 05, 2016 at 03:54:31PM +0800, Baolin Wang wrote:
> Hi Peter,
> 
> On 5 April 2016 at 14:46, Peter Chen  wrote:
> >
> > We are thinking USB charger framework for Freescale i.mx SoC series,
> > since our internal framework is not good enough.
> > So I have more questions for your framework since there are many
> > different USB charger designs, and I hope it is universal.
> 
> Great, thanks for your attention and suggestions.
> 
> >
> > - I would like to see your all code to let the charger work, eg
> > you have said the charger detection is done by PMIC automatically,
> > but I did not find your PMIC code to read charger type.
> 
> Yeah, this patchset did not give an example to read charger type from
> PMIC registers. (Cause now the user 'wm831x_power' don't need this.)
> But I think user can get it easily by implementing below callbacks.
> (1) gadget->ops->get_charger_type();
> (2) power_supply_get_property(uchger->psy, POWER_SUPPLY_PROP_CHARGE_TYPE, 
> );
> (3) uchger->get_charger_type();
> 

I just would like if you can have this, then, we (you) can test it, eg,
you can test if the wm831x can charge more than 1500mA for DCP.

> In some solutions, when one cable is plugin, the PMIC will detect the
> charger type automatically and you can read it from PMIC registers
> then. Then maybe one interrupt or other ways to report to gadget to do
> enumeration. So user can read the PMIC registers to get charger type
> by implementing any above methods.
> 

Wait. When the USB cable is plugging in, which module will get
interrupt? Only PMIC or Both PMIC and USB (or extcon)? If PMIC
can trigger USB "connect" interrupt, then it is ok.

> >
> > Besides, how you can make sure the charger detection has finished
> > before the framework handles USB_CHARGER_PRESENT event?
> 
> I think we don't need to care about this situation. If the charger
> type is 'UNKNOWN_TYPE' (maybe charger detection is not finished yet),
> the charger framework will not set current (current is 0) for power
> driver.

Then, when we notify the charger IC for larger current, eg, for DCP.

> 
> >
> > - I commented the current limit at different situations for USB
> > charger last time, but I have not seen your further comments.
> > I would like give it again. For DCP, you can notify charger IC
> > once you get the charger type. But for CDP/SDP, you need to
> > notify charger IC after set configuration has finished, since
> > the host may still not be ready to give high current.
> 
> As my understanding, if the usb charger framework get the charger
> type, it means we can notify the power driver to set the current. If
> you don't ready for setting current, please don't give the charger
> type to usb charger framework.
> 
> The framework does not want to focus on charger detection too much,
> and just supplies one callback '->charger_detect()' for user to be
> implemented if they ensure they need to do the SW charger detection
> manually (Note: must at the right time to do the SW detection.). So
> the usb charger just focus on dealing with the usb gadget power
> negotiation, and it does not need to care much how to do charger
> detection on your platform.

No, this comment is common one, but only for SW detection. Eg, when
the PMIC tells you it is a SDP, you can't notify to charger IC about
500mA at once, you need to do it after host allows you to do it.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2016-04-05 Thread Baolin Wang 
Hi Peter,

On 5 April 2016 at 14:46, Peter Chen  wrote:
>
> We are thinking USB charger framework for Freescale i.mx SoC series,
> since our internal framework is not good enough.
> So I have more questions for your framework since there are many
> different USB charger designs, and I hope it is universal.

Great, thanks for your attention and suggestions.

>
> - I would like to see your all code to let the charger work, eg
> you have said the charger detection is done by PMIC automatically,
> but I did not find your PMIC code to read charger type.

Yeah, this patchset did not give an example to read charger type from
PMIC registers. (Cause now the user 'wm831x_power' don't need this.)
But I think user can get it easily by implementing below callbacks.
(1) gadget->ops->get_charger_type();
(2) power_supply_get_property(uchger->psy, POWER_SUPPLY_PROP_CHARGE_TYPE, );
(3) uchger->get_charger_type();

In some solutions, when one cable is plugin, the PMIC will detect the
charger type automatically and you can read it from PMIC registers
then. Then maybe one interrupt or other ways to report to gadget to do
enumeration. So user can read the PMIC registers to get charger type
by implementing any above methods.

>
> Besides, how you can make sure the charger detection has finished
> before the framework handles USB_CHARGER_PRESENT event?

I think we don't need to care about this situation. If the charger
type is 'UNKNOWN_TYPE' (maybe charger detection is not finished yet),
the charger framework will not set current (current is 0) for power
driver.

>
> - I commented the current limit at different situations for USB
> charger last time, but I have not seen your further comments.
> I would like give it again. For DCP, you can notify charger IC
> once you get the charger type. But for CDP/SDP, you need to
> notify charger IC after set configuration has finished, since
> the host may still not be ready to give high current.

As my understanding, if the usb charger framework get the charger
type, it means we can notify the power driver to set the current. If
you don't ready for setting current, please don't give the charger
type to usb charger framework.

The framework does not want to focus on charger detection too much,
and just supplies one callback '->charger_detect()' for user to be
implemented if they ensure they need to do the SW charger detection
manually (Note: must at the right time to do the SW detection.). So
the usb charger just focus on dealing with the usb gadget power
negotiation, and it does not need to care much how to do charger
detection on your platform.

>
> --
>
> Best Regards,
> Peter Chen



-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2016-04-05 Thread Peter Chen 
On Fri, Apr 01, 2016 at 03:21:48PM +0800, Baolin Wang wrote:
> Currently the Linux kernel does not provide any standard integration of this
> feature that integrates the USB subsystem with the system power regulation
> provided by PMICs meaning that either vendors must add this in their kernels
> or USB gadget devices based on Linux (such as mobile phones) may not behave
> as they should. Thus provide a standard framework for doing this in kernel.
> 
> Now introduce one user with wm831x_power to support and test the usb charger,
> which is pending testing. Moreover there may be other potential users will use
> it in future.
> 
> Changes since v8:
>  - Remove the bus type things.
>  - Introduce one charger_detect() callback to detect charger type if it is 
> needed.
>  - Add some sysfs attributes for showing the charger type and state.
>  - Change the charger current attributes to read only.
>  - Move charger state and type definition to include/uapi.
>  - Some other optimiazations.
> 
> Baolin Wang (4):
>   gadget: Introduce the usb charger framework
>   gadget: Support for the usb charger framework
>   gadget: Integrate with the usb gadget supporting for usb charger
>   power: wm831x_power: Support USB charger current limit management
> 

We are thinking USB charger framework for Freescale i.mx SoC series,
since our internal framework is not good enough.
So I have more questions for your framework since there are many
different USB charger designs, and I hope it is universal.

- I would like to see your all code to let the charger work, eg
you have said the charger detection is done by PMIC automatically,
but I did not find your PMIC code to read charger type.

Besides, how you can make sure the charger detection has finished
before the framework handles USB_CHARGER_PRESENT event?

- I commented the current limit at different situations for USB
charger last time, but I have not seen your further comments.
I would like give it again. For DCP, you can notify charger IC
once you get the charger type. But for CDP/SDP, you need to
notify charger IC after set configuration has finished, since
the host may still not be ready to give high current.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html