2013/4/23 myungjoo.ham <myungjoo.ham at samsung.com> > 2013/4/22 Inki Dae > > 2013/4/22 Rafael J. Wysocki <rjw at sisk.pl> > > > On Monday, April 22, 2013 12:37:36 PM Tomasz Figa wrote: > > > > On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote: > > > > > 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 > ? > > > > > > > > I don't think this is a good idea. This would mean that any user that > from > > > > some reasons don't want to use PM_RUNTIME, would not be able to use > the driver > > > > anymore. > > > > > > > > Rafael, Kevin, do you have any opinion on this? > > > I agree. > > > > > > Drivers should work for CONFIG_PM_RUNTIME unset too and static inline > stubs for > > > all runtime PM helpers are available in that case. > > > > > Hi Rafael, > > The embedded system, at least Exynos SoC case, has the power domain > device > and this device could be enabled only by pm runtime interface. So the > device > couldn't be worked correctly without turning the power domain on only > calling clk_enable(). In this case, the power domain must be enabled at > machine code or bootloader. And the machine without CONFIG_PM_RUNTIME would > assume that their own drivers always are enabled so the devices would be > worked correctly. Is there any my missing point? > > > - Power domain: not controlled if !CONFIG_PM_RUNTIME. Thus, we may > assume that every power domain is kept ON from boot time if > !CONFIG_PM_RUNTIME. > If power domain is kept OFF from boot time (machine init code or > bootloader) > with !CONFIG_PM_RUNTIME, then it's simple a mistake at BSP writer. > > - Yes, the clock is still controlled while !CONFIG_PM_RUNTIME. > > My opinion is also to let probe do clk-enables though I don't want it > to have #ifdef or "clk_enable()" in the probe function. > Thus, implementing "power_on()"-like function in the driver and let probe() > and > runtime_pm_get callback call it seems appropriate to me. > (that "fimd_active(ctx, true)" is "power-on" to itself, right?) > > I thought that it should assume the power domain and relevant clocks are enabled without CONFIG_PM_RUNTIME. So could anyone please tell me about that? If only the power domain , I think Tomasz's proposal is good solution.
Thanks, Inki Dae > > Cheers, > MyungJoo > > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-samsung-soc" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130423/b78b28ed/attachment.html>
