[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200529215314.GZ37466@atomide.com>
Date: Fri, 29 May 2020 14:53:14 -0700
From: Tony Lindgren <tony@...mide.com>
To: Tomi Valkeinen <tomi.valkeinen@...com>
Cc: Faiz Abbas <faiz_abbas@...com>, Keerthy <j-keerthy@...com>,
linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
bcousson@...libre.com
Subject: Re: [PATCH v2] arm: dts: Move am33xx and am43xx mmc nodes to
sdhci-omap driver
* Tony Lindgren <tony@...mide.com> [200527 16:06]:
> * Tony Lindgren <tony@...mide.com> [200519 09:05]:
> > * Tomi Valkeinen <tomi.valkeinen@...com> [200519 15:55]:
> > > (Dropping DT from cc)
> > >
> > > On 19/05/2020 18:48, Tony Lindgren wrote:
> > >
> > > > > > Suspend/resume on am43xx-gpevm is broken right now in mainline and the regression looks
> > > > > > like it is caused by the display subsystem. I have reported this to Tomi and
> > > > > > its being investigated.
> > > > > >
> > > > > > Meanwhile I have tested this patch with display configs disabled and Keerthy's
> > > > > > suspend/resume tests pass on both am3 and am4.
> > > >
> > > > OK great thanks for checking it. Do you have the display subsystem
> > > > related commit that broke PM? I'm wondering if my recent DSS platform
> > > > data removal changes might have caused the regression.
> > >
> > > I spent a bit time looking at this, but unfortunately I wasn't even able to
> > > resume my AM4 evm from suspend. I tried with rtcwake and with plain console
> > > (with no_console_suspend). I did not have DSS loaded.
> >
> > My test-bbb-suspend script seems to have:
> >
> > sudo modprobe wkup_m3_ipc
> > sudo modprobe pm33xx
> > sudo modprobe rtc-omap
> > rtcwake -m mem -s 5
> >
> > I think the same should work for am437x. But some boards do not support
> > deep sleep like am437x-idk.
> >
> > > Anyone have quick hints on how to debug why resume doesn't seem to happen?
> >
> > You might get some info with no_console_suspend, but that might also
> > cause other issues.
>
> To me it seems we may have some dss clock missing with the ti-sysc dts
> changes that makes resume fail. Or else there is some ordering issue
> between the dss components now on resume, I'll try to debug more.
Looks like we now set the CLOCKATIVITY bit while earlier we did not
set it except for HWMOD_SET_DEFAULT_CLOCKACT cases. I've also found
few other minor issues, but I'm still seeing resume fail for DSS.
The clock and sysconfig registers look just fine, so getting closer.
Regards,
Tony
Powered by blists - more mailing lists