6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11234
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Rpi 4 with DRM and 7inch panel using kms driver

Wed May 05, 2021 5:19 pm

aBUGSworstnightmare wrote:
Wed May 05, 2021 4:52 pm
What does an overlay have to look like for this driver? Whatever I try is not working and just gives trash on the panel.
I'm just having a quick look. The bindings should tell you.
DSI needs to come in on port@0 / reg = <0>;
LVDS output is on port@2 / reg = <2>;
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

aBUGSworstnightmare
Posts: 2915
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Wed May 05, 2021 5:28 pm

6by9 wrote:
Wed May 05, 2021 5:19 pm
aBUGSworstnightmare wrote:
Wed May 05, 2021 4:52 pm
What does an overlay have to look like for this driver? Whatever I try is not working and just gives trash on the panel.
I'm just having a quick look. The bindings should tell you.
DSI needs to come in on port@0 / reg = <0>;
LVDS output is on port@2 / reg = <2>;
thanks, that's clear from the bindings. Where I struggle is how to add the panel (which is in panel-simple as previously) and what needs to be in the DSI fragment. What I try is to have a overlay similiar to the 7in DSI panel, so it's more easy to follow what is going on (and I'm using the old one as template)

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11234
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Rpi 4 with DRM and 7inch panel using kms driver

Wed May 05, 2021 5:33 pm

6by9 wrote:
Wed May 05, 2021 5:19 pm
aBUGSworstnightmare wrote:
Wed May 05, 2021 4:52 pm
What does an overlay have to look like for this driver? Whatever I try is not working and just gives trash on the panel.
I'm just having a quick look. The bindings should tell you.
DSI needs to come in on port@0 / reg = <0>;
LVDS output is on port@2 / reg = <2>;
The DSI input's endpoint also needs the info on number of data-lanes.
FWIW port@1 is for the second DSI input, and port@3 is for the dual-link LVDS output.

Code: Select all

/*
 * vc4-kms-dsi-sn65dsi8x-overlay.dts
 */

/dts-v1/;
/plugin/;
#include <dt-bindings/gpio/gpio.h>

/ {
	compatible = "brcm,bcm2835";

	/* PWM0 function */
	fragment@0 {
		target = <&gpio>;
		__overlay__ {
			pwm_pins: pwm_pins {
				brcm,pins = <12>;
				brcm,function = <4>; /* Alt1 */
			};
		};
	};

	fragment@1 {
		target = <&pwm>;
		frag1: __overlay__ {
			pinctrl-names = "default";
			pinctrl-0 = <&pwm_pins>;
			assigned-clock-rates = <100000000>;
			status = "okay";
		};
	};

	fragment@2 {
		target-path = "/";
		__overlay__ {
			//#gpio-cells = <2>;
			/* Panel backlight through PWM0 on GPIO 12 */
			backlight_lvds: backlight {
				compatible = "pwm-backlight";
				pwms = <&pwm 0 5000000>; /* Period of 5000000ns means 200Hz */
				brightness-levels = <0  1000>;
				num-interpolated-steps = <1000>;
				default-brightness-level = <800>;
				enable-gpios = <&gpio 17 0>; /* Backlight enable... */
			};

			panel: panel {
				compatible = "chunghwa,claa070wp03xglvds", "simple-panel";
				backlight = <&backlight_lvds>;

				port {
					panel_in_lvds: endpoint {
						remote-endpoint = <&bridge_out>;
					};
				};
			};
		};
	};

	fragment@3 {
		target = <&i2c_csi_dsi>;
		__overlay__ {
			#gpio-cells = <2>;
			#address-cells = <1>;
			#size-cells = <0>;
			status = "okay";

			bridge@2c {
				compatible = "ti,sn65dsi83";
				reg = <0x2c>;
				enable-gpios = <&gpio 4 0>;

				ports {
					#address-cells = <1>;
					#size-cells = <0>;

					port@0 {
						reg = <0>;
						bridge_in: endpoint {
							remote-endpoint = <&dsi_out_port>;
							data-lanes = <0 1 2 3>;
						};
					};

					port@2 {
						reg = <2>;
						bridge_out: endpoint {
							remote-endpoint = <&panel_in_lvds>;
						};
					};
				};
			};
		};
	};

	fragment@4 {
		target = <&dsi1>;
		__overlay__ {
			#address-cells = <1>;
			#size-cells = <0>;
			status = "okay";
			port {
				dsi_out_port: endpoint {
					remote-endpoint = <&bridge_in>;
					data-lanes = <0 1 2 3>;
				};
			};
		};
	};

	fragment@5 {
		target = <&i2c0if>;
		__overlay__ {
			status = "okay";
		};
	};
		
	fragment@6 {
		target = <&i2c0mux>;
		__overlay__ {
			status = "okay";
		};
	};
};
Has just loaded for me, and modetest reports everything as I expected.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

aBUGSworstnightmare
Posts: 2915
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Wed May 05, 2021 7:13 pm

WTF! Sorry, but I had - nearly - exactly this, but I missed the 'connector' (sorry, didn't even know if that's the right term) to the endpoint, means instead of i.e.

Code: Select all

 port@2 {
						reg = <2>;
						bridge_out: endpoint {
							remote-endpoint = <&panel_in_lvds>;
						};
					};  
I only had

Code: Select all

 port@2 {
						reg = <2>;
						endpoint {
							remote-endpoint = <&panel_in_lvds>;
						}; hi
					};  
hence I struggeled how this connects to the 'bridge_out' from the panel

Code: Select all

  panel: panel {
				compatible = "chunghwa,claa070wp03xglvds", "simple-panel";
				backlight = <&backlight_lvds>;

				port {
					panel_in_lvds: endpoint {
						remote-endpoint = <&bridge_out>;
					};
				};
			}; 
sorry, could have known but these overlays are still "Nothing works" (note that I'm quoting Mr CATWEAZLE) .. or for those who do not know what I'm talking about let me just say 'a kind of magic'

The overlay loads fine, LVDS-1 get's created but I need to dig into the code as I have a JEIDA panel and need to check the DSI8x FORMAT bits if they are correct. Will do that tomorrow..
The other jig gets a different panel with VESA mapping tomorrow morning as that one uses the Nexus7 Gen1 atm too.
Last edited by aBUGSworstnightmare on Sun May 09, 2021 5:40 am, edited 1 time in total.

aBUGSworstnightmare
Posts: 2915
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Thu May 06, 2021 7:02 am

6by9 wrote:
Wed May 05, 2021 1:10 pm
Marek sent a v3 earlier this morning, and both patches have just got a Reviewed-by.
Unless there's any bikeshedding, then that's likely to get merged.
https://patchwork.freedesktop.org/series/89801/
The driver is not working (at least so far) here on my end.
One critical failure which I've discovered so far is in the register definitions

Code: Select all

#define REG_DSI_LANE				0x10
#define  REG_DSI_LANE_LVDS_LINK_CFG_DUAL	BIT(5) /* dual or 2x single */
#define  REG_DSI_LANE_CHA_DSI_LANES(n)		(((n) & 0x3) << 3)
#define  REG_DSI_LANE_CHB_DSI_LANES(n)		(((n) & 0x3) << 1)
#define  REG_DSI_LANE_SOT_ERR_TOL_DIS		BIT(0)
The definition for register 0x10 is incorrect for BIT5! The LVDS_LINK_CFG bit is part of CSR 0x18 (BIT4) and not of CSR 0x10.

Definition should be changed to

Code: Select all

#define REG_DSI_LANE	0x10
#define  REG_DSI_LANE_L_R_PIXELS                BIT(7)
#define  REG_DSI_LANE_CHANNEL_MODE(n)		(((n) & 0x3) << 5) /* 01: Single channel DSI receiver (default) */
#define  REG_DSI_LANE_CHA_DSI_LANES(n)		(((n) & 0x3) << 3)
#define  REG_DSI_LANE_CHB_DSI_LANES(n)		(((n) & 0x3) << 1)
#define  REG_DSI_LANE_SOT_ERR_TOL_DIS		BIT(0)
and when it gets initialized it needs to be changed to

Code: Select all

	/* Set number of DSI lanes and link config. */
	regmap_write(ctx->regmap, REG_DSI_LANE,
		REG_DSI_LANE_CHANNEL_MODE(1) |
		REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)) |
		/* CHB is DSI85-only, set to default on DSI83/DSI84 */
		REG_DSI_LANE_CHB_DSI_LANES(3));
SN65DSI85 - CSR 0x10.jpg
CSR 0x10 from DSI85 data sheet
SN65DSI85 - CSR 0x10.jpg (96.98 KiB) Viewed 1255 times
will have to investigate further...

edit:
what I see is that pre-enable get's called twice which will cause issues:

Code: Select all

pi@raspberrypi:~ $ dmesg | grep dsi
[    6.493785] vc4-drm gpu: bound fe700000.dsi (ops vc4_dsi_ops [vc4])
[    6.539033] sn65dsi83 10-002c: pre-enable
[    6.561135] sn65dsi83 10-002c: EN HIGH
[    6.561952] sn65dsi83 10-002c: SOFT_RESET, PLL_EN LOW
[   13.243145] sn65dsi83 10-002c: pre-enable
[   13.264361] sn65dsi83 10-002c: EN HIGH
[   13.265065] sn65dsi83 10-002c: SOFT_RESET, PLL_EN LOW
pi@raspberrypi:~ $ 
which comes from here

Code: Select all

static void sn65dsi83_pre_enable(struct drm_bridge *bridge)
{
	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);

	/*
	 * Reset the chip, pull EN line low for t_reset=10ms,
	 * then high for t_en=10ms.
	 */
	dev_info(ctx->dev, "pre-enable\n"); 
	regcache_mark_dirty(ctx->regmap);
	gpiod_set_value(ctx->enable_gpio, 0);
	usleep_range(10000, 11000);
	gpiod_set_value(ctx->enable_gpio, 1);
	usleep_range(10000, 11000);
	dev_info(ctx->dev, "EN HIGH\n");
	/* Clear reset, disable PLL */
	regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
	regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
	dev_info(ctx->dev, "SOFT_RESET, PLL_EN LOW\n");
}

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11234
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Rpi 4 with DRM and 7inch panel using kms driver

Thu May 06, 2021 8:02 am

aBUGSworstnightmare wrote:
Thu May 06, 2021 7:02 am
One critical failure which I've discovered so far is in the register definitions

Code: Select all

#define REG_DSI_LANE				0x10
#define  REG_DSI_LANE_LVDS_LINK_CFG_DUAL	BIT(5) /* dual or 2x single */
#define  REG_DSI_LANE_CHA_DSI_LANES(n)		(((n) & 0x3) << 3)
#define  REG_DSI_LANE_CHB_DSI_LANES(n)		(((n) & 0x3) << 1)
#define  REG_DSI_LANE_SOT_ERR_TOL_DIS		BIT(0)
The definition for register 0x10 is incorrect for BIT5! The LVDS_LINK_CFG bit is part of CSR 0x18 (BIT4) and not of CSR 0x10.

Definition should be changed to

Code: Select all

#define REG_DSI_LANE	0x10
#define  REG_DSI_LANE_L_R_PIXELS                BIT(7)
#define  REG_DSI_LANE_CHANNEL_MODE(n)		(((n) & 0x3) << 5) /* 01: Single channel DSI receiver (default) */
#define  REG_DSI_LANE_CHA_DSI_LANES(n)		(((n) & 0x3) << 3)
#define  REG_DSI_LANE_CHB_DSI_LANES(n)		(((n) & 0x3) << 1)
#define  REG_DSI_LANE_SOT_ERR_TOL_DIS		BIT(0)
and when it gets initialized it needs to be changed to

Code: Select all

	/* Set number of DSI lanes and link config. */
	regmap_write(ctx->regmap, REG_DSI_LANE,
		REG_DSI_LANE_CHANNEL_MODE(1) |
		REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)) |
		/* CHB is DSI85-only, set to default on DSI83/DSI84 */
		REG_DSI_LANE_CHB_DSI_LANES(3));
SN65DSI85 - CSR 0x10.jpg
will have to investigate further...
Yes the define looks to be oddly named as it has no effect on LVDS, but as the supported modes specifically exclude dual DSI, the usage is fine.
edit:
what I see is that pre-enable get's called twice which will cause issues:

Code: Select all

pi@raspberrypi:~ $ dmesg | grep dsi
[    6.493785] vc4-drm gpu: bound fe700000.dsi (ops vc4_dsi_ops [vc4])
[    6.539033] sn65dsi83 10-002c: pre-enable
[    6.561135] sn65dsi83 10-002c: EN HIGH
[    6.561952] sn65dsi83 10-002c: SOFT_RESET, PLL_EN LOW
[   13.243145] sn65dsi83 10-002c: pre-enable
[   13.264361] sn65dsi83 10-002c: EN HIGH
[   13.265065] sn65dsi83 10-002c: SOFT_RESET, PLL_EN LOW
pi@raspberrypi:~ $ 
which comes from here

Code: Select all

static void sn65dsi83_pre_enable(struct drm_bridge *bridge)
{
	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);

	/*
	 * Reset the chip, pull EN line low for t_reset=10ms,
	 * then high for t_en=10ms.
	 */
	dev_info(ctx->dev, "pre-enable\n"); 
	regcache_mark_dirty(ctx->regmap);
	gpiod_set_value(ctx->enable_gpio, 0);
	usleep_range(10000, 11000);
	gpiod_set_value(ctx->enable_gpio, 1);
	usleep_range(10000, 11000);
	dev_info(ctx->dev, "EN HIGH\n");
	/* Clear reset, disable PLL */
	regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
	regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
	dev_info(ctx->dev, "SOFT_RESET, PLL_EN LOW\n");
}
Are you sure there isn't an enable, disable, and post-disable between them? They are separated by nearly 7 seconds in your logs, so I'd guess one is KMS loading, and the other is X starting.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11234
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Rpi 4 with DRM and 7inch panel using kms driver

Thu May 06, 2021 8:07 am

And actually the SN65DSI84 datasheet lists those fields as
Reserved - Do not write to this field. Must remain at default.
How you don't write to 2 bits within a byte when all access is byte-wise is a slight quirk with their wording.
Same for bit 7.

The intro description does say

Code: Select all

+ * - SN65DSI85
+ *   = 2x Single-link or 1x Dual-link DSI ~ 2x Single-link or 1x Dual-link LVDS
+ *   - Unsupported
+ *     (should be easy to add by someone who has the HW)
and has no compatible string, so overall it is all good.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

aBUGSworstnightmare
Posts: 2915
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Thu May 06, 2021 9:06 am

One needs to look at DSI85 data sheet as well, all other devices (83/84) are subsets with I/O not bonded/tested
Yes, default is BIT5 = 1

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11234
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Rpi 4 with DRM and 7inch panel using kms driver

Thu May 06, 2021 9:16 am

aBUGSworstnightmare wrote:
Thu May 06, 2021 9:06 am
One needs to look at DSI85 data sheet as well, all other devices (83/84) are subsets with I/O not bonded/tested
Yes, default is BIT5 = 1
Functionally it is correct and will work on all chips for the supported modes.
I will respond to Marek's patches over the t_en timeout, query this define name, and also point out some checkpatch warnings on alignment.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

aBUGSworstnightmare
Posts: 2915
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Thu May 06, 2021 9:36 am

6by9 wrote:
Thu May 06, 2021 9:16 am
aBUGSworstnightmare wrote:
Thu May 06, 2021 9:06 am
One needs to look at DSI85 data sheet as well, all other devices (83/84) are subsets with I/O not bonded/tested
Yes, default is BIT5 = 1
Functionally it is correct and will work on all chips for the supported modes.
I will respond to Marek's patches over the t_en timeout, query this define name, and also point out some checkpatch warnings on alignment.
Let me know if you want me to run another test.
I will connect a different panel today to see how this behaves (Vesa mapping) as both jigs show different behaviors here (fully identical setup in regards of HW and SW) to rule out an HW issue on the bridge board.

Sure, both will work as they relay on the default settings. But then either omitt all reserved registers or configure them in total.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11234
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Rpi 4 with DRM and 7inch panel using kms driver

Thu May 06, 2021 10:36 am

You can read my comments to Marek at https://patchwork.freedesktop.org/patch ... ent_775152
Yes it is incorrect, but it's not a critical error as the net result is the same.

I've switched to a new branch as I had other changes on the one I was working, and X wasn't starting. Now of course my sn65dsi83 overlay isn't loading (it isn't finding the panel on port@2).
I've pushed the changes to https://github.com/6by9/linux/tree/rpi- ... si8x-marek should you wish to have a look, and it includes a speculative patch that changes when DSI_DISP0_ENABLE in DISP0_CTRL gets set cf pre_enable & enable. With that and/or moving all the active code from sn65dsi83_enable to sn65dsi83_pre_enable I'd hope something might start working. I need to head out for a couple of hours so can't take it further right this minute.
...
Ah, I'd forgotten to enable BACKLIGHT_PWM as a module. Add that in (as well as DRM_TI_SN65DSI83) and it loads.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

aBUGSworstnightmare
Posts: 2915
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Thu May 06, 2021 10:43 am

6by9 wrote:
Thu May 06, 2021 10:36 am
You can read my comments to Marek at https://patchwork.freedesktop.org/patch ... ent_775152
Yes it is incorrect, but it's not a critical error as the net result is the same.

I've switched to a new branch as I had other changes on the one I was working, and X wasn't starting. Now of course my sn65dsi83 overlay isn't loading (it isn't finding the panel on port@2).
I've pushed the changes to https://github.com/6by9/linux/tree/rpi- ... si8x-marek should you wish to have a look, and it includes a speculative patch that changes when DSI_DISP0_ENABLE in DISP0_CTRL gets set cf pre_enable & enable. With that and/or moving all the active code from sn65dsi83_enable to sn65dsi83_pre_enable I'd hope something might start working. I need to head out for a couple of hours so can't take it further right this minute.
...
Ah, I'd forgotten to enable BACKLIGHT_PWM as a module. Add that in (as well as DRM_TI_SN65DSI83) and it loads.
will check .. Give me some to come back ..

EDIT: here's first feedback:
- runs pre-enable/enable twice as well --> risk for issues with DSI lane state for the second turn
- no display (but might be related to driver in regards of LVDS settings)

Code: Select all

pi@raspberrypi:~ $ dmesg | grep dsi
[    6.596748] sn65dsi83 10-002c: sn65dsi83_attach
[    6.596920] sn65dsi83 10-002c: sn65dsi83_attach - looking good
[    6.597068] vc4-drm gpu: bound fe700000.dsi (ops vc4_dsi_ops [vc4])
[    6.619260] [drm:sn65dsi83_pre_enable [ti_sn65dsi83]] *ERROR* sn65dsi83_pre_enable
[    6.631462] [drm:sn65dsi83_enable [ti_sn65dsi83]] *ERROR* sn65dsi83_enable
[   13.034167] [drm:sn65dsi83_disable [ti_sn65dsi83]] *ERROR* sn65dsi83_disable
[   13.054546] [drm:sn65dsi83_post_disable [ti_sn65dsi83]] *ERROR* sn65dsi83_post_disable
[   13.102688] [drm:sn65dsi83_pre_enable [ti_sn65dsi83]] *ERROR* sn65dsi83_pre_enable
[   13.114825] [drm:sn65dsi83_enable [ti_sn65dsi83]] *ERROR* sn65dsi83_enable
pi@raspberrypi:~ $ dmesg | grep vc4
[    5.400428] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    5.478727] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[    5.478959] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
[    5.487952] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present!
[    5.511459] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    5.513047] rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[    5.513276] input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input1
[    5.514277] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' already present!
[    5.531228] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    5.826053] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    5.844998] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[    5.845229] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input2
[    5.846046] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present!
[    5.850808] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    5.874541] rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[    5.874761] input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input3
[    5.875601] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' already present!
[    5.877636] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    6.154677] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    6.171234] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[    6.171461] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input4
[    6.172303] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present!
[    6.174067] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    6.176153] rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[    6.176404] input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input5
[    6.177229] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' already present!
[    6.179489] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    6.566623] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    6.572843] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[    6.573070] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input6
[    6.580495] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present!
[    6.582464] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    6.588273] rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[    6.588497] input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input7
[    6.589344] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' already present!
[    6.595472] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    6.597068] vc4-drm gpu: bound fe700000.dsi (ops vc4_dsi_ops [vc4])
[    6.597457] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[    6.597781] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.598111] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.598401] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.598655] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.598960] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.606734] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[    6.917421] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
[   16.942259] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   16.942687] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   16.943345] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   18.111037] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   18.111585] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   18.113163] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   18.113366] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   18.215241] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   18.215686] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   18.216547] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   18.269509] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   18.270239] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   18.271927] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   18.272208] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
pi@raspberrypi:~ $ 
xrandr shows positive HSYNC and VSYNC where is should be negative (at least that's what we tell it in 'panel-simple'

Code: Select all

pi@raspberrypi:~ $ xrandr --verbose
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 7680 x 7680
HDMI-1 disconnected primary (normal left inverted right x axis y axis)
	Identifier: 0x45
	Timestamp:  13094
	Subpixel:   unknown
	Clones:    
	CRTCs:      3
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	max bpc: 8 
		range: (8, 12)
	bottom margin: 0 
		range: (0, 100)
	top margin: 0 
		range: (0, 100)
	right margin: 0 
		range: (0, 100)
	left margin: 0 
		range: (0, 100)
	Colorspace: Default 
		supported: Default, SMPTE_170M_YCC, BT709_YCC, XVYCC_601, XVYCC_709, SYCC_601, opYCC_601, opRGB, BT2020_CYCC, BT2020_RGB, BT2020_YCC, DCI-P3_RGB_D65, DCI-P3_RGB_Theater
	link-status: Good 
		supported: Good, Bad
	CONNECTOR_ID: 32 
		supported: 32
	non-desktop: 0 
		range: (0, 1)
  1920x1080_vnc (0x369) 125.498MHz
        h: width  1920 start 1922 end 1924 total 1926 skew    0 clock  65.16KHz
        v: height 1080 start 1082 end 1084 total 1086           clock  60.00Hz
HDMI-2 disconnected (normal left inverted right x axis y axis)
	Identifier: 0x46
	Timestamp:  13094
	Subpixel:   unknown
	Clones:    
	CRTCs:      4
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	max bpc: 8 
		range: (8, 12)
	bottom margin: 0 
		range: (0, 100)
	top margin: 0 
		range: (0, 100)
	right margin: 0 
		range: (0, 100)
	left margin: 0 
		range: (0, 100)
	Colorspace: Default 
		supported: Default, SMPTE_170M_YCC, BT709_YCC, XVYCC_601, XVYCC_709, SYCC_601, opYCC_601, opRGB, BT2020_CYCC, BT2020_RGB, BT2020_YCC, DCI-P3_RGB_D65, DCI-P3_RGB_Theater
	link-status: Good 
		supported: Good, Bad
	CONNECTOR_ID: 40 
		supported: 40
	non-desktop: 0 
		range: (0, 1)
  1920x1080_vnc (0x369) 125.498MHz
        h: width  1920 start 1922 end 1924 total 1926 skew    0 clock  65.16KHz
        v: height 1080 start 1082 end 1084 total 1086           clock  60.00Hz
LVDS-1 connected 1280x800+0+0 (0x49) right (normal left inverted right x axis y axis) 0mm x 0mm
	Identifier: 0x47
	Timestamp:  13094
	Subpixel:   unknown
	Gamma:      1.0:1.0:1.0
	Brightness: 1.0
	Clones:    
	CRTC:       2
	CRTCs:      2
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	link-status: Good 
		supported: Good, Bad
	CONNECTOR_ID: 44 
		supported: 44
	non-desktop: 0 
		range: (0, 1)
  800x1280 (0x49) 66.800MHz +HSync +VSync *current +preferred
        h: width   800 start  816 end  832 total  864 skew    0 clock  77.31KHz
        v: height 1280 start 1285 end 1286 total 1288           clock  60.03Hz
  1920x1080_vnc (0x369) 125.498MHz
        h: width  1920 start 1922 end 1924 total 1926 skew    0 clock  65.16KHz
        v: height 1080 start 1082 end 1084 total 1086           clock  60.00Hz
pi@raspberrypi:~ $ 

Code: Select all

static const struct display_timing chunghwa_claa070wp03xglvds_timing = {
	.pixelclock = { 66800000, 66800000, 66800000 },
	.hactive = { 800, 800, 800 },
	.hfront_porch = { 16, 16, 16 },
	.hback_porch = { 32, 32, 32 },
	.hsync_len = { 16, 16, 16 },
	.vactive = { 1280, 1280, 1280 },
	.vfront_porch = { 5, 5, 5 },
	.vback_porch = { 2, 2, 2 },
	.vsync_len = { 1, 1, 1 },
	.flags = DRM_MODE_FLAG_NHSYNC |
		 DRM_MODE_FLAG_NVSYNC |
		 DISPLAY_FLAGS_DE_HIGH,
};

static const struct panel_desc chunghwa_claa070wp03xglvds = {
	.timings = &chunghwa_claa070wp03xglvds_timing,
	.num_timings = 1,
	.bpc = 8,
	.size = {
		.width = 94,
		.height = 150,
	},
	.delay = {
		.enable = 200,
		.disable = 110,
	},
	.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
	.bus_flags = DRM_BUS_FLAG_DE_HIGH,
	.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
What causes the second enable of the driver? Can this be avoided by changing the delays (se above)?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11234
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Rpi 4 with DRM and 7inch panel using kms driver

Thu May 06, 2021 5:12 pm

aBUGSworstnightmare wrote:
Thu May 06, 2021 10:43 am
xrandr shows positive HSYNC and VSYNC where is should be negative (at least that's what we tell it in 'panel-simple'

Code: Select all

pi@raspberrypi:~ $ xrandr --verbose
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 7680 x 7680
HDMI-1 disconnected primary (normal left inverted right x axis y axis)
	Identifier: 0x45
	Timestamp:  13094
	Subpixel:   unknown
	Clones:    
	CRTCs:      3
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	max bpc: 8 
		range: (8, 12)
	bottom margin: 0 
		range: (0, 100)
	top margin: 0 
		range: (0, 100)
	right margin: 0 
		range: (0, 100)
	left margin: 0 
		range: (0, 100)
	Colorspace: Default 
		supported: Default, SMPTE_170M_YCC, BT709_YCC, XVYCC_601, XVYCC_709, SYCC_601, opYCC_601, opRGB, BT2020_CYCC, BT2020_RGB, BT2020_YCC, DCI-P3_RGB_D65, DCI-P3_RGB_Theater
	link-status: Good 
		supported: Good, Bad
	CONNECTOR_ID: 32 
		supported: 32
	non-desktop: 0 
		range: (0, 1)
  1920x1080_vnc (0x369) 125.498MHz
        h: width  1920 start 1922 end 1924 total 1926 skew    0 clock  65.16KHz
        v: height 1080 start 1082 end 1084 total 1086           clock  60.00Hz
HDMI-2 disconnected (normal left inverted right x axis y axis)
	Identifier: 0x46
	Timestamp:  13094
	Subpixel:   unknown
	Clones:    
	CRTCs:      4
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	max bpc: 8 
		range: (8, 12)
	bottom margin: 0 
		range: (0, 100)
	top margin: 0 
		range: (0, 100)
	right margin: 0 
		range: (0, 100)
	left margin: 0 
		range: (0, 100)
	Colorspace: Default 
		supported: Default, SMPTE_170M_YCC, BT709_YCC, XVYCC_601, XVYCC_709, SYCC_601, opYCC_601, opRGB, BT2020_CYCC, BT2020_RGB, BT2020_YCC, DCI-P3_RGB_D65, DCI-P3_RGB_Theater
	link-status: Good 
		supported: Good, Bad
	CONNECTOR_ID: 40 
		supported: 40
	non-desktop: 0 
		range: (0, 1)
  1920x1080_vnc (0x369) 125.498MHz
        h: width  1920 start 1922 end 1924 total 1926 skew    0 clock  65.16KHz
        v: height 1080 start 1082 end 1084 total 1086           clock  60.00Hz
LVDS-1 connected 1280x800+0+0 (0x49) right (normal left inverted right x axis y axis) 0mm x 0mm
	Identifier: 0x47
	Timestamp:  13094
	Subpixel:   unknown
	Gamma:      1.0:1.0:1.0
	Brightness: 1.0
	Clones:    
	CRTC:       2
	CRTCs:      2
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	link-status: Good 
		supported: Good, Bad
	CONNECTOR_ID: 44 
		supported: 44
	non-desktop: 0 
		range: (0, 1)
  800x1280 (0x49) 66.800MHz +HSync +VSync *current +preferred
        h: width   800 start  816 end  832 total  864 skew    0 clock  77.31KHz
        v: height 1280 start 1285 end 1286 total 1288           clock  60.03Hz
  1920x1080_vnc (0x369) 125.498MHz
        h: width  1920 start 1922 end 1924 total 1926 skew    0 clock  65.16KHz
        v: height 1080 start 1082 end 1084 total 1086           clock  60.00Hz
pi@raspberrypi:~ $ 
It doesn't matter. DSI has sync packets/events rather than a physical line with a polarity.
What causes the second enable of the driver? Can this be avoided by changing the delays (se above)?
viewtopic.php?p=1861240#p1861240
Are you sure there isn't an enable, disable, and post-disable between them? They are separated by nearly 7 seconds in your logs, so I'd guess one is KMS loading, and the other is X starting.
X will fire off an xrandr config during initialisation to put all the displays in the positions they are meant to be, and I wouldn't be surprised if that resulted in all displays being disabled and reenabled.
Confirm by booting to the console instead of X (assuming you aren't already).

FYI There is discussion over VESA vs JEIDA formats on dri-devel with further changes probably coming. https://lists.freedesktop.org/archives/ ... 05776.html
Interesting that they are having issues with 4 lane mode, but working in 2. When dealing with RGB888 (24bpp) dividing it over 4 lanes rarely divides evenly, and the handling of that inequal division can be a right pain in the neck.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

aBUGSworstnightmare
Posts: 2915
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Thu May 06, 2021 6:52 pm

changed the overlay to dual lane DSI --> booting takes ages.

Added another panel to panel-simple, testing both formats (MEDIA_BUS_FMT_RGB888_1X24 - which doesn't make sense for LVDS connected panel, and MEDIA_BUS_FMT_RGB888_1X7X4_SPWG which should be 24bit VESA).

then changed back to 4 lane DSI with MEDIA_BUS_FMT_RGB888_1X7X4_SPWG. New panel is WXGA (1280x800 pixel), single channel LVDS. Works perfectly fine when firing the timing over DPI by LVDS4PI EVO).
Will investigate tomorrow what happens with 3lane DSI and also add debug output for the registers.
Cheers for today.

NOTE: Changing the DSI lane configuration affects of boot time (!) still no display.

Code: Select all

static const struct display_timing my_wxga_timing = {
	.pixelclock = { 71100000, 71100000, 71100000 },
	.hactive = { 1280, 1280, 1280 },
	.hfront_porch = { 160, 160, 160 },
	.hback_porch = { 48, 48, 48 },
	.hsync_len = { 48, 48, 48 },
	.vactive = { 800, 800, 800 },
	.vfront_porch = { 23, 23, 23 },
	.vback_porch = { 8, 8, 8 },
	.vsync_len = { 6, 6, 6 },
	.flags = DISPLAY_FLAGS_DE_HIGH,
};

static const struct panel_desc my_wxga = {
	.timings = &my_wxga_timing,
	.num_timings = 1,
	.bpc = 8,
	.size = {
		.width = 220,
		.height = 140,
	},	
	//.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
	.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
	.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
	.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
Last edited by aBUGSworstnightmare on Sat May 08, 2021 6:13 am, edited 1 time in total.

aBUGSworstnightmare
Posts: 2915
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri May 07, 2021 6:02 am

@6by9 or other folks working with/on that driver: can you please test on your side what's the result when you change the driver like below?

Code: Select all

static u8 sn65dsi83_get_lvds_range(struct sn65dsi83 *ctx)
{
	/*
	 * The encoding of the LVDS_CLK_RANGE is as follows:
	 * 000 - 25 MHz <= LVDS_CLK < 37.5 MHz
	 * 001 - 37.5 MHz <= LVDS_CLK < 62.5 MHz
	 * 010 - 62.5 MHz <= LVDS_CLK < 87.5 MHz
	 * 011 - 87.5 MHz <= LVDS_CLK < 112.5 MHz
	 * 100 - 112.5 MHz <= LVDS_CLK < 137.5 MHz
	 * 101 - 137.5 MHz <= LVDS_CLK <= 154 MHz
	 * which is a range of 12.5MHz..162.5MHz in 50MHz steps, except that
	 * the ends of the ranges are clamped to the supported range. Since
	 * sn65dsi83_mode_valid() already filters the valid modes and limits
	 * the clock to 25..154 MHz, the range calculation can be simplified
	 * as follows:
	 */
	int mode_clock = ctx->mode.clock;
	dev_info(ctx->dev, "mode_clock: %u\n", mode_clock);
	
	if (ctx->lvds_dual_link)
		mode_clock /= 2;

	dev_info(ctx->dev, "mode_clock: %u LVDS clock: %d\n", mode_clock, ((mode_clock - 12500) / 25000));
	return (mode_clock - 12500) / 25000;	
}
Whatever timing I throw on the driver, it always reports an LVDS_CLK range of zero (25MHz <= LVDS_CLK <= 37.5MHz).

Code: Select all

pi@raspberrypi:~ $ dmesg | grep dsi
[    6.469040] sn65dsi83 10-002c: sn65dsi83_attach
[    6.469165] sn65dsi83 10-002c: sn65dsi83_attach - looking good
[    6.469298] vc4-drm gpu: bound fe700000.dsi (ops vc4_dsi_ops [vc4])
[    6.574696] [drm:sn65dsi83_pre_enable [ti_sn65dsi83]] *ERROR* sn65dsi83_pre_enable
[    6.603523] [drm:sn65dsi83_enable [ti_sn65dsi83]] *ERROR* sn65dsi83_enable
[    6.604231] sn65dsi83 10-002c: mode_clock: 0
[    6.604285] sn65dsi83 10-002c: mode_clock: 0 LVDS clock: 0
pi@raspberrypi:~ $ 
Above output was created when I used "ampire,am-1280800n3tzqw-t00h" in the overlay (that's the first timing data from panel-simple.c), and it's always zero from all test I've made so far.

It is claimed the driver is working with 1024x600pixel resolution display ... what if it's working 'by chance' only because the DUT has an LVDS clock frequency in that particular range?

milo246
Posts: 73
Joined: Mon Mar 01, 2021 1:43 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri May 07, 2021 6:55 am

aBUGSworstnightmare wrote:
Wed May 05, 2021 2:19 pm
milo246 wrote:
Wed May 05, 2021 2:16 pm
It works!

Follow the datasheet. The SN65DSI8X datasheet specifically stated:
After power is applied and stable, the DSI CLK lanes MUST be in HS state and the DSI data lanes MUST be driven
to LP11 state
This wasn't being done properly, the DSI was up and running when calling enable. So what I did was:

- Move all SN65 init code from "enable" to "pre_enable"
- The "enable" code only reads back the "error" register, nothing else
- In the vc4_dsi.c driver, I moved the "vc4_dsi_ulps(dsi, false)" call AFTER the pre_enable calls
- I added vc4_dsi_ulps(dsi, true); BEFORE the pre-enable calls to make sure the DSI is in LP mode

After build and deploy, the display worked.

Now I can clean up code and make stuff ready for mainline.
Display working based on your driver or what has been submitted by Marek this morning?
Display based on mine. I haven't ventured into Marek's one.

I reversed the patch on the vc4_dsi and miraculously the panel still works. So I'm a bit puzzled as to what change exactly suddenly made the panel work. Moving all code into the pre_enable seemed to be the thing that made it word.

aBUGSworstnightmare
Posts: 2915
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri May 07, 2021 7:22 am

milo246 wrote:
Fri May 07, 2021 6:55 am
aBUGSworstnightmare wrote:
Wed May 05, 2021 2:19 pm
milo246 wrote:
Wed May 05, 2021 2:16 pm
It works!

Follow the datasheet. The SN65DSI8X datasheet specifically stated:


This wasn't being done properly, the DSI was up and running when calling enable. So what I did was:

- Move all SN65 init code from "enable" to "pre_enable"
- The "enable" code only reads back the "error" register, nothing else
- In the vc4_dsi.c driver, I moved the "vc4_dsi_ulps(dsi, false)" call AFTER the pre_enable calls
- I added vc4_dsi_ulps(dsi, true); BEFORE the pre-enable calls to make sure the DSI is in LP mode

After build and deploy, the display worked.

Now I can clean up code and make stuff ready for mainline.
Display working based on your driver or what has been submitted by Marek this morning?
Display based on mine. I haven't ventured into Marek's one.

I reversed the patch on the vc4_dsi and miraculously the panel still works. So I'm a bit puzzled as to what change exactly suddenly made the panel work. Moving all code into the pre_enable seemed to be the thing that made it word.
Which overlay do you use?
Stopped testing Mareks code as there seem to be an issue - at least on my version here.

With your latest source posted here viewtopic.php?f=44&t=305690&start=100#p1860728 I see below, but still no active display (module timing is the one posted here viewtopic.php?f=44&t=305690&p=1861654#p1861465)

Code: Select all

pi@raspberrypi:~ $ dmesg | grep dsi
[    6.601905] ti-sn65dsi8x 10-002c: sn65dsi_probe
[    6.625670] ti-sn65dsi8x 10-002c: sn65dsi_attach
[    6.625930] vc4-drm gpu: bound fe700000.dsi (ops vc4_dsi_ops [vc4])
[    6.659012] ti-sn65dsi8x 10-002c: sn65dsi_pre_enable
[    6.681134] ti-sn65dsi8x 10-002c: sn65dsi_enable
[    6.681152] ti-sn65dsi8x 10-002c: clock 71100 62500
[    6.681167] ti-sn65dsi8x 10-002c: hdisplay 1280 1280
[    6.681181] ti-sn65dsi8x 10-002c: hsync_start 1440 1254
[    6.681195] ti-sn65dsi8x 10-002c: hsync_end 1488 1302
[    6.681208] ti-sn65dsi8x 10-002c: htotal 1536 1350
[    6.681221] ti-sn65dsi8x 10-002c: vdisplay 800 800
[    6.681234] ti-sn65dsi8x 10-002c: vsync_start 823 823
[    6.681247] ti-sn65dsi8x 10-002c: vsync_end 829 829
[    6.681260] ti-sn65dsi8x 10-002c: vtotal 837 837
[    6.704051] ti-sn65dsi8x 10-002c: pixel_clk: 62500000 LVDS clock: 2
[    6.704419] ti-sn65dsi8x 10-002c: SN65DSI_CLK_DIV: 0x10
[    6.704782] ti-sn65dsi8x 10-002c: SN65DSI_DSI_CFG: 0x20
[    6.705152] ti-sn65dsi8x 10-002c: sn65dsi_enable pixel_clk=62500000 dsi_clk=187500000 range=37 flags=0x0 bpp=24
[    6.705513] ti-sn65dsi8x 10-002c: MEDIA_BUS_FMT_RGB888_1X7X4_SPWG
[    6.705869] ti-sn65dsi8x 10-002c: SN65DSI_LVDS_MODE=0x18
[    6.731753] ti-sn65dsi8x 10-002c: SN65DSI_CHA_ERR=0x0
pi@raspberrypi:~ $ 
btw, I see a lot of warning from 'dmesg | grep drm'
What other changes have you made?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11234
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri May 07, 2021 7:46 am

aBUGSworstnightmare wrote:
Fri May 07, 2021 6:02 am
@6by9 or other folks working with/on that driver: can you please test on your side what's the result when you change the driver like below?
<snip>

Whatever timing I throw on the driver, it always reports an LVDS_CLK range of zero (25MHz <= LVDS_CLK <= 37.5MHz).

Code: Select all

pi@raspberrypi:~ $ dmesg | grep dsi
[    6.469040] sn65dsi83 10-002c: sn65dsi83_attach
[    6.469165] sn65dsi83 10-002c: sn65dsi83_attach - looking good
[    6.469298] vc4-drm gpu: bound fe700000.dsi (ops vc4_dsi_ops [vc4])
[    6.574696] [drm:sn65dsi83_pre_enable [ti_sn65dsi83]] *ERROR* sn65dsi83_pre_enable
[    6.603523] [drm:sn65dsi83_enable [ti_sn65dsi83]] *ERROR* sn65dsi83_enable
[    6.604231] sn65dsi83 10-002c: mode_clock: 0
[    6.604285] sn65dsi83 10-002c: mode_clock: 0 LVDS clock: 0
pi@raspberrypi:~ $ 
Above output was created when I used "ampire,am-1280800n3tzqw-t00h" in the overlay (that's the first timing data from panel-simple.c), and it's always zero from all test I've made so far.

It is claimed the driver is working with 1024x600pixel resolution display ... what if it's working 'by chance' only because the DUT has an LVDS clock frequency in that particular range?
I'll have a look in a moment.
milo246 wrote:
Fri May 07, 2021 6:55 am
Display based on mine. I haven't ventured into Marek's one.

I reversed the patch on the vc4_dsi and miraculously the panel still works. So I'm a bit puzzled as to what change exactly suddenly made the panel work. Moving all code into the pre_enable seemed to be the thing that made it word.
Thanks for confirming that. Effectively all your I2C writes have moved to the other side of setting DISP0_CTRL.

Could you try reverting your mods so that configuration happens in _enable (not _pre_enable), and add patch https://github.com/6by9/linux/commit/b9 ... 1ec9fa58c2 from the top of https://github.com/6by9/linux/tree/rpi- ... si8x-marek please? Largely that is all you've done in moving code to _pre_enable, but I'm suspecting that setting DSI_DISP0_ENABLE early has resulted in the data lane change from LP-11 that is upsetting the SN65DSI8x.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

milo246
Posts: 73
Joined: Mon Mar 01, 2021 1:43 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri May 07, 2021 8:35 am

aBUGSworstnightmare wrote:
Fri May 07, 2021 7:22 am
What other changes have you made?
I attached a summary to this post. The tar contains the current C file, as well as the set of patches (Jagan's original patches and my amendments) that now lead to that code.
Attachments
sn65dsi83.tar.gz
(10.59 KiB) Downloaded 13 times

milo246
Posts: 73
Joined: Mon Mar 01, 2021 1:43 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri May 07, 2021 9:05 am

6by9 wrote:
Fri May 07, 2021 7:46 am
Thanks for confirming that. Effectively all your I2C writes have moved to the other side of setting DISP0_CTRL.

Could you try reverting your mods so that configuration happens in _enable (not _pre_enable), and add patch https://github.com/6by9/linux/commit/b9 ... 1ec9fa58c2 from the top of https://github.com/6by9/linux/tree/rpi- ... si8x-marek please? Largely that is all you've done in moving code to _pre_enable, but I'm suspecting that setting DSI_DISP0_ENABLE early has resulted in the data lane change from LP-11 that is upsetting the SN65DSI8x.
I'll try with that patch and my sn65dsi83 driver, and move stuff back into "enable" again. Looks like a winner.
(edit) YES, with this patch the display works.

I'll try Marek's code, but that'll probably have to wait until next week.

A bit unrelated but since we're here... I noticed that the framebuffer is only 16-bit. How do I make it default to 24-bit?

aBUGSworstnightmare
Posts: 2915
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri May 07, 2021 9:37 am

milo246 wrote:
Fri May 07, 2021 9:05 am
6by9 wrote:
Fri May 07, 2021 7:46 am
Thanks for confirming that. Effectively all your I2C writes have moved to the other side of setting DISP0_CTRL.

Could you try reverting your mods so that configuration happens in _enable (not _pre_enable), and add patch https://github.com/6by9/linux/commit/b9 ... 1ec9fa58c2 from the top of https://github.com/6by9/linux/tree/rpi- ... si8x-marek please? Largely that is all you've done in moving code to _pre_enable, but I'm suspecting that setting DSI_DISP0_ENABLE early has resulted in the data lane change from LP-11 that is upsetting the SN65DSI8x.
I'll try with that patch and my sn65dsi83 driver, and move stuff back into "enable" again. Looks like a winner.
(edit) YES, with this patch the display works.

I'll try Marek's code, but that'll probably have to wait until next week.

A bit unrelated but since we're here... I noticed that the framebuffer is only 16-bit. How do I make it default to 24-bit?
my latest results posted above are based on this kernel https://github.com/6by9/linux/tree/rpi- ... si8x-marek, so should have change mentioned by 6by9 already.

I've also added milo246 driver to that but can't get the display to show something.
Question goes again to milo246: is your overlay part of the archive posted above? Sorry, but writing from the tablet and that can't deal with such archive files.

@milo246: have you tested if it still works when no of DSI lanes gets changed? If I remember correctly you have 1024x768pixel resolution atm, so 2lane DSI is most likely fine. What if you change to 3 or 4 lane DSI?
Last edited by aBUGSworstnightmare on Fri May 07, 2021 9:42 am, edited 1 time in total.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11234
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri May 07, 2021 9:39 am

milo246 wrote:
Fri May 07, 2021 9:05 am
I'll try with that patch and my sn65dsi83 driver, and move stuff back into "enable" again. Looks like a winner.
(edit) YES, with this patch the display works.
Huge thanks - it sounds like we may have a smoking gun.
I do want to verify what is happening at the physical level before merging that change, but looking hopeful.
milo246 wrote:I'll try Marek's code, but that'll probably have to wait until next week.
No problem. It looks like Marek's code is getting more traction than Jagan's, so getting that right would be really helpful all round.
milo246 wrote:A bit unrelated but since we're here... I noticed that the framebuffer is only 16-bit. How do I make it default to 24-bit?
https://github.com/raspberrypi/linux/co ... 648927cd47

Code: Select all

commit f741b28fb299263d2d03a0fb701bfe648927cd47
Author: Maxime Ripard <maxime.ripard@bootlin.com>
Date:   Wed Mar 6 15:02:45 2019 +0100

    drm/vc4: Use 16bpp by default for the fbdev buffer
    
    The preferred bpp for the fbdev emulation buffer has been 32 so far, which
    means that by default we will allocate an 8MB buffer with a 1920x1080
    resolution.
    
    Worse this memory will be allocated from the CMA pool, and will never be
    freed even if we don't use the fbdev emulation. Therefore, reducing it is a
    big deal, and switching to 16bpp by default will gain us around 4MB at
    1920x1080, while keeping decent color depth. And users still have the
    option to switch to 32bpp using the kernel command line.
Shame they don't give the kernel command line entry required!
I'm working with Maxime anyway, so I'll ask him directly.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11234
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri May 07, 2021 9:54 am

6by9 wrote:
Fri May 07, 2021 9:39 am
Shame they don't give the kernel command line entry required!
I'm working with Maxime anyway, so I'll ask him directly.
Part of the video= line. eg

Code: Select all

video=DSI-1:1920x1080-24
to ask for 24bpp (although I'm not sure that's supported).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

milo246
Posts: 73
Joined: Mon Mar 01, 2021 1:43 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri May 07, 2021 11:50 am

6by9 wrote:
Fri May 07, 2021 9:39 am
I do want to verify what is happening at the physical level before merging that change, but looking hopeful.
Sure. I'll just use the patch "as is" for now.
6by9 wrote:No problem. It looks like Marek's code is getting more traction than Jagan's, so getting that right would be really helpful all round.
From what I've seen it's a nice step up. Have to check carefully to see if he caught them all. For one thing there's also the weird reset code in Marek's. I think the pre_enable and post_disable should just be empty, there's no point in doing that GPIO reset before then.
6by9 wrote:
milo246 wrote:A bit unrelated but since we're here... I noticed that the framebuffer is only 16-bit. How do I make it default to 24-bit?
https://github.com/raspberrypi/linux/co ... 648927cd47
Thanks for that gem, I'll just add a revert patch to my kernel to get 32 back.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11234
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri May 07, 2021 11:55 am

More discussions and I'm coming around to the view that the dsi driver is correct, and the I2C commands should largely be in pre_enable. Taking it up on dri-devel.

https://elixir.bootlin.com/linux/latest ... dge.h#L256
enable

Code: Select all

	 * The bridge can assume that the display pipe (i.e. clocks and timing
	 * signals) feeding it is running when this callback is called. This
	 * callback must enable the display link feeding the next bridge in the
	 * chain if there is one.
	 *
which means that putting the I2C writes in enable contradicts the requirement of the Initialization Sequence (table 7.2) Init Seq 2

Code: Select all

After power is applied and stable, the DSI CLK lanes MUST be in HS state and the DSI data lanes MUST be driven to LP11 state
as video can be running.

My patch is shifting starting video to after enable completes, which is contrary to the documented behaviour.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Return to “Interfacing (DSI, CSI, I2C, etc.)”