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 >>> <ota...@ossystems.com.br> wrote: >>>> Hello Eric, >>>> >>>> On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson >>>> <eric.nel...@boundarydevices.com> wrote: >>>>> Signed-off-by: Eric Nelson<eric.nel...@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: sba...@denx.de ===================================================================== _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
