On Tue, Mar 24, 2026 at 01:10:13PM +0000, cristian_ci wrote: > On Saturday, March 21st, 2026 at 17:46, Dmitry Baryshkov > <[email protected]> wrote: > > > On Sat, Mar 21, 2026 at 05:23:20PM +0100, Cristian Cozzolino via B4 Relay > > wrote: > > > From: Cristian Cozzolino <[email protected]> > > > > > > Document Novatek NT35532-based DSI display panel. > > > > > > Signed-off-by: Cristian Cozzolino <[email protected]> > > > --- > > > .../bindings/display/panel/novatek,nt35532.yaml | 77 > > > ++++++++++++++++++++++ > > > MAINTAINERS | 5 ++ > > > 2 files changed, 82 insertions(+) > > > > > +allOf: > > > + - $ref: panel-common.yaml# > > > + > > > +properties: > > > + compatible: > > > + const: novatek,nt35532 > > > > This is not enough to identify the panel. This name identifies the > > controller inside the panel, however the exact settings (and the > > behaviour) would depend on the exact TFT "glass" used with this > > controller. Downstream usually doesn't care that much and frequently > > just uses the controller name or the the controller with some kind of > > "description" like ("wqhd-dsc-cmd"). > > Ok but I just don't understand the following: I'd like to know (also > considering that I find it difficult to find someone, outside of this > ML, available to discuss this stuff, specifically) exactly why the > current bindings are not enough. > I mean: looking at schematics and datasheets of other similar devices > and based on observations about my device, I believe the generic bindings > approach for nt35532 works quite well for panels. > Novatek made the IC first and then whoever buys it can be a display > vendor. If we talk about downstream, differences between panels are described > there (i.e. my panel makes use of four supplies, while other ones could use > a different configuration).
Different "glass" means different programming sequences. Take a look at the existing drivers which handle multiple panels. Sequences, modes, etc. are different though the DDIC (controller) is the same. For Android kernels this is handled by putting all the information into the DT. This approach does not align well with the upstream DT expectations / guidelines / philosophy / etc. For example, let's take two NT35532 panels described by [1], [2]. The sequences are somewhat similar, but the contents is completely different. From the upstream point of view, each should be described by its own compatible string (so that the kernel can identify them). [1] https://github.com/eliot-shao/qcom/blob/master/display/LCM-NT35532-JM55FH-1080p/kernel/arch/arm/boot/dts/qcom/dsi-panel-nt35532-jm55fh-1080p-video.dtsi [2] https://github.com/balika011/android_kernel_xiaomi_msm8953/blob/master/arch/arm/boot/dts/qcom/dsi-panel-nt35532-fhd-video.dtsi > > > What does it mean for the upstream: > > - Try identifying the actual panel used for the phones. Sometimes > > googling for spare or replacement parts would reveal such a name. > > Sometimes it can be seen as a marking on the cable or on the backside > > of the panel (again, googling). > > It seems that 'google' approach fails, in my case :( (I only know that > the vendor assigned Smartron the work to design the HW - but SW too - > of the device. Nevertheless, Smartron is neither OEM nor ODM, so the > company was relying, at the time, on a series of chinese manufacturers to > provide > parts required for this device, including panel suppliers: in general, > the list of panel suppliers for Smartron includes BOE, Tianma and other known > companies. So, this panel may be any of those, paired with NT35532, and work > anyway). Unfortunately, even if marking on the cable is known, that doesn't > identify the panel but the cable itself (which is available on the market, > though), instead, in this case. > > > - If not found, come up with some artificial identifier that would > > identify the controller+glass combo (e.g. "tianma,fhd-video" or > > "lenovo,j606f-boe-nt36523w" (where lenovo,j6006f is a device name and > > boe is a "supplier"). > > Assuming that resources available which I've as source of information > for this panel are limited (the ones also described in v1's review thread), > my vendor devicetree describes the panel in > 'qcom,mdss_dsi_nt35532_1080p_cs_video' > node and makes use of: > > qcom,mdss-dsi-panel-name = "nt35532 1080p cs video mode dsi panel"; > > property. Until now, close-to-mainline devicetree I was using the following > compatible for the panel: > > compatible = "flipkart,rimob-nt35532-cs"; In the lack of any information, this is probably as good as anything else. Please describe in your commit message that you don't know the exact vendor of the panel (nor the id of the panel). > > and I'm not sure about the exact meaning of 'cs' suffix. I cannot state 'CS' > as panel supplier and use that upstream without proof/evidence. What do > you suggest, in this regard? > > -- With best wishes Dmitry
