Message-ID: <CAF6AEGvjkStnnL=51LCVnyqMyupzfUT-HVrgyREXW+uAFWCTgQ@mail.gmail.com>
Date: Mon, 29 Jul 2024 13:42:04 -0700
From: Rob Clark <robdclark@...il.com>
To: Mark Kettenis <mark.kettenis@...all.nl>
Cc: Bjorn Andersson <andersson@...nel.org>, dmitry.baryshkov@...aro.org, abel.vesa@...aro.org, 
	konrad.dybcio@...aro.org, robh@...nel.org, krzk+dt@...nel.org, 
	conor+dt@...nel.org, marijn.suijten@...ainline.org, 
	linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, johan@...nel.org, patrick@...nbsd.org
Subject: Re: [PATCH 3/3] arm64: dts: qcom: Add X1E78100 ThinkPad T14s Gen 6

On Tue, Jul 23, 2024 at 2:28 PM Mark Kettenis <mark.kettenis@...all.nl> wrote:
>
> > Date: Tue, 23 Jul 2024 13:55:20 -0500
> > From: Bjorn Andersson <andersson@...nel.org>
> >
> > On Mon, Jul 22, 2024 at 07:03:43PM GMT, Dmitry Baryshkov wrote:
> > > On Mon, Jul 22, 2024 at 08:00:19AM GMT, Rob Clark wrote:
> > > > On Mon, Jul 22, 2024 at 3:11 AM Abel Vesa <abel.vesa@...aro.org> wrote:
> > > > >
> > > > > On 24-07-22 10:42:57, Konrad Dybcio wrote:
> > > > > > On 21.07.2024 6:40 PM, Abel Vesa wrote:
> > > > > > > On 24-07-19 22:16:38, Konrad Dybcio wrote:
> > > > > > >> Add support for the aforementioned laptop. That includes:
> > > > > > >>
> > > > > > >> - input methods, incl. lid switch (keyboard needs the pdc
> > > > > > >>   wakeup-parent removal hack..)
> > > > > > >> - NVMe, WiFi
> > > > > > >> - USB-C ports
> > > > > > >> - GPU, display
> > > > > > >> - DSPs
> > > > > > >>
> > > > > > >> Notably, the USB-A ports on the side are depenedent on the USB
> > > > > > >> multiport controller making it upstream.
> > > > > > >>
> > > > > > >> At least one of the eDP panels used (non-touchscreen) identifies as
> > > > > > >> BOE 0x0b66.
> > > > > > >>
> > > > > > >> See below for the hardware description from the OEM.
> > > > > > >>
> > > > > > >> Link: https://www.lenovo.com/us/en/p/laptops/thinkpad/thinkpadt/lenovo-thinkpad-t14s-gen-6-(14-inch-snapdragon)/len101t0099
> > > > > > >> Signed-off-by: Konrad Dybcio <konrad.dybcio@...aro.org>
> > > > > > >
> > > > > > > Few comments below. Otherwise, LGTM.
> > > > > > >
> > > > > > > Reviewed-by: Abel Vesa <abel.vesa@...aro.org>
> > > > > > >
> > > > > > >> ---
> > > > > > >>  arch/arm64/boot/dts/qcom/Makefile                  |   1 +
> > > > > > >>  .../dts/qcom/x1e78100-lenovo-thinkpad-t14s.dts     | 792 +++++++++++++++++++++
> > > > > > >>  2 files changed, 793 insertions(+)
> > > > > > >>
> > > > > > >> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > > > > >> index 0e5c810304fb..734a05e04c4a 100644
> > > > > > >> --- a/arch/arm64/boot/dts/qcom/Makefile
> > > > > > >> +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > > > > >> @@ -261,6 +261,7 @@ dtb-$(CONFIG_ARCH_QCOM)        += sm8650-hdk-display-card.dtb
> > > > > > >>  dtb-$(CONFIG_ARCH_QCOM)   += sm8650-hdk.dtb
> > > > > > >>  dtb-$(CONFIG_ARCH_QCOM)   += sm8650-mtp.dtb
> > > > > > >>  dtb-$(CONFIG_ARCH_QCOM)   += sm8650-qrd.dtb
> > > > > > >> +dtb-$(CONFIG_ARCH_QCOM)   += x1e78100-lenovo-thinkpad-t14s.dtb
> > > > > > >>  dtb-$(CONFIG_ARCH_QCOM)   += x1e80100-asus-vivobook-s15.dtb
> > > > > > >>  dtb-$(CONFIG_ARCH_QCOM)   += x1e80100-crd.dtb
> > > > > > >>  dtb-$(CONFIG_ARCH_QCOM)   += x1e80100-lenovo-yoga-slim7x.dtb
> > > > > > >> diff --git a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dts b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dts
> > > > > > >
> > > > > > > So what happens for SKUs of this model wil have x1e80100 ?
> > > > > > >
> > > > > > > Maybe we should stick to x1e80100 ?
> > > > > >
> > > > > > This one only ships with 78100
> > > > > >
> > > > >
> > > > > Sure, but then in upstream we only have 80100. Plus, it is included in
> > > > > this file as well.
> > > > >
> > > > > I don't know what's the right thing to do here. But I think it keeps
> > > > > things more simple if we keep everything under the x1e80100 umbrella.
> > > >
> > > > plus sticking to x1e80100 will avoid angering tab completion :-P
> > >
> > > This is an old argument, with no clear answer. For some devices we
> > > choose to use correct SoC name (sda660-inforce-ifc6560). For other we
> > > didn't (sdm845-db845c, which really is SDA845). However for most of the
> > > devices the goal is to be accurate (think about all the qcs vs qcm
> > > stories). So my 2c. would go to x1e78100.
> > >
> >
> > I agree, x1e78100 follows the naming scheme we have agreed upon - for
> > better or worse.
>
> So should the device trees for the Asus Vivobook S15 and the Lenovo
> Yoga Slim 7x be renamed then?  Since those also (only) ship with
> X1E-78-100 variants of the SoC.
>
> There is supposed to be a variant of the Vivobook with the X1P-64-100
> (I haven't seen it actually for sale yet).  Since that one has only 10
> CPU cores, should that one gets its own device tree?  That may not be
> possible.  I have a strong suspicion that all the variants are just
> binned versions of the same SoC, where the X1P just has two of the
> cores disabled.  If Qualcomm, like Apple, attempts to increase the
> yield by binning SoCs with broken or badly performing cores as X1P it
> might be a lottery which of the 12 cores get disabled.
>
> And for the vendors that do offer models with different X1E variants,
> are there going to multiple device trees, one for each variant?
>
> I'm asking because on OpenBSD we load the device trees in our
> bootloader and map SMBIOS vendor and product names to a device tree
> name.  So a consistent naming scheme for the device trees is
> desirable.

multi-sku laptops are going to make this a mess..  We really should
just reconsider.. or maybe sidestep the issue and call them all
"x1-crd.dts", "x1-lenovo-yoga-7x.dts", etc

BR,
-R

> Thanks,
>
> Mark
>
> > Regards,
> > Bjorn
> >
> > > --
> > > With best wishes
> > > Dmitry
> >

Powered by blists - more mailing lists