On Tuesday, March 24th, 2026 at 23:20, Dmitry Baryshkov <[email protected]> wrote:
> 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: > > > > > 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. True. I completely forgot about that, my bad. Yes, vendors handle init sequences, modes and other information in the DT, while upstream puts initialization into panel driver. Now, I've looked at panel-sitronix-st7703.c driver to get an example of multiple panels supported by the same DDIC driver. > 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). Ok, apart adding a new compatible ("flipkart,rimob-panel-nt35532-cs") to dt-bindings (patch 1/6) - leaving "novatek,nt35532" as fallback - and setting that to panel node (patch 3/6), I'll have to change (patch 2/6) too, by renaming nt35532_on to rimob_panel_on and so on for nt35532_off, nt35532_mode; by adding a new struct named rimob_panel_desc defining .mode, .on, .off members and moving .lanes, .format and .mode_flags from nt35532_probe to this new desc specific struct and by adding .data argument to nt35532_of_match. What about the other nt35532 functions (i.e. nt35532_reset)? > > 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 >
