From: Stanislaw Gruszka <stf_xl@wp.pl>
To: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Cc: linux-fbdev-devel@lists.sourceforge.net
Subject: Re: [RFC] double buffering for atmel_lcdfb
Date: Wed, 6 Aug 2008 15:53:03 +0200 [thread overview]
Message-ID: <200808061553.03706.stf_xl@wp.pl> (raw)
In-Reply-To: <20080806141305.49e883a2@hskinnemo-gx745.norway.atmel.com>
[-- Attachment #1.1: Type: text/plain, Size: 4357 bytes --]
Wednesday 06 August 2008 14:13:05 Haavard Skinnemoen napisał(a):
> Stanislaw Gruszka <stf_xl@wp.pl> wrote:
> > Below is patch I have already done. I also attached program which I used
> > for for tests - as far result are quite nice.
>
> I sent this patch a while ago, but I forgot to send Nicolas a test
> program when he asked for it :-(
>
> Could you give it a try? If it works for you, I think we can conclude
> that y-panning indeed works on AT91 so the patch can be applied.
Yes, it works with my program with ypanstep == yres (I did not check with ypanstep == 1 yet),
> Haavard
>
> From c1dc155e3c1a828faa4379a1f6f6de0bb58385cc Mon Sep 17 00:00:00 2001
> From: Haavard Skinnemoen <hskinnemoen@atmel.com>
> Date: Sat, 23 Jun 2007 17:38:26 +0200
> Subject: [PATCH] atmel_lcdfb: Set ypanstep to 1 and enable y-panning on
> AT91
>
> Panning in the y-direction can be done by simply changing the DMA base
> address. This code is already in place, but FBIOPAN_DISPLAY will
> currently fail because ypanstep is 0.
>
> Set ypanstep to 1 to indicate that we do support y-panning and also
> set the necessary acceleration flags on AT91 (AVR32 already have
> them.)
>
> Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
> ---
> drivers/video/atmel_lcdfb.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index b004036..c0a0364 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -39,7 +39,9 @@
> #endif
>
> #if defined(CONFIG_ARCH_AT91)
> -#define ATMEL_LCDFB_FBINFO_DEFAULT FBINFO_DEFAULT
> +#define ATMEL_LCDFB_FBINFO_DEFAULT (FBINFO_DEFAULT \
> + | FBINFO_PARTIAL_PAN_OK \
> + | FBINFO_HWACCEL_YPAN)
>
> static inline void atmel_lcdfb_update_dma2d(struct atmel_lcdfb_info
> *sinfo, struct fb_var_screeninfo *var)
> @@ -177,7 +179,7 @@ static struct fb_fix_screeninfo atmel_lcdfb_fix
> __initdata = { .type = FB_TYPE_PACKED_PIXELS,
> .visual = FB_VISUAL_TRUECOLOR,
> .xpanstep = 0,
> - .ypanstep = 0,
> + .ypanstep = 1,
> .ywrapstep = 0,
> .accel = FB_ACCEL_NONE,
> };
I think some video memory allocation control is also needed for users which
want to have frame buffer in main memory (this is a must with bigger LCDs)
Currently I just increase smem_len just before dma_alloc_writecombine() is called.
@@ -241,7 +243,7 @@ static int atmel_lcdfb_alloc_video_memory(struct atmel_lcdfb_info *sinfo)
struct fb_info *info = sinfo->info;
struct fb_var_screeninfo *var = &info->var;
- info->fix.smem_len = (var->xres_virtual * var->yres_virtual
+ info->fix.smem_len = (var->xres_virtual * var->yres_virtual * 2
* ((var->bits_per_pixel + 7) / 8));
info->screen_base = dma_alloc_writecombine(info->device,
Ok I know that I could just add memory resource to at91_lcdc_device, but
main RAM memory is managed by linux and need to be somehow allocated.
So maybe worth to add smem_len hint in at91_lcdc_device like this:
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -240,9 +242,11 @@ static int atmel_lcdfb_alloc_video_memory(struct atmel_lcdfb_info *sinfo)
{
struct fb_info *info = sinfo->info;
struct fb_var_screeninfo *var = &info->var;
-
- info->fix.smem_len = (var->xres_virtual * var->yres_virtual
+ unsigned int smem_len;
+
+ smem_len = (var->xres_virtual * var->yres_virtual
* ((var->bits_per_pixel + 7) / 8));
+ info->fix.smem_len = max(smem_len, sinfo->smem_len);
info->screen_base = dma_alloc_writecombine(info->device, info->fix.smem_len,
(dma_addr_t *)&info->fix.smem_start, GFP_KERNEL);
diff --git a/include/video/atmel_lcdc.h b/include/video/atmel_lcdc.h
index ed64862..7f3ff79 100644
--- a/include/video/atmel_lcdc.h
+++ b/include/video/atmel_lcdc.h
@@ -37,6 +37,7 @@ struct atmel_lcdfb_info {
struct fb_info *info;
void __iomem *mmio;
unsigned long irq_base;
+ unsigned int smem_len;
unsigned int guard_time;
struct platform_device *pdev;
Regards
Stanislaw Gruszka
[-- Attachment #1.2: Type: text/html, Size: 5511 bytes --]
[-- Attachment #2: Type: text/plain, Size: 363 bytes --]
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
[-- Attachment #3: Type: text/plain, Size: 182 bytes --]
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
next prev parent reply other threads:[~2008-08-06 13:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-06 9:36 [RFC] double buffering for atmel_lcdfb Stanislaw Gruszka
2008-08-06 9:55 ` Geert Uytterhoeven
2008-08-06 12:13 ` Haavard Skinnemoen
2008-08-06 13:53 ` Stanislaw Gruszka [this message]
2008-08-07 7:25 ` Stanislaw Gruszka
2008-08-07 10:48 ` Haavard Skinnemoen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200808061553.03706.stf_xl@wp.pl \
--to=stf_xl@wp.pl \
--cc=haavard.skinnemoen@atmel.com \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).