linux-kernel - Re: [PATCH 2/3] drm/msm/dsi: support DSC configurations with slice_per

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK6c68iV=n3BvMMa30FuehbMs7-U01s0saZnsYwPVoiyw0VTrg@mail.gmail.com>
Date: Mon, 13 Oct 2025 19:04:43 +0800
From: Junjie Cao <caojunjie650@...il.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Neil Armstrong <neil.armstrong@...aro.org>, 
	Jessica Zhang <jessica.zhang@....qualcomm.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Rob Clark <robin.clark@....qualcomm.com>, Dmitry Baryshkov <lumag@...nel.org>, 
	Abhinav Kumar <abhinav.kumar@...ux.dev>, Sean Paul <sean@...rly.run>, 
	Marijn Suijten <marijn.suijten@...ainline.org>, Antonino Maniscalco <antomani103@...il.com>, 
	Jonathan Marek <jonathan@...ek.ca>, Eugene Lepshy <fekz115@...il.com>, Jun Nie <jun.nie@...aro.org>, 
	dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org, 
	freedreno@...ts.freedesktop.org
Subject: Re: [PATCH 2/3] drm/msm/dsi: support DSC configurations with
 slice_per_pkt > 1

Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com> 于2025年10月13日周一 17:39写道：
> On 13/10/2025 04:52, 曹俊杰 wrote:
> >  >Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com
> > <mailto:dmitry.baryshkov@....qualcomm.com>> 于2025年10月2日周四 10:04写道：
> >  >On Wed, Oct 01, 2025 at 09:59:13PM +0800, Junjie Cao wrote:
> >  >> From: Jun Nie <jun.nie@...aro.org <mailto:jun.nie@...aro.org>>
> >  >>
> >  >> Some panels support multiple slice to be sent in a single DSC
> > packet. And
> >  >> this feature is a must for specific panels, such as JDI LPM026M648C.
> > Add a
> >  >> dsc_slice_per_pkt member into struct mipi_dsi_device and support the
> >  >> feature in msm mdss driver.
> >  >>
> >  >> Co-developed-by: Jonathan Marek <jonathan@...ek.ca
> > <mailto:jonathan@...ek.ca>>
> >  >> Signed-off-by: Jonathan Marek <jonathan@...ek.ca
> > <mailto:jonathan@...ek.ca>>
> >  >> Signed-off-by: Jun Nie <jun.nie@...aro.org <mailto:jun.nie@...aro.org>>
> >  >> Signed-off-by: Junjie Cao <caojunjie650@...il.com
> > <mailto:caojunjie650@...il.com>>
> >  >> ---
> >  >>  drivers/gpu/drm/msm/dsi/dsi_host.c | 25 ++++++++++---------------
> >  >>  include/drm/drm_mipi_dsi.h         |  2 ++
> >  >>  2 files changed, 12 insertions(+), 15 deletions(-)
> >  >
> >  >Please extract the generic part, so that it can be merged through a
> >  >generic tree.
> >  >
> >
> > Sorry, I don't get it.  The generic part, generic tree? Do you mean
> > the drm tree? `slice_per_pkt >= 2` is seen on the panels of these
> > tablets that are equipped with qcom chips. I don't know if these
> > panels are used on other platforms, and if it is necessary to do it
> > in drm.
>
> There are two changes here:
> - MIPI DSI header change
> - msm DSI driver
>
> I've asked to split it to those two commits so that he change for
> drm_mipi_dsi.h is more obvious for reviewers and so that it can be
> merged through a drm-misc tree (or through drm-msm tree provided it gets
> a necessary ack).
>

Thanks for your clear explanation.

I don't mind to add the field separately. But should I submit it
with the panel driver together? Otherwise, this field is unused
for a while.

However, as you mentioned, this is not a part of standard, neither
mipi dsi nor VESA DSC. Recently, only Qualcomm devices require it
to calculate parameters, then we use them to program registers. Why
don't we parse the field from devicetree?

>
> --
> With best wishes
> Dmitry

Regards,
Junjie