Re: [Linux-fbdev-devel] [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver
> 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. I meant for it to work for non framebuffer devices. I realized that not such a great idea. - 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
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. I meant for it to work for non framebuffer devices. I realized that not such a great idea. - 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: [Linux-fbdev-devel] [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver
On Wed, 2007-02-21 at 11:55 -0500, Jaya Kumar wrote:
> 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:
>
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.
> 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?
It would be better if separate registering functions are created for
this functionality (ie deferred_io_register/unregister).
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] [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver
On Mon, 2007-02-19 at 23:13 -0500, Jaya Kumar wrote: > 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 Yes, this functionality is sorely needed by more than a few driver writers. > 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. There's definitely more than two :-). For the past several years, various people have been asking for this functionality. So yes, implementing this in a generic manner will be a big help. 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] [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver
On Mon, 2007-02-19 at 23:13 -0500, Jaya Kumar wrote: 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 Yes, this functionality is sorely needed by more than a few driver writers. 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. There's definitely more than two :-). For the past several years, various people have been asking for this functionality. So yes, implementing this in a generic manner will be a big help. 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] [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver
On Wed, 2007-02-21 at 11:55 -0500, Jaya Kumar wrote:
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:
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.
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?
It would be better if separate registering functions are created for
this functionality (ie deferred_io_register/unregister).
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] [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/
