Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190805124935.819068648@linuxfoundation.org> <20190805124936.173376284@linuxfoundation.org>
 <20190805144723.GC24265@amd>
In-Reply-To: <20190805144723.GC24265@amd>
From:   Doug Anderson <dianders@chromium.org>
Date:   Mon, 12 Aug 2019 17:04:01 -0700
Message-ID: <CAD=FV=Vcdq+Z8NQdQrweT0LhzvBiWEd4GQ=QLDEQyGL2=b6r_Q@mail.gmail.com>
Subject: Re: [PATCH 4.19 04/74] ARM: dts: rockchip: Mark that the rk3288 timer
 might stop in suspend
To:     Pavel Machek <pavel@denx.de>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        "# 4.0+" <stable@vger.kernel.org>,
        Heiko Stuebner <heiko@sntech.de>,
        Sasha Levin <sashal@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,

On Mon, Aug 5, 2019 at 7:47 AM Pavel Machek <pavel@denx.de> wrote:
>
> On Mon 2019-08-05 15:02:17, Greg Kroah-Hartman wrote:
> > [ Upstream commit 8ef1ba39a9fa53d2205e633bc9b21840a275908e ]
> >
> > This is similar to commit e6186820a745 ("arm64: dts: rockchip: Arch
> > counter doesn't tick in system suspend").  Specifically on the rk3288
> > it can be seen that the timer stops ticking in suspend if we end up
> > running through the "osc_disable" path in rk3288_slp_mode_set().  In
> > that path the 24 MHz clock will turn off and the timer stops.
> >
> > To test this, I ran this on a Chrome OS filesystem:
> >   before=$(date); \
> >   suspend_stress_test -c1 --suspend_min=30 --suspend_max=31; \
> >   echo ${before}; date
> >
> > ...and I found that unless I plug in a device that requests USB wakeup
> > to be active that the two calls to "date" would show that fewer than
> > 30 seconds passed.
> >
> > NOTE: deep suspend (where the 24 MHz clock gets disabled) isn't
> > supported yet on upstream Linux so this was tested on a downstream
> > kernel.
>
> I guess this does no harm, but deep sleep is unlikely to be suppored
> in the stable kernels, so ... is it good idea there?

People do merge stable kernels into local trees which have extra
patches (which might enable deep sleep).  Chrome OS is an example of
this.  If the patch does no harm then merging it seems nice.

That being said: we already have this in the Chrome OS tree, so unless
someone else is also mering stable into their tree and trying to
support rk3288 with deep sleep, this patch is unlikely to matter.
...so if everyone doesn't want it then it won't bother me.

-Doug