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: > > 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 >
Attachment:
signature.asc
Description: Digital signature
