Re: [RFC] dts: tegra124-nyan: Reenable CPU DFLL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thierry Reding – Mon, 11. February 2019 9:54
> On Sun, Feb 10, 2019 at 09:20:01PM +0100, Tristan Bastian wrote:
> > Hi John,
> > 
> > So I'm running with CPU DFLL Clock enabled and it is working fine..
> > 
> > Since I don't know how to debug the not working suspend, I attached my dmesg
> > output when running pm-suspend:
> > 
> > [ 548.312095] PM: suspend entry (deep)
> > [ 548.312106] PM: Syncing filesystems ... done.
> > [ 548.711143] rfkill: input handler enabled
> > [ 548.773693] Freezing user space processes ... (elapsed 0.004 seconds)
> > done.
> > [ 548.778001] OOM killer disabled.
> > [ 548.778007] Freezing remaining freezable tasks ... (elapsed 0.001
> > seconds) done.
> > [ 548.779912] printk: Suspending console(s) (use no_console_suspend to
> > debug)
> > [ 548.784432] mwifiex_sdio mmc1:0001:1: info: successfully disconnected
> > from 44:4e:6d:6f:a5:0d: reason code 3
> > [ 548.791657] mwifiex_sdio mmc1:0001:1: None of the WOWLAN triggers enabled
> > [ 553.843794] Bluetooth: Host sleep enable command failed
> > [ 553.843800] Bluetooth: HS not activated, suspend failed!
> > [ 553.843813] dpm_run_callback(): pm_generic_suspend+0x0/0x48 returns -16
> > [ 553.843826] PM: Device mmc1:0001:2 failed to suspend async: error -16
> > [ 553.843916] PM: Some devices failed to suspend, or early wake event
> > detected
> > [ 554.103601] tegra-sor 54540000.sor: failed to attach SOR: -110
> > [ 554.292068] OOM killer enabled.
> > [ 554.292074] Restarting tasks ...
> > [ 554.293913] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state
> > [ 554.295802] done.
> > [ 554.301180] PM: suspend exit
> > [ 554.321490] rfkill: input handler disabled
> > [ 554.393944] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state
> > [ 554.393955] mwifiex_sdio mmc1:0001:1: scan failed: -1
> > [ 554.564316] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state
> > [ 554.564415] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state
> > [ 554.664897] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state
> > [ 554.664914] mwifiex_sdio mmc1:0001:1: scan failed: -1
> > [ 555.666327] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state
> > [ 555.666335] mwifiex_sdio mmc1:0001:1: scan failed: -1
> > [ 556.668738] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state
> > [ 556.668779] mwifiex_sdio mmc1:0001:1: scan failed: -1
> > [ 557.672858] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state
> > [ 557.672915] mwifiex_sdio mmc1:0001:1: scan failed: -1
> > [ 558.676060] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state
> > [ 558.676070] mwifiex_sdio mmc1:0001:1: scan failed: -1
> > 
> > So it looks like this is failing because of bluetooth?
> 
> So when you're saying that suspend is failing, it's actually never
> entering suspend? Or is it suspending but not resuming properly?
> 
> If the former I wouldn't consider that a critical bug, but if we
> actually manage to suspend and then can't resume properly, that's fairly
> critical.
> 
> Thierry

I'm trying this on ubuntu and if I run systemctl suspend I'm ending at a blank screen with no backlight on.
And I'm not able to resume the system.

If I run the pm-suspend command from above, the system goes to the same black screen, but leaves after a short while.

I'm not sure if pm-suspend should end in a suspend mode or not..

Tristan

> > 
> > Thanks
> > 
> > Tristan
> > 
> > Am 28.01.19 um 11:20 schrieb Jon Hunter:
> > > On 28/01/2019 09:44, Tristan Bastian wrote:
> > > > The following commit disabled the CPU DFLL Clock of the nyan boards to
> fix suspend:
> > > > ARM: tegra: Fix suspend hang on Tegra124 Chromebooks (9a0baee960a7)
> > > I think you mean commit 80373d37bee5.
> > > 
> > > > I'm not sure if suspend was working afterwards, but at least suspend
> isn't working in the latest kernels.
> > > It was at least until v4.15 (I don't have any testlogs after that
> > > unfortunately).
> > > 
> > > > When suspend isn't working anyway we could reenable the CPU DFLL clock
> again to at least make that work.
> > > I don't think that is a good idea.
> > > 
> > > > So would it be possible to revert the commit from above or fix suspend
> or maybe both?
> > > If suspend is broken, then that needs to be fixed. Once that works, we
> > > need to have a way to switch from the DFLL to the PLL correctly for
> > > suspend before we can revert this change.
> > > 
> > > Cheers
> > > Jon
> > >



[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux