* [PATCH] ep93xx: add framebuffer support to edb93xx boards
2011-01-07 22:38 ` [PATCH] ep93xx: add framebuffer support to edb93xx boards H Hartley Sweeten
@ 2011-01-08 19:52 ` Martin Guy
2011-01-10 16:59 ` H Hartley Sweeten
2011-01-26 23:51 ` Ryan Mallon
2011-01-27 5:28 ` Martin Guy
2 siblings, 1 reply; 8+ messages in thread
From: Martin Guy @ 2011-01-08 19:52 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 7, 2011 at 11:38 PM, H Hartley Sweeten
<hartleys@visionengravers.com> 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
^ permalink raw reply [flat|nested] 8+ messages in thread* [PATCH] ep93xx: add framebuffer support to edb93xx boards
2011-01-08 19:52 ` Martin Guy
@ 2011-01-10 16:59 ` H Hartley Sweeten
0 siblings, 0 replies; 8+ messages in thread
From: H Hartley Sweeten @ 2011-01-10 16:59 UTC (permalink / raw)
To: linux-arm-kernel
On Saturday, January 08, 2011 12:53 PM, Martin Guy wrote:
> On Fri, Jan 7, 2011 at 11:38 PM, H Hartley Sweeten <hartleys@visionengravers.com> 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.
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] ep93xx: add framebuffer support to edb93xx boards
2011-01-07 22:38 ` [PATCH] ep93xx: add framebuffer support to edb93xx boards H Hartley Sweeten
2011-01-08 19:52 ` Martin Guy
@ 2011-01-26 23:51 ` Ryan Mallon
2011-01-27 0:04 ` H Hartley Sweeten
2011-01-27 5:28 ` Martin Guy
2 siblings, 1 reply; 8+ messages in thread
From: Ryan Mallon @ 2011-01-26 23:51 UTC (permalink / raw)
To: linux-arm-kernel
On 01/08/2011 11:38 AM, H Hartley Sweeten 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>
>
> ---
>
> 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()) {
return (machine_is_edb9307() || machine_is_edb9307a() ...
> + /* 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();
> }
Otherwise looks fine.
Acked-by: Ryan Mallon <ryan@bluewatersys.com>
--
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
^ permalink raw reply [flat|nested] 8+ messages in thread* [PATCH] ep93xx: add framebuffer support to edb93xx boards
2011-01-26 23:51 ` Ryan Mallon
@ 2011-01-27 0:04 ` H Hartley Sweeten
2011-01-27 0:10 ` Ryan Mallon
0 siblings, 1 reply; 8+ messages in thread
From: H Hartley Sweeten @ 2011-01-27 0:04 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday, January 26, 2011 4:51 PM, Ryan Mallon wrote:
> On 01/08/2011 11:38 AM, H Hartley Sweeten 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>
>>
>> +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
^ permalink raw reply [flat|nested] 8+ messages in thread* [PATCH] ep93xx: add framebuffer support to edb93xx boards
2011-01-27 0:04 ` H Hartley Sweeten
@ 2011-01-27 0:10 ` Ryan Mallon
0 siblings, 0 replies; 8+ messages in thread
From: Ryan Mallon @ 2011-01-27 0:10 UTC (permalink / raw)
To: linux-arm-kernel
On 01/27/2011 01:04 PM, H Hartley Sweeten wrote:
> On Wednesday, January 26, 2011 4:51 PM, Ryan Mallon wrote:
>> On 01/08/2011 11:38 AM, H Hartley Sweeten 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>
>>>
>
>>> +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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] ep93xx: add framebuffer support to edb93xx boards
2011-01-07 22:38 ` [PATCH] ep93xx: add framebuffer support to edb93xx boards H Hartley Sweeten
2011-01-08 19:52 ` Martin Guy
2011-01-26 23:51 ` Ryan Mallon
@ 2011-01-27 5:28 ` Martin Guy
2011-01-27 16:43 ` H Hartley Sweeten
2 siblings, 1 reply; 8+ messages in thread
From: Martin Guy @ 2011-01-27 5:28 UTC (permalink / raw)
To: linux-arm-kernel
On 7 January 2011 23:38, H Hartley Sweeten <hartleys@visionengravers.com> 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>
^ permalink raw reply [flat|nested] 8+ messages in thread* [PATCH] ep93xx: add framebuffer support to edb93xx boards
2011-01-27 5:28 ` Martin Guy
@ 2011-01-27 16:43 ` H Hartley Sweeten
0 siblings, 0 replies; 8+ messages in thread
From: H Hartley Sweeten @ 2011-01-27 16:43 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday, January 26, 2011 10:29 PM, Martin Guy wrote:
> On 7 January 2011 23:38, H Hartley Sweeten <hartleys@visionengravers.com> 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.
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
^ permalink raw reply [flat|nested] 8+ messages in thread