From: Cristian Cozzolino <cristian_ci@protonmail.com>
Document Novatek NT35532-based DSI display panel.
Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
---
.../bindings/display/panel/novatek,nt35532.yaml | 77 ++++++++++++++++++++++
MAINTAINERS | 5 ++
2 files changed, 82 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt35532.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt35532.yaml
new file mode 100644
index 000000000000..c7928553681a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt35532.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/novatek,nt35532.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Novatek NT35532-based DSI display panels
+
+maintainers:
+ - Cristian Cozzolino <cristian_ci@protonmail.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: novatek,nt35532
+
+ reg:
+ maxItems: 1
+
+ backlight: true
+ reset-gpios: true
+
+ avdd-supply:
+ description: positive boost supply regulator
+
+ avee-supply:
+ description: negative boost supply regulator
+
+ vci-supply:
+ description: regulator that supplies the analog voltage
+
+ vddam-supply:
+ description: power supply for MIPI interface
+
+ vddi-supply:
+ description: regulator that supplies the I/O voltage
+
+ port: true
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - vddi-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "novatek,nt35532";
+ reg = <0>;
+
+ backlight = <&pmi8950_wled>;
+ reset-gpios = <&tlmm 61 GPIO_ACTIVE_LOW>;
+ avdd-supply = <&lab>;
+ avee-supply = <&ibb>;
+ vci-supply = <&pm8953_l17>;
+ vddi-supply = <&pm8953_l6>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index a626dee5c106..8ed2866bbd6e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8171,6 +8171,11 @@ T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
F: drivers/gpu/drm/panel/panel-novatek-nt35510.c
+DRM DRIVER FOR NOVATEK NT35532 PANELS
+M: Cristian Cozzolino <cristian_ci@protonmail.com>
+S: Maintained
+F: Documentation/devicetree/bindings/display/panel/novatek,nt35532.yaml
+
DRM DRIVER FOR NOVATEK NT35560 PANELS
M: Linus Walleij <linusw@kernel.org>
S: Maintained
--
2.53.0On Sat, Mar 21, 2026 at 05:23:20PM +0100, Cristian Cozzolino via B4 Relay wrote:
> From: Cristian Cozzolino <cristian_ci@protonmail.com>
>
> Document Novatek NT35532-based DSI display panel.
>
> Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
> ---
> .../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").
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).
- 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").
- Either use both strings for compat property:
compatible = "tianma,fhd-video", "novatek,nt36672a"
or just the first one.
> +
> + reg:
> + maxItems: 1
> +
> + backlight: true
> + reset-gpios: true
> +
> + avdd-supply:
> + description: positive boost supply regulator
> +
> + avee-supply:
> + description: negative boost supply regulator
> +
> + vci-supply:
> + description: regulator that supplies the analog voltage
> +
> + vddam-supply:
> + description: power supply for MIPI interface
> +
> + vddi-supply:
> + description: regulator that supplies the I/O voltage
> +
> + port: true
> +
> +required:
> + - compatible
> + - reg
> + - reset-gpios
> + - vddi-supply
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + dsi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + panel@0 {
> + compatible = "novatek,nt35532";
> + reg = <0>;
> +
> + backlight = <&pmi8950_wled>;
> + reset-gpios = <&tlmm 61 GPIO_ACTIVE_LOW>;
> + avdd-supply = <&lab>;
> + avee-supply = <&ibb>;
> + vci-supply = <&pm8953_l17>;
> + vddi-supply = <&pm8953_l6>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&dsi0_out>;
> + };
> + };
> + };
> + };
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a626dee5c106..8ed2866bbd6e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8171,6 +8171,11 @@ T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
> F: Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
> F: drivers/gpu/drm/panel/panel-novatek-nt35510.c
>
> +DRM DRIVER FOR NOVATEK NT35532 PANELS
> +M: Cristian Cozzolino <cristian_ci@protonmail.com>
> +S: Maintained
> +F: Documentation/devicetree/bindings/display/panel/novatek,nt35532.yaml
> +
> DRM DRIVER FOR NOVATEK NT35560 PANELS
> M: Linus Walleij <linusw@kernel.org>
> S: Maintained
>
> --
> 2.53.0
>
>
--
With best wishes
Dmitry
On Saturday, March 21st, 2026 at 17:46, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> On Sat, Mar 21, 2026 at 05:23:20PM +0100, Cristian Cozzolino via B4 Relay wrote:
> > From: Cristian Cozzolino <cristian_ci@protonmail.com>
> >
> > Document Novatek NT35532-based DSI display panel.
> >
> > Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
> > ---
> > .../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).
> 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";
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?
Cristian
> - Either use both strings for compat property:
> compatible = "tianma,fhd-video", "novatek,nt36672a"
> or just the first one.
>
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + backlight: true
> > + reset-gpios: true
> > +
> > + avdd-supply:
> > + description: positive boost supply regulator
> > +
> > + avee-supply:
> > + description: negative boost supply regulator
> > +
> > + vci-supply:
> > + description: regulator that supplies the analog voltage
> > +
> > + vddam-supply:
> > + description: power supply for MIPI interface
> > +
> > + vddi-supply:
> > + description: regulator that supplies the I/O voltage
> > +
> > + port: true
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reset-gpios
> > + - vddi-supply
> > + - port
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/gpio/gpio.h>
> > +
> > + dsi {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + panel@0 {
> > + compatible = "novatek,nt35532";
> > + reg = <0>;
> > +
> > + backlight = <&pmi8950_wled>;
> > + reset-gpios = <&tlmm 61 GPIO_ACTIVE_LOW>;
> > + avdd-supply = <&lab>;
> > + avee-supply = <&ibb>;
> > + vci-supply = <&pm8953_l17>;
> > + vddi-supply = <&pm8953_l6>;
> > +
> > + port {
> > + panel_in: endpoint {
> > + remote-endpoint = <&dsi0_out>;
> > + };
> > + };
> > + };
> > + };
> > +...
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index a626dee5c106..8ed2866bbd6e 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -8171,6 +8171,11 @@ T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
> > F: Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
> > F: drivers/gpu/drm/panel/panel-novatek-nt35510.c
> >
> > +DRM DRIVER FOR NOVATEK NT35532 PANELS
> > +M: Cristian Cozzolino <cristian_ci@protonmail.com>
> > +S: Maintained
> > +F: Documentation/devicetree/bindings/display/panel/novatek,nt35532.yaml
> > +
> > DRM DRIVER FOR NOVATEK NT35560 PANELS
> > M: Linus Walleij <linusw@kernel.org>
> > S: Maintained
> >
> > --
> > 2.53.0
> >
> >
>
> --
> With best wishes
> Dmitry
>
On Tue, Mar 24, 2026 at 01:10:13PM +0000, cristian_ci wrote:
> On Saturday, March 21st, 2026 at 17:46, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> > On Sat, Mar 21, 2026 at 05:23:20PM +0100, Cristian Cozzolino via B4 Relay wrote:
> > > From: Cristian Cozzolino <cristian_ci@protonmail.com>
> > >
> > > Document Novatek NT35532-based DSI display panel.
> > >
> > > Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
> > > ---
> > > .../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
On Tuesday, March 24th, 2026 at 23:20, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> On Tue, Mar 24, 2026 at 01:10:13PM +0000, cristian_ci wrote:
> > On Saturday, March 21st, 2026 at 17:46, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 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
>
On Wed, Mar 25, 2026 at 06:31:47PM +0000, cristian_ci wrote:
> On Tuesday, March 24th, 2026 at 23:20, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> > On Tue, Mar 24, 2026 at 01:10:13PM +0000, cristian_ci wrote:
> > > On Saturday, March 21st, 2026 at 17:46, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >
> > 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
struct nt35532_panel_desc
> .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
I'd say, keep it simple. Move just let that struct have .mode and .on. I
think the rest can be generic until somebody needs those.
> to nt35532_of_match. What about the other nt35532 functions (i.e. nt35532_reset)?
You don't need to complicate the driver, keep the reset as is.
--
With best wishes
Dmitry
© 2016 - 2026 Red Hat, Inc.