RZ/G2L RGB HAS NO CLOCK OR SIGNALS

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.

You need a "driver" enabled the LCD. And you also need a matching "device" in the device tree. Otherwise the kernel will not know any LCD is attached.
Since RGB is simple, and with the new DRM style of graphics requiring a driver for each LCD panel, it is common to add your LCD to the panel simple driver instead of writing your own.

 I think you refer to panel compatible  as device and structures in panel-simple.c as drivers.  Here it is down below.

panel {
	compatible = "eld,eld00pa";
	power-supply = <&vcc_lcd_reg>;
	backlight = <&backlight>;
	status = "okay";
		
	port {
		panel_in: endpoint {
			remote-endpoint = <&rgb_out>;
		};
	};
	};
	};
	
/*And in panel-simple.c*/

static const struct display_timing eld_eld00pa_timing = {
	.pixelclock = { 6000000, 6000000, 6000000},
	.hactive = { 1024, 1024, 1024 },
	.hfront_porch = { 24, 24, 24 },
	.hback_porch = { 160, 160, 160 },
	.hsync_len = { 136, 136, 136},
	.vactive = { 768, 768, 768 },
	.vfront_porch = { 3, 3, 3},
	.vback_porch = { 29, 29, 29 },
	.vsync_len = { 6, 6, 6 },

};

static const struct panel_desc eld_eld00pa = {
	.timings = &eld_eld00pa_timing,
	.num_timings = 1,
	.bpc = 8,
	.size = {
		.width = 70,
		.height = 53,
	},	
	.delay = {
		.prepare = 50,
		.enable = 200,
		.disable = 110,
		.unprepare = 200,
	},
	
};

/*name of driver in panel-simple.c*/
{
		.compatible = "eld,eld00pa",
		.data = &eld_eld00pa,
	},

Is it above right? But its not working. Which connector type is used to connected to the flat transmitter?. Our display is DLC1040CBP00LF-3 dlc display. Or is there any other changes needed to be done?

Add initcall_debug to your kernel command line to make sure panel driver is getting loaded.

https://renesas.info/wiki/RZ-G/debug_tricks#Using_initcall_debug

At some point, you are not going to find your issue by only changing the Device Tree. You are going to have to put print statements in the drivers to find out what is going on. Or, if you never get into the driver at all, you have to use a JTAG debugger to step through the kernel code to find out why.

Our panel driver is not getting loaded. Kernel reverse things back saying incorrect settings. These are the msg getting.

rcar-du 10890000.display: Error applying setting, reverse things back

rcar-du: probe of 10890000.display failed with error -22

Eldhose Peter said:

rcar-du 10890000.display: Error applying setting, reverse things back

Search the kernel for that error message and find out what file it is in, and why it prints that message.

The rcar-du driver are here:   drivers/gpu/drm/rcar-du/

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

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