LKML Archive on
help / color / mirror / Atom feed
From: Paul Mundt <>
To: Jaya Kumar <>
Cc: Peter Zijlstra <>,,,
Subject: Re: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
Date: Mon, 19 Feb 2007 08:57:41 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, Feb 18, 2007 at 06:31:23AM -0500, Jaya Kumar wrote:
> On 2/17/07, Paul Mundt <> 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 be nice to have. There's more
> >than a few drivers that could take advantage of that.
> 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?
Yes, that's what I'm interested in trying. In the SH case we can
basically make use of the on-chip DMAC for any non-PCI device. Some of
these permit scatterlists and chained DMA in hardware, others do not. The
general problem is that since we have to go and poke at the dcache prior
to kicking off the DMA, it's rarely a win for a small number of pages,
memory bursts just end up being faster.

The other issue is that most of the "big" writers are doing so via mmap()
anyways, so it's futile to attempt to handle the DMA case in the
->write() path. Your approach seems like it might be an appropriate
interface for building something like this on top of.

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.

  reply	other threads:[~2007-02-18 23:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-17 10:42 Jaya Kumar
2007-02-17 12:34 ` Peter Zijlstra
2007-02-17 13:25   ` Jaya Kumar
2007-02-17 13:59     ` Paul Mundt
2007-02-18 11:31       ` Jaya Kumar
2007-02-18 23:57         ` Paul Mundt [this message]
2007-02-20  4:13           ` Jaya Kumar
2007-02-20  4:38             ` Paul Mundt
2007-02-20  6:11               ` Jaya Kumar
2007-02-21 16:46                 ` Jaya Kumar
2007-02-20  8:07             ` Geert Uytterhoeven
2007-02-21 16:55               ` Jaya Kumar
2007-02-21 21:52                 ` James Simmons
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-21 23:43                 ` Antonino A. Daplas
2007-02-21 23:47                   ` Jaya Kumar
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).