hedie
Posts: 13
Joined: Mon Aug 17, 2020 12:26 pm

VC4 Video Driver dont start DSI Interface

Mon Aug 17, 2020 12:35 pm

Hello

According to this topic: viewtopic.php?t=253912
i have tried to add my own DSI panel to the raspberry.

For this, i have created an overlay:

Code: Select all

// Enable the i2s interface
/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2835";

	fragment@0 {
	  //target = <&dsi1>;
	  target-path = "/soc/dsi@7e700000";
	  __overlay__{
		status = "okay";
		#address-cells = <1>;
		#size-cells = <0>;
		power-domains = <&power 18>;
		port {
		  dsi_out_port:endpoint {
			remote-endpoint = <&panel_dsi_port>;
		  };
		};
		myPanel:panel@0 {
		
			compatible = "simple-panel-dsi";
			reg = <0>;
			status = "okay";

			//reset-gpios = <&gpio8 3 1>;
			//reset-delay-ms = <50>;
			enable-delay-ms = <60>;
			prepare-delay-ms = <60>;
			unprepare-delay-ms = <60>;
			disable-delay-ms = <60>;
			dsi,flags = <7>;
			dsi,format = <0>;
			dsi,lanes  = <2>;

			panel-init-sequence = [
				05 00 02 B2 50
				05 00 02 80 8B
				05 00 02 81 78
				05 00 02 82 84
				05 00 02 83 88
				05 00 02 84 A8
				05 00 02 85 E3
				05 00 02 86 88 	
			];
 
			display-timings {
				timings {
					clock-frequency = <51000000>;
					hactive = <1024>;
					hfront-porch = <104>;
					hback-porch = <127>;
					hsync-len = <4>;
					vactive = <600>;
					vfront-porch = <4>;
					vback-porch = <3>;
					vsync-len = <2>;
					hsync-active = <0>;
					vsync-active = <0>;
					de-active = <0>;
					pixelclk-active = <0>;
                };
            };
		  port {
			 panel_dsi_port: endpoint {
			   remote-endpoint = <&dsi_out_port>;
			};
		  };
		};
	  };
	};
	
	fragment@1 {
		target = <&hdmi>;
		__overlay__  {
			status = "disabled";
		};
	};
};
I have also added the following entries to my config.txt

Code: Select all

dtoverlay=dsi
ignore_lcd=1
dtoverlay=vc4-kms-v3d
Unfortunately the VC4 does not try to start up the dsi interface.

This is the log output of dmesg

Code: Select all

4.891931] vc4_hdmi 3f902000.hdmi: ASoC: Failed to create component debugfs directory
[    4.898209] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok
[    4.911085] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[    4.911321] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
There is no output like in the above mentioned topic:

Code: Select all

[    6.168391] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[    6.168601] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
[    6.183276] vc4-drm soc:gpu: bound 3f700000.dsi (ops vc4_dsi_ops [vc4])
[    6.183513] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4])
[    6.183626] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[    6.184080] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.184538] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.184969] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
[    6.212193] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
It looks like, that my VC4 Driver only supports HDMI and VEC.

This is an excerpt of the devicetree after loading my overlay

Code: Select all

dsi@7e700000 {
			power-domains = < 0x0f 0x12 >;
			compatible = "brcm,bcm2835-dsi1";
			clocks = < 0x03 0x23 0x03 0x30 0x03 0x32 >;
			clock-names = "phy\0escape\0pixel";
			status = "okay";
			#address-cells = < 0x01 >;
			interrupts = < 0x02 0x0c >;
			#size-cells = < 0x00 >;
			#clock-cells = < 0x01 >;
			phandle = < 0x06 >;
			reg = < 0x7e700000 0x8c >;
			clock-output-names = "dsi1_byte\0dsi1_ddr2\0dsi1_ddr";

			port {

				endpoint {
					remote-endpoint = < 0x78 >;
					phandle = < 0x79 >;
				};
			};

			panel@0 {
				compatible = "simple-panel-dsi";
				unprepare-delay-ms = < 0x3c >;
				prepare-delay-ms = < 0x3c >;
				disable-delay-ms = < 0x3c >;
				panel-init-sequence = < 0x50002b2 0x50050002 0x808b0500 0x2817805 0x28284 0x5000283 0x88050002 0x84a80500 0x285e305 0x28688 >;
				dsi,lanes = < 0x02 >;
				dsi,format = < 0x00 >;
				status = "okay";
				phandle = < 0x7a >;
				reg = < 0x00 >;
				enable-delay-ms = < 0x3c >;
				dsi,flags = < 0x07 >;

				port {

					endpoint {
						remote-endpoint = < 0x79 >;
						phandle = < 0x78 >;
					};
				};

				display-timings {

					timings {
						hsync-active = < 0x00 >;
						vsync-active = < 0x00 >;
						hsync-len = < 0x04 >;
						hfront-porch = < 0x68 >;
						vfront-porch = < 0x04 >;
						pixelclk-active = < 0x00 >;
						vsync-len = < 0x02 >;
						de-active = < 0x00 >;
						vactive = < 0x258 >;
						hback-porch = < 0x7f >;
						clock-frequency = < 0x30a32c0 >;
						hactive = < 0x400 >;
						vback-porch = < 0x03 >;
					};
				};
			};
		};

Any ideas from your side?
Would be great to get some hints.

Thanks

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

Re: VC4 Video Driver dont start DSI Interface

Mon Aug 17, 2020 4:30 pm

Which kernel do you use and which RPI do you try with.

Latest kernel has issues with DSI; try 4.19.xx

hedie
Posts: 13
Joined: Mon Aug 17, 2020 12:26 pm

Re: VC4 Video Driver dont start DSI Interface

Tue Aug 18, 2020 5:32 am

Thank you for your answer.

I am using a CM3+ Module together with the latest Raspbian

Raspberry Pi OS (32-bit) with desktop
Image with desktop based on Debian Buster
Version: May 2020
Release date: 2020-05-27
Kernel version: 4.19
Size: 1128 MB

I have also tested the CM3+ with an original 7" TFT. This is working out of the box as long as i add the dt-blob.bin from here:
https://www.raspberrypi.org/documentati ... display.md

Interesting is, that when i am using the original TFT, both DSI-HW (DSI0 and DSI1) are disabled in the devicetree. But the Display is working anyway.

Ok, it looks like that i am using Kernel 4.19. I will try now an image with Kernel 4.18

hedie
Posts: 13
Joined: Mon Aug 17, 2020 12:26 pm

Re: VC4 Video Driver dont start DSI Interface

Tue Aug 18, 2020 6:24 am

Now i have changed to an older version of Raspbian

This has kernel version 4.14.98-v7+

The output of dmesg after applying the above mentioned overlay looks as following:

Code: Select all

[    3.160842] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok
[    3.161775] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[    3.161994] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
[    3.189705] vc4-drm soc:gpu: bound 3f700000.dsi (ops vc4_dsi_ops [vc4])
[    3.189824] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[    3.190106] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
[    3.190314] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
[    3.190531] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
[    3.219086] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
[    3.222903] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[    3.222918] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    3.222923] [drm] Driver supports precise vblank timestamp query.
[    3.268862] Console: switching to colour frame buffer device 90x30
[    3.291753] vc4-drm soc:gpu: fb0:  frame buffer device
[    3.908643] random: crng init done
[    3.908679] random: 7 urandom warning(s) missed due to ratelimiting
[    4.284424] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[    4.284657] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    4.513511] Adding 102396k swap on /var/swap.  Priority:-2 extents:1 across:102396k SSFS
[    5.894966] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[    5.895458] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC1E1
[    9.491415] fuse init (API version 7.26)
Now the vc4 binds to the dsi

Code: Select all

[    3.189705] vc4-drm soc:gpu: bound 3f700000.dsi (ops vc4_dsi_ops [vc4])
But there is no further message or other output related to DSI.
If i run

Code: Select all

dtc -I fs /sys/firmware/devicetree/base
i can see, that the overlay has been applied correctly, since DSI1 is enabled and a Panel has been attached with a compatible panel-simple-dsi

Do i have to also apply the dt-blob.bin file?

EDIT:
I have also applied the dt-blob.bin file without any changes to the DMESG output.

hedie
Posts: 13
Joined: Mon Aug 17, 2020 12:26 pm

Re: VC4 Video Driver dont start DSI Interface

Tue Aug 18, 2020 6:47 am

update:

If i remove my overlay from the config.txt, the dmesg output looks different:

Code: Select all

[    3.252520] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[    3.252738] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
[    3.252841] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[    3.253110] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
[    3.253321] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
[    3.253536] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
[    3.285361] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
This time, there is no .dsi section.
This let me assume, that my overlay works partly. But i dont know why the display doesnt get initialized.

I expect to see messages like these (from the topic mentioned in the first post)

Code: Select all

[    7.027441] panel-jdi-lt070me05000 3f700000.dsi.0: dsi_dcs_bl_update_status: 365
[    7.372603] panel-jdi-lt070me05000 3f700000.dsi.0: jdi_panel_get_modes: 323
[    7.374655] panel-jdi-lt070me05000 3f700000.dsi.0: jdi_panel_prepare: 237

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

Re: VC4 Video Driver dont start DSI Interface

Tue Aug 18, 2020 11:22 am

A few device tree quirks here.

Normally your display wouldn't be under the dsi node - it'd sit on it's own probably at the root of the tree as it doesn't belong to the SOC itself. I suppose it's a cousin to the DSI peripheral, unlike I2C connected peripherals which are definitely children to the I2C controller.

Secondly the compatible string that you've used of

Code: Select all

compatible = "simple-panel-dsi";
doesn't match any in the panel-simple driver, so device tree doesn't load a driver :-/

If you look at https://elixir.bootlin.com/linux/v4.19. ... le.c#L2821

Code: Select all

static int panel_simple_dsi_probe(struct mipi_dsi_device *dsi)
{
	const struct panel_desc_dsi *desc;
	const struct of_device_id *id;
	int err;

	id = of_match_node(dsi_of_match, dsi->dev.of_node);
	if (!id)
		return -ENODEV;

	desc = id->data;

	err = panel_simple_probe(&dsi->dev, &desc->desc);
	if (err < 0)
		return err;
So if it can't find a match for your compatible string in the table dsi_of_match, then it aborts with -ENODEV. If not it would be dereferencing a NULL pointer to try and get the config from.

Your panel timings should be specified via an entry in the driver, and adding a display-timings entry is a way to override the default timings. Using the compatible string of "auo,b080uan01" I get the driver loading, although it obviously fails to initialise the display as I don't have one.
As I'm only worrying about getting the driver to load, I'm still on 5.4.58 and a Pi4, but modetest reports the display as present

Code: Select all

Encoders:
id      crtc    type    possible crtcs  possible clones 
31      67      TMDS    0x00000004      0x00000000
37      0       TMDS    0x00000008      0x00000000
39      60      DSI     0x00000002      0x00000000
45      0       Virtual 0x00000000      0x00000000
...
40      39      connected       DSI-1           108x272         1       39
  modes:
        index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  #0 1200x1920 60.00 1200 1262 1266 1328 1920 1929 1931 1939 154500 flags: ; type: preferred, driver
  props:
        1 EDID:
                flags: immutable blob
                blobs:

                value:
        2 DPMS:
                flags: enum
                enums: On=0 Standby=1 Suspend=2 Off=3
                value: 0
        5 link-status:
                flags: enum
                enums: Good=0 Bad=1
                value: 0
        6 non-desktop:
                flags: immutable range
                values: 0 1
                value: 0
        4 TILE:
                flags: immutable blob
                blobs:

                value:
It hasn't apparently done anything with the timings, but that looks to be because panel-simple looks for a child called "panel-timing", not "display-timings / timing".

Checking in more detail, the description at the top of panel-simple.c
https://elixir.bootlin.com/linux/v5.4.5 ... mple.c#L42

Code: Select all

 * @modes: Pointer to array of fixed modes appropriate for this panel.  If
 *         only one mode then this can just be the address of this the mode.
 *         NOTE: cannot be used with "timings" and also if this is specified
 *         then you cannot override the mode in the device tree.
 * @num_modes: Number of elements in modes array.
 * @timings: Pointer to array of display timings.  NOTE: cannot be used with
 *           "modes" and also these will be used to validate a device tree
 *           override if one is present.
 * @num_timings: Number of elements in timings array.
So for a specific panel compatible string it either defines a list of modes which are then fixed, or a list of potential timings against which DT is validated.
All the DSI panels defined in panel-simple list modes, therefore you have to add in a new definition. It would seem logical to me to add in a "dummy" entry with very open-ended timings that allow you to configure it from DT, but this is all upstream code that would require some discussion with upstream to get it accepted.

Also currently you can't set the number of DSI lanes, flags, format from DT. It'd be nice if you could, but not currently.
And I'm not sure where your various delay values came from - nothing will be processing them.

...

Ah, I've just noted "panel_dpi" as a defined compatible string for DPI panels - https://elixir.bootlin.com/linux/v5.8/s ... le.c#L4032
That would allow you to set all the timings for a DPI panel from DT. There is currently no equivalent for "panel-dsi", so you have to add it to the driver with a new compatible string.
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.

hedie
Posts: 13
Joined: Mon Aug 17, 2020 12:26 pm

Re: VC4 Video Driver dont start DSI Interface

Tue Aug 18, 2020 11:34 am

Thank you very much for your answer.
Ok i see. This means that i have to compile my own kernel with my own panel driver?

I have used an rockchip RK3288 Chip in a previous project together with armbian.
The rockchip kernel seems to have such a universal driver available

https://gitlab.com/TeeFirefly/linux-ker ... -panel.txt

The Driver itself resides here: https://gitlab.com/TeeFirefly/linux-ker ... l-simple.c

This is where i have got the dt-settings from and it was also working properly with the MAAXBOARD (Rockchip Board from Avnet)
So it would be great to get the same driver to the raspberry.

But actually it looks like that the next steps i have to take is:

1) find a panel driver which is close to my panel
2) copy and modify this driver
3) compile the kernel
4) build a new raspbian dristribution together with the new kernel

About 4)
Is there an other, easy way to just load the new kernel?
Or is it enough to just compile ko modules and load the approrpiate kernel ko module into the running raspbian?

Thanks!

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

Re: VC4 Video Driver dont start DSI Interface

Tue Aug 18, 2020 12:08 pm

It looks like Rockchip started discussions upstream, but didn't follow it through. https://gitlab.com/TeeFirefly/linux-ker ... 3143e70fa6 links to a patch on the mailing list.

I'm not sure that is the correct solution as it adds a lot of checks for the desc. It also differs from the panel-dpi implementation that has been accepted upstream.
Rockchip have a habit of being a long way behind the latest kernel developments - the last kernel of theirs I looked at was still 4.4.
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.

hedie
Posts: 13
Joined: Mon Aug 17, 2020 12:26 pm

Re: VC4 Video Driver dont start DSI Interface

Tue Aug 18, 2020 12:13 pm

What would be your suggestion to me to get the DSI-Display up and running as painless as possible?

Just adding a new panel driver or copy and paste the simple-panel.c from rockchip, cross fingers, and see whether it will get compiled and if not, see whether the errors can be fixed?

Cause it would be very nice to have a "universal" driver as the rockip one is.
Adjusting the timing from the devicetree has worked great with the rockchip driver.

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

Re: VC4 Video Driver dont start DSI Interface

Tue Aug 18, 2020 12:18 pm

Actually finding the relevant patches on the mailing list, configuring video timings from DT was rejected - https://sietch-tagr.blogspot.com/2016/0 ... ecial.html

I'd need to look through more history to find when adding timings via panel-dpi was added and why the change of heart there.
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.

hedie
Posts: 13
Joined: Mon Aug 17, 2020 12:26 pm

Re: VC4 Video Driver dont start DSI Interface

Tue Aug 18, 2020 12:34 pm

Thank you for your answer.

I will try to compile the kernel and get the simple-panel-dsi driver into it.

Would be great to here more about the history, why this approach has been rejected.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4051
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: VC4 Video Driver dont start DSI Interface

Tue Aug 18, 2020 12:38 pm

Upstream are very picky about what should go in Device Tree (descriptions of hardware that can't describe itself in the way that, say, USB can) and what shouldn't (configuration of that hardware, anything OS-specific).

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

Re: VC4 Video Driver dont start DSI Interface

Tue Aug 18, 2020 1:23 pm

It seems Thierry Reding was the main objector, although Rob Herring (main DT maintainer) also wasn't keen generally.

https://lists.freedesktop.org/archives/ ... 09787.html

If I can find the conclusion to the discussions that actually permitted "panel-dpi" to be acceptable as a comaptible string, then I'll see if I can apply the same logic for a panel-dsi.
From my reading so far, I think the objection is mainly down to keeping panel-simple simple. Any form of initialisation requires a driver and unique compatible string. Your "panel-init-sequence" is going to fall into that category.
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.

hedie
Posts: 13
Joined: Mon Aug 17, 2020 12:26 pm

Re: VC4 Video Driver dont start DSI Interface

Tue Aug 18, 2020 1:30 pm

Thank you so much for your support.

But, there are thousands of different panels out there. it would be absolutley overkill if we have to create an own driver, or at least an own entry somwhere for every panel as long as the panel only needs some different initialisation strings which could be inserted into the DT.

It would be much much easier and much cleaner to handle the initialisation in the DT.

I think you also agree with me. Now we must convice the linux community or, linus itslef :)

I hope that we can make some progress here...
Thanks for your support!

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

Re: VC4 Video Driver dont start DSI Interface

Tue Aug 18, 2020 2:07 pm

OK, having read through, the main objection is over whether the panel is described simply enough for DT to fully describe it under all situations.
If the timings are baked into DT using a generic compatible, then there is no way to fix it later in a backwards compatible way - you can't go altering what "panel-dpi" means. If you look at the mailing lists for panel-simple, panel-dpi already has a number of proposed additional (optional) parameters since it was accepted.

Note panel-dpi was only added with the 5.7 release. It is not there in any earlier kernel.

DSI is likely to be worse than DPI. Panels often have initialisation sequences, delays, multiple power rails, and shutdown or reset GPIOs. The simple generic driver is not the place for supporting all that lot.
panel-simple states that explicitly

Code: Select all

  This binding file is a collection of the simple (dumb) panels that
  requires only a single power-supply.
  There are optionally a backlight and an enable GPIO.
  The panel may use an OF graph binding for the association to the display,
  or it may be a direct child node of the display.
  If the panel is more advanced a dedicated binding file is required.
as does panel-simple-dsi

Code: Select all

  This binding file is a collection of the DSI panels that
  requires only a single power-supply.
  There are optionally a backlight and an enable GPIO.
  The panel may use an OF graph binding for the association to the display,
  or it may be a direct child node of the display.
  If the panel is more advanced a dedicated binding file is required.
Actually I can't see a way with panel-dpi to specify the bus_format, so how do you setup RGB888 vs RGB666, etc. It gained a data-mapping property, which was then dropped again. I don't see a merged proposal that reinstates any mechanism to select the format, so the vc4 driver will always drive RGB888 for those panels.

I'm rather losing the enthusiasm to keep following the breadcrumbs on this. I don't see a complete solution in mainline, and the preference is for timings to be baked in via a dedicated compatible string. Anything we do downstream is likely to be superceded by something from mainline, at which point it becomes a maintenance burden.
We could fork panel-simple.c to do our own thing under a raspberrypi compatible string to avoid conflicts, but I'm not sure we aren't just causing grief.

PhilE - your view?
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.

hedie
Posts: 13
Joined: Mon Aug 17, 2020 12:26 pm

Re: VC4 Video Driver dont start DSI Interface

Wed Aug 19, 2020 8:07 am

I would like to share a short update with you.

I have now tried to add the simple-panel-dsi driver from the rockchip linux kernel into the raspberry-linux kernel 4.14.114.
For this i have copy pasted the content of simple-panel.c from rockchip and also adjusted the drm_panel.h

After these two modifications i was able to fully compile the whole kernel.
After that, i have transfered the kernel and all its new modules to the rpi and bootet from it.

It looks like that the changes were overtaken but there is an error.

This is the dmesg output.

Does anybody has an idea how to debug this error further?
Would be great to hear your ideas. Thank you.

Code: Select all

[    3.207792] vc4-drm soc:gpu: bound 3f700000.dsi (ops vc4_dsi_ops [vc4])
[    3.207926] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[    3.208314] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
[    3.208646] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
[    3.208968] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
[    3.232089] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
[    3.239142] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[    3.239161] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    3.239166] [drm] Driver supports precise vblank timestamp query.
[    3.268276] Console: switching to colour frame buffer device 90x30
[    3.288989] vc4-drm soc:gpu: fb0:  frame buffer device
[    3.358022] panel-simple-dsi 3f700000.dsi.0: 3f700000.dsi.0 supply power not found, using dummy regulator
[    3.358130] panel-simple-dsi 3f700000.dsi.0: panel_simple_dsi_parse_dcs_cmds: dcs_cmd=5 len=40, cmd_cnt=8
[    3.413993] Unable to handle kernel NULL pointer dereference at virtual address 00000008
[    3.422416] pgd = b795c000
[    3.425240] [00000008] *pgd=378ee835, *pte=00000000, *ppte=00000000
[    3.431772] Internal error: Oops: 17 [#1] SMP ARM
[    3.436628] Modules linked in: panel_simple vc4 drm_kms_helper drm snd_soc_core snd_bcm2835(C) snd_compress snd_pcm_dmaengine syscopyarea sysfillrect snd_pcm sysimgblt fb_sys_fops snd_timer snd i2c_bcm2835 uio_pdrv_genirq uio fixed i2c_dev ip_tables x_tables ipv6
[    3.460723] CPU: 0 PID: 186 Comm: plymouthd Tainted: G         C      4.14.114-v7-custom+ #1
[    3.469419] Hardware name: BCM2835
[    3.472928] task: b9a50f00 task.stack: b795a000
[    3.477734] PC is at handle_conflicting_encoders+0x124/0x2c4 [drm_kms_helper]
[    3.485356] LR is at drm_mode_object_put.part.0+0x44/0x80 [drm]
[    3.491460] pc : [<7f261998>]    lr : [<7f1f3908>]    psr: 60000013
[    3.497920] sp : b795bc58  ip : b795bc00  fp : b795bcac
[    3.503305] r10: 7f26d4b4  r9 : 00000000  r8 : b6d13c30
[    3.508691] r7 : 00000001  r6 : b7a58a40  r5 : 00000000  r4 : 00000000
[    3.515418] r3 : 00000006  r2 : 00000000  r1 : 00000000  r0 : b6d13c30
[    3.522147] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[    3.529501] Control: 10c5383d  Table: 3795c06a  DAC: 00000055
[    3.535424] Process plymouthd (pid: 186, stack limit = 0xb795a210)
[    3.541793] Stack: (0xb795bc58 to 0xb795c000)
[    3.546287] bc40:                                                       b780dd70 b795bccc
[    3.554722] bc60: b7a5bd00 bbbbbbbb b795bc84 b795bc78 80798d58 7f26d36c b780dc00 b6d13c30
[    3.563157] bc80: 7f1e3558 b6d12800 b983b010 00000054 00000003 b7a58a40 00000001 b9e07000
[    3.571592] bca0: b795bd1c b795bcb0 7f262844 7f261880 014000c0 00000020 b795bd04 807a716c

This is the corresponding probing section:

Code: Select all

static int panel_simple_dsi_probe(struct mipi_dsi_device *dsi)
{
	struct panel_simple *panel;
	const struct panel_desc_dsi *desc;
	const struct of_device_id *id;
	const struct panel_desc *pdesc;
	const void *data;
	int len;
	u32 val;
	int err;

	id = of_match_node(dsi_of_match, dsi->dev.of_node);
	if (!id)
		return -ENODEV;

	desc = id->data;

	if (desc) {
		dsi->mode_flags = desc->flags;
		dsi->format = desc->format;
		dsi->lanes = desc->lanes;
		pdesc = &desc->desc;
	} else {
		pdesc = NULL;
	}

	err = panel_simple_probe(&dsi->dev, pdesc);
	if (err < 0)
		return err;

	panel = dev_get_drvdata(&dsi->dev);
	panel->dsi = dsi;

	if (!of_property_read_u32(dsi->dev.of_node, "dsi,flags", &val))
		dsi->mode_flags = val;

	if (!of_property_read_u32(dsi->dev.of_node, "dsi,format", &val))
		dsi->format = val;

	if (!of_property_read_u32(dsi->dev.of_node, "dsi,lanes", &val))
		dsi->lanes = val;

	data = of_get_property(dsi->dev.of_node, "panel-init-sequence", &len);
	if (data) {
		panel->on_cmds = devm_kzalloc(&dsi->dev,
					      sizeof(*panel->on_cmds),
					      GFP_KERNEL);
		if (!panel->on_cmds)
			return -ENOMEM;

		err = panel_simple_dsi_parse_dcs_cmds(&dsi->dev, data, len,
						      panel->on_cmds);
		if (err) {
			dev_err(&dsi->dev, "failed to parse panel init sequence\n");
			return err;
		}
	}

	data = of_get_property(dsi->dev.of_node, "panel-exit-sequence", &len);
	if (data) {
		panel->off_cmds = devm_kzalloc(&dsi->dev,
					       sizeof(*panel->off_cmds),
					       GFP_KERNEL);
		if (!panel->off_cmds)
			return -ENOMEM;

		err = panel_simple_dsi_parse_dcs_cmds(&dsi->dev, data, len,
						      panel->off_cmds);
		if (err) {
			dev_err(&dsi->dev, "failed to parse panel exit sequence\n");
			return err;
		}
	}

	return mipi_dsi_attach(dsi);
}

hedie
Posts: 13
Joined: Mon Aug 17, 2020 12:26 pm

Re: VC4 Video Driver dont start DSI Interface

Wed Aug 19, 2020 11:08 am

I have a status update

I was able to evaluate the error a little bit more.

This is the actual output of dmesg:

Code: Select all

[    3.423407] panel-simple-dsi 3f700000.dsi.0: 3f700000.dsi.0 supply power not found, using dummy regulator
[    3.423525] panel-simple-dsi 3f700000.dsi.0: Try to read panel-init-sequence...
[    3.423542] panel-simple-dsi 3f700000.dsi.0: panel_simple_dsi_parse_dcs_cmds: dcs_cmd=5 len=40, cmd_cnt=8
[    3.423549] panel-simple-dsi 3f700000.dsi.0: Try to read panel-exit-sequence...
[    3.423557] panel-simple-dsi 3f700000.dsi.0: Panel Exit Sequence read....
[    3.423564] panel-simple-dsi 3f700000.dsi.0: Try to attach dsi to mipi_dsi_attach
[    3.423599] panel-simple-dsi 3f700000.dsi.0: Attaching done... Res: 0
[    3.436327] vc4-drm soc:gpu: fb0:  frame buffer device
[    3.558125] Unable to handle kernel NULL pointer dereference at virtual address 00000008
[    3.566748] pgd = b7d6c000
[    3.569596] [00000008] *pgd=37c46835, *pte=00000000, *ppte=00000000
[    3.576179] Internal error: Oops: 17 [#1] SMP ARM
[    3.581068] Modules linked in: panel_simple vc4 drm_kms_helper drm snd_soc_core snd_bcm2835(C) snd_compress snd_pcm_dmaengine snd_pcm syscopyarea sysfillrect sysimgblt fb_sys_fops snd_timer snd i2c_bcm2835 fixed uio_pdrv_genirq uio i2c_dev ip_tables x_tables ipv6
[    3.605362] CPU: 3 PID: 184 Comm: plymouthd Tainted: G         C      4.14.114-v7-custom+ #1
[    3.614139] Hardware name: BCM2835
[    3.617752] task: b7ce4b00 task.stack: b7d5e000
[    3.622684] PC is at handle_conflicting_encoders+0x124/0x2c4 [drm_kms_helper]
[    3.630456] LR is at drm_mode_object_put.part.0+0x44/0x80 [drm]
[    3.636639] pc : [<7f269998>]    lr : [<7f1fb908>]    psr: 60000013
[    3.643169] sp : b7d5fc58  ip : b7d5fc00  fp : b7d5fcac
[    3.648704] r10: 7f2754b4  r9 : 00000000  r8 : b9eb8030
[    3.654171] r7 : 00000001  r6 : b7db3b80  r5 : 00000000  r4 : 00000000
[    3.661011] r3 : 00000006  r2 : 00000000  r1 : 00000000  r0 : b9eb8030
[    3.667795] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[    3.675192] Control: 10c5383d  Table: 37d6c06a  DAC: 00000055
[    3.681191] Process plymouthd (pid: 184, stack limit = 0xb7d5e210)
....
As you can see, there are new messages.
This is because i have modified the probing function of panel-simple.c for simple-panel-dsi

Code: Select all

...
	dev_info(&dsi->dev, "Try to attach dsi to mipi_dsi_attach");
	int res = mipi_dsi_attach(dsi);
	dev_info(&dsi->dev, "Attaching done... Res: %d", res);
	return res;
}
It seems, that nullpointer exception arises AFTER returning out of the probing function.
But what is done after the probing function?

Could my DT-Structure cause such a problem?
Because i have not changed the order of my nodes. panel@0 is still under the DSI1 node.

It looks like that " handle_conflicting_encoders" has something to do with this error.
https://elixir.bootlin.com/linux/v4.8/s ... lper.c#L92

if i remove the vc4 overlay, all errors are gone, but there is also not dsi initialisation anymore.

Code: Select all

dtoverlay=vc4-kms-v3d
I have also enabled the drm.debug=0x1ff flag and got this output:

https://pastebin.com/NmRmZKhn

hedie
Posts: 13
Joined: Mon Aug 17, 2020 12:26 pm

Re: VC4 Video Driver dont start DSI Interface

Thu Aug 20, 2020 6:04 am

Any ideas?

hedie
Posts: 13
Joined: Mon Aug 17, 2020 12:26 pm

Re: VC4 Video Driver dont start DSI Interface

Fri Aug 21, 2020 7:23 am

push...

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

Re: VC4 Video Driver dont start DSI Interface

Fri Aug 21, 2020 9:28 am

Sorry, I don't have much to add.

The Rockchip extensions to panel-simple are for their platforms, and may or may not be done in a generic way, so may be missing some extra part that the Pi stack needs.

Have you still got the HDMI plugged in? handle_conflicting_encoders is trying to rationalise the list of requested output devices against the potential crtcs. Add some extra logging in there to work out which pointer is NULL that is being dereferenced. I don't see anything significantly changed in there between 4.19 and 5.8, so it's most likely a panel driver issue rather than framework one.
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.

hedie
Posts: 13
Joined: Mon Aug 17, 2020 12:26 pm

Re: VC4 Video Driver dont start DSI Interface

Fri Aug 21, 2020 9:39 am

Thanks for your answer.

No, i dont have HDMI plugged in.

I would like to use addr2line to see where the PC ist actually. But for this, i need to tell the kernel to not use the virtual address space.
Normally i would add nokaslr to the cmd line but unfortunately this doesnt seem to work.

Do you have any idea how to disable the address virtualisation for the rpi?

Thanks

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

Re: VC4 Video Driver dont start DSI Interface

Sun Aug 23, 2020 7:01 am

I normally just stick additional logging messages into the kernel to print out likely looking pointer derefs, and rebuild the kernel.
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.

msl
Posts: 190
Joined: Tue Jul 07, 2020 9:12 pm
Location: Munich
Contact: Website Twitter

Re: VC4 Video Driver dont start DSI Interface

Wed Aug 26, 2020 4:19 pm

6by9 wrote:
Tue Aug 18, 2020 1:23 pm
It seems Thierry Reding was the main objector, although Rob Herring (main DT maintainer) also wasn't keen generally.

https://lists.freedesktop.org/archives/ ... 09787.html

If I can find the conclusion to the discussions that actually permitted "panel-dpi" to be acceptable as a comaptible string, then I'll see if I can apply the same logic for a panel-dsi.
From my reading so far, I think the objection is mainly down to keeping panel-simple simple. Any form of initialisation requires a driver and unique compatible string. Your "panel-init-sequence" is going to fall into that category.
If that means something, I’d vote for Raspberry Pi universal DSI driver, where one can define flags, format, lanes, resolution, clock and init sequence in DT. Why? You’d be able use most of DSI panels with this driver, no need to recompile kernel and spend days for something that can be done in one hour.
I can agree on some arguments for conservative “one panel - one driver” approach in general, but to me Raspberry Pi community is more “hacking” than “canonical”. The only reason not to do this is fear for “beginners avalanche”, where lot of people will be asking for support on random undocumented DSI panels from AliExpress with connectors hard to solder (hello, solder bridges) and mixed up supply voltages (bye, little blue spirit, that used to live in the chip)

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

Re: VC4 Video Driver dont start DSI Interface

Thu Aug 27, 2020 7:35 am

msl wrote:
Wed Aug 26, 2020 4:19 pm
6by9 wrote:
Tue Aug 18, 2020 1:23 pm
It seems Thierry Reding was the main objector, although Rob Herring (main DT maintainer) also wasn't keen generally.

https://lists.freedesktop.org/archives/ ... 09787.html

If I can find the conclusion to the discussions that actually permitted "panel-dpi" to be acceptable as a comaptible string, then I'll see if I can apply the same logic for a panel-dsi.
From my reading so far, I think the objection is mainly down to keeping panel-simple simple. Any form of initialisation requires a driver and unique compatible string. Your "panel-init-sequence" is going to fall into that category.
If that means something, I’d vote for Raspberry Pi universal DSI driver, where one can define flags, format, lanes, resolution, clock and init sequence in DT. Why? You’d be able use most of DSI panels with this driver, no need to recompile kernel and spend days for something that can be done in one hour.
I can agree on some arguments for conservative “one panel - one driver” approach in general, but to me Raspberry Pi community is more “hacking” than “canonical”. The only reason not to do this is fear for “beginners avalanche”, where lot of people will be asking for support on random undocumented DSI panels from AliExpress with connectors hard to solder (hello, solder bridges) and mixed up supply voltages (bye, little blue spirit, that used to live in the chip)
Nice idea but sadly will not work! There is no standard for DSI panels, so init sequence, required control signals etc are different all the time. How should a 'generic DSI driver' deal with that?


@6by9: is DSI issue fixed in kernel 5.4.51 (2020-08-20 OS release) or do we need to keep using 4.19 for 'toying' around with DSI displays (other than official one)?

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

Re: VC4 Video Driver dont start DSI Interface

Thu Aug 27, 2020 9:12 am

aBUGSworstnightmare wrote:
Thu Aug 27, 2020 7:35 am
@6by9: is DSI issue fixed in kernel 5.4.51 (2020-08-20 OS release) or do we need to keep using 4.19 for 'toying' around with DSI displays (other than official one)?
Sorry, not fixed as yet.
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 “Compute Module”