[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4zj-BaX4tHji8B8gS5jiKkd-2BcwfzHM4fS-OUn0f8DSxcw@mail.gmail.com>
Date: Tue, 29 Aug 2023 10:48:08 +0800
From: Ben Chuang <benchuanggli@...il.com>
To: Sven van Ashbrook <svenva@...omium.org>, skardach@...gle.com
Cc: adrian.hunter@...el.com, SeanHY.chen@...esyslogic.com.tw,
ben.chuang@...esyslogic.com.tw, greg.tu@...esyslogic.com.tw,
jason.lai@...esyslogic.com.tw, jasonlai.genesyslogic@...il.com,
linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
reniuschengl@...il.com, stable@...r.kernel.org,
ulf.hansson@...aro.org, victor.shih@...esyslogic.com.tw,
victorshihgli@...il.com
Subject: Re: [PATCH v2] mmc: sdhci-pci-gli: fix LPM negotiation so x86/S0ix
SoCs can suspend
Hi Sven and Stanisław,
Sorry for Stanisław, I have seen your reply, but I only reply to this
Regarding the location of the source codes, if the maintainers don't
comment. I'll follow them too. :)
On Tue, Aug 29, 2023 at 6:51 AM Sven van Ashbrook <svenva@...omium.org> wrote:
>
> Hi Ben, thank you for reviewing this patch. See below.
>
> On Mon, Aug 28, 2023 at 6:03 AM Ben Chuang <benchuanggli@...il.com> wrote:
> >
> > There is a situation for your reference.
> > If `allow_runtime_pm' is set to false and the system resumes from suspend, GL9763E
> > LPM negotiation will be always disabled on S0. GL9763E will stay L0 and never
> > enter L1 because GL9763E LPM negotiation is disabled.
> >
> > This patch enables allow_runtime_pm. The simple flow is
> > gl9763e_suspend() -> LPM enabled -> gl9763e_resume() -> LPM disabled -> (a)
> > (a) -+--> idle --> gl9763e_runtime_suspend() -> LPM enabled
> > |
> > +--> no idle -> gl9763e_runtime_resume() -> LPM disabled
> >
> > This patch disables allow_runtime_pm. The simple flow is
> > gl9763e_suspend() -> LPM enabled -> gl9763e_resume() -> LPM disabled (no runtime_pm)
> >
> > Although that may not be the case with the current configuration, it's only a
> > possibility.
> >
>
> Thanks so much for bringing this up. We have discussed internally and
> as far as we know, the current patch will work correctly in all cases.
> Could you verify our argument please?
>
> The following assumptions are key:
>
> 1. If CONFIG_PM is set, the runtime_pm framework is always present, i.e. there
> cannot exist a kernel which has PM but lacks runtime_pm.
> 2. The pm_runtime framework always makes sure the device is runtime
> active before
> calling XXX_suspend, waking it up if need be. So when XXX_suspend gets called,
> the device is always runtime active.
> 3. if CONFIG_PM is set, runtime_pm can only be disabled via
> echo on > /sys/devices/.../power/control, and then the runtime_pm framework
> always keeps the device in runtime active. In such case LPM negotiation is
> always disabled.
>
> Using these assumptions, we get:
>
> Runtime_pm allowed:
> —------------------
> gl9763e_runtime_resume() -> LPM disabled -> gl9763e_suspend() -> LPM enabled
> -> gl9763e_resume() -> LPM disabled -> (a)
> (a) -+--> idle --> gl9763e_runtime_suspend() -> LPM enabled
> |
> +--> no idle -> nothing - already runtime active -> LPM disabled
>
> Runtime_pm not allowed:
> —----------------------
> gl9763e_runtime_resume() always called -> LPM always disabled
> gl9763e_suspend() -> LPM enabled -> gl9763e_resume() -> LPM disabled
>
> In all above cases the LPM negotiation flag is correct.
>
My concern is that when runtime_pm is false, gl9763e is disabled LPM
negotiation, gl9763e can't enter L1.x and s0ix may fail.
It seems that runtime_pm will always exist and that's ok.
> > >
> > > sdhci doesn't know anything about the bus. It is independent
> > > of PCI, so I can't see how it would make any difference.
> > > One of the people cc'ed might know more. Jason Lai (cc'ed)
> > > added it for runtime PM.
> > >
> >
> > As far as I know, when disabling LPM negotiation, the GL9763E will stop entering
> > L1. It doesn't other side effect. Does Jason.Lai and Victor.Shih have any comments
> > or suggestions?
>
> Sounds like everyone assumes that you can freely change LPM
> negotiation on the PCIe
> bus after the cqhci_suspend() and sdhci_suspend_host() calls, so we will assume
> that too.
Ah, I suppose cqhci_suspend() may need to be done first safely, then
gl9763e_set_low_power_negotiation(slot, true).
Best regards,
Ben Chuang
Powered by blists - more mailing lists