RZ/G2L RGB HAS NO CLOCK OR SIGNALS

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.

Parents
  • 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=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.

  • 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-boot

    In the u-boot parameter you can add the following to bootargs
    video=${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-1
    mode=current


  • 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?.

  • 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

Reply Children