2013/4/22 Sylwester Nawrocki <s.nawrocki@xxxxxxxxxxx>
On 04/22/2013 12:03 PM, Inki Dae wrote:How about making the driver dependant on PM_RUNTIME and making it always
> > 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?
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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
