All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Archit Taneja <archit@ti.com>,
	linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH 6/6] OMAPDSS: use runtime PM's autosuspend
Date: Tue, 26 Nov 2013 10:27:47 +0000	[thread overview]
Message-ID: <529477A3.3050301@ti.com> (raw)
In-Reply-To: <5292A7F4.8030106@ti.com>

[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]

On 2013-11-25 03:29, Archit Taneja wrote:
> On Monday 18 November 2013 06:20 PM, Tomi Valkeinen wrote:
>> Use runtime PM's autosuspend support with delay of 100ms.
>>
>> This will prevent the driver from turning the DSS modules off and on
>> multiple times e.g. when loading the module.
> 
> Could you explain this a bit more?

First of all, I'm not quite sure if this is even needed. Things are
probably simpler without autosuspend, and we don't have much on/off
cycles going on in DSS, so I don't think autosuspend helps much.

Maybe it's even bad if somebody wants to enable/disable the DSS HW very
quickly. So in the minimum, autosuspend should be made configurable. For
now, I think I'll just leave it out.

> Are you saying that when we insert the omapdss module, we have a lot of
> runtime_get/put pairs in probe, which leads to us excessive writing of
> DISPC the registers during resume, and the autosuspend feature would
> delay the effect of runtime_put() for a while?

For example, first DSS is probed. the dss.c driver will enable dss_core
(i.e. the whole DSS hw block), do some register reads/writes, and
disable dss_core. Then DISPC is probed, and things go very much like
with DSS. And so on. Each submodule will enable and disable the whole
DSS, because nothing is keeping the DSS enabled between the probes.

With autosuspend, the DSS HW block will stay enabled long enough so the
next probe gets ran.

> Also, do we need to do this for all the platform devices? Could we use
> autosuspend only for the parent platform device, and the children
> platform devices don't use it? Or am I understanding things wrongly here?

In theory, yes. In practice, if I'm not mistaken, no. When a device is
enabled, it'll enable the parent device. When the device is disabled,
its parent device will be immediately disabled (if nothing is using it),
so autosuspend doesn't have an effect there.

So we need to use autosuspend for the child devices.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Archit Taneja <archit@ti.com>,
	linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH 6/6] OMAPDSS: use runtime PM's autosuspend
Date: Tue, 26 Nov 2013 12:27:47 +0200	[thread overview]
Message-ID: <529477A3.3050301@ti.com> (raw)
In-Reply-To: <5292A7F4.8030106@ti.com>

[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]

On 2013-11-25 03:29, Archit Taneja wrote:
> On Monday 18 November 2013 06:20 PM, Tomi Valkeinen wrote:
>> Use runtime PM's autosuspend support with delay of 100ms.
>>
>> This will prevent the driver from turning the DSS modules off and on
>> multiple times e.g. when loading the module.
> 
> Could you explain this a bit more?

First of all, I'm not quite sure if this is even needed. Things are
probably simpler without autosuspend, and we don't have much on/off
cycles going on in DSS, so I don't think autosuspend helps much.

Maybe it's even bad if somebody wants to enable/disable the DSS HW very
quickly. So in the minimum, autosuspend should be made configurable. For
now, I think I'll just leave it out.

> Are you saying that when we insert the omapdss module, we have a lot of
> runtime_get/put pairs in probe, which leads to us excessive writing of
> DISPC the registers during resume, and the autosuspend feature would
> delay the effect of runtime_put() for a while?

For example, first DSS is probed. the dss.c driver will enable dss_core
(i.e. the whole DSS hw block), do some register reads/writes, and
disable dss_core. Then DISPC is probed, and things go very much like
with DSS. And so on. Each submodule will enable and disable the whole
DSS, because nothing is keeping the DSS enabled between the probes.

With autosuspend, the DSS HW block will stay enabled long enough so the
next probe gets ran.

> Also, do we need to do this for all the platform devices? Could we use
> autosuspend only for the parent platform device, and the children
> platform devices don't use it? Or am I understanding things wrongly here?

In theory, yes. In practice, if I'm not mistaken, no. When a device is
enabled, it'll enable the parent device. When the device is disabled,
its parent device will be immediately disabled (if nothing is using it),
so autosuspend doesn't have an effect there.

So we need to use autosuspend for the child devices.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

  reply	other threads:[~2013-11-26 10:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-18 12:50 [PATCH 0/6] OMAPDSS: suspend/resume improvements Tomi Valkeinen
2013-11-18 12:50 ` Tomi Valkeinen
2013-11-18 12:50 ` [PATCH 1/6] OMAPDSS: APPLY: set infos to dirty on enable Tomi Valkeinen
2013-11-18 12:50   ` Tomi Valkeinen
2013-11-25  1:06   ` Archit Taneja
2013-11-25  1:18     ` Archit Taneja
2013-11-26 10:21     ` Tomi Valkeinen
2013-11-26 10:21       ` Tomi Valkeinen
2013-11-18 12:50 ` [PATCH 2/6] OMAPDSS: DISPC: Remove context restore Tomi Valkeinen
2013-11-18 12:50   ` Tomi Valkeinen
2013-11-18 12:50 ` [PATCH 3/6] OMAPDSS: DSS remove ctx stuff Tomi Valkeinen
2013-11-18 12:50   ` Tomi Valkeinen
2013-11-18 12:50 ` [PATCH 4/6] OMAPDSS: remove dss_get_ctx_loss_count Tomi Valkeinen
2013-11-18 12:50   ` Tomi Valkeinen
2013-11-18 12:50 ` [PATCH 5/6] OMAPDSS: add debug print for runtime suspend/resume Tomi Valkeinen
2013-11-18 12:50   ` Tomi Valkeinen
2013-11-18 12:50 ` [PATCH 6/6] OMAPDSS: use runtime PM's autosuspend Tomi Valkeinen
2013-11-18 12:50   ` Tomi Valkeinen
2013-11-25  1:29   ` Archit Taneja
2013-11-25  1:41     ` Archit Taneja
2013-11-26 10:27     ` Tomi Valkeinen [this message]
2013-11-26 10:27       ` Tomi Valkeinen

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=529477A3.3050301@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=archit@ti.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-omap@vger.kernel.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.