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