Code base for rework of ppc440SPe ADMA driver

Code base for rework of ppc440SPe ADMA driver

[Anatolij Gustschin]

Hello Dan,

Currently I am trying to estimate efforts for rework of the
ppc440SPe ADMA driver for inclusion in mainline Linux and a couple of
questions have arisen. As the current ASYNC_TX API in mainline Linux
doesn't contain support for RAID6 offload operations, the current
ppc440SPe ADMA driver have to be reworked to support RAID5 operations
only which would be a step backward and also would require some
changes in the ASYNC_TX code to cope with large dma_addr_t addresses.
Therefore my understanding is that the rework of the ADMA driver for
inclusion in mainline should be better based on code from your raid6
branch. Or what would be a better base?

If I understand it correctly initially the intention was to place
this work in linux-next and probably submit a pull request towards
the end of the 2.6.31 merge window. Is there any plan to proceed with
this?  Did you get a chance to look at per-cpu implementation for the
scribble-buffer?

Thanks,
Anatolij

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office@denx.de

Re: Code base for rework of ppc440SPe ADMA driver

[Dan Williams]

On Wed, Aug 19, 2009 at 6:49 AM, Anatolij Gustschin<agust@denx.de> wrote:
> Hello Dan,
>
> Currently I am trying to estimate efforts for rework of the
> ppc440SPe ADMA driver for inclusion in mainline Linux and a couple of
> questions have arisen. As the current ASYNC_TX API in mainline Linux
> doesn't contain support for RAID6 offload operations, the current
> ppc440SPe ADMA driver have to be reworked to support RAID5 operations
> only which would be a step backward and also would require some
> changes in the ASYNC_TX code to cope with large dma_addr_t addresses.
> Therefore my understanding is that the rework of the ADMA driver for
> inclusion in mainline should be better based on code from your raid6
> branch. Or what would be a better base?
>
> If I understand it correctly initially the intention was to place
> this work in linux-next and probably submit a pull request towards
> the end of the 2.6.31 merge window. Is there any plan to proceed with
> this?  Did you get a chance to look at per-cpu implementation for the
> scribble-buffer?

Yes, this work is still progressing and I am planning a new drop of
the patches to the mailing list Real Soon Now TM.  I have just now
updated the raid6 branch [1] with the latest snapshot of the code.
You can start basing your update on this branch.  Note, it might
rebase as I receive review feedback, but I do not expect the dma
driver interface to change from this point.

This includes the percpu conversion of the scribble buffer [2], and a
new patch I am not sure about yet "multicore raid processing" [3].

--
Dan

[1]: git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git raid6
[2]: http://git.kernel.org/?p=linux/kernel/git/djbw/async_tx.git;a=commitdiff;h=d02774cc58b8d80d66d49efe541afa727f6a5f15
[3]: http://git.kernel.org/?p=linux/kernel/git/djbw/async_tx.git;a=commitdiff;h=a8882290f39a97ea3d16aa9bee309097d9c54abd
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html