From: Maxime Ripard <maxime@cerno.tech>
To: Dave Stevenson <dave.stevenson@raspberrypi.com>
Cc: Jagan Teki <jagan@amarulasolutions.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
Andrzej Hajda <andrzej.hajda@intel.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Robert Foss <rfoss@kernel.org>, Chen-Yu Tsai <wens@csie.org>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Samuel Holland <samuel@sholland.org>,
Sam Ravnborg <sam@ravnborg.org>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev, devicetree@vger.kernel.org,
dri-devel@lists.freedesktop.org, Marek Vasut <marex@denx.de>,
linux-amarula <linux-amarula@amarulasolutions.com>
Subject: Re: [PATCH v7 10/12] drm/bridge: Implement enable_next_first to alter bridge init order
Date: Wed, 29 Mar 2023 18:46:38 +0200 [thread overview]
Message-ID: <20230329164638.v43la4l7rxut6hk6@penduick> (raw)
In-Reply-To: <CAPY8ntCJP53uiGNQHUZqma08Vsxfwm7KvAkgMzK=hn4AxJLS3A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2722 bytes --]
On Wed, Mar 29, 2023 at 05:28:28PM +0100, Dave Stevenson wrote:
> On Wed, 29 Mar 2023 at 14:19, Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> > DSI sink devices typically send the MIPI-DCS commands to the DSI host
> > via general MIPI_DSI_DCS read and write API.
> >
> > The classical DSI sequence mentioned that the DSI host receives MIPI-DCS
> > commands from the DSI sink first in order to switch HS mode properly.
> > Once the DSI host switches to HS mode any MIPI-DCS commands from the
> > DSI sink are unfunctional.
>
> That statement contradicts the spec.
> The DSI spec section 8.11.1 Transmission Packet Sequences says that
> during any BLLP (Blanking or Low Power) period the host can do any of:
> - remain in LP-11
> - transmit one or more non-video packets from host to peripheral in escape mode
> - transmit one or more non-video packets from host to peripheral in
> using HS mode
> - receive one or more packets from peripheral to host using escape mode
> - transmit data on a different virtual channel.
>
> Indeed if the sink doesn't set MIPI_DSI_MODE_LPM /
> MIPI_DSI_MSG_USE_LPM, then the expectation is that any data transfer
> will be in HS mode.
>
> That makes me confused as to the need for this patch.
Yeah, and it looks like that would break the expectation that, in
enable, a bridge can expect its controller to be in HS mode.
I think that was Jagan is trying to do is to work around an issue with
the Allwinner DSI driver:
https://elixir.bootlin.com/linux/v6.3-rc4/source/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#L775
This is working mostly fine since we only have panel support and can
control that, but with bridge support added in the latest patch, then it
probably doesn't work anymore.
The proper way to fix this isn't to put more logic into the framework,
it's to make the DSI driver behave as expected by KMS.
Unfortunately, that controller is not documented, so it's not clear to
me how we can fix it.
IIRC, it's basically a state machine where you would encode the
transitions between one DSI state and the next depending on what your
expectations are.
I think there's two problem with the driver that need to be addressed:
- First the driver will drop back to LP11 mode to submit commands. I
don't think it's needed and could even be hurtful to the video
stream if it was to happen during HS mode:
https://elixir.bootlin.com/linux/v6.3-rc4/source/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#L877
- And then, it looks like, in HSD mode, we never get to go to the
state LPTX is in (LPDT). It would be interesting to test whether
adding a transition to that state makes it work or not.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2023-03-29 16:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-29 13:19 [PATCH v7 10/12] drm/bridge: Implement enable_next_first to alter bridge init order Jagan Teki
2023-03-29 13:19 ` [PATCH v7 11/12] drm/bridge: Document bridge init order with enable_next_first Jagan Teki
2023-03-29 13:19 ` [PATCH v7 12/12] drm: sun4: dsi: Convert to bridge driver Jagan Teki
2023-03-29 14:59 ` Maxime Ripard
2023-03-29 15:38 ` Jagan Teki
2023-03-29 16:06 ` Maxime Ripard
2023-03-30 6:45 ` Jagan Teki
2023-03-30 8:47 ` Maxime Ripard
2023-03-29 16:28 ` [PATCH v7 10/12] drm/bridge: Implement enable_next_first to alter bridge init order Dave Stevenson
2023-03-29 16:46 ` Maxime Ripard [this message]
2023-03-29 17:21 ` Dave Stevenson
2023-03-30 6:55 ` Jagan Teki
2023-03-30 10:01 ` Dave Stevenson
2023-03-31 9:12 ` Neil Armstrong
2023-04-04 18:00 ` Jagan Teki
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=20230329164638.v43la4l7rxut6hk6@penduick \
--to=maxime@cerno.tech \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=daniel@ffwll.ch \
--cc=dave.stevenson@raspberrypi.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jagan@amarulasolutions.com \
--cc=jernej.skrabec@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-amarula@amarulasolutions.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marex@denx.de \
--cc=neil.armstrong@linaro.org \
--cc=rfoss@kernel.org \
--cc=robh+dt@kernel.org \
--cc=sam@ravnborg.org \
--cc=samuel@sholland.org \
--cc=tzimmermann@suse.de \
--cc=wens@csie.org \
/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).