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

[Arnaud Pouliquen]

On 01/27/2017 06:17 PM, Lee Jones wrote:
> On Fri, 27 Jan 2017, Arnaud Pouliquen wrote:
>> On 01/27/2017 11:15 AM, Lee Jones wrote:
>>> On Tue, 24 Jan 2017, Arnaud Pouliquen wrote:
>>>> On 01/24/2017 12:36 PM, Lee Jones wrote:
>>>>> On Tue, 24 Jan 2017, Arnaud Pouliquen wrote:
>>>>>> On 01/24/2017 09:22 AM, Lee Jones wrote:
>>>>>>> On Mon, 23 Jan 2017, Arnaud Pouliquen wrote:
>>>>>>>
>>>>>>>> DFSDM hardware IP can be used at the same time for ADC sigma delta
>>>>>>>
>>>>>>> Same time as what?
>>>>>> DFSDM is used for ADC acquisition (through IIO) but also PDM microphone
>>>>>> capture (through ASOC).
>>>>>>>
>>>>>>>> conversion and audio PDM microphone.
>>>>>>>> MFD driver is in charge of configuring IP registers and managing IP clocks.
>>>>>>>> For this it exports an API to handles filters and channels resources.
>>>>>>>
>>>>>>> This looks like an ADC driver?  What is it that makes it an MFD?
>>>>>> Yes it a kind of ADC but that supports 2 features audio and iio.
>>>>>> So it has to support 2 features based on 2 separate Frameworks.
>>>>>
>>>>> I'm still unsure why it needs to live in MFD.
>>>>>
>>>>> By the looks of it, this driver needs to move into IIO and you need to
>>>>> call into it from ASoC.
>>>>>
>>>>
>>>> I think i introduce confusion by speaking about ADC for audio...
>>>>
>>>> 1) IIO handles sigma delta ADCs that can be used as example for motor
>>>> controls. the aim is to get value based on an application request or
>>>> using some triggers.
>>>> example: http://www.ti.com/lit/ds/symlink/ads1202.pdf
>>>>
>>>> 2) For audio part, we speak about Digital mems microphones that generate
>>>> PDM format stream. PDM is a continuous real time stream dedicated to
>>>> audio record and must be handled in ASOC ( codec Dmic part driver is
>>>> /sound/soc/codec/dmic.c).
>>>> DMIC example:
>>>> http://www.st.com/content/ccc/resource/technical/document/datasheet/47/bd/d2/13/8d/fd/48/26/DM00121815.pdf/files/DM00121815.pdf/jcr:content/translations/en.DM00121815.pdf
>>>>
>>>> Form my point of view it very strange to handle DMICs in IIO, as it is
>>>> not designed to support audio streams.it is two separate features that
>>>> are not compatible.
>>>>
>>>> Now, from software point of view
>>>> That would means that IIO declares ADCs that it can not expose, because
>>>> DMIC is not IIO standard. But IIO inkern API needs that device is
>>>> declared
>>>
>>>> So i should define a specific API in IIO for ASOC driver.
>>>
>>> Yes, this is what I think you should do.
>>>
>>> MFD is not a dumping ground for devices that do not fit anywhere else.
>>
>> I fully understand that you don't want to create unnecessary MFD devices.
>> But In case of DFSDM ,it is really a device that supports 2 features.
>> The main evidence is that "ADC acquisition" and "digital microphone"
>> features are handled by two separate frameworks.
>> So this corresponds to two features that share the same device resources
>> (registers, IRQs, clocks).
>> Seems that this match with MFD definition.
>>
>> Now, if IIO and ASOC maintainers are aligned with you proposal, i will
>> move MFD part in IIO.
>> But in this case, i can not see another way to do it, except a MFD
>> driver hidden in IIO?
>>
>> Here is my analysis of a design in IIO:
>>
>> Natural way to do this is to consider that ASOC is a customer of IIO so
>> use the customer.h API.
>> 1) As Digital microphone can not be handled by IIO dev interface, i can
>> not expose them as an IIO channel, that would be visible by applications
>> in /sys/bus/iio/devices/iio
>> 2) ASOC needs to configure DFSDM filter to match to specific frequencies
>> and sample formats requested by users. Not standard IIO interface to do
>> this. (on IIO side this is done by attribute file)
>> 3) audio stream is a real time stream. So for audio quality best is to
>> minimize latencies and Xrun. That why transfer as done from HW to
>> application using LLI DMA transfers with a minimum of copy. This does
>> not match with the IIO inkern API.
>>  => So seems not possible to use IIO inkern API.
>>
>> That's means that i would need to create a ST specific include file to
>> offer an API to ASoC to handle DFSDM resources linked to the DMIC.
>> and to probe ASOc device in IIO one.
>> So the solution would be to create something like a sub IIO driver That
>> probe and handle some IIO and ASOC devices.
>> Ultimately This would correspond to a MFD driver integrated in IIO...
> 
> The issue is not the creation of an MFD driver to create shared
> resources and probe the child devices.  That's what MFD *is* for.
> What I do take exception to is having lots of code in MFD which
> should clearly live in a different subsystem.
> 
> Since this device only serves a couple of functions, I expect it to be
> a few hundred lines, maximum.  Everything else should be farmed out.
> MFD knows nothing of "channels" or "filters" so anything related to
> them (init, get, start, stop, release, etc) needs to find another
> home.  Whether that's in IIO is a separate discussion, but it
> certainly doesn't live in MFD.

Thanks for your time and explanations Lee.
As you recommended, I will try to integrate it in IIO. And i notice for
the next time that i can not expose such "high level" interface in MFD.

Regards
Arnaud