[U-Boot] [PATCH 1/2] fdt_support: support adding EDID property to FDT display nodes
Boards can pass display timing info for drivers using EDID block. Provide common function to add board specific EDID data to the device tree. Subsequent patch makes use of this functionality.
Signed-off-by: Anatolij Gustschin agust@denx.de Cc: Gerald Van Baren vanbaren@cideas.com --- common/fdt_support.c | 29 +++++++++++++++++++++++++++++ include/fdt_support.h | 1 + 2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c index 33336be..13c8882 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -1171,3 +1171,32 @@ int fdt_alloc_phandle(void *blob)
return phandle + 1; } + +#if defined(CONFIG_VIDEO) +int fdt_add_edid(void *blob, const char *compat, unsigned char *edid_buf) +{ + int noff; + int ret; + + noff = fdt_node_offset_by_compatible(blob, -1, compat); + if (noff != -FDT_ERR_NOTFOUND) { + debug("%s: %s\n", fdt_get_name(blob, noff, 0), compat); +add_edid: + ret = fdt_setprop(blob, noff, "edid", edid_buf, 128); + if (ret == -FDT_ERR_NOSPACE) { + ret = fdt_increase_size(blob, 512); + if (!ret) + goto add_edid; + else + goto err_size; + } else if (ret < 0) { + printf("Can't add property: %s\n", fdt_strerror(ret)); + return ret; + } + } + return 0; +err_size: + printf("Can't increase blob size: %s\n", fdt_strerror(ret)); + return ret; +} +#endif diff --git a/include/fdt_support.h b/include/fdt_support.h index 871ef45..b2a7a0c 100644 --- a/include/fdt_support.h +++ b/include/fdt_support.h @@ -87,6 +87,7 @@ u64 fdt_translate_address(void *blob, int node_offset, const u32 *in_addr); int fdt_node_offset_by_compat_reg(void *blob, const char *compat, phys_addr_t compat_off); int fdt_alloc_phandle(void *blob); +int fdt_add_edid(void *blob, const char *compat, unsigned char *buf);
#endif /* ifdef CONFIG_OF_LIBFDT */ #endif /* ifndef __FDT_SUPPORT_H */
PDM360NG board uses this functionality to pass display timing info to the Linux Framebuffer driver.
Signed-off-by: Anatolij Gustschin agust@denx.de --- board/pdm360ng/pdm360ng.c | 24 ++++++++++++++++++++++++ 1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/board/pdm360ng/pdm360ng.c b/board/pdm360ng/pdm360ng.c index e3abeb8..06e7fde 100644 --- a/board/pdm360ng/pdm360ng.c +++ b/board/pdm360ng/pdm360ng.c @@ -518,6 +518,27 @@ struct node_info nodes[] = { }; #endif
+#if defined(CONFIG_VIDEO) +static unsigned char edid_buf[128] = { + 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, + 0x42, 0xC9, 0x34, 0x12, 0x01, 0x00, 0x00, 0x00, + 0x0A, 0x0C, 0x01, 0x03, 0x80, 0x98, 0x5B, 0x78, + 0xCA, 0x7E, 0x50, 0xA0, 0x58, 0x4E, 0x96, 0x25, + 0x1E, 0x50, 0x54, 0x00, 0x00, 0x00, 0x01, 0x01, + 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, + 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x80, 0x0C, + 0x20, 0x00, 0x31, 0xE0, 0x2D, 0x10, 0x2A, 0x80, + 0x12, 0x08, 0x30, 0xE4, 0x10, 0x00, 0x00, 0x18, + 0x00, 0x00, 0x00, 0xFD, 0x00, 0x38, 0x3C, 0x1F, + 0x3C, 0x04, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, + 0x20, 0x20, 0x00, 0x00, 0x00, 0xFF, 0x00, 0x50, + 0x4D, 0x30, 0x37, 0x30, 0x57, 0x4C, 0x33, 0x0A, + 0x0A, 0x0A, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0xFF, + 0x00, 0x41, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, + 0x30, 0x30, 0x30, 0x30, 0x30, 0x31, 0x00, 0xD4, +}; +#endif + void ft_board_setup(void *blob, bd_t *bd) { u32 val[8]; @@ -528,6 +549,9 @@ void ft_board_setup(void *blob, bd_t *bd) #ifdef CONFIG_FDT_FIXUP_PARTITIONS fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes)); #endif +#if defined(CONFIG_VIDEO) + fdt_add_edid(blob, "fsl,mpc5121-diu", edid_buf); +#endif
/* Fixup NOR FLASH mapping */ val[i++] = 0; /* chip select number */
Dear Anatolij Gustschin,
In message 1281963128-13777-2-git-send-email-agust@denx.de you wrote:
PDM360NG board uses this functionality to pass display timing info to the Linux Framebuffer driver.
thanks for these patches.
I have one (probably stupid) question:
+static unsigned char edid_buf[128] = {
- 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00,
- 0x42, 0xC9, 0x34, 0x12, 0x01, 0x00, 0x00, 0x00,
- 0x0A, 0x0C, 0x01, 0x03, 0x80, 0x98, 0x5B, 0x78,
- 0xCA, 0x7E, 0x50, 0xA0, 0x58, 0x4E, 0x96, 0x25,
- 0x1E, 0x50, 0x54, 0x00, 0x00, 0x00, 0x01, 0x01,
- 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
- 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x80, 0x0C,
- 0x20, 0x00, 0x31, 0xE0, 0x2D, 0x10, 0x2A, 0x80,
- 0x12, 0x08, 0x30, 0xE4, 0x10, 0x00, 0x00, 0x18,
- 0x00, 0x00, 0x00, 0xFD, 0x00, 0x38, 0x3C, 0x1F,
- 0x3C, 0x04, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20,
- 0x20, 0x20, 0x00, 0x00, 0x00, 0xFF, 0x00, 0x50,
- 0x4D, 0x30, 0x37, 0x30, 0x57, 0x4C, 0x33, 0x0A,
- 0x0A, 0x0A, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0xFF,
- 0x00, 0x41, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30,
- 0x30, 0x30, 0x30, 0x30, 0x30, 0x31, 0x00, 0xD4,
+};
Is there a way to make these magic numbers readbale for a mere human?
How do you generate these?
Best regards,
Wolfgang Denk
Hello Wolfgang,
On Mon, 16 Aug 2010 16:02:14 +0200 Wolfgang Denk wd@denx.de wrote: ...
I have one (probably stupid) question:
+static unsigned char edid_buf[128] = {
- 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00,
- 0x42, 0xC9, 0x34, 0x12, 0x01, 0x00, 0x00, 0x00,
- 0x0A, 0x0C, 0x01, 0x03, 0x80, 0x98, 0x5B, 0x78,
- 0xCA, 0x7E, 0x50, 0xA0, 0x58, 0x4E, 0x96, 0x25,
- 0x1E, 0x50, 0x54, 0x00, 0x00, 0x00, 0x01, 0x01,
- 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
- 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x80, 0x0C,
- 0x20, 0x00, 0x31, 0xE0, 0x2D, 0x10, 0x2A, 0x80,
- 0x12, 0x08, 0x30, 0xE4, 0x10, 0x00, 0x00, 0x18,
- 0x00, 0x00, 0x00, 0xFD, 0x00, 0x38, 0x3C, 0x1F,
- 0x3C, 0x04, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20,
- 0x20, 0x20, 0x00, 0x00, 0x00, 0xFF, 0x00, 0x50,
- 0x4D, 0x30, 0x37, 0x30, 0x57, 0x4C, 0x33, 0x0A,
- 0x0A, 0x0A, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0xFF,
- 0x00, 0x41, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30,
- 0x30, 0x30, 0x30, 0x30, 0x30, 0x31, 0x00, 0xD4,
+};
Is there a way to make these magic numbers readbale for a mere human?
The numbers encode some strings (manufacturer, date, display name, etc.) and display parameter numbers. I already thought about the way how to easily generate the structure. Using some macros doesn't make sense, I think. Better would be to describe the display in a file and write a tool that generates the edid data structure from this description.
How do you generate these?
I generated the block using Phoenix EDID Designer 1.3 (a tool for Windows). This creates a text file like:
EDID BYTES: 0x 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ------------------------------------------------ 00 | 00 FF FF FF FF FF FF 00 42 C9 34 12 01 00 00 00 10 | 0A 0C 01 03 80 98 5B 78 CA 7E 50 A0 58 4E 96 25 20 | 1E 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 30 | 01 01 01 01 01 01 80 0C 20 40 31 E0 26 10 18 80 40 | 36 00 30 E4 10 00 00 18 00 00 00 FD 00 38 3C 1F 50 | 3C 04 0A 20 20 20 20 20 20 20 00 00 00 FF 00 50 60 | 4D 30 37 30 57 4C 33 0A 0A 0A 0A 0A 00 00 00 FF 70 | 00 41 30 30 30 30 30 30 30 30 30 30 30 31 00 91
Then I manualy converted the needed bytes to a char array.
Best regards, Anatolij
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
Hi Anatolij,
Hello Wolfgang,
On Mon, 16 Aug 2010 16:02:14 +0200 Wolfgang Denk wd@denx.de wrote: ...
I have one (probably stupid) question:
+static unsigned char edid_buf[128] = {
- 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00,
- 0x42, 0xC9, 0x34, 0x12, 0x01, 0x00, 0x00, 0x00,
- 0x0A, 0x0C, 0x01, 0x03, 0x80, 0x98, 0x5B, 0x78,
- 0xCA, 0x7E, 0x50, 0xA0, 0x58, 0x4E, 0x96, 0x25,
- 0x1E, 0x50, 0x54, 0x00, 0x00, 0x00, 0x01, 0x01,
- 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
- 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x80, 0x0C,
- 0x20, 0x00, 0x31, 0xE0, 0x2D, 0x10, 0x2A, 0x80,
- 0x12, 0x08, 0x30, 0xE4, 0x10, 0x00, 0x00, 0x18,
- 0x00, 0x00, 0x00, 0xFD, 0x00, 0x38, 0x3C, 0x1F,
- 0x3C, 0x04, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20,
- 0x20, 0x20, 0x00, 0x00, 0x00, 0xFF, 0x00, 0x50,
- 0x4D, 0x30, 0x37, 0x30, 0x57, 0x4C, 0x33, 0x0A,
- 0x0A, 0x0A, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0xFF,
- 0x00, 0x41, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30,
- 0x30, 0x30, 0x30, 0x30, 0x30, 0x31, 0x00, 0xD4,
+};
Is there a way to make these magic numbers readbale for a mere human?
The numbers encode some strings (manufacturer, date, display name, etc.) and display parameter numbers. I already thought about the way how to easily generate the structure. Using some macros doesn't make sense, I think. Better would be to describe the display in a file and write a tool that generates the edid data structure from this description.
I don't believe that currently we have a need for such a tool. When we can document "verbally" how to generate the data and if it is used often enough, then maybe someone comes up with a cleverer solution.
How do you generate these?
I generated the block using Phoenix EDID Designer 1.3 (a tool for Windows). This creates a text file like:
EDID BYTES: 0x 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ------------------------------------------------ 00 | 00 FF FF FF FF FF FF 00 42 C9 34 12 01 00 00 00 10 | 0A 0C 01 03 80 98 5B 78 CA 7E 50 A0 58 4E 96 25 20 | 1E 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 30 | 01 01 01 01 01 01 80 0C 20 40 31 E0 26 10 18 80 40 | 36 00 30 E4 10 00 00 18 00 00 00 FD 00 38 3C 1F 50 | 3C 04 0A 20 20 20 20 20 20 20 00 00 00 FF 00 50 60 | 4D 30 37 30 57 4C 33 0A 0A 0A 0A 0A 00 00 00 FF 70 | 00 41 30 30 30 30 30 30 30 30 30 30 30 31 00 91
Then I manualy converted the needed bytes to a char array.
Then put this text as a "how-to comment" next to the data. This _is_ valuable informatino which we do not want to loose. Rather then putting it in a commit message, this will keep the comment intact once people begin copying the construct around.
Cheers Detlev
PDM360NG board uses this functionality to pass display timing info to the Linux Framebuffer driver.
Signed-off-by: Anatolij Gustschin agust@denx.de --- v2: - added "howto comment" explaining the generation of EDID data block.
board/pdm360ng/pdm360ng.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/board/pdm360ng/pdm360ng.c b/board/pdm360ng/pdm360ng.c index e3abeb8..d154517 100644 --- a/board/pdm360ng/pdm360ng.c +++ b/board/pdm360ng/pdm360ng.c @@ -518,6 +518,46 @@ struct node_info nodes[] = { }; #endif
+#if defined(CONFIG_VIDEO) +/* + * EDID block has been generated using Phoenix EDID Designer 1.3. + * This tool creates a text file containing: + * + * EDID BYTES: + * 0x 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F + * ------------------------------------------------ + * 00 | 00 FF FF FF FF FF FF 00 42 C9 34 12 01 00 00 00 + * 10 | 0A 0C 01 03 80 98 5B 78 CA 7E 50 A0 58 4E 96 25 + * 20 | 1E 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 + * 30 | 01 01 01 01 01 01 80 0C 20 00 31 E0 2D 10 2A 80 + * 40 | 12 08 30 E4 10 00 00 18 00 00 00 FD 00 38 3C 1F + * 50 | 3C 04 0A 20 20 20 20 20 20 20 00 00 00 FF 00 50 + * 60 | 4D 30 37 30 57 4C 33 0A 0A 0A 0A 0A 00 00 00 FF + * 70 | 00 41 30 30 30 30 30 30 30 30 30 30 30 31 00 D4 + * + * Then this data has been manually converted to the char + * array below. + */ +static unsigned char edid_buf[128] = { + 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, + 0x42, 0xC9, 0x34, 0x12, 0x01, 0x00, 0x00, 0x00, + 0x0A, 0x0C, 0x01, 0x03, 0x80, 0x98, 0x5B, 0x78, + 0xCA, 0x7E, 0x50, 0xA0, 0x58, 0x4E, 0x96, 0x25, + 0x1E, 0x50, 0x54, 0x00, 0x00, 0x00, 0x01, 0x01, + 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, + 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x80, 0x0C, + 0x20, 0x00, 0x31, 0xE0, 0x2D, 0x10, 0x2A, 0x80, + 0x12, 0x08, 0x30, 0xE4, 0x10, 0x00, 0x00, 0x18, + 0x00, 0x00, 0x00, 0xFD, 0x00, 0x38, 0x3C, 0x1F, + 0x3C, 0x04, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, + 0x20, 0x20, 0x00, 0x00, 0x00, 0xFF, 0x00, 0x50, + 0x4D, 0x30, 0x37, 0x30, 0x57, 0x4C, 0x33, 0x0A, + 0x0A, 0x0A, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0xFF, + 0x00, 0x41, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, + 0x30, 0x30, 0x30, 0x30, 0x30, 0x31, 0x00, 0xD4, +}; +#endif + void ft_board_setup(void *blob, bd_t *bd) { u32 val[8]; @@ -528,6 +568,9 @@ void ft_board_setup(void *blob, bd_t *bd) #ifdef CONFIG_FDT_FIXUP_PARTITIONS fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes)); #endif +#if defined(CONFIG_VIDEO) + fdt_add_edid(blob, "fsl,mpc5121-diu", edid_buf); +#endif
/* Fixup NOR FLASH mapping */ val[i++] = 0; /* chip select number */
Hi Anatolij,
PDM360NG board uses this functionality to pass display timing info to the Linux Framebuffer driver.
Signed-off-by: Anatolij Gustschin agust@denx.de
Acked-by: Detlev Zundel dzu@denx.de
Thanks! Detlev
Dear Anatolij Gustschin,
In message 1282059962-9001-1-git-send-email-agust@denx.de you wrote:
PDM360NG board uses this functionality to pass display timing info to the Linux Framebuffer driver.
Signed-off-by: Anatolij Gustschin agust@denx.de
v2:
- added "howto comment" explaining the generation of EDID data block.
board/pdm360ng/pdm360ng.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 43 insertions(+), 0 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
Hi Anatolij,
Boards can pass display timing info for drivers using EDID block. Provide common function to add board specific EDID data to the device tree. Subsequent patch makes use of this functionality.
You could mention that this is currently implemented on the Linux side by the fsl-diu-fb driver and it is documented there in Documentation/powerpc/dts-bindings/fsl/diu.txt.
Signed-off-by: Anatolij Gustschin agust@denx.de Cc: Gerald Van Baren vanbaren@cideas.com
Acked-by: Detlev Zundel dzu@denx.de
Thanks Detlev
Boards can pass display timing info for drivers using EDID block. Provide common function to add board specific EDID data to the device tree. Subsequent patch makes use of this functionality.
Detailed timing descriptor data from EDID is used for programming the display controller. This is currently implemented on the Linux side by the fsl-diu-fb frame buffer driver and it is documented there in Documentation/powerpc/dts-bindings/fsl/diu.txt.
Signed-off-by: Anatolij Gustschin agust@denx.de Acked-by: Detlev Zundel dzu@denx.de Cc: Gerald Van Baren vanbaren@cideas.com --- v2: - improve commit message as suggested by Detlev - add Acked-by line
common/fdt_support.c | 29 +++++++++++++++++++++++++++++ include/fdt_support.h | 1 + 2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c index 33336be..13c8882 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -1171,3 +1171,32 @@ int fdt_alloc_phandle(void *blob)
return phandle + 1; } + +#if defined(CONFIG_VIDEO) +int fdt_add_edid(void *blob, const char *compat, unsigned char *edid_buf) +{ + int noff; + int ret; + + noff = fdt_node_offset_by_compatible(blob, -1, compat); + if (noff != -FDT_ERR_NOTFOUND) { + debug("%s: %s\n", fdt_get_name(blob, noff, 0), compat); +add_edid: + ret = fdt_setprop(blob, noff, "edid", edid_buf, 128); + if (ret == -FDT_ERR_NOSPACE) { + ret = fdt_increase_size(blob, 512); + if (!ret) + goto add_edid; + else + goto err_size; + } else if (ret < 0) { + printf("Can't add property: %s\n", fdt_strerror(ret)); + return ret; + } + } + return 0; +err_size: + printf("Can't increase blob size: %s\n", fdt_strerror(ret)); + return ret; +} +#endif diff --git a/include/fdt_support.h b/include/fdt_support.h index 871ef45..b2a7a0c 100644 --- a/include/fdt_support.h +++ b/include/fdt_support.h @@ -87,6 +87,7 @@ u64 fdt_translate_address(void *blob, int node_offset, const u32 *in_addr); int fdt_node_offset_by_compat_reg(void *blob, const char *compat, phys_addr_t compat_off); int fdt_alloc_phandle(void *blob); +int fdt_add_edid(void *blob, const char *compat, unsigned char *buf);
#endif /* ifdef CONFIG_OF_LIBFDT */ #endif /* ifndef __FDT_SUPPORT_H */
Dear Anatolij Gustschin,
In message 1282123520-25823-1-git-send-email-agust@denx.de you wrote:
Boards can pass display timing info for drivers using EDID block. Provide common function to add board specific EDID data to the device tree. Subsequent patch makes use of this functionality.
Detailed timing descriptor data from EDID is used for programming the display controller. This is currently implemented on the Linux side by the fsl-diu-fb frame buffer driver and it is documented there in Documentation/powerpc/dts-bindings/fsl/diu.txt.
Signed-off-by: Anatolij Gustschin agust@denx.de Acked-by: Detlev Zundel dzu@denx.de Cc: Gerald Van Baren vanbaren@cideas.com
v2:
- improve commit message as suggested by Detlev
- add Acked-by line
common/fdt_support.c | 29 +++++++++++++++++++++++++++++ include/fdt_support.h | 1 + 2 files changed, 30 insertions(+), 0 deletions(-)
Applied.
Jerry, hope it's OK with you that I pulled this directly.
Best regards,
Wolfgang Denk
On 10/12/2010 3:06 PM, Wolfgang Denk wrote:
Dear Anatolij Gustschin,
In message1282123520-25823-1-git-send-email-agust@denx.de you wrote:
[snip]
Signed-off-by: Anatolij Gustschinagust@denx.de Acked-by: Detlev Zundeldzu@denx.de Cc: Gerald Van Barenvanbaren@cideas.com
v2:
- improve commit message as suggested by Detlev
- add Acked-by line
common/fdt_support.c | 29 +++++++++++++++++++++++++++++ include/fdt_support.h | 1 + 2 files changed, 30 insertions(+), 0 deletions(-)
Applied.
Jerry, hope it's OK with you that I pulled this directly.
Yes, thanks.
Best regards, Wolfgang Denk
Best regards, gvb
participants (4)
-
Anatolij Gustschin -
Detlev Zundel -
Jerry Van baren -
Wolfgang Denk