Re: [PATCH 2/3] fbdev: Make deferred I/O work as advertized
On Tue, Feb 26, 2008 at 9:45 AM, Markus Armbruster <[EMAIL PROTECTED]> wrote: > > What about pushing the fb_defio fixes independently of any new > fb_defio users? If fb_defio was worth merging into Linus's tree, it > should be worth fixing there, whether new users are in shape already > or not. I think that Andrew's message is saying that there may be a race condition in the defio patch itself as opposed to the defio user patch. If there is no race condition or other problems, then I think it would make sense to merge the defio patch independent of metronomefb or other new patches that use defio. 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: [PATCH 2/3] fbdev: Make deferred I/O work as advertized
On Mon, Feb 25, 2008 at 8:03 AM, Markus Armbruster <[EMAIL PROTECTED]> wrote: > > Subject: [PATCH 1/1 2.6.24] fbdev: defio and Metronomefb > From: Jaya Kumar <[EMAIL PROTECTED]> > Date: 2008-02-18 13:41:26 Hi Markus, Andrew pointed out that there may be race conditions associated with this patch. [ http://marc.info/?l=linux-fbdev-devel=120376473020396=2 ] So I would not encourage anyone to merge it. I'll try to figure things out this weekend. 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: [PATCH 2/3] fbdev: Make deferred I/O work as advertized
On Mon, Feb 25, 2008 at 8:03 AM, Markus Armbruster [EMAIL PROTECTED] wrote: Subject: [PATCH 1/1 2.6.24] fbdev: defio and Metronomefb From: Jaya Kumar [EMAIL PROTECTED] Date: 2008-02-18 13:41:26 Hi Markus, Andrew pointed out that there may be race conditions associated with this patch. [ http://marc.info/?l=linux-fbdev-develm=120376473020396w=2 ] So I would not encourage anyone to merge it. I'll try to figure things out this weekend. 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: [PATCH 2/3] fbdev: Make deferred I/O work as advertized
On Tue, Feb 26, 2008 at 9:45 AM, Markus Armbruster [EMAIL PROTECTED] wrote: What about pushing the fb_defio fixes independently of any new fb_defio users? If fb_defio was worth merging into Linus's tree, it should be worth fixing there, whether new users are in shape already or not. I think that Andrew's message is saying that there may be a race condition in the defio patch itself as opposed to the defio user patch. If there is no race condition or other problems, then I think it would make sense to merge the defio patch independent of metronomefb or other new patches that use defio. 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: [PATCH 2/2] xen pvfb: Para-virtual framebuffer, keyboard and pointer driver
On Thu, Feb 21, 2008 at 5:43 PM, Markus Armbruster <[EMAIL PROTECTED]> wrote: > +config XEN_FBDEV_FRONTEND > + select FB_DEFERRED_IO Groovy. :-) 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: [PATCH 1/2] fbdev: Make deferred I/O work as advertized
On Thu, Feb 21, 2008 at 5:43 PM, Markus Armbruster <[EMAIL PROTECTED]> wrote:
> Fix extracted from this linux-fbdev-devel message:
Hi Markus,
Yes, this was discussed back in November on linux-mm and hence my
patch. I didn't push for it to be merged by itself because I don't
think it makes sense to merge it separately from the full metronomefb
patch. As far as I can tell, only hecubafb and metronomefb seem to be
the consumers.
Out of curiosity, are you using defio or planning to use it? I would
love to hear back from people who are using it.
Thanks,
jaya
>
> Subject: [PATCH 1/1 2.6.24] fbdev: defio and Metronomefb
> From: Jaya Kumar <[EMAIL PROTECTED]>
> Date: 2008-02-18 13:41:26
>
> Signed-off-by: Jaya Kumar <[EMAIL PROTECTED]>
> Signed-off-by: Markus Armbruster <[EMAIL PROTECTED]>
>
> ---
>
> drivers/video/fb_defio.c | 22 --
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fb_defio.c b/drivers/video/fb_defio.c
> index 0f8cfb9..24843fd 100644
> --- a/drivers/video/fb_defio.c
> +++ b/drivers/video/fb_defio.c
> @@ -4,7 +4,7 @@
> * Copyright (C) 2006 Jaya Kumar
> *
> * This file is subject to the terms and conditions of the GNU General Public
> - * License. See the file COPYING in the main directory of this archive
> + * License. See the file COPYING in the main directory of this archive
> * for more details.
> */
>
> @@ -31,7 +31,7 @@ static int fb_deferred_io_fault(struct vm_area_struct *vma,
> unsigned long offset;
> struct page *page;
> struct fb_info *info = vma->vm_private_data;
> - /* info->screen_base is in System RAM */
> + /* info->screen_base is virtual memory */
> void *screen_base = (void __force *) info->screen_base;
>
> offset = vmf->pgoff << PAGE_SHIFT;
> @@ -43,6 +43,15 @@ static int fb_deferred_io_fault(struct vm_area_struct
> *vma,
> return VM_FAULT_SIGBUS;
>
> get_page(page);
> +
> + if (vma->vm_file)
> + page->mapping = vma->vm_file->f_mapping;
> + else
> + printk(KERN_ERR "no mapping available\n");
> +
> + BUG_ON(!page->mapping);
> + page->index = vmf->pgoff;
> +
> vmf->page = page;
> return 0;
> }
> @@ -138,11 +147,20 @@ EXPORT_SYMBOL_GPL(fb_deferred_io_init);
>
> void fb_deferred_io_cleanup(struct fb_info *info)
> {
> + void *screen_base = (void __force *) info->screen_base;
> struct fb_deferred_io *fbdefio = info->fbdefio;
> + struct page *page;
> + int i;
>
> BUG_ON(!fbdefio);
> cancel_delayed_work(>deferred_work);
> flush_scheduled_work();
> +
> + /* clear out the mapping that we setup */
> + for (i = 0 ; i < info->fix.smem_len; i += PAGE_SIZE) {
> + page = vmalloc_to_page(screen_base + i);
> + page->mapping = NULL;
> + }
> }
> EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
>
>
--
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: [PATCH 1/2] fbdev: Make deferred I/O work as advertized
On Thu, Feb 21, 2008 at 5:43 PM, Markus Armbruster [EMAIL PROTECTED] wrote:
Fix extracted from this linux-fbdev-devel message:
Hi Markus,
Yes, this was discussed back in November on linux-mm and hence my
patch. I didn't push for it to be merged by itself because I don't
think it makes sense to merge it separately from the full metronomefb
patch. As far as I can tell, only hecubafb and metronomefb seem to be
the consumers.
Out of curiosity, are you using defio or planning to use it? I would
love to hear back from people who are using it.
Thanks,
jaya
Subject: [PATCH 1/1 2.6.24] fbdev: defio and Metronomefb
From: Jaya Kumar [EMAIL PROTECTED]
Date: 2008-02-18 13:41:26
Signed-off-by: Jaya Kumar [EMAIL PROTECTED]
Signed-off-by: Markus Armbruster [EMAIL PROTECTED]
---
drivers/video/fb_defio.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fb_defio.c b/drivers/video/fb_defio.c
index 0f8cfb9..24843fd 100644
--- a/drivers/video/fb_defio.c
+++ b/drivers/video/fb_defio.c
@@ -4,7 +4,7 @@
* Copyright (C) 2006 Jaya Kumar
*
* This file is subject to the terms and conditions of the GNU General Public
- * License. See the file COPYING in the main directory of this archive
+ * License. See the file COPYING in the main directory of this archive
* for more details.
*/
@@ -31,7 +31,7 @@ static int fb_deferred_io_fault(struct vm_area_struct *vma,
unsigned long offset;
struct page *page;
struct fb_info *info = vma-vm_private_data;
- /* info-screen_base is in System RAM */
+ /* info-screen_base is virtual memory */
void *screen_base = (void __force *) info-screen_base;
offset = vmf-pgoff PAGE_SHIFT;
@@ -43,6 +43,15 @@ static int fb_deferred_io_fault(struct vm_area_struct
*vma,
return VM_FAULT_SIGBUS;
get_page(page);
+
+ if (vma-vm_file)
+ page-mapping = vma-vm_file-f_mapping;
+ else
+ printk(KERN_ERR no mapping available\n);
+
+ BUG_ON(!page-mapping);
+ page-index = vmf-pgoff;
+
vmf-page = page;
return 0;
}
@@ -138,11 +147,20 @@ EXPORT_SYMBOL_GPL(fb_deferred_io_init);
void fb_deferred_io_cleanup(struct fb_info *info)
{
+ void *screen_base = (void __force *) info-screen_base;
struct fb_deferred_io *fbdefio = info-fbdefio;
+ struct page *page;
+ int i;
BUG_ON(!fbdefio);
cancel_delayed_work(info-deferred_work);
flush_scheduled_work();
+
+ /* clear out the mapping that we setup */
+ for (i = 0 ; i info-fix.smem_len; i += PAGE_SIZE) {
+ page = vmalloc_to_page(screen_base + i);
+ page-mapping = NULL;
+ }
}
EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
--
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: [PATCH 2/2] xen pvfb: Para-virtual framebuffer, keyboard and pointer driver
On Thu, Feb 21, 2008 at 5:43 PM, Markus Armbruster [EMAIL PROTECTED] wrote: +config XEN_FBDEV_FRONTEND + select FB_DEFERRED_IO Groovy. :-) 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 1/1 2.6.22.10] fbdev: defio and Metronomefb
On Nov 4, 2007 5:24 AM, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: > On Sat, 3 Nov 2007, Jaya Kumar wrote: > > + interface. Please read > > Documentation/fb/metronomefb.txt is missing? Oops. I forgot to write that document. Ok, will do. 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 1/1 2.6.22.10] fbdev: defio and Metronomefb
On Nov 4, 2007 5:24 AM, Geert Uytterhoeven [EMAIL PROTECTED] wrote: On Sat, 3 Nov 2007, Jaya Kumar wrote: + interface. Please read file:Documentation/fb/metronomefb.txt Documentation/fb/metronomefb.txt is missing? Oops. I forgot to write that document. Ok, will do. 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: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
On Oct 30, 2007 11:47 AM, Hugh Dickins <[EMAIL PROTECTED]> wrote: > > I don't understand why you suggested an anon_vma, nor why Jaya is > suggesting a private list. All vmas mapping /dev/fb0 will be kept > in the prio_tree rooted in its struct address_space (__vma_link_file > in mm/mmap.c). And page_mkclean gets page_mkclean_file to walk that > very tree. The missing part is just the setting of page->mapping to > point to that struct address_space (and clearing it before finally > freeing the pages), and the setting of page->index as you described. > Isn't it? Oops, sorry that I missed that. Now I understand. I think: page->mapping = vma->vm_file->f_mapping page->index = ((addr - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff at nopage time and then before the driver vfrees, I'll clear mapping for all those pages. 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: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
On Oct 30, 2007 11:47 AM, Hugh Dickins [EMAIL PROTECTED] wrote: I don't understand why you suggested an anon_vma, nor why Jaya is suggesting a private list. All vmas mapping /dev/fb0 will be kept in the prio_tree rooted in its struct address_space (__vma_link_file in mm/mmap.c). And page_mkclean gets page_mkclean_file to walk that very tree. The missing part is just the setting of page-mapping to point to that struct address_space (and clearing it before finally freeing the pages), and the setting of page-index as you described. Isn't it? Oops, sorry that I missed that. Now I understand. I think: page-mapping = vma-vm_file-f_mapping page-index = ((addr - vma-vm_start) PAGE_SHIFT) + vma-vm_pgoff at nopage time and then before the driver vfrees, I'll clear mapping for all those pages. 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: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
On 10/30/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> So page->index does what you want it to, identify which part of the
> framebuffer this particular page belongs to.
Ok. I'm attempting to walk the code sequence. Here's what I think:
- driver loads
- driver vmalloc()s its fb
- this creates the necessary pte entries
then...
- app mmap(/dev/fb0)
- vma is created
- defio mmap adds this vma to private list (equivalent of
address_space or anon_vma)
- app touches base + pixel(128,128) = base + 16k
- page fault
- defio nopage gets called
- defio nopage does vmalloc_to_page(base+16k)
- that finds the correct struct page corresponding to that vaddr.
page->index has not been set by anyone so far, right?
* ah... i see, you are suggesting that this is where I could set the
index since i know the offset i want it to represent. right?
- defio mkwrite get called. defio adds page to its list. schedules delayed work
- app keeps writing the page
- delayed work occurs
- foreach vma { foreach page { page_mkclean_one(page, vma) }
- cycle repeats...
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: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
On 10/30/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
So page-index does what you want it to, identify which part of the
framebuffer this particular page belongs to.
Ok. I'm attempting to walk the code sequence. Here's what I think:
- driver loads
- driver vmalloc()s its fb
- this creates the necessary pte entries
then...
- app mmap(/dev/fb0)
- vma is created
- defio mmap adds this vma to private list (equivalent of
address_space or anon_vma)
- app touches base + pixel(128,128) = base + 16k
- page fault
- defio nopage gets called
- defio nopage does vmalloc_to_page(base+16k)
- that finds the correct struct page corresponding to that vaddr.
page-index has not been set by anyone so far, right?
* ah... i see, you are suggesting that this is where I could set the
index since i know the offset i want it to represent. right?
- defio mkwrite get called. defio adds page to its list. schedules delayed work
- app keeps writing the page
- delayed work occurs
- foreach vma { foreach page { page_mkclean_one(page, vma) }
- cycle repeats...
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: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
On 10/29/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > [ also, remap_vmalloc_range() suffers similar issues, only file and anon > have proper rmap ] > > I'm not sure we want full rmap for remap_pfn/vmalloc_range, but perhaps > we could assist drivers in maintaining and using vma lists. > > I think page_mkclean_one() would work if you'd manually set page->index > and iterate the vmas yourself. Although atm I'm not sure of anything so > don't pin me on it. :-) If it's anybody's fault, it's mine for not testing properly. My bad. In the case of defio, I think it's no trouble to build a list of vmas at mmap time and then to iterate through them when it's ready for mkclean time as you suggested. I don't fully understand page->index yet. I had thought it was only used by swap cache or file map. On an unrelated note, I was looking for somewhere to stuff a 16 bit offset (so that I have a cheap way to know which struct page corresponds to which framebuffer block or offset) for another driver. I had thought page->index was it but I think I am wrong now. 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: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
On 10/29/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote: > On Mon, 2007-10-29 at 01:17 -0700, Jaya Kumar wrote: > > An aside, I just tested that deferred IO works fine on 2.6.22.10/pxa255. > > > > I understood from the thread that PeterZ is looking into page_mkclean > > changes which I guess went into 2.6.23. I'm also happy to help in any > > way if the way we're doing fb_defio needs to change. > > OK, seems I can't read. Or at least, I missed a large part of the > problem. > > page_mkclean() hasn't changed, it was ->page_mkwrite() that changed. And > looking at the fb_defio code, I'm not sure I understand how its > page_mkclean() use could ever have worked. > > The proposed patch [1] only fixes the issue of ->page_mkwrite() on > vmalloc()'ed memory. Not page_mkclean(), and that has never worked from > what I can make of it. > > Jaya, could you shed some light on this? I presume you had your display > working. > I thought I had it working. I saw the display update after each mmap/write sequence to the framebuffer. I need to check if there's an munmap or anything else going on in between write sequences that would cause it to behave like page_mkclean was working. Is it correct to assume that page_mkclean should mark the pages read-only so that the next write would again trigger mkwrite? Even if the page was from a vmalloc_to_page()? 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: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
On 10/29/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Mon, 22 Oct 2007 16:40:57 +0200 Stefani Seibold <[EMAIL PROTECTED]> wrote: > > > > The problem original occurs with the fb_defio driver > > (driver/video/fb_defio.c). > > This driver use the vm_ops.page_mkwrite() handler for tracking the modified > > pages, > > which will be in an extra thread handled, to perform the IO and clean and > > write protect all pages with page_clean(). > > Hi, An aside, I just tested that deferred IO works fine on 2.6.22.10/pxa255. I understood from the thread that PeterZ is looking into page_mkclean changes which I guess went into 2.6.23. I'm also happy to help in any way if the way we're doing fb_defio needs to change. 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: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
On 10/29/07, Andrew Morton [EMAIL PROTECTED] wrote: On Mon, 22 Oct 2007 16:40:57 +0200 Stefani Seibold [EMAIL PROTECTED] wrote: The problem original occurs with the fb_defio driver (driver/video/fb_defio.c). This driver use the vm_ops.page_mkwrite() handler for tracking the modified pages, which will be in an extra thread handled, to perform the IO and clean and write protect all pages with page_clean(). Hi, An aside, I just tested that deferred IO works fine on 2.6.22.10/pxa255. I understood from the thread that PeterZ is looking into page_mkclean changes which I guess went into 2.6.23. I'm also happy to help in any way if the way we're doing fb_defio needs to change. 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: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
On 10/29/07, Peter Zijlstra [EMAIL PROTECTED] wrote: On Mon, 2007-10-29 at 01:17 -0700, Jaya Kumar wrote: An aside, I just tested that deferred IO works fine on 2.6.22.10/pxa255. I understood from the thread that PeterZ is looking into page_mkclean changes which I guess went into 2.6.23. I'm also happy to help in any way if the way we're doing fb_defio needs to change. OK, seems I can't read. Or at least, I missed a large part of the problem. page_mkclean() hasn't changed, it was -page_mkwrite() that changed. And looking at the fb_defio code, I'm not sure I understand how its page_mkclean() use could ever have worked. The proposed patch [1] only fixes the issue of -page_mkwrite() on vmalloc()'ed memory. Not page_mkclean(), and that has never worked from what I can make of it. Jaya, could you shed some light on this? I presume you had your display working. I thought I had it working. I saw the display update after each mmap/write sequence to the framebuffer. I need to check if there's an munmap or anything else going on in between write sequences that would cause it to behave like page_mkclean was working. Is it correct to assume that page_mkclean should mark the pages read-only so that the next write would again trigger mkwrite? Even if the page was from a vmalloc_to_page()? 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: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
On 10/29/07, Peter Zijlstra [EMAIL PROTECTED] wrote: [ also, remap_vmalloc_range() suffers similar issues, only file and anon have proper rmap ] I'm not sure we want full rmap for remap_pfn/vmalloc_range, but perhaps we could assist drivers in maintaining and using vma lists. I think page_mkclean_one() would work if you'd manually set page-index and iterate the vmas yourself. Although atm I'm not sure of anything so don't pin me on it. :-) If it's anybody's fault, it's mine for not testing properly. My bad. In the case of defio, I think it's no trouble to build a list of vmas at mmap time and then to iterate through them when it's ready for mkclean time as you suggested. I don't fully understand page-index yet. I had thought it was only used by swap cache or file map. On an unrelated note, I was looking for somewhere to stuff a 16 bit offset (so that I have a cheap way to know which struct page corresponds to which framebuffer block or offset) for another driver. I had thought page-index was it but I think I am wrong now. 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: [PATCH 0/5] ALSA: cs5535audio fixes
On 8/29/07, Andres Salomon <[EMAIL PROTECTED]> wrote: > Hi, > > Here are a bunch of fixes for the cs5535audio driver. None of these are > OLPC specific; generic chip and power management fixes, and one cleanup > patch. All have been tested on an OLPC (5536), so even though the 5535 > data sheet claims to be the same, it would be nice to hear success/failure > reports from someone with a 5535. The patches look good. I'm traveling till Sep 2nd so can't test on 5535 yet. Thanks very much for your efforts Andres. Thanks, jaya Acked-by: Jaya Kumar <[EMAIL PROTECTED]> - 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: [PATCH 0/5] ALSA: cs5535audio fixes
On 8/29/07, Andres Salomon [EMAIL PROTECTED] wrote: Hi, Here are a bunch of fixes for the cs5535audio driver. None of these are OLPC specific; generic chip and power management fixes, and one cleanup patch. All have been tested on an OLPC (5536), so even though the 5535 data sheet claims to be the same, it would be nice to hear success/failure reports from someone with a 5535. The patches look good. I'm traveling till Sep 2nd so can't test on 5535 yet. Thanks very much for your efforts Andres. Thanks, jaya Acked-by: Jaya Kumar [EMAIL PROTECTED] - 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: [PATCH/RFC 2.6.20 1/2] fbdev, mm: Deferred IO support
On 3/1/07, Paul Mundt <[EMAIL PROTECTED]> wrote: On Sun, Feb 25, 2007 at 06:13:12AM +0100, Jaya Kumar wrote: > This patch implements deferred IO support in fbdev. Deferred IO is a way to > delay and repurpose IO. This implementation is done using mm's page_mkwrite > and page_mkclean hooks in order to detect, delay and then rewrite IO. This > functionality is used by hecubafb. > Any updates on this? If there are no other concerns, it would be nice to at least get this in to -mm for testing if nothing else. I think Andrew merged it into -mm. Jaya, can you roll the fsync() patch in to your defio patch? There's not much point in keeping them separate. I forgot to add that. Sorry about that. Should I resubmit with it or would you prefer to post it? 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: [PATCH/RFC 2.6.20 1/2] fbdev, mm: Deferred IO support
On 3/1/07, Paul Mundt [EMAIL PROTECTED] wrote: On Sun, Feb 25, 2007 at 06:13:12AM +0100, Jaya Kumar wrote: This patch implements deferred IO support in fbdev. Deferred IO is a way to delay and repurpose IO. This implementation is done using mm's page_mkwrite and page_mkclean hooks in order to detect, delay and then rewrite IO. This functionality is used by hecubafb. Any updates on this? If there are no other concerns, it would be nice to at least get this in to -mm for testing if nothing else. I think Andrew merged it into -mm. Jaya, can you roll the fsync() patch in to your defio patch? There's not much point in keeping them separate. I forgot to add that. Sorry about that. Should I resubmit with it or would you prefer to post it? 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/
[PATCH/RFC 2.6.20 2/2] fbdev: Hecuba fb driver
This patch implements support for the E-Ink/hecuba display device. It uses
deferred IO support.
Thanks,
jaya
Signed-off-by: Jaya Kumar <[EMAIL PROTECTED]>
---
hecubafb.c | 480 +
1 file changed, 480 insertions(+)
---
diff --git a/drivers/video/hecubafb.c b/drivers/video/hecubafb.c
new file mode 100644
index 000..9944bee
--- /dev/null
+++ b/drivers/video/hecubafb.c
@@ -0,0 +1,480 @@
+/*
+ * linux/drivers/video/hecubafb.c -- FB driver for Hecuba controller
+ *
+ * Copyright (C) 2006, Jaya Kumar
+ * This work was sponsored by CIS(M) Sdn Bhd
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ *
+ * Layout is based on skeletonfb.c by James Simmons and Geert Uytterhoeven.
+ * This work was possible because of apollo display code from E-Ink's website
+ * http://support.eink.com/community
+ * All information used to write this code is from public material made
+ * available by E-Ink on its support site. Some commands such as 0xA4
+ * were found by looping through cmd=0x00 thru 0xFF and supplying random
+ * values. There are other commands that the display is capable of,
+ * beyond the 5 used here but they are more complex.
+ *
+ * This driver is written to be used with the Hecuba display controller
+ * board, and tested with the EInk 800x600 display in 1 bit mode.
+ * The interface between Hecuba and the host is TTL based GPIO. The
+ * GPIO requirements are 8 writable data lines and 6 lines for control.
+ * Only 4 of the controls are actually used here but 6 for future use.
+ * The driver requires the IO addresses for data and control GPIO at
+ * load time. It is also possible to use this display with a standard
+ * PC parallel port.
+ *
+ * General notes:
+ * - User must set hecubafb_enable=1 to enable it
+ * - User must set dio_addr=0xIOADDR cio_addr=0xIOADDR c2io_addr=0xIOADDR
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Apollo controller specific defines */
+#define APOLLO_START_NEW_IMG 0xA0
+#define APOLLO_STOP_IMG_DATA 0xA1
+#define APOLLO_DISPLAY_IMG 0xA2
+#define APOLLO_ERASE_DISPLAY 0xA3
+#define APOLLO_INIT_DISPLAY0xA4
+
+/* Hecuba interface specific defines */
+/* WUP is inverted, CD is inverted, DS is inverted */
+#define HCB_NWUP_BIT 0x01
+#define HCB_NDS_BIT0x02
+#define HCB_RW_BIT 0x04
+#define HCB_NCD_BIT0x08
+#define HCB_ACK_BIT0x80
+
+/* Display specific information */
+#define DPY_W 600
+#define DPY_H 800
+
+struct hecubafb_par {
+ unsigned long dio_addr;
+ unsigned long cio_addr;
+ unsigned long c2io_addr;
+ unsigned char ctl;
+ struct fb_info *info;
+ unsigned int irq;
+};
+
+static struct fb_fix_screeninfo hecubafb_fix __initdata = {
+ .id = "hecubafb",
+ .type = FB_TYPE_PACKED_PIXELS,
+ .visual = FB_VISUAL_MONO01,
+ .xpanstep = 0,
+ .ypanstep = 0,
+ .ywrapstep =0,
+ .accel =FB_ACCEL_NONE,
+};
+
+static struct fb_var_screeninfo hecubafb_var __initdata = {
+ .xres = DPY_W,
+ .yres = DPY_H,
+ .xres_virtual = DPY_W,
+ .yres_virtual = DPY_H,
+ .bits_per_pixel = 1,
+ .nonstd = 1,
+};
+
+static unsigned long dio_addr;
+static unsigned long cio_addr;
+static unsigned long c2io_addr;
+static unsigned long splashval;
+static unsigned int nosplash;
+static unsigned int hecubafb_enable;
+static unsigned int irq;
+
+static DECLARE_WAIT_QUEUE_HEAD(hecubafb_waitq);
+
+static void hcb_set_ctl(struct hecubafb_par *par)
+{
+ outb(par->ctl, par->cio_addr);
+}
+
+static unsigned char hcb_get_ctl(struct hecubafb_par *par)
+{
+ return inb(par->c2io_addr);
+}
+
+static void hcb_set_data(struct hecubafb_par *par, unsigned char value)
+{
+ outb(value, par->dio_addr);
+}
+
+static int __devinit apollo_init_control(struct hecubafb_par *par)
+{
+ unsigned char ctl;
+ /* for init, we want the following setup to be set:
+ WUP = lo
+ ACK = hi
+ DS = hi
+ RW = hi
+ CD = lo
+ */
+
+ /* write WUP to lo, DS to hi, RW to hi, CD to lo */
+ par->ctl = HCB_NWUP_BIT | HCB_RW_BIT | HCB_NCD_BIT ;
+ par->ctl &= ~HCB_NDS_BIT;
+ hcb_set_ctl(par);
+
+ /* check ACK is not lo */
+ ctl = hcb_get_ctl(par);
+ if ((ctl & HCB_ACK_BIT)) {
+ printk(KERN_ERR "Fail because ACK is already low\n");
+ return -ENXIO;
+ }
+
+ return 0;
+}
+
+void hcb_wait_for_ack(struct hecubafb_par *par)
+{
+
+ int timeout;
+ unsigned char ctl;
+
+ timeout=500;
+ do {
+ ctl = hcb_
[PATCH/RFC 2.6.20 1/2] fbdev, mm: Deferred IO support
This patch implements deferred IO support in fbdev. Deferred IO is a way to
delay and repurpose IO. This implementation is done using mm's page_mkwrite
and page_mkclean hooks in order to detect, delay and then rewrite IO. This
functionality is used by hecubafb.
Thanks,
jaya
Signed-off-by: Jaya Kumar <[EMAIL PROTECTED]>
---
Documentation/fb/deferred_io.txt | 75 +
drivers/video/Kconfig| 20 +
drivers/video/Makefile |2
drivers/video/fb_defio.c | 137 +++
include/linux/fb.h | 20 +
mm/rmap.c|1
6 files changed, 255 insertions(+)
---
diff --git a/Documentation/fb/deferred_io.txt b/Documentation/fb/deferred_io.txt
new file mode 100644
index 000..838c1a3
--- /dev/null
+++ b/Documentation/fb/deferred_io.txt
@@ -0,0 +1,75 @@
+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 structure. 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.
+
+2. Setup your deferred IO callback. Eg:
+static void hecubafb_dpy_deferred_io(struct fb_info *info,
+ struct list_head *pagelist)
+
+The deferred_io callback is where you would perform all your IO to the display
+device. You receive the pagelist which is the list of pages that were written
+to during the delay. You must not modify this list. This callback is called
+from a workqueue.
+
+3. Call init
+ info->fbdefio = _defio;
+ fb_deferred_io_init(info);
+
+4. Call cleanup
+ fb_deferred_io_cleanup(info);
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 8874cf2..a03c772 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -85,6 +85,12 @@ config FB_CFB_IMAGEBLIT
blitting. This is used by drivers that don't provide their own
(accelerated) version.
+# used by hecubafb
+config FB_DEFERRED_IO
+ bool
+ depends on FB
+ default n
+
config FB_SVGALIB
tristate
depends on FB
@@ -540,6 +546,20 @@ config FB_IMAC
help
This is the frame buffer device driver for the Intel-based Macintosh
+config FB_HECUBA
+ tristate "Hecuba board support"
+ depends on FB && X86 && MMU
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ select FB_DEFERRED_IO
+ help
+ This enables support for the Hecuba board. This driver was tested
+ wi
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/
[PATCH/RFC 2.6.20 1/2] fbdev, mm: Deferred IO support
This patch implements deferred IO support in fbdev. Deferred IO is a way to
delay and repurpose IO. This implementation is done using mm's page_mkwrite
and page_mkclean hooks in order to detect, delay and then rewrite IO. This
functionality is used by hecubafb.
Thanks,
jaya
Signed-off-by: Jaya Kumar [EMAIL PROTECTED]
---
Documentation/fb/deferred_io.txt | 75 +
drivers/video/Kconfig| 20 +
drivers/video/Makefile |2
drivers/video/fb_defio.c | 137 +++
include/linux/fb.h | 20 +
mm/rmap.c|1
6 files changed, 255 insertions(+)
---
diff --git a/Documentation/fb/deferred_io.txt b/Documentation/fb/deferred_io.txt
new file mode 100644
index 000..838c1a3
--- /dev/null
+++ b/Documentation/fb/deferred_io.txt
@@ -0,0 +1,75 @@
+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 structure. 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.
+
+2. Setup your deferred IO callback. Eg:
+static void hecubafb_dpy_deferred_io(struct fb_info *info,
+ struct list_head *pagelist)
+
+The deferred_io callback is where you would perform all your IO to the display
+device. You receive the pagelist which is the list of pages that were written
+to during the delay. You must not modify this list. This callback is called
+from a workqueue.
+
+3. Call init
+ info-fbdefio = hecubafb_defio;
+ fb_deferred_io_init(info);
+
+4. Call cleanup
+ fb_deferred_io_cleanup(info);
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 8874cf2..a03c772 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -85,6 +85,12 @@ config FB_CFB_IMAGEBLIT
blitting. This is used by drivers that don't provide their own
(accelerated) version.
+# used by hecubafb
+config FB_DEFERRED_IO
+ bool
+ depends on FB
+ default n
+
config FB_SVGALIB
tristate
depends on FB
@@ -540,6 +546,20 @@ config FB_IMAC
help
This is the frame buffer device driver for the Intel-based Macintosh
+config FB_HECUBA
+ tristate Hecuba board support
+ depends on FB X86 MMU
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ select FB_DEFERRED_IO
+ help
+ This enables support for the Hecuba board. This driver was tested
+ with an E-Ink 800x600 display and x86
[PATCH/RFC 2.6.20 2/2] fbdev: Hecuba fb driver
This patch implements support for the E-Ink/hecuba display device. It uses
deferred IO support.
Thanks,
jaya
Signed-off-by: Jaya Kumar [EMAIL PROTECTED]
---
hecubafb.c | 480 +
1 file changed, 480 insertions(+)
---
diff --git a/drivers/video/hecubafb.c b/drivers/video/hecubafb.c
new file mode 100644
index 000..9944bee
--- /dev/null
+++ b/drivers/video/hecubafb.c
@@ -0,0 +1,480 @@
+/*
+ * linux/drivers/video/hecubafb.c -- FB driver for Hecuba controller
+ *
+ * Copyright (C) 2006, Jaya Kumar
+ * This work was sponsored by CIS(M) Sdn Bhd
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ *
+ * Layout is based on skeletonfb.c by James Simmons and Geert Uytterhoeven.
+ * This work was possible because of apollo display code from E-Ink's website
+ * http://support.eink.com/community
+ * All information used to write this code is from public material made
+ * available by E-Ink on its support site. Some commands such as 0xA4
+ * were found by looping through cmd=0x00 thru 0xFF and supplying random
+ * values. There are other commands that the display is capable of,
+ * beyond the 5 used here but they are more complex.
+ *
+ * This driver is written to be used with the Hecuba display controller
+ * board, and tested with the EInk 800x600 display in 1 bit mode.
+ * The interface between Hecuba and the host is TTL based GPIO. The
+ * GPIO requirements are 8 writable data lines and 6 lines for control.
+ * Only 4 of the controls are actually used here but 6 for future use.
+ * The driver requires the IO addresses for data and control GPIO at
+ * load time. It is also possible to use this display with a standard
+ * PC parallel port.
+ *
+ * General notes:
+ * - User must set hecubafb_enable=1 to enable it
+ * - User must set dio_addr=0xIOADDR cio_addr=0xIOADDR c2io_addr=0xIOADDR
+ *
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/string.h
+#include linux/mm.h
+#include linux/slab.h
+#include linux/vmalloc.h
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/fb.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/list.h
+#include asm/uaccess.h
+
+/* Apollo controller specific defines */
+#define APOLLO_START_NEW_IMG 0xA0
+#define APOLLO_STOP_IMG_DATA 0xA1
+#define APOLLO_DISPLAY_IMG 0xA2
+#define APOLLO_ERASE_DISPLAY 0xA3
+#define APOLLO_INIT_DISPLAY0xA4
+
+/* Hecuba interface specific defines */
+/* WUP is inverted, CD is inverted, DS is inverted */
+#define HCB_NWUP_BIT 0x01
+#define HCB_NDS_BIT0x02
+#define HCB_RW_BIT 0x04
+#define HCB_NCD_BIT0x08
+#define HCB_ACK_BIT0x80
+
+/* Display specific information */
+#define DPY_W 600
+#define DPY_H 800
+
+struct hecubafb_par {
+ unsigned long dio_addr;
+ unsigned long cio_addr;
+ unsigned long c2io_addr;
+ unsigned char ctl;
+ struct fb_info *info;
+ unsigned int irq;
+};
+
+static struct fb_fix_screeninfo hecubafb_fix __initdata = {
+ .id = hecubafb,
+ .type = FB_TYPE_PACKED_PIXELS,
+ .visual = FB_VISUAL_MONO01,
+ .xpanstep = 0,
+ .ypanstep = 0,
+ .ywrapstep =0,
+ .accel =FB_ACCEL_NONE,
+};
+
+static struct fb_var_screeninfo hecubafb_var __initdata = {
+ .xres = DPY_W,
+ .yres = DPY_H,
+ .xres_virtual = DPY_W,
+ .yres_virtual = DPY_H,
+ .bits_per_pixel = 1,
+ .nonstd = 1,
+};
+
+static unsigned long dio_addr;
+static unsigned long cio_addr;
+static unsigned long c2io_addr;
+static unsigned long splashval;
+static unsigned int nosplash;
+static unsigned int hecubafb_enable;
+static unsigned int irq;
+
+static DECLARE_WAIT_QUEUE_HEAD(hecubafb_waitq);
+
+static void hcb_set_ctl(struct hecubafb_par *par)
+{
+ outb(par-ctl, par-cio_addr);
+}
+
+static unsigned char hcb_get_ctl(struct hecubafb_par *par)
+{
+ return inb(par-c2io_addr);
+}
+
+static void hcb_set_data(struct hecubafb_par *par, unsigned char value)
+{
+ outb(value, par-dio_addr);
+}
+
+static int __devinit apollo_init_control(struct hecubafb_par *par)
+{
+ unsigned char ctl;
+ /* for init, we want the following setup to be set:
+ WUP = lo
+ ACK = hi
+ DS = hi
+ RW = hi
+ CD = lo
+ */
+
+ /* write WUP to lo, DS to hi, RW to hi, CD to lo */
+ par-ctl = HCB_NWUP_BIT | HCB_RW_BIT | HCB_NCD_BIT ;
+ par-ctl = ~HCB_NDS_BIT;
+ hcb_set_ctl(par);
+
+ /* check ACK is not lo */
+ ctl = hcb_get_ctl(par);
+ if ((ctl HCB_ACK_BIT)) {
+ printk(KERN_ERR Fail because ACK is already low\n);
+ return -ENXIO;
+ }
+
+ return 0;
+}
+
+void hcb_wait_for_ack(struct hecubafb_par *par
[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,
+
[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
Re: [Linux-fbdev-devel] [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver
On 2/21/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: On Wed, 2007-02-21 at 11:55 -0500, Jaya Kumar wrote: > > You are right. I will need that. I could put that into struct > fb_deferred_io. So drivers would setup like: > Is it also possible to let the drivers do the 'deferred_io' themselves? Say, a driver that would flush the dirty pages on every VBLANK interrupt. Yes, I think so. The deferred_io callback that the driver would get would be to provide them with the dirty pages list. Then, they could use that to handle the on-vblank work. > When the driver calls register_framebuffer and unregister_framebuffer, > I can then do the init and destruction of the other members of that > struct. Does this sound okay? It would be better if separate registering functions are created for this functionality (ie deferred_io_register/unregister). Ok. Will do it that way. 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: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 2/21/07, James Simmons <[EMAIL PROTECTED]> wrote: Could you make it work without the framebuffer. There are embedded LCD displays that have internal memory that need data flushed to them. I'm not sure I understand. What the current implementation does is to use host based framebuffer memory. Apps mmap that memory and draw to that. Then after the delay, that framebuffer is written to the device's memory. That's the scenario for hecubafb where the Apollo controller maintains it's own internal framebuffer. When you say without the framebuffer, if you meant without the host memory, then this method doesn't work. If you mean without the device's internal memory, then yes, I think we can do that, because it would be up to the driver to use the touched pagelist to then perform IO as suitable for its device. 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: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 2/20/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
Don't you need a way to specify the maximum deferral time? E.g. a field in
fb_info.
You are right. I will need that. I could put that into struct
fb_deferred_io. So drivers would setup like:
static struct fb_deferred_io hecubafb_defio = {
.delay = HZ,
.deferred_io= hecubafb_dpy_update,
};
where that would be:
struct fb_deferred_io {
unsigned long delay;/* delay between mkwrite and deferred handler */
struct mutex lock; /* mutex that protects the page list */
struct list_head pagelist; /* list of touched pages */
struct delayed_work deferred_work;
void (*deferred_io)(struct fb_info *info, struct list_head
*pagelist); /* callback */
};
and the driver would do:
...
info->fbdefio = hecubafb_defio;
register_framebuffer...
When the driver calls register_framebuffer and unregister_framebuffer,
I can then do the init and destruction of the other members of that
struct. Does this sound okay?
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: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 2/20/07, Jaya Kumar <[EMAIL PROTECTED]> wrote:
On 2/19/07, Paul Mundt <[EMAIL PROTECTED]> wrote:
> That works for me, though I'd prefer for struct page_list to be done with
> a scatterlist, then it's trivial to setup from the workqueue context
> without having to shuffle things around.
>
Ok. Will check out when implementing.
Took a quick look. If I used scatterlist, I'd still need to build a
list of scatterlist to pass to the driver callback. The alternative
being a preallocated array of scatterlist based on the page count of
the framebuffer, which seems expensive since scatterlist has page,
offset, dma and length.
On a separate note, Peter pointed out that it may be possible to reuse
page->lru instead of using a struct page_list. This would enable
something like:
in mkwrite:
mutex_lock
list_add(page->lru, defio->pagelist)
mutex_unlock
in deferred handler:
mutex_lock
for_each page {
lock_page
mkclean
unlock_page
}
callback(fb_info, pagelist)
for_each page {
list_del
}
mutex_unlock
The advantage of reusing page->lru is that avoids needing the struct
page_list and allocation in mkwrite. Is the above exploitation of
->lru ok with mm folk?
In above, we're iterating over the page list twice. I have to mkclean
before calling the callback to avoid the situation where a touched
page is missed by the callback. I don't see a way around that part.
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: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 2/20/07, Jaya Kumar [EMAIL PROTECTED] wrote:
On 2/19/07, Paul Mundt [EMAIL PROTECTED] wrote:
That works for me, though I'd prefer for struct page_list to be done with
a scatterlist, then it's trivial to setup from the workqueue context
without having to shuffle things around.
Ok. Will check out when implementing.
Took a quick look. If I used scatterlist, I'd still need to build a
list of scatterlist to pass to the driver callback. The alternative
being a preallocated array of scatterlist based on the page count of
the framebuffer, which seems expensive since scatterlist has page,
offset, dma and length.
On a separate note, Peter pointed out that it may be possible to reuse
page-lru instead of using a struct page_list. This would enable
something like:
in mkwrite:
mutex_lock
list_add(page-lru, defio-pagelist)
mutex_unlock
in deferred handler:
mutex_lock
for_each page {
lock_page
mkclean
unlock_page
}
callback(fb_info, pagelist)
for_each page {
list_del
}
mutex_unlock
The advantage of reusing page-lru is that avoids needing the struct
page_list and allocation in mkwrite. Is the above exploitation of
-lru ok with mm folk?
In above, we're iterating over the page list twice. I have to mkclean
before calling the callback to avoid the situation where a touched
page is missed by the callback. I don't see a way around that part.
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: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 2/20/07, Geert Uytterhoeven [EMAIL PROTECTED] wrote:
Don't you need a way to specify the maximum deferral time? E.g. a field in
fb_info.
You are right. I will need that. I could put that into struct
fb_deferred_io. So drivers would setup like:
static struct fb_deferred_io hecubafb_defio = {
.delay = HZ,
.deferred_io= hecubafb_dpy_update,
};
where that would be:
struct fb_deferred_io {
unsigned long delay;/* delay between mkwrite and deferred handler */
struct mutex lock; /* mutex that protects the page list */
struct list_head pagelist; /* list of touched pages */
struct delayed_work deferred_work;
void (*deferred_io)(struct fb_info *info, struct list_head
*pagelist); /* callback */
};
and the driver would do:
...
info-fbdefio = hecubafb_defio;
register_framebuffer...
When the driver calls register_framebuffer and unregister_framebuffer,
I can then do the init and destruction of the other members of that
struct. Does this sound okay?
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: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 2/21/07, James Simmons [EMAIL PROTECTED] wrote: Could you make it work without the framebuffer. There are embedded LCD displays that have internal memory that need data flushed to them. I'm not sure I understand. What the current implementation does is to use host based framebuffer memory. Apps mmap that memory and draw to that. Then after the delay, that framebuffer is written to the device's memory. That's the scenario for hecubafb where the Apollo controller maintains it's own internal framebuffer. When you say without the framebuffer, if you meant without the host memory, then this method doesn't work. If you mean without the device's internal memory, then yes, I think we can do that, because it would be up to the driver to use the touched pagelist to then perform IO as suitable for its device. 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] [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver
On 2/21/07, Antonino A. Daplas [EMAIL PROTECTED] wrote: On Wed, 2007-02-21 at 11:55 -0500, Jaya Kumar wrote: You are right. I will need that. I could put that into struct fb_deferred_io. So drivers would setup like: Is it also possible to let the drivers do the 'deferred_io' themselves? Say, a driver that would flush the dirty pages on every VBLANK interrupt. Yes, I think so. The deferred_io callback that the driver would get would be to provide them with the dirty pages list. Then, they could use that to handle the on-vblank work. When the driver calls register_framebuffer and unregister_framebuffer, I can then do the init and destruction of the other members of that struct. Does this sound okay? It would be better if separate registering functions are created for this functionality (ie deferred_io_register/unregister). Ok. Will do it that way. 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: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 2/19/07, Paul Mundt <[EMAIL PROTECTED]> wrote: On Mon, Feb 19, 2007 at 11:13:04PM -0500, Jaya Kumar wrote: > > Ok. Here's what I'm thinking for abstracting this: > > fbdev drivers would setup fb_mmap with their own_mmap as usual. In > own_mmap, they would do what they normally do and setup a vm_ops. They > are free to have their own nopage handler but would set the > page_mkwrite handler to be fbdev_deferred_io_mkwrite(). The vast majority of drivers do not implement ->fb_mmap(), and with proper abstraction, this should be something that's possible as a direct alternative to drivers/video/fbmem.c:fb_mmap() for the people that want it. Of course it's just as easy to do something like the sbuslib.c route and then have drivers set their ->fb_mmap() from that too. I was thinking about having that fb_mmap replacement too. But then I got worried because that generic implementation of nopage/etc would need to handle whether the driver's fb memory was vmalloced, kmalloced or a mixture if some do that. So I figured let's aim low and just pull in the core part that does the setup and page tracking stuff. I hope that's okay. That works for me, though I'd prefer for struct page_list to be done with a scatterlist, then it's trivial to setup from the workqueue context without having to shuffle things around. Ok. Will check out when implementing. 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: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 2/18/07, Paul Mundt <[EMAIL PROTECTED]> wrote: Given that, this would have to be something that's dealt with at the subsystem level rather than in individual drivers, hence the desire to see something like this more generically visible. Hi Peter, Paul, fbdev folk, Ok. Here's what I'm thinking for abstracting this: fbdev drivers would setup fb_mmap with their own_mmap as usual. In own_mmap, they would do what they normally do and setup a vm_ops. They are free to have their own nopage handler but would set the page_mkwrite handler to be fbdev_deferred_io_mkwrite(). fbdev_deferred_io_mkwrite would build up the list of touched pages and pass it to a delayed workqueue which would then mkclean on each page and then pass a copy of that page list down to a driver's callback function. The fbdev driver's callback function can then do the actual IO to the framebuffer or coalesce DMA based on the provided page list. I would like to add something like the following to struct fb_info: #ifdef CONFIG_FB_DEFERRED_IO struct fb_deferred_io *defio; #endif to store the mutex (to protect the page list), the touched page list, and the driver's callback function. I hope this sounds sufficiently generic to meet everyone's (the two of us? :) needs. Thanks, jaya ps: I've added James and Geert to the CC list. I would appreciate any advice on whether this is a suitable approach. - 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: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 2/18/07, Paul Mundt [EMAIL PROTECTED] wrote: Given that, this would have to be something that's dealt with at the subsystem level rather than in individual drivers, hence the desire to see something like this more generically visible. Hi Peter, Paul, fbdev folk, Ok. Here's what I'm thinking for abstracting this: fbdev drivers would setup fb_mmap with their own_mmap as usual. In own_mmap, they would do what they normally do and setup a vm_ops. They are free to have their own nopage handler but would set the page_mkwrite handler to be fbdev_deferred_io_mkwrite(). fbdev_deferred_io_mkwrite would build up the list of touched pages and pass it to a delayed workqueue which would then mkclean on each page and then pass a copy of that page list down to a driver's callback function. The fbdev driver's callback function can then do the actual IO to the framebuffer or coalesce DMA based on the provided page list. I would like to add something like the following to struct fb_info: #ifdef CONFIG_FB_DEFERRED_IO struct fb_deferred_io *defio; #endif to store the mutex (to protect the page list), the touched page list, and the driver's callback function. I hope this sounds sufficiently generic to meet everyone's (the two of us? :) needs. Thanks, jaya ps: I've added James and Geert to the CC list. I would appreciate any advice on whether this is a suitable approach. - 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: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 2/19/07, Paul Mundt [EMAIL PROTECTED] wrote: On Mon, Feb 19, 2007 at 11:13:04PM -0500, Jaya Kumar wrote: Ok. Here's what I'm thinking for abstracting this: fbdev drivers would setup fb_mmap with their own_mmap as usual. In own_mmap, they would do what they normally do and setup a vm_ops. They are free to have their own nopage handler but would set the page_mkwrite handler to be fbdev_deferred_io_mkwrite(). The vast majority of drivers do not implement -fb_mmap(), and with proper abstraction, this should be something that's possible as a direct alternative to drivers/video/fbmem.c:fb_mmap() for the people that want it. Of course it's just as easy to do something like the sbuslib.c route and then have drivers set their -fb_mmap() from that too. I was thinking about having that fb_mmap replacement too. But then I got worried because that generic implementation of nopage/etc would need to handle whether the driver's fb memory was vmalloced, kmalloced or a mixture if some do that. So I figured let's aim low and just pull in the core part that does the setup and page tracking stuff. I hope that's okay. That works for me, though I'd prefer for struct page_list to be done with a scatterlist, then it's trivial to setup from the workqueue context without having to shuffle things around. Ok. Will check out when implementing. 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: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 2/17/07, Paul Mundt <[EMAIL PROTECTED]> wrote: On Sat, Feb 17, 2007 at 08:25:07AM -0500, Jaya Kumar wrote: > On 2/17/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote: > >And, as Andrew suggested last time around, could you perhaps push this > >fancy new idea into the FB layer so that more drivers can make us of it? > > I would like to do that very much. I have some ideas how it could work > for devices that support clean partial updates by tracking touched > pages. But I wonder if it is too early to try to abstract this out. > James, Geert, what do you think? > This would also provide an interesting hook for setting up chained DMA for the real framebuffer updates when there's more than a couple of pages that have been touched, which would also be nice to have. There's more than a few drivers that could take advantage of that. Hi Paul, I could benefit from knowing which driver and display device you are considering to be applicable. I was thinking the method used in hecubafb would only be useful to devices with very slow update paths, where "losing" some of the display activity is not an issue since the device would not have been able to update fast enough to show that activity anyway. What you described with chained DMA sounds different to this. I suppose one could use this technique to coalesce framebuffer IO to get better performance/utilization even for fast display devices. Sounds interesting to try. Did I understand you correctly? 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: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 2/17/07, Paul Mundt [EMAIL PROTECTED] wrote: On Sat, Feb 17, 2007 at 08:25:07AM -0500, Jaya Kumar wrote: On 2/17/07, Peter Zijlstra [EMAIL PROTECTED] wrote: And, as Andrew suggested last time around, could you perhaps push this fancy new idea into the FB layer so that more drivers can make us of it? I would like to do that very much. I have some ideas how it could work for devices that support clean partial updates by tracking touched pages. But I wonder if it is too early to try to abstract this out. James, Geert, what do you think? This would also provide an interesting hook for setting up chained DMA for the real framebuffer updates when there's more than a couple of pages that have been touched, which would also be nice to have. There's more than a few drivers that could take advantage of that. Hi Paul, I could benefit from knowing which driver and display device you are considering to be applicable. I was thinking the method used in hecubafb would only be useful to devices with very slow update paths, where losing some of the display activity is not an issue since the device would not have been able to update fast enough to show that activity anyway. What you described with chained DMA sounds different to this. I suppose one could use this technique to coalesce framebuffer IO to get better performance/utilization even for fast display devices. Sounds interesting to try. Did I understand you correctly? 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: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 2/17/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote: On Sat, 2007-02-17 at 11:42 +0100, Jaya Kumar wrote: > Hi James, Geert, lkml and mm, Hi Jaya, > This patch adds support for the Hecuba/E-Ink display with deferred IO. > The changes from the previous version are to switch to using a mutex > and lock_page. I welcome your feedback and advice. This changelog ought to be a little more extensive; esp. because you're using these fancy new functions ->page_mkwrite() and page_mkclean() in a novel way. Hi Peter, I had put the comment explaining the usage of mkwrite/mkclean in the .c file. Oh, I see, in the changelog message. Ok, I'll update with a changelog message mentioning mkwrite/mkclean. Also, I'd still like to see a way to call msync() on the mmap'ed region to force a flush. I think providing a fb_fsync() method in fbmem.c and a hook down to the driver ought to work. I'm hoping fbdev folk will give feedback if this is okay. James, Geert, what do you think? Also, you now seem to use a fixed 1 second delay, perhaps provide an ioctl or something to customize this? Ok. Will do. And, as Andrew suggested last time around, could you perhaps push this fancy new idea into the FB layer so that more drivers can make us of it? I would like to do that very much. I have some ideas how it could work for devices that support clean partial updates by tracking touched pages. But I wonder if it is too early to try to abstract this out. James, Geert, what do you think? 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/
[PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
Hi James, Geert, lkml and mm, This patch adds support for the Hecuba/E-Ink display with deferred IO. The changes from the previous version are to switch to using a mutex and lock_page. I welcome your feedback and advice. Signed-off-by: Jaya Kumar <[EMAIL PROTECTED]> --- drivers/video/Kconfig| 13 + drivers/video/Makefile |1 drivers/video/hecubafb.c | 590 +++ mm/rmap.c|1 4 files changed, 605 insertions(+) --- diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 8874cf2..151b6e0 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -540,6 +540,19 @@ config FB_IMAC help This is the frame buffer device driver for the Intel-based Macintosh +config FB_HECUBA + tristate "Hecuba board support" + depends on FB && X86 && MMU + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + help + This enables support for the Hecuba board. This driver was tested + with an E-Ink 800x600 display and x86 SBCs through a 16 bit GPIO + interface (8 bit data, 4 bit control). If you anticpate using + this driver, say Y or M; otherwise say N. You must specify the + GPIO IO address to be used for setting control and data. + config FB_HGA tristate "Hercules mono graphics support" depends on FB && X86 diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 6801edf..e9edf8e 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_FB_SGIVW)+= sgivwfb.o obj-$(CONFIG_FB_ACORN)+= acornfb.o obj-$(CONFIG_FB_ATARI)+= atafb.o obj-$(CONFIG_FB_MAC) += macfb.o +obj-$(CONFIG_FB_HECUBA) += hecubafb.o obj-$(CONFIG_FB_HGA) += hgafb.o obj-$(CONFIG_FB_IGA) += igafb.o obj-$(CONFIG_FB_APOLLO) += dnfb.o diff --git a/drivers/video/hecubafb.c b/drivers/video/hecubafb.c new file mode 100644 index 000..f0f538d --- /dev/null +++ b/drivers/video/hecubafb.c @@ -0,0 +1,590 @@ +/* + * linux/drivers/video/hecubafb.c -- FB driver for Hecuba controller + * + * Copyright (C) 2006, Jaya Kumar + * This work was sponsored by CIS(M) Sdn Bhd + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file COPYING in the main directory of this archive for + * more details. + * + * Layout is based on skeletonfb.c by James Simmons and Geert Uytterhoeven. + * This work was possible because of apollo display code from E-Ink's website + * http://support.eink.com/community + * All information used to write this code is from public material made + * available by E-Ink on its support site. Some commands such as 0xA4 + * were found by looping through cmd=0x00 thru 0xFF and supplying random + * values. There are other commands that the display is capable of, + * beyond the 5 used here but they are more complex. + * + * This driver is written to be used with the Hecuba display controller + * board, and tested with the EInk 800x600 display in 1 bit mode. + * The interface between Hecuba and the host is TTL based GPIO. The + * GPIO requirements are 8 writable data lines and 6 lines for control. + * Only 4 of the controls are actually used here but 6 for future use. + * The driver requires the IO addresses for data and control GPIO at + * load time. It is also possible to use this display with a standard + * PC parallel port. + * + * General notes: + * - User must set hecubafb_enable=1 to enable it + * - User must set dio_addr=0xIOADDR cio_addr=0xIOADDR c2io_addr=0xIOADDR + * + * Explaination for deferred IO: + * - userspace app like Xfbdev mmaps framebuffer + * - driver handles and sets up nopage and page_mkwrite handlers + * - app tries to write to mmaped vaddress + * - get pagefault and reaches driver's nopage handler + * - driver's nopage handler finds and returns physical page ( no + * actual framebuffer ) + * - write so get page_mkwrite where we add this page to a list + * - also schedules a workqueue task to be run after a delay + * - app continues writing to that page with no additional cost + * - the workqueue task then does page_mkclean for the pages on + * the list, then completes the updating of the framebuffer + * - app tries to write to the address (that was just cleaned) + * - get pagefault and the above sequence occurs again + * + * The desire is roughly to allow bursty framebuffer writes to occur. + * Then after some time when hopefully things have gone quiet, we go and + * really update the framebuffer. For this type of nonvolatile high latency + * display, the desired image is the final image rather than intermediate + * stages which is why it's okay to not update for each write that is + * occuring. + * + */ + +#include +#include +#include +#include +#include +#i
Re: [PATCH/RFC 2.6.20-rc4 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 1/12/07, Nick Piggin <[EMAIL PROTECTED]> wrote: Jaya Kumar wrote: > - write so get page_mkwrite where we add this page to a list > - also schedules a workqueue task to be run after a delay > - app continues writing to that page with no additional cost > - the workqueue task comes in and unmaps the pages on the list, then > completes the work associated with updating the framebuffer Have you thought about implementing a traditional write-back cache using the dirty bits, rather than unmapping the page? Ah, sorry, I erred in my description. I'm not unmapping pages, I'm calling page_mkclean which uses the dirty bits. 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: [PATCH/RFC 2.6.20-rc4 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 1/12/07, Nick Piggin [EMAIL PROTECTED] wrote: Jaya Kumar wrote: - write so get page_mkwrite where we add this page to a list - also schedules a workqueue task to be run after a delay - app continues writing to that page with no additional cost - the workqueue task comes in and unmaps the pages on the list, then completes the work associated with updating the framebuffer Have you thought about implementing a traditional write-back cache using the dirty bits, rather than unmapping the page? Ah, sorry, I erred in my description. I'm not unmapping pages, I'm calling page_mkclean which uses the dirty bits. 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/
[PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
Hi James, Geert, lkml and mm, This patch adds support for the Hecuba/E-Ink display with deferred IO. The changes from the previous version are to switch to using a mutex and lock_page. I welcome your feedback and advice. Signed-off-by: Jaya Kumar [EMAIL PROTECTED] --- drivers/video/Kconfig| 13 + drivers/video/Makefile |1 drivers/video/hecubafb.c | 590 +++ mm/rmap.c|1 4 files changed, 605 insertions(+) --- diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 8874cf2..151b6e0 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -540,6 +540,19 @@ config FB_IMAC help This is the frame buffer device driver for the Intel-based Macintosh +config FB_HECUBA + tristate Hecuba board support + depends on FB X86 MMU + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + help + This enables support for the Hecuba board. This driver was tested + with an E-Ink 800x600 display and x86 SBCs through a 16 bit GPIO + interface (8 bit data, 4 bit control). If you anticpate using + this driver, say Y or M; otherwise say N. You must specify the + GPIO IO address to be used for setting control and data. + config FB_HGA tristate Hercules mono graphics support depends on FB X86 diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 6801edf..e9edf8e 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_FB_SGIVW)+= sgivwfb.o obj-$(CONFIG_FB_ACORN)+= acornfb.o obj-$(CONFIG_FB_ATARI)+= atafb.o obj-$(CONFIG_FB_MAC) += macfb.o +obj-$(CONFIG_FB_HECUBA) += hecubafb.o obj-$(CONFIG_FB_HGA) += hgafb.o obj-$(CONFIG_FB_IGA) += igafb.o obj-$(CONFIG_FB_APOLLO) += dnfb.o diff --git a/drivers/video/hecubafb.c b/drivers/video/hecubafb.c new file mode 100644 index 000..f0f538d --- /dev/null +++ b/drivers/video/hecubafb.c @@ -0,0 +1,590 @@ +/* + * linux/drivers/video/hecubafb.c -- FB driver for Hecuba controller + * + * Copyright (C) 2006, Jaya Kumar + * This work was sponsored by CIS(M) Sdn Bhd + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file COPYING in the main directory of this archive for + * more details. + * + * Layout is based on skeletonfb.c by James Simmons and Geert Uytterhoeven. + * This work was possible because of apollo display code from E-Ink's website + * http://support.eink.com/community + * All information used to write this code is from public material made + * available by E-Ink on its support site. Some commands such as 0xA4 + * were found by looping through cmd=0x00 thru 0xFF and supplying random + * values. There are other commands that the display is capable of, + * beyond the 5 used here but they are more complex. + * + * This driver is written to be used with the Hecuba display controller + * board, and tested with the EInk 800x600 display in 1 bit mode. + * The interface between Hecuba and the host is TTL based GPIO. The + * GPIO requirements are 8 writable data lines and 6 lines for control. + * Only 4 of the controls are actually used here but 6 for future use. + * The driver requires the IO addresses for data and control GPIO at + * load time. It is also possible to use this display with a standard + * PC parallel port. + * + * General notes: + * - User must set hecubafb_enable=1 to enable it + * - User must set dio_addr=0xIOADDR cio_addr=0xIOADDR c2io_addr=0xIOADDR + * + * Explaination for deferred IO: + * - userspace app like Xfbdev mmaps framebuffer + * - driver handles and sets up nopage and page_mkwrite handlers + * - app tries to write to mmaped vaddress + * - get pagefault and reaches driver's nopage handler + * - driver's nopage handler finds and returns physical page ( no + * actual framebuffer ) + * - write so get page_mkwrite where we add this page to a list + * - also schedules a workqueue task to be run after a delay + * - app continues writing to that page with no additional cost + * - the workqueue task then does page_mkclean for the pages on + * the list, then completes the updating of the framebuffer + * - app tries to write to the address (that was just cleaned) + * - get pagefault and the above sequence occurs again + * + * The desire is roughly to allow bursty framebuffer writes to occur. + * Then after some time when hopefully things have gone quiet, we go and + * really update the framebuffer. For this type of nonvolatile high latency + * display, the desired image is the final image rather than intermediate + * stages which is why it's okay to not update for each write that is + * occuring. + * + */ + +#include asm/uaccess.h +#include linux/module.h +#include linux/kernel.h +#include linux/errno.h +#include linux/string.h
Re: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 2/17/07, Peter Zijlstra [EMAIL PROTECTED] wrote: On Sat, 2007-02-17 at 11:42 +0100, Jaya Kumar wrote: Hi James, Geert, lkml and mm, Hi Jaya, This patch adds support for the Hecuba/E-Ink display with deferred IO. The changes from the previous version are to switch to using a mutex and lock_page. I welcome your feedback and advice. This changelog ought to be a little more extensive; esp. because you're using these fancy new functions -page_mkwrite() and page_mkclean() in a novel way. Hi Peter, I had put the comment explaining the usage of mkwrite/mkclean in the .c file. Oh, I see, in the changelog message. Ok, I'll update with a changelog message mentioning mkwrite/mkclean. Also, I'd still like to see a way to call msync() on the mmap'ed region to force a flush. I think providing a fb_fsync() method in fbmem.c and a hook down to the driver ought to work. I'm hoping fbdev folk will give feedback if this is okay. James, Geert, what do you think? Also, you now seem to use a fixed 1 second delay, perhaps provide an ioctl or something to customize this? Ok. Will do. And, as Andrew suggested last time around, could you perhaps push this fancy new idea into the FB layer so that more drivers can make us of it? I would like to do that very much. I have some ideas how it could work for devices that support clean partial updates by tracking touched pages. But I wonder if it is too early to try to abstract this out. James, Geert, what do you think? 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: [PATCH/RFC 2.6.20-rc4 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 1/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: That's all very interesting. Please don't dump a bunch of new implementation concepts like this on us with no description of what it does, why it does it and why it does it in this particular manner. Hi Andrew, Actually, I didn't dump without description. :-) I had posted an RFC and an explanation of the design to the lists. Here's an archive link to that post. http://marc.theaimsgroup.com/?l=linux-kernel=116583546411423=2 I wasn't sure whether to include that description with the patch email because it was long. From that email: --- This is there in order to hide the latency associated with updating the display (500ms to 800ms). The method used is to fake a framebuffer in memory. Then use pagefaults followed by delayed unmaping and only then do the actual framebuffer update. To explain this better, the usage scenario is like this: - userspace app like Xfbdev mmaps framebuffer - driver handles and sets up nopage and page_mkwrite handlers - app tries to write to mmaped vaddress - get pagefault and reaches driver's nopage handler - driver's nopage handler finds and returns physical page ( no actual framebuffer ) - write so get page_mkwrite where we add this page to a list - also schedules a workqueue task to be run after a delay - app continues writing to that page with no additional cost - the workqueue task comes in and unmaps the pages on the list, then completes the work associated with updating the framebuffer - app tries to write to the address (that has now been unmapped) - get pagefault and the above sequence occurs again The desire is roughly to allow bursty framebuffer writes to occur. Then after some time when hopefully things have gone quiet, we go and really update the framebuffer. For this type of nonvolatile high latency display, the desired image is the final image rather than intermediate stages which is why it's okay to not update for each write that is occuring. --- What is the "theory of operation" here? Presumably this is a performance optimisation to permit batching of the copying from user memory into the frambuffer card? If so, how much performance does it gain? Yes, you are right. Updating the E-Ink display currently requires about 500ms - 800ms. It is a non-volatile display and as such it is typically used in a manner where only the final image is important. As a result, being able to avoid the bursts of IO associated with screen activity and only write the final result is attractive. I have not done any performance benchmarks. I'm not sure exactly what to compare. I imagine in one case would be using write() to deliver the image updates and the other case would be mmap(), memcpy(). The latter would win because it's hiding all the intermediate "writes". I expect the benefit will be large, and could be increased if you were to add a small delay between first-touch and writeback to the display. Let's talk about that a bit. Agreed. Though I may be misunderstanding what you mean by first-touch. Currently, I do a schedule_delayed_work and leave 1s between when the page_mkwrite callback indicating the first touch is received and when the deferred IO is processed to actually deliver the data to the display. I picked 1s because it rounds up the display latency. I imagine increasing the delay further may make it miss some desirable display activity. For example, a slider indicating progress of music may be slower than optimal. Perhaps I should make the delay a module parameter and leave the choice to the user? Is the optimisation applicable to other drivers? If so, should it be generalised into library code somewhere? I think the deferred IO code would be useful to devices that have slow updates and where only the final result is important. So far, this is the only device I've encountered that has this characteristic. I guess the export of page_mkclean() makes sense for this application. The use of lock_page_nosync() is wrong. It can still sleep, and here it's inside spinlock. And we don't want to export __lock_page_nosync() to modules. I suggest you convert the list locking here to a mutex and use lock_page(). Oops, sorry about that. I will correct it. Thanks, jayakumar - 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/
[PATCH/RFC 2.6.20-rc4 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
This patch adds support for the Hecuba/E-Ink display with deferred IO.
I welcome your feedback and advice.
Signed-off-by: Jaya Kumar <[EMAIL PROTECTED]>
---
drivers/video/Kconfig| 13 +
drivers/video/Makefile |1
drivers/video/hecubafb.c | 568 +++
mm/filemap.c |1
mm/rmap.c|1
5 files changed, 584 insertions(+)
---
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4e83f01..cf2dc50 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -568,6 +568,19 @@ config FB_IMAC
help
This is the frame buffer device driver for the Intel-based Macintosh
+config FB_HECUBA
+ tristate "Hecuba board support"
+ depends on FB && X86 && MMU
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ help
+ This enables support for the Hecuba board. This driver was tested
+ with an E-Ink 800x600 display and x86 SBCs through a 16 bit GPIO
+ interface (8 bit data, 4 bit control). If you anticpate using
+ this driver, say Y or M; otherwise say N. You must specify the
+ GPIO IO address to be used for setting control and data.
+
config FB_HGA
tristate "Hercules mono graphics support"
depends on FB && X86
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 309a26d..b4d5655 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_FB_SGIVW)+= sgivwfb.o
obj-$(CONFIG_FB_ACORN)+= acornfb.o
obj-$(CONFIG_FB_ATARI)+= atafb.o
obj-$(CONFIG_FB_MAC) += macfb.o
+obj-$(CONFIG_FB_HECUBA) += hecubafb.o
obj-$(CONFIG_FB_HGA) += hgafb.o
obj-$(CONFIG_FB_IGA) += igafb.o
obj-$(CONFIG_FB_APOLLO) += dnfb.o
diff --git a/drivers/video/hecubafb.c b/drivers/video/hecubafb.c
new file mode 100644
index 000..4740b92
--- /dev/null
+++ b/drivers/video/hecubafb.c
@@ -0,0 +1,568 @@
+/*
+ * linux/drivers/video/hecubafb.c -- FB driver for Hecuba controller
+ *
+ * Copyright (C) 2006, Jaya Kumar
+ * This work was sponsored by CIS(M) Sdn Bhd
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ *
+ * Layout is based on skeletonfb.c by James Simmons and Geert Uytterhoeven.
+ * This work was possible because of apollo display code from E-Ink's website
+ * http://support.eink.com/community
+ * All information used to write this code is from public material made
+ * available by E-Ink on its support site. Some commands such as 0xA4
+ * were found by looping through cmd=0x00 thru 0xFF and supplying random
+ * values. There are other commands that the display is capable of,
+ * beyond the 5 used here but they are more complex.
+ *
+ * This driver is written to be used with the Hecuba display controller
+ * board, and tested with the EInk 800x600 display in 1 bit mode.
+ * The interface between Hecuba and the host is TTL based GPIO. The
+ * GPIO requirements are 8 writable data lines and 6 lines for control.
+ * Only 4 of the controls are actually used here but 6 for future use.
+ * The driver requires the IO addresses for data and control GPIO at
+ * load time. It is also possible to use this display with a standard
+ * PC parallel port.
+ *
+ * General notes:
+ * - User must set hecubafb_enable=1 to enable it
+ * - User must set dio_addr=0xIOADDR cio_addr=0xIOADDR c2io_addr=0xIOADDR
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* to support deferred IO */
+#include
+#include
+
+/* Apollo controller specific defines */
+#define APOLLO_START_NEW_IMG 0xA0
+#define APOLLO_STOP_IMG_DATA 0xA1
+#define APOLLO_DISPLAY_IMG 0xA2
+#define APOLLO_ERASE_DISPLAY 0xA3
+#define APOLLO_INIT_DISPLAY0xA4
+
+/* Hecuba interface specific defines */
+/* WUP is inverted, CD is inverted, DS is inverted */
+#define HCB_NWUP_BIT 0x01
+#define HCB_NDS_BIT0x02
+#define HCB_RW_BIT 0x04
+#define HCB_NCD_BIT0x08
+#define HCB_ACK_BIT0x80
+
+/* Display specific information */
+#define DPY_W 600
+#define DPY_H 800
+
+struct hecubafb_par {
+ struct delayed_work deferred_work;
+ unsigned long dio_addr;
+ unsigned long cio_addr;
+ unsigned long c2io_addr;
+ unsigned char ctl;
+ atomic_t ref_count;
+ atomic_t vma_count;
+ struct fb_info *info;
+ unsigned int irq;
+ spinlock_t lock;
+ struct list_head pagelist;
+};
+
+struct page_list {
+ struct list_head list;
+ struct page *page;
+};
+
+static struct fb_fix_screeninfo hecubafb_fix __initdata = {
+ .id = "h
[PATCH/RFC 2.6.20-rc4 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
This patch adds support for the Hecuba/E-Ink display with deferred IO.
I welcome your feedback and advice.
Signed-off-by: Jaya Kumar [EMAIL PROTECTED]
---
drivers/video/Kconfig| 13 +
drivers/video/Makefile |1
drivers/video/hecubafb.c | 568 +++
mm/filemap.c |1
mm/rmap.c|1
5 files changed, 584 insertions(+)
---
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4e83f01..cf2dc50 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -568,6 +568,19 @@ config FB_IMAC
help
This is the frame buffer device driver for the Intel-based Macintosh
+config FB_HECUBA
+ tristate Hecuba board support
+ depends on FB X86 MMU
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ help
+ This enables support for the Hecuba board. This driver was tested
+ with an E-Ink 800x600 display and x86 SBCs through a 16 bit GPIO
+ interface (8 bit data, 4 bit control). If you anticpate using
+ this driver, say Y or M; otherwise say N. You must specify the
+ GPIO IO address to be used for setting control and data.
+
config FB_HGA
tristate Hercules mono graphics support
depends on FB X86
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 309a26d..b4d5655 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_FB_SGIVW)+= sgivwfb.o
obj-$(CONFIG_FB_ACORN)+= acornfb.o
obj-$(CONFIG_FB_ATARI)+= atafb.o
obj-$(CONFIG_FB_MAC) += macfb.o
+obj-$(CONFIG_FB_HECUBA) += hecubafb.o
obj-$(CONFIG_FB_HGA) += hgafb.o
obj-$(CONFIG_FB_IGA) += igafb.o
obj-$(CONFIG_FB_APOLLO) += dnfb.o
diff --git a/drivers/video/hecubafb.c b/drivers/video/hecubafb.c
new file mode 100644
index 000..4740b92
--- /dev/null
+++ b/drivers/video/hecubafb.c
@@ -0,0 +1,568 @@
+/*
+ * linux/drivers/video/hecubafb.c -- FB driver for Hecuba controller
+ *
+ * Copyright (C) 2006, Jaya Kumar
+ * This work was sponsored by CIS(M) Sdn Bhd
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ *
+ * Layout is based on skeletonfb.c by James Simmons and Geert Uytterhoeven.
+ * This work was possible because of apollo display code from E-Ink's website
+ * http://support.eink.com/community
+ * All information used to write this code is from public material made
+ * available by E-Ink on its support site. Some commands such as 0xA4
+ * were found by looping through cmd=0x00 thru 0xFF and supplying random
+ * values. There are other commands that the display is capable of,
+ * beyond the 5 used here but they are more complex.
+ *
+ * This driver is written to be used with the Hecuba display controller
+ * board, and tested with the EInk 800x600 display in 1 bit mode.
+ * The interface between Hecuba and the host is TTL based GPIO. The
+ * GPIO requirements are 8 writable data lines and 6 lines for control.
+ * Only 4 of the controls are actually used here but 6 for future use.
+ * The driver requires the IO addresses for data and control GPIO at
+ * load time. It is also possible to use this display with a standard
+ * PC parallel port.
+ *
+ * General notes:
+ * - User must set hecubafb_enable=1 to enable it
+ * - User must set dio_addr=0xIOADDR cio_addr=0xIOADDR c2io_addr=0xIOADDR
+ *
+ */
+
+#include asm/uaccess.h
+#include linux/module.h
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/string.h
+#include linux/mm.h
+#include linux/slab.h
+#include linux/vmalloc.h
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/fb.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/list.h
+
+/* to support deferred IO */
+#include linux/rmap.h
+#include linux/pagemap.h
+
+/* Apollo controller specific defines */
+#define APOLLO_START_NEW_IMG 0xA0
+#define APOLLO_STOP_IMG_DATA 0xA1
+#define APOLLO_DISPLAY_IMG 0xA2
+#define APOLLO_ERASE_DISPLAY 0xA3
+#define APOLLO_INIT_DISPLAY0xA4
+
+/* Hecuba interface specific defines */
+/* WUP is inverted, CD is inverted, DS is inverted */
+#define HCB_NWUP_BIT 0x01
+#define HCB_NDS_BIT0x02
+#define HCB_RW_BIT 0x04
+#define HCB_NCD_BIT0x08
+#define HCB_ACK_BIT0x80
+
+/* Display specific information */
+#define DPY_W 600
+#define DPY_H 800
+
+struct hecubafb_par {
+ struct delayed_work deferred_work;
+ unsigned long dio_addr;
+ unsigned long cio_addr;
+ unsigned long c2io_addr;
+ unsigned char ctl;
+ atomic_t ref_count;
+ atomic_t vma_count;
+ struct fb_info *info;
+ unsigned int irq;
+ spinlock_t lock;
+ struct list_head pagelist;
+};
+
+struct page_list {
+ struct
Re: [PATCH/RFC 2.6.20-rc4 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On 1/11/07, Andrew Morton [EMAIL PROTECTED] wrote: That's all very interesting. Please don't dump a bunch of new implementation concepts like this on us with no description of what it does, why it does it and why it does it in this particular manner. Hi Andrew, Actually, I didn't dump without description. :-) I had posted an RFC and an explanation of the design to the lists. Here's an archive link to that post. http://marc.theaimsgroup.com/?l=linux-kernelm=116583546411423w=2 I wasn't sure whether to include that description with the patch email because it was long. From that email: --- This is there in order to hide the latency associated with updating the display (500ms to 800ms). The method used is to fake a framebuffer in memory. Then use pagefaults followed by delayed unmaping and only then do the actual framebuffer update. To explain this better, the usage scenario is like this: - userspace app like Xfbdev mmaps framebuffer - driver handles and sets up nopage and page_mkwrite handlers - app tries to write to mmaped vaddress - get pagefault and reaches driver's nopage handler - driver's nopage handler finds and returns physical page ( no actual framebuffer ) - write so get page_mkwrite where we add this page to a list - also schedules a workqueue task to be run after a delay - app continues writing to that page with no additional cost - the workqueue task comes in and unmaps the pages on the list, then completes the work associated with updating the framebuffer - app tries to write to the address (that has now been unmapped) - get pagefault and the above sequence occurs again The desire is roughly to allow bursty framebuffer writes to occur. Then after some time when hopefully things have gone quiet, we go and really update the framebuffer. For this type of nonvolatile high latency display, the desired image is the final image rather than intermediate stages which is why it's okay to not update for each write that is occuring. --- What is the theory of operation here? Presumably this is a performance optimisation to permit batching of the copying from user memory into the frambuffer card? If so, how much performance does it gain? Yes, you are right. Updating the E-Ink display currently requires about 500ms - 800ms. It is a non-volatile display and as such it is typically used in a manner where only the final image is important. As a result, being able to avoid the bursts of IO associated with screen activity and only write the final result is attractive. I have not done any performance benchmarks. I'm not sure exactly what to compare. I imagine in one case would be using write() to deliver the image updates and the other case would be mmap(), memcpy(). The latter would win because it's hiding all the intermediate writes. I expect the benefit will be large, and could be increased if you were to add a small delay between first-touch and writeback to the display. Let's talk about that a bit. Agreed. Though I may be misunderstanding what you mean by first-touch. Currently, I do a schedule_delayed_work and leave 1s between when the page_mkwrite callback indicating the first touch is received and when the deferred IO is processed to actually deliver the data to the display. I picked 1s because it rounds up the display latency. I imagine increasing the delay further may make it miss some desirable display activity. For example, a slider indicating progress of music may be slower than optimal. Perhaps I should make the delay a module parameter and leave the choice to the user? Is the optimisation applicable to other drivers? If so, should it be generalised into library code somewhere? I think the deferred IO code would be useful to devices that have slow updates and where only the final result is important. So far, this is the only device I've encountered that has this characteristic. I guess the export of page_mkclean() makes sense for this application. The use of lock_page_nosync() is wrong. It can still sleep, and here it's inside spinlock. And we don't want to export __lock_page_nosync() to modules. I suggest you convert the list locking here to a mutex and use lock_page(). Oops, sorry about that. I will correct it. Thanks, jayakumar - 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.19 1/1] fbdev,mm: hecuba/E-Ink fbdev driver v2
On 12/22/06, Franck Bui-Huu <[EMAIL PROTECTED]> wrote: Well thinking more about it, this wouldn't work for all cache types. For example, if your cache is not a direct maped one, this workaround won't work. So this is definitely not a portable solution. From asking peterz on #mm, I think page_mkclean will do the right thing and call something like flush_cache_page. I think that resolves the issue which I think you identified where the end symptom on archs with virtually tagged caches could be a line of pixels written by userspace through one PTE remain in-cache and therefore "undisplayed" when the kernel reads through another PTE that may fall on a different cacheline. Thanks, jayakumar - 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.19 1/1] fbdev,mm: hecuba/E-Ink fbdev driver v2
On 12/22/06, Franck Bui-Huu [EMAIL PROTECTED] wrote: Well thinking more about it, this wouldn't work for all cache types. For example, if your cache is not a direct maped one, this workaround won't work. So this is definitely not a portable solution. From asking peterz on #mm, I think page_mkclean will do the right thing and call something like flush_cache_page. I think that resolves the issue which I think you identified where the end symptom on archs with virtually tagged caches could be a line of pixels written by userspace through one PTE remain in-cache and therefore undisplayed when the kernel reads through another PTE that may fall on a different cacheline. Thanks, jayakumar - 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.19 1/1] fbdev,mm: hecuba/E-Ink fbdev driver v2
On 12/13/06, Franck Bui-Huu <[EMAIL PROTECTED]> wrote: On 12/12/06, Jaya Kumar <[EMAIL PROTECTED]> wrote: > I think that PTEs set up by vmalloc are marked cacheable and via the > above nopage end up as cacheable. I'm not doing DMA. So the accesses > are through the cache so I don't think cache aliasing is an issue for > this case. Please let me know if I misunderstood. > This issue is not related to DMA: there are 2 different virtual addresses that can map the same physical address. If these 2 virtual addresses use 2 different data cache entries then you have a cache aliasing issue. In your case the 2 different virtual addresses are (1) Ok. I now see what you mean. In typical cases, only one path is used to write. Meaning an app will decide to use the mmap path or the slow write path and the kernel only ever reads from its pte entry (unless fbcon is used which is not suited for this type of display). But you are right that it is possible for a situation to arise where one app does mmap and another is doing write. My hope is that something takes care of flushing the data cache for me in this case. Do you recommend I add something to force that? I'm worried about having an fbdev driver that is too involved with mm. Thanks, jayakumar the one got by the kernel (returned by vmalloc) (2) the one got by the application (returned by mmap). Hope that helps. -- Franck - 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.19 1/1] fbdev,mm: hecuba/E-Ink fbdev driver v2
On 12/13/06, Franck Bui-Huu [EMAIL PROTECTED] wrote: On 12/12/06, Jaya Kumar [EMAIL PROTECTED] wrote: I think that PTEs set up by vmalloc are marked cacheable and via the above nopage end up as cacheable. I'm not doing DMA. So the accesses are through the cache so I don't think cache aliasing is an issue for this case. Please let me know if I misunderstood. This issue is not related to DMA: there are 2 different virtual addresses that can map the same physical address. If these 2 virtual addresses use 2 different data cache entries then you have a cache aliasing issue. In your case the 2 different virtual addresses are (1) Ok. I now see what you mean. In typical cases, only one path is used to write. Meaning an app will decide to use the mmap path or the slow write path and the kernel only ever reads from its pte entry (unless fbcon is used which is not suited for this type of display). But you are right that it is possible for a situation to arise where one app does mmap and another is doing write. My hope is that something takes care of flushing the data cache for me in this case. Do you recommend I add something to force that? I'm worried about having an fbdev driver that is too involved with mm. Thanks, jayakumar the one got by the kernel (returned by vmalloc) (2) the one got by the application (returned by mmap). Hope that helps. -- Franck - 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.19 1/1] fbdev,mm: hecuba/E-Ink fbdev driver v2
On 12/11/06, Franck Bui-Huu <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> + atomic_t ref_count;
> + atomic_t vma_count;
what purpose do these counters deserve ?
You are right. I can remove them.
> +
> +void hcb_wait_for_ack(struct hecubafb_par *par)
> +{
> +
> + int timeout;
> + unsigned char ctl;
> +
> + timeout=500;
> + do {
> + ctl = hcb_get_ctl(par);
> + if ((ctl & HCB_ACK_BIT))
> + return;
> + udelay(1);
> + } while (timeout--);
> + printk(KERN_ERR "timed out waiting for ack\n");
> +}
When timeout occur this function does not return any error values.
the callers needn't to be warn in this case ?
You are right. I need to figure out what exactly to do. Currently, if
a timeout is observed it normally means the display controller is
hung. However, in some cases the controller does seem to recover
after some period of time. I guess I should probably return an error
and terminate pending activity.
> +
> +/* this is to find and return the vmalloc-ed fb pages */
> +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;
> +}
> +
so page can be accessed by using vma->start virtual address
The userspace app would be doing:
ioctl(fd, FBIOGET_FSCREENINFO, );
ioctl(fd, FBIOGET_VSCREENINFO, );
screensize = ( vinfo.xres * vinfo.yres * vinfo.bits_per_pixel) / 8;
maddr = mmap(finfo.mmio_start, screensize, PROT_WRITE, MAP_SHARED, fd, 0);
> +static int hecubafb_page_mkwrite(struct vm_area_struct *vma,
[snip]
> +
> + if (!(videomemory = vmalloc(videomemorysize)))
> + return retval;
and here the kernel access to the same page by using address returned
by vmalloc which are different from the previous one. So 2 different
addresses map the same physical page. In this case are there any cache
aliasing issues specially for x86 arch ?
I think that PTEs set up by vmalloc are marked cacheable and via the
above nopage end up as cacheable. I'm not doing DMA. So the accesses
are through the cache so I don't think cache aliasing is an issue for
this case. Please let me know if I misunderstood.
Thanks,
jayakumar
-
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.19 1/1] fbdev,mm: hecuba/E-Ink fbdev driver v2
On 12/11/06, Franck Bui-Huu [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
+ atomic_t ref_count;
+ atomic_t vma_count;
what purpose do these counters deserve ?
You are right. I can remove them.
+
+void hcb_wait_for_ack(struct hecubafb_par *par)
+{
+
+ int timeout;
+ unsigned char ctl;
+
+ timeout=500;
+ do {
+ ctl = hcb_get_ctl(par);
+ if ((ctl HCB_ACK_BIT))
+ return;
+ udelay(1);
+ } while (timeout--);
+ printk(KERN_ERR timed out waiting for ack\n);
+}
When timeout occur this function does not return any error values.
the callers needn't to be warn in this case ?
You are right. I need to figure out what exactly to do. Currently, if
a timeout is observed it normally means the display controller is
hung. However, in some cases the controller does seem to recover
after some period of time. I guess I should probably return an error
and terminate pending activity.
+
+/* this is to find and return the vmalloc-ed fb pages */
+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;
+}
+
so page can be accessed by using vma-start virtual address
The userspace app would be doing:
ioctl(fd, FBIOGET_FSCREENINFO, finfo);
ioctl(fd, FBIOGET_VSCREENINFO, vinfo);
screensize = ( vinfo.xres * vinfo.yres * vinfo.bits_per_pixel) / 8;
maddr = mmap(finfo.mmio_start, screensize, PROT_WRITE, MAP_SHARED, fd, 0);
+static int hecubafb_page_mkwrite(struct vm_area_struct *vma,
[snip]
+
+ if (!(videomemory = vmalloc(videomemorysize)))
+ return retval;
and here the kernel access to the same page by using address returned
by vmalloc which are different from the previous one. So 2 different
addresses map the same physical page. In this case are there any cache
aliasing issues specially for x86 arch ?
I think that PTEs set up by vmalloc are marked cacheable and via the
above nopage end up as cacheable. I'm not doing DMA. So the accesses
are through the cache so I don't think cache aliasing is an issue for
this case. Please let me know if I misunderstood.
Thanks,
jayakumar
-
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/
