fb_defio with a coherent DMA framebuffer

fb_defio with a coherent DMA framebuffer

[Nick.Thompson]

Hi,

We are attempting to get frame buffer functionality working on an LCD device with a memory mapped register interface. The LCD video memory is not directly accessible. We have a dedicated video DMA system to move data from an fb_mem frame buffer to the LCD device. The frame buffer allocated by our driver is in coherent DMA (dma_alloc_coherent) memory and not allocated by vmalloc.

To keep bus load to a minimum, we decided to use fb_defio to collate the frame buffer dma copies, but it seems that this doesn't work. When an application mmaps the fb, this appears to work, but the application only ever see the zero page mapped in and so writing doesn't occur, defio's mkwrite doesn't get called, etc, etc

Is fb_defio supposed to work with DMA memory? I saw a thread from over a year ago about defio's nopage (we're still using 2.6.24) being written to use driver supplied flags to specify what memory allocation type nopage is dealing with. Was this not implemented or not deemed necessary? I would be very interested to hear any suggestions about how we should tackle making this work.

Many thanks,
Nick.

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/

Re: fb_defio with a coherent DMA framebuffer

[Jaya Kumar]

On Fri, Dec 12, 2008 at 8:00 PM,  <Nick.Thompson@infineon.com> wrote:
> Hi,
>
> We are attempting to get frame buffer functionality working on an LCD device with a memory mapped register interface. The LCD video memory is not directly accessible. We have a dedicated video DMA system to move data from an fb_mem frame buffer to the LCD device. The frame buffer allocated by our driver is in coherent DMA (dma_alloc_coherent) memory and not allocated by vmalloc.


Hi Nick,

Apologies for the delay in responding, still catching up on mail.

>
> To keep bus load to a minimum, we decided to use fb_defio to collate the frame buffer dma copies, but it seems that

For the first part, great, I was hoping someone would start to use it
for dma coalescing. btw, my english is poor, but I assume collate
above means the same thing as coalesce.

> this doesn't work. When an application mmaps the fb, this appears to work, but the application only ever see the zero page mapped in and so writing doesn't occur, defio's mkwrite doesn't get called, etc, etc
>
> Is fb_defio supposed to work with DMA memory? I saw a thread from over a year ago about defio's nopage (we're still using 2.6.24) being written to use driver supplied flags to specify what memory allocation type nopage is dealing with. Was this not implemented or not deemed necessary? I would be very interested to hear any suggestions about how we should tackle making this work.

The current defio code does not work with DMA memory. This has been
recently rectified by Magnus Damm. This effort is still in progress in
some areas but I think it is usable. As for using 2.6.24, my response
to that would be: Why? We're on 2.6.28 and defio has seen a reasonable
amount of change since 24. :-)

Thanks,
jaya

------------------------------------------------------------------------------

Re: fb_defio with a coherent DMA framebuffer

[Magnus Damm]

On Fri, Dec 26, 2008 at 5:43 AM, Jaya Kumar <jayakumar.lkml@gmail.com> wrote:
> On Fri, Dec 12, 2008 at 8:00 PM,  <Nick.Thompson@infineon.com> wrote:
>> Is fb_defio supposed to work with DMA memory? I saw a thread from over a year ago about defio's nopage (we're still using 2.6.24) being written to use driver supplied flags to specify what memory allocation type nopage is dealing with. Was this not implemented or not deemed necessary? I would be very interested to hear any suggestions about how we should tackle making this work.
>
> The current defio code does not work with DMA memory. This has been
> recently rectified by Magnus Damm. This effort is still in progress in
> some areas but I think it is usable. As for using 2.6.24, my response
> to that would be: Why? We're on 2.6.28 and defio has seen a reasonable
> amount of change since 24. :-)

The patch that Jaya referrers to simply adds support for physically
contiguous frame buffers. This means that the frame buffer is
contiguous both in virtual space and physical space. Your frame buffer
memory must be backed with struct page though. The patch can be found
here:

http://thread.gmane.org/gmane.linux.ports.sh.devel/5012/focus=5015

However, your coherent memory may or may not be backed by struct page.
Some types of memories may have pfn mappings only. If your memory is
backed by struct page or not depends on your coherent DMA memory
implementation. On SuperH we use __get_free_pages() and split_page()
unless dma_declare_coherent() has been used. This works well for me.
Have a look at arch/sh/mm/consistent.c and kernel/dma-coherent.c in a
recent kernel.

Cheers,

/ magnus

------------------------------------------------------------------------------