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 12:25 pm

6by9 wrote:
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.
That was my first thought, hence my first attempt, but the pre_enable documentation states:

Code: Select all

	 * The display pipe (i.e. clocks and timing signals) feeding this bridge
	 * will not yet be running when this callback is called. The bridge must
	 * not enable the display link feeding the next bridge in the chain (if
	 * there is one) when this callback is called.
So this means that during pre_enable the clocks may not be running yet.

What the SN65DSI83 wants at startup is a running DSI clock but idle DSI data lanes. There's no callback that satisfies that, pre_enable lacks the clock and enable lacks the idle data lanes.

That matches what I recall of "native" DSI panels where you'd do the MIPI "command" mode things in "prepare" and the rest (if anything) during "enable".

Your change is sort of inbetween - it sets up the link for everything but the actual pixel data.

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

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

Fri May 07, 2021 12:40 pm

Allow me to 'add to the confusion':
- I'm using 6by9's kernel version - https://github.com/6by9/linux/tree/rpi- ... si8x-marek - with the driver by milo246

Let me show you something:
wuxga_vesa.jpg
WXGA module with VESA mapping - working fine
wuxga_vesa.jpg (201.93 KiB) Viewed 1394 times
wuxga_jeida.jpg
Nexus 7 Gen1 has JEIDA mapping - there is some color issue
wuxga_jeida.jpg (148.74 KiB) Viewed 1394 times
jeida color issue.jpg
Color issue details
jeida color issue.jpg (85.52 KiB) Viewed 1394 times
This is the output from the driver, shows 24bpp --> something I need to investigate further. Clocks are related to 2-lane DSI config.

Code: Select all

pi@raspberrypi:~ $ dmesg | grep dsi
[    6.379921] ti-sn65dsi8x 10-002c: sn65dsi_probe
[    6.517602] ti-sn65dsi8x 10-002c: sn65dsi_attach
[    6.517872] vc4-drm gpu: bound fe700000.dsi (ops vc4_dsi_ops [vc4])
[    6.554725] ti-sn65dsi8x 10-002c: sn65dsi_pre_enable
[    6.554743] ti-sn65dsi8x 10-002c: clock 66800 83333
[    6.554768] ti-sn65dsi8x 10-002c: hdisplay 800 800
[    6.554783] ti-sn65dsi8x 10-002c: hsync_start 816 1029
[    6.554797] ti-sn65dsi8x 10-002c: hsync_end 832 1045
[    6.554810] ti-sn65dsi8x 10-002c: htotal 864 1077
[    6.554823] ti-sn65dsi8x 10-002c: vdisplay 1280 1280
[    6.554837] ti-sn65dsi8x 10-002c: vsync_start 1285 1285
[    6.554850] ti-sn65dsi8x 10-002c: vsync_end 1286 1286
[    6.554863] ti-sn65dsi8x 10-002c: vtotal 1288 1288
[    6.581969] ti-sn65dsi8x 10-002c: pixel_clk: 83333000 LVDS clock: 2
[    6.582334] ti-sn65dsi8x 10-002c: SN65DSI_CLK_DIV: 0x28
[    6.582690] ti-sn65dsi8x 10-002c: SN65DSI_DSI_CFG: 0x30
[    6.583046] ti-sn65dsi8x 10-002c: sn65dsi_pre_enable pixel_clk=83333000 dsi_clk=499998000 range=99 flags=0x5 bpp=24
[    6.583415] ti-sn65dsi8x 10-002c: MEDIA_BUS_FMT_RGB666_1X7X3_SPWG
[    6.583780] ti-sn65dsi8x 10-002c: SN65DSI_LVDS_MODE=0x10
[    6.604246] ti-sn65dsi8x 10-002c: sn65dsi_enable
[    6.609094] ti-sn65dsi8x 10-002c: SN65DSI_CHA_ERR=0x0
pi@raspberrypi:~ $ 
NONE of the displays is working in 4-lane DSI configuration, both are working fine in 2-lane or 3-lane config.
For those who want to test here is the overlay template I'm working with for milo246 driver version.

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>;
						};
					};

					port@1 {
						reg = <1>;
						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>;
				};
			};
		};
	};

	fragment@5 {
		target = <&i2c0if>;
		__overlay__ {
			status = "okay";
		};
	};
		
	fragment@6 {
		target = <&i2c0mux>;
		__overlay__ {
			status = "okay";
		};
	};
};
Conclusion: working with some minor quirks to be sorted out. Will now prepare an interface cable for the WXGA which has the config line for set to JEIDA mapping (that module can work with both mappings) and will report back later.
Nexus 7 Gen1 is a 18-bit JEIDA btw.

EDIT ... one more note: if screen blanking is enabled the DSI image will not be restarted after blanking; screen stays black!
Last edited by aBUGSworstnightmare on Sat May 08, 2021 5:04 am, edited 1 time in total.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11253
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 1:07 pm

aBUGSworstnightmare wrote:
Fri May 07, 2021 12:40 pm
Allow me to 'add to the confusion':
- I'm using 6by9's kernel version - https://github.com/6by9/linux/tree/rpi- ... si8x-marek - with the driver by milo246
:o :o :o
I'll have a look to see if there is anything obviously different in the config.
Seeing as Marek's driver has traction upstream, I expect that it is the one that needs to be made to work.
aBUGSworstnightmare wrote:NONE of the displays is working in 4-lane DSI configuration, both are working fine in 2-lane or 3-lane config.
Same comment made by someone on i.MX8 at https://lists.freedesktop.org/archives/ ... 05776.html
I wonder if this is a TI quirk in handling non-integer division of pixels to lanes.
1920x1080 @ 60Hz is just within spec for 3 lane operation so that will cover most displays.
aBUGSworstnightmare wrote:Conclusion: working with some minor quirks to be sorted out. Will now prepare an interface cable for the WUXGA which has the config line for set to JEIDA mapping (that module can work with both mappings) and will report back later.
Nexus 7 Gen1 is a 18-bit JEIDA btw.

EDIT ... one more note: if screen blanking is enabled the DSI image will not be restarted after blanking; screen stays black!
Disable/enable is always one of the painful ones. Potentially power sequencing again.
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: 2942
Joined: Tue Jun 30, 2015 1:35 pm

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

Fri May 07, 2021 1:54 pm

@milo246:
below will fix the issue with 18-bit JEIDA mapping; you disabled CHA_24BPP_MODE (which defaults to zero) but missed to switch to FORMAT1. Below will fix the issue as you can see when comparing the pics to the first ones.

Code: Select all

	switch (bus_format) {
		case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
			/* "jeida-18" */
			dev_info(sn->dev, "MEDIA_BUS_FMT_RGB666_1X7X3_SPWG\n");
			val |= CHA_24BPP_FORMAT1;
			break;
		case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
			/* "vesa-24" */
			/* LVDS lane 3 transmits the 2 MSB per color */
			dev_info(sn->dev, "MEDIA_BUS_FMT_RGB888_1X7X4_SPWG\n");
			val |= CHA_24BPP_MODE;
			break;
		case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
			 /* "jeida-24" */
			 /* LVDS lane 3 transmits the 2 LSB per color */
			dev_info(sn->dev, "MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA\n");
			val |= CHA_24BPP_MODE | CHA_24BPP_FORMAT1;
			break;
		default:
			dev_warn(sn->dev, "Unknown output mode 0x%x\n",
				 bus_format);
	}
jeida18_fixed.jpg
18-bit JEIDA issue fixed
jeida18_fixed.jpg (113.31 KiB) Viewed 1365 times
jeida18fixed_1.jpg
18-bit JEIDA issue fixed
jeida18fixed_1.jpg (130.85 KiB) Viewed 1365 times

Minor issue (yes, I can be picky): there is no 'DPPLL_SRC_DP_PLL_LOCK' bit in DSI83/4/5; that one is solely available in DSI86.
In the DSI83/84/85 spec it is named 'PLL_EN_STAT' (BIT7 of CSR 0x0A). It's confusing in case someone tries to understand the driver code.
So you may want to change to

Code: Select all

	...
	/* After PLL_EN_STAT = 1, wait at least 3 ms for PLL to lock */
	usleep_range(3000, 4000);

	ret = regmap_read_poll_timeout(sn->regmap, SN65DSI_LVDS_CLK, val,
				       val & PLL_EN_STAT, 1000, 50 * 1000);
	 ...
	
decided to take another challenge : 1366x768pixel in JEIDA-24 ... will be interested to see how CM4 copes with that one on DSI.

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 2:05 pm

@milo246:
below will fix the issue with 18-bit JEIDA mapping; you disabled CHA_24BPP_MODE (which defaults to zero) but missed to switch to FORMAT1. Below will fix the issue as you can see when comparing the pics to the first ones.
Good catch. That was also still a bit of work in progress. I also wanted to look at the bpp field.

If you have a 24 bpp DSI connection but an 18bpp (i.e. 3-lane) LVDS link, I think the config should set CHA_24BPP_FORMAT1 to "1" to have the chip downconvert from 24 to 18 bits properly. If the DSI link is already 18-bit, then CHA_24BPP_FORMAT1 should be "0".

If I read the DS correctly.
CHA_24BPP_FORMAT1
This field selects the 24 bpp data format
0 – LVDS channel A lane A_Y3P or A_Y3N transmits the 2 MSB per color;
format 2 (default)
1 – LVDS channel A lane A_Y3P or A_Y3N transmits the 2 LSB per color;
format 1
Note1: This field must be 0 when 18bpp data is received from DSI.
Note2: If this field is set to 1 and CHA_24BPP_MODE is 0, the SN65DSI83
device will convert 24-bpp data to 18-bpp data for transmission to an 18-bpp
panel. In this configuration, the SN65DSI83 device will not transmit the 2
LSB per color on LVDS channel A, since LVDS channel A lane 4 is disabled.
Then the code would be like this:

Code: Select all

	/* setup lvds modes */
	val = LVDS_LINK_CFG;
	if (mode->flags & DRM_MODE_FLAG_NVSYNC)
		val |= VS_NEG_POLARITY;
	if (mode->flags & DRM_MODE_FLAG_NHSYNC)
		val |= HS_NEG_POLARITY;

	if (connector) {
		bus_format = connector->display_info.bus_formats[0];
	} else {
		dev_warn(sn->dev, "NULL connector, using default bus format\n");
		bus_format = (bpp == 24) ?
				MEDIA_BUS_FMT_RGB888_1X7X4_SPWG :
				MEDIA_BUS_FMT_RGB666_1X7X3_SPWG;
	}

	switch (bus_format) {
		case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
			dev_info(sn->dev, "MEDIA_BUS_FMT_RGB666_1X7X3_SPWG\n");
			/* Convert 24->18 if needed */
			if (bpp == 24)
				val |= CHA_24BPP_FORMAT1;
			break;
		case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
			 /* LVDS lane 3 transmits the 2 MSB per color */
			dev_info(sn->dev, "MEDIA_BUS_FMT_RGB888_1X7X4_SPWG\n");
			val |= CHA_24BPP_MODE;
			break;
		case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
			 /* LVDS lane 3 transmits the 2 LSB per color */
			dev_info(sn->dev, "MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA\n");
			val |= CHA_24BPP_MODE | CHA_24BPP_FORMAT1;
			break;
		default:
			dev_warn(sn->dev, "Unknown output mode 0x%x\n",
				 bus_format);
	}

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

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

Fri May 07, 2021 2:34 pm

milo246 wrote: Good catch. That was also still a bit of work in progress. I also wanted to look at the bpp field.

If you have a 24 bpp DSI connection but an 18bpp (i.e. 3-lane) LVDS link, I think the config should set CHA_24BPP_FORMAT1 to "1" to have the chip downconvert from 24 to 18 bits properly. If the DSI link is already 18-bit, then CHA_24BPP_FORMAT1 should be "0".
From the spec FORMAT1 is JEIDA mapping, figure 11 and 12 show JEIDA mapping. Don't know why there is figure 9 because this would be cutting of the MSB of VESA (no Y3P/N) so in real life it will become JEIDA (as I'm I doubt that somebody will drop the color MSB because white would then be shifted to gray).

Anyhow, let me check again and report back. Checking for bpc (or bpp) would be good anyhow.

Edit: MIPi DSI sends 24bit RGB data, hence format conversion is needed so CHA_24BPP_FORMAT1 =1 and CHA_24BPP_MODE = 0 --> exactly what Note2 of the spec translates to.
In your 'sn65dsi_attach'

Code: Select all

 ...	sn->dsi->lanes = sn->dsi_lanes;
	sn->dsi->format = MIPI_DSI_FMT_RGB888;
	sn->dsi->mode_flags = MIPI_DSI_MODE_VIDEO; 
Last edited by aBUGSworstnightmare on Sun May 09, 2021 7:34 am, edited 2 times in total.

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

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

Fri May 07, 2021 2:39 pm

Here is the result from 1366x768pixel JEIDA-24 display testing. As with every Pi4 and this resolution:
1366x768 fails.jpg
1366x768pixels fail like with every Pi4/CM4/Pi400 - refer to the Pi documentation for details
1366x768 fails.jpg (141.33 KiB) Viewed 1337 times
1364x768 is fine.jpg
changed resolution to 1364x768pixels which comes out nicely
1364x768 is fine.jpg (132.2 KiB) Viewed 1337 times
in doubt.jpg
In case somebody is in doubt : CM4 on CM4IO, connected to an SN65DSI84 on the MIPI2LVDS board. The display shown is a 12.1in with 1366x768pixels native resolution.
in doubt.jpg (152.1 KiB) Viewed 1337 times
Last edited by aBUGSworstnightmare on Fri May 07, 2021 7:00 pm, edited 2 times in total.

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 2:42 pm

I guess the idea is that CHA_24BPP_FORMAT1 just changes the way the bits are re-ordered in transit from DSI to LVDS. Regardless of the actual number of bits received from DSI. It just internally does something like "out = ((in & 0xfc) >> 2) | ((in & 0x03) << 6)" when you set that bit

If the DSI is sending 24 bits, this causes the LVDS channel to take the 6 MSBs instead of the LSBs from the DSI data. If the DSI is sending 18 bits, I guess you'll just lose the lower 2 bits as well...

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 2:59 pm

I use this for testing (fb-test). As you can see 24-bit works now, and the gradients are all smooth so the bits are in their proper places. The moire is caused by the camera seeing the world differently than us humans...
testscreen.jpg
testscreen.jpg (138.05 KiB) Viewed 1321 times

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

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

Fri May 07, 2021 3:46 pm

milo246 wrote:
Fri May 07, 2021 2:42 pm
I guess the idea is that CHA_24BPP_FORMAT1 just changes the way the bits are re-ordered in transit from DSI to LVDS. Regardless of the actual number of bits received from DSI. It just internally does something like "out = ((in & 0xfc) >> 2) | ((in & 0x03) << 6)" when you set that bit

If the DSI is sending 24 bits, this causes the LVDS channel to take the 6 MSBs instead of the LSBs from the DSI data. If the DSI is sending 18 bits, I guess you'll just lose the lower 2 bits as well...
If the DSI is sending 18bit data only then it's 18bit anyhow. DSI would have to shuffle the bit's around but that's not done AFIK as there is the bus_format definition. O.k., we are relaying on the ones for LVDS and there might be more for DSI...
Let's keep an eye on that.
What other changes have you done (or is it only that one https://github.com/raspberrypi/linux/co ... 648927cd47, sorry, but I've not tested it yet)?
Last edited by aBUGSworstnightmare on Sat May 08, 2021 6:18 am, edited 1 time in total.

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

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

Fri May 07, 2021 7:27 pm

6by9 wrote:
Fri May 07, 2021 1:07 pm
aBUGSworstnightmare wrote:
Fri May 07, 2021 12:40 pm
Allow me to 'add to the confusion':
- I'm using 6by9's kernel version - https://github.com/6by9/linux/tree/rpi- ... si8x-marek - with the driver by milo246
:o :o :o
I'll have a look to see if there is anything obviously different in the config.
Seeing as Marek's driver has traction upstream, I expect that it is the one that needs to be made to work.
aBUGSworstnightmare wrote:NONE of the displays is working in 4-lane DSI configuration, both are working fine in 2-lane or 3-lane config.
Same comment made by someone on i.MX8 at https://lists.freedesktop.org/archives/ ... 05776.html
I wonder if this is a TI quirk in handling non-integer division of pixels to lanes.
1920x1080 @ 60Hz is just within spec for 3 lane operation so that will cover most displays.
aBUGSworstnightmare wrote:Conclusion: working with some minor quirks to be sorted out. Will now prepare an interface cable for the WUXGA which has the config line for set to JEIDA mapping (that module can work with both mappings) and will report back later.
Nexus 7 Gen1 is a 18-bit JEIDA btw.

EDIT ... one more note: if screen blanking is enabled the DSI image will not be restarted after blanking; screen stays black!
Disable/enable is always one of the painful ones. Potentially power sequencing again.
will have to source a FHD panel before beeing able to check dual-channel LVDS.

What can cause DSI blanking? I have disabled screen blanking btw..
This is what the DSI83/4/5 spec says on stopping/restarting video:
9.1.1 Video STOP and Restart Sequence

When the system requires to stop outputting video to the display, using the following sequence for the SN65DSI85-Q1 device is recommended:

Clear the PLL_EN bit to 0(CSR 0x0D.0).
Stop video streaming on DSI inputs.
Drive all DSI input lanes including DSI CLK lane to LP11.

When the system is ready to restart the video streaming.

Start video streaming on DSI inputs.
Set the PLL_EN bit to 1 (CSR 0x0D.0).
Wait for a minimum of 3 ms.
Set the SOFT_RESET bit (0x09.0).
looks like we only need to figure out where to clear the pll_en bit and where/when to write again. Maybe that is in Mareks driver already..

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11253
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

Mon May 10, 2021 8:15 am

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: 2942
Joined: Tue Jun 30, 2015 1:35 pm

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

Mon May 10, 2021 9:06 am

6by9 wrote:
Mon May 10, 2021 8:15 am
Marek has sent v4 - https://patchwork.freedesktop.org/series/89914/
will give it a try in the afternoon and report back.
Thanks for letting us know. Btw. Any idea where to look for resume in case of blanking?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11253
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

Mon May 10, 2021 9:17 am

aBUGSworstnightmare wrote:
Mon May 10, 2021 9:06 am
will give it a try in the afternoon and report back.
You'll still need my patch that moves the enable of video until after _enable. I'm still discussing that with him as his response at https://lists.freedesktop.org/archives/ ... 06054.html is two wrongs making a right.
aBUGSworstnightmare wrote:Thanks for letting us know. Btw. Any idea where to look for resume in case of blanking?
It'll be going through a normal _disable, _post_disable, _pre_enable, __enable sequence.

Looking at Marek's driver he pulls the enable gpio in _post_disable, so everything should get reset by that. Is your reset GPIO connected up and functioning correctly?
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: 2942
Joined: Tue Jun 30, 2015 1:35 pm

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

Mon May 10, 2021 11:32 am

6by9 wrote:
Mon May 10, 2021 9:17 am
aBUGSworstnightmare wrote:
Mon May 10, 2021 9:06 am
will give it a try in the afternoon and report back.
You'll still need my patch that moves the enable of video until after _enable. I'm still discussing that with him as his response at https://lists.freedesktop.org/archives/ ... 06054.html is two wrongs making a right.
aBUGSworstnightmare wrote:Thanks for letting us know. Btw. Any idea where to look for resume in case of blanking?
It'll be going through a normal _disable, _post_disable, _pre_enable, __enable sequence.

Looking at Marek's driver he pulls the enable gpio in _post_disable, so everything should get reset by that. Is your reset GPIO connected up and functioning correctly?
Hi 6by9,
will also test it with your 'Marek' branch, same that I've tested milo246 driver's with. Isn't that 'video patch' implemented there?

My enable pin is working correctly from what I can see, so let's see what happens.

Edit:
applied the patch, changed to dual lane DSI --> not working here! LVDS-1 gets created but no display.

Code: Select all

pi@raspberrypi:~ $ dmesg | grep dsi
[    6.515914] vc4-drm gpu: bound fe700000.dsi (ops vc4_dsi_ops [vc4])
pi@raspberrypi:~ $ dmesg | grep drm
[    5.306451] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    5.342580] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    5.394034] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    5.401040] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    5.409705] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    5.558256] [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 1
[    5.635264] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    5.667547] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    5.689128] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    6.152763] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    6.173742] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    6.193612] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    6.475448] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    6.497624] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    6.514316] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    6.515914] vc4-drm gpu: bound fe700000.dsi (ops vc4_dsi_ops [vc4])
[    6.516322] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[    6.516641] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.516983] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.517301] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.517556] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.517883] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.542021] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[    6.861981] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
pi@raspberrypi:~ $ dmesg | grep vc4
[    5.306451] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    5.342580] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    5.394034] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    5.398126] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[    5.398364] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
[    5.399281] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present!
[    5.401040] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    5.405514] rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[    5.405828] input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input1
[    5.406847] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' already present!
[    5.409705] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    5.635264] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    5.664732] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[    5.664951] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input2
[    5.665741] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present!
[    5.667547] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    5.685311] rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[    5.685528] input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input3
[    5.686336] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' already present!
[    5.689128] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    6.152763] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    6.168257] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[    6.168489] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input4
[    6.169309] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present!
[    6.173742] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    6.189666] rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[    6.189895] input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input5
[    6.190724] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' already present!
[    6.193612] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    6.475448] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    6.479634] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[    6.479871] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input6
[    6.482852] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present!
[    6.497624] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    6.507464] rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[    6.507681] input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input7
[    6.509906] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' already present!
[    6.514316] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    6.515914] vc4-drm gpu: bound fe700000.dsi (ops vc4_dsi_ops [vc4])
[    6.516322] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[    6.516641] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.516983] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.517301] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.517556] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.517883] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.542021] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[    6.861981] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
[   15.479803] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   15.480343] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   15.481232] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   16.200409] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   16.201123] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   16.202847] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   16.203086] vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
[   16.276547] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   16.277229] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   16.278263] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   16.339726] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   16.341074] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   16.343949] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
[   16.344802] vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
pi@raspberrypi:~ $ 

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11253
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

Mon May 10, 2021 5:24 pm

Sorry, it's a tricky situation working without hardware, and currently still generally from home. It's not helped by too much other stuff going on.

In trying to determine what is up with Marek's driver (and I haven't updated my branch with V4 as yet), could you grab the I2C traffic from milo's and Marek's drivers? A comparison of the drivers is a pain as all the register defines are different between them.
https://michlstechblog.info/blog/linux- ... l-tracing/
The log will look a little confused as i2c-10 being a i2cmux-pinctrl node off i2c-11 means everything gets logged twice, once under each node.
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: 2942
Joined: Tue Jun 30, 2015 1:35 pm

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

Mon May 10, 2021 6:42 pm

6by9 wrote:
Mon May 10, 2021 5:24 pm
Sorry, it's a tricky situation working without hardware, and currently still generally from home. It's not helped by too much other stuff going on.

In trying to determine what is up with Marek's driver (and I haven't updated my branch with V4 as yet), could you grab the I2C traffic from milo's and Marek's drivers? A comparison of the drivers is a pain as all the register defines are different between them.
https://michlstechblog.info/blog/linux- ... l-tracing/
The log will look a little confused as i2c-10 being a i2cmux-pinctrl node off i2c-11 means everything gets logged twice, once under each node.
let me try rhis tomorrow.

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

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

Tue May 11, 2021 5:20 am

6by9 wrote:
Mon May 10, 2021 5:24 pm
Sorry, it's a tricky situation working without hardware, and currently still generally from home. It's not helped by too much other stuff going on.

In trying to determine what is up with Marek's driver (and I haven't updated my branch with V4 as yet), could you grab the I2C traffic from milo's and Marek's drivers? A comparison of the drivers is a pain as all the register defines are different between them.
https://michlstechblog.info/blog/linux- ... l-tracing/
The log will look a little confused as i2c-10 being a i2cmux-pinctrl node off i2c-11 means everything gets logged twice, once under each node.
The log needs to be created during boot, so how do I force this? Sorry, but I've never used this feature before.

What I've did is adding some debug prints, reading back the registers which were previously written. What one can see is that the driver is not parsing the display timing data correctly/at all (look i.e. at LVDS_PLL which is zero or the ACTIVE_LINE_LENGHT H/L)

Code: Select all

pi@raspberrypi:~ $ dmesg | grep dsi
[    6.460030] vc4-drm gpu: bound fe700000.dsi (ops vc4_dsi_ops [vc4])
[    6.520310] sn65dsi83 10-002c: sn65dsi83_pre_enable
[    6.542414] sn65dsi83 10-002c: sn65dsi83_enable
[    6.543943] sn65dsi83 10-002c: REG_RC_LVDS_PLL 0x1
[    6.543960] sn65dsi83 10-002c: REG_DSI_CLK 0x8
[    6.543975] sn65dsi83 10-002c: REG_RC_DSI_CLK 0x28
[    6.544334] sn65dsi83 10-002c: REG_DSI_LANE 0x36
[    6.544697] sn65dsi83 10-002c: REG_DSI_EQ 0x0
[    6.546086] sn65dsi83 10-002c: REG_LVDS_FMT 0x10
[    6.546102] sn65dsi83 10-002c: REG_LVDS_VCOM 0x5
[    6.546116] sn65dsi83 10-002c: REG_LVDS_LANE 0x3
[    6.546130] sn65dsi83 10-002c: REG_LVDS_CM 0x0
[    6.546596] sn65dsi83 10-002c: REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH 0x0
[    6.546623] sn65dsi83 10-002c: REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW 0x0
[    6.547080] sn65dsi83 10-002c: REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH 0x0
[    6.547101] sn65dsi83 10-002c: REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW 0x0
pi@raspberrypi:~ $ 
That's what I've already reported from my last testing with Marek's driver (viewtopic.php?f=44&t=305690&start=125#p1861631). As I don't know if this problem only happens on my setup here I also want to understand how they are passing display (register setting) details on the i.MX8 platform which they are using. Do they have the timing in the Device Tree or how is it to be configured?
I've added the changed source file as well as my overlay to the archive.
Attachments
Marekv4_test.tar
Changed V4 source and overlay in use
(30 KiB) Downloaded 9 times

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11253
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

Tue May 11, 2021 11:06 am

Nothing is calling the mode_set functions, so sn65dsi83_mode_set never sets ctx->mode in struct sn65dsi83, nor mode_valid to setup lvds_format_24bpp and lvds_format_jeida.
Jagan / Milo's driver uses

Code: Select all

struct drm_display_mode *adjusted_mode =
		&bridge->encoder->crtc->state->adjusted_mode;
in pre_enable and enable.

Now to find the bit of framework that is missing.
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: 11253
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

Tue May 11, 2021 11:56 am

6by9 wrote:
Tue May 11, 2021 11:06 am
Nothing is calling the mode_set functions, so sn65dsi83_mode_set never sets ctx->mode in struct sn65dsi83, nor mode_valid to setup lvds_format_24bpp and lvds_format_jeida.
Jagan / Milo's driver uses

Code: Select all

struct drm_display_mode *adjusted_mode =
		&bridge->encoder->crtc->state->adjusted_mode;
in pre_enable and enable.

Now to find the bit of framework that is missing.
Hmm, so it seems that in https://github.com/raspberrypi/linux/co ... 24438ae35d having removed the hooks for pre_enable/enable/disable/post_disable (by setting dsi->encoder->bridge to NULL), it's also killed off the hooks for mode_set and mode_valid. I guess the driver needs to call those as well - such fun!
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: 2942
Joined: Tue Jun 30, 2015 1:35 pm

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

Tue May 11, 2021 1:14 pm

6by9 wrote:
Tue May 11, 2021 11:56 am
6by9 wrote:
Tue May 11, 2021 11:06 am
Nothing is calling the mode_set functions, so sn65dsi83_mode_set never sets ctx->mode in struct sn65dsi83, nor mode_valid to setup lvds_format_24bpp and lvds_format_jeida.
Jagan / Milo's driver uses

Code: Select all

struct drm_display_mode *adjusted_mode =
		&bridge->encoder->crtc->state->adjusted_mode;
in pre_enable and enable.

Now to find the bit of framework that is missing.
Hmm, so it seems that in https://github.com/raspberrypi/linux/co ... 24438ae35d having removed the hooks for pre_enable/enable/disable/post_disable (by setting dsi->encoder->bridge to NULL), it's also killed off the hooks for mode_set and mode_valid. I guess the driver needs to call those as well - such fun!
Well, but what makes Marek's driver then different when compared to milo246 driver?
And: my vc4_dsi.c is different as the related code snipped is

Code: Select all

	/* Disable the atomic helper calls into the bridge.  We
	 * manually call the bridge pre_enable / enable / etc. calls
	 * from our driver, since we need to sequence them within the
	 * encoder's enable/disable paths.
	 */
	list_splice_init(&dsi->encoder->bridge_chain, &dsi->bridge_chain);
compared to what you posted the link to is

Code: Select all

	/* Disable the atomic helper calls into the bridge.  We
	 * manually call the bridge pre_enable / enable / etc. calls
	 * from our driver, since we need to sequence them within the
	 * encoder's enable/disable paths.
	 */
	dsi->encoder->bridge = NULL;
Sorry, but have no idea why it is different. Still thought it is your kernel version with the Marek V3 (patched to V4 then by me).
Or is this change coming from some milo246 patch?? Will grab your https://github.com/6by9/linux/commits/r ... si8x-marek again and apply V4 patch to that. Will report back (after checking/comparing the above on that kernel as well).

EDIT (17:53pm): pulled the kernel, patched it with V4, changed to overlay to 2-lane and compiled the kernel.
Result: Nothing, not even able to show the desktop in. VNC session; the overlay which is in 6by9's patch doesn't get loaded --> LVDS-1 is not created (means no DSI entry in kernel log).

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11253
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

Tue May 11, 2021 5:00 pm

aBUGSworstnightmare wrote:
Tue May 11, 2021 1:14 pm
Well, but what makes Marek's driver then different when compared to milo246 driver?
Marek's code uses the mode_set and mode_valid hooks. Milo246's driver doesn't.
aBUGSworstnightmare wrote:And: my vc4_dsi.c is different as the related code snipped is

Code: Select all

	/* Disable the atomic helper calls into the bridge.  We
	 * manually call the bridge pre_enable / enable / etc. calls
	 * from our driver, since we need to sequence them within the
	 * encoder's enable/disable paths.
	 */
	list_splice_init(&dsi->encoder->bridge_chain, &dsi->bridge_chain);
compared to what you posted the link to is

Code: Select all

	/* Disable the atomic helper calls into the bridge.  We
	 * manually call the bridge pre_enable / enable / etc. calls
	 * from our driver, since we need to sequence them within the
	 * encoder's enable/disable paths.
	 */
	dsi->encoder->bridge = NULL;
Sorry, but have no idea why it is different.
It's been updated since Eric's original commit to create a doubly linked list, so setting a single pointer to NULL doesn't work and hence the list is spliced. Either way we have two list fragments to run through.
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: 2942
Joined: Tue Jun 30, 2015 1:35 pm

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

Tue May 11, 2021 5:59 pm

6by9 wrote:
Tue May 11, 2021 5:00 pm
aBUGSworstnightmare wrote:
Tue May 11, 2021 1:14 pm
Well, but what makes Marek's driver then different when compared to milo246 driver?
Marek's code uses the mode_set and mode_valid hooks. Milo246's driver doesn't.
aBUGSworstnightmare wrote:And: my vc4_dsi.c is different as the related code snipped is

Code: Select all

	/* Disable the atomic helper calls into the bridge.  We
	 * manually call the bridge pre_enable / enable / etc. calls
	 * from our driver, since we need to sequence them within the
	 * encoder's enable/disable paths.
	 */
	list_splice_init(&dsi->encoder->bridge_chain, &dsi->bridge_chain);
compared to what you posted the link to is

Code: Select all

	/* Disable the atomic helper calls into the bridge.  We
	 * manually call the bridge pre_enable / enable / etc. calls
	 * from our driver, since we need to sequence them within the
	 * encoder's enable/disable paths.
	 */
	dsi->encoder->bridge = NULL;
Sorry, but have no idea why it is different.
It's been updated since Eric's original commit to create a doubly linked list, so setting a single pointer to NULL doesn't work and hence the list is spliced. Either way we have two list fragments to run through.
to have correct understanding, the code with the 'spliced list' (list_splice_init) is the most recent one, right?
And is the problem now a 'Marek driver' or 'VC4' problem? Sorry, I'm a little lost here. Btw, is Marek testing on i.MX8 only or does he test with other Hw (i.e. RPi) too?

UberDoefus
Posts: 19
Joined: Tue May 04, 2021 8:28 am

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

Fri May 14, 2021 8:07 pm

Dear guru's,

something is confusing me to bits. I've been using the Marek driver, which we needed to modify for certain registers that were incorrect for our LVDS display (like hardcoded 200ohm termination and there are others...). Once done and proven to be working, we'll be providing them to the community. Those are all quite straightforward but there is one main thing bothering me, which is the DSI clock.
Maybe some of you could point me in the right direction...

Our LVDS panel requires a DSI clock of around 425Mhz to be able to keep up with the data, following the formula:

DSICLK = (2 * LVDSCLK * bpp)/(2 * nr_dsi_lanes)

Our panel has a typical LVDSCLK according to the datasheet of 70.93Mhz, so DSICLK = (2*70.93*24)/(2*4) = 425Mhz

Now, what we receive in the sn65dsi83 bridge itself, code wise, is a pixelclock of 62.5Mhz (ctx->mode.clock, which is by coincidence? exactly one of the register bounds in the SN65DSI84 datasheet). This clock is then used to calculate the DSI clock register value from, which is hence completely incorrect.

Also, the marek driver does a

if (ctx->lvds_dual_link)
mode_clock /= 2;

to determine the lvds clock range, where is this /2 coming from, I don't see that in the datasheet?

The DSI range is calculated using a different formula:

u8 dsiClk = DIV_ROUND_UP(clamp((unsigned int)ctx->mode.clock *
mipi_dsi_pixel_format_to_bpp(ctx->dsi->format) /
ctx->dsi_lanes / 2, 40000U, 500000U), 5000U);

Why is this range calculated differently than the usual formula?


The vc4_dsi_encoder_enable method reports a pixel_clock_hz of 62500000 and a dsi_divider of 6, a phy_clock of 375006000, an escape_clock of 99947946 and an hs_clock of 375000012. Then the phy clock is divided by 8 and the pixel_clock is set to that value, which is 46.8Mhz.

Which of these numbers in the vc4_dsi.c is the actual DSI clock and what determines the actual dsi clock that is used? I would think the DSI clock is derived from the timing of the panel, as that requires a certain DSI clock for the data. I cannot seem to find how this is determined in the code and why our clock is so off...

Thanks for clarifying my mind in advance...

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

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

Sat May 15, 2021 5:29 am

UberDoefus wrote: if (ctx->lvds_dual_link)
mode_clock /= 2;
in case of a dual link LVDS panel the pixel clock needs to be devided as there are two clocks (Channel A and Channel B).

Some questions:
1. Is Mareks driver working for you? I can't get it to work as the panel mode is not set. Because of that all registers which relay on data from display timing are not configured correctly.

2. Changing LVDS termination to 100 Ohms is simple, but which other registers are incorrect?

3. Changing the formula for calculating DSI clock frequency will be simple, but what I would like to see is the reference where yoi found below formula
UberDoefus wrote:DSICLK = (2 * LVDSCLK * bpp)/(2 * nr_dsi_lanes)
4. Which panel resolution do you have? What I'm waiting for to show up is 1920x1080.

5. Have you tetsed milo246 driver? Do you have it working with your panel. If yes, post the output of 'dmesg | grep dsi'

6 in SLLA356.pdf - trouble shooting app not for DSI8x it is given as

Code: Select all

 DSICLK = (LVDSCLK * bpp)/(2 * nr_dsi_lanes)  
yes, there are some videos from TI which explain how to use DSI8x and there it is mentioned that LVDSCLK needs to be divided by two, as with all horizontal timing data(!). But that is only valid for dual channel LVDS. So one need to be careful when extracting the timing data from the module spec and based on the driver then needs to adjust them for such use case (should be simple to accomplish as Marek uses a dedicated port in the DT overlay for dual channel).

7. Btw, I don't see any benefit in using a formula to calculate the LVDS clock range as this could be done quite simple - and way more transparent
like below. One can add a DRM_DEV_ERROR message to warn/stop on incorrect range.

Code: Select all

	/* Determine LVDS clock-range setting */
	if (lvds_clock <= 37500) {
		REG_RC_LVDS_PLL_LVDS_CLK_RANGE = 0x00;
	}
	else if (lvds_clock <= 62500) {
		REG_RC_LVDS_PLL_LVDS_CLK_RANGE = 0x01;
	}
	else if (lvds_clock <= 87500){
		REG_RC_LVDS_PLL_LVDS_CLK_RANGE = 0x02;
	}
	else if (lvds_clock <= 112500)	{
		REG_RC_LVDS_PLL_LVDS_CLK_RANGE = 0x03;
	}
	else if (lvds_clock <= 137500) {
		REG_RC_LVDS_PLL_LVDS_CLK_RANGE = 0x04;
	}
	else {
		REG_RC_LVDS_PLL_LVDS_CLK_RANGE = 0x05;
	}
I haven't tested dual-channel mode yet as I'm waiting for a panel to arrive. Anyhow, will test with milo246 driver first as Marek driver is not working for me atm.

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