linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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