From: Michael Walle <mwalle@kernel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: tony@atomide.com, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, Laurent.pinchart@ideasonboard.com,
andrzej.hajda@intel.com, marijn.suijten@somainline.org,
marex@denx.de, rfoss@kernel.org, dave.stevenson@raspberrypi.com,
jernej.skrabec@gmail.com, alexander.stein@ew.tq-group.com,
quic_jesszhan@quicinc.com, jonas@kwiboo.se,
linux-arm-msm@vger.kernel.org, quic_abhinavk@quicinc.com,
mripard@kernel.org, sean@poorly.run, neil.armstrong@linaro.org,
dianders@chromium.org, konrad.dybcio@linaro.org,
tzimmermann@suse.de, freedreno@lists.freedesktop.org
Subject: Re: [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
Date: Tue, 28 Nov 2023 17:55:53 +0100 [thread overview]
Message-ID: <dce76a6e1321a6374ad39125bead56b3@kernel.org> (raw)
In-Reply-To: <CAA8EJpphwXoKnzDkY3cBqzsDZwdw+nze-Ev2toPBJm-2VJvY_g@mail.gmail.com>
>> > DSI device lifetime has three different stages:
>> > 1. before the DSI link being powered up and clocking,
>> > 2. when the DSI link is in LP state (for the purpose of this question,
>> > this is the time between the DSI link being powered up and the video
>> > stream start)
>> > 3. when the DSI link is in HS state (while streaming the video).
>>
>> It's not clear to me what (2) is. What is the state of the clock and
>> data lanes?
>
> Clk an Data0 should be in the LP mode, ready for LP Data Transfer.
Then this is somehow missing
https://docs.kernel.org/gpu/drm-kms-helpers.html#mipi-dsi-bridge-operation
A DSI host should keep the PHY powered down until the pre_enable
operation
is called. All lanes are in an undefined idle state up to this point,
and
it must not be assumed that it is LP-11. pre_enable should initialise
the
PHY, set the data lanes to LP-11, and the clock lane to either LP-11
or HS
depending on the mode_flag MIPI_DSI_CLOCK_NON_CONTINUOUS.
So I don't think these three states are sufficient, see below, that
there
should be at least four.
-michael
>
> I don't think we support ULPS currently.
>
>
>>
>> I'm facing similar issues with the tc358775 bridge. This bridge needs
>> to release its reset while both clock and data lanes are in LP-11
>> mode.
>> But then it needs to be configured (via I2C) while the clock lane is
>> in enabled (HS mode), but the data lanes are still in LP-11 mode.
>>
>> To me it looks like there is a fouth case then:
>> 1. unpowered
>> 2. DSI clock and data are in LP-11
>> 3. DSI clock is in HS and data are in LP-11
>> 4. DSI clock is in HS and data is in HS
>>
>> (And of course the bridge needs continuous clock mode).
>>
>> > Different DSI bridges have different requirements with respect to the
>> > code being executed at stages 1 and 2. For example several DSI-to-eDP
>> > bridges (ps8640, tc358767 require for the link to be quiet during
>> > reset time.
>> > The DSI-controlled bridges and DSI panels need to send some commands
>> > in stage 2, before starting up video
>> >
>> > In the DRM subsystem stage 3 naturally maps to the
>> > drm_bridge_funcs::enable, stage 1 also naturally maps to the
>> > drm_bridge_funcs::pre_enable. Stage 2 doesn't have its own place in
>> > the DRM call chain.
>> > Earlier we attempted to solve that using the pre_enable_prev_first,
>> > which remapped pre-enable callback execution order. However it has led
>> > us to the two issues. First, at the DSI host driver we do not know
>> > whether the panel / bridge were updated to use pre_enable_prev_first
>> > or not. Second, if the bridge has to perform steps during both stages
>> > 1 and 2, it can not do that.
>> >
>> > I'm trying to find a way to express the difference between stages 1
>> > and 2 in the generic code, so that we do not to worry about particular
>> > DSI host and DSI bridge / panel peculiarities when implementing the
>> > DSI host and/or DSI panel driver.
>>
>> For now, I have a rather hacky ".dsi_lp11_notify" callback in
>> drm_bridge_funcs which is supposed to be called by the DSI host while
>> the
>> clock and data lanes are in LP-11 mode. But that is rather an RFC and
>> me
>> needing something to get the driver for this bridge working. Because
>> it's
>> badly broken. FWIW, you can find my work-in-progress patches at
>> https://github.com/mwalle/linux/tree/feature-tc358775-fixes
>>
>> -michael
>>
>
>
> --
> With best wishes
> Dmitry
next prev parent reply other threads:[~2023-11-28 16:56 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-16 16:53 [RFC PATCH 00/10] drm/mipi-dsi: another attempt at sorting out DSI link powerup Dmitry Baryshkov
2023-10-16 16:53 ` [RFC PATCH 01/10] Revert "drm/bridge: tc358762: Split register programming from pre-enable to enable" Dmitry Baryshkov
2023-10-16 16:53 ` [RFC PATCH 02/10] drm/mipi-dsi: document DSI hosts limitations Dmitry Baryshkov
2023-10-16 16:53 ` [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state Dmitry Baryshkov
2023-10-19 9:26 ` Maxime Ripard
2023-10-19 11:19 ` Dmitry Baryshkov
2023-10-19 11:42 ` Alexander Stein
2023-10-22 10:49 ` Dmitry Baryshkov
2023-10-23 6:52 ` Alexander Stein
2023-10-23 7:34 ` Dmitry Baryshkov
2023-10-23 8:14 ` Alexander Stein
2023-10-23 8:40 ` Dmitry Baryshkov
2023-10-25 12:44 ` Maxime Ripard
2023-10-25 15:16 ` Dmitry Baryshkov
2023-10-26 8:04 ` Maxime Ripard
2023-10-26 8:41 ` Dmitry Baryshkov
2023-11-07 10:57 ` Maxime Ripard
2023-11-07 11:22 ` Greg Kroah-Hartman
2023-11-07 12:18 ` Maxime Ripard
2023-11-07 15:26 ` Greg Kroah-Hartman
2023-11-08 15:34 ` Maxime Ripard
2023-11-08 15:58 ` Laurent Pinchart
2023-11-29 8:57 ` Neil Armstrong
2023-11-27 16:06 ` Michael Walle
2023-11-28 16:49 ` Dmitry Baryshkov
2023-11-28 16:55 ` Michael Walle [this message]
2023-11-28 17:12 ` Dmitry Baryshkov
2023-11-28 19:50 ` Michael Walle
2023-11-28 20:23 ` Dmitry Baryshkov
2023-11-28 22:17 ` Michael Walle
2023-11-28 22:20 ` Michael Walle
2023-11-28 22:21 ` Dmitry Baryshkov
2023-11-28 22:44 ` Michael Walle
2023-10-23 7:35 ` Neil Armstrong
2023-10-23 7:40 ` Dmitry Baryshkov
2023-10-16 16:53 ` [RFC PATCH 04/10] drm/msm/dsi: use dsi_mgr_bridge_power_off in dsi_mgr_bridge_post_disable Dmitry Baryshkov
2023-10-16 16:53 ` [RFC PATCH 05/10] drm/msm/dsi: implement manual power control Dmitry Baryshkov
2023-10-16 16:53 ` [RFC PATCH 06/10] drm/bridge: tc358762: add support for manual DSI " Dmitry Baryshkov
2023-10-16 16:53 ` [RFC PATCH 07/10] drm/bridge: ps8640: require " Dmitry Baryshkov
2023-10-16 16:53 ` [RFC PATCH 08/10] drm/bridge: lt9611: mark for automatic " Dmitry Baryshkov
2023-10-16 16:53 ` [RFC PATCH 09/10] drm/bridge: lt9611uxc: implement " Dmitry Baryshkov
2023-10-16 16:53 ` [RFC PATCH 10/10] drm/msm/dsi: drop (again) the ps8640 workaround Dmitry Baryshkov
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=dce76a6e1321a6374ad39125bead56b3@kernel.org \
--to=mwalle@kernel.org \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=alexander.stein@ew.tq-group.com \
--cc=andrzej.hajda@intel.com \
--cc=dave.stevenson@raspberrypi.com \
--cc=dianders@chromium.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=konrad.dybcio@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marex@denx.de \
--cc=marijn.suijten@somainline.org \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=quic_abhinavk@quicinc.com \
--cc=quic_jesszhan@quicinc.com \
--cc=rfoss@kernel.org \
--cc=sean@poorly.run \
--cc=tony@atomide.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: 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).