| Message ID | 1389165866-17509-3-git-send-email-christian.gmeiner@gmail.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Anatolij Gustschin |
| Headers | show |
Hi Christian, On 08/01/2014 08:24, Christian Gmeiner wrote: > This new function is used to set all display-timings > properties based on fb_videomode. > > display-timings { > timing0 { > clock-frequency = <25000000>; > hactive = <640>; > vactive = <480>; > hback-porch = <48>; > hfront-porch = <16>; > vback-porch = <31>; > vfront-porch = <12>; > hsync-len = <96>; > vsync-len = <2>; > }; > }; > > Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> > --- > common/fdt_support.c | 23 +++++++++++++++++++++++ > include/fdt_support.h | 3 +++ > 2 files changed, 26 insertions(+) > > diff --git a/common/fdt_support.c b/common/fdt_support.c > index 4e32b02..cf81a4b 100644 > --- a/common/fdt_support.c > +++ b/common/fdt_support.c > @@ -11,6 +11,7 @@ > #include <stdio_dev.h> > #include <linux/ctype.h> > #include <linux/types.h> > +#include <linux/fb.h> > #include <asm/global_data.h> > #include <libfdt.h> > #include <fdt_support.h> > @@ -1342,6 +1343,28 @@ err_size: > #endif > > /* > + * fdt_add_display_timings: add display-timings properties > + * > + * @fdt: ptr to device tree > + * @noff: node to update > + * @mode: ptr to b_videomode > + */ > +void fdt_add_display_timings(void *fdt, int noff, struct fb_videomode *mode) > +{ > + if (noff != -FDT_ERR_NOTFOUND) { > + fdt_setprop_u32(fdt, noff, "clock-frequency", mode->pixclock); > + fdt_setprop_u32(fdt, noff, "hactive", mode->xres); > + fdt_setprop_u32(fdt, noff, "vactive", mode->yres); > + fdt_setprop_u32(fdt, noff, "hback-porch", mode->left_margin); > + fdt_setprop_u32(fdt, noff, "hfront-porch", mode->right_margin); > + fdt_setprop_u32(fdt, noff, "vback-porch", mode->upper_margin); > + fdt_setprop_u32(fdt, noff, "vfront-porch", mode->lower_margin); > + fdt_setprop_u32(fdt, noff, "hsync-len", mode->hsync_len); > + fdt_setprop_u32(fdt, noff, "vsync-len", mode->vsync_len); > + } > +} > + > +/* > * Verify the physical address of device tree node for a given alias > * > * This function locates the device tree node of a given alias, and then > diff --git a/include/fdt_support.h b/include/fdt_support.h > index 9871e2f..1c54880 100644 > --- a/include/fdt_support.h > +++ b/include/fdt_support.h > @@ -82,6 +82,9 @@ int fdt_set_phandle(void *fdt, int nodeoffset, uint32_t phandle); > unsigned int fdt_create_phandle(void *fdt, int nodeoffset); > int fdt_add_edid(void *blob, const char *compat, unsigned char *buf); > > +struct fb_videomode; > +void fdt_add_display_timings(void *blob, int noff, struct fb_videomode *mode); > + > int fdt_verify_alias_address(void *fdt, int anode, const char *alias, > u64 addr); > u64 fdt_get_base_address(void *fdt, int node); > Agree that we have to sync u-boot and kernel, and this can be a way in the short term. I am asking if this is in the long term the best way to do it. You are converting EDID values to fb_videomode *mode, and then again to the device node as required by DT. We have already had some talks about moving U-Boot configuration to DT, that is U-Boot can be also configured by a DT file (see for example support for Nvidia processors, they already support DT in U-Boot). Anatolji, what do you think as best solution we have to follow for display setting ? Best regards, Stefano Babic
Hi Stefano, 2014/1/8 Stefano Babic <sbabic@denx.de>: > Hi Christian, > > On 08/01/2014 08:24, Christian Gmeiner wrote: >> This new function is used to set all display-timings >> properties based on fb_videomode. >> >> display-timings { >> timing0 { >> clock-frequency = <25000000>; >> hactive = <640>; >> vactive = <480>; >> hback-porch = <48>; >> hfront-porch = <16>; >> vback-porch = <31>; >> vfront-porch = <12>; >> hsync-len = <96>; >> vsync-len = <2>; >> }; >> }; >> >> Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> >> --- >> common/fdt_support.c | 23 +++++++++++++++++++++++ >> include/fdt_support.h | 3 +++ >> 2 files changed, 26 insertions(+) >> >> diff --git a/common/fdt_support.c b/common/fdt_support.c >> index 4e32b02..cf81a4b 100644 >> --- a/common/fdt_support.c >> +++ b/common/fdt_support.c >> @@ -11,6 +11,7 @@ >> #include <stdio_dev.h> >> #include <linux/ctype.h> >> #include <linux/types.h> >> +#include <linux/fb.h> >> #include <asm/global_data.h> >> #include <libfdt.h> >> #include <fdt_support.h> >> @@ -1342,6 +1343,28 @@ err_size: >> #endif >> >> /* >> + * fdt_add_display_timings: add display-timings properties >> + * >> + * @fdt: ptr to device tree >> + * @noff: node to update >> + * @mode: ptr to b_videomode >> + */ >> +void fdt_add_display_timings(void *fdt, int noff, struct fb_videomode *mode) >> +{ >> + if (noff != -FDT_ERR_NOTFOUND) { >> + fdt_setprop_u32(fdt, noff, "clock-frequency", mode->pixclock); >> + fdt_setprop_u32(fdt, noff, "hactive", mode->xres); >> + fdt_setprop_u32(fdt, noff, "vactive", mode->yres); >> + fdt_setprop_u32(fdt, noff, "hback-porch", mode->left_margin); >> + fdt_setprop_u32(fdt, noff, "hfront-porch", mode->right_margin); >> + fdt_setprop_u32(fdt, noff, "vback-porch", mode->upper_margin); >> + fdt_setprop_u32(fdt, noff, "vfront-porch", mode->lower_margin); >> + fdt_setprop_u32(fdt, noff, "hsync-len", mode->hsync_len); >> + fdt_setprop_u32(fdt, noff, "vsync-len", mode->vsync_len); >> + } >> +} >> + >> +/* >> * Verify the physical address of device tree node for a given alias >> * >> * This function locates the device tree node of a given alias, and then >> diff --git a/include/fdt_support.h b/include/fdt_support.h >> index 9871e2f..1c54880 100644 >> --- a/include/fdt_support.h >> +++ b/include/fdt_support.h >> @@ -82,6 +82,9 @@ int fdt_set_phandle(void *fdt, int nodeoffset, uint32_t phandle); >> unsigned int fdt_create_phandle(void *fdt, int nodeoffset); >> int fdt_add_edid(void *blob, const char *compat, unsigned char *buf); >> >> +struct fb_videomode; >> +void fdt_add_display_timings(void *blob, int noff, struct fb_videomode *mode); >> + >> int fdt_verify_alias_address(void *fdt, int anode, const char *alias, >> u64 addr); >> u64 fdt_get_base_address(void *fdt, int node); >> > > Agree that we have to sync u-boot and kernel, and this can be a way in > the short term. > > I am asking if this is in the long term the best way to do it. You are > converting EDID values to fb_videomode *mode, and then again to the > device node as required by DT. > We have already had some talks about moving U-Boot configuration to DT, > that is U-Boot can be also configured by a DT file (see for example > support for Nvidia processors, they already support DT in U-Boot). > The problem for me here is that DT only does not work in my case. As it is possible to attach different panels/displays via lvds (different timings and resolutions) we have put an at24 on our print, which contains the suitable EDID data. So I need to readout the at24 every boot and need to manipulate the loaded (emmc) DT. > Anatolji, what do you think as best solution we have to follow for > display setting ? > thanks -- Christian Gmeiner, MSc
Hi Christian, On 09/01/2014 08:12, Christian Gmeiner wrote: >> Agree that we have to sync u-boot and kernel, and this can be a way in >> the short term. >> >> I am asking if this is in the long term the best way to do it. You are >> converting EDID values to fb_videomode *mode, and then again to the >> device node as required by DT. >> We have already had some talks about moving U-Boot configuration to DT, >> that is U-Boot can be also configured by a DT file (see for example >> support for Nvidia processors, they already support DT in U-Boot). >> > > The problem for me here is that DT only does not work in my case. As it is > possible to attach different panels/displays via lvds (different > timings and resolutions) > we have put an at24 on our print, which contains the suitable EDID data. > > So I need to readout the at24 every boot and need to manipulate the > loaded (emmc) DT. Understood, thanks for clarification. Agree that we need functions for EDID manipulation. My only concern remains if we need a temporary conversion to videomode as in this patch, or we go towards a edid-to-fdt() function. Regards, Stefano Babic
Hi Stefano, On 01/09/2014 03:44 AM, Stefano Babic wrote: > Hi Christian, > > On 09/01/2014 08:12, Christian Gmeiner wrote: > >>> Agree that we have to sync u-boot and kernel, and this can be a way in >>> the short term. >>> >>> I am asking if this is in the long term the best way to do it. You are >>> converting EDID values to fb_videomode *mode, and then again to the >>> device node as required by DT. >>> We have already had some talks about moving U-Boot configuration to DT, >>> that is U-Boot can be also configured by a DT file (see for example >>> support for Nvidia processors, they already support DT in U-Boot). >>> >> >> The problem for me here is that DT only does not work in my case. As it is >> possible to attach different panels/displays via lvds (different >> timings and resolutions) >> we have put an at24 on our print, which contains the suitable EDID data. >> >> So I need to readout the at24 every boot and need to manipulate the >> loaded (emmc) DT. > > Understood, thanks for clarification. Agree that we need functions for > EDID manipulation. My only concern remains if we need a temporary > conversion to videomode as in this patch, or we go towards a > edid-to-fdt() function. > I'd really like to keep Christian's patch and use it to remove the hard-coded resolutions as shown in SabreSD and Nitrogen6X boards: http://git.denx.de/?p=u-boot.git;a=blob;f=board/freescale/mx6sabresd/mx6sabresd.c;h=9dbe605cf4a5a8ba16c674f14b894ccb59bece9f;hb=HEAD#l266 http://git.denx.de/?p=u-boot.git;a=blob;f=board/boundary/nitrogen6x/nitrogen6x.c;h=53cb8dffd0d534629a4de5c7b9798733015adb6e;hb=HEAD#l520 Regards, Eric
Hi Eric, On 09/01/2014 15:52, Eric Nelson wrote: > Hi Stefano, > > On 01/09/2014 03:44 AM, Stefano Babic wrote: >> Hi Christian, >> >> On 09/01/2014 08:12, Christian Gmeiner wrote: >> >>>> Agree that we have to sync u-boot and kernel, and this can be a way in >>>> the short term. >>>> >>>> I am asking if this is in the long term the best way to do it. You are >>>> converting EDID values to fb_videomode *mode, and then again to the >>>> device node as required by DT. >>>> We have already had some talks about moving U-Boot configuration to DT, >>>> that is U-Boot can be also configured by a DT file (see for example >>>> support for Nvidia processors, they already support DT in U-Boot). >>>> >>> >>> The problem for me here is that DT only does not work in my case. As >>> it is >>> possible to attach different panels/displays via lvds (different >>> timings and resolutions) >>> we have put an at24 on our print, which contains the suitable EDID data. >>> >>> So I need to readout the at24 every boot and need to manipulate the >>> loaded (emmc) DT. >> >> Understood, thanks for clarification. Agree that we need functions for >> EDID manipulation. My only concern remains if we need a temporary >> conversion to videomode as in this patch, or we go towards a >> edid-to-fdt() function. >> > > I'd really like to keep Christian's patch and use it to remove > the hard-coded resolutions as shown in SabreSD and Nitrogen6X boards: > > http://git.denx.de/?p=u-boot.git;a=blob;f=board/freescale/mx6sabresd/mx6sabresd.c;h=9dbe605cf4a5a8ba16c674f14b894ccb59bece9f;hb=HEAD#l266 > > http://git.denx.de/?p=u-boot.git;a=blob;f=board/boundary/nitrogen6x/nitrogen6x.c;h=53cb8dffd0d534629a4de5c7b9798733015adb6e;hb=HEAD#l520 > ok - I see also that Christian's patch fills the gap with the display setup in fdt. Regards, Stefano
On 01/09/2014 07:52 AM, Eric Nelson wrote: > Hi Stefano, > > On 01/09/2014 03:44 AM, Stefano Babic wrote: >> Hi Christian, >> >> On 09/01/2014 08:12, Christian Gmeiner wrote: >> >>>> Agree that we have to sync u-boot and kernel, and this can be a way in >>>> the short term. >>>> >>>> I am asking if this is in the long term the best way to do it. You are >>>> converting EDID values to fb_videomode *mode, and then again to the >>>> device node as required by DT. >>>> We have already had some talks about moving U-Boot configuration to DT, >>>> that is U-Boot can be also configured by a DT file (see for example >>>> support for Nvidia processors, they already support DT in U-Boot). >>>> >>> >>> The problem for me here is that DT only does not work in my case. As >>> it is >>> possible to attach different panels/displays via lvds (different >>> timings and resolutions) >>> we have put an at24 on our print, which contains the suitable EDID data. >>> >>> So I need to readout the at24 every boot and need to manipulate the >>> loaded (emmc) DT. >> >> Understood, thanks for clarification. Agree that we need functions for >> EDID manipulation. My only concern remains if we need a temporary >> conversion to videomode as in this patch, or we go towards a >> edid-to-fdt() function. In my opinion, without having read the patch or the rest of the thread: Both the DT and the EDID are sources for information about supported video modes. Those two sources (and any others that might appear later like ACPI or hard-coded modes inside U-Boot) should be directly converted to U-Boot's internal mode representation, rather than chaining conversions e.g. EDID -> DT -> internal.
HI Stephen. 2014/1/9 Stephen Warren <swarren@wwwdotorg.org>: > On 01/09/2014 07:52 AM, Eric Nelson wrote: >> Hi Stefano, >> >> On 01/09/2014 03:44 AM, Stefano Babic wrote: >>> Hi Christian, >>> >>> On 09/01/2014 08:12, Christian Gmeiner wrote: >>> >>>>> Agree that we have to sync u-boot and kernel, and this can be a way in >>>>> the short term. >>>>> >>>>> I am asking if this is in the long term the best way to do it. You are >>>>> converting EDID values to fb_videomode *mode, and then again to the >>>>> device node as required by DT. >>>>> We have already had some talks about moving U-Boot configuration to DT, >>>>> that is U-Boot can be also configured by a DT file (see for example >>>>> support for Nvidia processors, they already support DT in U-Boot). >>>>> >>>> >>>> The problem for me here is that DT only does not work in my case. As >>>> it is >>>> possible to attach different panels/displays via lvds (different >>>> timings and resolutions) >>>> we have put an at24 on our print, which contains the suitable EDID data. >>>> >>>> So I need to readout the at24 every boot and need to manipulate the >>>> loaded (emmc) DT. >>> >>> Understood, thanks for clarification. Agree that we need functions for >>> EDID manipulation. My only concern remains if we need a temporary >>> conversion to videomode as in this patch, or we go towards a >>> edid-to-fdt() function. > > In my opinion, without having read the patch or the rest of the thread: > Both the DT and the EDID are sources for information about supported > video modes. Those two sources (and any others that might appear later > like ACPI or hard-coded modes inside U-Boot) should be directly > converted to U-Boot's internal mode representation, rather than chaining > conversions e.g. EDID -> DT -> internal. The patch does this: EDID -> internal -> DT But it depends a little bit on your definition of "internal". greets -- Christian Gmeiner, MSc
Hi Stefano, On Wed, 08 Jan 2014 11:53:39 +0100 Stefano Babic <sbabic@denx.de> wrote: ... > Agree that we have to sync u-boot and kernel, and this can be a way in > the short term. > > I am asking if this is in the long term the best way to do it. You are > converting EDID values to fb_videomode *mode, and then again to the > device node as required by DT. > We have already had some talks about moving U-Boot configuration to DT, > that is U-Boot can be also configured by a DT file (see for example > support for Nvidia processors, they already support DT in U-Boot). > > Anatolji, what do you think as best solution we have to follow for > display setting ? many drivers use struct fb_videomode internally and this display-timings binding already exists in linux, so I think a function for converting from fb_videomode to DT is useful. However we should probably extend this current implementation of the function, e.g. rename it to fdt_update_display_timings() and pass more arguments: node compatible and the name of the parent node containing the display-timings node. The code for searching the display-timings node is also needed for other boards, so if it is in the function itself, it will simplify the usage. This function could look for display-timings node and create it if it doesn't exist. Or update the existing node with new info. Thanks, Anatolij
2014/1/12 Anatolij Gustschin <agust@denx.de>: > Hi Stefano, > > On Wed, 08 Jan 2014 11:53:39 +0100 > Stefano Babic <sbabic@denx.de> wrote: > ... >> Agree that we have to sync u-boot and kernel, and this can be a way in >> the short term. >> >> I am asking if this is in the long term the best way to do it. You are >> converting EDID values to fb_videomode *mode, and then again to the >> device node as required by DT. >> We have already had some talks about moving U-Boot configuration to DT, >> that is U-Boot can be also configured by a DT file (see for example >> support for Nvidia processors, they already support DT in U-Boot). >> >> Anatolji, what do you think as best solution we have to follow for >> display setting ? > > many drivers use struct fb_videomode internally and this display-timings > binding already exists in linux, so I think a function for converting > from fb_videomode to DT is useful. However we should probably extend > this current implementation of the function, e.g. rename it to > fdt_update_display_timings() and pass more arguments: node compatible > and the name of the parent node containing the display-timings node. > The code for searching the display-timings node is also needed for > other boards, so if it is in the function itself, it will simplify > the usage. > > This function could look for display-timings node and create it if > it doesn't exist. Or update the existing node with new info. > Thanks for your comments... will come up with something in the next version of the patch series. thanks -- Christian Gmeiner, MSc
Hi all 2014/1/14 Christian Gmeiner <christian.gmeiner@gmail.com>: > 2014/1/12 Anatolij Gustschin <agust@denx.de>: >> Hi Stefano, >> >> On Wed, 08 Jan 2014 11:53:39 +0100 >> Stefano Babic <sbabic@denx.de> wrote: >> ... >>> Agree that we have to sync u-boot and kernel, and this can be a way in >>> the short term. >>> >>> I am asking if this is in the long term the best way to do it. You are >>> converting EDID values to fb_videomode *mode, and then again to the >>> device node as required by DT. >>> We have already had some talks about moving U-Boot configuration to DT, >>> that is U-Boot can be also configured by a DT file (see for example >>> support for Nvidia processors, they already support DT in U-Boot). >>> >>> Anatolji, what do you think as best solution we have to follow for >>> display setting ? >> >> many drivers use struct fb_videomode internally and this display-timings >> binding already exists in linux, so I think a function for converting >> from fb_videomode to DT is useful. However we should probably extend >> this current implementation of the function, e.g. rename it to >> fdt_update_display_timings() and pass more arguments: node compatible >> and the name of the parent node containing the display-timings node. >> The code for searching the display-timings node is also needed for >> other boards, so if it is in the function itself, it will simplify >> the usage. >> >> This function could look for display-timings node and create it if >> it doesn't exist. Or update the existing node with new info. >> > > Thanks for your comments... will come up with something in the next version > of the patch series. > I have some time to work on this patch. Anatolij are you happy witht the following functions? int fdt_find_display_timings(void *fdt, const char *compat, const char *parent) { int coff = fdt_node_offset_by_compatible(fdt, -1, compat); int poff = fdt_subnode_offset(fdt, coff, parent); int timings = fdt_subnode_offset(fdt, poff, "display-timings"); return timings; } int fdt_update_display_timings(void *fdt, const char *compat, const char *parent, struct fb_videomode *mode) { int timings = fdt_find_display_timings(fdt, compat, parent); /* check if display-timings subnode does exist */ if (timings == -FDT_ERR_NOTFOUND) { return timings; } /* set all needed properties */ if (timings != -FDT_ERR_NOTFOUND) { fdt_setprop_u32(fdt, noff, "clock-frequency", mode->pixclock); fdt_setprop_u32(fdt, noff, "hactive", mode->xres); fdt_setprop_u32(fdt, noff, "vactive", mode->yres); fdt_setprop_u32(fdt, noff, "hback-porch", mode->left_margin); fdt_setprop_u32(fdt, noff, "hfront-porch", mode->right_margin); fdt_setprop_u32(fdt, noff, "vback-porch", mode->upper_margin); fdt_setprop_u32(fdt, noff, "vfront-porch", mode->lower_margin); fdt_setprop_u32(fdt, noff, "hsync-len", mode->hsync_len); fdt_setprop_u32(fdt, noff, "vsync-len", mode->vsync_len); } return 0; } This would allow us to update an existing display-timings node via fdt_update_display_timings(blob, "fsl,imx6q-ldb", "lvds-channel", mode); Note: not even compile tested :) thanks -- Christian Gmeiner, MSc
2014-01-16 12:44 GMT+01:00 Christian Gmeiner <christian.gmeiner@gmail.com>: > Hi all > > 2014/1/14 Christian Gmeiner <christian.gmeiner@gmail.com>: >> 2014/1/12 Anatolij Gustschin <agust@denx.de>: >>> Hi Stefano, >>> >>> On Wed, 08 Jan 2014 11:53:39 +0100 >>> Stefano Babic <sbabic@denx.de> wrote: >>> ... >>>> Agree that we have to sync u-boot and kernel, and this can be a way in >>>> the short term. >>>> >>>> I am asking if this is in the long term the best way to do it. You are >>>> converting EDID values to fb_videomode *mode, and then again to the >>>> device node as required by DT. >>>> We have already had some talks about moving U-Boot configuration to DT, >>>> that is U-Boot can be also configured by a DT file (see for example >>>> support for Nvidia processors, they already support DT in U-Boot). >>>> >>>> Anatolji, what do you think as best solution we have to follow for >>>> display setting ? >>> >>> many drivers use struct fb_videomode internally and this display-timings >>> binding already exists in linux, so I think a function for converting >>> from fb_videomode to DT is useful. However we should probably extend >>> this current implementation of the function, e.g. rename it to >>> fdt_update_display_timings() and pass more arguments: node compatible >>> and the name of the parent node containing the display-timings node. >>> The code for searching the display-timings node is also needed for >>> other boards, so if it is in the function itself, it will simplify >>> the usage. >>> >>> This function could look for display-timings node and create it if >>> it doesn't exist. Or update the existing node with new info. >>> >> >> Thanks for your comments... will come up with something in the next version >> of the patch series. >> > > I have some time to work on this patch. > > Anatolij are you happy witht the following functions? > > int fdt_find_display_timings(void *fdt, const char *compat, const char *parent) > { > int coff = fdt_node_offset_by_compatible(fdt, -1, compat); > int poff = fdt_subnode_offset(fdt, coff, parent); > int timings = fdt_subnode_offset(fdt, poff, "display-timings"); > > return timings; > } > > int fdt_update_display_timings(void *fdt, const char *compat, const > char *parent, struct fb_videomode *mode) > { > int timings = fdt_find_display_timings(fdt, compat, parent); > > /* check if display-timings subnode does exist */ > if (timings == -FDT_ERR_NOTFOUND) { > return timings; > } > > /* set all needed properties */ > if (timings != -FDT_ERR_NOTFOUND) { > fdt_setprop_u32(fdt, noff, "clock-frequency", mode->pixclock); > fdt_setprop_u32(fdt, noff, "hactive", mode->xres); > fdt_setprop_u32(fdt, noff, "vactive", mode->yres); > fdt_setprop_u32(fdt, noff, "hback-porch", mode->left_margin); > fdt_setprop_u32(fdt, noff, "hfront-porch", mode->right_margin); > fdt_setprop_u32(fdt, noff, "vback-porch", mode->upper_margin); > fdt_setprop_u32(fdt, noff, "vfront-porch", mode->lower_margin); > fdt_setprop_u32(fdt, noff, "hsync-len", mode->hsync_len); > fdt_setprop_u32(fdt, noff, "vsync-len", mode->vsync_len); > } > > return 0; > } > > This would allow us to update an existing display-timings node via > > fdt_update_display_timings(blob, "fsl,imx6q-ldb", "lvds-channel", mode); > > > Note: not even compile tested :) > I got no feedback over some months - bad. But okay I really want to get all the bits of our imx6 based board upstream as soon as possible. So has something changed in that area? In the end I want to read EDID stored in an eeprom and put it into the device tree (patching or creating new node). greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner
diff --git a/common/fdt_support.c b/common/fdt_support.c index 4e32b02..cf81a4b 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -11,6 +11,7 @@ #include <stdio_dev.h> #include <linux/ctype.h> #include <linux/types.h> +#include <linux/fb.h> #include <asm/global_data.h> #include <libfdt.h> #include <fdt_support.h> @@ -1342,6 +1343,28 @@ err_size: #endif /* + * fdt_add_display_timings: add display-timings properties + * + * @fdt: ptr to device tree + * @noff: node to update + * @mode: ptr to b_videomode + */ +void fdt_add_display_timings(void *fdt, int noff, struct fb_videomode *mode) +{ + if (noff != -FDT_ERR_NOTFOUND) { + fdt_setprop_u32(fdt, noff, "clock-frequency", mode->pixclock); + fdt_setprop_u32(fdt, noff, "hactive", mode->xres); + fdt_setprop_u32(fdt, noff, "vactive", mode->yres); + fdt_setprop_u32(fdt, noff, "hback-porch", mode->left_margin); + fdt_setprop_u32(fdt, noff, "hfront-porch", mode->right_margin); + fdt_setprop_u32(fdt, noff, "vback-porch", mode->upper_margin); + fdt_setprop_u32(fdt, noff, "vfront-porch", mode->lower_margin); + fdt_setprop_u32(fdt, noff, "hsync-len", mode->hsync_len); + fdt_setprop_u32(fdt, noff, "vsync-len", mode->vsync_len); + } +} + +/* * Verify the physical address of device tree node for a given alias * * This function locates the device tree node of a given alias, and then diff --git a/include/fdt_support.h b/include/fdt_support.h index 9871e2f..1c54880 100644 --- a/include/fdt_support.h +++ b/include/fdt_support.h @@ -82,6 +82,9 @@ int fdt_set_phandle(void *fdt, int nodeoffset, uint32_t phandle); unsigned int fdt_create_phandle(void *fdt, int nodeoffset); int fdt_add_edid(void *blob, const char *compat, unsigned char *buf); +struct fb_videomode; +void fdt_add_display_timings(void *blob, int noff, struct fb_videomode *mode); + int fdt_verify_alias_address(void *fdt, int anode, const char *alias, u64 addr); u64 fdt_get_base_address(void *fdt, int node);
This new function is used to set all display-timings properties based on fb_videomode. display-timings { timing0 { clock-frequency = <25000000>; hactive = <640>; vactive = <480>; hback-porch = <48>; hfront-porch = <16>; vback-porch = <31>; vfront-porch = <12>; hsync-len = <96>; vsync-len = <2>; }; }; Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> --- common/fdt_support.c | 23 +++++++++++++++++++++++ include/fdt_support.h | 3 +++ 2 files changed, 26 insertions(+)