That sounds nice. There are slightly fewer things called
SPU than there are called SPE I imagine? Or is it just a
historical misnomer.
AFAIK SPE is the preferred name, as the SPU is only a part of the SPE.
That's what I was told.
And you were told right. I was trying to be sarcastic
here, b
On Thu, 22 Mar 2007, Segher Boessenkool wrote:
> > BTW folks. Would it be hard to change your spe_ prefixes to
> > something
> > else ? There's already enough confusion between the freescale SPE
> > unit
> > and the cell SPEs :-)
>
> Will you change _your_ prefixes to
BTW folks. Would it be hard to change your spe_ prefixes to
something
else ? There's already enough confusion between the freescale SPE
unit
and the cell SPEs :-)
Will you change _your_ prefixes too? :-) :-)
Which ones ? I'm not in charge of the fsl spe thingy nor the spe
scheduler code :-)
On Wed, Mar 21, 2007 at 09:03:27PM +0100, Segher Boessenkool wrote:
> >>> BTW folks. Would it be hard to change your spe_ prefixes to something
> >>> else ? There's already enough confusion between the freescale SPE
> >>> unit
> >>> and the cell SPEs :-)
> >>
> >> Will you change _your_ prefixes t
BTW folks. Would it be hard to change your spe_ prefixes to something
else ? There's already enough confusion between the freescale SPE
unit
and the cell SPEs :-)
Will you change _your_ prefixes too? :-) :-)
Which ones ? I'm not in charge of the fsl spe thingy nor the spe
scheduler code :-)
On Wed, 2007-03-21 at 15:10 +0100, Segher Boessenkool wrote:
> > BTW folks. Would it be hard to change your spe_ prefixes to something
> > else ? There's already enough confusion between the freescale SPE unit
> > and the cell SPEs :-)
>
> Will you change _your_ prefixes too? :-) :-)
Which ones
BTW folks. Would it be hard to change your spe_ prefixes to something
else ? There's already enough confusion between the freescale SPE unit
and the cell SPEs :-)
Will you change _your_ prefixes too? :-) :-)
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
th
On Tuesday 20 March 2007 04:06, Michael Ellerman wrote:
> On Mon, 2007-03-19 at 17:13 +0100, Benjamin Herrenschmidt wrote:
> > BTW folks. Would it be hard to change your spe_ prefixes to something
> > else ? There's already enough confusion between the freescale SPE unit
> > and the cell SPEs :-)
>
On Mon, 2007-03-19 at 17:13 +0100, Benjamin Herrenschmidt wrote:
> BTW folks. Would it be hard to change your spe_ prefixes to something
> else ? There's already enough confusion between the freescale SPE unit
> and the cell SPEs :-)
>
> (such confusion is annoying when grepp'ing for code that mig
BTW folks. Would it be hard to change your spe_ prefixes to something
else ? There's already enough confusion between the freescale SPE unit
and the cell SPEs :-)
(such confusion is annoying when grepp'ing for code that might touch a
given functionality for example).
Cheers,
Ben.
-
To unsubscri
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
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-
On 3/17/07, Stefan Roese <[EMAIL PROTECTED]> wrote:
Dan,
I just noticed that your patch "dmaengine: add the async_tx api":
@@ -22,6 +22,17 @@ config NET_DMA
Since this is the main user of the DMA engine, it should be enabled;
say Y here.
+config ASYNC_TX_DMA
+ tristat
Hi Dan,
On Friday 16 March 2007 21:00, you wrote:
> Here are some additional comments/nits:
> > +/*
> > + * Init DMA0/1 and XOR engines; allocate memory for DMAx FIFOs; set
> > platform_device + * memory resources addresses
> > + */
> > +static void ppc440spe_configure_raid_devices(void)
>
> Any
Dan,
I just noticed that your patch "dmaengine: add the async_tx api":
@@ -22,6 +22,17 @@ config NET_DMA
Since this is the main user of the DMA engine, it should be enabled;
say Y here.
+config ASYNC_TX_DMA
+ tristate "Asynchronous Bulk Memory Transfers/Transforms API"
Here are some additional comments/nits:
+/*
+ * Init DMA0/1 and XOR engines; allocate memory for DMAx FIFOs; set
platform_device
+ * memory resources addresses
+ */
+static void ppc440spe_configure_raid_devices(void)
Any reason not to move most of this function into spe_adma_probe? The
"set
On 3/16/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> + PRINTK("\tfree slot %x: %d stride: %d\n", desc->phys, desc->idx,
desc->stride);
Why don't you use the kernel existing debugging facilitie, like
pr_debug, or dev_dbg if you have a proper struct device (which you
should have wi
On 3/16/07, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
In message <[EMAIL PROTECTED]> you wrote:
>
> They are in -mm (git-md-accel.patch). I'll review this driver and and
> integrate it into my next push to Andrew, along with some further
> cleanups.
Thanks.
We're doing some cleanup now based on
On Friday 16 March 2007 09:29, Benjamin Herrenschmidt wrote:
> > + /*
> > +* Map registers
> > +*/
> > + i2o_reg = (i2o_regs_t *)ioremap64(I2O_MMAP_BASE, I2O_MMAP_SIZE);
> > + dma_reg0 = (dma_regs_t *)ioremap64(DMA0_MMAP_BASE, DMA_MMAP_SIZE);
> > + dma_reg1 = (dma_regs_t *)ioremap6
Dear Ben,
in message <[EMAIL PROTECTED]> you wrote:
>
> This is all very ugly, hopefully, can be replaced by a proper
> device-tree representation in arch/powerpc. What are your plans for
> porting 440SP/SPe over ?
We will start working on it as soon as we can lay fingers on an
arch/powerp
In message <[EMAIL PROTECTED]> you wrote:
>
> They are in -mm (git-md-accel.patch). I'll review this driver and and
> integrate it into my next push to Andrew, along with some further
> cleanups.
Thanks.
We're doing some cleanup now based on the feedback we receive.
What is easier for you to ha
Hi !
I'm short on time, so no really in-depth review right now, but a few
nits I've spotted while browsing the patch..
> static u64 ppc440spe_adma_dmamask = DMA_32BIT_MASK;
> +
> +/* DMA and XOR platform devices' resources */
> +static struct resource ppc440spe_dma_0_resources[] = {
> + {
> +
On 3/15/07, Paul Mackerras <[EMAIL PROTECTED]> wrote:
Wolfgang Denk writes:
> This patch is based on and requires a set of patches posted to the
> linux-raid mailing list by Dan Williams on 2007-01-23:
Those patches don't seem to be upstream in Linus' tree. Are they in
-mm, or is anyone pushin
Wolfgang Denk writes:
> This patch is based on and requires a set of patches posted to the
> linux-raid mailing list by Dan Williams on 2007-01-23:
Those patches don't seem to be upstream in Linus' tree. Are they in
-mm, or is anyone pushing for them to be?
Paul.
-
To unsubscribe from this list
24 matches
Mail list logo
