Re: [PATCH 2/2] arm64: dts: qcom: sm8650: Add support for Oneplus Pad Pro (caihong)

[Pengyu Luo <mitltlatltl@gmail.com>]

On Wed, May 21, 2025 at 8:49 PM <neil.armstrong@linaro.org> wrote:
>
> Hi,
>
> On 20/05/2025 18:42, Pengyu Luo wrote:
> > The OnePlus Pad Pro is an Android tablet based on the Qualcomm SM8650
> > platform. Its device codename is "caihong". This patch adds an initial
> > devicetree for basic functionality.
> >
> > Currently working components include:
> > - Backlight
> > - Bluetooth
> > - Battery charging (up to 5v 0.5a) & reporting via pmic-glink (There
> > are many unknown notifications)
> > - Display panel ([1])
> > - Keyboard (via BT)
> > - Power key & volume keys
> > - Touchscreen & stylus ([2])
> > - USB Type-c port
> > - UFS storage
> > - Wi-Fi
> >
> > The following components are currently non-functional:
> > - Audio
> > - Cameras
> > - Charging pump (dual sc8547)
> > - Keyboard (via pogo pin)
> > - Stylus wireless charger (cps8601)
> > - UCSI over GLINK (PPM init fails)
>
> Are you sure the QMP PHY and the dwc3 probes ? if one is missing, UCSI PPM init will timeout because it doesn't find the connectors muxes & otg devices.
>

I am pretty sure.
ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: PPM init failed, stop trying

> >
> > [1]: The panel is a dual-DSI, dual-DSC display that requires setting
> >       'slice_per_pkt = 2' in the DPU configuration. The panel driver
> >       will be submitted separately later.
> > [2]: Touchscreen/stylus driver available at:
> >       https://github.com/OnePlusOSS/android_kernel_modules_and_devicetree_oneplus_sm8650/blob/oneplus/sm8650_v_15.0.0_pad_pro/vendor/oplus/kernel/touchpanel/oplus_touchscreen_v2/Novatek/NT36532_noflash/nvt_drivers_nt36532_noflash.c
> >       The downstream driver has been ported and tested locally, but
> >       requires cleanup, it may be submitted separately later.
> >
> > To test this device tree, follow these minimal steps:
> >
> > 1. Build the kernel. Ensure that all `compatible` strings used in
> > this device tree (or any included dtsi files) have corresponding
> > drivers enabled in the kernel configuration.
> >
> > 2. Creating boot image
> >
> > Merge the kernel and device tree blob:
> >
> > cat arch/arm64/boot/Image.gz arch/arm64/boot/dts/qcom/sm8650-oneplus-\
> > caihong.dtb > kernel-dtb
> >
> > Then create a boot.img:
> >
> > mkbootimg \
> > --base 0x00000000 \
> > --kernel_offset 0x00008000 \
> > --ramdisk_offset 0x01000000 \
> > --second_offset 0x00f00000 \
> > --tags_offset 0x00000100 \
> > --pagesize 4096 \
> > --header_version 4 \
> > --kernel kernel-dtb \
> > --ramdisk some_ramdisk \
> > --cmdline "some comeline" \
> > -o mainline-boot.img
>
> Isn't image version 2 working ?
>

Yes, '--header_version 2' works, I followed the version of stock boot
image. If there is a rule to follow?

> >
> > 3. Flashing the boot image
> >
> > fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
> > fastboot erase dtbo
> > fastboot flash boot mainline-boot.img
> >
> > See also https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=39c5963
> >
> > Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> > ---
> >   .../boot/dts/qcom/sm8650-oneplus-caihong.dts  | 960 ++++++++++++++++++
> >   1 file changed, 960 insertions(+)
> >   create mode 100644 arch/arm64/boot/dts/qcom/sm8650-oneplus-caihong.dts
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8650-oneplus-caihong.dts b/arch/arm64/boot/dts/qcom/sm8650-oneplus-caihong.dts
> > new file mode 100644
> > index 0000000000..93aed47e10
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/sm8650-oneplus-caihong.dts
> > @@ -0,0 +1,960 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/*
> > + * Based on Qualcomm Reference Device DeviceTree
> > + *
> > + * Copyright (c) 2023, Linaro Limited
> > + * Copyright (c) 2025, Pengyu Luo <mitltlatltl@gmail.com>
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> > +#include "sm8650.dtsi"
> > +#include "pm8550.dtsi"
> > +#include "pm8550b.dtsi"
> > +#define PMK8550VE_SID 8
> > +#include "pm8550ve.dtsi"
> > +#include "pm8550vs.dtsi"
> > +#include "pmk8550.dtsi"
> > +
> > +/delete-node/ &adspslpi_mem;
> > +/delete-node/ &hwfence_shbuf;
> > +
> > +/* No Modem */
> > +/delete-node/ &mpss_mem;
> > +/delete-node/ &q6_mpss_dtb_mem;
> > +/delete-node/ &mpss_dsm_mem;
> > +/delete-node/ &mpss_dsm_mem_2;
> > +/delete-node/ &qlink_logging_mem;
> > +/delete-node/ &remoteproc_mpss;
> > +
> > +/* Unused now, and reusable, taking 144 MiB back */
> > +/delete-node/ &trust_ui_vm_mem;
> > +/delete-node/ &oem_vm_mem;
> > +/delete-node/ &qdss_mem;
>
> Are you sure QTEE won't use this ?
>

I am not sure, but these two VM nodes are never referred by any device
in the downstream DT. QDSS and coresight things are unnecessary on the
retail devices.

> > +
> > +/ {
> > +     model = "Oneplus Pad Pro";
> > +     compatible = "oneplus,caihong", "qcom,sm8650";
> > +     chassis-type = "tablet";
> > +
> > +     aliases {
> > +             serial0 = &uart14;
> > +     };
> > +
> > +     bl_avdd_5p9: bl-avdd-regulator {
> > +             compatible = "regulator-fixed";
> > +             regulator-name = "bl_avdd_5p9";
> > +             regulator-min-microvolt = <5900000>;
> > +             regulator-max-microvolt = <5900000>;
> > +             gpio = <&tlmm 90 GPIO_ACTIVE_HIGH>;
> > +             enable-active-high;
> > +     };
> > +
> > +     bl_avee_5p9: bl-avee-regulator {
> > +             compatible = "regulator-fixed";
> > +             regulator-name = "bl_avee_5p9";
> > +             regulator-min-microvolt = <5900000>;
> > +             regulator-max-microvolt = <5900000>;
> > +             gpio = <&tlmm 91 GPIO_ACTIVE_HIGH>;
> > +             enable-active-high;
> > +     };
> > +
> > +     gpio-keys {
> > +             compatible = "gpio-keys";
> > +
> > +             pinctrl-0 = <&volume_up_n>;
> > +             pinctrl-names = "default";
> > +
> > +             key-volume-up {
> > +                     label = "Volume Up";
> > +                     linux,code = <KEY_VOLUMEDOWN>;
> > +                     gpios = <&pm8550_gpios 6 GPIO_ACTIVE_LOW>;
> > +                     debounce-interval = <15>;
> > +                     linux,can-disable;
> > +                     wakeup-source;
> > +             };
> > +     };
> > +
> > +     pmic-glink {
> > +             compatible = "qcom,sm8650-pmic-glink",
> > +                          "qcom,sm8550-pmic-glink",
> > +                          "qcom,pmic-glink";
> > +             #address-cells = <1>;
> > +             #size-cells = <0>;
> > +             orientation-gpios = <&tlmm 29 GPIO_ACTIVE_HIGH>;
> > +
> > +             connector@0 {
> > +                     compatible = "usb-c-connector";
> > +                     reg = <0>;
> > +
> > +                     power-role = "dual";
> > +                     data-role = "dual";
> > +
> > +                     ports {
> > +                             #address-cells = <1>;
> > +                             #size-cells = <0>;
> > +
> > +                             port@0 {
> > +                                     reg = <0>;
> > +
> > +                                     pmic_glink_hs_in: endpoint {
> > +                                             remote-endpoint = <&usb_1_dwc3_hs>;
> > +                                     };
> > +                             };
> > +
> > +                             port@1 {
> > +                                     reg = <1>;
> > +
> > +                                     pmic_glink_ss_in: endpoint {
> > +                                             remote-endpoint = <&usb_dp_qmpphy_out>;
> > +                                     };
> > +                             };
>
> No Altmode display ? no SBU mux nor redrivers ?
>

There should be a wcd939x_i2c@e, it will be added after I figure out
sound things. Actually, I added it locally, it does not work. Since
its name is wcd939x, it made me feel it is for usb dac handling only.
I never checked it carefully. But you mentioned this, I just checked
downstream bindings, it says

QTI WCD9395 Device

This device is used for switching orientation of USB-C analog
and for display. It uses I2C communication to set the registers
to configure the switches inside the WCD9395 chip to change
orientation and also to set SBU1/SBU2 connections of USB-C.

Thanks. I will check it again.

Best wishes,
Pengyu