Hi Olivier, > Am 06.11.2026 um 12:21 schrieb Olivier Louvignes <[email protected]>: > > Hi Nikolaus, > > On Thu, Nov 05, 2026 at 11:27:12AM +0100, H. Nikolaus Schaller wrote: >> The manual for the x1600 is a bit ambiguous, but the x2000 and x2600 >> documentation identifies this block as the "DPU (Display Processing Unit) >> Display Controller" (located at base address 0x13050000 on all three SoC). > [...] >> Please update the compatible string to "ingenic,x1600-dpu" (with >> "ingenic,dpu" >> as the fallback) and rename the file to ingenic-dpu.c to reflect that this is >> a scalable DPU driver not limited to "LCD". > > Agreed on the name, v3 uses ingenic,x1600-dpu. The X1600 manual says > DPU too in its register and clock names, and when I checked the driver > against the X2000 manual it came out as the X2000's DPU without the > composer. > > No ingenic,dpu fallback though: writing-bindings.rst asks for SoC > compatibles rather than family names, so an X2000 would be > ingenic,x2000-dpu, with the X1600's as its fallback if its registers > allow. > > The driver keeps its file name for now. It only drives what the X1600 > has and what I can test (parallel RGB from one plane), so the split > between the core and the interfaces, and the X2600's rotation, is better > shaped by whoever adds the X2000 with a board to test it on.
So we will have: $ ls -1 drivers/gpu/drm/ingenic/*.c drivers/gpu/drm/ingenic/ingenic-drm-drv.c drivers/gpu/drm/ingenic/ingenic-drm.mod.c drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c drivers/gpu/drm/ingenic/ingenic-ipu.c drivers/gpu/drm/ingenic/ingenic-x1600-drm.c What about ingenic-dpu-x1600.c then? I.e. make the DPU variant a suffix? >> However, this approach triggered a kernel lockup during boot >> right after successfully running lg35583_get_modes(). > > I can't reproduce it here, the R1 comes up with its panel at every boot > (with v3 again today). With nothing on the pins I don't know yet where > it would hang. If you get a log of it (the last lines with > initcall_debug) I'll have a look. Indeed. What I have done is to hack some return 0; into the driver because probe fails without missing SPI client - as it should and likely does if you disconnect the panel. So I should try to locate a non-SPI panel and pretend in the device tree it is connected... > > v3: https://lore.kernel.org/r/[email protected] > > Thanks for the review, > Olivier You are welcome, Nikolaus
