mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stefan Agner <stefan@agner.ch>
To: Marek Vasut <marex@denx.de>
Cc: Anson Huang <anson.huang@nxp.com>,
	airlied@linux.ie, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH] drm: mxsfb: fix runtime PM handling
Date: Fri, 13 Jul 2018 12:33:36 +0200	[thread overview]
Message-ID: <00b5faf737efd1054eb4f0f0e6fc8369@agner.ch> (raw)
In-Reply-To: <90d16681-2a7a-4826-0411-478353d2afe3@denx.de>

On 13.07.2018 11:12, Marek Vasut wrote:
> On 07/13/2018 11:06 AM, Anson Huang wrote:
> [...]
>>>
>>> On 07/13/2018 10:54 AM, Anson Huang wrote:
>>>> As display power domain is combined with lcdif node on some i.MX
>>>> platforms like i.MX6SL, when lcdif driver is enabled, the mxsfb_load
>>>> is called to enable runtime pm, and a pair of pm_runtime_get_sync and
>>>> pm_runtime_put_sync are also called, that will cause generic power
>>>> domain driver to disable lcdif power domain and lcdif is no longer
>>>> working, the lcdif power should ONLY be turned off when display is
>>>> disabled, so move the pm_runtime_put_sync to mxsfb_unload and remove
>>>> the pm_runtime_get_sync in mxsfb_unload as well, in this way, when
>>>> display is enabled, the lcdif power will be always ON until the
>>>> display is disabled.
>>>>
>>>> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
>>>
>>> Doesn't this also mean the block will always be on, thus wasting power ?
>>
>> I think drm driver should have somewhere to implement the display
>> disable case, like when fb0 is blank (echo 1 > /sys/class/graphics/fb0/blank),
> 
> Isn't this just the fbdev emulation on top of drm/kms ?
> I think this stuff can be compiled out completely.
> 
>> then lcdif can be powered gated, and
>> when display is back on (unblank), lcdif needs to be re-initialization and display will
>> be on, current implementation is incorrect, with kernel booting up, lcdif
>> is NOT working at all.
> 
> It works fine on MX6SX , so I think this is isolated to MX6SL ?
> I'm CCing Stefan, he might have some valuable feedback here.
> 

Yeah not sure, but putting it in mxsfb_load seems wrong.

MXSFB uses struct drm_simple_display_pipe_funcs which does have
enable/disable callbacks, probably closer to what we want...

--
Stefan

>> The runtime power gating case can be implemented later to save power,
>> need lcdif experts to do it. Thanks.
>>
>> Anson.
>>
>>>
>>>> ---
>>>>  drivers/gpu/drm/mxsfb/mxsfb_drv.c | 3 +--
>>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>>>> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>>>> index ffe5137..1ba179b 100644
>>>> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>>>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>>>> @@ -235,7 +235,6 @@ static int mxsfb_load(struct drm_device *drm,
>>>> unsigned long flags)
>>>>
>>>>  	pm_runtime_get_sync(drm->dev);
>>>>  	ret = drm_irq_install(drm, platform_get_irq(pdev, 0));
>>>> -	pm_runtime_put_sync(drm->dev);
>>>>
>>>>  	if (ret < 0) {
>>>>  		dev_err(drm->dev, "Failed to install IRQ handler\n"); @@ -264,6
>>>> +263,7 @@ static int mxsfb_load(struct drm_device *drm, unsigned long
>>>> flags)
>>>>  err_irq:
>>>>  	drm_panel_detach(mxsfb->panel);
>>>>  err_vblank:
>>>> +	pm_runtime_put_sync(drm->dev);
>>>>  	pm_runtime_disable(drm->dev);
>>>>
>>>>  	return ret;
>>>> @@ -279,7 +279,6 @@ static void mxsfb_unload(struct drm_device *drm)
>>>>  	drm_kms_helper_poll_fini(drm);
>>>>  	drm_mode_config_cleanup(drm);
>>>>
>>>> -	pm_runtime_get_sync(drm->dev);
>>>>  	drm_irq_uninstall(drm);
>>>>  	pm_runtime_put_sync(drm->dev);
>>>>
>>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Marek Vasut

  parent reply	other threads:[~2018-07-13 10:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-13  8:54 Anson Huang
2018-07-13  9:03 ` Marek Vasut
2018-07-13  9:06   ` Anson Huang
2018-07-13  9:12     ` Marek Vasut
2018-07-13 10:30       ` Leonard Crestez
2018-07-13 10:33       ` Stefan Agner [this message]
2018-07-13 10:36         ` Marek Vasut
2018-07-13 10:39           ` Stefan Agner
2018-07-13 10:45             ` Marek Vasut

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=00b5faf737efd1054eb4f0f0e6fc8369@agner.ch \
    --to=stefan@agner.ch \
    --cc=airlied@linux.ie \
    --cc=anson.huang@nxp.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marex@denx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®