From: Stefan Roese <sr@denx.de>
To: linuxppc-dev@ozlabs.org
Cc: Dan Williams <dan.j.williams@intel.com>, linux-raid@vger.kernel.org
Subject: Re: [PATCH] [PPC32] ADMA support for PPC 440SPe processors.
Date: Sat, 17 Mar 2007 19:43:27 +0100 [thread overview]
Message-ID: <200703171943.27465.sr@denx.de> (raw)
In-Reply-To: <e9c3a7c20703171117w7989adfehda99416265eef906@mail.gmail.com>
On Saturday 17 March 2007 19:17, Dan Williams wrote:
> Yes, defaulting to 'y' is not necessary, but ASYNC_TX_DMA=y &&
> DMA_ENGINE=n is an explicit feature of the interface. When DMA_ENGINE
> is not selected all the asynchronous paths in the API are compiled
> out. This allows subsytems, like md-raid5, to be written in an
> asynchronous fashion without regard for the architecture[1] or
> availability of offload engines.
The current implementation builds on my embedded PPC4xx system without any
disks the objects async_tx.o and xor.o into the kernel which I definitely
don't need and want. And I get something like:
async_tx: api initialized (sync-only)
xor: measuring software checksumming speed
8regs : 145.000 MB/sec
8regs_prefetch: 115.000 MB/sec
32regs : 176.000 MB/sec
32regs_prefetch: 135.000 MB/sec
xor: using function: 32regs (176.000 MB/sec)
upon bootup.
Best regards,
Stefan
WARNING: multiple messages have this Message-ID (diff)
From: Stefan Roese <sr@denx.de>
To: linuxppc-dev@ozlabs.org
Cc: linux-raid@vger.kernel.org, Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCH] [PPC32] ADMA support for PPC 440SPe processors.
Date: Sat, 17 Mar 2007 19:43:27 +0100 [thread overview]
Message-ID: <200703171943.27465.sr@denx.de> (raw)
In-Reply-To: <e9c3a7c20703171117w7989adfehda99416265eef906@mail.gmail.com>
On Saturday 17 March 2007 19:17, Dan Williams wrote:
> Yes, defaulting to 'y' is not necessary, but ASYNC_TX_DMA=y &&
> DMA_ENGINE=n is an explicit feature of the interface. When DMA_ENGINE
> is not selected all the asynchronous paths in the API are compiled
> out. This allows subsytems, like md-raid5, to be written in an
> asynchronous fashion without regard for the architecture[1] or
> availability of offload engines.
The current implementation builds on my embedded PPC4xx system without any
disks the objects async_tx.o and xor.o into the kernel which I definitely
don't need and want. And I get something like:
async_tx: api initialized (sync-only)
xor: measuring software checksumming speed
8regs : 145.000 MB/sec
8regs_prefetch: 115.000 MB/sec
32regs : 176.000 MB/sec
32regs_prefetch: 135.000 MB/sec
xor: using function: 32regs (176.000 MB/sec)
upon bootup.
Best regards,
Stefan
next prev parent reply other threads:[~2007-03-17 18:43 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-15 23:29 [PATCH] [PPC32] ADMA support for PPC 440SPe processors Wolfgang Denk
2007-03-16 5:27 ` Paul Mackerras
2007-03-16 5:27 ` Paul Mackerras
2007-03-16 5:55 ` Dan Williams
2007-03-16 5:55 ` Dan Williams
2007-03-16 10:16 ` Wolfgang Denk
2007-03-16 10:16 ` Wolfgang Denk
2007-03-16 16:33 ` Dan Williams
2007-03-16 16:33 ` Dan Williams
2007-03-16 8:29 ` Benjamin Herrenschmidt
2007-03-16 8:29 ` Benjamin Herrenschmidt
2007-03-16 10:23 ` Wolfgang Denk
2007-03-16 10:23 ` Wolfgang Denk
2007-03-16 12:44 ` Stefan Roese
2007-03-16 16:57 ` Dan Williams
2007-03-16 16:57 ` Dan Williams
2007-03-16 18:00 ` Dan Williams
2007-03-16 18:00 ` Dan Williams
2007-03-17 8:09 ` Stefan Roese
2007-03-17 8:09 ` Stefan Roese
2007-03-17 18:17 ` Dan Williams
2007-03-17 18:17 ` Dan Williams
2007-03-17 18:43 ` Stefan Roese [this message]
2007-03-17 18:43 ` Stefan Roese
2007-03-17 19:09 ` Dan Williams
2007-03-17 19:09 ` Dan Williams
2007-03-19 16:13 ` Benjamin Herrenschmidt
2007-03-19 16:13 ` Benjamin Herrenschmidt
2007-03-20 3:06 ` Michael Ellerman
2007-03-20 3:06 ` Michael Ellerman
2007-03-20 5:39 ` Stefan Roese
2007-03-20 5:39 ` Stefan Roese
2007-03-21 14:10 ` Segher Boessenkool
2007-03-21 14:10 ` Segher Boessenkool
2007-03-21 19:55 ` Benjamin Herrenschmidt
2007-03-21 19:55 ` Benjamin Herrenschmidt
2007-03-21 20:03 ` Segher Boessenkool
2007-03-21 20:03 ` Segher Boessenkool
2007-03-22 11:38 ` Christoph Hellwig
2007-03-22 11:38 ` Christoph Hellwig
2007-03-22 12:36 ` Segher Boessenkool
2007-03-22 12:36 ` Segher Boessenkool
2007-03-22 13:20 ` Geert Uytterhoeven
2007-03-22 13:20 ` Geert Uytterhoeven
2007-03-22 13:38 ` Segher Boessenkool
2007-03-22 13:38 ` Segher Boessenkool
2007-03-17 8:57 ` Yuri Tikhonov
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=200703171943.27465.sr@denx.de \
--to=sr@denx.de \
--cc=dan.j.williams@intel.com \
--cc=linux-raid@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.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.