> Date: Tue, 23 Jul 2024 13:55:20 -0500 > From: Bjorn Andersson <andersson@xxxxxxxxxx> > > 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@xxxxxxxxxx> 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@xxxxxxxxxx> > > > > > > > > > > > > Few comments below. Otherwise, LGTM. > > > > > > > > > > > > Reviewed-by: Abel Vesa <abel.vesa@xxxxxxxxxx> > > > > > > > > > > > >> --- > > > > > >> 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. Thanks, Mark > Regards, > Bjorn > > > -- > > With best wishes > > Dmitry >
