Re: [PATCH v4] drm/exynos: prepare FIMD clocks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 






2013/4/22 Tomasz Figa <t.figa@xxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux