linux-kernel - Re: [v8, PATCH 1/3] drm/dsi: transfer DSI HS packets ending at the same time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20220113110941.GA2480843@anxtwsw-Precision-3640-Tower>
Date:   Thu, 13 Jan 2022 19:09:41 +0800
From:   Xin Ji <xji@...logixsemi.com>
To:     Andrzej Hajda <andrzej.hajda@...el.com>,
        Rex-BC Chen <rex-bc.chen@...iatek.com>,
        chunkuang.hu@...nel.org, matthias.bgg@...il.com,
        narmstrong@...libre.com, robert.foss@...aro.org, daniel@...ll.ch,
        airlied@...ux.ie, p.zabel@...gutronix.de
Cc:     jitao.shi@...iatek.com, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Project_Global_Chrome_Upstream_Group@...iatek.com
Subject: Re: [v8, PATCH 1/3] drm/dsi: transfer DSI HS packets ending at the
 same time

Hi Andrzej Hajda,

On Thu, Jan 13, 2022 at 01:14:14AM +0100, Andrzej Hajda wrote:
> 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?
We have application note, and it is confirmed by designer, 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.
This is anx7625 bridge chip design limitation.

> 
> The question if it can be fixed. If not patches are welcome.
> 
> 
> > 
> > Signed-off-by: Jitao Shi <jitao.shi@...iatek.com>
> > Reviewed-by: Chun-Kuang Hu <chunkuang.hu@...nel.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.
mode_flag should be OK.

Thanks,
Xin
> 
> 
> Regards
> 
> Andrzej
> 
> 
> 
> >   };
> >   #define MIPI_DSI_MODULE_PREFIX "mipi-dsi:"