pxafb and am200epd question

Hi Eric,

I just noticed commit ce4fb7b892a6d6c6a0f87366b26fd834d2923dd7 which
splits out the pxa LCD defines from pxa-regs.h into a separate
regs-lcd.h. Unfortunately,  drivers/video/am200epd.c had a dependency
on the LCD definitions from pxa-regs.h so its build is temporarily
broken. I will do a quick patch to make am200epd use regs-lcd.h and
also switch to the __raw_read/write just like pxafb. That'll fix
things in the short term.

I think I am at fault here because maybe I shouldn't be directly
touching the pxa LCDC regs. I think I should explain some of the
background so that we can figure out a solution. Okay, so here are the
details:

* metronomefb is the arch independent code that handles talking to an
E-Ink controller called Metronome. It uses a vmalloc-ed framebuffer
that is memory mappable by userspace apps (using fb_defio) which is
then backed by a physically contiguous dma-able framebuffer which also
has to store other non-framebuffer things like a waveform used by the
E-Ink controller.
* am200epd is the "platform device", ie: board specific code (runs on
a gumstix pxa255 board) that provides the functions called by
metronomefb that sets up board specific gpio, LCD controller setup,
interrupt from gpio and other board related things. This is the driver
that is the source of the problem. It touches stuff from the pxa's
LCDC in order to set the LCDC to use the metronomefb framebuffer and
also set up a custom modeline.

Temporarily am200epd will need to depend on regs-lcd.h because I
haven't figured out all the different panels that E-Ink have and how
to handle resolution setup for them. Longer term, maybe am200epd can
share some code with pxafb to setup various parameters on its behalf.
So basically am200epd could call a pxa-lcdc type function to say
"please setup the LCDC with the following desired mode parameters and
give me a physically contiguous framebuffer of this size".

The other alternative is to just leave things as they are and have
am200epd keep some private LCDC setup. I guess its not much code,
maybe 20-50 lines of LCDC register init and we would then need to

12 more lines

Hi Jaya,

I'm sorry I didn't expect the change to impact other modules. I'm OK
with your short-term solution.

In a long run, I guess the most critical dependency of metronomefb on
pxafb is the video memory, while pxafb currently allocates its own
video memory (correct me if my understanding is wrong).  For such case
pxafb.c should really be modified where its platform data can specify
customized video memory location. I'm not sure if this satisfy your
requirement.

And indeed what am200epd.c is doing looks quite platform specific, which
means it's better to move them into some kind of <platform>.c, and note
that manipulating GPARx/GPSRx/GPLRx directly is no longer recommended :)

Thoughts?

- eric

-----Original Message-----
From: Jaya Kumar [mailto:<redacted>]
Sent: Tuesday, May 06, 2008 8:06 PM
To: Eric Miao
Cc: Linux Frame Buffer Device Development
Subject: pxafb and am200epd question

Hi Eric,

I just noticed commit ce4fb7b892a6d6c6a0f87366b26fd834d2923dd7 which
splits out the pxa LCD defines from pxa-regs.h into a separate
regs-lcd.h. Unfortunately,  drivers/video/am200epd.c had a dependency
on the LCD definitions from pxa-regs.h so its build is temporarily
broken. I will do a quick patch to make am200epd use regs-lcd.h and
also switch to the __raw_read/write just like pxafb. That'll fix
things in the short term.

I think I am at fault here because maybe I shouldn't be directly
touching the pxa LCDC regs. I think I should explain some of the
background so that we can figure out a solution. Okay, so here are the
details:

* metronomefb is the arch independent code that handles talking to an
E-Ink controller called Metronome. It uses a vmalloc-ed framebuffer
that is memory mappable by userspace apps (using fb_defio) which is
then backed by a physically contiguous dma-able framebuffer which also
has to store other non-framebuffer things like a waveform used by the
E-Ink controller.
* am200epd is the "platform device", ie: board specific code (runs on
a gumstix pxa255 board) that provides the functions called by
metronomefb that sets up board specific gpio, LCD controller setup,
interrupt from gpio and other board related things. This is the driver
that is the source of the problem. It touches stuff from the pxa's
LCDC in order to set the LCDC to use the metronomefb framebuffer and
also set up a custom modeline.

Temporarily am200epd will need to depend on regs-lcd.h because I
haven't figured out all the different panels that E-Ink have and how
to handle resolution setup for them. Longer term, maybe am200epd can
share some code with pxafb to setup various parameters on its behalf.

13 more quoted lines

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

On Tue, May 6, 2008 at 9:14 PM, Eric Miao [off-list ref] wrote:

 In a long run, I guess the most critical dependency of metronomefb on
 pxafb is the video memory, while pxafb currently allocates its own
 video memory (correct me if my understanding is wrong).  For such case
 pxafb.c should really be modified where its platform data can specify
 customized video memory location. I'm not sure if this satisfy your
 requirement.

Hi Eric,

I think you are right. I can make modifications to accommodate this so
that am200epd doesn't result in allocation of its own physical
framebuffer. Here's what I am thinking:

a) am200epd will use set_pxa_fb_info and pxafb_mach_info to pass pxafb
information about modes that it wants. It can pass desired LCCR0..3
settings through the lccr0,1,2,3 entries in pxafb_mach_info.
b) am200epd will find out from metronomefb about the size of the
waveform area that it needs in the framebuffer. It can do this before
it calls set_pxa_fb_info. We can add an entry to pxafb_mach_info like
extra_video_mem. Then pxafb can add that to the calculation of
map_size so that the allocated framebuffer is suitable for am200epd.
c) am200epd will need a way to get access to pxafb's map_cpu. This is
the part that I'm unsure about. Maybe we can add a callback function
entry in pxafb_mach_info that will be called by pxafb once it has
allocated a framebuffer.

Let me know if this sounds reasonable, especially on part c. If you
like it, I will be happy to start writing a patch to do this.

 And indeed what am200epd.c is doing looks quite platform specific, which
 means it's better to move them into some kind of <platform>.c, and note
 that manipulating GPARx/GPSRx/GPLRx directly is no longer recommended :)

Agreed. I intend to remove that code and switch to the new gpio stuff.

Thanks,
jaya

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

On Wed, May 7, 2008 at 11:07 AM, Jaya Kumar [off-list ref] wrote:

On Tue, May 6, 2008 at 9:14 PM, Eric Miao [off-list ref] wrote:

quoted

 In a long run, I guess the most critical dependency of metronomefb on
 pxafb is the video memory, while pxafb currently allocates its own
 video memory (correct me if my understanding is wrong).  For such case
 pxafb.c should really be modified where its platform data can specify
 customized video memory location. I'm not sure if this satisfy your
 requirement.

Hi Eric,

I think you are right. I can make modifications to accommodate this so
that am200epd doesn't result in allocation of its own physical
framebuffer. Here's what I am thinking:

a) am200epd will use set_pxa_fb_info and pxafb_mach_info to pass pxafb
information about modes that it wants. It can pass desired LCCR0..3
settings through the lccr0,1,2,3 entries in pxafb_mach_info.
b) am200epd will find out from metronomefb about the size of the
waveform area that it needs in the framebuffer. It can do this before
it calls set_pxa_fb_info. We can add an entry to pxafb_mach_info like
extra_video_mem. Then pxafb can add that to the calculation of
map_size so that the allocated framebuffer is suitable for am200epd.
c) am200epd will need a way to get access to pxafb's map_cpu. This is
the part that I'm unsure about. Maybe we can add a callback function
entry in pxafb_mach_info that will be called by pxafb once it has
allocated a framebuffer.

Let me know if this sounds reasonable, especially on part c. If you
like it, I will be happy to start writing a patch to do this.

quoted

 And indeed what am200epd.c is doing looks quite platform specific, which
 means it's better to move them into some kind of <platform>.c, and note
 that manipulating GPARx/GPSRx/GPLRx directly is no longer recommended :)

Agreed. I intend to remove that code and switch to the new gpio stuff.

Thanks,

2 more quoted lines

Hi Eric,

I'm thinking something along the lines of the following. Not a real
patch, just a draft.

diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
index 3ab6e3d..6d48fd2 100644
--- a/drivers/video/pxafb.c
+++ b/drivers/video/pxafb.c

@@ -1247,14 +1248,16 @@ static int pxafb_resume(struct platform_device *dev)
  *      cache.  Once this area is remapped, all virtual memory
  *      access to the video memory should occur at the new region.
  */
-static int __init pxafb_map_video_memory(struct pxafb_info *fbi)
+static int __init pxafb_map_video_memory(struct pxafb_info *fbi,
+                                        struct pxafb_mach_info *inf)
 {
        /*
         * We reserve one page for the palette, plus the size
         * of the framebuffer.
         */
        fbi->video_offset = PAGE_ALIGN(sizeof(struct pxafb_dma_buff));
-       fbi->map_size = PAGE_ALIGN(fbi->fb.fix.smem_len + fbi->video_offset);
+       fbi->map_size = PAGE_ALIGN(fbi->fb.fix.smem_len + fbi->video_offset +
+                                       inf->extra_video_mem);
        fbi->map_cpu = dma_alloc_writecombine(fbi->dev, fbi->map_size,
                                              &fbi->map_dma, GFP_KERNEL);

@@ -1281,6 +1284,9 @@ static int __init pxafb_map_video_memory(struct

pxafb_info *fbi)
                fbi->smart_cmds = (uint16_t *) fbi->dma_buff->cmd_buff;
                fbi->n_smart_cmds = 0;
 #endif
+               if (inf->share_video_mem)
+                       inf->share_video_mem(fbi->fb.screen_base,
+                                       fbi->screen_dma, inf->extra_data);
        }

        return fbi->map_cpu ? 0 : -ENOMEM;

@@ -1703,7 +1709,7 @@ static int __init pxafb_probe(struct platform_device *dev)
        }

        /* Initialize video memory */
-       ret = pxafb_map_video_memory(fbi);
+       ret = pxafb_map_video_memory(fbi, inf);
        if (ret) {
                dev_err(&dev->dev, "Failed to allocate video RAM: %d\n", ret);
                ret = -ENOMEM;

diff --git a/include/asm-arm/arch-pxa/pxafb.h b/include/asm-arm/arch-pxa/pxafb.h
index bbd2239..39560c2 100644
--- a/include/asm-arm/arch-pxa/pxafb.h
+++ b/include/asm-arm/arch-pxa/pxafb.h

@@ -138,9 +138,13 @@ struct pxafb_mach_info {
         * All other bits in LCCR4 should be left alone.
         */
        u_int           lccr4;
+       unsigned int    extra_video_mem; /* extra mem for special devices */
+       void            *extra_data; /* extra data for 2ndary drivers */
        void (*pxafb_backlight_power)(int);
        void (*pxafb_lcd_power)(int, struct fb_var_screeninfo *);
        void (*smart_update)(struct fb_info *);
+       /* share_video_mem allows a 2ndary driver to use the framebuffer */
+       void (*share_video_mem)(unsigned char *, dma_addr_t, void *);
 };
 void set_pxa_fb_info(struct pxafb_mach_info *hard_pxa_fb_info);
 void set_pxa_fb_parent(struct device *parent_dev);

I haven't tried it out yet but I think that would be the bulk of the
changes. Let me know what you think. If you're happy with that and if
I can get it to work, then I can probably skip doing the temporary fix
to use __raw_write.

Thanks,
jaya

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Hi Jaya,

I'm ok with the extra_video_mem, yet I feel a bit upset about the callback
to notify the peer about its allocated memory. I guess the am200epd.c can
still examine the registered_fb[] to see the screen_base and screen_size.

- eric

-----Original Message-----
From: Jaya Kumar [mailto:<redacted>]
Sent: Friday, May 09, 2008 12:03 AM
To: Eric Miao
Cc: Linux Frame Buffer Device Development
Subject: Re: pxafb and am200epd question

On Wed, May 7, 2008 at 11:07 AM, Jaya Kumar [off-list ref] wrote:

quoted

On Tue, May 6, 2008 at 9:14 PM, Eric Miao [off-list ref] wrote:

quoted

 In a long run, I guess the most critical dependency of metronomefb on
 pxafb is the video memory, while pxafb currently allocates its own
 video memory (correct me if my understanding is wrong).  For such case
 pxafb.c should really be modified where its platform data can specify
 customized video memory location. I'm not sure if this satisfy your
 requirement.

Hi Eric,

I think you are right. I can make modifications to accommodate this so
that am200epd doesn't result in allocation of its own physical
framebuffer. Here's what I am thinking:

a) am200epd will use set_pxa_fb_info and pxafb_mach_info to pass pxafb
information about modes that it wants. It can pass desired LCCR0..3
settings through the lccr0,1,2,3 entries in pxafb_mach_info.
b) am200epd will find out from metronomefb about the size of the
waveform area that it needs in the framebuffer. It can do this before
it calls set_pxa_fb_info. We can add an entry to pxafb_mach_info like
extra_video_mem. Then pxafb can add that to the calculation of
map_size so that the allocated framebuffer is suitable for am200epd.
c) am200epd will need a way to get access to pxafb's map_cpu. This is
the part that I'm unsure about. Maybe we can add a callback function
entry in pxafb_mach_info that will be called by pxafb once it has
allocated a framebuffer.

Let me know if this sounds reasonable, especially on part c. If you
like it, I will be happy to start writing a patch to do this.

quoted

87 more quoted lines

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

On Fri, May 9, 2008 at 5:02 AM, Eric Miao [off-list ref] wrote:

Hi Jaya,

I'm ok with the extra_video_mem, yet I feel a bit upset about the callback
to notify the peer about its allocated memory. I guess the am200epd.c can
still examine the registered_fb[] to see the screen_base and screen_size.

Hi Eric,

Not sure I follow. How would am200epd get access to the screen_base
without a callback?

Thanks,
jaya

- eric

quoted

-----Original Message-----
From: Jaya Kumar [mailto:<redacted>]
Sent: Friday, May 09, 2008 12:03 AM
To: Eric Miao
Cc: Linux Frame Buffer Device Development
Subject: Re: pxafb and am200epd question

On Wed, May 7, 2008 at 11:07 AM, Jaya Kumar [off-list ref] wrote:

quoted

On Tue, May 6, 2008 at 9:14 PM, Eric Miao [off-list ref] wrote:

quoted

 In a long run, I guess the most critical dependency of metronomefb on
 pxafb is the video memory, while pxafb currently allocates its own
 video memory (correct me if my understanding is wrong).  For such case
 pxafb.c should really be modified where its platform data can specify
 customized video memory location. I'm not sure if this satisfy your
 requirement.

Hi Eric,

I think you are right. I can make modifications to accommodate this so
that am200epd doesn't result in allocation of its own physical
framebuffer. Here's what I am thinking:

a) am200epd will use set_pxa_fb_info and pxafb_mach_info to pass pxafb
information about modes that it wants. It can pass desired LCCR0..3
settings through the lccr0,1,2,3 entries in pxafb_mach_info.
b) am200epd will find out from metronomefb about the size of the
waveform area that it needs in the framebuffer. It can do this before
it calls set_pxa_fb_info. We can add an entry to pxafb_mach_info like
extra_video_mem. Then pxafb can add that to the calculation of
map_size so that the allocated framebuffer is suitable for am200epd.
c) am200epd will need a way to get access to pxafb's map_cpu. This is
the part that I'm unsure about. Maybe we can add a callback function
entry in pxafb_mach_info that will be called by pxafb once it has
allocated a framebuffer.

Let me know if this sounds reasonable, especially on part c. If you

91 more quoted lines

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

registered_fb[] is an array that fbmem.c maintains but exported for other
drivers' usage

You can check that from fbmem.c

- eric

-----Original Message-----
From: Jaya Kumar [mailto:<redacted>]
Sent: Friday, May 09, 2008 5:08 PM
To: Eric Miao
Cc: Linux Frame Buffer Device Development
Subject: Re: pxafb and am200epd question

On Fri, May 9, 2008 at 5:02 AM, Eric Miao [off-list ref] wrote:

quoted

Hi Jaya,

I'm ok with the extra_video_mem, yet I feel a bit upset about the callback
to notify the peer about its allocated memory. I guess the am200epd.c can
still examine the registered_fb[] to see the screen_base and screen_size.

Hi Eric,

Not sure I follow. How would am200epd get access to the screen_base
without a callback?

Thanks,
jaya

quoted

- eric

quoted

-----Original Message-----
From: Jaya Kumar [mailto:<redacted>]
Sent: Friday, May 09, 2008 12:03 AM
To: Eric Miao
Cc: Linux Frame Buffer Device Development
Subject: Re: pxafb and am200epd question

On Wed, May 7, 2008 at 11:07 AM, Jaya Kumar [off-list ref] wrote:

quoted

On Tue, May 6, 2008 at 9:14 PM, Eric Miao [off-list ref] wrote:

quoted

 In a long run, I guess the most critical dependency of metronomefb on
 pxafb is the video memory, while pxafb currently allocates its own
 video memory (correct me if my understanding is wrong).  For such case
 pxafb.c should really be modified where its platform data can specify
 customized video memory location. I'm not sure if this satisfy your

117 more quoted lines

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

On Fri, May 9, 2008 at 5:10 AM, Eric Miao [off-list ref] wrote:

registered_fb[] is an array that fbmem.c maintains but exported for other
drivers' usage

You can check that from fbmem.c

Ok. I think I understand what you mean now. Just to make sure I
understood correctly, here's what I see:

struct fb_info *registered_fb[FB_MAX] __read_mostly;

and your suggestion is for am200epd to walk the list of registered_fb
until it finds the fb_info with matching parameter like below. But
am200epd may have some trouble identifying which is the right
registered_fb[]. am200epd could assume that it will always be
registered_fb[0] but that doesn't seem like the right solution.
am200epd can deref the fb_var_screeninfo of each info and then see if
it matches the modes it supplied but that also doesn't seem right. Is
there a better way to make sure it has found the correct fb?
        for (i = 0; i < FB_MAX; i++) {
                mapped = 0;
                info = registered_fb[i];

I think with the callback, there is an advantage which is that pxafb
can inform am200epd at the right time after the framebuffer allocation
is done, and we can also add a callback to notify it when it is no
longer safe to access the framebuffer. I think this will be more
complex to achieve with the registered_fb based access.

I'm trying to figure out what is the disadvantage of having the
callback. Can you help me to understand this?

Thanks,
jaya

- eric

quoted

-----Original Message-----
From: Jaya Kumar [mailto:<redacted>]
Sent: Friday, May 09, 2008 5:08 PM
To: Eric Miao
Cc: Linux Frame Buffer Device Development
Subject: Re: pxafb and am200epd question

On Fri, May 9, 2008 at 5:02 AM, Eric Miao [off-list ref] wrote:

quoted

Hi Jaya,

I'm ok with the extra_video_mem, yet I feel a bit upset about the callback
to notify the peer about its allocated memory. I guess the am200epd.c can
still examine the registered_fb[] to see the screen_base and screen_size.

Hi Eric,

Not sure I follow. How would am200epd get access to the screen_base
without a callback?

Thanks,
jaya

quoted

- eric

quoted

-----Original Message-----
From: Jaya Kumar [mailto:<redacted>]
Sent: Friday, May 09, 2008 12:03 AM
To: Eric Miao
Cc: Linux Frame Buffer Device Development
Subject: Re: pxafb and am200epd question

On Wed, May 7, 2008 at 11:07 AM, Jaya Kumar [off-list ref] wrote:

quoted

On Tue, May 6, 2008 at 9:14 PM, Eric Miao [off-list ref] wrote:

quoted

 In a long run, I guess the most critical dependency of metronomefb on
 pxafb is the video memory, while pxafb currently allocates its own

121 more quoted lines

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

On Thu, May 8, 2008 at 12:03 PM, Jaya Kumar [off-list ref] wrote:

Hi Eric,

I'm thinking something along the lines of the following. Not a real
patch, just a draft.

Hi Eric,

After starting to test, a few more changes came up:

diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index d6c05b6..f7fcb5e 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c

@@ -127,6 +127,7 @@ struct platform_device pxa_device_fb = {
        .num_resources  = ARRAY_SIZE(pxafb_resources),
        .resource       = pxafb_resources,
 };
+EXPORT_SYMBOL_GPL(pxa_device_fb);

this is so that am200epd can access pxa_device_fb and pass it as the
platform_dev to pxafb when it is loaded. If I use a duplicate copy of
the struct, then pxafb can't get the LCDCLK.

diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
index 3ab6e3d..c9c7eea 100644

@@ -1613,24 +1661,28 @@ MODULE_PARM_DESC(options, "LCD parameters (see

Documentation/fb/pxafb.txt)");
 #define pxafb_setup_options()          (0)
 #endif


-static int __init pxafb_probe(struct platform_device *dev)
+static int __devinit pxafb_probe(struct platform_device *dev)

This was needed to solve that memory overlap on insmod issue. I think
__devinit is the right setting for pxafb_probe since it is called only
at probe().

@@ -778,8 +794,9 @@ static void setup_parallel_timing(struct pxafb_info *fbi,
 {
        unsigned int lines_per_panel, pcd = get_pcd(fbi, var->pixclock);

        fbi->reg_lccr1 =
-               LCCR1_DisWdth(var->xres) +
+               LCCR1_DisWdth(var->xres/2) +

This one is dirty and I'm trying to find a different solution now.
Basically, it is there because the metronome controller accepts only
16-bit transfers on the AMLCD. To get pxa to do that, I have to set
16bpp on lccr3. But the pixels are 8bpp which is why the lccr1 pixels
per line needs to actually be half what the actual ppl is. I'm
planning to spend some time looking at how pxa and metronome transfers
are done and see if I can find a better way to do this.

-               LCCR1_DisWdth(var->xres) +
+               LCCR1_DisWdth(var->xres/fbi->custom_ppl_div) +

Above would be the worst case, adding an entry like custom_ppl_div to
handle this 16bpp transfer with 8bpp lines. I'll try my best to avoid
that.

        if (fbi->map_cpu) {
                /* prevent initial garbage on screen */
                memset(fbi->map_cpu, 0, fbi->map_size);
-               fbi->fb.screen_base = fbi->map_cpu + fbi->video_offset;
-               fbi->screen_dma = fbi->map_dma + fbi->video_offset;
+               fbi->fb.screen_base = fbi->map_cpu;
+               fbi->screen_dma = fbi->map_dma;

@@ -1273,14 +1306,18 @@ static int __init

pxafb_map_video_memory(struct pxafb_info *fbi)
                fbi->fb.fix.smem_start = fbi->screen_dma;
                fbi->palette_size = fbi->fb.var.bits_per_pixel == 8 ? 256 : 16;
-               fbi->dma_buff = (void *) fbi->map_cpu;
-               fbi->dma_buff_phys = fbi->map_dma;
+               fbi->dma_buff = (void *) fbi->map_cpu + fbi->map_size
- fbi->video_offset;
+               fbi->dma_buff_phys = fbi->map_dma + fbi->map_size -
fbi->video_offset;

I moved the dma descriptors to the end of the framebuffer rather than
at the top. The reason is that way metronomefb can lay out the memory
in the framebuffer as: cmd, waveform, image data.

I'm sorry for the inconveniences that this may cause and really
appreciate your help in getting this right.

Thanks,
jaya

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone