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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
