On Mon, Oct 17, 2016 at 06:53:52PM +0200, Lars-Peter Clausen wrote:

On 10/17/2016 10:36 AM, Edward Cragg wrote:

...

Hi,

We have an ASoC driver in which we have added support for TDM over an I2S interface.

We would like to have the capability of re-mapping the channel ordering, for which i know there is a callback in place to start this process, set_channel_map.

The only backend implementation of this is using the ALSA API and the .copy handler in an ALSA PCM driver to mutate data copied out of ALSA before it's DMA'd to hardware. This is in sound/soc/blackfin/bf5xx-i2s-pcm.c

The problem we have is that the driver we're using currently uses a dmaengine based PCM driver, and i'm not sure whether this is compatible with using the .copy callback, without reimplementing the driver entirely as an ALSA PCM driver.

Since there aren't very many examples in mainline, I was hoping to ask for advice for the best way of doing this.

I wondered:

• Would it be possible to add a functional copy callback using a dmaengine based PCM driver?
• Otherwise, would there be a good way to implement channel remapping in a TDM frame using the dmaengine based PCM driver? or
• Would the best way indeed be to reimplement the PCM driver as a normal ALSA PCM driver?

Does your hardware support re-mapping? Or is this something you want to do in the same style as the blackfin driver by having the kernel shuffle all the samples around? If it is the later I'd recommend to implement this in userspace. The general idea for kernel drivers is to advertise the hardware capabilities, but not go beyond them and emulate missing functionality since this can have unexpected performance impacts. (And yes, the Blackfin driver should have never been implemented the way it is)

As far as I can see, the hardware doesn't support re-mapping.

I'd rather not have to do something like that, and would prefer to do something upstreamable with the rest of the extra functionality we've developed with this driver. I'm glad for the clarification that drivers shouldn't implement such extra functionality.

It would indeed be quite trivial to implement the mapping in userspace, but we have an unusual situation where we are trying to reimplement the behaviour of an existing kernel using upstream, while not being able to modify userspace. Either way, it seems that this is something that is happening either in the kernel or hardware.

After some investigation, it has turned out that the re-mapping seems to be a word-swap of 16-bit samples within successive 32-bit segments of the data, such that the channel ordering we require is 2,1,4,3,6,5,8,7 but with mainline we're currently seeing 1,2,3,4,5,6,7,8. The only conclusion we can draw is that it's something to do with the Tegra30 hardware we have, which needs some further scrutiny.

Thanks,

Ed