Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Andrzej Hajda <andrzej.hajda@intel.com>
To: Rex-BC Chen <rex-bc.chen@mediatek.com>, <chunkuang.hu@kernel.org>,
	<matthias.bgg@gmail.com>, <narmstrong@baylibre.com>,
	<robert.foss@linaro.org>, <daniel@ffwll.ch>, <airlied@linux.ie>,
	<p.zabel@pengutronix.de>
Cc: <xji@analogixsemi.com>, <jitao.shi@mediatek.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	 <linux-kernel@vger.kernel.org>,
	<Project_Global_Chrome_Upstream_Group@mediatek.com>
Subject: Re: [v8, PATCH 1/3] drm/dsi: transfer DSI HS packets ending at the same time
Date: Thu, 13 Jan 2022 01:14:14 +0100	[thread overview]
Message-ID: <2f0fd4a9-4d24-a6b7-12ae-51763f304761@intel.com> (raw)
In-Reply-To: <20220112153639.12343-2-rex-bc.chen@mediatek.com>

Hi,

On 12.01.2022 16:36, Rex-BC Chen wrote:
> Since a HS transmission is composed of an arbitrary number
> of bytes that may not be an integer multiple of lanes, some
> lanes may run out of data before others.
> (Defined in 6.1.3 of mipi_DSI_specification_v.01-02-00)
>
> However, for some DSI RX devices (for example, anx7625),
> there is a limitation that packet number should be the same
> on all DSI lanes. In other words, they need to end a HS at
> the same time.


Is it documented in anx7625 manual? Is it confirmed with hw team?

If not, how it was detected? Have you tried to find workaround for it by 
inspecting registers, maybe it is just matter of clock gating deferral, 
timings or sth similar ???.

>
> Because this limitation is for some specific DSI RX devices,
> it is more reasonable to put the enable control in these
> DSI RX drivers. If DSI TX driver knows the information,
> they can adjust the setting for this situation.
>
> Therefore, add a flag to control this situation beacuse the
> mipi DSI specification is not forbidden this situation.


I am not sure what you mean here.

I have an impression (according t 6.1.3 of spec) that devices should 
allow transmission of arbitrary number of bytes, so this is bug in hw/fw.

The question if it can be fixed. If not patches are welcome.


>
> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
> Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
> ---
>   include/drm/drm_mipi_dsi.h | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 147e51b6d241..df4d15345326 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -177,6 +177,8 @@ struct mipi_dsi_device_info {
>    * @lp_rate: maximum lane frequency for low power mode in hertz, this should
>    * be set to the real limits of the hardware, zero is only accepted for
>    * legacy drivers
> + * @hs_packet_end_aligned: transfer DSI HS packets ending at the same time
> + * for all DSI lanes
>    */
>   struct mipi_dsi_device {
>   	struct mipi_dsi_host *host;
> @@ -189,6 +191,7 @@ struct mipi_dsi_device {
>   	unsigned long mode_flags;
>   	unsigned long hs_rate;
>   	unsigned long lp_rate;
> +	bool hs_packet_end_aligned;


Maybe it would be better to add another mode_flag.


Regards

Andrzej



>   };
>   
>   #define MIPI_DSI_MODULE_PREFIX "mipi-dsi:"

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-01-13  0:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-12 15:36 [v8, PATCH 0/3] force hsa hbp hfp packets multiple of lanenum to avoid screen shift Rex-BC Chen
2022-01-12 15:36 ` [v8, PATCH 1/3] drm/dsi: transfer DSI HS packets ending at the same time Rex-BC Chen
2022-01-13  0:14   ` Andrzej Hajda [this message]
2022-01-13 11:09     ` Xin Ji
2022-01-12 15:36 ` [v8, PATCH 2/3] drm/mediatek: implement the DSI hs packets aligned Rex-BC Chen
2022-01-12 15:36 ` [v8, PATCH 3/3] drm/bridge: anx7625: config hs packets end aligned to avoid screen shift Rex-BC Chen

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=2f0fd4a9-4d24-a6b7-12ae-51763f304761@intel.com \
    --to=andrzej.hajda@intel.com \
    --cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
    --cc=airlied@linux.ie \
    --cc=chunkuang.hu@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=jitao.shi@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=narmstrong@baylibre.com \
    --cc=p.zabel@pengutronix.de \
    --cc=rex-bc.chen@mediatek.com \
    --cc=robert.foss@linaro.org \
    --cc=xji@analogixsemi.com \
    /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