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
Could you make it work without the framebuffer. There are embedded LCD
displays that have internal memory that need data flushed to them.
On Wed, 21 Feb 2007, Jaya Kumar wrote:
> On 2/20/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> > Don't you need a way to specify the maximum deferral
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
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.
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
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 =
Could you make it work without the framebuffer. There are embedded LCD
displays that have internal memory that need data flushed to them.
On Wed, 21 Feb 2007, Jaya Kumar wrote:
On 2/20/07, Geert Uytterhoeven [EMAIL PROTECTED] wrote:
Don't you need a way to specify the maximum deferral time?
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
On Mon, 19 Feb 2007, 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.
> >
On Mon, 19 Feb 2007, 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
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
On Mon, Feb 19, 2007 at 11:13:04PM -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
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
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
On Mon, Feb 19, 2007 at 11:13:04PM -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
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.
On Sun, Feb 18, 2007 at 06:31:23AM -0500, Jaya Kumar wrote:
> On 2/17/07, Paul Mundt <[EMAIL PROTECTED]> wrote:
> >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
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
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
On Sun, Feb 18, 2007 at 06:31:23AM -0500, Jaya Kumar wrote:
On 2/17/07, Paul Mundt [EMAIL PROTECTED] wrote:
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
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
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
>
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
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
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
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
26 matches
Mail list logo
