[PATCH v2.5] drm/msm/dsi: switch to DRM_PANEL_BRIDGE

[Thorsten Leemhuis]

Hi, this is your Linux kernel regression tracker.

On 13.11.22 14:28, Dmitry Baryshkov wrote:
> Hi Caleb,
> 
> On Fri, 11 Nov 2022 at 18:30, Caleb Connolly <caleb.connolly at linaro.org> wrote:
>>
>> Hi,
>>
>> This patch has caused a regression on 6.1-rc for some devices that use
>> DSI panels. The new behaviour results in the DSI controller being
>> switched off before the panel unprepare hook is called. As a result,
>> panel drivers which call mipi_dsi_dcs_write() or similar in
>> unprepare() fail.
> 
> Thanks for the notice. Can you move your command stream to
> panel_disable() hook? (even if it's just as a temporary workaround)

Caleb, did you look into what Dmitry suggested? This issue is on my list
of tracked regressions in 6.1 and time is running out to get it fixed
before the release.

Or was there any progress to get this fixed and I just missed it?

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.

#regzbot ignore-activity

> From what I see from other panels, some of them call
> mipi_dsi_dcs_set_display_off() in the unprepare() hook, while others
> do it in disable().
> 
> Yes, this is (again) the DSI host vs device order here. Short story:
> the DRM has a notion of 'the display pipe (i.e. clocks and timing
> signals) feeding the bridge being running'. That's the difference
> between enable/pre_enable and disable/post_disable. For the DSI we
> have a third state, when the DSI clock and ln0 allow transferring
> commands to the panel, but the image is not enabled.
> 
> There was a somewhat promising patchset at [1], but it seems it went
> out of the radar. I can try working on an alternative (explicit)
> approach if I have time.
> 
> With respect to your panel. Let me quote the docs: 'Before stopping
> video transmission from the display controller it can be necessary to
> turn off the panel to avoid visual glitches. This is done in the
> .disable() function. Analogously to .enable() this typically involves
> turning off the backlight and waiting for some time to make sure no
> image is visible on the panel. It is then safe for the display
> controller to cease transmission of video data.'
> 
> So, if we stop the call chain after switching the DSI host off but
> before calling the panel's unprepare() hook, will we see any
> artifacts/image leftover/etc. on the panel? Generally I have the
> feeling that all panels should call mipi_dsi_dcs_set_display_off() in
> the .disable() hook, not in the .unprepare() one.
> 
> [1] https://lore.kernel.org/dri-devel/cover.1646406653.git.dave.stevenson@raspberrypi.com/
> 
>>
>> I've noticed it specifically on the OnePlus 6 (with upstream Samsung
>> s0fef00 panel driver) and the SHIFT6mq with an out of tree driver.
>>
>> On 12/07/2022 14:22, Dmitry Baryshkov wrote:
>>> Currently the DSI driver has two separate paths: one if the next device
>>> in a chain is a bridge and another one if the panel is connected
>>> directly to the DSI host. Simplify the code path by using panel-bridge
>>> driver (already selected in Kconfig) and dropping support for
>>> handling the panel directly.
>>>
>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
>>> ---
>>>
>>> I'm not sending this as a separate patchset (I'd like to sort out mdp5
>>> first), but more of a preview of changes related to
>>> msm_dsi_manager_ext_bridge_init().
>>>
>>> ---
>>>   drivers/gpu/drm/msm/dsi/dsi.c         |  35 +---
>>>   drivers/gpu/drm/msm/dsi/dsi.h         |  16 +-
>>>   drivers/gpu/drm/msm/dsi/dsi_host.c    |  25 ---
>>>   drivers/gpu/drm/msm/dsi/dsi_manager.c | 283 +++-----------------------
>>>   4 files changed, 36 insertions(+), 323 deletions(-)
> 
> [skipped the patch itself]
>