Re: [RFC 2.6.20 1/1] fbdev,mm: Deferred IO and hecubafb driver
On 2/23/07, Paul Mundt <[EMAIL PROTECTED]> wrote: On Fri, Feb 23, 2007 at 07:32:28AM +0100, Jaya Kumar wrote: > This is a first pass at abstracting deferred IO out from hecubafb and > into fbdev as was discussed before: > http://marc.theaimsgroup.com/?l=linux-fbdev-devel=117187443327466=2 > > Please let me know your feedback and if it looks okay so far. > How about this for an fsync()? I wonder if this will be sufficient for msync() based flushing, or whether the ->sync VMA op is needed again.. Looks fine to me. Thanks, jaya - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [RFC 2.6.20 1/1] fbdev, mm: Deferred IO and hecubafb driver
On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Fri, 2007-02-23 at 07:32 +0100, Jaya Kumar wrote:
Can you create 2 separate patches, one for the deferred_io and another
for the driver that uses it?
Will do.
> +static struct vm_operations_struct hecubafb_vm_ops = {
> + .nopage = hecubafb_vm_nopage,
> + .page_mkwrite = fb_deferred_io_mkwrite,
> +};
> +
It would seem to me that the above can be made generic, so we have this
instead:
We could. But I think fb_deferred_io_vm_nopage would then have to
handle the different types or possible combinations of framebuffer
allocations, if they kmalloced or vmalloced or maybe combinations. Ok.
I'll try to implement that. Maybe we'll need a flag where the driver
informs us of the type of allocation.
> +static struct fb_deferred_io hecubafb_defio = {
> + .delay = HZ,
> + .deferred_io= hecubafb_dpy_deferred_io,
> +};
Leaving the drivers to just fill up the above. This would result in a
decrease of code duplication and it will be easier for driver writers.
I agree it'll be much cleaner that way but was worried if having
fb_defio do that would prevent driver writers from having their own
nopage and controlling other vm related functionality. Looking at
drivers/video/* shows no one touching vm_ops, so I guess we'll be
fine. If fb_defio takes ownership of the driver's nopage, vm_ops, etc,
then it could be just the above struct and the
fb_deferred_io_init/cleanup functions that are exposed to the driver.
ie: if an fbdev driver calls fb_deferred_io_init, we setup their mmap,
vm_ops and the necessary bits. I'll give that a shot.
I would prefer to have the init and cleanup functions called by the
driver themselves, instead of piggy-backing them to the
framebuffer_register/unregister.
Understood. I had done it that way originally but changed just before
posting. I'll revert back. :)
This basically dumps the entire framebuffer to the hardware, doesn't it?
This framebuffer has only 2 pages at the most, so it doesn't matter. But
for hardware with MB's of RAM, I don't think this is feasible.
Yup, hecuba doesn't have clean partial update functionality. But the
callback exposed to drivers is:
+ void (*deferred_io)(struct fb_info *info, struct list_head *pagelist);
which gives the drivers the list of dirty pages in pagelist. So other
drivers for hardware with the right capabilities can implement
selective or partial updates. As you mentioned, I imagine that the
drivers internally could have a bit array to enable them to mark and
find sequential partial updates. I would leave the page bitmap for
drivers to do since it would be specific to their hardware.
Thanks,
jaya
Is there a way to selectively update only the touched pages, ie from the
fbdevio->pagelist? struct page has a field (pgoff_t index), is this
usable? If not, can we just create a bit array, just to tell the driver
which are the dirty pages?
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [RFC 2.6.20 1/1] fbdev, mm: Deferred IO and hecubafb driver
On 2/24/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Fri, 2007-02-23 at 07:32 +0100, Jaya Kumar wrote:
Can you create 2 separate patches, one for the deferred_io and another
for the driver that uses it?
Will do.
+static struct vm_operations_struct hecubafb_vm_ops = {
+ .nopage = hecubafb_vm_nopage,
+ .page_mkwrite = fb_deferred_io_mkwrite,
+};
+
It would seem to me that the above can be made generic, so we have this
instead:
We could. But I think fb_deferred_io_vm_nopage would then have to
handle the different types or possible combinations of framebuffer
allocations, if they kmalloced or vmalloced or maybe combinations. Ok.
I'll try to implement that. Maybe we'll need a flag where the driver
informs us of the type of allocation.
+static struct fb_deferred_io hecubafb_defio = {
+ .delay = HZ,
+ .deferred_io= hecubafb_dpy_deferred_io,
+};
Leaving the drivers to just fill up the above. This would result in a
decrease of code duplication and it will be easier for driver writers.
I agree it'll be much cleaner that way but was worried if having
fb_defio do that would prevent driver writers from having their own
nopage and controlling other vm related functionality. Looking at
drivers/video/* shows no one touching vm_ops, so I guess we'll be
fine. If fb_defio takes ownership of the driver's nopage, vm_ops, etc,
then it could be just the above struct and the
fb_deferred_io_init/cleanup functions that are exposed to the driver.
ie: if an fbdev driver calls fb_deferred_io_init, we setup their mmap,
vm_ops and the necessary bits. I'll give that a shot.
I would prefer to have the init and cleanup functions called by the
driver themselves, instead of piggy-backing them to the
framebuffer_register/unregister.
Understood. I had done it that way originally but changed just before
posting. I'll revert back. :)
This basically dumps the entire framebuffer to the hardware, doesn't it?
This framebuffer has only 2 pages at the most, so it doesn't matter. But
for hardware with MB's of RAM, I don't think this is feasible.
Yup, hecuba doesn't have clean partial update functionality. But the
callback exposed to drivers is:
+ void (*deferred_io)(struct fb_info *info, struct list_head *pagelist);
which gives the drivers the list of dirty pages in pagelist. So other
drivers for hardware with the right capabilities can implement
selective or partial updates. As you mentioned, I imagine that the
drivers internally could have a bit array to enable them to mark and
find sequential partial updates. I would leave the page bitmap for
drivers to do since it would be specific to their hardware.
Thanks,
jaya
Is there a way to selectively update only the touched pages, ie from the
fbdevio-pagelist? struct page has a field (pgoff_t index), is this
usable? If not, can we just create a bit array, just to tell the driver
which are the dirty pages?
Tony
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2.6.20 1/1] fbdev,mm: Deferred IO and hecubafb driver
On 2/23/07, Paul Mundt [EMAIL PROTECTED] wrote: On Fri, Feb 23, 2007 at 07:32:28AM +0100, Jaya Kumar wrote: This is a first pass at abstracting deferred IO out from hecubafb and into fbdev as was discussed before: http://marc.theaimsgroup.com/?l=linux-fbdev-develm=117187443327466w=2 Please let me know your feedback and if it looks okay so far. How about this for an fsync()? I wonder if this will be sufficient for msync() based flushing, or whether the -sync VMA op is needed again.. Looks fine to me. Thanks, jaya - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [RFC 2.6.20 1/1] fbdev, mm: Deferred IO and hecubafb driver
On Fri, 2007-02-23 at 07:32 +0100, Jaya Kumar wrote:
> Hi Tony, Paul, Peter, fbdev, lkml, and mm,
>
> This is a first pass at abstracting deferred IO out from hecubafb and
> into fbdev as was discussed before:
> http://marc.theaimsgroup.com/?l=linux-fbdev-devel=117187443327466=2
>
> Please let me know your feedback and if it looks okay so far.
>
Can you create 2 separate patches, one for the deferred_io and another
for the driver that uses it?
> +Another one may be if one has a device framebuffer that is in an usual
> format,
> +say diagonally shifting RGB, this may then be a mechanism for you to allow
> +apps to pretend to have a normal framebuffer but reswizzle for the device
> +framebuffer at vsync time based on the touched pagelist.
Hmm, yes, it can be used to implement a shadow framebuffer :-)
> +
> +How to use it: (for applications)
> +-
> +No changes needed. mmap the framebuffer like normal and just use it.
> +
> +How to use it: (for fbdev drivers)
> +--
> +The following example may be helpful.
> +
> +1. Setup your mmap and vm_ops structures. Eg:
> +
> +
> +The delay is the minimum delay between when the page_mkwrite trigger occurs
> +and when the deferred_io callback is called. The deferred_io callback is
> +explained below.
> +
> +static struct vm_operations_struct hecubafb_vm_ops = {
> + .nopage = hecubafb_vm_nopage,
> + .page_mkwrite = fb_deferred_io_mkwrite,
> +};
> +
It would seem to me that the above can be made generic, so we have this
instead:
static struct vm_operations_struct fb_deferred_vm_ops = {
.nopage = fb_deferred_io_vm_nopage,
.page_mkwrite = fb_deferred_io_mkwrite,
};
> +You will need a nopage routine to find and retrive the struct page for your
> +framebuffer pages. You must set page_mkwrite to fb_deferred_io_mkwrite.
> +Here's the example nopage for hecubafb where it is a vmalloced framebuffer.
> +
> +static int hecubafb_mmap(struct fb_info *info, struct vm_area_struct *vma)
> +{
> + vma->vm_ops = _vm_ops;
> + vma->vm_flags |= ( VM_IO | VM_RESERVED | VM_DONTEXPAND );
> + vma->vm_private_data = info;
> + return 0;
> +}
And this too as fb_deferred_io_mmap.
> +
> +static struct page* hecubafb_vm_nopage(struct vm_area_struct *vma,
> + unsigned long vaddr, int *type)
> +{
> + unsigned long offset;
> + struct page *page;
> + struct fb_info *info = vma->vm_private_data;
> +
> + offset = (vaddr - vma->vm_start) + (vma->vm_pgoff << PAGE_SHIFT);
> + if (offset >= (DPY_W*DPY_H)/8)
> + return NOPAGE_SIGBUS;
> +
To make it generic, this can simply be:
if (offset >= info->fix.smem_len)
return NOPAGE_SIGBUS.
> + page = vmalloc_to_page(info->screen_base + offset);
> + if (!page)
> + return NOPAGE_OOM;
> +
> + get_page(page);
> + if (type)
> + *type = VM_FAULT_MINOR;
> + return page;
> +}
> +
>
> +static struct fb_deferred_io hecubafb_defio = {
> + .delay = HZ,
> + .deferred_io= hecubafb_dpy_deferred_io,
> +};
Leaving the drivers to just fill up the above. This would result in a
decrease of code duplication and it will be easier for driver writers.
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 2822526..863126a 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1325,6 +1325,7 @@ register_framebuffer(struct fb_info *fb_info)
>
> event.info = fb_info;
> fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, );
> + fb_deferred_io_init(fb_info);
> return 0;
> }
>
> @@ -1355,6 +1356,7 @@ unregister_framebuffer(struct fb_info *fb_info)
> fb_destroy_modelist(_info->modelist);
> registered_fb[i]=NULL;
> num_registered_fb--;
> + fb_deferred_io_cleanup(fb_info);
> fb_cleanup_device(fb_info);
> device_destroy(fb_class, MKDEV(FB_MAJOR, i));
> event.info = fb_info;
I would prefer to have the init and cleanup functions called by the
driver themselves, instead of piggy-backing them to the
framebuffer_register/unregister.
> +static void hecubafb_dpy_update(struct hecubafb_par *par)
> +{
> + int i;
> + unsigned char *buf = par->info->screen_base;
> +
> + apollo_send_command(par, 0xA0);
> +
> + for (i=0; i < (DPY_W*DPY_H/8); i++) {
> + apollo_send_data(par, *(buf++));
> + }
> +
This basically dumps the entire framebuffer to the hardware, doesn't it?
This framebuffer has only 2 pages at the most, so it doesn't matter. But
for hardware with MB's of RAM, I don't think this is feasible.
Is there a way to selectively update only the touched pages, ie from the
fbdevio->pagelist? struct page has a field (pgoff_t index), is this
usable? If not, can we just create a bit array, just to tell the driver
which are the dirty pages?
Tony
-
To unsubscribe from this list: send the line
Re: [RFC 2.6.20 1/1] fbdev,mm: Deferred IO and hecubafb driver
On Fri, Feb 23, 2007 at 07:32:28AM +0100, Jaya Kumar wrote:
> This is a first pass at abstracting deferred IO out from hecubafb and
> into fbdev as was discussed before:
> http://marc.theaimsgroup.com/?l=linux-fbdev-devel=117187443327466=2
>
> Please let me know your feedback and if it looks okay so far.
>
How about this for an fsync()? I wonder if this will be sufficient for
msync() based flushing, or whether the ->sync VMA op is needed again..
Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
--
drivers/video/fb_defio.c | 12
drivers/video/fbmem.c|3 +++
include/linux/fb.h |2 ++
3 files changed, 17 insertions(+)
diff --git a/drivers/video/fb_defio.c b/drivers/video/fb_defio.c
index c3e57cc..8a66dc8 100644
--- a/drivers/video/fb_defio.c
+++ b/drivers/video/fb_defio.c
@@ -52,6 +52,18 @@ static void fb_deferred_io_work(struct work_struct *work)
mutex_unlock(>lock);
}
+int fb_deferred_io_fsync(struct file *file, struct dentry *dentry, int
datasync)
+{
+ struct fb_info *info = file->private_data;
+
+ /* Kill off the delayed work */
+ cancel_rearming_delayed_work(>deferred_work);
+
+ /* Run it immediately */
+ return schedule_delayed_work(>deferred_work, 0);
+}
+EXPORT_SYMBOL_GPL(fb_deferred_io_fsync);
+
/* vm_ops->page_mkwrite handler */
int fb_deferred_io_mkwrite(struct vm_area_struct *vma,
struct page *page)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 863126a..69bbbe2 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1266,6 +1266,9 @@ static const struct file_operations fb_fops = {
#ifdef HAVE_ARCH_FB_UNMAPPED_AREA
.get_unmapped_area = get_fb_unmapped_area,
#endif
+#ifdef CONFIG_FB_DEFERRED_IO
+ .fsync =fb_deferred_io_fsync,
+#endif
};
struct class *fb_class;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index af217dd..3f62652 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -933,6 +933,8 @@ extern void fb_deferred_io_init(struct fb_info *info);
extern void fb_deferred_io_cleanup(struct fb_info *info);
extern int fb_deferred_io_mkwrite(struct vm_area_struct *vma,
struct page *page);
+extern int fb_deferred_io_fsync(struct file *file, struct dentry *dentry,
+ int datasync);
#else
#define fb_deferred_io_init(fb_info) do { } while (0)
#define fb_deferred_io_cleanup(fb_info)do { } while (0)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2.6.20 1/1] fbdev,mm: Deferred IO and hecubafb driver
On Fri, Feb 23, 2007 at 07:32:28AM +0100, Jaya Kumar wrote:
This is a first pass at abstracting deferred IO out from hecubafb and
into fbdev as was discussed before:
http://marc.theaimsgroup.com/?l=linux-fbdev-develm=117187443327466w=2
Please let me know your feedback and if it looks okay so far.
How about this for an fsync()? I wonder if this will be sufficient for
msync() based flushing, or whether the -sync VMA op is needed again..
Signed-off-by: Paul Mundt [EMAIL PROTECTED]
--
drivers/video/fb_defio.c | 12
drivers/video/fbmem.c|3 +++
include/linux/fb.h |2 ++
3 files changed, 17 insertions(+)
diff --git a/drivers/video/fb_defio.c b/drivers/video/fb_defio.c
index c3e57cc..8a66dc8 100644
--- a/drivers/video/fb_defio.c
+++ b/drivers/video/fb_defio.c
@@ -52,6 +52,18 @@ static void fb_deferred_io_work(struct work_struct *work)
mutex_unlock(fbdefio-lock);
}
+int fb_deferred_io_fsync(struct file *file, struct dentry *dentry, int
datasync)
+{
+ struct fb_info *info = file-private_data;
+
+ /* Kill off the delayed work */
+ cancel_rearming_delayed_work(info-deferred_work);
+
+ /* Run it immediately */
+ return schedule_delayed_work(info-deferred_work, 0);
+}
+EXPORT_SYMBOL_GPL(fb_deferred_io_fsync);
+
/* vm_ops-page_mkwrite handler */
int fb_deferred_io_mkwrite(struct vm_area_struct *vma,
struct page *page)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 863126a..69bbbe2 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1266,6 +1266,9 @@ static const struct file_operations fb_fops = {
#ifdef HAVE_ARCH_FB_UNMAPPED_AREA
.get_unmapped_area = get_fb_unmapped_area,
#endif
+#ifdef CONFIG_FB_DEFERRED_IO
+ .fsync =fb_deferred_io_fsync,
+#endif
};
struct class *fb_class;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index af217dd..3f62652 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -933,6 +933,8 @@ extern void fb_deferred_io_init(struct fb_info *info);
extern void fb_deferred_io_cleanup(struct fb_info *info);
extern int fb_deferred_io_mkwrite(struct vm_area_struct *vma,
struct page *page);
+extern int fb_deferred_io_fsync(struct file *file, struct dentry *dentry,
+ int datasync);
#else
#define fb_deferred_io_init(fb_info) do { } while (0)
#define fb_deferred_io_cleanup(fb_info)do { } while (0)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [RFC 2.6.20 1/1] fbdev, mm: Deferred IO and hecubafb driver
On Fri, 2007-02-23 at 07:32 +0100, Jaya Kumar wrote:
Hi Tony, Paul, Peter, fbdev, lkml, and mm,
This is a first pass at abstracting deferred IO out from hecubafb and
into fbdev as was discussed before:
http://marc.theaimsgroup.com/?l=linux-fbdev-develm=117187443327466w=2
Please let me know your feedback and if it looks okay so far.
Can you create 2 separate patches, one for the deferred_io and another
for the driver that uses it?
+Another one may be if one has a device framebuffer that is in an usual
format,
+say diagonally shifting RGB, this may then be a mechanism for you to allow
+apps to pretend to have a normal framebuffer but reswizzle for the device
+framebuffer at vsync time based on the touched pagelist.
Hmm, yes, it can be used to implement a shadow framebuffer :-)
+
+How to use it: (for applications)
+-
+No changes needed. mmap the framebuffer like normal and just use it.
+
+How to use it: (for fbdev drivers)
+--
+The following example may be helpful.
+
+1. Setup your mmap and vm_ops structures. Eg:
+
+
+The delay is the minimum delay between when the page_mkwrite trigger occurs
+and when the deferred_io callback is called. The deferred_io callback is
+explained below.
+
+static struct vm_operations_struct hecubafb_vm_ops = {
+ .nopage = hecubafb_vm_nopage,
+ .page_mkwrite = fb_deferred_io_mkwrite,
+};
+
It would seem to me that the above can be made generic, so we have this
instead:
static struct vm_operations_struct fb_deferred_vm_ops = {
.nopage = fb_deferred_io_vm_nopage,
.page_mkwrite = fb_deferred_io_mkwrite,
};
+You will need a nopage routine to find and retrive the struct page for your
+framebuffer pages. You must set page_mkwrite to fb_deferred_io_mkwrite.
+Here's the example nopage for hecubafb where it is a vmalloced framebuffer.
+
+static int hecubafb_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ vma-vm_ops = hecubafb_vm_ops;
+ vma-vm_flags |= ( VM_IO | VM_RESERVED | VM_DONTEXPAND );
+ vma-vm_private_data = info;
+ return 0;
+}
And this too as fb_deferred_io_mmap.
+
+static struct page* hecubafb_vm_nopage(struct vm_area_struct *vma,
+ unsigned long vaddr, int *type)
+{
+ unsigned long offset;
+ struct page *page;
+ struct fb_info *info = vma-vm_private_data;
+
+ offset = (vaddr - vma-vm_start) + (vma-vm_pgoff PAGE_SHIFT);
+ if (offset = (DPY_W*DPY_H)/8)
+ return NOPAGE_SIGBUS;
+
To make it generic, this can simply be:
if (offset = info-fix.smem_len)
return NOPAGE_SIGBUS.
+ page = vmalloc_to_page(info-screen_base + offset);
+ if (!page)
+ return NOPAGE_OOM;
+
+ get_page(page);
+ if (type)
+ *type = VM_FAULT_MINOR;
+ return page;
+}
+
+static struct fb_deferred_io hecubafb_defio = {
+ .delay = HZ,
+ .deferred_io= hecubafb_dpy_deferred_io,
+};
Leaving the drivers to just fill up the above. This would result in a
decrease of code duplication and it will be easier for driver writers.
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 2822526..863126a 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1325,6 +1325,7 @@ register_framebuffer(struct fb_info *fb_info)
event.info = fb_info;
fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, event);
+ fb_deferred_io_init(fb_info);
return 0;
}
@@ -1355,6 +1356,7 @@ unregister_framebuffer(struct fb_info *fb_info)
fb_destroy_modelist(fb_info-modelist);
registered_fb[i]=NULL;
num_registered_fb--;
+ fb_deferred_io_cleanup(fb_info);
fb_cleanup_device(fb_info);
device_destroy(fb_class, MKDEV(FB_MAJOR, i));
event.info = fb_info;
I would prefer to have the init and cleanup functions called by the
driver themselves, instead of piggy-backing them to the
framebuffer_register/unregister.
+static void hecubafb_dpy_update(struct hecubafb_par *par)
+{
+ int i;
+ unsigned char *buf = par-info-screen_base;
+
+ apollo_send_command(par, 0xA0);
+
+ for (i=0; i (DPY_W*DPY_H/8); i++) {
+ apollo_send_data(par, *(buf++));
+ }
+
This basically dumps the entire framebuffer to the hardware, doesn't it?
This framebuffer has only 2 pages at the most, so it doesn't matter. But
for hardware with MB's of RAM, I don't think this is feasible.
Is there a way to selectively update only the touched pages, ie from the
fbdevio-pagelist? struct page has a field (pgoff_t index), is this
usable? If not, can we just create a bit array, just to tell the driver
which are the dirty pages?
Tony
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[RFC 2.6.20 1/1] fbdev,mm: Deferred IO and hecubafb driver
Hi Tony, Paul, Peter, fbdev, lkml, and mm,
This is a first pass at abstracting deferred IO out from hecubafb and
into fbdev as was discussed before:
http://marc.theaimsgroup.com/?l=linux-fbdev-devel=117187443327466=2
Please let me know your feedback and if it looks okay so far.
Thanks,
jaya
Signed-off-by: Jaya Kumar <[EMAIL PROTECTED]>
---
Documentation/fb/deferred_io.txt | 114
drivers/video/Kconfig| 20 +
drivers/video/Makefile |2
drivers/video/fb_defio.c | 104 +++
drivers/video/fbmem.c|2
drivers/video/hecubafb.c | 513 +++
include/linux/fb.h | 25 +
mm/rmap.c|1
8 files changed, 781 insertions(+)
diff --git a/Documentation/fb/deferred_io.txt b/Documentation/fb/deferred_io.txt
new file mode 100644
index 000..be74dcc
--- /dev/null
+++ b/Documentation/fb/deferred_io.txt
@@ -0,0 +1,114 @@
+Deferred IO
+---
+
+Deferred IO is a way to delay and repurpose IO. It uses host memory as a
+buffer and the MMU pagefault as a pretrigger for when to perform the device
+IO. The following example may be a useful explaination of how one such setup
+works:
+
+- userspace app like Xfbdev mmaps framebuffer
+- deferred IO and driver sets up nopage and page_mkwrite handlers
+- userspace app tries to write to mmaped vaddress
+- we get pagefault and reach nopage handler
+- nopage handler finds and returns physical page
+- we get page_mkwrite where we add this page to a list
+- schedule a workqueue task to be run after a delay
+- app continues writing to that page with no additional cost. this is
+ the key benefit.
+- the workqueue task comes in and mkcleans the pages on the list, then
+ completes the work associated with updating the framebuffer. this is
+ the real work talking to the device.
+- app tries to write to the address (that has now been mkcleaned)
+- get pagefault and the above sequence occurs again
+
+As can be seen from above, one benefit is roughly to allow bursty framebuffer
+writes to occur at minimum cost. Then after some time when hopefully things
+have gone quiet, we go and really update the framebuffer which would be
+a relatively more expensive operation.
+
+For some types of nonvolatile high latency displays, the desired image is
+the final image rather than the intermediate stages which is why it's okay
+to not update for each write that is occuring.
+
+It may be the case that this is useful in other scenarios as well. Paul Mundt
+has mentioned a case where it is beneficial to use the page count to decide
+whether to coalesce and issue SG DMA or to do memory bursts.
+
+Another one may be if one has a device framebuffer that is in an usual format,
+say diagonally shifting RGB, this may then be a mechanism for you to allow
+apps to pretend to have a normal framebuffer but reswizzle for the device
+framebuffer at vsync time based on the touched pagelist.
+
+How to use it: (for applications)
+-
+No changes needed. mmap the framebuffer like normal and just use it.
+
+How to use it: (for fbdev drivers)
+--
+The following example may be helpful.
+
+1. Setup your mmap and vm_ops structures. Eg:
+
+static struct fb_deferred_io hecubafb_defio = {
+ .delay = HZ,
+ .deferred_io= hecubafb_dpy_deferred_io,
+};
+
+The delay is the minimum delay between when the page_mkwrite trigger occurs
+and when the deferred_io callback is called. The deferred_io callback is
+explained below.
+
+static struct vm_operations_struct hecubafb_vm_ops = {
+ .nopage = hecubafb_vm_nopage,
+ .page_mkwrite = fb_deferred_io_mkwrite,
+};
+
+You will need a nopage routine to find and retrive the struct page for your
+framebuffer pages. You must set page_mkwrite to fb_deferred_io_mkwrite.
+Here's the example nopage for hecubafb where it is a vmalloced framebuffer.
+
+static int hecubafb_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ vma->vm_ops = _vm_ops;
+ vma->vm_flags |= ( VM_IO | VM_RESERVED | VM_DONTEXPAND );
+ vma->vm_private_data = info;
+ return 0;
+}
+
+static struct page* hecubafb_vm_nopage(struct vm_area_struct *vma,
+ unsigned long vaddr, int *type)
+{
+ unsigned long offset;
+ struct page *page;
+ struct fb_info *info = vma->vm_private_data;
+
+ offset = (vaddr - vma->vm_start) + (vma->vm_pgoff << PAGE_SHIFT);
+ if (offset >= (DPY_W*DPY_H)/8)
+ return NOPAGE_SIGBUS;
+
+ page = vmalloc_to_page(info->screen_base + offset);
+ if (!page)
+ return NOPAGE_OOM;
+
+ get_page(page);
+ if (type)
+ *type = VM_FAULT_MINOR;
+ return page;
+}
+
+2. Setup your deferred IO callback. Eg:
+static void hecubafb_dpy_deferred_io(struct fb_info *info,
+ struct
[RFC 2.6.20 1/1] fbdev,mm: Deferred IO and hecubafb driver
Hi Tony, Paul, Peter, fbdev, lkml, and mm,
This is a first pass at abstracting deferred IO out from hecubafb and
into fbdev as was discussed before:
http://marc.theaimsgroup.com/?l=linux-fbdev-develm=117187443327466w=2
Please let me know your feedback and if it looks okay so far.
Thanks,
jaya
Signed-off-by: Jaya Kumar [EMAIL PROTECTED]
---
Documentation/fb/deferred_io.txt | 114
drivers/video/Kconfig| 20 +
drivers/video/Makefile |2
drivers/video/fb_defio.c | 104 +++
drivers/video/fbmem.c|2
drivers/video/hecubafb.c | 513 +++
include/linux/fb.h | 25 +
mm/rmap.c|1
8 files changed, 781 insertions(+)
diff --git a/Documentation/fb/deferred_io.txt b/Documentation/fb/deferred_io.txt
new file mode 100644
index 000..be74dcc
--- /dev/null
+++ b/Documentation/fb/deferred_io.txt
@@ -0,0 +1,114 @@
+Deferred IO
+---
+
+Deferred IO is a way to delay and repurpose IO. It uses host memory as a
+buffer and the MMU pagefault as a pretrigger for when to perform the device
+IO. The following example may be a useful explaination of how one such setup
+works:
+
+- userspace app like Xfbdev mmaps framebuffer
+- deferred IO and driver sets up nopage and page_mkwrite handlers
+- userspace app tries to write to mmaped vaddress
+- we get pagefault and reach nopage handler
+- nopage handler finds and returns physical page
+- we get page_mkwrite where we add this page to a list
+- schedule a workqueue task to be run after a delay
+- app continues writing to that page with no additional cost. this is
+ the key benefit.
+- the workqueue task comes in and mkcleans the pages on the list, then
+ completes the work associated with updating the framebuffer. this is
+ the real work talking to the device.
+- app tries to write to the address (that has now been mkcleaned)
+- get pagefault and the above sequence occurs again
+
+As can be seen from above, one benefit is roughly to allow bursty framebuffer
+writes to occur at minimum cost. Then after some time when hopefully things
+have gone quiet, we go and really update the framebuffer which would be
+a relatively more expensive operation.
+
+For some types of nonvolatile high latency displays, the desired image is
+the final image rather than the intermediate stages which is why it's okay
+to not update for each write that is occuring.
+
+It may be the case that this is useful in other scenarios as well. Paul Mundt
+has mentioned a case where it is beneficial to use the page count to decide
+whether to coalesce and issue SG DMA or to do memory bursts.
+
+Another one may be if one has a device framebuffer that is in an usual format,
+say diagonally shifting RGB, this may then be a mechanism for you to allow
+apps to pretend to have a normal framebuffer but reswizzle for the device
+framebuffer at vsync time based on the touched pagelist.
+
+How to use it: (for applications)
+-
+No changes needed. mmap the framebuffer like normal and just use it.
+
+How to use it: (for fbdev drivers)
+--
+The following example may be helpful.
+
+1. Setup your mmap and vm_ops structures. Eg:
+
+static struct fb_deferred_io hecubafb_defio = {
+ .delay = HZ,
+ .deferred_io= hecubafb_dpy_deferred_io,
+};
+
+The delay is the minimum delay between when the page_mkwrite trigger occurs
+and when the deferred_io callback is called. The deferred_io callback is
+explained below.
+
+static struct vm_operations_struct hecubafb_vm_ops = {
+ .nopage = hecubafb_vm_nopage,
+ .page_mkwrite = fb_deferred_io_mkwrite,
+};
+
+You will need a nopage routine to find and retrive the struct page for your
+framebuffer pages. You must set page_mkwrite to fb_deferred_io_mkwrite.
+Here's the example nopage for hecubafb where it is a vmalloced framebuffer.
+
+static int hecubafb_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ vma-vm_ops = hecubafb_vm_ops;
+ vma-vm_flags |= ( VM_IO | VM_RESERVED | VM_DONTEXPAND );
+ vma-vm_private_data = info;
+ return 0;
+}
+
+static struct page* hecubafb_vm_nopage(struct vm_area_struct *vma,
+ unsigned long vaddr, int *type)
+{
+ unsigned long offset;
+ struct page *page;
+ struct fb_info *info = vma-vm_private_data;
+
+ offset = (vaddr - vma-vm_start) + (vma-vm_pgoff PAGE_SHIFT);
+ if (offset = (DPY_W*DPY_H)/8)
+ return NOPAGE_SIGBUS;
+
+ page = vmalloc_to_page(info-screen_base + offset);
+ if (!page)
+ return NOPAGE_OOM;
+
+ get_page(page);
+ if (type)
+ *type = VM_FAULT_MINOR;
+ return page;
+}
+
+2. Setup your deferred IO callback. Eg:
+static void hecubafb_dpy_deferred_io(struct fb_info *info,
+ struct
