Dear Team,
We using a custom board based on RZ/G2L and RGB to LVDS connected by a SN75LVDS83ADGGR flat transmitter. We have written the dtsi code for rgb according to this renesas website, ie https://renesas.info/wiki/RZ-G/RZG_DeviceTree#Display . We have connected 4 channel 24 bit lvds and the device tree as follows:
rgb-dummy { compatible = "renesas,rgb-dummy"; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; rgb_in: endpoint { remote-endpoint = <&du_out_rgb>; }; }; port@1 { reg = <1>; rgb_out: endpoint { remote-endpoint = <&panel_in>; }; }; }; }; panel { compatible = "dlc,dlc1010gig";/*edited*/ power-supply = <&vcc_lcd_reg>; backlight = <&backlight>; status = "okay"; port { panel_in: endpoint { remote-endpoint = <&rgb_out>; }; }; }; }; &pinctrl { du_pins: du { data { pinmux = <RZG2L_PORT_PINMUX(7, 2, 1)>, <RZG2L_PORT_PINMUX(8, 0, 1)>, <RZG2L_PORT_PINMUX(8, 1, 1)>, <RZG2L_PORT_PINMUX(8, 2, 1)>, <RZG2L_PORT_PINMUX(9, 0, 1)>, <RZG2L_PORT_PINMUX(9, 1, 1)>, <RZG2L_PORT_PINMUX(10, 0, 1)>, <RZG2L_PORT_PINMUX(10, 1, 1)>, <RZG2L_PORT_PINMUX(11, 0, 1)>, <RZG2L_PORT_PINMUX(11, 1, 1)>, <RZG2L_PORT_PINMUX(12, 0, 1)>, <RZG2L_PORT_PINMUX(12, 1, 1)>, <RZG2L_PORT_PINMUX(13, 0, 1)>, <RZG2L_PORT_PINMUX(13, 1, 1)>, <RZG2L_PORT_PINMUX(13, 2, 1)>, <RZG2L_PORT_PINMUX(14, 0, 1)>, <RZG2L_PORT_PINMUX(14, 1, 1)>, <RZG2L_PORT_PINMUX(15, 0, 1)>, <RZG2L_PORT_PINMUX(15, 1, 1)>, <RZG2L_PORT_PINMUX(16, 0, 1)>, <RZG2L_PORT_PINMUX(16, 1, 1)>, <RZG2L_PORT_PINMUX(17, 0, 1)>, <RZG2L_PORT_PINMUX(17, 1, 1)>, <RZG2L_PORT_PINMUX(17, 2, 1)>; }; sync { pinmux = <RZG2L_PORT_PINMUX(6, 1, 1)>, /* HSYNC */ <RZG2L_PORT_PINMUX(7, 0, 1)>; /* VSYNC */ }; de { pinmux = <RZG2L_PORT_PINMUX(7, 1, 1)>; /* DE */ }; clk { pinmux = <RZG2L_PORT_PINMUX(6, 0, 1)>; /* CLK */ }; }; };
1. There is no error showing in the kernel. But it is not detecting the display as there is no /dev/fb0.
2. There is no clock or signals from RGB.
I am attaching a our RGB to LVDS schematic part for your reference.
Can you please suggest any software changes ? Is there any change in panel-simple.c code for display timings and panel info?. Please help.
Check to see if it finds your panel on boot.
Put a printk in function panel_simple_dsi_probe( ) to make sure it matches up what you put in the Device Tree.
Also keep in mind that you need to set CONFIG_DRM_PANEL_SIMPLE…
Also keep in mind that you need to set CONFIG_DRM_PANEL_SIMPLE=y in your kernel config to enable the panel simple driver.
Thanks for your reply,
We are not using mipi-dsi module, but rgb to lvds. So i don't know why we are checking panel_simple_dsi_probe? There is not hdmi adv7535 in our board. And CONFIG_DRM_PANEL_SIMPLE=y set in kernel.
No its not finding panel in the boot.
rcar-du 10890000.display: Error applying setting, reverse things back
rcar-du: probe of 10890000.display failed with error -22
=> It often related to pin settings, please recheck that if any pin conflict occurs.
Well the pins are free. So thats not the problem. The display is not detected by the kernel. There is no panel module in kernel.
Eldhose Peter said:rcar-du 10890000.display: Error applying setting, reverse things back
This error message comes from file: drivers/pinctrl/core.c
/* Apply all the settings for the new state */ list_for_each_entry(setting, &state->settings, node) { switch (setting->type) { case PIN_MAP_TYPE_MUX_GROUP: ret = pinmux_enable_setting(setting); break; case PIN_MAP_TYPE_CONFIGS_PIN: case PIN_MAP_TYPE_CONFIGS_GROUP: ret = pinconf_apply_setting(setting); break; default: ret = -EINVAL; break; } if (ret < 0) { goto unapply_new_state; } /* Do not link hogs (circular dependency) */ if (p != setting->pctldev->p) pinctrl_link_add(setting->pctldev, p->dev); } p->state = state; return 0; unapply_new_state: dev_err(p->dev, "Error applying setting, reverse things back\n");
So, it is not the display driver that has the issue.
If the pin settings cannot be made, the display driver will never get to run. The pin setup done by the kernel before the driver probe routine is run.
You need to find out why the pins cannot be set.
Thanks for your response. The error above i mentioned is due to my mistake. When i checked it I put a lcd pin echo mode manually resulting that error. Sorry for inconvenience.
My problem from the start is that the panel is not getting recognized. It is not loading. rcar-du is not getting loaded. The panel is not getting detected. lcd pin are free.
Is the dummy bridge is correct? Or is it SN75LVDS83ADGGR lvds transmitter? In panel-simple.c which connector should we use? Which bus format?
Chris,
We removed the dummy bridge and we got the display connected, and the display is working but colors shown are wrong and the data sometimes pixelated. The first figure show correct image with correct colors. This is from hdmi out.
Following is the image we got in our lvds display.
Next is the image of an application data is pixelized.
How can we change the format? what is to be done to correct this?
I'm not sure if the following will help you.Weston can take parameter directly from u-bootIn the u-boot parameter you can add the following to bootargsvideo=${videomode}
and set the mode (has to be adapted to your requirements settings/adapter and display)
setenv videomode HDMI-A-1:1920x1080@60
saveenv
In the weston.ini file the following modification/etc/xdg/weston/weston.ini[output]name=HDMI-A-1mode=current
Eldhose Peter said:We removed the dummy bridge and we got the display connected, and the display is working but colors shown are wrong and the data sometimes pixelated.
Can you share your Device Tree without dummy bridge?
Maybe some BSP update caused some change and we need to update the sample device tree for RGB displays.
What BSP version are you using?
More specific, what "branch" is your kernel based off of?
For your colors, that is strange.
The color format of the of the frame buffer is set by register "RPFn Input Format Registers (VI6_RPFn_INFMT)". I think the default set by the kernel is "0x13" which is format ARGB.
Does it look like 2 colors are swapped?
For pixelized data, I think that is screen resolution. Are you sure you are setting the correct panel resolution?
I want to set clock below 40Mhz for display clock. But no matter it doesn't stray from 40mhz. What to do? Yes I am setting correct panel resolution but can't change clock. It's always 40 mhz
What BSP version are you using?: The original driver did not have many clock frequency options. But the driver in the new BSP can set any frequency because it does the PLL and divider math inside the driver at run-time.
Rzg2 3.0.1. Device tree is almost same as rzg2ul but in panel it du_rgb_out and in du is panel_out in Port. Kernel version 5.10.x . How to change or disable automatic frequency setting?
There we many LCD driver changes between BSP 3.0.1 and 3.0.4.Please consider to update. Or, just update the kernel (in Yocto, change the branch and commit that Yocto will check out)
Bsp 3.0.4 works with dummy Bridge or not?. And whether I change clock for lcd or not, it stay at 40mhz when I change in panel-simple.c . Is there any way to change the clock manually not automating it?
There is an internal Renesas document for how to manually set the clock registers in old BSP versions. Please contact your local Renesas person to get it.
"The color format of the of the frame buffer is set by register "RPFn Input Format Registers (VI6_RPFn_INFMT)". I think the default set by the kernel is "0x13" which is format ARGB."
Where can i find the file related to the RPFn Input Format Registers VI6_RPFn_INFMT in the kernel?.
Chris said:The color format of the of the frame buffer is set by register "RPFn Input Format Registers (VI6_RPFn_INFMT)". I think the default set by the kernel is "0x13" which is format ARGB.
how can we find the file to change the VI6_RPFn_INFMT in the kernel. Kindly please advice
Hi Eldhose,Is your issue resolved? If so, then would you like to verify the suggested answer? It is very useful for our community because it may help other users who have a similar issue.Thank you for your time.Kind Regards.
lvds display only works in 18 bit mode not in 24 bit. Following images are 18 bit and 24 bit format.
18 bit is the correct color format. But in 24 bit format we get,
The 2nd one is in 24 bit which the color is in wrong. Please help.
From the RGB -> LVDS converter, I see two connecting diagrams:
From the schematics I can see you are using the second: 24-bit host to 18-bit display.
Can this be the reason of the wrong colors?
Hello Eldhose Peter,Did you resolve your issue? Is there anything else to assist you? Would you like to verify the suggested answer if it was resolved? Kind Regards.