Re: ASoC TDM channel re-mapping

[Edward Cragg <edward.cragg@codethink.co.uk>]

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