[Letux-kernel] Fwd: mmc PM regression

[Andreas Kemnade]

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";
                };

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


> > 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?
Was it once enabled and caused problems?
277acf4b545327104c9b779eec7c440285d11a39
looks like that.

Is the idea to never switch off vaux4? At least everything
regarding sdio suspend/remove/resume should be tested in both ways


Regards,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20160205/552699e1/attachment.asc>