[U-Boot] [PATCH v2 2/2] mx6sabresd: Reset counter to prevent error message

[Eric Nelson <eric.nelson@boundarydevices.com>]

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/Documentation/devicetree/bindings/fb/mxsfb.txt?id=refs/tags/v3.11

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