Hi Stefano,
On 09/12/2013 03:17 AM, Stefano Babic wrote:
Hi Fabio,
On 11/09/2013 23:14, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@freescale.com
If a HDMI cable is not connected, the following message is seen on boot:
CPU: Freescale i.MX6Q rev1.1 at 792 MHz Reset cause: POR Board: MX6-SabreSD DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 No panel detected: default to HDMI unsupported panel HDMI
Reset the 'i' variable to fix the 'unsupported panel' message.
This follows the same idea of commit 47ac53d7ae (imx: nitrogen6x/mx6qsabrelite: Fix bug in board_video_skip).
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
board/freescale/mx6sabresd/mx6sabresd.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c b/board/freescale/mx6sabresd/mx6sabresd.c index 0f91fe2..61fe67c 100644 --- a/board/freescale/mx6sabresd/mx6sabresd.c +++ b/board/freescale/mx6sabresd/mx6sabresd.c @@ -322,6 +322,7 @@ int board_video_skip(void) if (!panel) { panel = displays[0].mode.name; printf("No panel detected: default to %s\n", panel);
i = 0;Robert sents the same fix for nitrogen6x, and it was integrated. The two functions board_video_skip() are exactly the same. What about to factorizee the code putting it maybe in imx-common ?
We can do this, but as I mentioned in my earlier e-mail, I hope this code doesn't have a long shelf life.
It seems reasonable to have a small number of displays supported by various boards (those offered as part of standard EVKs), but we integrate dozens of displays every year and it's not reasonable to change the code base for all of them.
To distill some earlier conversations: - Display timing information should be data, and preferably stored in the environment so it can be used early in the boot process.
- Display selection in U-Boot should be translatable into kernel parameters (bootargs or device-tree)
The main problem lies in the second, since at the moment, both the 3.0.35 kernel tree and the 3.5.7 kernel tree use either mode strings or named display types as display configuration. The mode strings (VESA GTF timings) are useful, but not all panels work optimally with those timings, causing the kernel to suffer the same requirement to update a data table for the new display.
For any that didn't participate in the earlier discussion, some notes can be found in this thread: http://lists.denx.de/pipermail/u-boot/2013-July/thread.html#159514
After my first shudder at using DT for this, I am currently of the belief that some form of detailed timing as is done in the kernel FB bindings is appropriate:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documen...
The primary concern I have is whether adding the ability to parse this nested structure is appropriate, and again, the inability to pass the information to current i.MX6 kernels.
I think the right thing may be to simply require **all** fields from the DT structure and allow prompting of each.
And of course, add kernel patches to allow them to accept the detailed information.
Please let me know your thoughts on this.
Regards,
Eric