2013/4/22 Sylwester Nawrocki <s.nawrocki at 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 ? > > That's what I want~~ :)
> Thanks, > Sylwester > _______________________________________________ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130422/c2e62ab4/attachment.html>