We'd also have to make sure that the comparison is between the linux-omap
kernel and the OMAPZoo kernel, rather than o-z PIO vs. o-z DMA. The
OMAPZoom kernel doesn't post any device register writes. That should
cause any driver using PIO to drag, compared to the l-o kernel.
There effetely
David Hagood wrote:
Well, that's not what I would have expected - I would have thought
reads on POP would have been faster than that, and cheaper - the SD
being the same speed but less CPU is surprising.
1. As Russ and David said, OneNAND driver does not really
use DMA, because the I/O is done
On Mon, Apr 6, 2009 at 12:41 AM, Artem Bityutskiy dedek...@yandex.ru wrote:
David Hagood wrote:
Well, that's not what I would have expected - I would have thought
reads on POP would have been faster than that, and cheaper - the SD
being the same speed but less CPU is surprising.
1. As Russ
Russ Dill wrote:
On Mon, Apr 6, 2009 at 12:41 AM, Artem Bityutskiy dedek...@yandex.ru wrote:
David Hagood wrote:
Well, that's not what I would have expected - I would have thought
reads on POP would have been faster than that, and cheaper - the SD
being the same speed but less CPU is
On Monday 06 April 2009, Russ Dill wrote:
Also, it appears from looking an the openzoom git, there are some
patches to add DMA support in, but I'm not sure what effect they have.
We had asked for some benchmark data -- anything! -- to get a
handle on that, and the prefetch/etc engine; nothing
On Mon, 6 Apr 2009, David Brownell wrote:
I'd think the first thing to check is two linux-omap PIO flavors:
with vs without the prefetch/postwrite engine. Benchmarking DMA
would be a separate issue. Ditto comparing kernels with/without
write posting.
Makes sense to me. FIFO-less GPMC PIO
On Monday 06 April 2009, Paul Walmsley wrote:
Puzzle: get a dma_copypage() to work faster than copy_page().
Or a dma_clear_page() faster than clear_page(). Not easy...
Doing it via the DMA engine may save power, since MPU can sleep.
But the CPU overhead of calling the DMA engine can
Hi David
On Mon, 6 Apr 2009, David Brownell wrote:
On Monday 06 April 2009, Russ Dill wrote:
Also, it appears from looking an the openzoom git, there are some
patches to add DMA support in, but I'm not sure what effect they have.
We had asked for some benchmark data -- anything! -- to
On Monday 06 April 2009, Paul Walmsley wrote:
Hi David
On Mon, 6 Apr 2009, David Brownell wrote:
On Monday 06 April 2009, Russ Dill wrote:
Also, it appears from looking an the openzoom git, there are some
patches to add DMA support in, but I'm not sure what effect they have.
We
On Friday 03 April 2009, Russ Dill wrote:
On Fri, Apr 3, 2009 at 7:52 PM, David Hagood david.hag...@gmail.com wrote:
Well, that's not what I would have expected - I would have thought
reads on POP would have been faster than that, and cheaper - the SD
being the same speed but less CPU is
Has anybody done any benchmarking on POP flash read/write speeds (using
JFFS2) vs. MMC/SDHC card access (using ext[234])? Or for that matter, has
anybody done any playing around with using the execute in place function
of JFFS2 to see if there is any over-all speed advantage (due to reduced
On Fri, Apr 3, 2009 at 2:24 PM, david.hag...@gmail.com wrote:
Has anybody done any benchmarking on POP flash read/write speeds (using
JFFS2) vs. MMC/SDHC card access (using ext[234])? Or for that matter, has
anybody done any playing around with using the execute in place function
of JFFS2 to
Well, that's not what I would have expected - I would have thought reads on POP
would have been faster than that, and cheaper - the SD being the same speed but
less CPU is surprising.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On Fri, Apr 3, 2009 at 7:52 PM, David Hagood david.hag...@gmail.com wrote:
Well, that's not what I would have expected - I would have thought reads on
POP would have been faster than that, and cheaper - the SD being the same
speed but less CPU is surprising.
The POP flash may not have a DMA
14 matches
Mail list logo
