On Sat, Jun 28, 2025 at 3:48 AM Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote: > On 6/17/25 11:29 AM, Pengyu Luo wrote: > > The Ntmer TW220 is a WOS tablet based on the Qualcomm SC8280XP platform, > > also known as the Robo&Kala 2-in-1 Laptop. Thanks to Hong for providing > > the unlocked device and early development work. This patch adds an > > initial device tree to enable basic functionality. > > > > Currently supported components include: > > - Bluetooth & Wi-Fi (board file regeneration required) > > - Battery charging (up to 15V/3A fixed PDO) and reporting via pmic-glink > > - Flash LEDs (front and rear) > > - Hall sensor (lid detection) > > - Keyboard (via Bluetooth or USB) > > - NVMe SSD > > - Power and volume keys > > - Simple-framebuffer > > - Sound (playback and capture; top-left DMIC only, top-right works only > > on Windows) > > - Touchscreen and stylus (requires GPI DMA support [1] and stylus support [2]) > > - USB Type-C ports > > > > The following components are currently non-functional: > > - Cameras (GalaxyCore GC5035; only sensor ID is detectable, no frames in libcamera; > > partial driver can be found on LKML archives) > > - DSI display (blank screen with `dsi_err_worker: status=4`; primary DSI register > > dump included below) > > - Stylus wireless charger (CPS4035) > > - UCSI over GLINK > > > > [1]: https://lore.kernel.org/linux-arm-msm/20250617090032.1487382-3-mitltlatltl@xxxxxxxxx > > [2]: https://lore.kernel.org/linux-input/20250605054855.403487-2-mitltlatltl@xxxxxxxxx > > > > Note: This series does **not** include any confidential material. Those > > who wish to run Linux on this device should contact Ntmer, as the > > bootloader is locked via secure boot. > > > > Co-developed-by: Hong Zhu <vanyang@xxxxxxxxxxxxxxxx> > > Signed-off-by: Hong Zhu <vanyang@xxxxxxxxxxxxxxxx> > > Signed-off-by: Pengyu Luo <mitltlatltl@xxxxxxxxx> > > > > dsi_ctrl, reg = <0 0x0ae94000 0 0x400>; > > 0xae94000 20050001 000001f3 0000000b dddd1011 > > This is not something we want in the commit log > I will remove it. I need help, then I attached it, two of my sc8280xp devices require dsi to work. Reversing and guessing wasted a lot of time. I will appreciate it if qcom could support it. > [...] > > > + gpio-leds { > > + compatible = "gpio-leds"; > > + > > + pinctrl-names = "default"; > > + pinctrl-0 = <&camf_indicator_en>, <&camr_indicator_en>; > > property-n > property-names > > in that order, across the file, please > Ack > [...] > > > + wsa-dai-link { > > + link-name = "WSA Playback"; > > + > > + cpu { > > + sound-dai = <&q6apmbedai WSA_CODEC_DMA_RX_0>; > > + }; > > + > > + codec { > > 'co'dec < 'cp'u > Ack > [...] > > > +/* > > + * cci0_i2c1 > > + * sda: gpio115, scl: gpio116 > > + * > > + * CAMI ov9234 @36 @48 > > + * > > + * power on sequence > > + * gpio7 out low > > + * l3q 1p8 > > + * l6q 2p8 > > + * l2q 1p2 > > + * gpio7 out high > > + * msleep 5 > > + * cam_cc_mclk4_clk 2.4MHz (gpio6) > > + */ > > It would be useful to enable these buses and set up what we can, > otherwise this is quite a lot of text for comments.. > Ack > [...] > > > +&spi22 { > > + status = "okay"; > > + pinctrl-0 = <&spi22_default>; > > + pinctrl-names = "default"; > > status should be the last property (before subnodes), preferably > with a newline before it, so: > > pinctrl-0 = <&spi22_default>; > pinctrl-names = "default"; > > status = "okay"; > Ack > > > + > > + touchscreen@0 { > > + /* > > + * The ACPI device ID is GXTS7986, its exact suffix is unknown. > > + * The Windows driver suggests it is a GTBerlinB variant and > > + * communicates via HID over SPI, which aligns with the Linux > > + * driver `drivers/hid/hid-goodix-spi.c`. > > + * > > + * However, the HID descriptor read from the device appears > > + * garbled, preventing proper probe with the HID driver. In > > + * contrast, the driver at > > + * `drivers/input/touchscreen/goodix_berlin_spi.c` shares many > > + * similarities and functions correctly with this hardware. > > + * > > + * Therefore, we choose to use the goodix_berlin_spi driver > > + * instead. > > Is this something you could work out with the aforementioned drivers' > maintainers? > Since the ts device works well, I am still occupied with dsi things, I may contact them later. BTW, could you please review the gpi dma patches, touchscreen depends on it, it is still hanging there, thanks in advance. https://lore.kernel.org/linux-arm-msm/20250617090032.1487382-3-mitltlatltl@xxxxxxxxx > [...] > > > +&pcie4_port0 { > > + wifi@0 { > > + compatible = "pci17cb,1103"; > > + reg = <0x10000 0x0 0x0 0x0 0x0>; > > + > > + vddrfacmn-supply = <&vreg_pmu_rfa_cmn_0p8>; > > + vddaon-supply = <&vreg_pmu_aon_0p8>; > > + vddwlcx-supply = <&vreg_pmu_wlcx_0p8>; > > + vddwlmx-supply = <&vreg_pmu_wlmx_0p8>; > > + vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>; > > + vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>; > > + vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>; > > + vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>; > > + vddrfa1p8-supply = <&vreg_pmu_rfa_1p7>; > > + > > + /* > > + * bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb, > > + * subsystem-device=0108,qmi-chip-id=18,qmi-board-id=255 > > + * > > + * Regenerate board file, x13s one works well > > Please post on the ath11k mailing list and propose and ask for > that variant to be included > Ack Best wishes, Pengyu