[U-Boot] [PATCH 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm

[Eric Nelson]

Hi Stefano,

On 09/23/2012 08:56 AM, Stefano Babic wrote:
> On 22/09/2012 16:37, Fabio Estevam wrote:
>> On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador
>> <otavio at ossystems.com.br>  wrote:
>>> Hello Eric,
>>>
>>> On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson
>>> <eric.nelson at boundarydevices.com>  wrote:
>>>> Signed-off-by: Eric Nelson<eric.nelson at boundarydevices.com>
>>>
>>> Did you test it in mx5 too? We seem to need to handle it in mx5 too as
>>> we had hungs in FSL kernel when using framebuffer in U-Boot. We're
>>> using a patch in kernel for workaround it but it seems your fix does
>>> what is need.
>>
>> I have just tested Eric's series on a mx53loco and it does fix the
>> kernel hang issue.
>>
>> I made some comments on this series and hopefully Eric's v2 can get
>> into 2012.10, since this is a bug fix.
>
> Ok, I am waiting for V2 and I will push it.
>

I'll forward this later today.

> Anyway, a question about the issue. It seems to me that it is not
> possible with IPUV3 (I have not tested myself, so my question) to get
> the u-boot splashscreen displayed on the LCD until the kernel has
> finished to boot. This could be possible (and it is possible on other
> SOC) if the IPU is loaded as module instead of statically linked to the
> kernel, and if the kernel does not touch the IPU setup. This means also
> that it should not disable the clocks used by U-Boot for the IPU.
>

I'm not sure I understand. The splash screen comes up as soon as
the call to ipuv3_fb_init() is made (in board_video_skip() in my
implementation for SABRE Lite).

As it stands, if we leave the IPU running, we'll see garbage on
the display as the kernel re-purposes the RAM used by U-Boot's
frame buffer.

> But I understand from your patch that this way is not possible on
> iMX53/MX6, and IPU must be always disabled. Is this correct ?
>

Sascha responded to a note about this on AKML that the hand-over of
a live FB isn't a supported kernel use case and it's definitely
tricky.

I don't know about the policy, but from a practical matter, the
IPU frame buffer implementation in U-Boot isn't currently up to
that task, since:
	it only supports a single display (i.MX6 can handle 4)
	it only supports 16bpp

Additional functionality would be helpful here.

I would like to see a handoff of display settings from U-Boot to
the kernel, but that's also a tricky thing as long as we're supporting
different mechanisms (DT in main-line and kernel parameters in
older kernels).

Regards,


Eric