On Mon, Sep 27, 2010 at 10:21 AM, Arun Murthy <arunrmurthy.83@xxxxxxxxx> wrote:
> On Mon, Sep 27, 2010 at 1:05 AM, Grazvydas Ignotas <notasas@xxxxxxxxx>
> wrote:
>> ---
>> This is v3 of BCI charger driver I first sent nearly a year ago [1].
>> I've updated it to use the new OTG notifiers for VBUS notifications,
>> however it still is not able to determine charge current to use.
>> For that reason there is now a temporary module param to enable USB
>> charging, until I can figure out how to get that info from the gadget
>> stack (hopefully Felipe can help me here).
>
> On detecting USB plug, the driver is suppose to detect the type of usb
> device. Then if the device is a PC(standard host) the charging current is to
> be obtained from the usb stack. Hence the driver will have to wait until the
> usb stack or driver notifies the current that can be drawn. The usb stack or
> driver gets to know the amount of current to be drawn through the
> negotiations that happen between the host and device.
I'm aware of that, the question was how to get that from Linux USB
stack (which Felipe already responded).
<snip>
> Only AC and USB monitoring is achieved by registering with power supply
> class.
> How is battery monitored?
> An instance of battery is to be registered with power supply class in order
> to monitor battery.
The problem is that BCI is only active while charging, when it is not
charging most (all?) monitoring registers freeze and no monitoring
happens (BCI registers read frozen values from last charge). So I
don't register battery as it has no useful data to report. I heard it
is possible to use MADC to perform monitoring while not charging, so
battery can be added when MADC driver is merged and corresponding code
is written for this driver.
>>
>> +
>> +static struct platform_driver twl4030_bci_driver = {
>> + .probe = twl4030_bci_probe,
>> + .remove = __devexit_p(twl4030_bci_remove),
>> + .driver = {
>> + .name = "twl4030_bci",
>> + .owner = THIS_MODULE,
>> + },
>> +};
>
> dev_pm_ops can be use
nothing to do there right now, the driver relies on FSM change
interrupts from BCI to update state.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
