BPP Setting Not Reflecting on LCD Interface with Custom BeagleBone Board

Hello everyone,

I’m working on a custom BeagleBone board where I’m using the LCD interface to send video data to an FPGA. The EEPROM has been programmed so that the board is recognized as a BeagleBone Green. I’ve set up the following device tree overlay to configure the LCD signals:

/dts-v1/;
/plugin/;

#include "dt-bindings/board/am335x-bbw-bbb-base.h"
#include "dt-bindings/gpio/gpio.h"
#include "dt-bindings/pinctrl/am33xx.h"

/ {
	/* identification */
	part-number = "BB-LCD-TEST";
	version = "00A0";

	fragment@0 {
		target = <&am33xx_pinmux>;
		__overlay__ {

			bb_lcd_lcd_pins: pinmux_bb_lcd_lcd_pins {
				pinctrl-single,pins = <
					BONE_P8_45 (PIN_OUTPUT | MUX_MODE0) /* lcd_data0.lcd_data0 */
					BONE_P8_46 (PIN_OUTPUT | MUX_MODE0) /* lcd_data1.lcd_data1 */
					BONE_P8_43 (PIN_OUTPUT | MUX_MODE0) /* lcd_data2.lcd_data2 */
					BONE_P8_44 (PIN_OUTPUT | MUX_MODE0) /* lcd_data3.lcd_data3 */
					BONE_P8_41 (PIN_OUTPUT | MUX_MODE0) /* lcd_data4.lcd_data4 */
					BONE_P8_42 (PIN_OUTPUT | MUX_MODE0) /* lcd_data5.lcd_data5 */
					BONE_P8_39 (PIN_OUTPUT | MUX_MODE0) /* lcd_data6.lcd_data6 */
					BONE_P8_40 (PIN_OUTPUT | MUX_MODE0) /* lcd_data7.lcd_data7 */
					BONE_P8_37 (PIN_OUTPUT | MUX_MODE0) /* lcd_data8.lcd_data8 */
					BONE_P8_38 (PIN_OUTPUT | MUX_MODE0) /* lcd_data9.lcd_data9 */
					BONE_P8_36 (PIN_OUTPUT | MUX_MODE0) /* lcd_data10.lcd_data10 */
					BONE_P8_34 (PIN_OUTPUT | MUX_MODE0) /* lcd_data11.lcd_data11 */
					BONE_P8_35 (PIN_OUTPUT | MUX_MODE0) /* lcd_data12.lcd_data12 */
					BONE_P8_33 (PIN_OUTPUT | MUX_MODE0) /* lcd_data13.lcd_data13 */
					BONE_P8_31 (PIN_OUTPUT | MUX_MODE0) /* lcd_data14.lcd_data14 */
					BONE_P8_32 (PIN_OUTPUT | MUX_MODE0) /* lcd_data15.lcd_data15 */

					BONE_P8_27 (PIN_OUTPUT | MUX_MODE0) /* lcd_vsync.lcd_vsync */
					BONE_P8_29 (PIN_OUTPUT | MUX_MODE0) /* lcd_hsync.lcd_hsync */
					BONE_P8_28 (PIN_OUTPUT | MUX_MODE0) /* lcd_pclk.lcd_pclk */
					BONE_P8_30 (PIN_OUTPUT | MUX_MODE0) /* lcd_ac_bias_en.lcd_ac_bias_en */

					/*LCD enable */
					BONE_P8_18 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* gpmc_clk_mux0.gpio2_1 */
				>;
			};

		};
	};

	fragment@1 {
		target = <&lcdc>;
		__overlay__ {
			status = "okay";
			blue-and-red-wiring = "crossed";
		};
	};

	fragment@2 {
		target-path="/";
		__overlay__ {

			#address-cells = <1>;
			#size-cells = <1>;

			
			panel {
				status = "okay";
				compatible = "ti,tilcdc,panel";
				pinctrl-names = "default";
				pinctrl-0 = <&bb_lcd_lcd_pins>;
				panel-info {
					ac-bias           = <255>;
					ac-bias-intrpt    = <0>;
					dma-burst-sz      = <16>;
					bpp               = <16>; /* Set BPP to 16 (RGB565) */
					fdd               = <0x80>;
					tft-alt-mode      = <0>;
					stn-565-mode      = <0>;
					mono-8bit-mode    = <0>;
					sync-edge         = <0>;
					sync-ctrl         = <0>;
					raster-order      = <0>;
					fifo-th           = <0>;
				};
				display-timings {
					native-mode = <&timing0>;
					timing0: 1024x1024 {
						clock-frequency = <31230000>;
						hactive = <1024>;
						vactive = <1024>;
						hfront-porch = <16>;
						hback-porch = <113>;
						hsync-len = <97>;
						vback-porch = <12>;
						vfront-porch = <2>;
						vsync-len = <3>;
						hsync-active = <1>;
						vsync-active = <1>;
						pixelclk-active =<1>;
					};
				};
				port {
					panel_port: endpoint@0 {
						remote-endpoint = <&fb_port>;
					};
				};
			};
			fb {
				compatible = "ti,am33xx-tilcdc";
				reg = <0x4830e000 0x1000>;
				interrupt-parent = <&intc>;
				interrupts = <36>;
				ti,hwmods = "lcdc";
				port {
					fb_port: endpoint@0 {
						remote-endpoint = <&panel_port>;
					};
				};
			};
		};
	};
};

After booting, the framebuffer /dev/fb0 appears correctly configured to my specified resolution. I can also verify using an oscilloscope that the LCD signal timings are correct as per the settings in the overlay. However, the BPP (bits per pixel) does not seem to be applying correctly. When I check the value via: cat /sys/class/graphics/fb0/bits_per_pixel , it shows 32 instead of the expected 16. This discrepancy might also be the reason why I see unexpectedly high CPU usage when playing video using mplayer.

The output of dmesg | grep tilcdc and dmesg | grep tilcdc provides the following relevant information:

[    1.052068] tilcdc 4830e000.lcdc: fb0: DRM emulated frame buffer device
[    1.052852] [drm] Initialized tilcdc 1.0.0 20121205 for 4830e000.lcdc on minor 0
[    2.408599] [<c08eae38>] (__pm_runtime_resume) from [<c08c1438>] (tilcdc_init.constprop.2+0x204/0x60c)
[    2.408615] [<c08c1438>] (tilcdc_init.constprop.2) from [<c08c18a0>] (tilcdc_pdev_probe+0x60/0xa8)
[    2.408629] [<c08c18a0>] (tilcdc_pdev_probe) from [<c08dfbfc>] (platform_drv_probe+0x58/0xa8)
[    2.408844] tilcdc 4830e000.fb: use pm_runtime_put_sync_suspend() in driver?
i
[ 0.995407] OF: graph: no port node found in /ocp/lcdc@4830e000
[    1.001554] mmc0: host does not support reading read-only switch, assuming write-enable
[    1.001980] OF: graph: no port node found in /ocp/lcdc@4830e000
[    1.009653] OF: graph: no port node found in /ocp/lcdc@4830e000

Questions:

  1. Why is the bpp not applying as set in the overlay (16 bpp)?
  2. How can I ensure the framebuffer operates in the 16 bpp (RGB565) mode?

Any insights or guidance would be greatly appreciated. Thank you!

My idea may be stupid, but check to set the bpp simply to 8 for testing. Whatever happens, it could bring a new idea of whats the matter.

This assumes ‘fb0’ is accurate. with the move to TIDSS/DRM fb is really emulated, so don’t trust the values it dumps…

Regards,

Hi @Ernst_D ,

Thank you for the suggestion! I went ahead and tried setting the bpp to 8 on the overlay for testing, but unfortunately, it didn’t make any difference, and I still see the bpp as 32.

Hi @RobertCNelson ,

Thank you for your response. Given that /dev/fb0 might be emulated and not reflect the actual values, how can I verify and correctly set the bpp using the TIDSS/DRM system? Is there a way to confirm that the display settings, including bpp, are actually being applied within the TIDSS/DRM framework?

Same idea. Changing values should have any result (whenever a bad one). That missed port node …still no clue, why.

I would check these possibilities: Reduce the picture signal to b/w and, if possible, the resolution for testing. This could answer, whatever causes the high cpu load. In this case, the picrels quality doesn’t play a role. Can You test another display itself for testing? there are often odd effects caused by the panel itself.