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

[neil.armstrong@linaro.org]

On 22/05/2025 12:05, Pengyu Luo wrote:
> 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.

The WCD9395 has 2 independent functions on the same die, one
as a codec and the other one as an SBU mux for Altmode and audio
headset. They are representd as 2 devices since they have 2
separate communication ports (one is i2c, and the other is via soundwire)

Neil

> 
> Thanks. I will check it again.
> 
> Best wishes,
> Pengyu
>