[Letux-kernel] Fwd: mmc PM regression

H. Nikolaus Schaller hns at goldelico.com
Mon Feb 8 11:18:23 CET 2016


Hi,

> Am 07.02.2016 um 22:22 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> Hi Nikolaus,
> 
> On Sun, 7 Feb 2016 10:53:38 +0100
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>> Hi Andreas,
>> 
>>> Am 07.02.2016 um 10:06 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> 
>>> Hi Nikolaus,
>>> 
>>> On Fri, 5 Feb 2016 19:30:27 +0100
>>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>> 
>>>>> &mmc2 {
>>>>>      vmmc-supply = <&vaux4>;
>>>>>      bus-width = <4>;
>>>>>      ti,non-removable;
>>>>>      cap-power-off-card;     /* remove! */ <----
>>>>> };
>>>>> What about the "remove!" here? What are the plans/ideas/problems here?  
>>>> 
>>>> I don't know.
>>>> 
>>> If I understand that correctly, then that is about what to do with vaux4.
>>> Thats why I asked my question below.
>>> 
>>>>> Was it once enabled and caused problems?
>>>>> 277acf4b545327104c9b779eec7c440285d11a39
>>>>> looks like that.  
>>>> 
>>>> That is heritage from Neil nobody else was able to understand so far...
>>>> 
>>>>> 
>>>>> Is the idea to never switch off vaux4? At least everything
>>>>> regarding sdio suspend/remove/resume should be tested in both ways  
>>>> 
>>>> No, vaux4 must be turned off if we neither need WLAN nor BT.
>>>> 
>>> It should. But *must* it be turned off?
>> 
>> Yes. It is also shared with the Bluetooth side... So if you keep the WLAN
>> running we will also have ~50mA for bluetooth.
>> 
> BT seems to have quite good power saving.
> I have booted 4.5rc2 with init=/bin/bash
> loading modules, ifconfig wlan0 up (no connection), 
> hciattach, hciconfig hci0 up
> and running l2ping gives 90mA total consumption, around 80mA without l2ping.

Well, Bluetooth in total has not a big consumption. I think <50mA.

But 10mA is a lot...

> 
>>> Are there any other reason besides saving a few mA (which is of course
>>> important)?
>> 
>> Very important, and more important than everything else...
>> 
> That does not answer my question. 

Maybe I can't answer it because I have not written that code...

> 
> There might be a board with a libertas wifi chip which does not have its separate
> power rail. And the reset pin is at some system reset chip. And therefore
> the card is never powered down but only reset/shutdown via sd commands. If I understand
> the mmc system correctly (I am not as deep in there as I am in libertas), such
> a situation is indicated to the kernel by not specifying "cap-power-off-card;"
> in devicetree which is indicated by not having MMC_CAP_POWER_OFF_CARD in host->caps.

I find this description in the mmc bindings:

- cap-power-off-card: powering off the card is safe
 
Hm. This means that it is permissable to turn power off. Which is for our W2CBW003 in the GTA04.

It was introduced here:

http://lists.goldelico.com/pipermail/gta04-owner/2015-January/006116.html

So it is probably right to have this property in DT, because it just defines that it is safe.

What a driver does with this information is another discussion...

I would *assume* that it sends some shutdown command to the card, waits for cleanup
confirmation and then disables the regulator.

And if it is powered down, it enables the power regulator, asserts reset for some time
and then sends the initialization sequence required after reset.

This all does not say anything about when the card is powered down.

For that I would expect that it is at least powered down during suspend. But it should
also be completely powered down on ifconfig wlan0 down.

But it does not need to be powered down if the interface is up and the card is not used
for >30 seconds. Like it would be useful for a µSD card or hard disk...

> At first glance that is not important for us but:
> 
> 1. That strange patch by Neil changes exactly behaviour in such
> situations so for upstreaming that one we need an argument that it does not create
> regressions.

Hm. I do not know which change you refer to and what is not yet upstreamed.

> 
> 2. At the moment working at that area feels like trying to get a few spaghetti from
> the plate and instead getting a bunch that does not fit into my mouth.

That is normal if you do not fix some simple typos in drivers. As soon as you want
to make something really working, it becomes a Hydra...

See the "UART slaves" topic which just wants to power on the GPS chip on open("/dev/ttyO1").

> Having the reset/enable stuff moved out of the way (for testing) should simplify
> finding bugs. (the "remove" comment might indicates IMHO such a thing)
> 
> Next thing I do is insert some more debug output around the reset thing.
> The puzzle starts to form in my head...

Maybe Neil just did a hack to get the Reset impulse being issued at the right moment.

So this cap-power-off-card does what it should, but it might be that the standard
mmc drivers do not issue the reset as needed. So after suspend the W2CBW003 is
powered on but not in a correct reset state.

Ah, and it might also be an interaction with the BT side:
* if BT is enabled when WLAN is being turned off
* VAUX4 remains on
* i.e. the WLAN module continues to run
* but the driver thinks it has been powered off (because it can if BT is off)
* and the driver is not monitoring the real VAUX4 but only the regulator-enable
* and therefore sends a power on initialization the WLAN side does not expect and understand
* unless it gets a reset impulse

That may be the problem Neil wanted to solve.

> 
> After bringing 6 patches into wireless-next I feel encouraged to do the same
> with the needed ones of the remaing patches (max. 5).

Yes. Would be great!

BR,
Nikolaus



More information about the Letux-kernel mailing list