Porting plat-pxa to the MMP PDMA driver

Porting plat-pxa to the MMP PDMA driver

[Laurent Pinchart]

Hello,

The MMP DMA (drivers/dma/mmap_pdma.c) driver supports the DMA engine found in 
PXA chips. However, PXA platforms still use a mix of custom platform code 
(arch/arm/plat-pxa/dma.c) and direct DMA controller access in various drivers 
(pata_pxa, spi-pxa2xx, pxa3xx_nand, pxaficp_ir, pxamci, smc91x, smc911x and 
pxa_camera).

I'd like to use the MMP PDMA driver through the DMA engine API in a new driver 
I'm writing instead of the legacy PXA DMA code. However, this requires porting 
the platform to the MMP PDMA driver first, which involves porting all the 
above drivers to the DMA engine API. The spi-pxa2xx driver has already been 
ported and currently supports both the legacy PXA DMA API and the DMA engine 
API. All the other drivers seem to require the legacy PXA DMA API.

I was wondering if any effort had been started in that direction. I could 
possibly help with the pxamci driver, but not with the other drivers as the 
corresponding peripherals are not used on my test platform (a custom PXA27x 
board).

-- 
Regards,

Laurent Pinchart

Porting plat-pxa to the MMP PDMA driver

[Daniel Mack]

Hi Laurent,

(copying some more people)

On 04/07/2014 03:12 PM, Laurent Pinchart wrote:
> The MMP DMA (drivers/dma/mmap_pdma.c) driver supports the DMA engine found in 
> PXA chips. However, PXA platforms still use a mix of custom platform code 
> (arch/arm/plat-pxa/dma.c) and direct DMA controller access in various drivers 
> (pata_pxa, spi-pxa2xx, pxa3xx_nand, pxaficp_ir, pxamci, smc91x, smc911x and 
> pxa_camera).
> 
> I'd like to use the MMP PDMA driver through the DMA engine API in a new driver 
> I'm writing instead of the legacy PXA DMA code. However, this requires porting 
> the platform to the MMP PDMA driver first, which involves porting all the 
> above drivers to the DMA engine API. The spi-pxa2xx driver has already been 
> ported and currently supports both the legacy PXA DMA API and the DMA engine 
> API. All the other drivers seem to require the legacy PXA DMA API.
>
> I was wondering if any effort had been started in that direction. I could 
> possibly help with the pxamci driver, but not with the other drivers as the 
> corresponding peripherals are not used on my test platform (a custom PXA27x 
> board).

Yes, I've started working on this a long time ago, but got stuck because
of the lack of support from users, as I don't have hardware with all
possible DMA-capable components in use. Have a look here, the tree
should be easily rebasable onto newer versions:

  https://github.com/zonque/linux/tree/pxa-dma-v3

* I ported some drivers blindly, and Marek Vasut reported success on the
pxa-pata driver.

* The spi-driver just works thanks to previous preparations.

* The mmc driver seems to work, but people reported significant
performance loss in comparison to the current code.

* I ported over the ASoC drivers so the dma framework can be used as
drop-in replacement. One patch for mmp-pdma residue reporting is pending
though, I need to get back to Vinod on that.

* One thing that was especially tricky to port was the camera driver,
and Robert wasn't sure whether the type of DMA hot-linking which his
driver does was at all doable with the DMA framework as it stands.


Which PXA based hardware can you get your hands on for testing? It would
be good to get some movement into this topic again :)


Thanks,
Daniel

Porting plat-pxa to the MMP PDMA driver

[Mark Brown]

On Mon, Apr 07, 2014 at 03:25:19PM +0200, Daniel Mack wrote:
> On 04/07/2014 03:12 PM, Laurent Pinchart wrote:

> > I'm writing instead of the legacy PXA DMA code. However, this requires porting 
> > the platform to the MMP PDMA driver first, which involves porting all the 
> > above drivers to the DMA engine API. The spi-pxa2xx driver has already been 
> > ported and currently supports both the legacy PXA DMA API and the DMA engine 
> > API. All the other drivers seem to require the legacy PXA DMA API.

> > I was wondering if any effort had been started in that direction. I could 
> > possibly help with the pxamci driver, but not with the other drivers as the 
> > corresponding peripherals are not used on my test platform (a custom PXA27x 
> > board).

> Yes, I've started working on this a long time ago, but got stuck because
> of the lack of support from users, as I don't have hardware with all
> possible DMA-capable components in use. Have a look here, the tree
> should be easily rebasable onto newer versions:

Is it not possible to do what we're doing with the Samsung platforms and
have both platform and generic DMA code in the source, selected via a
Kconfig symbol?  That way you don't have to have a flag day.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140407/fa32b3aa/attachment.sig>

Porting plat-pxa to the MMP PDMA driver

[Daniel Mack]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/07/2014 04:02 PM, Mark Brown wrote:
> On Mon, Apr 07, 2014 at 03:25:19PM +0200, Daniel Mack wrote:
>> On 04/07/2014 03:12 PM, Laurent Pinchart wrote:
> 
>>> I'm writing instead of the legacy PXA DMA code. However, this
>>> requires porting the platform to the MMP PDMA driver first,
>>> which involves porting all the above drivers to the DMA engine
>>> API. The spi-pxa2xx driver has already been ported and
>>> currently supports both the legacy PXA DMA API and the DMA
>>> engine API. All the other drivers seem to require the legacy
>>> PXA DMA API.
> 
>>> I was wondering if any effort had been started in that
>>> direction. I could possibly help with the pxamci driver, but
>>> not with the other drivers as the corresponding peripherals are
>>> not used on my test platform (a custom PXA27x board).
> 
>> Yes, I've started working on this a long time ago, but got stuck
>> because of the lack of support from users, as I don't have
>> hardware with all possible DMA-capable components in use. Have a
>> look here, the tree should be easily rebasable onto newer
>> versions:
> 
> Is it not possible to do what we're doing with the Samsung
> platforms and have both platform and generic DMA code in the
> source, selected via a Kconfig symbol?  That way you don't have to
> have a flag day.

Not sure whether I'm following, but on PXA, the DMA controller can
either be used by the old framework or the new driver, and so users
can't choose which one to use. I thought about a macro hack to make
the transition easier, but that seems impossible to do.

Sure, we could keep implementations for both environments around, but
chances are that we'll never get rid of the old cruft at all then.
Also, for most drivers that means lots of code duplication.


Regards,
Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTQrIMAAoJELphMRr8Y1QkSzwP/3kAIGICW9nkst6Bx4Bb5xty
ACm0cexJCcS739IBB5ztSUGQaNPtB+d1js44TNU0maTmKrsjeVUBLzHYtz8DXezM
cJTWOodbqpzKVEanjOZiGLa7EWIyFdTjdaqzCzaRtxl4YSFeghF0H+PwQxrnzVq3
qHFWelsuXFOC3S3F6Mf4DfAf3JCVV681BqYFXEqnP92NcaYIrUnTwnCPSPtEIbPh
nNq+9r6nDVfEd8PLAAvMcwtWYPhD+ECg86zH/sdfTTNCwtEW59tHCm1mUxY3MhOR
jYCCvTBzL2DZuucdp1pxyifoIaQ3qjLc5kl0/cPZQ+j0aREnAgMewiJxbR/DR8SL
j84wHeYeudu/aPdNdfR3lvN00quyh3+K3uvLtjcBgpS2NLtwiA63PelmdG0RUUpI
mM5/X4z4cGFwQYjS+zF1oIplDqfeWoppd/hJWUco4TUn+SlAOjr2MX3zHR31Sr5t
E+RbQcsO3D/msNY+fMHk36LqK9zNAOacJR/Pw/8euJ0sr2tl5SBEpao2Lf81TvGr
6t7ufZ/xQ5PxUQUb7Fbe6/7snq+ECaR64DqMg6JXiU8tuPbJl5+HQ6oJSMuU8fCt
AUA4gvNG3spxH18CIy8pYlyNve4oHT0b+TBGaYGd7tQCsRN77eXLh0erbNK+GwFE
qA8hY3PJA1uhD1n4fOKY
=dkRF
-----END PGP SIGNATURE-----

Porting plat-pxa to the MMP PDMA driver

[Mark Brown]

On Mon, Apr 07, 2014 at 04:11:24PM +0200, Daniel Mack wrote:
> On 04/07/2014 04:02 PM, Mark Brown wrote:

> > Is it not possible to do what we're doing with the Samsung
> > platforms and have both platform and generic DMA code in the
> > source, selected via a Kconfig symbol?  That way you don't have to
> > have a flag day.

> Not sure whether I'm following, but on PXA, the DMA controller can
> either be used by the old framework or the new driver, and so users
> can't choose which one to use. I thought about a macro hack to make
> the transition easier, but that seems impossible to do.

That's exactly what Samsung have too - an old API and dmaengine as
either/or options.

> Sure, we could keep implementations for both environments around, but
> chances are that we'll never get rid of the old cruft at all then.
> Also, for most drivers that means lots of code duplication.

At least with Samsung the transition has mostly happened, it's been
taking a long time but there's progress and it means that platforms that
are actively being worked on get to use the new stuff.  The code
duplication is a pain point but it's less painful than having to
transition the entire platform at once when it's difficult to get people
to care.  It makes it easier to maintian forward motion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140407/20c91c88/attachment.sig>

Porting plat-pxa to the MMP PDMA driver

[Laurent Pinchart]

Hi Daniel,

On Monday 07 April 2014 15:25:19 Daniel Mack wrote:
> Hi Laurent,
> 
> (copying some more people)
> 
> On 04/07/2014 03:12 PM, Laurent Pinchart wrote:
> > The MMP DMA (drivers/dma/mmap_pdma.c) driver supports the DMA engine found
> > in PXA chips. However, PXA platforms still use a mix of custom platform
> > code (arch/arm/plat-pxa/dma.c) and direct DMA controller access in
> > various drivers (pata_pxa, spi-pxa2xx, pxa3xx_nand, pxaficp_ir, pxamci,
> > smc91x, smc911x and pxa_camera).
> > 
> > I'd like to use the MMP PDMA driver through the DMA engine API in a new
> > driver I'm writing instead of the legacy PXA DMA code. However, this
> > requires porting the platform to the MMP PDMA driver first, which
> > involves porting all the above drivers to the DMA engine API. The
> > spi-pxa2xx driver has already been ported and currently supports both the
> > legacy PXA DMA API and the DMA engine API. All the other drivers seem to
> > require the legacy PXA DMA API.
> > 
> > I was wondering if any effort had been started in that direction. I could
> > possibly help with the pxamci driver, but not with the other drivers as
> > the corresponding peripherals are not used on my test platform (a custom
> > PXA27x board).
> 
> Yes, I've started working on this a long time ago, but got stuck because
> of the lack of support from users, as I don't have hardware with all
> possible DMA-capable components in use. Have a look here, the tree
> should be easily rebasable onto newer versions:
> 
>   https://github.com/zonque/linux/tree/pxa-dma-v3

Thank you, that's helpful.

> * I ported some drivers blindly, and Marek Vasut reported success on the
> pxa-pata driver.
> 
> * The spi-driver just works thanks to previous preparations.
> 
> * The mmc driver seems to work, but people reported significant
> performance loss in comparison to the current code.

I'll try to test it.

> * I ported over the ASoC drivers so the dma framework can be used as
> drop-in replacement. One patch for mmp-pdma residue reporting is pending
> though, I need to get back to Vinod on that.
> 
> * One thing that was especially tricky to port was the camera driver,
> and Robert wasn't sure whether the type of DMA hot-linking which his
> driver does was at all doable with the DMA framework as it stands.
> 
> 
> Which PXA based hardware can you get your hands on for testing? It would
> be good to get some movement into this topic again :)

I only have access to a custom pxa27x board. I'm working on a driver for an 
FPGA-based device that requires DMA in fly-by mode, so I'll need to implement 
support for that in the mmp_pdma driver.

-- 
Regards,

Laurent Pinchart