On Thu, Feb 20, 2025 at 02:26:22PM +0200, Svyatoslav Ryhel wrote: > т, 20 лют. 2025 р. о 13:35 Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> пише: > > > > On Thu, Feb 20, 2025 at 09:37:18AM +0200, Svyatoslav Ryhel wrote: > > > ср, 19 лют. 2025 р. о 15:34 Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> пише: > > > > > > > > On Tue, Feb 18, 2025 at 04:36:17PM +0200, Svyatoslav Ryhel wrote: > > > > > вт, 18 лют. 2025 р. о 16:20 Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> пише: > > > > > > > > > > > > On Tue, Feb 18, 2025 at 02:45:19PM +0200, Svyatoslav Ryhel wrote: > > > > > > > вт, 18 лют. 2025 р. о 14:31 Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> пише: > > > > > > > > > > > > > > > > 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@xxxxxxxxx> > > > > > > > > > --- > > > > > > > > > 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. > > [ 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
