From mboxrd@z Thu Jan 1 00:00:00 1970 From: Inki Dae Subject: Re: [PATCH v4] drm/exynos: prepare FIMD clocks Date: Mon, 22 Apr 2013 20:52:11 +0900 Message-ID: References: <1365419265-21238-1-git-send-email-vikas.sajjan@linaro.org> <51750E43.1050602@samsung.com> <2218256.k8DNv9nCJl@amdc1227> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0987933675==" Return-path: In-Reply-To: <2218256.k8DNv9nCJl@amdc1227> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Tomasz Figa Cc: Kukjin Kim , "patches@linaro.org" , Kevin Hilman , Viresh Kumar , Tomasz Figa , DRI mailing list , rjw@sisk.pl, linux-samsung-soc@vger.kernel.org, myungjoo.ham@samsung.com, Sylwester Nawrocki , Vikas Sajjan , linaro-kernel@lists.linaro.org, "linux-media@vger.kernel.org" List-Id: linux-samsung-soc@vger.kernel.org --===============0987933675== Content-Type: multipart/alternative; boundary=089e0115fe5cf5230904daf1b205 --089e0115fe5cf5230904daf1b205 Content-Type: text/plain; charset=ISO-8859-1 2013/4/22 Tomasz Figa > 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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > --089e0115fe5cf5230904daf1b205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



2013/4/22 Tomasz Figa <t.figa@samsung.com>
On Monday 22 of April 2013 12:17:39= Sylwester Nawrocki wrote:
> On 04/22/2013 12:03 PM, Inki Dae wrote:
> > =A0 =A0 > Also looks good to me. But what if power domain was = disabled without
> > =A0 =A0 > pm
> > =A0 =A0 > runtime? In this case, you must enable the power dom= ain at machine
> > =A0 =A0 > code or
> > =A0 =A0 > bootloader somewhere. This way would not only need s= ome hard codes
> > =A0 =A0 > to turn
> > =A0 =A0 > the power domain on but also not manage power manage= ment fully. This
> > =A0 =A0 > is same as only the use of pm runtime interface(need= ing some hard
> > =A0 =A0 > codes without pm runtime) so I don't prefer to a= dd
> > =A0 =A0 > clk_enable/disable to fimd probe(). I quite tend to = force only the
> > =A0 =A0 > use of pm runtime as possible. So please add the har= d codes to
> > =A0 =A0 > machine code or bootloader like you did for power do= main if you
> > =A0 =A0 > want to use drm fimd without pm runtime.
> >
> > =A0 =A0 That's not how the runtime PM, clock subsystems work:=
> >
> > =A0 =A0 1) When CONFIG_PM_RUNTIME is disabled, all the used hardw= are must be
> > =A0 =A0 kept
> > =A0 =A0 powered on all the time.
> >
> > =A0 =A0 2) Common Clock Framework will always gate all clocks tha= t have zero
> > =A0 =A0 enable_count. Note that CCF support for Exynos is already= merged for
> > =A0 =A0 3.10 and it will be the only available clock support meth= od for
> > =A0 =A0 Exynos.
> >
> > =A0 =A0 AFAIK, drivers must work correctly in both cases, with > > =A0 =A0 CONFIG_PM_RUNTIME
> > =A0 =A0 enabled and disabled.
> >
> > Then is the driver worked correctly if the power domain to this d= evice was
> > disabled at bootloader without CONFIG_PM_RUNTIME and with clk_ena= ble()? =A0I
> > 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 dom= ain
> > somewhere. What is the difference between these two cases?
>
> How about making the driver dependant on PM_RUNTIME and making it alwa= ys
> use pm_runtime_* API, regardless if the platform actually implements r= untime
> PM or not ? Is there any issue in using the Runtime PM core always, ra= ther
> 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 driv= er isn't worked correctly without CONFIG_PM_RUNTIME and with clk_enable= (). Could you guarantee the driver to be worked correctly only adding clk_e= nable() to probe() without CONFIG_PM_RUNTIME? as I said before, what if the= power domain to the device was disabled?
=A0
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@lists.freedesk= top.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

--089e0115fe5cf5230904daf1b205-- --===============0987933675== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0987933675==--