[Letux-kernel] Fwd: mmc PM regression

[H. Nikolaus Schaller]

Hi,

Am 05.02.2016 um 17:30 schrieb Andreas Kemnade <andreas at kemnade.info>:

> Hi,
> 
> On Fri, 5 Feb 2016 08:58:24 +0100
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>> Hi,
>> 
>> Am 04.02.2016 um 23:05 schrieb Andreas Kemnade <andreas at kemnade.info>:
>> 
>>> On Thu, 2016-02-04 at 16:37 +0100, H. Nikolaus Schaller wrote:
>>> 
>>>> I have merged the patch and at least on the OMAP5 it makes a difference!
>>>> 
>>>> http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/gta04/pm
>>>> 
>>>> So it looks as if we have a (temp) solution. We just should revert/remove it if there
>>>> is an official solution coming.
>>>> 
>>> no improvements on gta04.
>> 
>> ok. It was only trying to fix a pm issue for mmc/sdio cards and for a bug
>> I have had when booting on the Pyra hardware.
>> 
>>> e.g. bluetooth is not fixed, same situation as before.
>> 
>> seems to have a different reason: reset management of the WiFi chip.
>> 
> Hmm, looking at the device tree file I found only the following
> about reset handling
>        tca_gpios: tca6507 at 45 {
>               wifi_reset: wifi_reset at 6 { /* reference as <&tca_gpios 0 0> since it is currently the only GPIO */
>                        reg = <0x6>;
>                        compatible = "gpio";
>                };

Yes. The mess is that the W2CBW has only a shared reset line for WLAN&BT.

> 
>     wifi_pwrseq: wifi_pwrseq {
>                compatible = "mmc-pwrseq-simple";
>                reset-gpios = <&tca_gpios 0 GPIO_ACTIVE_LOW>;   /* W2CBW003 reset through tca6507 */
>        };
> &mmc2 {
>        // remove cap-power-off-card;
>        mmc-pwrseq = <&wifi_pwrseq>;
> };
> 
> That is all about reset handling controlled by wifi but I do not understand
> how a bluethooth power on will cause a reset there...

Well, Bluetooth does not reset.

> For bluetooth I found (besides sound) only
>        bluetooth: w2cbw003 {
>                compatible = "wi2wi,w2cbw003-bluetooth";
>                uart = <&uart1>;
>                vdd-supply = <&vaux4>;
>        };

This is our special driver which should power on the BT end if we
open /dev/ttyO1 (i.e. hciattach).

But to work, it must be sure that WLAN is not applying a reset!

Maybe we have broken everything by using the mmc-pwrseq-simple
for the WLAN side.

If I remember correctly Neil's experiments some years ago, the reset
must be inactive for BT to work. And for WLAN it must be a *short*
impulse so that it does not disturb a running BT subsystem.

If reset is permanently asserted, BT does not work.

So we probably have to patch/replace mmc-pwrseq-simple so that it
only does a momentary reset (10us or so) to reset WLAN only.

> 
> 
>>> X is still happily crashing...
>> 
>> I didn't look into that yet.
>> 
>>> wifi  causes still suspend problems
>>> neither libertas_tf nor libertas work correctly.
>>> The best situation possible is to comment out pm_ops in
>>> if_sdio.c (have a patch for it now in my branch). The card is cleanly
>>> removed but reappears only after
>>> rebinding of the omap_hsmmc driver for mmc2.
>>> besides of doing rmmod libertas_sdio before suspend...
>>> so mmc really smells
>> 
>> Indeed. It seems to be an ongoing hack.
>> 
> &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.

> 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.

The logic is that both vdd-supply = <&vaux4>; and vmmc-supply = <&vaux4>;
make a "wired or" to turn power on for the W2CBW.

BR,
Nikolaus