i.MX IPU preparation patches

i.MX IPU preparation patches

[Sascha Hauer]

The following are two patches I have which reset the IPU and setup
the MIPI interface on i.MX51. They will be needed once we add graphics
support on i.MX5, but won't harm if we add them now.

----------------------------------------------------------------
Sascha Hauer (2):
      ARM i.MX51: setup mipi
      ARM i.MX5: Hard reset the IPU during startup

 arch/arm/mach-imx/mm-imx5.c |   41 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

[PATCH 1/2] ARM i.MX51: setup mipi

[Sascha Hauer]

The mipi unit has to be brought to a sane default state. This
unit is not present on i.MX53, so we add the setup here instead
of the ipu driver.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/mach-imx/mm-imx5.c |   21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/mach-imx/mm-imx5.c b/arch/arm/mach-imx/mm-imx5.c
index feeee17..a4cb441 100644
--- a/arch/arm/mach-imx/mm-imx5.c
+++ b/arch/arm/mach-imx/mm-imx5.c
@@ -194,6 +194,26 @@ void __init imx50_soc_init(void)
 					ARRAY_SIZE(imx50_audmux_res));
 }
 
+/*
+ * The MIPI HSC unit has been removed from the i.MX51 Reference Manual by
+ * the Freescale marketing division. However this did not remove the
+ * hardware from the chip which still needs to be configured for proper
+ * IPU support.
+ */
+static void __init imx51_ipu_mipi_setup(void)
+{
+	void __iomem *hsc_addr;
+
+	hsc_addr = MX51_IO_ADDRESS(MX51_MIPI_HSC_BASE_ADDR);
+
+	/* setup MIPI module to legacy mode */
+	__raw_writel(0xf00, hsc_addr);
+
+	/* CSI mode: reserved; DI control mode: legacy (from Freescale BSP) */
+	__raw_writel(__raw_readl(hsc_addr + 0x800) | 0x30ff,
+		hsc_addr + 0x800);
+}
+
 void __init imx51_soc_init(void)
 {
 	/* i.mx51 has the i.mx31 type gpio */
@@ -212,6 +232,7 @@ void __init imx51_soc_init(void)
 	/* i.mx51 has the i.mx31 type audmux */
 	platform_device_register_simple("imx31-audmux", 0, imx51_audmux_res,
 					ARRAY_SIZE(imx51_audmux_res));
+	imx51_ipu_mipi_setup();
 }
 
 void __init imx53_soc_init(void)
-- 
1.7.10

[PATCH 1/2] ARM i.MX51: setup mipi

[Shawn Guo]

Hi Sascha,

On Tue, Jun 05, 2012 at 11:30:29AM +0200, Sascha Hauer wrote:
> The mipi unit has to be brought to a sane default state. This
> unit is not present on i.MX53, so we add the setup here instead
> of the ipu driver.
> 
Can't we do some detection in IPU driver to have the setup done in
IPU driver?  To me, this (as well as the reset in patch #2) is not
really the material for soc specific initialization.  If I'm running
a system without IPU driver enabled, why do I have to go through these
setup at all?

Regards,
Shawn

> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>  arch/arm/mach-imx/mm-imx5.c |   21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/mm-imx5.c b/arch/arm/mach-imx/mm-imx5.c
> index feeee17..a4cb441 100644
> --- a/arch/arm/mach-imx/mm-imx5.c
> +++ b/arch/arm/mach-imx/mm-imx5.c
> @@ -194,6 +194,26 @@ void __init imx50_soc_init(void)
>  					ARRAY_SIZE(imx50_audmux_res));
>  }
>  
> +/*
> + * The MIPI HSC unit has been removed from the i.MX51 Reference Manual by
> + * the Freescale marketing division. However this did not remove the
> + * hardware from the chip which still needs to be configured for proper
> + * IPU support.
> + */
> +static void __init imx51_ipu_mipi_setup(void)
> +{
> +	void __iomem *hsc_addr;
> +
> +	hsc_addr = MX51_IO_ADDRESS(MX51_MIPI_HSC_BASE_ADDR);
> +
> +	/* setup MIPI module to legacy mode */
> +	__raw_writel(0xf00, hsc_addr);
> +
> +	/* CSI mode: reserved; DI control mode: legacy (from Freescale BSP) */
> +	__raw_writel(__raw_readl(hsc_addr + 0x800) | 0x30ff,
> +		hsc_addr + 0x800);
> +}
> +
>  void __init imx51_soc_init(void)
>  {
>  	/* i.mx51 has the i.mx31 type gpio */
> @@ -212,6 +232,7 @@ void __init imx51_soc_init(void)
>  	/* i.mx51 has the i.mx31 type audmux */
>  	platform_device_register_simple("imx31-audmux", 0, imx51_audmux_res,
>  					ARRAY_SIZE(imx51_audmux_res));
> +	imx51_ipu_mipi_setup();
>  }
>  
>  void __init imx53_soc_init(void)
> -- 
> 1.7.10
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/2] ARM i.MX51: setup mipi

[David Jander]

On Thu, 7 Jun 2012 10:59:51 +0800
Shawn Guo <shawn.guo@linaro.org> wrote:

> Hi Sascha,
> 
> On Tue, Jun 05, 2012 at 11:30:29AM +0200, Sascha Hauer wrote:
> > The mipi unit has to be brought to a sane default state. This
> > unit is not present on i.MX53, so we add the setup here instead
> > of the ipu driver.
> > 
> Can't we do some detection in IPU driver to have the setup done in
> IPU driver?  To me, this (as well as the reset in patch #2) is not
> really the material for soc specific initialization.  If I'm running
> a system without IPU driver enabled, why do I have to go through these
> setup at all?

I would consider it part of SoC setup for the simple reason, that this
peripheral officially does not even exist (although it is physically there in
the chip and unfortunately _needs_ to be initialized). There is no
documentation of it anywhere (besides old, obsolete and unreleased manuals).
If one wanted to implement an IPU driver later on, there would be no way of
knowing that this part must be done first. We should take the chance that
someone happens to have this "knowledge" and do this (further harmless)
initialization in SoC setup, so that it is dealt with and won't get in the way
later. There is no worse driver developer nightmare than incomplete
documentation causing your otherwise correct driver to just not work.
OTOH, if this was an officially supported peripheral, it should have it's own
driver and not be part of the IPU driver either.

Best regards,

-- 
David Jander
Protonic Holland.

[PATCH 1/2] ARM i.MX51: setup mipi

[Shawn Guo]

On 7 June 2012 14:13, David Jander <david.jander@protonic.nl> wrote:
> I would consider it part of SoC setup for the simple reason, that this
> peripheral officially does not even exist (although it is physically there in
> the chip and unfortunately _needs_ to be initialized). There is no
> documentation of it anywhere (besides old, obsolete and unreleased manuals).
> If one wanted to implement an IPU driver later on, there would be no way of
> knowing that this part must be done first. We should take the chance that
> someone happens to have this "knowledge" and do this (further harmless)
> initialization in SoC setup, so that it is dealt with and won't get in the way
> later. There is no worse driver developer nightmare than incomplete
> documentation causing your otherwise correct driver to just not work.
> OTOH, if this was an officially supported peripheral, it should have it's own
> driver and not be part of the IPU driver either.
>
That does not necessarily mean imx51_soc_init() is the right place for
that initialization, simply because not every single boot of imx51
needs that initialization.

I can probably accept the mipi initialization changes if you are saying
imx51_soc_init is not the right place for it either, but at the moment
there is no better place than imx51_soc_init().

But why can't we do ipu reset (the second patch) in ipu driver then?

Regards,
Shawn

[PATCH 1/2] ARM i.MX51: setup mipi

[David Jander]

On Thu, 7 Jun 2012 15:10:05 +0800
Shawn Guo <shawn.guo@linaro.org> wrote:

> On 7 June 2012 14:13, David Jander <david.jander@protonic.nl> wrote:
> > I would consider it part of SoC setup for the simple reason, that this
> > peripheral officially does not even exist (although it is physically there in
> > the chip and unfortunately _needs_ to be initialized). There is no
> > documentation of it anywhere (besides old, obsolete and unreleased manuals).
> > If one wanted to implement an IPU driver later on, there would be no way of
> > knowing that this part must be done first. We should take the chance that
> > someone happens to have this "knowledge" and do this (further harmless)
> > initialization in SoC setup, so that it is dealt with and won't get in the way
> > later. There is no worse driver developer nightmare than incomplete
> > documentation causing your otherwise correct driver to just not work.
> > OTOH, if this was an officially supported peripheral, it should have it's own
> > driver and not be part of the IPU driver either.
> >
> That does not necessarily mean imx51_soc_init() is the right place for
> that initialization, simply because not every single boot of imx51
> needs that initialization.

I agree, but I couldn't come up with a better place.

> I can probably accept the mipi initialization changes if you are saying
> imx51_soc_init is not the right place for it either, but at the moment
> there is no better place than imx51_soc_init().

Sounds good. Yes, can we agree on that?

> But why can't we do ipu reset (the second patch) in ipu driver then?

No idea... I don't want to preempt Sascha here.
Just my guess: The system reset controller could potentially be used by other
peripherals, and in that case it would need to be a separate driver with
locking for register access. Doing it here seems a safe way of avoiding
concurrent access to the register of the SRC?
Same reason as above?

Best regards,

-- 
David Jander
Protonic Holland.

[PATCH 1/2] ARM i.MX51: setup mipi

[Sascha Hauer]

On Thu, Jun 07, 2012 at 03:10:05PM +0800, Shawn Guo wrote:
> On 7 June 2012 14:13, David Jander <david.jander@protonic.nl> wrote:
> > I would consider it part of SoC setup for the simple reason, that this
> > peripheral officially does not even exist (although it is physically there in
> > the chip and unfortunately _needs_ to be initialized). There is no
> > documentation of it anywhere (besides old, obsolete and unreleased manuals).
> > If one wanted to implement an IPU driver later on, there would be no way of
> > knowing that this part must be done first. We should take the chance that
> > someone happens to have this "knowledge" and do this (further harmless)
> > initialization in SoC setup, so that it is dealt with and won't get in the way
> > later. There is no worse driver developer nightmare than incomplete
> > documentation causing your otherwise correct driver to just not work.
> > OTOH, if this was an officially supported peripheral, it should have it's own
> > driver and not be part of the IPU driver either.
> >
> That does not necessarily mean imx51_soc_init() is the right place for
> that initialization, simply because not every single boot of imx51
> needs that initialization.

Since it doesn't really add to the boot time I think it won't be a
problem.

> 
> I can probably accept the mipi initialization changes if you are saying
> imx51_soc_init is not the right place for it either, but at the moment
> there is no better place than imx51_soc_init().
> 
> But why can't we do ipu reset (the second patch) in ipu driver then?

Ok, we might have to come up with something better. I originally had the
IPU reset in the IPU driver (copied from the FSL BSP). There are two
problems with this:

- The IPU reset is external to the IPU which means that we have to
  distinguish between SoCs.
- The IPU reset takes quite a long time (about 300ms). Doing this in
  the IPU driver means that the kernel boot delays for this time. Doing
  this in early init means that the 300ms can be spent bringing the rest
  of the system up.

As said, there are more clean ways to do this without having the two
mentioned problems, I'm just not sure whether it's worth it to put
significant amount of work into this.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 1/2] ARM i.MX51: setup mipi

[Shawn Guo]

On Thu, Jun 07, 2012 at 10:43:36AM +0200, Sascha Hauer wrote:
> On Thu, Jun 07, 2012 at 03:10:05PM +0800, Shawn Guo wrote:
> > But why can't we do ipu reset (the second patch) in ipu driver then?
> 
> Ok, we might have to come up with something better. I originally had the
> IPU reset in the IPU driver (copied from the FSL BSP). There are two
> problems with this:
> 
> - The IPU reset is external to the IPU which means that we have to
>   distinguish between SoCs.
> - The IPU reset takes quite a long time (about 300ms). Doing this in
>   the IPU driver means that the kernel boot delays for this time. Doing
>   this in early init means that the 300ms can be spent bringing the rest
>   of the system up.
> 
> As said, there are more clean ways to do this without having the two
> mentioned problems, I'm just not sure whether it's worth it to put
> significant amount of work into this.
> 
IMO, it's worth the effort.  Otherwise, we will end up with having
such reset functions for IPU, VPU and GPU (maybe more on later SoC)
over individual SoC initialization functions.  Well, VPU and GPU may
be less concerned by the mainline tree, but from FSL perspective, we
have to care about them.

Also, how will you support that for imx6q, considering we already have
src.c created as a little "driver" for imx6q System Reset Controller
(SRC)?  I feel like that we should extend this little "driver" to
support what you need for IPU reset here.

-- 
Regards,
Shawn

[PATCH 1/2] ARM i.MX51: setup mipi

[Sascha Hauer]

On Thu, Jun 07, 2012 at 09:37:35PM +0800, Shawn Guo wrote:
> On Thu, Jun 07, 2012 at 10:43:36AM +0200, Sascha Hauer wrote:
> > On Thu, Jun 07, 2012 at 03:10:05PM +0800, Shawn Guo wrote:
> > > But why can't we do ipu reset (the second patch) in ipu driver then?
> > 
> > Ok, we might have to come up with something better. I originally had the
> > IPU reset in the IPU driver (copied from the FSL BSP). There are two
> > problems with this:
> > 
> > - The IPU reset is external to the IPU which means that we have to
> >   distinguish between SoCs.
> > - The IPU reset takes quite a long time (about 300ms). Doing this in
> >   the IPU driver means that the kernel boot delays for this time. Doing
> >   this in early init means that the 300ms can be spent bringing the rest
> >   of the system up.
> > 
> > As said, there are more clean ways to do this without having the two
> > mentioned problems, I'm just not sure whether it's worth it to put
> > significant amount of work into this.
> > 
> IMO, it's worth the effort.  Otherwise, we will end up with having
> such reset functions for IPU, VPU and GPU (maybe more on later SoC)
> over individual SoC initialization functions.  Well, VPU and GPU may
> be less concerned by the mainline tree, but from FSL perspective, we
> have to care about them.
> 
> Also, how will you support that for imx6q, considering we already have
> src.c created as a little "driver" for imx6q System Reset Controller
> (SRC)?  I feel like that we should extend this little "driver" to
> support what you need for IPU reset here.

Do you have an idea what kind of API such a reset unit should export?
Are you thinking about some kind of reset_me(struct device *dev) or
what else?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 1/2] ARM i.MX51: setup mipi

[Shawn Guo]

On Sat, Jun 09, 2012 at 01:32:20PM +0200, Sascha Hauer wrote:
> Do you have an idea what kind of API such a reset unit should export?
> Are you thinking about some kind of reset_me(struct device *dev) or
> what else?
> 
Yeah, that works for me.  We can have sub-nodes under SRC node in device
tree representing reset register and bit for those peripherals, and have
a phandle like "fsl,reset-handler" under peripheral nodes pointing to
the sub-nodes.

-- 
Regards,
Shawn

[PATCH 2/2] ARM i.MX5: Hard reset the IPU during startup

[Sascha Hauer]

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

[PATCH 2/2] ARM i.MX5: Hard reset the IPU during startup

[Lothar Waßmann]

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

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________

[PATCH 2/2] ARM i.MX5: Hard reset the IPU during startup

[Sascha Hauer]

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

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 2/2] ARM i.MX5: Hard reset the IPU during startup

[Matt Sealey]

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.

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.

[PATCH 2/2] ARM i.MX5: Hard reset the IPU during startup

[Russell King - ARM Linux]

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.

[PATCH 2/2] ARM i.MX5: Hard reset the IPU during startup

[Matt Sealey]

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?

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.