[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211019125929.GD16320@pengutronix.de>
Date: Tue, 19 Oct 2021 14:59:29 +0200
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Daniel Lezcano <daniel.lezcano@...aro.org>
Cc: Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
linux-pm@...r.kernel.org, Petr Benes <petrben@...il.com>,
Amit Kucheria <amitk@...nel.org>, linux-kernel@...r.kernel.org,
Andrzej Pietrasiewicz <andrzej.p@...labora.com>,
NXP Linux Team <linux-imx@....com>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
David Jander <david@...tonic.nl>,
Zhang Rui <rui.zhang@...el.com>,
Fabio Estevam <festevam@...il.com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v1 1/1] thermal: imx: implement runtime PM support
On Tue, Oct 19, 2021 at 01:55:32PM +0200, Daniel Lezcano wrote:
> On 19/10/2021 13:51, Oleksij Rempel wrote:
> > Hi Daniel,
> >
> > On Tue, Oct 19, 2021 at 01:04:46PM +0200, Daniel Lezcano wrote:
> >> On 24/09/2021 13:50, Oleksij Rempel wrote:
> >>> Starting with commit d92ed2c9d3ff ("thermal: imx: Use driver's local
> >>> data to decide whether to run a measurement") this driver stared using
> >>> irq_enabled flag to make decision to power on/off the thermal core. This
> >>> triggered a regression, where after reaching critical temperature, alarm
> >>> IRQ handler set irq_enabled to false, disabled thermal core and was not
> >>> able read temperature and disable cooling sequence.
> >>>
> >>> In case the cooling device is "CPU/GPU freq", the system will run with
> >>> reduce performance until next reboot.
> >>>
> >>> To solve this issue, we need to move all parts implementing hand made
> >>> runtime power management and let it handle actual runtime PM framework.
> >>>
> >>> Fixes: d92ed2c9d3ff ("thermal: imx: Use driver's local data to decide whether to run a measurement")
> >>> Signed-off-by: Oleksij Rempel <o.rempel@...gutronix.de>
> >>
> >> Thanks for this fix.
> >>
> >> Petr or Oleksij,
> >>
> >> could you confirm it is tested and working without CONFIG_PM ?
> >
> > Petr was right, no it is not working without PM.
> Ok, thanks.
>
> I suppose the fix is related to the initialization of the sensor which
> should be enabled with/out pm_runtime, right ?
No, i did sanity check on pm_runtime_put() within the probe. Without PM
it will properly return ENOSYS, so I aborted the probe. Looks like I
should ignore return value on this function like every driver is doing
it.
>
>
> --
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Powered by blists - more mailing lists