From: "Antonino A. Daplas" <adaplas@gmail.com>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: jsimmons@infradead.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Paul Mundt <lethal@linux-sh.org>,
Geert.Uytterhoeven@sonycom.com,
Jaya Kumar <jayakumar.lkml@gmail.com>
Subject: Re: [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver
Date: Thu, 22 Feb 2007 07:43:33 +0800 [thread overview]
Message-ID: <1172101413.4217.18.camel@daplas> (raw)
In-Reply-To: <45a44e480702192013s7d49d05ai31e576f0448a485e@mail.gmail.com>
On Mon, 2007-02-19 at 23:13 -0500, Jaya Kumar wrote:
> On 2/18/07, Paul Mundt <lethal@linux-sh.org> 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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
WARNING: multiple messages have this Message-ID (diff)
From: "Antonino A. Daplas" <adaplas@gmail.com>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: Paul Mundt <lethal@linux-sh.org>,
Jaya Kumar <jayakumar.lkml@gmail.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Geert.Uytterhoeven@sonycom.com, jsimmons@infradead.org
Subject: Re: [Linux-fbdev-devel] [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver
Date: Thu, 22 Feb 2007 07:43:33 +0800 [thread overview]
Message-ID: <1172101413.4217.18.camel@daplas> (raw)
In-Reply-To: <45a44e480702192013s7d49d05ai31e576f0448a485e@mail.gmail.com>
On Mon, 2007-02-19 at 23:13 -0500, Jaya Kumar wrote:
> On 2/18/07, Paul Mundt <lethal@linux-sh.org> 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
WARNING: multiple messages have this Message-ID (diff)
From: "Antonino A. Daplas" <adaplas@gmail.com>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: Paul Mundt <lethal@linux-sh.org>,
Jaya Kumar <jayakumar.lkml@gmail.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Geert.Uytterhoeven@sonycom.com, jsimmons@infradead.org
Subject: Re: [Linux-fbdev-devel] [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver
Date: Thu, 22 Feb 2007 07:43:33 +0800 [thread overview]
Message-ID: <1172101413.4217.18.camel@daplas> (raw)
In-Reply-To: <45a44e480702192013s7d49d05ai31e576f0448a485e@mail.gmail.com>
On Mon, 2007-02-19 at 23:13 -0500, Jaya Kumar wrote:
> On 2/18/07, Paul Mundt <lethal@linux-sh.org> 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-02-21 23:40 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-17 10:42 [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver Jaya Kumar
2007-02-17 10:42 ` [PATCH 2.6.20 1/1] fbdev,mm: " Jaya Kumar
2007-02-17 10:42 ` Jaya Kumar
2007-02-17 12:34 ` Peter Zijlstra
2007-02-17 12:34 ` Peter Zijlstra
2007-02-17 13:25 ` [PATCH 2.6.20 1/1] fbdev, mm: " Jaya Kumar
2007-02-17 13:25 ` [PATCH 2.6.20 1/1] fbdev,mm: " Jaya Kumar
2007-02-17 13:25 ` Jaya Kumar
2007-02-17 13:59 ` [PATCH 2.6.20 1/1] fbdev, mm: " Paul Mundt
2007-02-17 13:59 ` [PATCH 2.6.20 1/1] fbdev,mm: " Paul Mundt
2007-02-17 13:59 ` Paul Mundt
2007-02-18 11:31 ` [PATCH 2.6.20 1/1] fbdev, mm: " Jaya Kumar
2007-02-18 11:31 ` [PATCH 2.6.20 1/1] fbdev,mm: " Jaya Kumar
2007-02-18 11:31 ` Jaya Kumar
2007-02-18 23:57 ` [PATCH 2.6.20 1/1] fbdev, mm: " Paul Mundt
2007-02-18 23:57 ` [PATCH 2.6.20 1/1] fbdev,mm: " Paul Mundt
2007-02-18 23:57 ` Paul Mundt
2007-02-20 4:13 ` [PATCH 2.6.20 1/1] fbdev, mm: " Jaya Kumar
2007-02-20 4:13 ` [PATCH 2.6.20 1/1] fbdev,mm: " Jaya Kumar
2007-02-20 4:13 ` Jaya Kumar
2007-02-20 4:38 ` [PATCH 2.6.20 1/1] fbdev, mm: " Paul Mundt
2007-02-20 4:38 ` [PATCH 2.6.20 1/1] fbdev,mm: " Paul Mundt
2007-02-20 4:38 ` Paul Mundt
2007-02-20 6:11 ` [PATCH 2.6.20 1/1] fbdev, mm: " Jaya Kumar
2007-02-20 6:11 ` [PATCH 2.6.20 1/1] fbdev,mm: " Jaya Kumar
2007-02-20 6:11 ` Jaya Kumar
2007-02-21 16:46 ` [PATCH 2.6.20 1/1] fbdev, mm: " Jaya Kumar
2007-02-21 16:46 ` [PATCH 2.6.20 1/1] fbdev,mm: " Jaya Kumar
2007-02-21 16:46 ` Jaya Kumar
2007-02-20 8:07 ` [PATCH 2.6.20 1/1] fbdev, mm: " Geert Uytterhoeven
2007-02-20 8:07 ` [PATCH 2.6.20 1/1] fbdev,mm: " Geert Uytterhoeven
2007-02-20 8:07 ` Geert Uytterhoeven
2007-02-21 16:55 ` Jaya Kumar
2007-02-21 16:55 ` Jaya Kumar
2007-02-21 21:52 ` [PATCH 2.6.20 1/1] fbdev, mm: " James Simmons
2007-02-21 21:52 ` [PATCH 2.6.20 1/1] fbdev,mm: " James Simmons
2007-02-21 21:52 ` James Simmons
2007-02-21 23:22 ` [PATCH 2.6.20 1/1] fbdev, mm: " Jaya Kumar
2007-02-21 23:22 ` [PATCH 2.6.20 1/1] fbdev,mm: " Jaya Kumar
2007-02-21 23:22 ` Jaya Kumar
2007-02-28 16:50 ` [Linux-fbdev-devel] [PATCH 2.6.20 1/1] fbdev, mm: " James Simmons
2007-02-28 16:50 ` James Simmons
2007-02-21 23:43 ` Antonino A. Daplas
2007-02-21 23:43 ` [Linux-fbdev-devel] " Antonino A. Daplas
2007-02-21 23:43 ` Antonino A. Daplas
2007-02-21 23:47 ` Jaya Kumar
2007-02-21 23:47 ` [Linux-fbdev-devel] " Jaya Kumar
2007-02-21 23:47 ` Jaya Kumar
2007-02-21 23:43 ` Antonino A. Daplas [this message]
2007-02-21 23:43 ` Antonino A. Daplas
2007-02-21 23:43 ` Antonino A. Daplas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1172101413.4217.18.camel@daplas \
--to=adaplas@gmail.com \
--cc=Geert.Uytterhoeven@sonycom.com \
--cc=a.p.zijlstra@chello.nl \
--cc=jayakumar.lkml@gmail.com \
--cc=jsimmons@infradead.org \
--cc=lethal@linux-sh.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.