Re: [PATCH 1/2] dt-bindings: display: panel: Add bindings for Novatek NT37703

[David Heidelberg]

On 12/08/2026 14:22, Neil Armstrong wrote:
> On 8/12/26 14:15, David Heidelberg wrote:
> > On 12/08/2026 13:52, Neil Armstrong wrote:
> > > On 8/12/26 10:46, David Heidelberg wrote:
> > > > On 12/08/2026 07:21, Esteban Urrutia wrote:
> > > > > On 8/11/26 9:05 AM, David Heidelberg wrote:
> > > > > > Hi Esteban,
> > > > > >
> > > > > > Usually the used pattern is vendor,ddic+panel-model
> > > > > >
> > > > > > novatek,nt37703-motorola-bronco
> > > > > >
> > > > > > ...but motorola bronco isn't the model of the panel.
> > > > > >
> > > > > > My recommendation - look at some video of screen replacement, stop at moment
> > > > > > when FLEX cable from panel is visible and that's where the panel model 
> > > > > > usually is.
> > > > >
> > > > >
> > > > > I somewhat doubt the panel model would be located in the FPC cable.
> > > > > I did search anyway but didn't find anything of interest. And I'm not
> > > > > willing to risk damaging the display flex or the battery of my
> > > > > development device just for a possibility either.
> > > >
> > > > No-one asks you to disassemble the device :)
> > > > Sadly, I haven't found any video doing display replacement either.
> > > > In worst case such as this I assume it make sense keep the phone model in 
> > > > the compatible until panel codename is found.
> > > >
> > > > > For the compatible pattern I used the implemented pattern for the
> > > > > NT36523 TDDI, which is also used for other ICs such as the RM69380.
> > > > >
> > > > > So, I believe it should be okay to leave the compatible as is.
> > > >
> > > > I would like to hear a word from Neil first. In similar cases like this 
> > > > would make sense to have one way defining these compatible strings used in 
> > > > phones.
> > > >
> > > >
> > > > bit I missed in the review the part:
> > > >
> > > > +            compatible = "motorola,bronco-tianma-v2-nt37703", 
> > > > "novatek,nt37703";
> > > >
> > > > Unless the driver is able to auto-detect the connected panel (unlikely), 
> > > > novatek,nt37703 doesn't make sense. The DDIC without the panel is useless.
> > > >
> > > > For example, in sdm845-oneplus-fajita and enchilada, we have the generic 
> > > > compatible because it was introduced before, so it's kept for compatibility 
> > > > reasons. There is no need to do that here.
> > >
> > > Yeah today the norm is to add the ddic as second compatible entry so the 
> > > first compatible just describes the pane, so here it should be:
> > >
> > > compatible = "motorola,bronco-tianma-v2", "novatek,nt37703";
> >
> > So let's me present a situation which can happen, let say I'll be upstreaming:
> >
> > DDIC (novatek,nt37700) + panel (samsung,amb630qy).
> >
> > For the example I choose samsung,amb630qy because here the panel has phone 
> > model in it, which avoids the possible issue I'll be describing with this schema.
> >
> > Vendor can pair this panel with different DDIC. Thus it would be
> >
> > compatible = "samsung,amb630qy", "novatek,nt37700"; // new one
> > compatible = "samsung,amb630qy", "novatek,nt37703"; // existing
> >
> > The reality the driver picks only the first compatible, and that's all causing 
> > to load wrong driver now.
>
> No, the core will pick the first compatible that matches, so...
>
> > Solution here would be differentiate between
> >
> > a) DDIC + panel
> > b) module name (consisting DDIC + panel).
> >
> > We could say module is motorola,bronco-tianma-v2 and contains [ DDIC + unknown 
> > panel ], which doesn't even have to be mentioned in device-tree.
> >
> > While it may seems I overthinking, in this case it doesn't matter that much, I 
> > already have patchsets for DDIC which can be combined with three types of 
> > panels (and using different schema) and I would like to have good solution for 
> > longterm contributions and development.
>
> ... in theory we could have:
>
> compatible = "samsung,amb630qy", "novatek,nt37700"; // new one
> compatible = "samsung,amb630qy", "novatek,nt37703"; // existing
>
> and drivers would only have:
>
> "novatek,nt37700"
>
> and
>
> "novatek,nt37703"
>
> as compatible and then a separate match table with :
>
> "samsung,amb630qy" and "samsung,amb630qy" which associates with the panel data.
>
> If it doesn't match, return -ENODEV and it would work like before,
>
> I mean it's valid, it's a matter of implementation, if the same module can have
> different DDIC then it should be described like that.
>
> In this case, the bindings should be for the module and not for the DDIC.

Definitely make sense in the context. This would mean I'll need to adapt my 
patchset to-be-sent :)

Btw the disccusion slowly mentally gets me closer to the Camera module model, 
where you have multiple components such as

module (sunny-XY) -> camera (sony,imx519)
                  -> focus (dongwoon,dw9714)
                  -> OIS
                  -> fixed components as optics

where as we have here only

"module" (motorola-bronco-tianma-v2) -> DDIC (nt37703)
                                            ↕
                                     -> panel (unknown)
                                     -> touchscreen (sometimes, depend on the
                                                     phone build)

Sometimes init sequences and stuff depends on each other, thus touchscreen is 
part of the module in some cases.

Would it make sense to somehow model this into DT?

Since we doing all the stuff in the panel node, it could be something like

display@0 {
    compatible = "novatek,nt37703"; // first thing we interact with here
    module = "motorola-bronco-tianma-v2"; // DDIC driver picks the module data

    vddio-supply = "...";
    backlight = <&pmi8998_wled>;
    ...

    // I already have combination where two panels has different supplies
    // Samsung S9 vs Pixel 3 XL. One wiring is over DDIC it seems, second
    // directly to the panel
    panel { // REAL panel node
        compatible = "samsung,ams622xy" // maybe as a docs?
        vddneg-supply = <&lab>;
        vddpos-supply = <&ibb>;
    }
}

Just dumping my brain, feel free to ignore if it's complete nonsense.


David



> Neil
>
> > What do you think?
> > David
> >
> >
> > > Neil
> > >
> > > > Thanks
> > > > David
> > > >
> > > > > > David Heidelberg
> > > > >
> > > > >
> > > > > Regards,
> > > > > Esteban

--
David Heidelberg