| Message ID | 1348259795-9314-2-git-send-email-eric.nelson@boundarydevices.com |
|---|---|
| State | Superseded |
| Delegated to: | Anatolij Gustschin |
| Headers | show |
Hello Eric,
On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> Signed-off-by: Eric Nelson <eric.nelson@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.
Fabio did the workaround patch and knows the details. Added him in CC.
On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador <otavio@ossystems.com.br> wrote: > Hello Eric, > > On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson > <eric.nelson@boundarydevices.com> wrote: >> Signed-off-by: Eric Nelson <eric.nelson@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. Regards, Fabio Estevam
On Sat, Sep 22, 2012 at 11:37 AM, Fabio Estevam <festevam@gmail.com> wrote: > On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador > <otavio@ossystems.com.br> wrote: >> Hello Eric, >> >> On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson >> <eric.nelson@boundarydevices.com> wrote: >>> Signed-off-by: Eric Nelson <eric.nelson@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. Neat. :-)
On 22/09/2012 16:37, Fabio Estevam wrote: > On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador > <otavio@ossystems.com.br> wrote: >> Hello Eric, >> >> On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson >> <eric.nelson@boundarydevices.com> wrote: >>> Signed-off-by: Eric Nelson <eric.nelson@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. 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. But I understand from your patch that this way is not possible on iMX53/MX6, and IPU must be always disabled. Is this correct ? Best regards, Stefano
On 23.09.2012 17:56, Stefano Babic wrote: > On 22/09/2012 16:37, Fabio Estevam wrote: >> On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador >> <otavio@ossystems.com.br> wrote: >>> Hello Eric, >>> >>> On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson >>> <eric.nelson@boundarydevices.com> wrote: >>>> Signed-off-by: Eric Nelson<eric.nelson@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. > > 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. > > But I understand from your patch that this way is not possible on > iMX53/MX6, and IPU must be always disabled. Is this correct ? I'm no expert on this, so I might be wrong and people will correct me: No, not always. It's my understanding that at the *moment* we have to disable the IPU in U-Boot before jumping into the kernel due to a bug in Sascha's kernel IPU driver: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/121980.html http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/122100.html So from my understanding, this isn't a SOC limitation. But we have to do it as long as the kernel's IPU driver isn't fixed. Sorry if this is wrong ;) Best regards Dirk
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@ossystems.com.br> wrote: >>> Hello Eric, >>> >>> On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson >>> <eric.nelson@boundarydevices.com> wrote: >>>> Signed-off-by: Eric Nelson<eric.nelson@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
On Sun, Sep 23, 2012 at 1:46 PM, Eric Nelson <eric.nelson@boundarydevices.com> wrote: > 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. And on mx53qsb we get kernel hangs at about half of the boots (tested on 2.6.35 FSL kernel). So turning off the IPU in U-boot, as Eric did in this series is an important fix. Regards, Fabio Estevam
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@ossystems.com.br> wrote: >>>> Hello Eric, >>>> >>>> On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson >>>> <eric.nelson@boundarydevices.com> wrote: >>>>> Signed-off-by: Eric Nelson<eric.nelson@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
V2 moves arch_preboot_os() into arch/arm/imx-common/cpu.c
Hi Stefano, I changed the subject line because we've veered off-topic. On 09/23/2012 10:27 AM, Stefano Babic wrote: > 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@ossystems.com.br> wrote: >>>>> Hello Eric, >>>>> >>>>> On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson >>>>> <eric.nelson@boundarydevices.com> wrote: >>>>>> Signed-off-by: Eric Nelson<eric.nelson@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. i > Note: this has nothing to do with this patch ;-). I will merge it into > the current release when you push V2. > I agree with all of your goals but have a more mundane set for U-Boot and i.MX6: -- HDMI support -- Better strategy for storing display setup. The implementation of a compiled-in list of supported displays doesn't scale. -- Hand-off of display setup to DT-enabled kernel (Sascha's drivers) -- Multiple displays -- Hand-off of display setup to older kernels My thought is to take things in more or less this order, although a couple of things can make the last one trivial to do in a boot script and it's a pain point for me. (My blog post on setting up bootargs doesn't seem to be doing the trick) My thinking is that: HDMI support can and should support EDID and flexible choice of resolution, and We'll need to store that choice somewhere, and The manner of display should be enough for the kernel to configure at least the screen resolution. Some of this really belongs in the boot loader where we're dealing with the board-specifics. It seems entirely appropriate for a board to tell the kernel that it wants: HDMI on IPU0/DI0 at 1920x1080 LVDS on IPU0/DI1 at 1024x768 using SPWG standard, and PRGB on IPU1/DI0 at 800x480 with inverted pixel clock and 18 bits of output Handing this off gracefully will help keep board-specific fixups out of the kernel and a lot of thrashing out of DT. Once we have this general display configuration and hand-off right, handing off a frame buffer address (or two or four) will likely be easier on the kernel side. I'm certainly over-simplifying, and the kernel and userspace will need more information, especially for multiple displays: who's on /dev/fb0? what bit depth is wanted? which of multiple touch screens is associated with which panel? which backlight is connected to which panel? Sorry for the long e-mail, but this gave me the a push to get some thoughts in writing. Regards, Eric
On Sun, Sep 23, 2012 at 07:27:41PM +0200, Stefano Babic wrote: > > > > > 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. The clock framework disables all unused clocks in a late_initcall. when the IPU is compiled as a module, the IPU clock will be one of those. Sascha
This series implements an HDMI detection command for i.MX6 boards
and configures mx6qsabrelite to use it as discussed in this
thread on the ML:
http://lists.denx.de/pipermail/u-boot/2012-September/135037.html
On 24/09/2012 01:02, Eric Nelson wrote: > This series implements an HDMI detection command for i.MX6 boards > and configures mx6qsabrelite to use it as discussed in this > thread on the ML: > http://lists.denx.de/pipermail/u-boot/2012-September/135037.html > > Applied to u-boot-imx, next branch, thanks. Best regards, Stefano Babic
diff --git a/drivers/video/mxc_ipuv3_fb.c b/drivers/video/mxc_ipuv3_fb.c index c38e22d..47b336e 100644 --- a/drivers/video/mxc_ipuv3_fb.c +++ b/drivers/video/mxc_ipuv3_fb.c @@ -38,6 +38,7 @@ #include "videomodes.h" #include "ipu.h" #include "mxcfb.h" +#include "ipu_regs.h" static int mxcfb_map_video_memory(struct fb_info *fbi); static int mxcfb_unmap_video_memory(struct fb_info *fbi); @@ -576,6 +577,25 @@ err0: return ret; } +void ipuv3_fb_shutdown(void) +{ + int i; + struct ipu_stat *stat = (struct ipu_stat *)IPU_STAT; + + for (i = 0; i < ARRAY_SIZE(mxcfb_info); i++) { + struct fb_info *fbi = mxcfb_info[i]; + if (fbi) { + struct mxcfb_info *mxc_fbi = fbi->par; + ipu_disable_channel(mxc_fbi->ipu_ch); + ipu_uninit_channel(mxc_fbi->ipu_ch); + } + } + for (i = 0; i < ARRAY_SIZE(stat->int_stat); i++) { + __raw_writel(__raw_readl(&stat->int_stat[i]), + &stat->int_stat[i]); + } +} + void *video_hw_init(void) { int ret; diff --git a/include/ipu_pixfmt.h b/include/ipu_pixfmt.h index 0019898..4baa711 100644 --- a/include/ipu_pixfmt.h +++ b/include/ipu_pixfmt.h @@ -77,5 +77,6 @@ #define IPU_PIX_FMT_YUV422P fourcc('4', '2', '2', 'P') /*< 16 YUV 4:2:2 */ int ipuv3_fb_init(struct fb_videomode *mode, uint8_t disp, uint32_t pixfmt); +void ipuv3_fb_shutdown(void); #endif
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com> --- drivers/video/mxc_ipuv3_fb.c | 20 ++++++++++++++++++++ include/ipu_pixfmt.h | 1 + 2 files changed, 21 insertions(+), 0 deletions(-)