All of lore.kernel.org
 help / color / mirror / Atom feed
From: Inki Dae <inki.dae@samsung.com>
To: Tomasz Figa <t.figa@samsung.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>,
	"patches@linaro.org" <patches@linaro.org>,
	Kevin Hilman <khilman@deeprootsystems.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Tomasz Figa <tomasz.figa@gmail.com>,
	DRI mailing list <dri-devel@lists.freedesktop.org>,
	rjw@sisk.pl, linux-samsung-soc@vger.kernel.org,
	myungjoo.ham@samsung.com,
	Sylwester Nawrocki <s.nawrocki@samsung.com>,
	Vikas Sajjan <vikas.sajjan@linaro.org>,
	linaro-kernel@lists.linaro.org,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH v4] drm/exynos: prepare FIMD clocks
Date: Mon, 22 Apr 2013 20:52:11 +0900	[thread overview]
Message-ID: <CAAQKjZOcqcPaDShDUYd7VfNn0zQNbt9QeigR8hy2VNow_xUT7w@mail.gmail.com> (raw)
In-Reply-To: <2218256.k8DNv9nCJl@amdc1227>


[-- Attachment #1.1: Type: text/plain, Size: 3091 bytes --]

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:
> > >     > 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
>

[-- Attachment #1.2: Type: text/html, Size: 4251 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

  parent reply	other threads:[~2013-04-22 11:52 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-08 11:07 [PATCH v4] drm/exynos: prepare FIMD clocks Vikas Sajjan
2013-04-08 11:11 ` Viresh Kumar
2013-04-19  8:55   ` Vikas Sajjan
2013-04-20 15:26     ` Inki Dae
2013-04-21  7:24       ` Vikas Sajjan
2013-04-21  7:53       ` Viresh Kumar
2013-04-21 10:35         ` Tomasz Figa
2013-04-21 14:05           ` Inki Dae
2013-04-21 14:15             ` Tomasz Figa
2013-04-21 10:26   ` Tomasz Figa
2013-04-21 13:36     ` Inki Dae
2013-04-21 14:43       ` Tomasz Figa
2013-04-22  5:11         ` Inki Dae
2013-04-22  9:52           ` Tomasz Figa
2013-04-22 10:03             ` Inki Dae
2013-04-22 10:17               ` Sylwester Nawrocki
2013-04-22 10:20                 ` Inki Dae
2013-04-22 10:37                 ` Tomasz Figa
2013-04-22 11:42                   ` Rafael J. Wysocki
2013-04-22 12:04                     ` Inki Dae
2013-04-23 11:51                       ` myungjoo.ham
2013-04-23 12:09                         ` Inki Dae
2013-04-22 11:52                   ` Inki Dae [this message]
2013-04-22  5:14         ` Viresh Kumar
2013-04-22  9:56           ` Tomasz Figa
2013-04-22 10:05             ` Sylwester Nawrocki
2013-04-22 12:30               ` Tomasz Figa
2013-04-22 10:26             ` Viresh Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAQKjZOcqcPaDShDUYd7VfNn0zQNbt9QeigR8hy2VNow_xUT7w@mail.gmail.com \
    --to=inki.dae@samsung.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kgene.kim@samsung.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=patches@linaro.org \
    --cc=rjw@sisk.pl \
    --cc=s.nawrocki@samsung.com \
    --cc=t.figa@samsung.com \
    --cc=tomasz.figa@gmail.com \
    --cc=vikas.sajjan@linaro.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.