[alsa-devel] [PATCH 2/7] MFD: add STM32 DFSDM support

[Arnaud Pouliquen]

Hello Lars,

On 01/29/2017 03:19 PM, Lars-Peter Clausen wrote:
> On 01/29/2017 01:28 PM, Jonathan Cameron wrote:
> [...]
>>>> Jonathan, Mark, Please could you share your opinion on this topic?
>> Hmm - based on a fairly quick read through of the code (which is never
>> ideal!). I can see that the ideal would indeed be as Lee says, to
>> expand the IIO interfaces sufficiently to support what you need.
>>
>>
>> So, reading the code (fairly quickly I'm afraid as had a lot of reviews
>> to catch up on this weekend).
>> What we need:
>> 1) DMA support in the ADC driver.  This would be a good anyway!
>> 2) DMA consumer support - I defer to Lars for comments on this.
>> 3) Means of describing and controlling the sinc filters applied. 
>> 4) Appropriate channel support.  I'm not convinced that it doesn't make
>> sense to have IIO channels for the microphones - at least in a streaming
>> mode.  It's data - I don't really care what ;)
>> Coarsely it's a filtered pulse per period counter which is
>> a perfectly valid type to have a channel for.
>>
>> The big question to my mind is the DMA consumer support. How would
>> it work. It it wouldn't this is somewhat of a non starter.
>>
>> To bring up another slightly ugly MFD case where it is borderline
>> on whether an MFD makes sense (just as a reference point of something
>> we have discussed a few times before)
>>
>> ADCs with features directed at touchscreen support.
>> These are odd as the ADC bit is generic, but the specific output
>> and read sequences used for touchscreen reading don't correspond to
>> anything that makes any real sense for other applications.
>>
>> We have started to get hybrid drives that have an MFD underneath but
>> do the ADC reads through IIO consumer interfaces, and the timing
>> control from a touchscreen driver.  We haven't really gotten this
>> one right yet either.
>>
>> Here however, to my mind things are different - as I read it
>> (and feel free to point out what I'm missing), the sound usecase
>> is just a question of setting up sampling frequencies and filters
>> appropriate to the microphones and what ASoC expects?
>>
>> That's not to say the IIO dma stuff is flexible enough (yet) to
>> handle the data flows, but perhaps we can work towards that.
> 
> Yeah, so this is a bit different, but not unexpected. And I'm sure we'll see
> more similar hardware in the future. I've talked about this before[1], the
> cost structure of creating and manufacturing new hardware drives the design
> in a certain direction so that we end up with general purpose hardware that
> suddenly has applications in multiple frameworks that were previously fully
> orthogonal.
> 
> This device is certainly not a multi-function-device. It only has one
> function, it's a sigma-delta demodulator. It is rather a
> multi-purpose-device. It can be used for sigma-delta demodulation in audio
> applications as well as more specialized data capture applications.
> 
> It's comparable to something like a GPIO that can be used to control a reset
> pin or turn on and off a LED. The GPIO chip is not considered
> multi-function-device though, even though it can be used for many different
> applications.
> 
> As for DMA we already have a lot of DMA infrastructure on the audio side and
> we probably want to reuse that rather than inserting IIO as a middle layer
> since audio buffer capture as different requirements from IIO buffer and
> we'd have to go the route of the least common denominator and loose
> expressibility in the process.

I'm agree with your analysis.
Audio DMA engine seems a more secure solution to avoid audio runtime
issue, and should minimize impact in IIO.

> 
> I've created a IIO buffer[2] that does not capture data to memory but is
> only used to enable/disable the data capture process. We use this in setups
> where the data is passed from the converter to a application specific
> processing chain without ever going through system memory. This buffer could
> probably also be used here on the audio side to control the converter state.

This remind me HDMI.
For HDMI, solution integrated is a drm driver that probes
"hdmi-audio-codec" driver.

Something similar could be done. An IIO device that probes a generic DAI
ASoC driver. Driver data structure should be used to provide DMA config
and IIO device phandles. Then DAI drivers could use your "hw_consummer"
interface to control iio device...

> 
> - Lars
> 
> [1]
> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-July/003029.html
> 
> [2]
> https://github.com/analogdevicesinc/linux/blob/xcomm_zynq/drivers/iio/buffer/hw_consumer.c
> 

Regards
Arnaud