Add DPI mode 3 (rgb565-padhi) support to vc4-kms-dpi-generic

[grigorig]

Adds support for DPI mode 3 (a different pin mapping) to the vc4-kms-dpi-generic overlay. This mode is used by some cheap DPI VGA adapters in particular, such as 'VGA565'. It can be used with these like this:

dtoverlay=vc4-kms-dpi-generic
dtparam=hactive=1024,hfp=24,hsync=136,hbp=160
dtparam=vactive=768,vfp=3,vsync=6,vbp=29
dtparam=clock-frequency=65000000
dtparam=rgb565-padhi

I noticed that the overrides weren't working, neither for bus format nor for the pin mapping overrides. I believe a recent refactoring broke this. I included a workaround, but I am not sure how correct it is. My Device Tree knowledge is very limited.

[6by9]

Adding rgb565-padhi looks fine.

I want to check out the other patch. I suspect it's an issue of application order - the overrides update <&panel> or <&dpi_node>, and then fragments 0 & 1 come along and overwrite them. In which case your patch is correct to update fragments 0 & 1 instead of the base nodes.
@pelwell will probably be able to confirm that one immediately to save me running that configuration.

[pelwell]

Yes, the problem is one of application order. Overlay application is split into three phases - preparing the overlay fragments, applying intra-overlay fragments to other fragments, and applying the remaining fragments to the base dtb. In the case of runtime overlay application, the third phase is performed by the kernel.

Without the fixing patch provided here, the parameters are applied to fragment 100's panel node in phase 1, then they are overwritten by the defaults from fragment 0 in phase 2. This fix is one solution - applying the overrides to fragment 0 (and 1 - the same problem applies). The other would be to replace fragments 0 and 1 with code that directly patches the panel and dpi_node nodes:

&panel {
	compatible = "panel-dpi";

	width-mm = <154>;
	height-mm = <83>;
	bus-format = <0x1009>;

	timing: panel-timing {
		clock-frequency = <29500000>;
		hactive = <800>;
		hfront-porch = <24>;
		hsync-len = <72>;
		hback-porch = <96>;
		hsync-active = <1>;
		vactive = <480>;
		vfront-porch = <3>;
		vsync-len = <10>;
		vback-porch = <7>;
		vsync-active = <1>;

		de-active = <1>;
		pixelclk-active = <1>;
	};
};

&dpi_node {
	pinctrl-0 = <&dpi_18bit_gpio0>;
};

That is a large and unnecessary change, but it does reduce the amount of overlay magic needed, relying instead on the dtc compiler to combine chunks.

I did notice an asymmetry between the panel and dpi halves of the overlay. Fragment 0 targets the panel node in fragment 100, while fragment 1 targets the dpi node in the base dtb, which is also targeted by dpi_node in fragment 101. There is no overlay, and therefore no problem, but perhaps fragment 1 was intended to target dpi_node?

[grigorig]

Thanks, I'm starting to understand what's going on. Maybe further cleanups (for better consistency) should be tackled in a separate PR though? I'm mostly a user and just want these features to work. 😅

[pelwell]

I wasn't suggesting you make any changes to your PR. We'll take it as is, since it solves the immediate problem.