diff mbox

[U-Boot] sunxi: axp221: Use vbus-available rather then vbus-usable for vbus-detect

Message ID 1427128104-30144-1-git-send-email-hdegoede@redhat.com
State Superseded
Delegated to: Hans de Goede
Headers show

Commit Message

Hans de Goede March 23, 2015, 4:28 p.m. UTC
vbus-usable does not get set if power is provided through the power barrel
connector, even if external 5v is also present on the otg connector.

vbus-available correctly always reflects if there is 5v present on the otg
connector.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/power/axp221.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Paul Kocialkowski March 23, 2015, 4:33 p.m. UTC | #1
Le lundi 23 mars 2015 à 17:28 +0100, Hans de Goede a écrit :
> vbus-usable does not get set if power is provided through the power barrel
> connector, even if external 5v is also present on the otg connector.
> 
> vbus-available correctly always reflects if there is 5v present on the otg
> connector.

You (or I) could submit the very same change for the AXP209. It's the
same bit for available (1 << 5).

> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>  drivers/power/axp221.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/axp221.c b/drivers/power/axp221.c
> index f758a75..dc3a7f1 100644
> --- a/drivers/power/axp221.c
> +++ b/drivers/power/axp221.c
> @@ -424,7 +424,7 @@ int axp_gpio_get_value(unsigned int pin)
>  		if (ret)
>  			return ret;
>  
> -		return !!(val & AXP221_POWER_STATUS_VBUS_USABLE);
> +		return !!(val & AXP221_POWER_STATUS_VBUS_AVAIL);
>  	default:
>  		return -EINVAL;
>  	}
Hans de Goede March 23, 2015, 4:34 p.m. UTC | #2
Hi,

On 23-03-15 17:28, Hans de Goede wrote:
> vbus-usable does not get set if power is provided through the power barrel
> connector, even if external 5v is also present on the otg connector.
>
> vbus-available correctly always reflects if there is 5v present on the otg
> connector.

Except that it also gets set when there is a usb-host cable with a device
attached plugged in, so this is going to need some more thinking, I'll
send a new patch when I've something which does not break using the port
in host mode.

Regards,

Hans
Hans de Goede March 23, 2015, 4:38 p.m. UTC | #3
Hi,

On 23-03-15 17:33, Paul Kocialkowski wrote:
> Le lundi 23 mars 2015 à 17:28 +0100, Hans de Goede a écrit :
>> vbus-usable does not get set if power is provided through the power barrel
>> connector, even if external 5v is also present on the otg connector.
>>
>> vbus-available correctly always reflects if there is 5v present on the otg
>> connector.
>
> You (or I) could submit the very same change for the AXP209. It's the
> same bit for available (1 << 5).

Yes I was about to mail you about that when I noticed that this seems to
break actual host mode support on the otg connector, it seems that
plugging in a micro-b to usb-a receptacle (aka host) convertor + a device
plugged into the usb-a receptacle also causes bit 5 to get set :|

So my patch is no good, but powering the otg port while external 5v is present
also is not good (one side effect is that the tablet will power up immediately
after sending a power-off command to the axp221).

If you've some time to tinker with this I would appreciate any ideas
you may have (assuming the same problem exists on the axp209)
simply plug in 5v power into the power barrel, as well as 5v power
(e.g. simply from your pc) and boot up the tablet, at least in my
case then it does not properly give the charger plugged in error.

Regards,

Hans



>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>>   drivers/power/axp221.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/power/axp221.c b/drivers/power/axp221.c
>> index f758a75..dc3a7f1 100644
>> --- a/drivers/power/axp221.c
>> +++ b/drivers/power/axp221.c
>> @@ -424,7 +424,7 @@ int axp_gpio_get_value(unsigned int pin)
>>   		if (ret)
>>   			return ret;
>>
>> -		return !!(val & AXP221_POWER_STATUS_VBUS_USABLE);
>> +		return !!(val & AXP221_POWER_STATUS_VBUS_AVAIL);
>>   	default:
>>   		return -EINVAL;
>>   	}
>
Chen-Yu Tsai March 23, 2015, 4:46 p.m. UTC | #4
Hi,

On Mon, Mar 23, 2015 at 9:34 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 23-03-15 17:28, Hans de Goede wrote:
>>
>> vbus-usable does not get set if power is provided through the power barrel
>> connector, even if external 5v is also present on the otg connector.
>>
>> vbus-available correctly always reflects if there is 5v present on the otg
>> connector.
>
>
> Except that it also gets set when there is a usb-host cable with a device
> attached plugged in, so this is going to need some more thinking, I'll
> send a new patch when I've something which does not break using the port
> in host mode.

My understanding is VBUS_Usable = VBUS_Available && (!(N_VBUSEN || reg 30h[7]))

reg 30h[7] says whether to check N_VBUSEN before using VBUS.

ChenYu
Paul Kocialkowski March 23, 2015, 10:44 p.m. UTC | #5
Le lundi 23 mars 2015 à 17:38 +0100, Hans de Goede a écrit :
> Hi,
> 
> On 23-03-15 17:33, Paul Kocialkowski wrote:
> > Le lundi 23 mars 2015 à 17:28 +0100, Hans de Goede a écrit :
> >> vbus-usable does not get set if power is provided through the power barrel
> >> connector, even if external 5v is also present on the otg connector.
> >>
> >> vbus-available correctly always reflects if there is 5v present on the otg
> >> connector.
> >
> > You (or I) could submit the very same change for the AXP209. It's the
> > same bit for available (1 << 5).
> 
> Yes I was about to mail you about that when I noticed that this seems to
> break actual host mode support on the otg connector, it seems that
> plugging in a micro-b to usb-a receptacle (aka host) convertor + a device
> plugged into the usb-a receptacle also causes bit 5 to get set :|

Actually, as soon as host mode is enabled on the musb controller (even
without a device), vbus is set to 1 and the present bit (5) from the
axp209 gets set (tested with both an OTG and a non-OTG micro-b to usb-a
adapter). However, it only happens *after* starting the musb controller
(with or without a device in), so since detection is done prior to that,
it should still work to use available bit (5) to detect external cables,
at least for our use case.

Are you experiencing the same thing, or does having AC plugged-in change
that?

> So my patch is no good, but powering the otg port while external 5v is present
> also is not good (one side effect is that the tablet will power up immediately
> after sending a power-off command to the axp221).

Of course, the port shouldn't be set in host mode when a cable that
provides VBUS is attached, we should avoid this.

> If you've some time to tinker with this I would appreciate any ideas
> you may have (assuming the same problem exists on the axp209)
> simply plug in 5v power into the power barrel, as well as 5v power
> (e.g. simply from your pc) and boot up the tablet, at least in my
> case then it does not properly give the charger plugged in error.

The (axp209-enabled and axp209-vbus-detection-enabled) tablet I have
around this week doesn't have a power barrel (the Ainol AW1), but I get
the problem in theory.

If I understood correctly the AXP209 datasheet (and according to
Chen-Yu's email), setting REG30H[7] to 1 will force the AXP to charge
the battery from USB when AC is in. It is unclear whether it will simply
ignore the power barrel or somewhat use both to charge the battery.

That would enable us to keep using the usable bit (4) for detection in
every case.

Since I cannot test this week (until next week-end), I'll leave it up to
you (or anyone else) to do the actual testing.

> Regards,
> 
> Hans
> 
> 
> 
> >
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >> ---
> >>   drivers/power/axp221.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/power/axp221.c b/drivers/power/axp221.c
> >> index f758a75..dc3a7f1 100644
> >> --- a/drivers/power/axp221.c
> >> +++ b/drivers/power/axp221.c
> >> @@ -424,7 +424,7 @@ int axp_gpio_get_value(unsigned int pin)
> >>   		if (ret)
> >>   			return ret;
> >>
> >> -		return !!(val & AXP221_POWER_STATUS_VBUS_USABLE);
> >> +		return !!(val & AXP221_POWER_STATUS_VBUS_AVAIL);
> >>   	default:
> >>   		return -EINVAL;
> >>   	}
> >
Hans de Goede March 27, 2015, 8:37 p.m. UTC | #6
Hi,

On 23-03-15 17:38, Hans de Goede wrote:
> Hi,
>
> On 23-03-15 17:33, Paul Kocialkowski wrote:
>> Le lundi 23 mars 2015 à 17:28 +0100, Hans de Goede a écrit :
>>> vbus-usable does not get set if power is provided through the power barrel
>>> connector, even if external 5v is also present on the otg connector.
>>>
>>> vbus-available correctly always reflects if there is 5v present on the otg
>>> connector.
>>
>> You (or I) could submit the very same change for the AXP209. It's the
>> same bit for available (1 << 5).
>
> Yes I was about to mail you about that when I noticed that this seems to
> break actual host mode support on the otg connector, it seems that
> plugging in a micro-b to usb-a receptacle (aka host) convertor + a device
> plugged into the usb-a receptacle also causes bit 5 to get set :|
>
> So my patch is no good, but powering the otg port while external 5v is present
> also is not good (one side effect is that the tablet will power up immediately
> after sending a power-off command to the axp221).
>
> If you've some time to tinker with this I would appreciate any ideas
> you may have (assuming the same problem exists on the axp209)
> simply plug in 5v power into the power barrel, as well as 5v power
> (e.g. simply from your pc) and boot up the tablet, at least in my
> case then it does not properly give the charger plugged in error.

Ok, so it took me a while but here is a follow up to this:

1) My original patch is correct, but it took me a while to reproduce the
original problem, I'll send an updated patch with the reproducer clearly
spelled out in the commit msg as it is non obvious

2) My original patch does introduce a *new* problem, or rather exposes
an existing problem when turning of vusb to the otg port (when in hostmode,
so vusb coming from the board) it takes a while for vusb to discharge and
if we are to quick with reading vusb-detect after a reset when the vusb
was on we see the residual charge and assume we've an external vusb, this is
worse when vbus gets not only sensed, but also controller by the pmic,
as then it does not get turned of on reset at all. I've patches fixing all
of this now, which I will include in the patch-set which I'm about to send
out. I'll put the fixes before this patch in the patch set so that the
bug it exposes gets fixed before it is exposed.

I think this all does not have much influence on the axp209, because AFAICT
we only ever do vbus sense through the pmic there and never vbus control.

Regards,

Hans
Paul Kocialkowski March 28, 2015, 8:27 a.m. UTC | #7
Le vendredi 27 mars 2015 à 21:37 +0100, Hans de Goede a écrit :
> Hi,
> 
> On 23-03-15 17:38, Hans de Goede wrote:
> > Hi,
> >
> > On 23-03-15 17:33, Paul Kocialkowski wrote:
> >> Le lundi 23 mars 2015 à 17:28 +0100, Hans de Goede a écrit :
> >>> vbus-usable does not get set if power is provided through the power barrel
> >>> connector, even if external 5v is also present on the otg connector.
> >>>
> >>> vbus-available correctly always reflects if there is 5v present on the otg
> >>> connector.
> >>
> >> You (or I) could submit the very same change for the AXP209. It's the
> >> same bit for available (1 << 5).
> >
> > Yes I was about to mail you about that when I noticed that this seems to
> > break actual host mode support on the otg connector, it seems that
> > plugging in a micro-b to usb-a receptacle (aka host) convertor + a device
> > plugged into the usb-a receptacle also causes bit 5 to get set :|
> >
> > So my patch is no good, but powering the otg port while external 5v is present
> > also is not good (one side effect is that the tablet will power up immediately
> > after sending a power-off command to the axp221).
> >
> > If you've some time to tinker with this I would appreciate any ideas
> > you may have (assuming the same problem exists on the axp209)
> > simply plug in 5v power into the power barrel, as well as 5v power
> > (e.g. simply from your pc) and boot up the tablet, at least in my
> > case then it does not properly give the charger plugged in error.
> 
> Ok, so it took me a while but here is a follow up to this:
> 
> 1) My original patch is correct, but it took me a while to reproduce the
> original problem, I'll send an updated patch with the reproducer clearly
> spelled out in the commit msg as it is non obvious

Your patch seemed to work fine for me, indeed.

> 2) My original patch does introduce a *new* problem, or rather exposes
> an existing problem when turning of vusb to the otg port (when in hostmode,
> so vusb coming from the board) it takes a while for vusb to discharge and
> if we are to quick with reading vusb-detect after a reset when the vusb
> was on we see the residual charge and assume we've an external vusb, this is
> worse when vbus gets not only sensed, but also controller by the pmic,
> as then it does not get turned of on reset at all. I've patches fixing all
> of this now, which I will include in the patch-set which I'm about to send
> out. I'll put the fixes before this patch in the patch set so that the
> bug it exposes gets fixed before it is exposed.

Ahhh, that makes sense, well spotted! I think that in my case, there was
no charge left on vbus after reset, so I couldn't spot the problem. 

> I think this all does not have much influence on the axp209, because AFAICT
> we only ever do vbus sense through the pmic there and never vbus control.

That's right, we only do vbus detection, not vbus driving through the
AXP209 (at this point, perhaps it's possible though).
diff mbox

Patch

diff --git a/drivers/power/axp221.c b/drivers/power/axp221.c
index f758a75..dc3a7f1 100644
--- a/drivers/power/axp221.c
+++ b/drivers/power/axp221.c
@@ -424,7 +424,7 @@  int axp_gpio_get_value(unsigned int pin)
 		if (ret)
 			return ret;
 
-		return !!(val & AXP221_POWER_STATUS_VBUS_USABLE);
+		return !!(val & AXP221_POWER_STATUS_VBUS_AVAIL);
 	default:
 		return -EINVAL;
 	}