Interfacing with SN65DSI83 : DSI TO BRIDGE

[NPal.2]

Hi all,

I am trying to interface SN65DSI83 with STM32MP1.

Below is my device tree:

&ltdc{
 
	status = "okay";
 
	/* USER CODE BEGIN ltdc */
 
	port {
			#address-cells = <1>;
			#size-cells = <0>;
 
			ltdc_ep0_out: endpoint@0 {
				reg = <0>;
				remote-endpoint = <&dsi_in>;
			};
	};
 
	/* USER CODE END ltdc */
};
 
&dsi {
	
	#address-cells = <1>;
	#size-cells = <0>;
	status = "okay";
 
	ports {
		#address-cells = <1>;
		#size-cells = <0>;
 
		port@0 {
			reg = <0>;
			dsi_in: endpoint {
				remote-endpoint = <&ltdc_ep0_out>;
			};
		};
 
		port@1 {
			reg = <1>;
			dsi_out: endpoint {
				remote-endpoint = <&dsi_lvds_bridge_in>;
			};
		};
	};
};
 
&i2c4 {
 dsi_lvds_bridge: sn65dsi83@2c {
 compatible = "ti,sn65dsi83";
 reg = <0x2c>;
 ti,dsi-lanes = <2>;
 ti,lvds-format = <1>;
 ti,lvds-bpp = <24>;
 ti,width-mm = <217>;
 ti,height-mm = <136>;
 enable-gpios = <&gpiob 10 GPIO_ACTIVE_LOW>;
 interrupt-parent = <&gpiob>;
		 interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
 pinctrl-names = "default";
 /* pinctrl-0 = <&pinctrl_lvds>; */
 status = "okay";
 
 display-timings {
 lvds {
 clock-frequency = <66000000>;
 hactive = <1024>;
 vactive = <768>;
 hback-porch = <200>;
 hfront-porch = <0>;
 vback-porch = <38>;
 vfront-porch = <0>;
 hsync-len = <1>;
 vsync-len = <1>;
 hsync-active = <0>;
 vsync-active = <0>;
 de-active = <1>;
 pixelclk-active = <0>;
 };
 };
 
 port {
 dsi_lvds_bridge_in: endpoint {
 remote-endpoint = <&dsi_out>;
 };
 };
 };
};

I have ported the driver available for ti-sn65dsi83 from main linux tree since it is not yet available in the latest release.

However I keep getting following message upon kernel boot:

 sn65dsi83: probe of 0-002c failed with error -22

Any leads will be highly appreciated.

[AntonioST]

I've just run a quick check, I haven't tried to replicate it.

The error -22 is EINVAL, "Invalid argument".

The values in display-timings are quite strange, it's not a usual configuration.

Where did you got them? Are them specifically required for your display panel?

I would suggest you to use at least 2 for {h,v}sync-len, {h,v}front-porch and {h,v}back-porch.

I suspect that one of the zero values causes the invalid argument error.

[NPal.2]

Hi @AntonioST​ : Thanks for the response.

I tried your suggestions but it seems i ended up running into same error.

I ported driver from main linux tree : here. to 5.10-stm32mp kernel.

I did encounter these changes in file : dsi_mipi_drm.h and dsi_mipi_drm.c - for function definitions.

I am not sure whether performing these have caused another issue.

[AntonioST]

There could be many part of the kernel that returns -EINVAL. The simpler way to identify who is returning it, and then why it is returning, is to add some traces with printk() in sn65dsi83_probe().

The change you mention in include/drm/drm_mipi_dsi.h is due to upstream commit 0f3b68b66a6d ("drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling features").

As far as I can see, the patch itself does not impact the code in sn65dsi83 driver nor in the ST DSI driver. I don't expect this to be the reason of the error.

Other point, the sn65dsi83 driver does not use any interrupt. Why you have properties interrupt-parent and interrupts? Can you try removing them?

Maybe I have found it!

I don't know where you copied the devicetree fragment from, but it is not following the specifications for this driver listed here.

All the properties "ti,*" does not exist! And "ti,dsi-lanes = <2>;" must be written as "data-lanes = <2>;". This error triggers -EINVAL here.

[NPal.2]

@AntonioST​ : Thank you for your analysis and response. We did also arrive on same conclusion and now we are past that error.

However, now we are looking at strange issue. There is no trace of any error in dmesg which is related to sn65dsi83. Is it safe to assume driver is loaded? (probably yes).

Now the issue if it got loaded successfully, why can't we see the dsi clk at the clk pin of sn65dsi83. sn65dsi83 derives its clock from the stm32mp1. Here we can see that there is no clock and hence , no resulting video output.

Now if manually configure the sn65dsi83 via i2c we are able to run screen on test mode (no device tree integration , no driver.)

When we try to integrate with the driver and the device tree , it is not working appropriately.

Performing i2c detect provide us output where-in we are able to see : 2c instead of UU .

Attached is the modified device tree.

Thanks for support.

[AntonioST]

> Performing i2c detect provide us output where-in we are able to see : 2c instead of UU.

If you see 2c instead of UU it should mean the device is there on the I2C bus, but there is no driver using the device, so the probe has silently failed.

Why you have this line in DT?

enable-gpios = <&gpiob 10 GPIO_ACTIVE_LOW>;

The binding document uses GPIO_ACTIVE_HIGH in the example and the description reports "GPIO specifier for bridge_en pin (active high)".

From TI datasheet the pin is enable (high) or reset (low).

I suspect this line forces the device in reset during probe, so it does not answer to I2C queries.

I'm also checking this patch upstream. It looks relevant for this I2C bridge. Would you consider backporting it too?

[Kevin HUBER]

Hello @NPal.2​ ,

Did you have a look at the patch provided by Antonio, does it works as expected?

Regards,

Kevin