LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Douglas Anderson <dianders@chromium.org> To: dri-devel@lists.freedesktop.org Cc: tzimmermann@suse.de, linux-arm-msm@vger.kernel.org, a.hajda@samsung.com, sam@ravnborg.org, airlied@linux.ie, bjorn.andersson@linaro.org, daniel@ffwll.ch, devicetree@vger.kernel.org, rodrigo.vivi@intel.com, jonas@kwiboo.se, narmstrong@baylibre.com, Laurent.pinchart@ideasonboard.com, robert.foss@linaro.org, jernej.skrabec@gmail.com, mripard@kernel.org, linus.walleij@linaro.org, maarten.lankhorst@linux.intel.com, rajeevny@codeaurora.org, lyude@redhat.com, thierry.reding@gmail.com, steev@kali.org, Douglas Anderson <dianders@chromium.org>, Sandeep Panda <spanda@codeaurora.org>, linux-kernel@vger.kernel.org Subject: [PATCH 2/6] drm/bridge: ti-sn65dsi86: Fix power off sequence Date: Wed, 28 Jul 2021 09:45:53 -0700 [thread overview] Message-ID: <20210728094511.2.If8a8ec3bf1855cf0dbb62c005a71d6698c99c125@changeid> (raw) In-Reply-To: <20210728164557.1882787-1-dianders@chromium.org> When testing with a panel that's apparently a little more persnickety about the correct power sequence (specifically Samsung ATNA33XC20), we found that the ti-sn65dsi86 was doing things just slightly wrong. Looking closely at the ti-sn65dsi86's datasheet, the power off sequence is supposed to be: 1. Clear VSTREAM_ENABLE bit 2. Stop DSI stream from GPU. DSI lanes must be placed in LP11 state. 3. Program the ML_TX_MODE to 0x0 (OFF) 4. Program the DP_NUM_LANES register to 0x0 5. Clear the DP_PLL_EN bit. 6. Deassert the EN pin. 7. Remove power from supply pins Since we were doing the whole sequence in the "disable", I believe that step #2 (stopping the DSI stream from the GPU) wasn't happening. We also weren't setting DP_NUM_LANES to 0. Let's fix this. NOTE: things are a little asymmetric now. For instance, we turn the PLL on in "enable" but now we're not turning it off until "post_disable". It would seem to make sense to move the PLL turning on to "pre_enable" to match. Unfortunately, I don't believe that's allowed. It looks as if (in the non-refclk mode which probably nobody is using) we have to wait until the MIPI clock is there before we can enable the PLL. In any case, the way it is here won't really hurt--it'll just leave the PLL on a little longer. Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver") Signed-off-by: Douglas Anderson <dianders@chromium.org> --- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index 9bf889302bcc..5e932070a1c3 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -766,10 +766,6 @@ static void ti_sn_bridge_disable(struct drm_bridge *bridge) /* disable video stream */ regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG, VSTREAM_ENABLE, 0); - /* semi auto link training mode OFF */ - regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0); - /* disable DP PLL */ - regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 0); } static void ti_sn_bridge_set_dsi_rate(struct ti_sn65dsi86 *pdata) @@ -1106,6 +1102,13 @@ static void ti_sn_bridge_post_disable(struct drm_bridge *bridge) { struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge); + /* semi auto link training mode OFF */ + regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0); + /* Num lanes to 0 as per power sequencing in data sheet */ + regmap_update_bits(pdata->regmap, SN_SSC_CONFIG_REG, DP_NUM_LANES_MASK, 0); + /* disable DP PLL */ + regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 0); + if (!pdata->refclk) ti_sn65dsi86_disable_comms(pdata); -- 2.32.0.432.gabb21c7263-goog
next prev parent reply other threads:[~2021-07-28 16:46 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-28 16:45 [PATCH 0/6] drm/panel: atna33xc20: Fix the Samsung ATNA33XC20 panel Douglas Anderson 2021-07-28 16:45 ` [PATCH 1/6] drm/dp: Don't zero PWMGEN_BIT_COUNT when driver_pwm_freq_hz not specified Douglas Anderson 2021-07-28 16:45 ` Douglas Anderson [this message] 2021-07-29 11:47 ` [PATCH 2/6] drm/bridge: ti-sn65dsi86: Fix power off sequence Robert Foss 2021-07-28 16:45 ` [PATCH 3/6] drm/bridge: ti-sn65dsi86: Add some 100 us delays Douglas Anderson 2021-07-29 11:48 ` Robert Foss 2021-07-28 16:45 ` [PATCH 4/6] Revert "drm/panel-simple: Add Samsung ATNA33XC20" Douglas Anderson 2021-07-28 16:45 ` [PATCH 5/6] Revert "drm/panel-simple: Support for delays between GPIO & regulator" Douglas Anderson 2021-07-28 16:45 ` [PATCH 6/6] drm/panel: atna33xc20: Introduce the Samsung ATNA33XC20 panel Douglas Anderson 2021-07-29 19:42 ` [PATCH 0/6] drm/panel: atna33xc20: Fix " Sean Paul
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=20210728094511.2.If8a8ec3bf1855cf0dbb62c005a71d6698c99c125@changeid \ --to=dianders@chromium.org \ --cc=Laurent.pinchart@ideasonboard.com \ --cc=a.hajda@samsung.com \ --cc=airlied@linux.ie \ --cc=bjorn.andersson@linaro.org \ --cc=daniel@ffwll.ch \ --cc=devicetree@vger.kernel.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=jernej.skrabec@gmail.com \ --cc=jonas@kwiboo.se \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lyude@redhat.com \ --cc=maarten.lankhorst@linux.intel.com \ --cc=mripard@kernel.org \ --cc=narmstrong@baylibre.com \ --cc=rajeevny@codeaurora.org \ --cc=robert.foss@linaro.org \ --cc=rodrigo.vivi@intel.com \ --cc=sam@ravnborg.org \ --cc=spanda@codeaurora.org \ --cc=steev@kali.org \ --cc=thierry.reding@gmail.com \ --cc=tzimmermann@suse.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: linkBe 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).