Re: [PATCH V2 0/3] DSI host and peripheral initialisation ordering

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 17/11/2022 17:34, Maxime Ripard wrote:
On Thu, Nov 17, 2022 at 03:24:07PM +0200, Dmitry Baryshkov wrote:
On 15/11/2022 17:38, Dave Stevenson wrote:
Hi Dmitry

On Tue, 15 Nov 2022 at 14:21, Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxx> wrote:

On 15/11/2022 17:14, Dave Stevenson wrote:
Hi Dmitry

On Sun, 13 Nov 2022 at 13:06, Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxx> wrote:

Hi Dave,

On 19/07/2022 16:45, Dave Stevenson wrote:
Hi Sam

On Mon, 18 Jul 2022 at 21:52, Sam Ravnborg <sam@xxxxxxxxxxxx> wrote:

Hi Dave,

a long overdue reply on this series.

On Fri, Mar 04, 2022 at 03:17:55PM +0000, Dave Stevenson wrote:
Hi All

Changes from v1:
- New patch to refactor drm_bridge_chain_post_disable and drm_bridge_chain_pre_enable
      to reuse drm_atomic_bridge_chain_post_disable / drm_atomic_bridge_chain_pre_enable
      but with a NULL state.
- New patch that adds a pre_enable_upstream_first to drm_panel.
- changed from an OPS flag to a bool "pre_enable_upstream_first" in drm_bridge.
- Followed Andrzej's suggestion of using continue in the main loop to avoid
      needing 2 additional loops (one forward to find the last bridge wanting
      upstream first, and the second backwards again).
- Actioned Laurent's review comments on docs patch.

Original cover letter:

Hopefully I've cc'ed all those that have bashed this problem around previously,
or are otherwise linked to DRM bridges.

There have been numerous discussions around how DSI support is currently broken
as it doesn't support initialising the PHY to LP-11 and potentially the clock
lane to HS prior to configuring the DSI peripheral. There is no op where the
interface is initialised but HS video isn't also being sent.
Currently you have:
- peripheral pre_enable (host not initialised yet)
- host pre_enable
- encoder enable
- host enable
- peripheral enable (video already running)

vc4 and exynos currently implement the DSI host as an encoder, and split the
bridge_chain. This fails if you want to switch to being a bridge and/or use
atomic calls as the state of all the elements split off are not added by
drm_atomic_add_encoder_bridges.

A typically chain looks like this:

CRTC => Encoder => Bridge A => Bridge B

We have in DRM bridges established what is the "next" bridge - indicated
with the direction of the arrows in the drawing.

This set of patches introduces the concept of "upstream" bridges.

pre_enable_prev_bridge_first would be easier to understand as it uses
the current terminology.
I get that "upstream" is used in the DSI specification - but we are
dealing with bridges that happens to support DSI and more, and mixing
the two terminologies is not good.

Note: Upstream is also used in a bridge doc section - here it should
          most likely be updated too.

Sure, I have no issues with switching to prev/next from upstream/downstream.
To the outsider it can be confusing - in pre_enable and disable, the
next bridge to be called is the previous one. At least it is
documented.

The current approach set a flag that magically makes the core do something
else. Have you considered a much more explicit approach?

A few helpers like:

            drm_bridge_pre_enable_prev_bridge()
            drm_bridge_enable_prev_bridge()
            drm_bridge_disable_prev_bridge()
            drm_bridge_post_disable_prev_bridge()

No point in drm_bridge_enable_prev_bridge() and
drm_bridge_post_disable_prev_bridge() as the call order down the chain
will mean that they have already been called.
drm_bridge_enable_next_bridge() and
drm_bridge_post_disable_next_bridge() possibly.

And then update the core so the relevant function is only called once
for a bridge.
Then the need for DSI lanes in LP-11 can be archived by a call to

            drm_bridge_pre_enable_prev_bridge()

Unfortunately it gets ugly with post_disable.
The DSI host controller post_disable will have been called before the
DSI peripheral's post_disable, and there are conditions where the
peripheral needs to send DSI commands in post_disable (eg
panel-asus-z00t-tm5p5-n35596 [1]). Changing all DSI hosts to call
drm_bridge_post_disable_next_bridge feels like the wrong thing to do.
There are currently hacks in dw-mipi-dsi that do call the next
panel/bridge post_disable [2] and it would be nice to get rid of them.
Currently the calls aren't tracked for state, so you end up with
post_disable being called twice, and panels having to track state (eg
jdi_lt070me050000 [3]).

[1] tm5p5_nt35596_unprepare() calls tm5p5_nt35596_off()
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c#L107
[2] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L889
[3] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c#L44

This is more explicit than a flag that triggers some magic behaviour.
It may even see uses we have not realised yet.

Personally it feels like more boilerplate in almost all DSI drivers,
and generally I see a push to remove boilerplate.

It is late here - so maybe the above is not a good idea tomorrow - but
right now I like the simplicity of it.

Other than the above I read that a mipi_dsi_host_init() is planned,
which is also explicit and simple - good.

It's been raised, but the justification for most use cases hasn't been
made. The Exynos conversion looks to be doing the wrong thing in
checking state, and that's why it is currently needing it.
Again it's also more boilerplate.

TC358767 is an odd one as it wants the DSI interface enabled very
early in order to have a clock for the DP aux channel well before
video is running. I had a thought on that, but It looks like I haven't
hit send on a reply to Lucas on that one - too many distractions.

Have we seen a new revision of some of these?
Chances are high that I have missed it then.

No, still on V2. Other than Dmitry's comment over updating
parade-ps8640 and dropping drm_bridge_chain_*, no real comments had
been made.

It's been a while now. Do you still plan to pursue this patchset?

If there was anything that could actually be worked on, then I'm happy
to respin it, but if the approach is generally being rejected then I
don't want to waste the effort.

I'm not totally clear who the maintainers are that the final arbiters
and need to sign off on this.
drm_bridge.c falls to Maarten, Maxime, and Thomas for "DRM DRIVERS AND
MISC GPU PATCHES"
drm_panel.c falls to Thierry and Sam for "DRM PANEL DRIVERS", and then
Maarten, Maxime, and Thomas.
Only Sam has responded publicly. I have had discussions with Maxime,
but it's not directly his area of knowledge.

Looking at the patch series:
Patch 1: Your comment "update parade-ps8640 to use
drm_atomic_bridge_chain_". It looks like patchset [1] by Sam does
this, but the patchset went wrong and is missing patches 8-11 and
therefore hasn't been merged.
Patch 2: Comment from Jagan that it's like an old patch. It has
similarities, but isn't the same.
Patch 3: R-b by you (thank you), but concerns from Jagan which I still
don't understand. Without clarification on the issue and whether my
suggested alternative place for the hook solves the issue, IMHO it's
not worth respinning.
Patch 4: R-b Laurent.

This cover note got totally subverted with Exynos issues.
Sam did request use of prev / next instead of upstream / downstream,
which can be done and perhaps warrants a respin now.

[personal notice: I'd prefer something less strange, e.g. an explicit
calls to mipi_dsi_host, but as this patchset seems to fix the issues,
I'm fine with it].

That can fix the power up sequence, but how do you propose telling the
DSI controller NOT to power down in post_disable before the DSI
peripheral post_disable has potentially sent DCS commands - i.e. the
case you were discussing on Friday in [2].

I thought that the same 'call the parent beforehand' switch applied to
the deinit paths, didn't it?

My proposed flag does indeed swap the order of post_disable as well.

Perhaps I was misunderstanding your personal preference.
I was taking it as an explicit mipi_dsi_host call to initialise the
DSI link, which then also needs an explicit mipi_dsi_host call to tear
it down as well. In that situation there is a need to rework the
bridge chain post_disable to allow for the panel post_disable to send
DCS commands before the DSI host is disabled.

If a panel/bridge driver doesn't call mipi_dsi_host_init then the
expectation must be that it will be called by the DSI controller's
pre_enable, and deinit from post_disable. Likewise init & deinit would
be called if host_transfer is used when the host isn't initialised.

If the panel/bridge driver explicitly calls mipi_dsi_host_init, then
does that mandate that it must also call mipi_dsi_host_deinint. The
controller post_disable is then effectively a no-op. This can be
covered in documentation, but also leaves the potential for strange
behaviour if the requirement is not followed, and I can't think of a
nice place to drop a WARN to flag the issue in the driver.


TBH The lack of interest in solving the issues almost makes me want to
just document the total brokenness of it and throw in the towel.
Seeing as we as Raspberry Pi run a vendor kernel, we can run with
downstream patches until those who care finally make a decision for
mainline. I'd prefer to solve it properly, but it requires some
engagement from the community.

I see. I can probably try spinning a patchset doing explicit mipi_dsi
calls. Let's see if it gains more attention.

Is it better to have 2 competing patchsets floating around, or try and
get responses on one first? I'll try and get an updated set out today.

I'm a bit in a tough position here. I can't say that I like this approach,
but it seems to fix all the issues that we have with DSI hosts, so it's
better than the current state.

I'd say the bridge support in general is under-maintained. Historically,
Boris and Laurent did most of the architecture work, but are either
completely drowning under patches or have moved on.

I can't really speak for Thomas and Maarten, but I don't really have
such a good knowledge about the bridge infrastructure and haven't been
very involved. I have the same impression from Maarten and Thomas
though.

Which means that it's pretty much a blindspot for us :)

I'm sorry if it's taking a while, but I'd say that if you two have a
good comprehension of the issue (and I know Dave has), if you can reach
a reasonable solution for both of you, and if there is proper
documentation for the new work, I'd consider this a net improvement.

And as far as I know from that discussion, we're pretty much there
already. So yeah, go ahead with a new version and we'll merge it.

Ack, then I'll hold on my proposal to let Dave's version to be merged.

--
With best wishes
Dmitry




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux