<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/4/22 Tomasz Figa <span dir="ltr"><<a href="mailto:t.figa@samsung.com" target="_blank">t.figa@samsung.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote:<br>
> On 04/22/2013 12:03 PM, Inki Dae wrote:<br>
> >     > Also looks good to me. But what if power domain was disabled without<br>
> >     > pm<br>
> >     > runtime? In this case, you must enable the power domain at machine<br>
> >     > code or<br>
> >     > bootloader somewhere. This way would not only need some hard codes<br>
> >     > to turn<br>
> >     > the power domain on but also not manage power management fully. This<br>
> >     > is same as only the use of pm runtime interface(needing some hard<br>
> >     > codes without pm runtime) so I don't prefer to add<br>
> >     > clk_enable/disable to fimd probe(). I quite tend to force only the<br>
> >     > use of pm runtime as possible. So please add the hard codes to<br>
> >     > machine code or bootloader like you did for power domain if you<br>
> >     > want to use drm fimd without pm runtime.<br>
> ><br>
> >     That's not how the runtime PM, clock subsystems work:<br>
> ><br>
> >     1) When CONFIG_PM_RUNTIME is disabled, all the used hardware must be<br>
> >     kept<br>
> >     powered on all the time.<br>
> ><br>
> >     2) Common Clock Framework will always gate all clocks that have zero<br>
> >     enable_count. Note that CCF support for Exynos is already merged for<br>
> >     3.10 and it will be the only available clock support method for<br>
> >     Exynos.<br>
> ><br>
> >     AFAIK, drivers must work correctly in both cases, with<br>
> >     CONFIG_PM_RUNTIME<br>
> >     enabled and disabled.<br>
> ><br>
> > Then is the driver worked correctly if the power domain to this device was<br>
> > disabled at bootloader without CONFIG_PM_RUNTIME and with clk_enable()?  I<br>
> > think, in this case, the device wouldn't be worked correctly because the<br>
> > power of the device remains off. So you must enable the power domain<br>
> > somewhere. What is the difference between these two cases?<br>
><br>
> How about making the driver dependant on PM_RUNTIME and making it always<br>
> use pm_runtime_* API, regardless if the platform actually implements runtime<br>
> PM or not ? Is there any issue in using the Runtime PM core always, rather<br>
> than coding any workarounds in drivers when PM_RUNTIME is disabled ?<br>
<br>
</div></div>I don't think this is a good idea. This would mean that any user that from<br>
some reasons don't want to use PM_RUNTIME, would not be able to use the driver<br>
anymore.<br>
<br></blockquote><div><br></div><div>Again. There is any case that the driver isn't worked correctly without CONFIG_PM_RUNTIME and with clk_enable(). Could you guarantee the driver to be worked correctly only adding clk_enable() to probe() without CONFIG_PM_RUNTIME? as I said before, what if the power domain to the device was disabled?<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Rafael, Kevin, do you have any opinion on this?<br>
<div class="im HOEnZb"><br>
Best regards,<br>
--<br>
Tomasz Figa<br>
Samsung Poland R&D Center<br>
SW Solution Development, Kernel and System Framework<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
dri-devel mailing list<br>
<a href="mailto:dri-devel@lists.freedesktop.org">dri-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/dri-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/dri-devel</a><br>
</div></div></blockquote></div><br></div></div>