[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190614134251.GG15526@ulmo>
Date: Fri, 14 Jun 2019 15:42:51 +0200
From: Thierry Reding <thierry.reding@...il.com>
To: Dmitry Osipenko <digetx@...il.com>
Cc: Daniel Lezcano <daniel.lezcano@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Alessandro Zummo <a.zummo@...ertech.it>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Jonathan Hunter <jonathanh@...dia.com>,
linux-tegra@...r.kernel.org, linux-rtc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] rtc: tegra: Implement suspend clock source
On Fri, Jun 14, 2019 at 03:35:14PM +0300, Dmitry Osipenko wrote:
> 14.06.2019 13:47, Thierry Reding пишет:
> > From: Thierry Reding <treding@...dia.com>
> >
> > The suspend clock source for Tegra210 and earlier is currently
> > implemented in the Tegra timer driver. However, the suspend clock source
> > code accesses registers that are part of the RTC hardware block, so both
> > can step on each others' toes. In practice this isn't an issue, but
> > there is no reason why the RTC driver can't implement the clock source,
> > so move the code over to the tegra-rtc driver.
> >
> > Signed-off-by: Thierry Reding <treding@...dia.com>
> > ---
>
>
> [snip]
>
> > +static struct tegra_rtc_info *to_tegra_rtc(struct clocksource *clksrc)
> > +{
> > + return container_of(clksrc, struct tegra_rtc_info, clksrc);
> > +}
>
> Shouldn't hurt to inline this function explicitly because I assume that it won't get
> inlined with a certain kernel configurations, like with enabled ftracing for example.
Yeah, makes sense.
Thierry
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists