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

[Stefano Babic]

On 23/09/2012 18:46, Eric Nelson wrote:
> 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.

Ok

> 
>> 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.

Right, if the kernel reuse the same memory. I am aware that it is not
implemented, I am asking if there some reason to make it impossible.

Some customers want to have a picture shown on the LCD until their
application is running. This makes sense, because the application can
take a lot of time before displaying something on the LCD.

If we reserve some memory for this scope, that is not used by the kernel
later (passing the mem= parameter, for example, or using a .reserve
entry in the board initialization code), we can reach the goal. In
U-Boot we have a single display with 16bit, that means that the memory
consumption is not very high.

> 
>> 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.

And I agree with him, the handover is tricky and not easy, I mean, it
can work with a SOC (it remains tricky..) but not with another one. What
I am saying is not this, but what happens if the IPU is not touched
until the IPU modules are loaded.

> 
> 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.

Agree with you. And this is the reason I am not supposing that the
kernel takes the IPU setup made by U-Boot. It could be a nightmare.

> 
> 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).

Yes, and a lot of other things. I know Anatolji implemented this
behavior for a PPC5121, but we cannot generalize. I agree that the
handoff is difficult and not maintainable. My question is different: if
the IPU drivers in kernel are compiled as modules, and I will load them
only after booting, and the framebuffer's memory is reserved so that the
kernel does not touch it, is there still a known reason because the IPU
should not run when we boot the kernel? I know this issue with USB,
maybe we have now the same with the IPU.

Note: this has nothing to do with this patch ;-). I will merge it into
the current release when you push V2.

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================