2013/4/22 Sylwester Nawrocki s.nawrocki@samsung.com
On 04/22/2013 12:03 PM, Inki Dae wrote:
> Also looks good to me. But what if power domain was disabledwithout pm
> runtime? In this case, you must enable the power domain at machinecode or
> bootloader somewhere. This way would not only need some hard codesto turn
> the power domain on but also not manage power management fully.This is same
> as only the use of pm runtime interface(needing some hard codeswithout pm
> runtime) so I don't prefer to add clk_enable/disable to fimdprobe(). I quite
> tend to force only the use of pm runtime as possible. So pleaseadd the hard
> codes to machine code or bootloader like you did for power domainif you
> want to use drm fimd without pm runtime. That's not how the runtime PM, clock subsystems work: 1) When CONFIG_PM_RUNTIME is disabled, all the used hardware must bekept
powered on all the time. 2) Common Clock Framework will always gate all clocks that have zero enable_count. Note that CCF support for Exynos is already merged for3.10 and
it will be the only available clock support method for Exynos. AFAIK, drivers must work correctly in both cases, withCONFIG_PM_RUNTIME
enabled and disabled.Then is the driver worked correctly if the power domain to this device
was
disabled at bootloader without CONFIG_PM_RUNTIME and with clk_enable()?
I
think, in this case, the device wouldn't be worked correctly because the
power
of the device remains off. So you must enable the power domain
somewhere. What
is the difference between these two cases?
How about making the driver dependant on PM_RUNTIME and making it always use pm_runtime_* API, regardless if the platform actually implements runtime PM or not ? Is there any issue in using the Runtime PM core always, rather than coding any workarounds in drivers when PM_RUNTIME is disabled ?
That's what I want~~ :)
Thanks, Sylwester _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel