upstraming drivers/dma/bcm2835-dma.c

[msperl]

I am trying to upstream drivers/dma/bcm2835-dma.c - especially the slave-portion.

One of the thing that turns up is that upstream wants changes to the code, which I can do.

The question is: how would it filter back to this branched code how can I help making that work smoothly?

[pelwell]

Are they changes that affect other modules, or strictly internal implementation details?

In general, I wouldn't worry about it. We frequently have to merge upstream changes with downstream patches, and the fact that you have contributed both (and thank you for that, Martin) doesn't really change that.

Having said that, if you think the merge may not be trivial then you could send us a patch that gets us from the top of our tree to what you think the final code should look like, and then we can check post-merge that we end up in the right place.

[msperl]

I would take care to upstream patches the same way you did - with the exception that I may move the dma pool in earlier (as I need to merge some of the cyclic and slave code into a single shared piece of code) - anyways: I would do that slightly differently...

My biggest problem is: I can not test the cyclic dma code - no experience how that works and what HW I would need

[pelwell]

An external audio HAT is probably the best way to test cyclic DMA. Several purveyors of fine audio cards frequent these parts - @hifiberry and @iqaudio come to mind.

[hifiberry]

@msperl Contact me at support@hifiberry.com if you need a board for testing purposes.

[pelwell]

@HiassofT may also be able to help with testing.

[msperl]

The biggest thing is the learning-curve of i2s (which obviously requires some of my time)...
@hifiberry: contacting you - I hope it does not require that many jumper-cables, as my dev board is a CM...
@HiassofT may do some independent testing to see that it works...

[hifiberry]

I will send you the DAC+ Light, this one needs only 3 data lines + 5V + GND, no additional I2C connection is needed for this one.

[msperl]

thanks

[clivem]

@msperl You can also ping me with patches if you want any testing done in this specific area. I have a test group comprising a Zero, CM, A+, B+ and 2B, which each have I2S DAC attached, outputting audio 24/7..... Currently running downstream 4.3 plus backport of the dma pool patch from downstream 4.4rc, but can be changed to whatever you want tested.

[iqaudio]

Who needs a board? Happy to ship worldwide :-)

Seasons greetings,

Gordon@iqaudio.com

On 18 Dec 2015, at 08:44, Phil Elwell notifications@github.com wrote:

An external audio HAT is probably the best way to test cyclic DMA. Several purveyors of fine audio cards frequent these parts - @hifiberry and @iqaudio come to mind.

—
Reply to this email directly or view it on GitHub.

[HiassofT]

@msperl just drop me a line if you need some help with testing or if you have questions about the I2S code

Note that there's an unfixed bug in the cyclic DMA code, it would be good to resolve this before upstreaming the code.See #1193

As for testing with upstream: The hifiberry DAC+ light seems to be a good candidate as it has very few external code dependencies. I guess you should get it working if you add the hw_params function plus the .ops definition from the downstream driver to the test code I wrote for testing the dmapool patch
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/387442.html

[HiassofT]

FYI: here's the bcm2835-dma code I'm currently testing with kernel 4.3:
https://gist.github.com/HiassofT/95f073242f19299b4da0

It includes the dmapool patch and I've removed the incorrect period-splitting/rearrangement code from bcm2835_dma_prep_dma_cyclic.

If a period larger than the maximum supported length is requested it errors out. Likewise if the buffer length is not a multiple of period length. This matches the implementation of most other DMA drivers, eg dma-axi-dmac, imx-sdma, mxs-dma - and simplifies the code quite a bit.

So far I haven't run into any issues with these changes, the only requirement is that period_bytes_max in bcm2835-i2s is set up correctly (to 64k-4 bytes).

[clivem]

@HiassofT Now running your latest bcm2835-dma code on 3 of my I2S test group. All looks good so far. I'll switch the others to it tomorrow.

[msperl]

@HiassofT: Reviewing existing patches so that I can argue them (playing a bit of devils advocate):

• why do we switch to dmapool implementation? What is the advantage/arguments/measurements supporting those arguments?
• why is there a different cyclic limit for cyclic DMA channels - I see nothing obvious? Would not: "#define MAX_LITE_TRANSFER (SZ_64K - SZ_K)" work more efficiently? (I can guess about the - 4 byte case - 2 transfers - one of 65532 bytes and one 4 bytes long with the corresponding CB overhead of 64 bytes to load for the control block.)

[HiassofT]

@HiassofT: Reviewing existing patches so that I can argue them (playing a bit of devils advocate):

That's a good idea, let's take the code apart and see if we can find more skeletons in the closet :)

why do we switch to dmapool implementation? What is the advantage/arguments/measurements supporting those arguments?

Since kernel 4.3 dma_free_coherent complains loudly when it's beeing called from interrupt context - which happens when an audio device is closed. Switching to dmapool is one solution to that problem. See discussion here: #1178 (comment)

why is there a different cyclic limit for cyclic DMA channels - I see nothing obvious? Would not: "#define MAX_LITE_TRANSFER (SZ_64K - SZ_K)" work more efficiently? (I can guess about the - 4 byte case - 2 transfers - one of 65532 bytes and one 4 bytes long with the corresponding CB overhead of 64 bytes to load for the control block.)

That was a temporary quick-fix to get rid of clicks during audio playback starting with kernel 4.2. See here: #1153 (comment)

This quick-fix just masked the underlying bugs in the code, but it took a while until I found out what exactly was going wrong.

The cyclic DMA code really shouldn't mess around with the parameters. The userspace application chooses buffer and period sizes within the limits reported by the PCM driver (bcm2835-i2s) so that it can meet it's latency etc constraints - and it relies on the PCM/DMA driver to operate as requested. If it fails to do so you may get buffer over/undderruns, manifesting in clicks or dropouts during recording and other nasty stuff - IOW it may break audio.

I've just PRed my proposed fixes for the 4.4 branch, the bcm2835-dma code is identical to the 4.3 one I uploaded to gist (modulo some whitespace/comment diffs). See here: #1233