public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Esben Haabendal <esben@geanix.com>
To: Alexander Stein <alexander.stein@ew.tq-group.com>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>,
	 Neil Armstrong <neil.armstrong@linaro.org>,
	 Robert Foss <rfoss@kernel.org>,
	 Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	 Jonas Karlman <jonas@kwiboo.se>,
	 Jernej Skrabec <jernej.skrabec@gmail.com>,
	 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	 Maxime Ripard <mripard@kernel.org>,
	 Thomas Zimmermann <tzimmermann@suse.de>,
	 David Airlie <airlied@gmail.com>,
	 Daniel Vetter <daniel@ffwll.ch>,
	dri-devel@lists.freedesktop.org,  linux-kernel@vger.kernel.org
Subject: Re: drm/bridge: nwl-dsi: Use vsync/hsync polarity from display mode
Date: Wed, 22 Jan 2025 08:15:50 +0100	[thread overview]
Message-ID: <878qr3uxnd.fsf@geanix.com> (raw)
In-Reply-To: <4658759.LvFx2qVVIh@steina-w> (Alexander Stein's message of "Mon, 20 Jan 2025 13:42:30 +0100")

Alexander Stein <alexander.stein@ew.tq-group.com> writes:

> Hi,
>
> I'm sorry I'm late to the party.
>
> Am Mittwoch, 14. August 2024, 12:37:26 CET schrieb Esben Haabendal:
>> Using the correct bit helps. The documentation specifies bit 0 in both
>> registers to be controlling polarity of dpi_vsync_input and
>> dpi_hsync_input polarity. Bit 1 is reserved, and should therefore not be
>> set.
>> 
>> Tested with panel that requires active high vsync and hsync.
>> 
>> Signed-off-by: Esben Haabendal <esben@geanix.com>
>> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
>
> I just noticed this commit causes a regression on my platform TQMa8Mx/MBa8Mx.
> DT overlay: arch/arm64/boot/dts/freescale/imx8mq-tqma8mq-mba8mx-lvds-tm070jvhg33.dtso
> My bridges are configured as follow:
>> $ cat /sys/kernel/debug/dri/30320000.lcd-controller/encoder-0/bridges
>> bridge[0]: nwl_dsi_bridge_funcs [nwl_dsi]
>> 
>>         type: [0] Unknown
>>         OF: /soc@0/bus@30800000/dsi@30a00000:fsl,imx8mq-nwl-dsi
>>         ops: [0x0]
>> 
>> bridge[1]: sn65dsi83_funcs [ti_sn65dsi83]
>> 
>>         type: [0] Unknown
>>         OF: /soc@0/bus@30800000/i2c@30a40000/bridge@2d:ti,sn65dsi84
>>         ops: [0x0]
>> 
>> bridge[2]: panel_bridge_bridge_funcs
>> 
>>         type: [7] LVDS
>>         OF: /panel-lvds:tianma,tm070jvhg33
>>         ops: [0x8] modes
>
> The display needs active-low sync signals, otherwise the image is shifted
> by the amount of sync pulse.
> The patch itself looks good. But there is also nwl_dsi_bridge_atomic_check()
> unconditionally enabling DRM_MODE_FLAG_PHSYNC and DRM_MODE_FLAG_PVSYNC.

Yes, the code you mention does look quite suspicious to me.

        /* At least LCDIF + NWL needs active high sync */
        adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
        adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC)

Why would we want to unconditionally enable active high sync signals in
.atomic_check()? It is perfectly valid to have active-low sync signals,
which your case perfectly proves.

Could we simply drop this, and thus require that the sync signals are
properly configured?

> Reverting the patch immediately restores the display image correctly.

And breaks it in other cases :(

We need a way to be able to select the sync signal polarity.

/Esben

>
> Best regards,
> Alexander
>> ---
>>  drivers/gpu/drm/bridge/nwl-dsi.c | 8 ++++----
>>  drivers/gpu/drm/bridge/nwl-dsi.h | 4 ++--
>>  2 files changed, 6 insertions(+), 6 deletions(-)
>> 
>> 
>> ---
>> base-commit: 7c626ce4bae1ac14f60076d00eafe71af30450ba
>> change-id: 20240814-nwl-dsi-sync-polarity-ddc58435a4c4
>> 
>> Best regards,
>> 
>> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
>> index 8d54091ec66e..5f05647a3bea 100644
>> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
>> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
>> @@ -289,13 +289,13 @@ static int nwl_dsi_config_dpi(struct nwl_dsi *dsi)
>>  
>>  	nwl_dsi_write(dsi, NWL_DSI_INTERFACE_COLOR_CODING, NWL_DSI_DPI_24_BIT);
>>  	nwl_dsi_write(dsi, NWL_DSI_PIXEL_FORMAT, color_format);
>> -	/*
>> -	 * Adjusting input polarity based on the video mode results in
>> -	 * a black screen so always pick active low:
>> -	 */
>>  	nwl_dsi_write(dsi, NWL_DSI_VSYNC_POLARITY,
>> +		      dsi->mode.flags & DRM_MODE_FLAG_PVSYNC ?
>> +		      NWL_DSI_VSYNC_POLARITY_ACTIVE_HIGH :
>>  		      NWL_DSI_VSYNC_POLARITY_ACTIVE_LOW);
>>  	nwl_dsi_write(dsi, NWL_DSI_HSYNC_POLARITY,
>> +		      dsi->mode.flags & DRM_MODE_FLAG_PHSYNC ?
>> +		      NWL_DSI_HSYNC_POLARITY_ACTIVE_HIGH :
>>  		      NWL_DSI_HSYNC_POLARITY_ACTIVE_LOW);
>>  
>>  	burst_mode = (dsi->dsi_mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
>> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.h b/drivers/gpu/drm/bridge/nwl-dsi.h
>> index a247a8a11c7c..61e7d65cb1eb 100644
>> --- a/drivers/gpu/drm/bridge/nwl-dsi.h
>> +++ b/drivers/gpu/drm/bridge/nwl-dsi.h
>> @@ -30,11 +30,11 @@
>>  #define NWL_DSI_PIXEL_FORMAT			0x20c
>>  #define NWL_DSI_VSYNC_POLARITY			0x210
>>  #define NWL_DSI_VSYNC_POLARITY_ACTIVE_LOW	0
>> -#define NWL_DSI_VSYNC_POLARITY_ACTIVE_HIGH	BIT(1)
>> +#define NWL_DSI_VSYNC_POLARITY_ACTIVE_HIGH	BIT(0)
>>  
>>  #define NWL_DSI_HSYNC_POLARITY			0x214
>>  #define NWL_DSI_HSYNC_POLARITY_ACTIVE_LOW	0
>> -#define NWL_DSI_HSYNC_POLARITY_ACTIVE_HIGH	BIT(1)
>> +#define NWL_DSI_HSYNC_POLARITY_ACTIVE_HIGH	BIT(0)
>>  
>>  #define NWL_DSI_VIDEO_MODE			0x218
>>  #define NWL_DSI_HFP				0x21c
>> 

      reply	other threads:[~2025-01-22  7:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-14 10:37 [PATCH] drm/bridge: nwl-dsi: Use vsync/hsync polarity from display mode Esben Haabendal
2024-09-13  7:55 ` Neil Armstrong
2025-01-20 12:42 ` Alexander Stein
2025-01-22  7:15   ` Esben Haabendal [this message]

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=878qr3uxnd.fsf@geanix.com \
    --to=esben@geanix.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=airlied@gmail.com \
    --cc=alexander.stein@ew.tq-group.com \
    --cc=andrzej.hajda@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=rfoss@kernel.org \
    --cc=tzimmermann@suse.de \
    /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