[PATCH v4] drm/exynos: prepare FIMD clocks

Inki Dae inki.dae at samsung.com
Mon Apr 22 04:52:11 PDT 2013


2013/4/22 Tomasz Figa <t.figa at samsung.com>

> 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.
>
>
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?


> Rafael, Kevin, do you have any opinion on this?
>
> Best regards,
> --
> Tomasz Figa
> Samsung Poland R&D Center
> SW Solution Development, Kernel and System Framework
>
> _______________________________________________
> 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/bf04724c/attachment.html>


More information about the dri-devel mailing list