From: Stanislaw Gruszka <stf_xl@wp.pl>
To: linux-fbdev-devel@lists.sourceforge.net
Subject: Re: [RFC] double buffering for atmel_lcdfb
Date: Thu, 7 Aug 2008 09:25:54 +0200 [thread overview]
Message-ID: <200808070925.54552.stf_xl@wp.pl> (raw)
In-Reply-To: <200808061553.03706.stf_xl@wp.pl>
Wednesday 06 August 2008 15:53:03 Stanislaw Gruszka napisał(a):
> 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),
Panning by step 1 works too on my hardware.
> > 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;
Any comments on this?
Cheers
Stanislaw Gruszka
-------------------------------------------------------------------------
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=/
_______________________________________________
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-07 7:26 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
2008-08-07 7:25 ` Stanislaw Gruszka [this message]
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=200808070925.54552.stf_xl@wp.pl \
--to=stf_xl@wp.pl \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.