ARM: pxa: move core and drivers to dmaengine
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest2 of 20 patches 0 repliesNew
2 of 20 patches are in this archive. The cover letter announces 20.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 4/20 | ARM: pxa: ssp: add DT bindings | +0 | 0 replies | |
| 9/20 | ata: pdata_pxa: migrate over to dmaengine usage | +0 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 00/20] ARM: pxa: move core and drivers to dmaengine
Quoted 20 lines · Daniel Mack
I've been working on teaching the mmp-pdma driver more functions and porting tree-wide scattered pxa specific drivers over to dmaengine implementations. I posted the first round of patches for mmp-pdma here:
http://marc.info/?l=linux-arm-kernel&m=137587082530228
With the following patches applied, I can boot a PXA3xx board boot with all DMA runtime information determined from DT, using pxa3xx-nand, pxamci and audio components (cyclic DMA).
However, the transition is quite intrusive and spans across several subsystem, and due to the nature of the current pxa DMA implementation, it cannot be gap-less. All drivers currently request an exclusive channel via code in
arch/arm/plat-pxa/dma.cand then do direct register modifications regarding their obtained channel. We can't allow this with the mmp-pdma driver of course, and I also have no idea how to provide sane stubs for the existing hooks which end up in dmaengine calls.
Quoted 4 lines
Hence, all drivers have to be ported over in one series, and all these changes should be merged by one pull request eventually in order to prevent both build and functional breakage. Haojian's repository seems most suitable for that, as he's the PXA maintainer.
Very nice series! I just looked over these and only found a few minor details that could be improved.
Arnd