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

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