Re: [PATCH v4] drm/exynos: prepare FIMD clocks

[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 disabled without pm
>     > runtime? In this case, you must enable the power domain at machine code or
>     > bootloader somewhere. This way would not only need some hard codes to 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 codes without pm
>     > runtime) so I don't prefer to add clk_enable/disable to fimd probe(). I quite
>     > tend to force only the use of pm runtime as possible. So please add the hard
>     > codes to machine code or bootloader like you did for power domain if 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 be kept
>     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 for 3.10 and
>     it will be the only available clock support method for Exynos.
> 
>     AFAIK, drivers must work correctly in both cases, with CONFIG_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 ?

Thanks,
Sylwester