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