aBUGSworstnightmare
Posts: 3141
Joined: Tue Jun 30, 2015 1:35 pm

[SOLVED] Need to define new color mappings to be used with DPI mode 6 (under KMS)

Fri May 28, 2021 3:16 pm

dpi-packing-mode6.jpg
need to use DPI in mode 6
dpi-packing-mode6.jpg (124.84 KiB) Viewed 1277 times
As I need to use DPI interface in mode 6 I've added below to 'bcm270x.dtsi'

Code: Select all

&gpio {
	interrupts = <2 17>, <2 18>;

	dpi_18bit_mode6_gpio0: dpi_18bit_mode6_gpio0 {
		brcm,pins = <0 1 2 3 4 5 6 7 8 9 
			     12 13 14 15 16 17 
			     20 21 22 23 24 25>;
		brcm,function = <BCM2835_FSEL_ALT2>;
	};
	dpi_18bit_mode6_gpio2: dpi_18bit_mode6_gpio2 {
		brcm,pins = <2 3 4 5 6 7 8 9 
			     12 13 14 15 16 17 
			     20 21 22 23 24 25>;
		brcm,function = <BCM2835_FSEL_ALT2>;
	};
	dpi_18bit_gpio0: dpi_18bit_gpio0 {
		brcm,pins = <0 1 2 3 4 5 6 7 8 9 10 11
			     12 13 14 15 16 17 18 19
			     20 21>;
		brcm,function = <BCM2835_FSEL_ALT2>;
	};
	dpi_18bit_gpio2: dpi_18bit_gpio2 {
		brcm,pins = <2 3 4 5 6 7 8 9 10 11
			     12 13 14 15 16 17 18 19
			     20 21>;
		brcm,function = <BCM2835_FSEL_ALT2>;
	};
};
In my DT overlay it then get's used like below

Code: Select all

	fragment@3 {
		target = <&dpi>;
		__overlay__  {
			status = "okay";

			pinctrl-names = "default";
			pinctrl-0 = <&dpi_18bit_mode6_gpio0>;

			port {
				dpi_out: endpoint@0 {
					remote-endpoint = <&panel_in>;
				};
			};
		};
	};
which results in the GPIO being configured for DPI mode (note: target platform for current testing is CM3 + CMIO).

Code: Select all

pi@raspberrypi:~ $ raspi-gpio get
BANK0 (GPIO 0 to 27):
GPIO 0: level=0 fsel=6 alt=2 func=PCLK
GPIO 1: level=0 fsel=6 alt=2 func=DE
GPIO 2: level=1 fsel=6 alt=2 func=LCD_VSYNC
GPIO 3: level=1 fsel=6 alt=2 func=LCD_HSYNC
GPIO 4: level=1 fsel=6 alt=2 func=DPI_D0
GPIO 5: level=0 fsel=6 alt=2 func=DPI_D1
GPIO 6: level=0 fsel=6 alt=2 func=DPI_D2
GPIO 7: level=0 fsel=6 alt=2 func=DPI_D3
GPIO 8: level=0 fsel=6 alt=2 func=DPI_D4
GPIO 9: level=0 fsel=6 alt=2 func=DPI_D5
GPIO 10: level=0 fsel=0 func=INPUT
GPIO 11: level=0 fsel=0 func=INPUT
GPIO 12: level=0 fsel=6 alt=2 func=DPI_D8
GPIO 13: level=0 fsel=6 alt=2 func=DPI_D9
GPIO 14: level=0 fsel=6 alt=2 func=DPI_D10
GPIO 15: level=0 fsel=6 alt=2 func=DPI_D11
GPIO 16: level=0 fsel=6 alt=2 func=DPI_D12
GPIO 17: level=0 fsel=6 alt=2 func=DPI_D13
GPIO 18: level=0 fsel=0 func=INPUT
GPIO 19: level=0 fsel=2 alt=5 func=PWM1
GPIO 20: level=0 fsel=6 alt=2 func=DPI_D16
GPIO 21: level=0 fsel=6 alt=2 func=DPI_D17
GPIO 22: level=0 fsel=6 alt=2 func=DPI_D18
GPIO 23: level=0 fsel=6 alt=2 func=DPI_D19
GPIO 24: level=0 fsel=6 alt=2 func=DPI_D20
GPIO 25: level=0 fsel=6 alt=2 func=DPI_D21
GPIO 26: level=0 fsel=0 func=INPUT
GPIO 27: level=0 fsel=0 func=INPUT
BANK1 (GPIO 28 to 45):
GPIO 28: level=0 fsel=0 func=INPUT
GPIO 29: level=0 fsel=0 func=INPUT
GPIO 30: level=0 fsel=0 func=INPUT
GPIO 31: level=0 fsel=0 func=INPUT
GPIO 32: level=0 fsel=0 func=INPUT
GPIO 33: level=0 fsel=0 func=INPUT
GPIO 34: level=1 fsel=0 func=INPUT
GPIO 35: level=1 fsel=0 func=INPUT
GPIO 36: level=1 fsel=0 func=INPUT
GPIO 37: level=0 fsel=0 func=INPUT
GPIO 38: level=0 fsel=0 func=INPUT
GPIO 39: level=0 fsel=0 func=INPUT
GPIO 40: level=0 fsel=0 func=INPUT
GPIO 41: level=0 fsel=0 func=INPUT
GPIO 42: level=0 fsel=0 func=INPUT
GPIO 43: level=0 fsel=0 func=INPUT
GPIO 44: level=0 fsel=0 func=INPUT
GPIO 45: level=0 fsel=0 func=INPUT
BANK2 (GPIO 46 to 53):
GPIO 46: level=1 fsel=0 func=INPUT
GPIO 47: level=1 fsel=1 func=OUTPUT
GPIO 48: level=0 fsel=4 alt=0 func=SD0_CLK
GPIO 49: level=1 fsel=4 alt=0 func=SD0_CMD
GPIO 50: level=1 fsel=4 alt=0 func=SD0_DAT0
GPIO 51: level=1 fsel=4 alt=0 func=SD0_DAT1
GPIO 52: level=1 fsel=4 alt=0 func=SD0_DAT2
GPIO 53: level=1 fsel=4 alt=0 func=SD0_DAT3
pi@raspberrypi:~ $ 
As one can see from the above, DPI interface is initialized correctly.

But .. now comes the problem: As my color mapping is incorrect for the hardware I need to define another media bus format.
My display is 18-bit color and the only available media bus format is 'MEDIA_BUS_FMT_RGB666_1X18' which results in this
IMG_20210528_160925.jpg
incorrect color mapping (is MEDIA_BUS_FMT_RGB666_1X18) but needs to be changed to BGR
IMG_20210528_160925.jpg (220.61 KiB) Viewed 1277 times

I need someone to point me to the correct place where and how to define/add a new 'MEDIA_BUS_FMT_BGR666_1X18'. These macros are defined in 'media-bus-format.h' (find it in include->uapi->linux) but I need to understand how they work, and if there is another location which requires changes (to make the new format work).
Or: is there another way to change the DPI color mapping (as there are 4 options when looking at dpi_output_format):
rgb_order:
1: DPI_RGB_ORDER_RGB
2: DPI_RGB_ORDER_BGR
3: DPI_RGB_ORDER_GRB
4: DPI_RGB_ORDER_BRG

Before you ask: yes, my display timing is correct and the required color mapping is well known/confirmed. As said, I'm testing based on CM3 atm, and 'cheating' with the interface hardware let the module light up just fine.
IMG_20210528_163138.jpg
Required mapping s BGR666 - this image was made when using a hacked HW configured for 'MEDIA_BUS_FMT_BGR888_1X24'
IMG_20210528_163138.jpg (178.92 KiB) Viewed 1277 times
for the sake of completeness, here is my panel timing (added to 'panel-simple.c):

Code: Select all

static const struct display_timing innolux_at056tn53v1_timing = {
	.pixelclock = { 39700000, 39700000, 39700000},
	.hactive = { 640, 640, 640 },
	.hfront_porch = { 16, 16, 16 },
	.hback_porch = { 134, 134, 134 },
	.hsync_len = { 10, 10, 10},
	.vactive = { 480, 480, 480 },
	.vfront_porch = { 32, 32, 32},
	.vback_porch = { 11, 11, 11 },
	.vsync_len = { 2, 2, 2 },
	.flags = DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_PHSYNC,
};

static const struct panel_desc innolux_at056tn53v1 = {
	.timings = &innolux_at056tn53v1_timing,
	.num_timings = 1,
	.bpc = 6,
	.size = {
		.width = 112,
		.height = 84,
	},	
	.delay = {
		.prepare = 50,
		.enable = 200,
		.disable = 110,
		.unprepare = 200,
	},
	.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
	.bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
	.connector_type = DRM_MODE_CONNECTOR_DPI,
};
Last edited by aBUGSworstnightmare on Sat May 29, 2021 7:10 am, edited 1 time in total.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11447
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Need to define new color mappings to be used with DPI mode 6 (under KMS)

Fri May 28, 2021 4:42 pm

Whilst it's mode 6 in the table, the registers count from 0, so we're looking at mode 5 as listed at https://github.com/raspberrypi/linux/bl ... _dpi.c#L46

Code: Select all

/* This define is named in the hardware, but actually just outputs 0. */
# define DPI_FORMAT_9BIT_666_RGB	0
/* Outputs 00000000rrrrrggggggbbbbb */
# define DPI_FORMAT_16BIT_565_RGB_1	1
/* Outputs 000rrrrr00gggggg000bbbbb */
# define DPI_FORMAT_16BIT_565_RGB_2	2
/* Outputs 00rrrrr000gggggg00bbbbb0 */
# define DPI_FORMAT_16BIT_565_RGB_3	3
/* Outputs 000000rrrrrrggggggbbbbbb */
# define DPI_FORMAT_18BIT_666_RGB_1	4
/* Outputs 00rrrrrr00gggggg00bbbbbb */
# define DPI_FORMAT_18BIT_666_RGB_2	5
/* Outputs rrrrrrrrggggggggbbbbbbbb */
# define DPI_FORMAT_24BIT_888_RGB	6
vc4_dpi_encoder_enable should iterate through to the connector on a link and take the properties from there.
Media bus format MEDIA_BUS_FMT_RGB666_1X24_CPADHI should map to DPI_FORMAT_18BIT_666_RGB_2 (5), and set the peripheral to what the docs say is mode 6. If you look at the docs for the format it does match up.

I have hit one minor issue with that path when adding the VGA666 overlay in that it skips over any bridges in finding the end connector, and those bridges could change or need to set the format. VGA666 ended up in the "else" case which defaults to DPI_FORMAT_18BIT_666_RGB_1. One to try and understand at a later date.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

aBUGSworstnightmare
Posts: 3141
Joined: Tue Jun 30, 2015 1:35 pm

Re: Need to define new color mappings to be used with DPI mode 6 (under KMS)

Fri May 28, 2021 6:25 pm

6by9 wrote:
Fri May 28, 2021 4:42 pm
Whilst it's mode 6 in the table, the registers count from 0, so we're looking at mode 5 as listed at https://github.com/raspberrypi/linux/bl ... _dpi.c#L46

Code: Select all

/* This define is named in the hardware, but actually just outputs 0. */
# define DPI_FORMAT_9BIT_666_RGB	0
/* Outputs 00000000rrrrrggggggbbbbb */
# define DPI_FORMAT_16BIT_565_RGB_1	1
/* Outputs 000rrrrr00gggggg000bbbbb */
# define DPI_FORMAT_16BIT_565_RGB_2	2
/* Outputs 00rrrrr000gggggg00bbbbb0 */
# define DPI_FORMAT_16BIT_565_RGB_3	3
/* Outputs 000000rrrrrrggggggbbbbbb */
# define DPI_FORMAT_18BIT_666_RGB_1	4
/* Outputs 00rrrrrr00gggggg00bbbbbb */
# define DPI_FORMAT_18BIT_666_RGB_2	5
/* Outputs rrrrrrrrggggggggbbbbbbbb */
# define DPI_FORMAT_24BIT_888_RGB	6
vc4_dpi_encoder_enable should iterate through to the connector on a link and take the properties from there.
Media bus format MEDIA_BUS_FMT_RGB666_1X24_CPADHI should map to DPI_FORMAT_18BIT_666_RGB_2 (5), and set the peripheral to what the docs say is mode 6. If you look at the docs for the format it does match up.

I have hit one minor issue with that path when adding the VGA666 overlay in that it skips over any bridges in finding the end connector, and those bridges could change or need to set the format. VGA666 ended up in the "else" case which defaults to DPI_FORMAT_18BIT_666_RGB_1. One to try and understand at a later date.
yes, MEDIA_BUS_FMT_RGB666_1X24_CPADHI should configure DPI output in the correct mode, but it still doesn't solve the issue of color mapping.
I need it in BGR, so dealing with dpi_rgb_order is missing (compare RGB888 with BGR888 for 24-bit data). How can I add that?

Code: Select all

	case MEDIA_BUS_FMT_RGB888_1X24:
			dpi_c |= VC4_SET_FIELD(DPI_FORMAT_24BIT_888_RGB,
					       DPI_FORMAT);
			break;
		case MEDIA_BUS_FMT_BGR888_1X24:
			dpi_c |= VC4_SET_FIELD(DPI_FORMAT_24BIT_888_RGB,
					       DPI_FORMAT);
			dpi_c |= VC4_SET_FIELD(DPI_ORDER_BGR, DPI_ORDER);
			break;
		case MEDIA_BUS_FMT_RGB666_1X24_CPADHI:
			dpi_c |= VC4_SET_FIELD(DPI_FORMAT_18BIT_666_RGB_2,
					       DPI_FORMAT);
			break;
Need to have a look at the VGA overlay tomorrow (not possible with my tablet).

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11447
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Need to define new color mappings to be used with DPI mode 6 (under KMS)

Fri May 28, 2021 8:00 pm

You'll need to define a new format for it. MEDIA_BUS_FMT_BGR666_1X24_CPADHI would be the obvious choice.
The new case in vc4_dpi_encoder_enable needs to copy the style of bgr888 in setting the mode and the pixel order.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

aBUGSworstnightmare
Posts: 3141
Joined: Tue Jun 30, 2015 1:35 pm

Re: Need to define new color mappings to be used with DPI mode 6 (under KMS)

Fri May 28, 2021 9:30 pm

6by9 wrote:
Fri May 28, 2021 8:00 pm
You'll need to define a new format for it. MEDIA_BUS_FMT_BGR666_1X24_CPADHI would be the obvious choice.
The new case in vc4_dpi_encoder_enable needs to copy the style of bgr888 in setting the mode and the pixel order.
thanks for confirming this, but is there some documentation how the macro (in 'media-bus-format.h' ) needs to be defined?
Do I simply assign it to code 0x101d and change the comment to '/* RGB - next is 0x101e */'?
Is it that simple? Think I will have to test it ...

aBUGSworstnightmare
Posts: 3141
Joined: Tue Jun 30, 2015 1:35 pm

Re: [SOLVED] Need to define new color mappings to be used with DPI mode 6 (under KMS)

Sat May 29, 2021 7:12 am

O.k. Let's start with a picture of the test jig in use, showing the final result
IMG_20210529_090322.jpg
'messy' setup used for kernel modification - final display after all changes were applied
IMG_20210529_090322.jpg (161.62 KiB) Viewed 1092 times
Last edited by aBUGSworstnightmare on Sat May 29, 2021 7:28 am, edited 1 time in total.

aBUGSworstnightmare
Posts: 3141
Joined: Tue Jun 30, 2015 1:35 pm

Re: [SOLVED] Need to define new color mappings to be used with DPI mode 6 (under KMS)

Sat May 29, 2021 7:28 am

O.k. so here is what I did to solve this (hoping it might be useful and/or of particular interest to others with similar problem).

1. changed 'bcm270x.dtsi' by adding a new configuration for DPI mode 6 (see first post)

2. As said, I was using 'MEDIA_BUS_FMT_RGB666_1X18' as bus_format in my module definition. This resulted then in below image
IMG_20210528_160925.jpg
output with MEDIA_BUS_FMT_RGB666_1X18
IMG_20210528_160925.jpg (220.61 KiB) Viewed 1087 times

3. 6by9 pointed me into the right direction regarding the media format, so as a first step I've changed my definition to 'MEDIA_BUS_FMT_RGB666_1X24_CPADHI' which results in below image
IMG_20210529_085148.jpg
output with MEDIA_BUS_FMT_RGB666_1X24_CPADHI
IMG_20210529_085148.jpg (172.19 KiB) Viewed 1087 times

4. as this was working as expected I've added a new format definition to 'media-bus-format.h' (code 0x101d)

Code: Select all

/* RGB - next is	0x101e */
...
#define MEDIA_BUS_FMT_RBG888_1X24		0x100e
#define MEDIA_BUS_FMT_RGB666_1X24_CPADHI	0x1015
#define MEDIA_BUS_FMT_BGR666_1X24_CPADHI	0x101d
#define MEDIA_BUS_FMT_RGB666_1X7X3_SPWG		0x1010
...
and also changed the bus_format switch routine in 'vc4_dpi.c' as below (take note of the new MEDIA_BUS_FMT_BGR666_1X24_CPADHI which is also applying color mapping to BGR)

Code: Select all

		switch (bus_format) {
		case MEDIA_BUS_FMT_RGB888_1X24:
			dpi_c |= VC4_SET_FIELD(DPI_FORMAT_24BIT_888_RGB,
					       DPI_FORMAT);
			break;
		case MEDIA_BUS_FMT_BGR888_1X24:
			dpi_c |= VC4_SET_FIELD(DPI_FORMAT_24BIT_888_RGB,
					       DPI_FORMAT);
			dpi_c |= VC4_SET_FIELD(DPI_ORDER_BGR, DPI_ORDER);
			break;
		case MEDIA_BUS_FMT_RGB666_1X24_CPADHI:
			dpi_c |= VC4_SET_FIELD(DPI_FORMAT_18BIT_666_RGB_2,
					       DPI_FORMAT);
			break;
		case MEDIA_BUS_FMT_BGR666_1X24_CPADHI:
			dpi_c |= VC4_SET_FIELD(DPI_FORMAT_18BIT_666_RGB_2,
					       DPI_FORMAT);
			dpi_c |= VC4_SET_FIELD(DPI_ORDER_BGR, DPI_ORDER);		       
			break;
		case MEDIA_BUS_FMT_RGB666_1X18:
			dpi_c |= VC4_SET_FIELD(DPI_FORMAT_18BIT_666_RGB_1,
					       DPI_FORMAT);
			break;
		case MEDIA_BUS_FMT_RGB565_1X16:
			dpi_c |= VC4_SET_FIELD(DPI_FORMAT_16BIT_565_RGB_3,
					       DPI_FORMAT);
			break;
		default:
			DRM_ERROR("Unknown media bus format %d\n", bus_format);
			break;
		}
compiling all these changes then leads to a final result as shown below
IMG_20210529_090304.jpg
output with new MEDIA_BUS_FMT_BGR666_1X24_CPADHI --> ISSUE SOLVED
IMG_20210529_090304.jpg (178.92 KiB) Viewed 1087 times

Note: next thing is to figure out how to created kernel patches (diff files) which will allow others (or me when starting from scratch next time) to apply the shown fixes easily.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11447
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: [SOLVED] Need to define new color mappings to be used with DPI mode 6 (under KMS)

Sat May 29, 2021 8:41 am

If you create a PR that has two patches:
1 - Defines the format in include/uapi/linux/media-bus-format.h, updates the "next is" entry, and then describes it in Documentation/userspace-api/media/v4l/subdev-formats.rst (copy/paste of the RGB versions with r & b swapped).
2 - Adds the relevant config to vc4_dpi.c

and preferably repeat for a MEDIA_BUS_FMT_BGR666_1X18 as well, then I can ask Maxime to upstream them. If they aren't upstreamed then we'll get conflicts every time someone else adds a new RGB media-bus format. Patches do need a Signed-off-by: line to be acceptable upstream (see Documentation/process/submitting-patches.rst) but you'll get to see your name in lights in the mainline Linux kernel history!

Minor issue that MEDIA_BUS_FMT_RGB888_3X8_DELTA was added in 5.11 - conflict time.
You can use "git cherry-pick <hash>" to pull that commit back to rpi-5.10.y as part of a PR to that branch. Phil will generally as that you then "git commit --amend" to add the line "Commit <hash> upstream" at the start of the commit text to ease tree maintenance. Doing so means that your commits can be upstreamed without modification.

The addition to bcm270x.dtsi is fine, although I'd probably call it 18bit_cpadhi to match the panel driver side - Mode 6 doesn't mean anything in KMS. Another patch, but that remains only in our downstream tree.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

aBUGSworstnightmare
Posts: 3141
Joined: Tue Jun 30, 2015 1:35 pm

Re: [SOLVED] Need to define new color mappings to be used with DPI mode 6 (under KMS)

Mon May 31, 2021 7:46 am

6by9 wrote:
Sat May 29, 2021 8:41 am
If you create a PR that has two patches:
1 - Defines the format in include/uapi/linux/media-bus-format.h, updates the "next is" entry, and then describes it in Documentation/userspace-api/media/v4l/subdev-formats.rst (copy/paste of the RGB versions with r & b swapped).
2 - Adds the relevant config to vc4_dpi.c

and preferably repeat for a MEDIA_BUS_FMT_BGR666_1X18 as well, then I can ask Maxime to upstream them. If they aren't upstreamed then we'll get conflicts every time someone else adds a new RGB media-bus format. Patches do need a Signed-off-by: line to be acceptable upstream (see Documentation/process/submitting-patches.rst) but you'll get to see your name in lights in the mainline Linux kernel history!

Minor issue that MEDIA_BUS_FMT_RGB888_3X8_DELTA was added in 5.11 - conflict time.
You can use "git cherry-pick <hash>" to pull that commit back to rpi-5.10.y as part of a PR to that branch. Phil will generally as that you then "git commit --amend" to add the line "Commit <hash> upstream" at the start of the commit text to ease tree maintenance. Doing so means that your commits can be upstreamed without modification.

The addition to bcm270x.dtsi is fine, although I'd probably call it 18bit_cpadhi to match the panel driver side - Mode 6 doesn't mean anything in KMS. Another patch, but that remains only in our downstream tree.
Sorry, but is there an how-to-guide for this? That one - https://projects.raspberrypi.org/en/pro ... d-with-git - isn't really helpful. If I i.e. user name and e-mail and then use 'git log' the result is as below

Code: Select all

pi@raspberrypi:~/linux $ git log
commit cbc7c3d2dcc76ad714df19951b382a97a6a66228 (HEAD -> rpi-5.11.y)
Author: Serge Schneider <serge@raspberrypi.com>
Date:   Mon Dec 2 14:48:05 2019 +0000

    overlays: Add rpi-poe-plus overlay
    
    Signed-off-by: Serge Schneider <serge@raspberrypi.com>
So, what I would need is a step-by-step instruction which can be used by non-software-guys. As I haven't used git it is a little over my head atm.

a 'git diff' output is below, so basically all changes are there, question is how to convert them into a patch and how to submit them.

Code: Select all

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 27fffafe5..3b7d9d651 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -147,6 +147,8 @@ properties:
       - ivo,m133nwf4-r0
         # Innolux AT043TN24 4.3" WQVGA TFT LCD panel
       - innolux,at043tn24
+        # Innolux AT056tN53V1 5.6" VGA (640x480) TFT LCD panel
+      - innolux,at056tn53v1
         # Innolux AT070TN92 7.0" WQVGA TFT LCD panel
       - innolux,at070tn92
         # Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel
diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst
index 6ee95ab16..bd91ab7b8 100644
--- a/Documentation/userspace-api/media/v4l/subdev-formats.rst
+++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst
@@ -945,6 +945,43 @@ The following tables list existing packed RGB formats.
       - b\ :sub:`2`
       - b\ :sub:`1`
       - b\ :sub:`0`
+    * .. _MEDIA-BUS-FMT-BGR666-1X18:
+
+      - MEDIA_BUS_FMT_BGR666_1X18
+      - 0x101f
+      -
+      -
+      -
+      -
+      -
+      -
+      -
+      -
+      -
+      -
+      -
+      -
+      -
+      -
+      -
+      - b\ :sub:`5`
+      - b\ :sub:`4`
+      - b\ :sub:`3`
+      - b\ :sub:`2`
+      - b\ :sub:`1`
+      - b\ :sub:`0`
+      - g\ :sub:`5`
+      - g\ :sub:`4`
+      - g\ :sub:`3`
+      - g\ :sub:`2`
+      - g\ :sub:`1`
+      - g\ :sub:`0`
+      - r\ :sub:`5`
+      - r\ :sub:`4`
+      - r\ :sub:`3`
+      - r\ :sub:`2`
+      - r\ :sub:`1`
+      - r\ :sub:`0`
     * .. _MEDIA-BUS-FMT-RBG888-1X24:
 
       - MEDIA_BUS_FMT_RBG888_1X24
@@ -1019,6 +1056,43 @@ The following tables list existing packed RGB formats.
       - b\ :sub:`2`
       - b\ :sub:`1`
       - b\ :sub:`0`
+    * .. _MEDIA-BUS-FMT-BGR666-1X24_CPADHI:
+
+      - MEDIA_BUS_FMT_BGR666_1X24_CPADHI
+      - 0x101e
+      -
+      -
+      -
+      -
+      -
+      -
+      -
+      -
+      -
+      - 0
+      - 0
+      - b\ :sub:`5`
+      - b\ :sub:`4`
+      - b\ :sub:`3`
+      - b\ :sub:`2`
+      - b\ :sub:`1`
+      - b\ :sub:`0`
+      - 0
+      - 0
+      - g\ :sub:`5`
+      - g\ :sub:`4`
+      - g\ :sub:`3`
+      - g\ :sub:`2`
+      - g\ :sub:`1`
+      - g\ :sub:`0`
+      - 0
+      - 0
+      - r\ :sub:`5`
+      - r\ :sub:`4`
+      - r\ :sub:`3`
+      - r\ :sub:`2`
+      - r\ :sub:`1`
+      - r\ :sub:`0`
     * .. _MEDIA-BUS-FMT-BGR888-1X24:
 
       - MEDIA_BUS_FMT_BGR888_1X24
diff --git a/arch/arm/boot/dts/bcm270x.dtsi b/arch/arm/boot/dts/bcm270x.dtsi
index 12c7b0b2b..8e557bbd1 100644
--- a/arch/arm/boot/dts/bcm270x.dtsi
+++ b/arch/arm/boot/dts/bcm270x.dtsi
@@ -164,6 +164,18 @@
 &gpio {
 	interrupts = <2 17>, <2 18>;
 
+	dpi_18bit_cpadhi_gpio0: dpi_18bit_cpadhi_gpio0 {
+		brcm,pins = <0 1 2 3 4 5 6 7 8 9
+			     12 13 14 15 16 17
+			     20 21 22 23 24 25>;
+		brcm,function = <BCM2835_FSEL_ALT2>;
+	};
+	dpi_18bit_cpadhi_gpio2: dpi_18bit_cpadhi_gpio2 {
+		brcm,pins = <2 3 4 5 6 7 8 9
+			     12 13 14 15 16 17
+			     20 21 22 23 24 25>;
+		brcm,function = <BCM2835_FSEL_ALT2>;
+	};
 	dpi_18bit_gpio0: dpi_18bit_gpio0 {
 		brcm,pins = <0 1 2 3 4 5 6 7 8 9 10 11
 			     12 13 14 15 16 17 18 19
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 41bbec72b..8ff7ebf77 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2096,6 +2096,38 @@ static const struct panel_desc innolux_at043tn24 = {
 	.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
 };
 
+static const struct display_timing innolux_at056tn53v1_timing = {
+	.pixelclock = { 39700000, 39700000, 39700000},
+	.hactive = { 640, 640, 640 },
+	.hfront_porch = { 16, 16, 16 },
+	.hback_porch = { 134, 134, 134 },
+	.hsync_len = { 10, 10, 10},
+	.vactive = { 480, 480, 480 },
+	.vfront_porch = { 32, 32, 32},
+	.vback_porch = { 11, 11, 11 },
+	.vsync_len = { 2, 2, 2 },
+	.flags = DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_PHSYNC,
+};
+
+static const struct panel_desc innolux_at056tn53v1 = {
+	.timings = &innolux_at056tn53v1_timing,
+	.num_timings = 1,
+	.bpc = 6,
+	.size = {
+		.width = 112,
+		.height = 84,
+	},
+	.delay = {
+		.prepare = 50,
+		.enable = 200,
+		.disable = 110,
+		.unprepare = 200,
+	},
+	.bus_format = MEDIA_BUS_FMT_BGR666_1X24_CPADHI,
+	.bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
+	.connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
 static const struct drm_display_mode innolux_at070tn92_mode = {
 	.clock = 33333,
 	.hdisplay = 800,
@@ -4130,6 +4162,9 @@ static const struct of_device_id platform_of_match[] = {
 		.compatible = "innolux,at043tn24",
 		.data = &innolux_at043tn24,
 	}, {
+		.compatible = "innolux,at056tn53v1",
+		.data = &innolux_at056tn53v1,
+	},{
 		.compatible = "innolux,at070tn92",
 		.data = &innolux_at070tn92,
 	}, {
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
index db63f4e11..dde2c6014 100644
--- a/drivers/gpu/drm/vc4/vc4_dpi.c
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -165,10 +165,20 @@ static void vc4_dpi_encoder_enable(struct drm_encoder *encoder)
 			dpi_c |= VC4_SET_FIELD(DPI_FORMAT_18BIT_666_RGB_2,
 					       DPI_FORMAT);
 			break;
+		case MEDIA_BUS_FMT_BGR666_1X24_CPADHI:
+			dpi_c |= VC4_SET_FIELD(DPI_FORMAT_18BIT_666_RGB_2,
+					       DPI_FORMAT);
+			dpi_c |= VC4_SET_FIELD(DPI_ORDER_BGR, DPI_ORDER);
+			break;
 		case MEDIA_BUS_FMT_RGB666_1X18:
 			dpi_c |= VC4_SET_FIELD(DPI_FORMAT_18BIT_666_RGB_1,
 					       DPI_FORMAT);
 			break;
+		case MEDIA_BUS_FMT_BGR666_1X18:
+			dpi_c |= VC4_SET_FIELD(DPI_FORMAT_18BIT_666_RGB_1,
+					       DPI_FORMAT);
+			dpi_c |= VC4_SET_FIELD(DPI_ORDER_BGR, DPI_ORDER);
+			break;
 		case MEDIA_BUS_FMT_RGB565_1X16:
 			dpi_c |= VC4_SET_FIELD(DPI_FORMAT_16BIT_565_RGB_3,
 					       DPI_FORMAT);
diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h
index aa56d7f54..6d09ffaa8 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -34,7 +34,7 @@
 
 #define MEDIA_BUS_FMT_FIXED			0x0001
 
-/* RGB - next is	0x101e */
+/* RGB - next is	0x1020 */
 #define MEDIA_BUS_FMT_RGB444_1X12		0x1016
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE	0x1001
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE	0x1002
@@ -46,8 +46,10 @@
 #define MEDIA_BUS_FMT_RGB565_2X8_BE		0x1007
 #define MEDIA_BUS_FMT_RGB565_2X8_LE		0x1008
 #define MEDIA_BUS_FMT_RGB666_1X18		0x1009
+#define MEDIA_BUS_FMT_BGR666_1X18		0x101f
 #define MEDIA_BUS_FMT_RBG888_1X24		0x100e
 #define MEDIA_BUS_FMT_RGB666_1X24_CPADHI	0x1015
+#define MEDIA_BUS_FMT_BGR666_1X24_CPADHI	0x101e
 #define MEDIA_BUS_FMT_RGB666_1X7X3_SPWG		0x1010
 #define MEDIA_BUS_FMT_BGR888_1X24		0x1013
 #define MEDIA_BUS_FMT_BGR888_3X8		0x101b

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11447
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: [SOLVED] Need to define new color mappings to be used with DPI mode 6 (under KMS)

Fri Jun 04, 2021 10:33 am

With git there are always at least 3 different ways of doing anything. I'll give you the flow I tend to use, but there will be other options.

I assume you've started with a "git clone https://github.com/raspberrypi/linux.git" to retrieve the kernel repo. You'll ideally want to look at using SSH keys instead of https with username and password, but skip that bit for now.

"git status" will give you a list of the changed files.

"git add <filename>" will stage all the changes for the file/files listed, ready for committing. "git add -i" allows you to got through each hunk that is changed in the file and choose whether to stage them or not.
"git commit" will commit them. "git commit -s" will add a "Signed-off-by:" line to the commit text - this is required for any contribution to mainline. See https://www.kernel.org/doc/html/latest/ ... -of-origin for what SoB means.

If you just want to commit the changes, you can combine those two into one with "git commit <filename>", or "git commit -p <filename>" to do the equivalent of "add -i".
"git show" should now show you your new commit, and the full history with "git log".

To push it to Github, you'll need an account on Github. Ensure the email address that you use for your commits is at least tied to your Github account (Settings/Emails).
Fork the raspberrypi/linux repo to your account by going to https://github.com/raspberrypi/linux/ and clicking on the word "Fork" at the top right. It'll ask you which account you wish to fork it into.

Add your repo to your git repo. "git remote add my_remote https://github.com/your_username/linux".
Fetch it - "git fetch my_remote".
Push your changes - "git push my_remote HEAD:rpi-5.10.y". It's likely to ask you for your username and password.

Go to your repo on Github and you should now see your change pushed. It's generally pretty good at noting that there is a new change pushed and suggesting you might want to make a Pull Request in a banner at the top, otherwise it'll generally tell you
"This branch is 1 commit ahead, 56 commits behind raspberrypi:rpi-5.10.y." or equivalent, with a "Contribute" button that lets you open a PR.
If you get feedback and changes requested on your patches, you'll be looking for "git rebase -i" to allow you to amend the patches that are changed on your tree. It'll open an editor with all your local changes listed by hash, with the word "pick" beside each one. Replace the word "pick" beside the patch you want to change with "e" or "edit", and when you quite the editor git will roll back to that commit and allow you to amend it with "git commit --amend". When you've finished making your changes use "git rebase --continue" to get git to continue the rebase. You can set multiple patches to be edited, or change the order of the patches if necessary.
If it all goes wrong, then use "git rebase --abort" to reset to the the state you were in before "git rebase -i".
When done, use "git push -f my_remote HEAD:rpi-5.10.y" to force push to your branch on Github. The PR will automatically update to reflect these changes.

If the raspberrypi repo moves on whilst you're working on your patches, then "git fetch origin", and "git rebase" will reapply your patches on top of them.

If contributing to the Linux kernel, then checkpatch.pl is your friend to check that your patch follows the kernel coding standard. I tend to edit the file in my repo .git/hooks/post-commit to read

Code: Select all

#!/bin/sh
exec git show --format=email HEAD | ./scripts/checkpatch.pl --strict --codespell
so that as soon as I do a git commit on anything it runs checkpatch and tells me of any issues. Getting into the habit of immediately doing "git commit --amend" on those warnings generally saves a bit of faffing around later.

To use SSH keys with Github, create your key on your local machine, and then copy the PUBLIC key to settings/SSH and GPG keys section of GIthub. You then use remotes in the form "git@github.com:<username>/linux.git" rather than https://. You can go into .git/config and manually alter the remote line to save having to pull the full remote again. A "git fetch" or "git push" should then pull securely using the key and not requesting a username or password. It will request your SSH passkey if you set one (recommended), but you can use an ssh-agent to handle that for you.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11447
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: [SOLVED] Need to define new color mappings to be used with DPI mode 6 (under KMS)

Fri Jun 04, 2021 10:42 am

Please note the ordering in media-bus-formats.h - alphabetical order.

Code: Select all

 * The bus formats are grouped by type, bus_width, bits per component, samples
 * per pixel and order of subsamples. Numerical values are sorted using generic
 * numerical sort order (8 thus comes before 10).
 *
Your BGR formats aren't following that as both MEDIA_BUS_FMT_BGR666_1X18 and MEDIA_BUS_FMT_BGR666_1X24_CPADHI should be before MEDIA_BUS_FMT_RGB666_1X18.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

aBUGSworstnightmare
Posts: 3141
Joined: Tue Jun 30, 2015 1:35 pm

Re: [SOLVED] Need to define new color mappings to be used with DPI mode 6 (under KMS)

Mon Jun 07, 2021 6:36 pm

@6by9: I'm having a hard time here in getting the display to work on a CM4IO + CM4.
I've changed the kernel sources as described above (used a CMIO + CM3L so far) and compiled it, but when I connect the display the CM4 either refuses to boot or does not show readabke content.

I have a few questions on this:
1: what is the default drive strenght for DPI (GPIO configured to ALT2) on CM3L and what is it on CM4? If memory serves me right CM4 is different, right?
Module works fine on CM3L (as one can see from the pics), but not at all on CM4.

2. What is the available current on the 3V3 rail (from GPIO, think I've read 600mA somewhere)? Maybe inrush current to the TFT module is too hight which let's the PMIC stall. Module current consumption is 200mA typ (@3.3V)

3. Is there anything which would stop me from 'hacking' the CM4IO and make use of the 3V3 supply rail to PCIe slot, using that one as Digital_VCC for the display?

EDIT: here are some more infos!
Status of the GPIOs

Code: Select all

pi@raspberrypi:~ $ raspi-gpio get
BANK0 (GPIO 0 to 27):
GPIO 0: level=0 fsel=6 alt=2 func=PCLK pull=NONE
GPIO 1: level=1 fsel=6 alt=2 func=DE pull=NONE
GPIO 2: level=1 fsel=6 alt=2 func=LCD_VSYNC pull=NONE
GPIO 3: level=1 fsel=6 alt=2 func=LCD_HSYNC pull=NONE
GPIO 4: level=1 fsel=6 alt=2 func=DPI_D0 pull=NONE
GPIO 5: level=1 fsel=6 alt=2 func=DPI_D1 pull=NONE
GPIO 6: level=1 fsel=6 alt=2 func=DPI_D2 pull=NONE
GPIO 7: level=1 fsel=6 alt=2 func=DPI_D3 pull=NONE
GPIO 8: level=1 fsel=6 alt=2 func=DPI_D4 pull=NONE
GPIO 9: level=1 fsel=6 alt=2 func=DPI_D5 pull=NONE
GPIO 10: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 11: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 12: level=1 fsel=6 alt=2 func=DPI_D8 pull=NONE
GPIO 13: level=0 fsel=6 alt=2 func=DPI_D9 pull=NONE
GPIO 14: level=1 fsel=6 alt=2 func=DPI_D10 pull=NONE
GPIO 15: level=1 fsel=6 alt=2 func=DPI_D11 pull=NONE
GPIO 16: level=1 fsel=6 alt=2 func=DPI_D12 pull=NONE
GPIO 17: level=1 fsel=6 alt=2 func=DPI_D13 pull=NONE
GPIO 18: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 19: level=0 fsel=2 alt=5 func=PWM0_1 pull=DOWN
GPIO 20: level=1 fsel=6 alt=2 func=DPI_D16 pull=NONE
GPIO 21: level=1 fsel=6 alt=2 func=DPI_D17 pull=NONE
GPIO 22: level=1 fsel=6 alt=2 func=DPI_D18 pull=NONE
GPIO 23: level=1 fsel=6 alt=2 func=DPI_D19 pull=NONE
GPIO 24: level=0 fsel=6 alt=2 func=DPI_D20 pull=NONE
GPIO 25: level=1 fsel=6 alt=2 func=DPI_D21 pull=NONE
GPIO 26: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 27: level=0 fsel=0 func=INPUT pull=DOWN
BANK1 (GPIO 28 to 45):
GPIO 28: level=1 fsel=2 alt=5 func=RGMII_MDIO pull=UP
GPIO 29: level=0 fsel=2 alt=5 func=RGMII_MDC pull=DOWN
GPIO 30: level=1 fsel=7 alt=3 func=CTS0 pull=UP
GPIO 31: level=1 fsel=7 alt=3 func=RTS0 pull=NONE
GPIO 32: level=0 fsel=7 alt=3 func=TXD0 pull=NONE
GPIO 33: level=1 fsel=7 alt=3 func=RXD0 pull=UP
GPIO 34: level=0 fsel=7 alt=3 func=SD1_CLK pull=NONE
GPIO 35: level=1 fsel=7 alt=3 func=SD1_CMD pull=UP
GPIO 36: level=1 fsel=7 alt=3 func=SD1_DAT0 pull=UP
GPIO 37: level=1 fsel=7 alt=3 func=SD1_DAT1 pull=UP
GPIO 38: level=1 fsel=7 alt=3 func=SD1_DAT2 pull=UP
GPIO 39: level=1 fsel=7 alt=3 func=SD1_DAT3 pull=UP
GPIO 40: level=1 fsel=0 func=INPUT pull=NONE
GPIO 41: level=1 fsel=0 func=INPUT pull=NONE
GPIO 42: level=0 fsel=1 func=OUTPUT pull=NONE
GPIO 43: level=1 fsel=0 func=INPUT pull=NONE
GPIO 44: level=1 fsel=0 func=INPUT pull=NONE
GPIO 45: level=1 fsel=0 func=INPUT pull=NONE
BANK2 (GPIO 46 to 53):
GPIO 46: level=0 fsel=0 func=INPUT pull=UP
GPIO 47: level=0 fsel=0 func=INPUT pull=UP
GPIO 48: level=0 fsel=4 alt=0 func=SD0_CLK pull=DOWN
GPIO 49: level=0 fsel=4 alt=0 func=SD0_CMD pull=DOWN
GPIO 50: level=0 fsel=4 alt=0 func=SD0_DAT0 pull=DOWN
GPIO 51: level=0 fsel=4 alt=0 func=SD0_DAT1 pull=DOWN
GPIO 52: level=0 fsel=4 alt=0 func=SD0_DAT2 pull=DOWN
GPIO 53: level=0 fsel=4 alt=0 func=SD0_DAT3 pull=DOWN
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.11.22-v7l+ #1 SMP Mon Jun 7 13:47:24 CEST 2021 armv7l GNU/Linux
What looks strange from the above is the pull-down on the GPIO19 (used as PWM).

Here are some pictures of the DUT:
IMG_20210608_090934.jpg
CM4IO +CM4 (2GB lite) jig setup
IMG_20210608_090934.jpg (127.84 KiB) Viewed 722 times
IMG_20210608_090003.jpg
observe the noise
IMG_20210608_090003.jpg (131.43 KiB) Viewed 722 times
IMG_20210608_090013.jpg
noise in detail
IMG_20210608_090013.jpg (116.97 KiB) Viewed 722 times

aBUGSworstnightmare
Posts: 3141
Joined: Tue Jun 30, 2015 1:35 pm

Re: [SOLVED] Need to define new color mappings to be used with DPI mode 6 (under KMS)

Tue Jun 08, 2021 7:35 am

sorry, noisy signal seems to be more related to crosstalk; added some shielding to the clock signal wire gives better results.

Nevertheless I would like to get questions 1 and 2 answered;. No 3 (3V3 from the PCIe DC/DC) is working (note the wire with the clip).
Also need to understand why GPIO19 has a pull-down (see my overlay below)

Code: Select all

/*
 * vc4-kms-at056tn53v1-overlay.dts
 */

/dts-v1/;
/plugin/;
#include <dt-bindings/gpio/gpio.h>

/ {
	compatible = "brcm,bcm2835";

	/* PWM0 function */
	fragment@0 {
		target = <&gpio>;
		__overlay__ {
			pwm_pins: pwm_pins {
				brcm,pins = <19>;
				brcm,function = <2>; /* Alt5 */
			};
		};
	};

	fragment@1 {
		target = <&pwm>;
		frag1: __overlay__ {
			pinctrl-names = "default";
			pinctrl-0 = <&pwm_pins>;
			assigned-clock-rates = <100000000>;
			status = "okay";
		};
	};

	fragment@2 {
		target-path = "/";
		__overlay__ {
			//#gpio-cells = <2>;
			/* Panel backlight through PWM0 on GPIO 19 */
			backlight_lvds: backlight {
				compatible = "pwm-backlight";
				pwms = <&pwm 0 5000000>; /* Period of 5000000ns means 200Hz */
				brightness-levels = <0  1000>;
				num-interpolated-steps = <1000>;
				default-brightness-level = <800>;
			};
			panel: panel {
				compatible = "innolux,at056tn53v1", "simple-panel";
				backlight = <&backlight_lvds>;
				
				port {
					panel_in: endpoint {
						remote-endpoint = <&dpi_out>;
					};
				};
			};
		};
	};

	fragment@3 {
		target = <&dpi>;
		__overlay__  {
			status = "okay";

			pinctrl-names = "default";
			pinctrl-0 = <&dpi_18bit_cpadhi_gpio0>;

			port {
				dpi_out: endpoint {
					remote-endpoint = <&panel_in>;
				};
			};
		};
	};
};

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11447
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: [SOLVED] Need to define new color mappings to be used with DPI mode 6 (under KMS)

Tue Jun 08, 2021 11:31 am

aBUGSworstnightmare wrote:
Mon Jun 07, 2021 6:36 pm
2. What is the available current on the 3V3 rail (from GPIO, think I've read 600mA somewhere)? Maybe inrush current to the TFT module is too hight which let's the PMIC stall. Module current consumption is 200mA typ (@3.3V)
https://datasheets.raspberrypi.org/cm4/ ... asheet.pdf page 19 pins 84 & 86

Code: Select all

3.3V +/-2.5% Power Output max 300mA per pin for a total of 600mA. This will be powered down during power off or GLOBAL_EN being set low
aBUGSworstnightmare wrote:3. Is there anything which would stop me from 'hacking' the CM4IO and make use of the 3V3 supply rail to PCIe slot, using that one as Digital_VCC for the display?
Nothing wrong with using that 3.3V supply.
Based on https://datasheets.raspberrypi.org/cm4i ... asheet.pdf page 10, you've got an AP64501SP-13 listed as 3.3V @ 3.3A.
aBUGSworstnightmare wrote:
Tue Jun 08, 2021 7:35 am
Also need to understand why GPIO19 has a pull-down (see my overlay below)
Your overlay doesn't appear to list any config for GPIO19. Add a "brcm,pull = <BCM2835_PUD_OFF>" or similar if you're wanting to force it.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

aBUGSworstnightmare
Posts: 3141
Joined: Tue Jun 30, 2015 1:35 pm

Re: [SOLVED] Need to define new color mappings to be used with DPI mode 6 (under KMS)

Fri Jun 18, 2021 1:05 pm

Added an overlay which configures DPI to mode 6 when using FKMS/FB and finally made a pull request (Rpi 5.11.y #4400).
Never done this before, so let's see how this goes and if some of the changes/additions will get accepted.

aBUGSworstnightmare
Posts: 3141
Joined: Tue Jun 30, 2015 1:35 pm

Re: [SOLVED] Need to define new color mappings to be used with DPI mode 6 (under KMS)

Sun Jul 11, 2021 11:57 am

Hi 6by9,
just tried to use the 'dpi18cpadhi-overlay' with Linux kernel 5.10.48 but this fails; GPIO's don't get initialized to ALT2.

Find the debug messages from kernel from the file. I also see tons of the messages below and don't know where they originate from.

Code: Select all

debug_sym: vc_mem_copy: Unable to open '/dev/fb0': No such file or directory(2)
The 'dpi18' and 'dpi24' overlays, which have the pin_ctrl specified in the overlay are working fine; no such message in the log.

In case I enable GPIO to ALT2 like below I also see this error messages in the log

Code: Select all

#dtoverlay=dpi18cpadhi
gpio=19=op,dh
gpio=0-9=a2
gpio=12-17=a2
gpio=20-25=a2
enable_dpi_lcd=1
dpi_group=2
dpi_mode=87
dpi_output_format=98342
dpi_timings=640 0 16 10 134 480 0 32 2 11 0 0 0 60 0 39700000 1
All logs are from the same system (CM4+CM4IO)!

EDIT: just checked under KMS with the 'vc4-kms-dpi-at056tn53v1' overlay --> not working either! So my observation is that pin_crtl 'dpi_18bit_cpadhi_gpio0' in 'bcm2701.dtsi get's ignored!

The kms overlay for Adafruit's Kippah, which relies on 'bcm2701.dtsi' as well is working though.

The debug output from trying to use 'vc4-kms-dpi-at056tn53v1.dtbo ' with KMS. As you can see the symbol 'dpi_18bit_cpadhi_gpio0' can't be found. Sorry, but I have no idea what has been changed on this new kernel which can cause this? Would you be so kind to check?

Code: Select all

007342.038: Loaded overlay 'vc4-kms-v3d'
007366.701: dtdebug: fragment 17 disabled
007366.753: dtdebug: fragment 18 disabled
007369.613: dtdebug: fragment 21 disabled
007369.666: dtdebug: fragment 22 disabled
007371.651: dtdebug: merge_fragment(/reserved-memory/linux,cma,/fragment@0/__overlay__)
007371.669: dtdebug:   +prop(size)
007372.416: dtdebug: merge_fragment() end
007381.680: dtdebug: merge_fragment(/soc/i2c@7ef04500,/fragment@1/__overlay__)
007381.698: dtdebug:   +prop(status)
007382.078: dtdebug: merge_fragment() end
007391.325: dtdebug: merge_fragment(/soc/i2c@7ef09500,/fragment@2/__overlay__)
007391.342: dtdebug:   +prop(status)
007391.713: dtdebug: merge_fragment() end
007400.938: dtdebug: merge_fragment(/soc/hdmi@7ef00700,/fragment@3/__overlay__)
007400.955: dtdebug:   +prop(status)
007401.362: dtdebug: merge_fragment() end
007410.660: dtdebug: merge_fragment(/soc/hdmi@7ef05700,/fragment@4/__overlay__)
007410.678: dtdebug:   +prop(status)
007411.074: dtdebug: merge_fragment() end
007418.633: dtdebug: merge_fragment(/soc/hvs@7e400000,/fragment@5/__overlay__)
007418.650: dtdebug:   +prop(status)
007419.133: dtdebug: merge_fragment() end
007427.843: dtdebug: merge_fragment(/soc/pixelvalve@7e206000,/fragment@6/__overlay__)
007427.858: dtdebug:   +prop(status)
007428.265: dtdebug: merge_fragment() end
007437.047: dtdebug: merge_fragment(/soc/pixelvalve@7e207000,/fragment@7/__overlay__)
007437.063: dtdebug:   +prop(status)
007437.470: dtdebug: merge_fragment() end
007446.311: dtdebug: merge_fragment(/soc/pixelvalve@7e20a000,/fragment@8/__overlay__)
007446.326: dtdebug:   +prop(status)
007446.729: dtdebug: merge_fragment() end
007455.755: dtdebug: merge_fragment(/soc/pixelvalve@7ec12000,/fragment@9/__overlay__)
007455.771: dtdebug:   +prop(status)
007456.169: dtdebug: merge_fragment() end
007465.157: dtdebug: merge_fragment(/soc/pixelvalve@7e216000,/fragment@10/__overlay__)
007465.171: dtdebug:   +prop(status)
007465.569: dtdebug: merge_fragment() end
007477.670: dtdebug: merge_fragment(/v3dbus/v3d@7ec04000,/fragment@11/__overlay__)
007477.688: dtdebug:   +prop(status)
007477.933: dtdebug: merge_fragment() end
007488.299: dtdebug: merge_fragment(/gpu,/fragment@12/__overlay__)
007488.314: dtdebug:   +prop(status)
007488.626: dtdebug: merge_fragment() end
007489.649: dtdebug: merge_fragment(/soc/txp@7e004000,/fragment@13/__overlay__)
007489.666: dtdebug:   +prop(status)
007490.386: dtdebug: merge_fragment() end
007500.621: dtdebug: merge_fragment(/soc/fb,/fragment@14/__overlay__)
007500.639: dtdebug:   +prop(status)
007500.961: dtdebug: merge_fragment() end
007510.921: dtdebug: merge_fragment(/soc/firmwarekms@7e600000,/fragment@15/__overlay__)
007510.939: dtdebug:   +prop(status)
007511.293: dtdebug: merge_fragment() end
007519.124: dtdebug: merge_fragment(/soc/vec@7e806000,/fragment@16/__overlay__)
007519.142: dtdebug:   +prop(status)
007519.611: dtdebug: merge_fragment() end
007519.662: dtdebug: fragment 17 disabled
007519.714: dtdebug: fragment 18 disabled
007529.548: dtdebug: merge_fragment(/soc/mailbox@7e00b840/bcm2835_audio,/fragment@19/__overlay__)
007529.567: dtdebug:   +prop(brcm,disable-hdmi)
007530.198: dtdebug: merge_fragment() end
007539.488: dtdebug: merge_fragment(/soc/clock@7ef00000,/fragment@20/__overlay__)
007539.504: dtdebug:   +prop(status)
007539.906: dtdebug: merge_fragment() end
007539.959: dtdebug: fragment 21 disabled
007540.008: dtdebug: fragment 22 disabled
007549.408: dtdebug: merge_fragment(/soc/interrupt-controller@7ef00100,/fragment@23/__overlay__)
007549.424: dtdebug:   +prop(status)
007549.821: dtdebug: merge_fragment() end
007550.231: brfs: File read: 3831 bytes
007577.082: dtdebug: Opened overlay file 'overlays/vc4-kms-dpi-at056tn53v1.dtbo'
007578.106: brfs: File read: /mfs/sd/overlays/vc4-kms-dpi-at056tn53v1.dtbo
007584.088: dterror: can't find symbol 'dpi_18bit_cpadhi_gpio0'
007584.099: Failed to resolve overlay 'vc4-kms-dpi-at056tn53v1'
007594.773: brfs: File read: 1861 bytes
Attachments
log messages.zip
(9.21 KiB) Downloaded 4 times

aBUGSworstnightmare
Posts: 3141
Joined: Tue Jun 30, 2015 1:35 pm

Re: [SOLVED] Need to define new color mappings to be used with DPI mode 6 (under KMS)

Wed Jul 14, 2021 2:53 pm

consider last post as solved! Might be a miss-match with dbs files causing it.

Return to “Interfacing (DSI, CSI, I2C, etc.)”