From: Tony Lindgren <tony@atomide.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-omap@vger.kernel.org,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
dri-devel@lists.freedesktop.org,
Sebastian Reichel <sre@kernel.org>
Subject: Re: [PATCH] drm/omap: dsi: Fix PM for display blank with paired dss_pll calls
Date: Mon, 4 Feb 2019 07:42:08 -0800 [thread overview]
Message-ID: <20190204154208.GG5720@atomide.com> (raw)
In-Reply-To: <4a054efc-3111-38cd-aa9b-935ea224abe4@ti.com>
Hi,
* Tomi Valkeinen <tomi.valkeinen@ti.com> [190204 09:57]:
> On 31/01/2019 05:32, Tony Lindgren wrote:
> > Currently dsi_display_init_dsi() calls dss_pll_enable() but it is not
> > paired with dss_pll_disable() in dsi_display_uninit_dsi(). This leaves
>
> But it is paired with dsi_pll_uninit().
But we need to also call dss_pll_disable(). Now we're only calling
dsi_pll_disable() and skipping dss_pll_disable().
> > the DSS clocks enabled when the display is blanked wasting about extra
> > 5mW of power while idle.
>
> Which clocks? I think all the clocks are disabled. But if
> disconnect_lanes == false, the regulator is left enabled.
Without this patch I'm seeing DSS_CLKCTRL bit 10 OPTFCLKEN_SYS_CLK
left enabled after blanking, also known as sys_clk in the dts.
> If some clocks are left enabled, then that's a bug, but this didn't seem
> to be the case after a brief review of the code.
Yeah the code there currently is a bit confusing to follow.
With the missing call to dss_pll_disable(), we never call
clk_disable_unprepare(pll->clkin).
> > Let's fix this by setting a dsi->disconnect_lanes flag and making
> > the current dsi_pll_uninit() into dsi_pll_disable(). This way we can
> > just call dss_pll_disable() from dsi_display_uninit_dsi() and the
> > code becomes a bit easier to follow.
>
> It's been a long time since I worked on these DSI features, but:
> - If the regulator is disabled, the DSI lanes are in undefined state
> - If the DSI lanes are in undefined state, the panel often sees that as
> errors (or, in theory, might even read it as some real event) in the DSI
> lanes
> - If the panel driver can handle lanes in undefined state, it can set
> disconnect_lanes to true
> - ULPS needs the lanes to be in defined state (high/low, I can't recall)
Hmm OK. So after this patch we now have the following at dss and
dsi levels:
- dsi_pll_disable() calls regulator_disable(dsi->vdds_dsi_reg) if
dsi->disconnect_lanes is set
- dss_pll_disable() calls regulator_disable(pll->regulator)
unconditionally
At least I'm not seeing any issues with dss_pll_disable()
call regulator_disable(pll->regulator) even without having
dsi->disconnect_lanes set.
Sebastian do you think this might be an issue on n950 for a
blank/unblank cycle?
N950 does have vdda_video-supply = <&vdac> configured which
should be the pll->regulator I think.
My guess is that the dsi lanes are fine with just the
dsi->vdds_dsi_reg and do not need the pll->regulator :)
This guess is based on the fact that the DSS components
should be mostly independent modules on the DSS internal
interconnect.
> I can't remember the details, but I think there was a reason why the
> panel-dsi-cm.c doesn't disconnect the lanes... I also faintly remember
> that in Nokia we had some hacky code to change the pinmux to keep the
> pins in defined states even if the regulator got disabled. But that was
> never upstreamed.
OK good to know. That can be done with pinctrl named states now.
Regards,
Tony
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-02-04 15:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-31 3:32 [PATCH] drm/omap: dsi: Fix PM for display blank with paired dss_pll calls Tony Lindgren
2019-02-04 9:57 ` Tomi Valkeinen
2019-02-04 15:42 ` Tony Lindgren [this message]
2019-02-05 11:06 ` Tomi Valkeinen
2019-02-05 17:58 ` Tony Lindgren
2019-02-06 9:13 ` Tomi Valkeinen
2019-02-06 16:00 ` Tony Lindgren
2019-02-06 16:09 ` Tomi Valkeinen
2019-02-06 16:29 ` Tony Lindgren
2019-02-07 9:07 ` Tomi Valkeinen
2019-02-07 15:46 ` Tony Lindgren
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=20190204154208.GG5720@atomide.com \
--to=tony@atomide.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-omap@vger.kernel.org \
--cc=sre@kernel.org \
--cc=tomi.valkeinen@ti.com \
/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;
as well as URLs for NNTP newsgroup(s).