Re: [U-Boot] [PATCH] video: add cfb console driver for sunxi

2014-08-07 Thread Hans de Goede 
Hi,

On 08/06/2014 01:40 PM, Luc Verhaegen wrote:
 On Tue, Aug 05, 2014 at 01:56:36PM +0200, Hans de Goede wrote:
 Hi,

 On 08/02/2014 06:14 PM, Luc Verhaegen wrote:
 This adds a fixed mode hdmi driver (lcd to be added in future) for the
 sunxi platform. Current config is such that 8MB is shaved off at the top
 of the RAM. Simplefb support is available for kernels that know how to
 use it.

 I've been trying to follow all the discussion in this thread, and here
 is what I think we should do:

 1) There has been some discussion about using this console-driver
 in u-boot without generating the simplefb dt node. This means yet another
 variation in how all the bits fit together, so I don't think we should do
 this. Note I realize that the original patch did not have a specific
 config option for this, but it was mentioned later in the thread.
 TL;DR: Enabling the console driver will always generate the simplefb dt
 node.
 
 When we do not claim clocks, we luckily cleanly disable hw, in our case.
 
 2) I think we can worry about what to do with the reserved memory\when not 
 using simplefb
 (or when switching from simplefb to kms) later. For now lets focus on the
 issue with the clocks.
 
 Yes, this was the plan all along.
 
 3) To me the issue with clocks seems simple, we should modify the
 devicetree binding for simplefb to support a clocks property, and modify
 the simplefb kernel code to get + prep_and_enable any clocks specified
 in the dt node.
 
 For me, an important part of this discussion was seemingly flawed way in 
 which clocks are defined. I was of course not going to completely 
 overturn the thinking here, but i had expected that people would've at 
 least agreed that something was obviously awry, as there are several 
 obvious indicators there.

I think the way clocks are defined is fine, it works fine for all
the other parts of the SoC we've added support for so far. I guess
it may take some getting used too.

Anyways I don't think having an extended discussion about how clocks
are defined is useful, this is simply something which we are not
going to change, so better get used to it.

 
 This means parsing enough of the dt to find the clocks to be able to
 specify phandles to them in the added node. I don't know how hard it will
 be to do this in u-boot, but IMHO it is simply the right thing to do, so
 this is how it should be done.
 
 No, you do not need to add nodes. This was never the case. ahb_gates 
 is never used like that.
 
 It is either used as ahb_gates bit from the dt, or ahb_bitname 
 from kernel code which directly references clocks, with the 
 ahb_bitnames listed as part of ahb_gates in the clock-output-names 
 property. This lack of symmetry is one very clear sign.

That is how the gates are modeled yes, but we don't want to insert
direct refences to the gates into the generated simple-framebuffer
devicetree node. Instead what should be done is add module clock
nodes to the devicetree (in the dts file, not on the fly in u-boot),
and then the uboot code should search for those (this is what I meant
with parse the dtb) and then insert phandles to these into the
generated simpe-framebuffer node.

Note we will need multiple module-clocks node, one for lcd0 ch0 one for lcd0
ch1, etc. See for example the mmc0_clk node, and the usage of it in the mmc0
node. I think we don't need a module clock node for the hdmi encoder,
as it seems the module clock register for it at address 1c20150 does not do
anything, instead it seems the hdmi encoder is hooked up
directly to pll 3 / 7 and has its own clock selection mechanism through
one of the hdmi encoder registers. At least this is the conclusion I
came to when working on dvi support, etc. in the sunxi-3.4 kernels.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] video: add cfb console driver for sunxi

2014-08-06 Thread Luc Verhaegen 
On Tue, Aug 05, 2014 at 01:56:36PM +0200, Hans de Goede wrote:
 Hi,
 
 On 08/02/2014 06:14 PM, Luc Verhaegen wrote:
  This adds a fixed mode hdmi driver (lcd to be added in future) for the
  sunxi platform. Current config is such that 8MB is shaved off at the top
  of the RAM. Simplefb support is available for kernels that know how to
  use it.
 
 I've been trying to follow all the discussion in this thread, and here
 is what I think we should do:
 
 1) There has been some discussion about using this console-driver
 in u-boot without generating the simplefb dt node. This means yet another
 variation in how all the bits fit together, so I don't think we should do
 this. Note I realize that the original patch did not have a specific
 config option for this, but it was mentioned later in the thread.
 TL;DR: Enabling the console driver will always generate the simplefb dt
 node.

When we do not claim clocks, we luckily cleanly disable hw, in our case.

 2) I think we can worry about what to do with the reserved memory\when not 
 using simplefb
 (or when switching from simplefb to kms) later. For now lets focus on the
 issue with the clocks.

Yes, this was the plan all along.

 3) To me the issue with clocks seems simple, we should modify the
 devicetree binding for simplefb to support a clocks property, and modify
 the simplefb kernel code to get + prep_and_enable any clocks specified
 in the dt node.

For me, an important part of this discussion was seemingly flawed way in 
which clocks are defined. I was of course not going to completely 
overturn the thinking here, but i had expected that people would've at 
least agreed that something was obviously awry, as there are several 
obvious indicators there.

 This means parsing enough of the dt to find the clocks to be able to
 specify phandles to them in the added node. I don't know how hard it will
 be to do this in u-boot, but IMHO it is simply the right thing to do, so
 this is how it should be done.

No, you do not need to add nodes. This was never the case. ahb_gates 
is never used like that.

It is either used as ahb_gates bit from the dt, or ahb_bitname 
from kernel code which directly references clocks, with the 
ahb_bitnames listed as part of ahb_gates in the clock-output-names 
property. This lack of symmetry is one very clear sign.

The fact that only the kernel knows how to map the clock-output-names 
list, which is only defined in the dts, to bits only defined in the clk 
driver code in the kernel, that's another very clear sign.

 If others agree that specifying the clocks in the simplefb dt node is
 the right way to ensure that the clocks don't get enabled I'm willing
 at taking a shot on coding this.

I have been on it since last friday, when i started seeing the issues 
here, but haven't done much code til now, and am only uncovering many 
more inconsistencies.

For instance, in the linux kernel, 
Documentation/devicetree/bindings/clock/clock-bindings.txt only adds to 
the confusion.

Now trying to find a working solution from the kernel side, as i already 
manually inserted 6 u32s: {phandle, bit, phandle, bit, phandle, bit}.
Wait and see how that pans out, but i know that this will not provide a 
proper or lasting solution, as the pairs of cells needed now will at one 
point need to be mixed with directly referenced clocks (pll3/pll7, which 
are currently not defined in dts yet).

Luc Verhaegen.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] video: add cfb console driver for sunxi

2014-08-05 Thread Hans de Goede 
Hi,

On 08/02/2014 06:14 PM, Luc Verhaegen wrote:
 This adds a fixed mode hdmi driver (lcd to be added in future) for the
 sunxi platform. Current config is such that 8MB is shaved off at the top
 of the RAM. Simplefb support is available for kernels that know how to
 use it.

I've been trying to follow all the discussion in this thread, and here
is what I think we should do:

1) There has been some discussion about using this console-driver
in u-boot without generating the simplefb dt node. This means yet another
variation in how all the bits fit together, so I don't think we should do
this. Note I realize that the original patch did not have a specific
config option for this, but it was mentioned later in the thread.
TL;DR: Enabling the console driver will always generate the simplefb dt
node.

2) I think we can worry about what to do with the reserved memory\when not 
using simplefb
(or when switching from simplefb to kms) later. For now lets focus on the
issue with the clocks.

3) To me the issue with clocks seems simple, we should modify the
devicetree binding for simplefb to support a clocks property, and modify
the simplefb kernel code to get + prep_and_enable any clocks specified
in the dt node.

This means parsing enough of the dt to find the clocks to be able to
specify phandles to them in the added node. I don't know how hard it will
be to do this in u-boot, but IMHO it is simply the right thing to do, so
this is how it should be done.

If others agree that specifying the clocks in the simplefb dt node is
the right way to ensure that the clocks don't get enabled I'm willing
at taking a shot on coding this.

Regards,

Hans



 
 Signed-off-by: Luc Verhaegen l...@skynet.be
 ---
  arch/arm/include/asm/arch-sunxi/sunxi_display.h |   21 +
  board/sunxi/board.c |   14 +
  drivers/video/Makefile  |1 +
  drivers/video/sunxi_display.c   |  639 
 +++
  include/configs/sunxi-common.h  |   34 ++
  5 files changed, 709 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/include/asm/arch-sunxi/sunxi_display.h
  create mode 100644 drivers/video/sunxi_display.c
 
 diff --git a/arch/arm/include/asm/arch-sunxi/sunxi_display.h 
 b/arch/arm/include/asm/arch-sunxi/sunxi_display.h
 new file mode 100644
 index 000..4456778
 --- /dev/null
 +++ b/arch/arm/include/asm/arch-sunxi/sunxi_display.h
 @@ -0,0 +1,21 @@
 +/*
 + * (C) Copyright 2014 Luc Verhaegen l...@skynet.be
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License as
 + * published by the Free Software Foundation's version 2 and any
 + * later version the License.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +#ifndef _SUNXI_DISPLAY_H_
 +#define _SUNXI_DISPLAY_H_
 +
 +#ifdef CONFIG_VIDEO_DT_SIMPLEFB
 +void sunxi_simplefb_setup(void *blob);
 +#endif
 +
 +#endif /* _SUNXI_DISPLAY_H_ */
 diff --git a/board/sunxi/board.c b/board/sunxi/board.c
 index 2179e23..e819b12 100644
 --- a/board/sunxi/board.c
 +++ b/board/sunxi/board.c
 @@ -26,6 +26,10 @@
  #include asm/io.h
  #include net.h
  
 +#ifdef CONFIG_VIDEO
 +#include asm/arch-sunxi/sunxi_display.h
 +#endif
 +
  DECLARE_GLOBAL_DATA_PTR;
  
  /* add board specific code here */
 @@ -185,3 +189,13 @@ int misc_init_r(void)
   return 0;
  }
  #endif
 +
 +#ifdef CONFIG_OF_BOARD_SETUP
 +void
 +ft_board_setup(void *blob, bd_t *bd)
 +{
 +#ifdef CONFIG_VIDEO_DT_SIMPLEFB
 + sunxi_simplefb_setup(blob);
 +#endif
 +}
 +#endif /* CONFIG_OF_BOARD_SETUP */
 diff --git a/drivers/video/Makefile b/drivers/video/Makefile
 index 945f35d..9a25c84 100644
 --- a/drivers/video/Makefile
 +++ b/drivers/video/Makefile
 @@ -38,6 +38,7 @@ obj-$(CONFIG_VIDEO_SANDBOX_SDL) += sandbox_sdl.o
  obj-$(CONFIG_VIDEO_SED13806) += sed13806.o
  obj-$(CONFIG_VIDEO_SM501) += sm501.o
  obj-$(CONFIG_VIDEO_SMI_LYNXEM) += smiLynxEM.o videomodes.o
 +obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o
  obj-$(CONFIG_VIDEO_TEGRA) += tegra.o
  obj-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o
  obj-$(CONFIG_FORMIKE) += formike.o
 diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
 new file mode 100644
 index 000..251fb67
 --- /dev/null
 +++ b/drivers/video/sunxi_display.c
 @@ -0,0 +1,639 @@
 +/*
 + * (C) Copyright 2013-2014 Luc Verhaegen l...@skynet.be
 + *
 + * Display driver for Allwinner SoCs.
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License as
 + * published by the Free Software Foundation's version 2 and any
 + * later version the License.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY;

Re: [U-Boot] [PATCH] video: add cfb console driver for sunxi

2014-08-04 Thread Hans de Goede 
Hi Luc,

On 08/02/2014 06:14 PM, Luc Verhaegen wrote:
 This adds a fixed mode hdmi driver (lcd to be added in future) for the
 sunxi platform. Current config is such that 8MB is shaved off at the top
 of the RAM. Simplefb support is available for kernels that know how to
 use it.
 
 Signed-off-by: Luc Verhaegen l...@skynet.be

First of all many thanks for your work on this.

ATM I don't have time to do a full review, but I don't expect there
to be too many suprises when I do find the time.

Really my only concern is the handover of the reserved memory, etc. to
the kernel. We need to get a plan in place for that *before* this can
be merged. Note I don't want to raise any artificial barriers here,
I would love to see this merged ASAP. But I don't want to paint us
in a corner where u-boot having hdmi console support makes it harder
to get kms support in the kernel going. I think we can both agree on that.

So I really want to see some plan how this will work in place before merging.
Note just a plan, I don't expect kernel patches ready to be merged for this,
just a good idea / sketch of how all the bits will fit together.

In one of the threads about this there was some discussion about doing a
flicker free handover. I agree with you that given that we will be fixed
to 1024x768 in u-boot this won't be realistic. But in the light of that
it would be nice if we could make it so that if none of the stdout and stderr
variables point to vga we don't init the hdmi at all, this will avoid
what ever is attached to first have to sync at 1024x768 and then at its
native resolution when the kernel takes over, and this will also allow
for an easy way to not steal the 8MB of memory for people who care about
that (think headless server which is low on memory)

Regards,

Hans



 ---
  arch/arm/include/asm/arch-sunxi/sunxi_display.h |   21 +
  board/sunxi/board.c |   14 +
  drivers/video/Makefile  |1 +
  drivers/video/sunxi_display.c   |  639 
 +++
  include/configs/sunxi-common.h  |   34 ++
  5 files changed, 709 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/include/asm/arch-sunxi/sunxi_display.h
  create mode 100644 drivers/video/sunxi_display.c
 
 diff --git a/arch/arm/include/asm/arch-sunxi/sunxi_display.h 
 b/arch/arm/include/asm/arch-sunxi/sunxi_display.h
 new file mode 100644
 index 000..4456778
 --- /dev/null
 +++ b/arch/arm/include/asm/arch-sunxi/sunxi_display.h
 @@ -0,0 +1,21 @@
 +/*
 + * (C) Copyright 2014 Luc Verhaegen l...@skynet.be
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License as
 + * published by the Free Software Foundation's version 2 and any
 + * later version the License.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +#ifndef _SUNXI_DISPLAY_H_
 +#define _SUNXI_DISPLAY_H_
 +
 +#ifdef CONFIG_VIDEO_DT_SIMPLEFB
 +void sunxi_simplefb_setup(void *blob);
 +#endif
 +
 +#endif /* _SUNXI_DISPLAY_H_ */
 diff --git a/board/sunxi/board.c b/board/sunxi/board.c
 index 2179e23..e819b12 100644
 --- a/board/sunxi/board.c
 +++ b/board/sunxi/board.c
 @@ -26,6 +26,10 @@
  #include asm/io.h
  #include net.h
  
 +#ifdef CONFIG_VIDEO
 +#include asm/arch-sunxi/sunxi_display.h
 +#endif
 +
  DECLARE_GLOBAL_DATA_PTR;
  
  /* add board specific code here */
 @@ -185,3 +189,13 @@ int misc_init_r(void)
   return 0;
  }
  #endif
 +
 +#ifdef CONFIG_OF_BOARD_SETUP
 +void
 +ft_board_setup(void *blob, bd_t *bd)
 +{
 +#ifdef CONFIG_VIDEO_DT_SIMPLEFB
 + sunxi_simplefb_setup(blob);
 +#endif
 +}
 +#endif /* CONFIG_OF_BOARD_SETUP */
 diff --git a/drivers/video/Makefile b/drivers/video/Makefile
 index 945f35d..9a25c84 100644
 --- a/drivers/video/Makefile
 +++ b/drivers/video/Makefile
 @@ -38,6 +38,7 @@ obj-$(CONFIG_VIDEO_SANDBOX_SDL) += sandbox_sdl.o
  obj-$(CONFIG_VIDEO_SED13806) += sed13806.o
  obj-$(CONFIG_VIDEO_SM501) += sm501.o
  obj-$(CONFIG_VIDEO_SMI_LYNXEM) += smiLynxEM.o videomodes.o
 +obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o
  obj-$(CONFIG_VIDEO_TEGRA) += tegra.o
  obj-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o
  obj-$(CONFIG_FORMIKE) += formike.o
 diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
 new file mode 100644
 index 000..251fb67
 --- /dev/null
 +++ b/drivers/video/sunxi_display.c
 @@ -0,0 +1,639 @@
 +/*
 + * (C) Copyright 2013-2014 Luc Verhaegen l...@skynet.be
 + *
 + * Display driver for Allwinner SoCs.
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License as
 + * published by the Free Software Foundation's version 2 and any
 + * later version the License.
 + *
 + * This program is

Re: [U-Boot] [PATCH] video: add cfb console driver for sunxi

2014-08-04 Thread Luc Verhaegen 
On Mon, Aug 04, 2014 at 10:39:13AM +0200, Hans de Goede wrote:
 Hi Luc,
 
 First of all many thanks for your work on this.
 
 ATM I don't have time to do a full review, but I don't expect there
 to be too many suprises when I do find the time.
 
 Really my only concern is the handover of the reserved memory, etc. to
 the kernel. We need to get a plan in place for that *before* this can
 be merged. Note I don't want to raise any artificial barriers here,
 I would love to see this merged ASAP. But I don't want to paint us
 in a corner where u-boot having hdmi console support makes it harder
 to get kms support in the kernel going. I think we can both agree on that.

 So I really want to see some plan how this will work in place before merging.
 Note just a plan, I don't expect kernel patches ready to be merged for this,
 just a good idea / sketch of how all the bits will fit together.

Memory is not the biggest worry.

Some kernel code needs to claim clocks if the mode is to cleanly survive 
the start of the kernel. If not, there is no coming back until a proper 
display driver runs. If the simplefb driver claims these clocks, then 
the simplefb driver also must release these clocks, and this driver 
should then never be started again, so it should set the simplefb dt 
node status to disabled.

But that's not the full extent of this story. If we have a kms driver, 
then we need to claim these clocks, and set a proper mode on the hw. So 
the simplefb driver claiming these resources must've properly unclaimed 
them by then, _and_ have set the dt node to disabled. This kills your 
flicker-free right here unless there is a clean way for the kms driver 
to reclaim the clocks before the simplefb driver unclaims them.

But... What do we do when u-boot sets up cfb, without setting up a
simplefb node in the dt. Or what do we do when a simplefb node is set 
up, but no simplefb code is included in the kernel? Well, we then either 
need to claim the clocks, and make sure that nothing else touches the 
memory, or we need to cleanly disable the display engine. But which do 
we choose, do we keep the u-boot output forever, or do we sync off when 
the kernel starts?

Suddenly, simplefb doesn't look as simple anymore. It's turned into 
quite the mess. Life is easy when you are called rpi, and you sweep 
everything under the videocore rug, and do everything behind the lesser 
cores back. But if you want to solve this properly, then you end up 
smearing bits of simplefb driver code all over the kernel tree.

As for memory, that's closely tied into the clock code, as whatever code
claims or disables the clocks for the display engine, that's also where 
the dt node gets set to disabled, and thus also where the memory either 
is added to some cma area directly, released from (upcoming) reserved 
memory, or forgotten. Simplefb at least gives us a nice handle on the 
location and size of the memory, so we can always find a workable 
solution.

So i don't think the memory issue is as important. We already give the
kernel a nice handle on that. How the kernel wishes to handle it in 
detail is then pretty much up to the kernel, and i expect the kernels 
behaviour to change when kms comes out and i have to think about dealing 
with simplefb.

Clocks are quite a bit more crucial in this context. How the memory 
is handled needs to follow how the clocks are handled.

 In one of the threads about this there was some discussion about doing a
 flicker free handover. I agree with you that given that we will be fixed
 to 1024x768 in u-boot this won't be realistic. But in the light of that
 it would be nice if we could make it so that if none of the stdout and stderr
 variables point to vga we don't init the hdmi at all, this will avoid
 what ever is attached to first have to sync at 1024x768 and then at its
 native resolution when the kernel takes over, and this will also allow
 for an easy way to not steal the 8MB of memory for people who care about
 that (think headless server which is low on memory)

That's not how u-boot or the console code works.

First off, this stdout/stderr variable setting, that's all handled after 
the driver has been loaded and an (extra) console device is created. The 
cfb console driver is created because of a build time config, but it is 
allowed to fail (in our case, because HPD says nothing is attached).

Iirc, without iomux, the last created console driver is the one that 
gets stdout, stderr and stdin, so you lose the UART console. With iomux, 
you always need to load env for anything but the uart console to work. 
This means that you can have both cfb and uart working side by side, but 
you do not get anything on cfb unless the env is set as such.

For a future spin of this patch, the logic around enabling this code 
will be swapped around. People will have to manually add VIDEO to their 
board config. There's just to many hairy cornercases and tough to answer 
what ifs here, when you actually start

[U-Boot] [PATCH] video: add cfb console driver for sunxi

2014-08-02 Thread Luc Verhaegen 
This adds a fixed mode hdmi driver (lcd to be added in future) for the
sunxi platform. Current config is such that 8MB is shaved off at the top
of the RAM. Simplefb support is available for kernels that know how to
use it.

Signed-off-by: Luc Verhaegen l...@skynet.be
---
 arch/arm/include/asm/arch-sunxi/sunxi_display.h |   21 +
 board/sunxi/board.c |   14 +
 drivers/video/Makefile  |1 +
 drivers/video/sunxi_display.c   |  639 +++
 include/configs/sunxi-common.h  |   34 ++
 5 files changed, 709 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-sunxi/sunxi_display.h
 create mode 100644 drivers/video/sunxi_display.c

diff --git a/arch/arm/include/asm/arch-sunxi/sunxi_display.h 
b/arch/arm/include/asm/arch-sunxi/sunxi_display.h
new file mode 100644
index 000..4456778
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/sunxi_display.h
@@ -0,0 +1,21 @@
+/*
+ * (C) Copyright 2014 Luc Verhaegen l...@skynet.be
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation's version 2 and any
+ * later version the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#ifndef _SUNXI_DISPLAY_H_
+#define _SUNXI_DISPLAY_H_
+
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+void sunxi_simplefb_setup(void *blob);
+#endif
+
+#endif /* _SUNXI_DISPLAY_H_ */
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 2179e23..e819b12 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -26,6 +26,10 @@
 #include asm/io.h
 #include net.h
 
+#ifdef CONFIG_VIDEO
+#include asm/arch-sunxi/sunxi_display.h
+#endif
+
 DECLARE_GLOBAL_DATA_PTR;
 
 /* add board specific code here */
@@ -185,3 +189,13 @@ int misc_init_r(void)
return 0;
 }
 #endif
+
+#ifdef CONFIG_OF_BOARD_SETUP
+void
+ft_board_setup(void *blob, bd_t *bd)
+{
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+   sunxi_simplefb_setup(blob);
+#endif
+}
+#endif /* CONFIG_OF_BOARD_SETUP */
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 945f35d..9a25c84 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_VIDEO_SANDBOX_SDL) += sandbox_sdl.o
 obj-$(CONFIG_VIDEO_SED13806) += sed13806.o
 obj-$(CONFIG_VIDEO_SM501) += sm501.o
 obj-$(CONFIG_VIDEO_SMI_LYNXEM) += smiLynxEM.o videomodes.o
+obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o
 obj-$(CONFIG_VIDEO_TEGRA) += tegra.o
 obj-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o
 obj-$(CONFIG_FORMIKE) += formike.o
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
new file mode 100644
index 000..251fb67
--- /dev/null
+++ b/drivers/video/sunxi_display.c
@@ -0,0 +1,639 @@
+/*
+ * (C) Copyright 2013-2014 Luc Verhaegen l...@skynet.be
+ *
+ * Display driver for Allwinner SoCs.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation's version 2 and any
+ * later version the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * This driver does nothing but HDMI at a fixed mode right now. At some
+ * point in the near future, LCD and VGA will be added.
+ *
+ * The display driver infrastructure in uboot does not immediately allow for
+ * modeline creation off of edid. The mode is therefor hardcoded to
+ * 1024x768@60Hz 32bpp. This is acceptable for most HDMI monitors, but far
+ * from ideal. If so desired, alter the modeline in video_hw_init()
+ */
+
+#include common.h
+
+#include asm/io.h
+#include asm/global_data.h
+#include video_fb.h
+#include linux/fb.h
+#include asm/arch-sunxi/sunxi_display.h
+
+/* for simplefb */
+#ifdef CONFIG_OF_BOARD_SETUP
+#include libfdt.h
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct sunxi_display {
+   GraphicDevice graphic_device[1];
+   int enabled;
+} sunxi_display[1];
+
+/*
+ * Convenience functions to ease readability, and to provide an easy
+ * comparison with the sunxi kms driver.
+ */
+static unsigned int
+sunxi_io_read(void *base, int offset)
+{
+   return readl(base + offset);
+}
+
+static void
+sunxi_io_write(void *base, int offset, unsigned int value)
+{
+   writel(value, base + offset);
+}
+
+static void
+sunxi_io_mask(void *base, int offset, unsigned int value, unsigned int mask)
+{
+   unsigned int tmp = readl(base + offset);
+
+   tmp = ~mask;
+   tmp |= value  mask;
+
+   writel(tmp, base +