[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250522100605.914443-1-mitltlatltl@gmail.com>
Date: Thu, 22 May 2025 18:05:53 +0800
From: Pengyu Luo <mitltlatltl@...il.com>
To: neil.armstrong@...aro.org
Cc: andersson@...nel.org,
conor+dt@...nel.org,
devicetree@...r.kernel.org,
konradybcio@...nel.org,
krzk+dt@...nel.org,
linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org,
mitltlatltl@...il.com,
robh@...nel.org
Subject: Re: [PATCH 2/2] arm64: dts: qcom: sm8650: Add support for Oneplus Pad Pro (caihong)
On Wed, May 21, 2025 at 8:49 PM <neil.armstrong@...aro.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@...il.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@...il.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
Powered by blists - more mailing lists