Re: [RFC] double buffering for atmel_lcdfb
flat view
From: Stanislaw Gruszka <stf_xl@wp.pl>
Date: 2008-08-06 13:53:18
Subsystem:
framebuffer layer, microchip lcdfb driver, the rest · Maintainers:
Helge Deller, Nicolas Ferre, Linus Torvalds
Wednesday 06 August 2008 14:13:05 Haavard Skinnemoen napisał(a):
Stanislaw Gruszka [off-list ref] wrote:quoted
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),
quoted hunk ↗ jump to hunk
Haavard From c1dc155e3c1a828faa4379a1f6f6de0bb58385cc Mon Sep 17 00:00:00 2001 From: Haavard Skinnemoen <redacted> 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 <redacted> --- 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