[PATCH 5/9] ARM: dts: provide DMA config to pxamci

Sergei Ianovich
2013-12-09T13:16:37Z

On Mon, 2013-12-09 at 11:21 +0100, Daniel Mack wrote:
> On 12/09/2013 10:34 AM, Sergei Ianovich wrote:
> > On Mon, 2013-12-09 at 10:04 +0100, Daniel Mack wrote:
> >> On 12/09/2013 02:33 AM, Arnd Bergmann wrote:
> >>> It hasn't made it upstream yet, but see http://list-archives.org/2013/08/07/linux-mtd-lists-infradead-org/patch-00-20-arm-pxa-move-core-and-drivers-to-dmaengine/f/3444199144
> >>> for how it's done. Maybe Daniel can comment on the status of his
> >>> patches.
> >>
...
> The only real problem is the PXA camera driver, which does tricky things
> like hot re-queuing of DMA descriptors. That one needs fixing before the
> series can land.

My impression is that his series is hard to land. I've expressed my
concerns about big changes in a separate mail.

PXA device tree support issue is practically orthogonal. As of August
2013, Daniel's dma series doesn't add any dt support. After new DMA is
working, we will need to add dt support in the same drivers.

Basically we have three options:
A. Wait for Daniel DMA, than for PXA clock, than do dt support
pros:
* correct order
cons:
* need to wait, possibly a long time
* dt boot not possible, while we wait

B. Provide 'hackish' support to dt, than correct hacks when DMA is
merged.
pros:
* parallel development
* healthier kernel code (current PXA usb driver won't compile with dt
enabled)
cons:
* wrong concept (like my patch 5/9) until DMA is working
* need to recompile dtb files when kernel changes

C. Use 'fake' DMA provider dt binding to emulate existing DMA until new
DMA is merged, than
pros:
* parallel development
* healthier kernel code
* correct device trees from the beginning
cons:
* more work
* still need to recompile dtbs when clock support is merged

Any ideas?