drm/panel: add VIEWE 7 inch JD9365TX in-cell DSI panel by HF-2001 · Pull Request #7633 · raspberrypi/linux

HF-2001 · 2026-09-18T10:45:43Z

Add support for the VIEWE 7" 720x1280 MIPI DSI panel (Jadard JD9365TX, module 7KF82). Includes the DRM panel driver, in-cell touch (I2C poll), I2C backlight, DT bindings, and overlays for Pi 4 and Pi 5.

Usage:
dtoverlay=vc4-kms-dsi-viewe-7inch # Pi 4
dtoverlay=vc4-kms-dsi-viewe-7inch-pi5 # Pi 5

Panel is 2-lane only. Touch is at 0x68, backlight MCU at 0x45.
Tested on Raspberry Pi 4 and Raspberry Pi 5.

6by9

These comments are based on a fairly brief read through.

6by9 · 2026-09-22T14:24:42Z

+ * Init sequence (page select via 0xDE). Page0 0xCC = 0x31 (2-lane).
+ */
+static const struct jd9365tx_cmd jd9365tx_7kf82_init[] = {
+#include "panel-viewe-jd9365tx-init.h"


Including a .h file that isn't a header isn't acceptable.

6by9 · 2026-09-22T14:34:16Z

+{
+	struct jd9365tx_panel *ctx = to_jd9365tx(panel);
+	const struct drm_display_mode *src =
+		use_60hz ? &jd9365tx_7kf82_mode_60 : &jd9365tx_7kf82_mode_50;


Should be switched by the compatible string, not a module parameter.

6by9 · 2026-09-22T14:35:24Z

+		 "Delay between DISPOFF/SLPIN retries");
+
+static struct mipi_dsi_device *g_reboot_dsi;
+static struct notifier_block jd9365tx_reboot_nb;


Globals don't work if you have two of the devices connected to the system.

6by9 · 2026-09-22T14:36:02Z

+static uint sleep_cmd_retry_delay_ms = 20;
+module_param(sleep_cmd_retry_delay_ms, uint, 0644);
+MODULE_PARM_DESC(sleep_cmd_retry_delay_ms,
+		 "Delay between DISPOFF/SLPIN retries");


None of these things should be module parameters. You're writing the driver for this particular panel, so these values should be known.

6by9 · 2026-09-22T14:38:47Z

+	return 0;
+}
+
+static void jd9365tx_run_dsi_diag(struct mipi_dsi_device *dsi, const char *tag)


DSI reads are generally a little dubious. This adds nothing.

6by9 · 2026-09-22T14:57:12Z

+
+/*
+ * Parse ESRAM section table for coordinate_report address / length.
+ * Layout matches official jd9365tx_ChipInfoInit / ReadSectionInfo.


If you're referencing documentation, then it needs to be a complete reference to what the document is.

6by9 · 2026-09-22T14:58:21Z

+		if (ret == 1)
+			return 0;
+		msleep(20);
+	}


Why is I2C communication with this device so unreliable that it requires retries? That implies some issue in the design somewhere.

6by9 · 2026-09-22T14:59:19Z

+		if (down) {
+			touchscreen_report_pos(ts->input, &ts->prop, x, y, true);
+			input_report_abs(ts->input, ABS_MT_TOUCH_MAJOR, w);
+			ts->prev_x[i] = x;


Why store the points? They are never read back.

6by9 · 2026-09-22T15:01:57Z

+	if (ts->suspended)
+		return;
+
+	mutex_lock(&ts->lock);


What do you think this mutex is protecting against? The poll worker will only ever be called from one workqueue context, and this is the only thing that locks and unlocks the mutex.

6by9 · 2026-09-22T15:10:27Z

+	};
+
+	fragment@2 {
+		target = <&i2c_csi_dsi1>;


On pi5, i2c_csi_dsi is an alias of i2c_csi_dsi1, so no need for a separate overlay at all as that is the only diff.

https://github.com/raspberrypi/linux/blob/rpi-6.18.y/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dts#L221

6by9 · 2026-09-22T15:16:13Z

This needs to be broken into at least the following patches:

DT bindings for panel driver
DT bindings for touch driver
DT bindings for backlight MCU
DRM panel driver
touch driver
backlight MCU driver
defconfig changes (ideally splitting arm from arm64)
overlay

The kernel requires all patches to have the Signed-off-by: to be an identifiable individual. https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
We don't care as much for dtoverlays, but drivers need it.

The weird bus driver setup for touchscreen and backlight needs some explanation. They're on separate I2C addresses, and all i2c_transfer calls are atomic, so why the need to try synchronising them?

And all the drivers and binding should be submitted upstream. Having drivers in this downstream kernel tree adds an undesirable maintenance burden. Upstream will give you a significantly more thorough review as well.

HF-2001 · 2026-09-23T01:38:21Z

We greatly appreciate your meticulous guidance. The code will be revised strictly in compliance with your specified requirements. Our sincere gratitude goes to you for your support. Original From:6by9 ***@***.***> Sent Time:Sep 22, 2026 23:16 To:raspberrypi/linux ***@***.***> Cc:HF-2001 ***@***.***>, Author ***@***.***> Subject:Re: [raspberrypi/linux] drm/panel: add VIEWE 7 inch JD9365TX in-cell DSI panel (PR #7633) 6by9 left a comment (raspberrypi/linux#7633) This needs to be broken into at least the following patches: DT bindings for panel driver DT bindings for touch driver DT bindings for backlight MCU DRM panel driver touch driver backlight MCU driver defconfig changes (ideally splitting arm from arm64) overlay The kernel requires all patches to have the Signed-off-by: to be an identifiable individual. https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin We don't care as much for dtoverlays, but drivers need it. The weird bus driver setup for touchscreen and backlight needs some explanation. They're on separate I2C addresses, and all i2c_transfer calls are atomic, so why the need to try synchronising them? And all the drivers and binding should be submitted upstream. Having drivers in this downstream kernel tree adds an undesirable maintenance burden. Upstream will give you a significantly more thorough review as well. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.

HF-2001 · 2026-09-28T06:10:17Z

Thanks for the review.

Pushed an updated series:

split into separate commits for the bindings, panel, touch, backlight, defconfig and overlay
inlined the panel init sequence into the .c and dropped the extra header
removed the module parameters, DSI read diagnostics, reboot notifier and globals
removed the shared I2C backlight queue; backlight now writes directly
touch uses input_setup_polling()
one overlay on i2c_csi_dsi

The queue was left over from early bring-up. Touch and backlight are on different addresses, so normal independent I2C transfers are enough.

HF-2001 · 2026-10-21T07:04:31Z

Hi Dave,

Just a gentle reminder that we pushed an updated series on Sep 28 addressing your review comments (split commits, removed the shared I2C queue, input_setup_polling, single overlay, etc.).

Whenever you have a moment to take another look, that would be much appreciated. Thanks again for your guidance.

Best regards

6by9

I haven't reviewed the dtbindings in detail as the upstream maintainers deal with that. However vendor specific properties will have to be justified.

I'd said last time

And all the drivers and binding should be submitted upstream. Having drivers in this downstream kernel tree adds an undesirable maintenance burden. Upstream will give you a significantly more thorough review as well.

Are you intending to submit upstream?

And as per one of my review comments, what is different about JD9365TX vs JD9365A that already has a panel driver?

6by9 · 2026-10-21T17:42:58Z

+  reg:
+    maxItems: 1
+
+  default-brightness:


You've included common.yaml, so you shouldn't need to define default-brightness again.

Agreed. We included common.yaml already, so we will drop the duplicate default-brightness definition.

6by9 · 2026-10-21T17:47:16Z

+	__overrides__ {
+		rotation = <&panel>, "rotation:0";
+		notouch = <&jadard_tp>, "status=disabled";
+		nobl = <&viewe_bl>, "status=disabled";


Doesn't the backlight = <&viewe_bl>; line for the panel not need to be disabled too? (Question rather than statement)

Good catch — yes. With nobl we should also stop the panel from referencing &viewe_bl (clear/disable that backlight link), otherwise the panel still expects a backlight device that is disabled. We will fix the overlay accordingly.

6by9 · 2026-10-22T14:42:06Z

@@ -0,0 +1,390 @@
+// SPDX-License-Identifier: GPL-2.0


There is already a panel-jadard-jd9365a-h3.c panel driver in the tree (https://github.com/raspberrypi/linux/blob/rpi-6.18.y/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c)

What's the difference with JD9365TX that makes it incompatible?

The existing driver is for the JD9365DA family (panel-jadard-jd9365da-h3.c), used by 800x1280 / 4-lane modules with their own init tables.

This panel is a JD9365TX on VIEWE 7KF82: 720x1280, 2-lane only, and a different init sequence (including 2-lane config). Those differences make it incompatible with the existing DA driver without turning that file into a catch-all for unrelated modules, so we kept a separate panel driver.

6by9 · 2026-10-22T14:48:05Z

+  reg:
+    maxItems: 1
+
+  jadard,poll-interval-ms:


input-common.yaml defines a standard poll-interval property.

Agreed. We will switch to the standard poll-interval property from input-common.yaml and drop jadard,poll-interval-ms.

6by9 · 2026-10-22T17:37:06Z

+    minimum: 8
+    maximum: 100
+
+  jadard,max-touch-number:


Is this really a configurable thing that can't be read back from the touch controller?

For this module the touch point count is fixed by the firmware/panel design and we do not have a reliable register readback for it during bring-up. We will hard-code it in the driver and remove the DT property.

6by9 · 2026-10-22T17:46:27Z

+	if (IS_ERR(bl->bd))
+		return PTR_ERR(bl->bd);
+
+	ret = viewe_bl_write(client, VIEWE_BL_DEFAULT);


Not needed as you've set brightness in the backlight_properties struct, which is documented as setting the default brightness
https://elixir.bootlin.com/linux/v6.18.57/source/include/linux/backlight.h#L171

Based on that, viewe_bl_write may as well be merged into viewe_bl_update_status as it's the only place it is then called from.

Agreed. We will drop the extra viewe_bl_write() in probe and fold the I2C write into viewe_bl_update_status only.

6by9 · 2026-10-22T17:49:09Z

+MODULE_AUTHOR("Hefei <3066883572@qq.com>");
+MODULE_DESCRIPTION("VIEWE 7\" JD9365TX MIPI-DSI panel");
+MODULE_LICENSE("GPL");
+MODULE_SOFTDEP("pre: viewe_bl_i2c");


Do we still have a dependency?

No carriage return at the end of the file.

The panel uses drm_panel_of_backlight() via phandle, so there is no hard module load dependency on viewe_bl_i2c. We will drop MODULE_SOFTDEP and add the missing trailing newline.

6by9 · 2026-10-22T17:52:06Z

+	if (!(jd_section_ready(ts->client) && !jd_resolve_coord_addr(ts))) {
+		if (!ts->coord_addr)
+			ts->coord_addr = JD_DEFAULT_COORD_ADDR;
+		if (!ts->touch_data_size)


How are you expecting this condition to ever be true? Line 272 says
ts->touch_data_size = JD_TOUCH_DATA_SIZE;
and probe has to have completed before poll has a chance to run.

You are right — that condition cannot become true after probe sets touch_data_size. It was left over from earlier bring-up. We will remove the dead path.

6by9 · 2026-10-22T17:53:40Z

 obj-$(CONFIG_TOUCHSCREEN_ILI210X)	+= ili210x.o
 obj-$(CONFIG_TOUCHSCREEN_ILITEK)	+= ilitek_ts_i2c.o
 obj-$(CONFIG_TOUCHSCREEN_ILITEK_V3)	+= ilitek_v3_ts_i2c.o
+obj-$(CONFIG_TOUCHSCREEN_JADARD_JD9365TX) += jadard_jd9365tx.o


Alphabetical order please

Will fix — place the entry in alphabetical order.

6by9 · 2026-10-22T17:53:59Z

 	  To compile this driver as a module, choose M here: the
 	  module will be called ilitek_v3_ts_i2c.

+config TOUCHSCREEN_JADARD_JD9365TX


Alphabetical order please.

Will fix — place the Kconfig entry in alphabetical order.

HF-2001 · 2026-10-26T08:16:45Z

Thanks for the further review.

Yes — we intend to submit the drivers and bindings upstream. We will prepare that once the remaining review comments here are addressed.

On JD9365TX vs the existing Jadard panel driver (panel-jadard-jd9365da-h3.c, JD9365DA family):

Different controller variant: JD9365TX vs JD9365DA
Different panel geometry: 720x1280 (VIEWE 7KF82) vs 800x1280 modules in that driver
Different DSI topology: 2-lane only here vs 4-lane there
Different init / gamma / lane-config sequences (our panel sets 2-lane via page0 0xCC=0x31)

So it is not a compatible drop-in for that driver; a separate panel description is needed.

We will update the series for the other inline comments (bindings cleanup, overlay nobl/backlight handling, remove prepared, backlight probe cleanup, touch dead path, Kconfig/Makefile ordering, etc.) and push again shortly.

HF-2001 · 2026-10-26T08:29:28Z

Pushed a follow-up commit addressing the latest review comments:

backlight binding: drop duplicate default-brightness (use common.yaml)
overlay: nobl also clears panel backlight phandle; touch uses jadard,jd9365tx + poll-interval
panel: DISPON delay #define, remove prepared flag and MODULE_SOFTDEP
backlight driver: fold I2C write into update_status; no probe-time write
touch: fix coord-addr fallback, hard-coded max points, Kconfig/Makefile order

Happy to adjust further if needed.

HF-2001 · 2026-10-26T08:34:59Z

Hi Dave, Thanks for the further review. Yes — we intend to submit the drivers and bindings upstream. We will prepare that once the remaining comments on this PR are sorted. On JD9365TX vs the existing Jadard panel driver (panel-jadard-jd9365da-h3.c, JD9365DA family): - different controller variant: JD9365TX vs JD9365DA - different geometry: 720x1280 (VIEWE 7KF82) vs 800x1280 modules in that driver - different DSI setup: 2-lane only here vs 4-lane there - different init / lane-config sequences (this panel sets 2-lane via page0 0xCC=0x31) So it is not a drop-in for that driver; a separate panel description is needed. We have also pushed a follow-up commit on the PR addressing your inline comments (bindings cleanup, overlay nobl/backlight handling, prepared/softdep removal, backlight probe cleanup, touch fallback, Kconfig/Makefile order). Happy to adjust further if needed. Best regards, Hefei Original From:6by9 ***@***.***> Sent Time:Oct 23, 2026 01:58 To:raspberrypi/linux ***@***.***> Cc:HF-2001 ***@***.***>, Author ***@***.***> Subject:Re: [raspberrypi/linux] drm/panel: add VIEWE 7 inch JD9365TX in-cell DSI panel (PR #7633) @6by9 commented on this pull request. I haven't reviewed the dtbindings in detail as the upstream maintainers deal with that. However vendor specific properties will have to be justified. I'd said last time And all the drivers and binding should be submitted upstream. Having drivers in this downstream kernel tree adds an undesirable maintenance burden. Upstream will give you a significantly more thorough review as well. Are you intending to submit upstream? And as per one of my review comments, what is different about JD9365TX vs JD9365A that already has a panel driver? In Documentation/devicetree/bindings/leds/backlight/viewe,i2c-backlight.yaml: > + +description: | +  Simple I2C backlight used on VIEWE DSI modules. Default protocol is device +  address 0x45, register 0x86, brightness 0..255. + +allOf: +  - $ref: common.yaml# + +properties: +  compatible: +    const: viewe,i2c-backlight + +  reg: +    maxItems: 1 + +  default-brightness: You've included common.yaml, so you shouldn't need to define default-brightness again. In arch/arm/boot/dts/overlays/vc4-kms-dsi-viewe-7inch-overlay.dts: > + __overlay__ { + status = "okay"; + }; + }; + + ***@***.*** { + target = <&i2c0mux>; + __overlay__ { + status = "okay"; + }; + }; + + __overrides__ { + rotation = <&panel>, "rotation:0"; + notouch = <&jadard_tp>, "status=disabled"; + nobl = <&viewe_bl>, "status=disabled"; Doesn't the backlight = <&viewe_bl>; line for the panel not need to be disabled too? (Question rather than statement) In drivers/gpu/drm/panel/panel-viewe-jd9365tx.c: > @@ -0,0 +1,390 @@ +// SPDX-License-Identifier: GPL-2.0 There is already a panel-jadard-jd9365a-h3.c panel driver in the tree (https://github.com/raspberrypi/linux/blob/rpi-6.18.y/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c) What's the difference with JD9365TX that makes it incompatible? In Documentation/devicetree/bindings/input/touchscreen/jadard,jd9365tx.yaml: > +  often exposes only I2C (no interrupt GPIO); the driver polls coordinate +  reports. + +allOf: +  - $ref: touchscreen.yaml# + +properties: +  compatible: +    enum: +      - jadard,jd9365tx +      - jadard,jd9365tx-tp + +  reg: +    maxItems: 1 + +  jadard,poll-interval-ms: input-common.yaml defines a standard poll-interval property. In Documentation/devicetree/bindings/input/touchscreen/jadard,jd9365tx.yaml: > + +properties: +  compatible: +    enum: +      - jadard,jd9365tx +      - jadard,jd9365tx-tp + +  reg: +    maxItems: 1 + +  jadard,poll-interval-ms: +    description: Polling interval in milliseconds (default 16) +    minimum: 8 +    maximum: 100 + +  jadard,max-touch-number: Is this really a configurable thing that can't be read back from the touch controller? In Documentation/devicetree/bindings/input/touchscreen/jadard,jd9365tx.yaml: > +maintainers: +  - Hefei ***@***.***> + +description: | +  In-cell touch integrated with Jadard JD9365TX DSI panels. The module FPC +  often exposes only I2C (no interrupt GPIO); the driver polls coordinate +  reports. + +allOf: +  - $ref: touchscreen.yaml# + +properties: +  compatible: +    enum: +      - jadard,jd9365tx +      - jadard,jd9365tx-tp Why the 2 compatibles? In drivers/gpu/drm/panel/panel-viewe-jd9365tx.c: > + if (ctx->reset) + gpiod_set_value_cansleep(ctx->reset, 1); + regulator_disable(ctx->vdd); + regulator_disable(ctx->iovcc); + return ret; +} + +static int jd9365tx_enable(struct drm_panel *panel) +{ + struct jd9365tx_panel *ctx = to_jd9365tx(panel); + int ret; + + ret = mipi_dsi_dcs_set_display_on(ctx->dsi); + if (ret) + dev_warn(&ctx->dsi->dev, "display on: %d\n", ret); + msleep(20); Seeing as you #defined values for JD9365TX_DISPOFF_DELAY_MS and JD9365TX_SLPIN_DELAY_MS in the disable path, why the raw values in the enable path? In drivers/gpu/drm/panel/panel-viewe-jd9365tx.c: > + +#include <drm/drm_mipi_dsi.h> +#include <drm/drm_modes.h> +#include <drm/drm_panel.h> + +#define JD9365TX_DISPOFF_DELAY_MS 80 +#define JD9365TX_SLPIN_DELAY_MS 200 + +struct jd9365tx_panel { + struct drm_panel panel; + struct mipi_dsi_device *dsi; + struct gpio_desc *reset; + struct regulator *vdd; + struct regulator *iovcc; + enum drm_panel_orientation orientation; + bool prepared; This shouldn't be necessary. The core already prevents this https://elixir.bootlin.com/linux/v6.18.57/source/drivers/gpu/drm/drm_panel.c#L122 https://elixir.bootlin.com/linux/v6.18.57/source/drivers/gpu/drm/drm_panel.c#L177 In drivers/video/backlight/viewe_bl_i2c.c: > + int ret; + + bl = devm_kzalloc(&client->dev, sizeof(*bl), GFP_KERNEL); + if (!bl) + return -ENOMEM; + + bl->client = client; + i2c_set_clientdata(client, bl); + + bl->bd = devm_backlight_device_register(&client->dev, "viewe_bl", + &client->dev, bl, &viewe_bl_ops, + &props); + if (IS_ERR(bl->bd)) + return PTR_ERR(bl->bd); + + ret = viewe_bl_write(client, VIEWE_BL_DEFAULT); Not needed as you've set brightness in the backlight_properties struct, which is documented as setting the default brightness https://elixir.bootlin.com/linux/v6.18.57/source/include/linux/backlight.h#L171 Based on that, viewe_bl_write may as well be merged into viewe_bl_update_status as it's the only place it is then called from. In drivers/gpu/drm/panel/panel-viewe-jd9365tx.c: > +MODULE_DEVICE_TABLE(of, jd9365tx_of_match); + +static struct mipi_dsi_driver jd9365tx_driver = { + .probe = jd9365tx_probe, + .remove = jd9365tx_remove, + .driver = { + .name = "panel-viewe-jd9365tx", + .of_match_table = jd9365tx_of_match, + }, +}; +module_mipi_dsi_driver(jd9365tx_driver); + +MODULE_AUTHOR("Hefei ***@***.***>"); +MODULE_DESCRIPTION("VIEWE 7\" JD9365TX MIPI-DSI panel"); +MODULE_LICENSE("GPL"); +MODULE_SOFTDEP("pre: viewe_bl_i2c"); Do we still have a dependency? No carriage return at the end of the file. In drivers/input/touchscreen/jadard_jd9365tx.c: > + return ret; + + ret = jd_get_chip_id(ts->client, &chip_id); + if (ret) + return ret; + + if (chip_id != JD_CHIP_ID && chip_id != JD_CHIP_ID_ALT && +    (chip_id == 0 || chip_id == 0xFFFF)) + return -ENODEV; + + jd_enter_backdoor(ts->client); + + if (!(jd_section_ready(ts->client) && !jd_resolve_coord_addr(ts))) { + if (!ts->coord_addr) + ts->coord_addr = JD_DEFAULT_COORD_ADDR; + if (!ts->touch_data_size) How are you expecting this condition to ever be true? Line 272 says ts->touch_data_size = JD_TOUCH_DATA_SIZE; and probe has to have completed before poll has a chance to run. In drivers/input/touchscreen/Makefile: > @@ -55,6 +55,7 @@ obj-$(CONFIG_TOUCHSCREEN_HYNITRON_CST816X) += hynitron-cst816x.o obj-$(CONFIG_TOUCHSCREEN_ILI210X) += ili210x.o obj-$(CONFIG_TOUCHSCREEN_ILITEK) += ilitek_ts_i2c.o obj-$(CONFIG_TOUCHSCREEN_ILITEK_V3) += ilitek_v3_ts_i2c.o +obj-$(CONFIG_TOUCHSCREEN_JADARD_JD9365TX) += jadard_jd9365tx.o Alphabetical order please In drivers/input/touchscreen/Kconfig: > @@ -528,6 +528,18 @@ config TOUCHSCREEN_ILITEK_V3  To compile this driver as a module, choose M here: the  module will be called ilitek_v3_ts_i2c. +config TOUCHSCREEN_JADARD_JD9365TX Alphabetical order please. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.

6by9

On JD9365TX vs the existing Jadard panel driver (panel-jadard-jd9365da-h3.c, JD9365DA family):

different controller variant: JD9365TX vs JD9365DA

different geometry: 720x1280 (VIEWE 7KF82) vs 800x1280 modules in that driver

different DSI setup: 2-lane only here vs 4-lane there

different init / lane-config sequences (this panel sets 2-lane via page0 0xCC=0x31)

So it is not a drop-in for that driver; a separate panel description is needed.

I can't find a datasheet for JD9365TX, hence asking these questions. You'll get exactly the same when you send it upstream.

You'll see from panel-ilitek-ili9881c that supporting multiple geometries and number of lanes isn't justification for not extending the existing driver.

The upstream version of the panel-jadard-jd9365da-h3.c (since kernel 7.2) has gained support for 2 and 4 lane modes, 720x1280, 600x1600, and 800x800 panels, and differing init sequences.
It does appear to use register 0x80 bit[1] to switch between 2 and 4 lane modes, so potentially it is different. The datasheet I've found for JD9365DA-H3 lists a DSI_INIT0 register with bit [0] switching modes, so that contradicts the driver. It also doesn't list which register DSI_INIT0 would correspond to.

The cleanups can't just be dumped into one big lump. They should be merged back into the relevant patches that had the issue.

6by9 · 2026-10-26T16:24:37Z


+Name:   vc4-kms-dsi-viewe-7inch
+Info:   Enable the VIEWE 7" 720x1280 JD9365TX in-cell DSI panel.
+        2-lane, DSI1 + i2c_csi_dsi (Pi 3/4/5).


Is there a reason it doesn't work on Pi1, or by implication Compute Modules?

No hardware reason known against Pi 1 / Compute Modules that expose DSI + i2c_csi_dsi — we only listed Pi 3/4/5 because that is what we tested. We asked in the main thread whether you want full MIPI-capable Pi / CM coverage before we update the README wording.

Add the device tree binding for the VIEWE 7KF82 720x1280 Jadard JD9365TX MIPI-DSI panel. Signed-off-by: Hefei <3066883572@qq.com>

Add the binding for the Jadard JD9365TX in-cell touchscreen used on the VIEWE 7KF82 module. Signed-off-by: Hefei <3066883572@qq.com>

Add the binding for the VIEWE panel backlight MCU on I2C. Signed-off-by: Hefei <3066883572@qq.com>

Add a DRM MIPI-DSI panel driver for the VIEWE 7KF82 module based on Jadard JD9365TX (2-lane video mode). Signed-off-by: Hefei <3066883572@qq.com>

Add a polling I2C touchscreen driver for Jadard JD9365TX in-cell panels that do not wire an interrupt line on the FPC. Signed-off-by: Hefei <3066883572@qq.com>

Add a simple I2C backlight class driver for the VIEWE panel MCU at address 0x45, register 0x86. Signed-off-by: Hefei <3066883572@qq.com>

Enable the VIEWE panel, touch and backlight drivers as modules in the Raspberry Pi bcm2711 and bcm2712 defconfigs. Signed-off-by: Hefei <3066883572@qq.com>

Add a dtoverlay for the VIEWE 7 inch JD9365TX panel on DSI1 using i2c_csi_dsi for touch and backlight. Signed-off-by: Hefei <3066883572@qq.com>

HF-2001 · 2026-10-27T07:13:21Z

Thanks for the follow-up.

On folding into panel-jadard-jd9365da-h3: we looked at that driver (including the newer upstream version with 2/4-lane and 720x1280 variants). The DRM structure is similar (per-module desc + init), but the programming model does not match this panel:

page select is 0xDE here, vs 0xE0 on JD9365DA
bring-up unlock is 0xDF/0x90/0x84/0x14, vs the DA 0xE1/0xE2/0xE3 sequence
lane config is page0 0xCC (0x31 for 2-lane), vs DA register 0x80
the rest of the init table is a different register map

So this is not just another geometry/lane combo on the same controller interface. We do not have a public JD9365TX datasheet to hand either; if you still prefer extending the DA driver despite that command-set difference, please say so and we will rework it that way.

On the patch series: the previous single cleanup commit has been folded back into the relevant patches and force-pushed (still the same 8-way split).

On the README "Pi 3/4/5" wording: we only tested on Pi 4 and Pi 5. Would you like us to validate on every Raspberry Pi platform that can drive a MIPI DSI panel (Pi 1 / earlier boards where applicable, and Compute Modules), or is coverage of the current DSI-capable products you care about enough? Happy to widen testing if that is what you need.

6by9 requested changes Sep 22, 2026

View reviewed changes

HF-2001 force-pushed the viewe-7inch-jd9365tx branch from 48f2e04 to d9149a0 Compare September 28, 2026 06:03

6by9 reviewed Oct 22, 2026

View reviewed changes

6by9 reviewed Oct 26, 2026

View reviewed changes

HF-2001 added 8 commits October 27, 2026 15:12

dt-bindings: display: add VIEWE JD9365TX panel binding

c34d866

Add the device tree binding for the VIEWE 7KF82 720x1280 Jadard JD9365TX MIPI-DSI panel. Signed-off-by: Hefei <3066883572@qq.com>

dt-bindings: input: add Jadard JD9365TX touchscreen binding

b0d3a78

Add the binding for the Jadard JD9365TX in-cell touchscreen used on the VIEWE 7KF82 module. Signed-off-by: Hefei <3066883572@qq.com>

dt-bindings: backlight: add VIEWE I2C backlight binding

70fbb48

Add the binding for the VIEWE panel backlight MCU on I2C. Signed-off-by: Hefei <3066883572@qq.com>

drm/panel: add VIEWE JD9365TX 7 inch DSI panel

34d6038

Add a DRM MIPI-DSI panel driver for the VIEWE 7KF82 module based on Jadard JD9365TX (2-lane video mode). Signed-off-by: Hefei <3066883572@qq.com>

Input: add Jadard JD9365TX in-cell touchscreen driver

deda790

Add a polling I2C touchscreen driver for Jadard JD9365TX in-cell panels that do not wire an interrupt line on the FPC. Signed-off-by: Hefei <3066883572@qq.com>

backlight: add VIEWE I2C backlight driver

4ea30fd

Add a simple I2C backlight class driver for the VIEWE panel MCU at address 0x45, register 0x86. Signed-off-by: Hefei <3066883572@qq.com>

configs: enable VIEWE 7inch panel drivers

2c24e3b

Enable the VIEWE panel, touch and backlight drivers as modules in the Raspberry Pi bcm2711 and bcm2712 defconfigs. Signed-off-by: Hefei <3066883572@qq.com>

overlays: add vc4-kms-dsi-viewe-7inch

1932bd4

Add a dtoverlay for the VIEWE 7 inch JD9365TX panel on DSI1 using i2c_csi_dsi for touch and backlight. Signed-off-by: Hefei <3066883572@qq.com>

HF-2001 force-pushed the viewe-7inch-jd9365tx branch from 0ad7783 to 1932bd4 Compare October 27, 2026 07:12

Conversation

HF-2001 commented Sep 18, 2026

Uh oh!

6by9 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

6by9 commented Sep 22, 2026

Uh oh!

HF-2001 commented Sep 23, 2026 via email

Uh oh!

HF-2001 commented Sep 28, 2026

Uh oh!

HF-2001 commented Oct 21, 2026

Uh oh!

6by9 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HF-2001 commented Oct 26, 2026

Uh oh!

HF-2001 commented Oct 26, 2026