Thread (7 messages) 7 messages, 2 authors, 2015-08-17

Re: [PATCHv4 2/4] serial: imx: add runtime pm support

From: Eduardo Valentin <edubezval@gmail.com>
Date: 2015-08-17 17:28:33
Also in: linux-pm, lkml

Bartlomiej,

On Mon, Aug 17, 2015 at 05:40:59PM +0200, Bartlomiej Zolnierkiewicz wrote:
Hi,

On Friday, August 14, 2015 09:37:46 PM Eduardo Valentin wrote:
quoted
This change introduces the runtime pm support on imx serial
driver. The objective is to be able to idle the uart
port whenever it is not in use while still being able
to wake it up when needed. The key changes in this patch are:
1. Move the clock handling to runtime pm. Both, ipg and per,
are now handled in the suspend and resume callbacks. Only
enabling and disabling the clocks are handled in runtime
suspend and resume, so we are able to use runtime pm
in IRQ context.
2. Clocks are prepared in probe and unprepared in remove,
so we do not need to prepare (may sleep) in runtime pm.
3. We mark the device activity based on uart and console
callbacks. Whenever the device is needed and we want to
access registers, we runtime_pm_get and then mark its
last usage when we are done. This is done also across
IRQs and DMA callbacks.
4. We reuse the infrastructure in place for suspend and
resume, so we do not need to redo wakeup configuration,
or context save and restore.

After this change, the clocks are still sane, in the sense
of having balanced clock prepare and enable.
The clock changes in this patch seem to make this driver
non-functional with CONFIG_PM=n.  Have you tested your
changes with CONFIG_PM=n?
This is a valid point. I tried it yes, but maybe because in my
environment I had another user of the pll3_80m I did not see
issues with PM=n. Now after sanitizing my .config, executing
the system with only the uart port / console as user of pll3_80m,
I see the uart console hanging because the uart clocks get gated.
Generally the driver should not depend on PM support to
enable its clocks.  We had this issue in few Exynos-specific
drivers not that long time ago..
No doubt here. I am checking the best way to cover for this case.
Probably I will go for adding the support via the pm_clk*
infrastructure, as already suggested by khilman.

Thanks for spotting this.

BR,
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help