Message-ID: <CAPVz0n3GqWhMvos_dacsgEyiv3dV5_VnYR7YuNGe2XTLWe30jQ@mail.gmail.com>
Date: Thu, 20 Feb 2025 20:47:41 +0200
From: Svyatoslav Ryhel <clamor95@...il.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Andrzej Hajda <andrzej.hajda@...el.com>, Neil Armstrong <neil.armstrong@...aro.org>, 
	Robert Foss <rfoss@...nel.org>, Laurent Pinchart <Laurent.pinchart@...asonboard.com>, 
	Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] drm: bridge: Add support for Solomon SSD2825
 RGB/DSI bridge

чт, 20 лют. 2025 р. о 17:07 Dmitry Baryshkov <dmitry.baryshkov@...aro.org> пише:
>
> On Thu, Feb 20, 2025 at 02:26:22PM +0200, Svyatoslav Ryhel wrote:
> > т, 20 лют. 2025 р. о 13:35 Dmitry Baryshkov <dmitry.baryshkov@...aro.org> пише:
> > >
> > > On Thu, Feb 20, 2025 at 09:37:18AM +0200, Svyatoslav Ryhel wrote:
> > > > ср, 19 лют. 2025 р. о 15:34 Dmitry Baryshkov <dmitry.baryshkov@...aro.org> пише:
> > > > >
> > > > > On Tue, Feb 18, 2025 at 04:36:17PM +0200, Svyatoslav Ryhel wrote:
> > > > > > вт, 18 лют. 2025 р. о 16:20 Dmitry Baryshkov <dmitry.baryshkov@...aro.org> пише:
> > > > > > >
> > > > > > > On Tue, Feb 18, 2025 at 02:45:19PM +0200, Svyatoslav Ryhel wrote:
> > > > > > > > вт, 18 лют. 2025 р. о 14:31 Dmitry Baryshkov <dmitry.baryshkov@...aro.org> пише:
> > > > > > > > >
> > > > > > > > > On Mon, Feb 17, 2025 at 04:09:10PM +0200, Svyatoslav Ryhel wrote:
> > > > > > > > > > SSD2825 is a cost-effective MIPI Bridge Chip solution targeting mainly
> > > > > > > > > > smartphones. It can convert 24bit RGB interface into 4-lane MIPI-DSI
> > > > > > > > > > interface to drive display modules of up to 800 x 1366, while supporting
> > > > > > > > > > AMOLED, a-si LCD or LTPS panel technologies for smartphone applications.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@...il.com>
> > > > > > > > > > ---
> > > > > > > > > >  drivers/gpu/drm/bridge/Kconfig   |  14 +
> > > > > > > > > >  drivers/gpu/drm/bridge/Makefile  |   1 +
> > > > > > > > > >  drivers/gpu/drm/bridge/ssd2825.c | 824 +++++++++++++++++++++++++++++++
> > > > > > > > > >  3 files changed, 839 insertions(+)
> > > > > > > > > >  create mode 100644 drivers/gpu/drm/bridge/ssd2825.c
> > > > > > > > > >
> > ...
> > > > > > > > >
> > > > > > > > > From v1:
> > > > > > > > >
> > > > > > > > > Most of these flags should be set depending on the
> > > > > > > > > mipi_dsi_device.mode_flags.
> > > > > > > > >
> > > > > > > > > > +             ssd2825_write_reg(priv, SSD2825_PLL_CTRL_REG, 0x0001);
> > > > > > > > > > +             ssd2825_write_reg(priv, SSD2825_VC_CTRL_REG, 0x0000);
> > > > > > > > >
> > > > > > > > > Why? Why do you need this special handling for the
> > > > > > > > > MIPI_DCS_SET_DISPLAY_ON? Why can't it just go to .atomic_enable()?
> > > > > > > > >
> > > > > > > >
> > > > > > > > This has to be called after panel init dsi sequence completes, is
> > > > > > > > atomic_enable called after panel init dsi seq is completed? Maybe you
> > > > > > > > can suggest where to place it.
> > > > > > >
> > > > > > > That depends on a panel. Significant number of panel drivers call all
> > > > > > > DSI programming in .prepare because some DSI hosts can not transfer
> > > > > > > commands after starting DSI video stream.
> > > > > > >
> > > > > > > So these commands should go to your .enable().
> > > > > > >
> > > > > >
> > > > > > This is weird and counter intuitive to send dsi commands in prepare,
> > > > > > there should be smth like enable_post. Oh well, fine, I will try to
> > > > > > fit this somehow.
> > > > > >
> > > >
> > > > Who had made this cursed framework?
> > > >
> > > > Functions are called in the next seq
> > > >
> > > > panel_prepare > bridge_pre_enable > bridge_enable > panel_enable
> > >
> > > Use drm_bridge.pre_enable_prev_first or drm_panel.prepare_prev_first. I
> > > think that fixes your order issues.
> > >
> >
> > This seems to have no effect. I have set panel.prepare_prev_first =
> > true in the panel probe, which should result in
> > bridge_atomic_pre_enable be called before panel prepare,
> > and yet I still have this:
>
> I've cc'ed you on the patch that should fix this behaviour.
>

And this did not resolve my issue. I managed to configure panel to
work, but it makes panel degrade.

With the flag above seq is better bridge_prep > panel_prep > bridge_en
> panel_en but this is still not enough.

It seems that my panel hw must be enabled before bridge_pre_enable,
preferable just before it is called, if I contain all in panel_prepare
I get no image with light halo in the middle. If I set hw
configuration in panel probe as a last step, it will be active and
panel degrades so I end up with flickering once image appears.

This partially is related to a 6.13 regression which causes bridge to
be pre/enabled extremely late, approx 75 sec from start and it skips
entire bootanimation.

> >
> > [   45.280653] renesas_r61307_prepare start
> > [   45.300873] renesas_r61307_prepare end
> > [   45.301070] ssd2825_bridge_atomic_pre_enable start
> > [   45.317248] ssd2825_bridge_atomic_pre_enable end
> > [   45.317287] ssd2825_bridge_atomic_enable start
> > [   45.331650] ssd2825_bridge_atomic_enable end
> > [   45.331677] renesas_r61307_enable start
> > [   45.520959] renesas_r61307_enable end
> >
> > With or without the flag it is same
> >
> > > > There is no gap in between bridge_pre_enable and bridge enable, hence
> > > > I cannot call dsi commands in panel_prepare since bridge is not even
> > > > pre_enabled, and if I call then in panel_enable, I cannot complete
> > > > bridge configuration since bridge enable is called before. like WTF!
> > > >
> > > > I enclose log with function call seq
> > > >
> > > > DSI commands in panel prepare
> > > > [   75.149700] ssd2825_dsi_host_transfer start  << this is panel prepare
> > > > [   75.149737] ssd2825 spi0.2: Bridge is not enabled
> > > > [   75.149750] panel-renesas-r61307 spi0.2.1: Failed to exit sleep mode: -19
> > > > [   75.149779] ssd2825_bridge_atomic_pre_enable start
> > > > [   75.178518] ssd2825_bridge_atomic_pre_enable end
> > > > [   75.178552] ssd2825_bridge_atomic_enable start
> > > > [   75.179026] ssd2825_bridge_atomic_enable end
> > > >
> > > > DSI commands in panel enable
> > > >
> > > > [  102.821580] ssd2825_bridge_atomic_pre_enable start
> > > > [  102.852000] ssd2825_bridge_atomic_pre_enable end
> > > > [  102.852057] ssd2825_bridge_atomic_enable start
> > > > [  102.852840] ssd2825_bridge_atomic_enable end
> > > > [  102.852866] ssd2825_dsi_host_transfer start  << panel enable
> > > > [  102.853876] ssd2825_dsi_host_transfer end
> > > > [  102.948420] ssd2825_dsi_host_transfer start
> > > > [  102.949289] ssd2825_dsi_host_transfer end
> > > > [  102.978389] ssd2825_dsi_host_transfer start
> > > > [  102.979567] ssd2825_dsi_host_transfer end
> > > > [  102.980117] ssd2825_dsi_host_transfer start
> > > > [  102.981248] ssd2825_dsi_host_transfer end
> > > > [  102.981809] ssd2825_dsi_host_transfer start
> > > > [  102.982851] ssd2825_dsi_host_transfer end
> > > > [  102.983537] ssd2825_dsi_host_transfer start
> > > > [  102.984556] ssd2825_dsi_host_transfer end
> > > > [  102.986743] ssd2825_dsi_host_transfer start
> > > > [  102.988078] ssd2825_dsi_host_transfer end
> > > > [  102.989445] ssd2825_dsi_host_transfer start
> > > > [  102.990411] ssd2825_dsi_host_transfer end
> > > > [  102.990912] ssd2825_dsi_host_transfer start
> > > > [  102.992274] ssd2825_dsi_host_transfer end
> > > >
> > > > In both cases there is no gap in between bridge pre_enable and enable
> > > >
> > > > > > > But what is the case for these calls? Are you manually implementing the
> > > > > > > MIPI_DSI_MODE_LPM flag? What exactly do they do? What happens if the
> > > > > > > panel driver asks for the MIPI_DCS_SET_DISPLAY_ON command after you've
> > > > > > > programmed those registers? What happens if the panel asks for the
> > > > > > > backlight control?
> > > > > > >
> > > > > >
> > > > > > Backlight is externally controlled, at least on my device, so I cannot
> > > > > > test other cases. If I configure those registers before dsi sequence
> > > > > > is completed panel stays black. If I simply remove those
> > > > > > configuration, panel stays black.
> > > > > >
>
> --
> With best wishes
> Dmitry

Powered by blists - more mailing lists