[PATCH] ep93xx: add framebuffer support to edb93xx boards

The ep9307, ep9312, and ep9315 variants of the ep93xx processor include the
raster engine needed for framebuffer support.

This allows the EDB93xx boards with those processors to use the framebuffer
driver.

Tested on an EDB9307A with the following kernel parameters:
	video=640x480-16 at 60
	video=1024x768-16 at 60

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>

---

diff --git a/arch/arm/mach-ep93xx/edb93xx.c b/arch/arm/mach-ep93xx/edb93xx.c
index 4b04316..49e3b3d 100644
--- a/arch/arm/mach-ep93xx/edb93xx.c
+++ b/arch/arm/mach-ep93xx/edb93xx.c

@@ -32,6 +32,7 @@
 #include <linux/i2c-gpio.h>
 
 #include <mach/hardware.h>
+#include <mach/fb.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>

@@ -111,6 +112,41 @@ static void __init edb93xx_register_pwm(void)
 }
 
 
+/*************************************************************************
+ * EDB93xx framebuffer
+ *************************************************************************/
+static struct ep93xxfb_mach_info __initdata edb93xxfb_info = {
+	.num_modes	= EP93XXFB_USE_MODEDB,
+	.bpp		= 16,
+	.flags		= 0,
+};
+
+static int __init edb93xx_has_fb(void)
+{
+	if (machine_is_edb9307() || machine_is_edb9307a() ||
+	    machine_is_edb9312() || machine_is_edb9315() ||
+	    machine_is_edb9315a()) {
+		/* These all have an ep93xx with video capability */
+		return 1;
+	} else {
+		/* The ep9301 and ep9302 do not have a video peripheral */
+		return 0;
+	}
+}
+
+static void __init edb93xx_register_fb(void)
+{
+	if (!edb93xx_has_fb())
+		return;
+
+	if (machine_is_edb9307a() || machine_is_edb9315a())
+		edb93xxfb_info.flags |= EP93XXFB_USE_SDCSN0;
+	else
+		edb93xxfb_info.flags |= EP93XXFB_USE_SDCSN3;
+
+	ep93xx_register_fb(&edb93xxfb_info);
+}
+
 static void __init edb93xx_init_machine(void)
 {
 	ep93xx_init_devices();

@@ -118,6 +154,7 @@ static void __init edb93xx_init_machine(void)
 	ep93xx_register_eth(&edb93xx_eth_data, 1);
 	edb93xx_register_i2c();
 	edb93xx_register_pwm();
+	edb93xx_register_fb();
 }
 
 

On Fri, Jan 7, 2011 at 11:38 PM, H Hartley Sweeten
[off-list ref] wrote:

The ep9307, ep9312, and ep9315 variants of the ep93xx processor include the
raster engine needed for framebuffer support.

This allows the EDB93xx boards with those processors to use the framebuffer
driver.

Tested on an EDB9307A with the following kernel parameters:
? ? ? ?video=640x480-16 at 60
? ? ? ?video=1024x768-16 at 60

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>

The code looks good, but there are hardware bugs in the EP93XX that
make the screen image jump a few pixels to the right once every few
seconds.  We found that 800x600-16 and 1024x768-8 were the highest
modes that are stable.
Did you find 1024x768-16 to be stable, say when running X and moving a
window? The effect was most visible on a phosphor CRT, less noticeable
on an LCD.

    M

On Saturday, January 08, 2011 12:53 PM, Martin Guy wrote:

On Fri, Jan 7, 2011 at 11:38 PM, H Hartley Sweeten [off-list ref] wrote:

quoted

The ep9307, ep9312, and ep9315 variants of the ep93xx processor include the
raster engine needed for framebuffer support.

This allows the EDB93xx boards with those processors to use the framebuffer
driver.

Tested on an EDB9307A with the following kernel parameters:
? ? ? ?video=640x480-16 at 60
? ? ? ?video=1024x768-16 at 60

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>

The code looks good, but there are hardware bugs in the EP93XX that
make the screen image jump a few pixels to the right once every few
seconds.  We found that 800x600-16 and 1024x768-8 were the highest
modes that are stable.

Hardware bugs in the EP93XX... No... ;-)

Did you find 1024x768-16 to be stable, say when running X and moving a
window? The effect was most visible on a phosphor CRT, less noticeable
on an LCD.

I don't have any use for X on the EP93XX so, no I have not tested that.
My app uses the SDL library and has very little actual "motion" going on
so the screen looks pretty stable in my tests.

I have noticed some timing issues with the framebuffer driver, the requested
60Hz refresh is being reported as either 59 or 61Hz on the display, but I
haven't taken the time to look into it yet.

Could the problem you are seeing just be a bandwidth limitation?  Have you
tried changing the AHB master priority order with the SysCon BysMstrArb
register (0x8093_0054)?  The default priority (00) has the following order:

1 - Raster Cursor
2 - MAC
3 - USB
4 - DMA
5 - ARM920T
6 - Raster

The other priority's put the Raster first and shuffle the others around
various ways.

Regards,
Hartley

On 01/08/2011 11:38 AM, H Hartley Sweeten wrote:

return (machine_is_edb9307() || machine_is_edb9307a() ...

Otherwise looks fine.

Acked-by: Ryan Mallon <redacted>

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

On Wednesday, January 26, 2011 4:51 PM, Ryan Mallon wrote:

On 01/08/2011 11:38 AM, H Hartley Sweeten wrote:

quoted

The ep9307, ep9312, and ep9315 variants of the ep93xx processor include the
raster engine needed for framebuffer support.

This allows the EDB93xx boards with those processors to use the framebuffer
driver.

Tested on an EDB9307A with the following kernel parameters:
	video=640x480-16 at 60
	video=1024x768-16 at 60

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>

quoted

+static int __init edb93xx_has_fb(void)
+{
+	if (machine_is_edb9307() || machine_is_edb9307a() ||
+	    machine_is_edb9312() || machine_is_edb9315() ||
+	    machine_is_edb9315a()) {

return (machine_is_edb9307() || machine_is_edb9307a() ...

OK.

I'm wondering if these *_has_{peripheral} helpers should just be defines and
moved to one of the mach headers.  That way the other ep93xx platforms can
use the same helpers.

Regards,
Hartley

On 01/27/2011 01:04 PM, H Hartley Sweeten wrote:

On Wednesday, January 26, 2011 4:51 PM, Ryan Mallon wrote:

quoted

On 01/08/2011 11:38 AM, H Hartley Sweeten wrote:

quoted

The ep9307, ep9312, and ep9315 variants of the ep93xx processor include the
raster engine needed for framebuffer support.

This allows the EDB93xx boards with those processors to use the framebuffer
driver.

Tested on an EDB9307A with the following kernel parameters:
	video=640x480-16 at 60
	video=1024x768-16 at 60

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>

quoted

quoted

+static int __init edb93xx_has_fb(void)
+{
+	if (machine_is_edb9307() || machine_is_edb9307a() ||
+	    machine_is_edb9312() || machine_is_edb9315() ||
+	    machine_is_edb9315a()) {

return (machine_is_edb9307() || machine_is_edb9307a() ...

OK.

I'm wondering if these *_has_{peripheral} helpers should just be defines and
moved to one of the mach headers.  That way the other ep93xx platforms can
use the same helpers.

I would think that they are only really needed for the edb board file
which supports all of the processors types. IIRC, The other boards all
have a specific processor and so the peripheral setup is fixed.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

On 7 January 2011 23:38, H Hartley Sweeten [off-list ref] wrote:

The ep9307, ep9312, and ep9315 variants of the ep93xx processor include the
raster engine needed for framebuffer support.

This allows the EDB93xx boards with those processors to use the framebuffer
driver.

Tested on an EDB9307A with the following kernel parameters:
? ? ? ?video=640x480-16 at 60
? ? ? ?video=1024x768-16 at 60

Hi. Sorry, I've been out of action for personal reasons.

I don't have an edb to test this, but suggest you compare with the
simone.c board file, which has similar code to enable the fb.
Compared to the mainline code in 2.6.36, I use just one patch, which
defines the working video modes. I attach it for reference.

    M
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simone-set-video-modes.patch
Type: text/x-patch
Size: 2038 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110127/7e1eba14/attachment.bin>

On Wednesday, January 26, 2011 10:29 PM, Martin Guy wrote:

On 7 January 2011 23:38, H Hartley Sweeten [off-list ref] wrote:

quoted

The ep9307, ep9312, and ep9315 variants of the ep93xx processor include the
raster engine needed for framebuffer support.

This allows the EDB93xx boards with those processors to use the framebuffer
driver.

Tested on an EDB9307A with the following kernel parameters:
? ? ? ?video=640x480-16 at 60
? ? ? ?video=1024x768-16 at 60

Hi. Sorry, I've been out of action for personal reasons.

I don't have an edb to test this, but suggest you compare with the
simone.c board file, which has similar code to enable the fb.
Compared to the mainline code in 2.6.36, I use just one patch, which
defines the working video modes. I attach it for reference.

The edb boards _are_ development boards, as such I really don't wish to limit the
modes that the framebuffer can be used with.

It's really up to the end user if the "twitching" at higher resolutions is an
issue.  For the dev boards I don't want to enforce any limitations.

Thanks,
Hartley