Hi,
[EMAIL PROTECTED] wrote:
> Hi Geert, James, FBdev, MM folk,
>
> Appended is my attempt to support the Hecuba/E-Ink display. I've added
> some code to do deferred IO. 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.
>
> Please let me know if this looks okay so far and if you have any feedback
> or suggestions. Thanks to peterz for the page_mkwrite/clean suggestions
> that made this possible.
>
[snip]
> +struct hecubafb_par {
> + unsigned long dio_addr;
> + unsigned long cio_addr;
> + unsigned long c2io_addr;
> + unsigned char ctl;
> + atomic_t ref_count;
> + atomic_t vma_count;
what purpose do these counters deserve ?
> + struct fb_info *info;
> + unsigned int irq;
> + spinlock_t lock;
> + struct workqueue_struct *wq;
> + struct work_struct work;
> + struct list_head pagelist;
> +};
> +
[snip]
> +
> +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 ?
> +
> +void hcb_wait_for_ack_clear(struct hecubafb_par *par)
[snip]
> +}
> +
> +/* 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....
> +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 ?
thanks
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/
