On 30/01/17 11:13, Arnaud Pouliquen wrote:

Hello,

Thanks everyone for you feedback!
My comments below.

On 01/29/2017 03:34 PM, Lars-Peter Clausen wrote:

quoted

On 01/29/2017 03:19 PM, Lars-Peter Clausen wrote:

quoted

On 01/29/2017 01:28 PM, Jonathan Cameron wrote:
[...]

quoted

quoted

quoted

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'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.

I forgot to mention. I think the first thing we should do is work on
terminology. This is not an ADC, this is a configurable low-pass-filter.

It works in conjunction with a analog frontend (ADC) that produces a 1-bit
pulse-density-modulated stream, takes that stream and converts it into N-bit
PCM samples. The PCM samples are generated at a fraction of the PDM stream
samplerate that corresponds to the decimation factor.

This is not an unusual device. Many audio CODEC and audio controllers
contain such a core as well as most SigmaDelta converters supported by IIO.
What is special about this part is that it is a dedicated core that is not
embedded in some other hardware component. This creates greater flexibility,
but of course also greater complexity that is required to manage all that
flexibility.

We shouldn't codify anything about the kernel internal frameworks through
which the device might be exposed into the devicetree. We should accurately
describe the hardware (including the analog frontend) and then create a
appropriate software structures to handle them.	

So if everyone is aligned, i will abandon the MFD driver and try to bind
an ASoC driver on IIO interface. The "challenge" is to
define appropriate relation ship between ASoC and IIO...

In a first step, a lot of question to answers and points to clarify... i
will reply to associated mails.

Then I see two main topics to clarify:
	- DFSDM integration in IIO in a generic way. Lars, if i well interpret,
your proposal should be to introduce front-end and filter notions in
IIO, to support this kind of hardware?
	- DMA engine for audio purpose.
I propose to come back with RFC for both subjects.

If you want to have more detail on DFSDM: DFSDM datasheet is included in
STM32F413 datasheet available here:
http://www.st.com/content/ccc/resource/technical/document/reference_manual/group0/81/ea/88/1f/97/9e/4a/d0/DM00305666/files/DM00305666.pdf/jcr:content/translations/en.DM00305666.pdf

DFSDM Block diagram p 384

Sounds like a sensible way forward to me.

Might well go through a few more rounds before we get this right, but
I agree with Lars that this looks to be something we are going to meet
more and more in the future so would be excellent to get it right!

Jonathan

Regards
Arnaud



--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html