Message ID | 1338888630-25930-3-git-send-email-s.hauer@pengutronix.de |
---|---|
State | New |
Headers | show |
Hi, Sascha Hauer writes: > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> > --- > arch/arm/mach-imx/mm-imx5.c | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/arch/arm/mach-imx/mm-imx5.c b/arch/arm/mach-imx/mm-imx5.c > index a4cb441..3b028ef 100644 > --- a/arch/arm/mach-imx/mm-imx5.c > +++ b/arch/arm/mach-imx/mm-imx5.c > @@ -214,6 +214,15 @@ static void __init imx51_ipu_mipi_setup(void) > hsc_addr + 0x800); > } > > +static void __init imx51_ipu_hardreset(void) > +{ > + u32 val; > + > + val = readl(MX51_IO_ADDRESS(MX51_SRC_BASE_ADDR)); > + val |= 1 << 3; > + writel(val, MX51_IO_ADDRESS(MX51_SRC_BASE_ADDR)); > +} > + > void __init imx51_soc_init(void) > { > /* i.mx51 has the i.mx31 type gpio */ > @@ -233,6 +242,16 @@ void __init imx51_soc_init(void) > platform_device_register_simple("imx31-audmux", 0, imx51_audmux_res, > ARRAY_SIZE(imx51_audmux_res)); > imx51_ipu_mipi_setup(); > + imx51_ipu_hardreset(); > +} > + > +static void __init imx53_ipu_hardreset(void) > +{ > + u32 val; > + > + val = readl(MX53_IO_ADDRESS(MX53_SRC_BASE_ADDR)); > + val |= 1 << 3; > + writel(val, MX53_IO_ADDRESS(MX53_SRC_BASE_ADDR)); > } > > void __init imx53_soc_init(void) > @@ -257,6 +276,7 @@ void __init imx53_soc_init(void) > /* i.mx53 has the i.mx31 type audmux */ > platform_device_register_simple("imx31-audmux", 0, imx53_audmux_res, > ARRAY_SIZE(imx53_audmux_res)); > + imx53_ipu_hardreset(); > } > > void __init imx51_init_late(void) > How would you implement a seamless transition from a boot logo to the application display when resetting the IPU during startup? Lothar Waßmann
On Tue, Jun 05, 2012 at 12:29:12PM +0200, Lothar Waßmann wrote: > Hi, > > Sascha Hauer writes: > > > How would you implement a seamless transition from a boot logo to the > application display when resetting the IPU during startup? I usually say to Robert: Make the bootloader fast enough so that nobody misses a splash from the bootloader. Robert is never happy with that answer... Is there any mainline compatible way to take over an initialized graphics core? Usually we do not want to depend on preinitialized hardware. With the graphics cores becoming more and more complex and given that the DRM/KMS stuff is more complex than the framebuffer stuff I'd first like to see a solution how this can be done in general before I care about the specific implementations. When this is in place we can easily remove the IPU reset (or only do it when we detect that the IPU is uninitialized) Sascha
On Tue, Jun 5, 2012 at 6:08 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > On Tue, Jun 05, 2012 at 12:29:12PM +0200, Lothar Waßmann wrote: >> Hi, >> >> Sascha Hauer writes: >> > >> How would you implement a seamless transition from a boot logo to the >> application display when resetting the IPU during startup? > > I usually say to Robert: Make the bootloader fast enough so that nobody > misses a splash from the bootloader. Robert is never happy with that > answer... > > Is there any mainline compatible way to take over an initialized > graphics core? No. There used to be an ATAG for finding the linear framebuffer and it's details but it got removed. This was from a long forgotten time when you could initialize a VGA graphics card and never care that it had an interrupt or not, since it never got used for your average, simple linear framebuffer operations. A device tree would be able to define (based on seeding that information from the bootloader) this too, and we have sample code of this working on a PPC system (Pegasos II) which would initialize a VGA graphics card using x86 emulation, set up the framebuffer using faked BIOS calls and put that information in the device tree for Linux to pick up using ofwfb. Lothar; The problem is on the IPU at least, having a running IDMAC channel kind of means breaking all kinds of good behavior in the transition between bootloader and kernel - usually you can assume that interrupts and caches are disabled, all DMA operations are halted/torn down, and strange effects happen obviously if this is not exactly true (on Pegasos II we had an old firmware which accidentally left USB running, and when Linux started.. all hell broke loose. At random.). It would also assume that the framebuffer memory was preserved, that the OS booting knew how to use that exact framebuffer format, So, unless your LCDC is extremely dumb, and your OS extremely smart, it can't be done. Robert and Lothar, you will have to live with it. What some people do is get clever inside the kernel, i.e. boot your kernel as fast as possible as you said and then use fancy features like precompiling the splash image into the kernel, then using DMA to fill the screen buffer with data so you have a working splash extremely early in boot - and while the kernel is probing devices after the bare minimum you architected, the DMA unit is putting your penguin on the screen. There's no reason to expect that display has to be configured after USB, for example, and you can make your "real" display driver hand-off much easier between initial kernel setup and real driver inside the kernel, than trying to handle it across the loader/kernel transitition. I saw an article on this (may have been published and peer reviewed, but also had a youtube video.. :) that did this exact thing, it was a response to all those "5 second boot" articles, on how to do it properly on embedded systems. I'll see if I can find it. There are plenty of things that you could do in the bootloader like using DMA for instance (why not use SDMA for relocation of the kernel if required?) in ways other than accelerating the disk accesses, and the same stuff can be done in the kernel to get to the "put a nice screen up" stage even faster.
On Mon, Aug 06, 2012 at 04:31:50PM -0500, Matt Sealey wrote: > There used to be an ATAG for finding the linear framebuffer and it's > details but it got removed. This > was from a long forgotten time when you could initialize a VGA > graphics card and never care that > it had an interrupt or not, since it never got used for your average, > simple linear framebuffer operations. No ATAG definitions have been removed from the kernel. The one you are referring to is: #define ATAG_VIDEOLFB 0x54410008 and the associated struct tag_videolfb, which is still in the kernel today. What isn't there is the implementation which reads this data, because only a few boards supported it, and they passed over some data from this to their FB drivers. So, when the boards were updated such that this became unnecessary, unsurprisingly the users disappeared (because they were all in platform code.) We have never had a generic "framebuffer" driver which has used this ATAG. Or if one was created, it never came anywhere near mainline. Either way, the situation is not as you describe above.
On Tue, Aug 7, 2012 at 12:04 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Aug 06, 2012 at 04:31:50PM -0500, Matt Sealey wrote: >> There used to be an ATAG for finding the linear framebuffer and it's >> details but it got removed. This >> was from a long forgotten time when you could initialize a VGA >> graphics card and never care that >> it had an interrupt or not, since it never got used for your average, >> simple linear framebuffer operations. > > No ATAG definitions have been removed from the kernel. The one you > are referring to is: > > #define ATAG_VIDEOLFB 0x54410008 > > and the associated struct tag_videolfb, which is still in the kernel > today. What isn't there is the implementation which reads this data, > because only a few boards supported it, and they passed over some data > from this to their FB drivers. > > So, when the boards were updated such that this became unnecessary, > unsurprisingly the users disappeared (because they were all in platform > code.) > > We have never had a generic "framebuffer" driver which has used this > ATAG. Or if one was created, it never came anywhere near mainline. > > Either way, the situation is not as you describe above. That's funny, I was absolutely certain the complete removal was done in the kernel, especially since it was patched out of U-Boot (commit 47ea6ed) a long, long time ago based on it being unsupported in the ATAG parser. I also saw a patch for OMAP which you nacked (violently :) long before that, because it was parsing ATAG_VIDEOLFB and passing it to it's display driver. Just found it again: http://www.spinics.net/lists/linux-omap/msg08287.html I must have just assumed that since the kernel doesn't pay attention to it, which caused it to be patched out of U-Boot since around June 2010, it would actually have completely gone away by now. Since no future boards use it (because you refuse to let them do it anymore, and also because the Device Tree is better anyway), no drivers use it anyway, wouldn't it be time to remove it completely, or is it there just for legacy's sake, a sepia-toned halcyon reminder of what we used to do to boot ARM boards? We are in 2012 though and the git history will always reflect the day it got removed. I think the only reason people haven't noticed it's still defined is because U-Boot doesn't pass it anymore and most of us are running U-Boots compiled much newer than June 2010. Who's really going to miss it?
diff --git a/arch/arm/mach-imx/mm-imx5.c b/arch/arm/mach-imx/mm-imx5.c index a4cb441..3b028ef 100644 --- a/arch/arm/mach-imx/mm-imx5.c +++ b/arch/arm/mach-imx/mm-imx5.c @@ -214,6 +214,15 @@ static void __init imx51_ipu_mipi_setup(void) hsc_addr + 0x800); } +static void __init imx51_ipu_hardreset(void) +{ + u32 val; + + val = readl(MX51_IO_ADDRESS(MX51_SRC_BASE_ADDR)); + val |= 1 << 3; + writel(val, MX51_IO_ADDRESS(MX51_SRC_BASE_ADDR)); +} + void __init imx51_soc_init(void) { /* i.mx51 has the i.mx31 type gpio */ @@ -233,6 +242,16 @@ void __init imx51_soc_init(void) platform_device_register_simple("imx31-audmux", 0, imx51_audmux_res, ARRAY_SIZE(imx51_audmux_res)); imx51_ipu_mipi_setup(); + imx51_ipu_hardreset(); +} + +static void __init imx53_ipu_hardreset(void) +{ + u32 val; + + val = readl(MX53_IO_ADDRESS(MX53_SRC_BASE_ADDR)); + val |= 1 << 3; + writel(val, MX53_IO_ADDRESS(MX53_SRC_BASE_ADDR)); } void __init imx53_soc_init(void) @@ -257,6 +276,7 @@ void __init imx53_soc_init(void) /* i.mx53 has the i.mx31 type audmux */ platform_device_register_simple("imx31-audmux", 0, imx53_audmux_res, ARRAY_SIZE(imx53_audmux_res)); + imx53_ipu_hardreset(); } void __init imx51_init_late(void)
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> --- arch/arm/mach-imx/mm-imx5.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)