[alsa-devel] [PATCH 0/3] ASoC: Enable a new IC master mode: bcm2835<=>IC<=>cs42xx8

[Emmanuel Fusté]

Le 21/03/2017 à 23:11, Matthias Reichl a écrit :
> On Tue, Mar 21, 2017 at 10:21:04PM +0100, Emmanuel Fusté wrote:
>> Le 16/03/2017 à 23:14, Matt Flax a écrit :
>>>
>>> On 17/03/17 08:27, Lars-Peter Clausen wrote:
>>>> On 03/16/2017 09:51 PM, Matt Flax wrote:
>>>>> On 16/03/17 06:01, Mark Brown wrote:
>>>>>> On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote:
>>>>>>> On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote:
>>>>>>>>> I have a bcm2835 (Pi 2 and 3) SoC here. It is producing
>>>>>>>>> multichannel (8
>>>>>>>>> out,
>>>>>>>>> 6 in) audio. In ALSA we call that DSP mode - right ?!
>>>>>>>> No. DSP modes are protocol/timing specifications as I2S, PDP,
>>>>>>>> S/PDIF, ...
>>>>>>>> You can look these up in datasheets and if a chip implements such a
>>>>>>>> protocol you can be sure that it adheres to that standard - i.e. it
>>>>>>>> will sync the frames to the pulses on LRclk.
>>>>>>> I agree with the thoughts in this thread really if the AP doesn't
>>>>>>> actually support DSP A mode we shouldn't add DSP A mode.
>>>>>> The trouble here is that this isn't 100% clear, the specifications of
>>>>>> the DSP modes are such that only one edge in the LRCLK matters and so
>>>>>> providing you're doing mono or have exact clocking they interoperate
>>>>>> perfectly well.  We already frequently do similar things the other
>>>>>> way,
>>>>>> most of the programmable serial ports can't actually do I2S modes
>>>>>> properly and rely on exact clocking to get things right when operating
>>>>>> as I2S since they only sync on one edge (though they can generally
>>>>>> generate the clocks correctly when operating as master, they just
>>>>>> don't
>>>>>> pay attention to the left/right switch edge).
>>>>>>
>>>>>> That said unless we're doing something with the data layout or similar
>>>>>> configuration there's a fairly strong case for putting the mangling
>>>>>> for
>>>>>> this in the core, something like just falling back to I2S mode if we
>>>>>> set
>>>>>> DSP A and so on.  Which would be a lot nicer if we actually got
>>>>>> round to
>>>>>> putting mode capability information in the drivers.
>>>>> I agree, the data layout is already configurable in the bcm2835_i2s.c
>>>>> platform driver. We can already use the "snd_soc_dai_set_bclk_ratio"
>>>>> function to manage word offsets in our machine drivers.
>>>>>
>>>>> There is nothing which says that the bcm2835 SoC is I2S restricted in
>>>>> any
>>>>> way. In fact, the reference document says quite the opposite.
>>>>>
>>>>> In the reference "BCM2835 ARM Peripherals" pdf, they call the audio
>>>>> system
>>>>> an "APB peripheral". They are saying that it is reconfigurable and
>>>>> part of
>>>>> the AMBA family of interconnect schemes.
>>>>>
>>>>> As far as the bcm2835_i2s platform driver goes, it has implemented an
>>>>> AMBA
>>>>> protocol, where audio words are counted from the LR clock onset - for
>>>>> some
>>>>> reason people are insisting this is an I2S bus. Really our
>>>>> implementation is
>>>>> not I2S at all, because word onsets are programmable and flexible in
>>>>> the
>>>>> bcm2835_i2s.c driver.
>>>> AMBA/APB is the interface which connects the peripheral to the system
>>>> memory
>>>> bus. It is the interface over which the CPU does configuration register
>>>> writes. This has nothing and absolutely nothing to do with the I2S
>>>> interface
>>>> that is also implemented by the peripheral that is used to stream audio
>>>> to
>>>> and from external components.
>>>>
>>> Their (BCM reference) document [1] specifically states "It supports many
>>> classic PCM formats including I2S".
>>>
>>> Do agree with Mark's statement "the specifications of the DSP modes are
>>> such that only one edge in the LRCLK matters" ?
>>>
>>> If we look at the bcm2835 platform driver setup, it is concerned with bit
>>> clock counting to specify the audio data for both of the AMBA/APB channels
>> >from serial bitstream into memory. It has two channels into memory,
>>> however "it supports many classic PCM formats" ... my vote for one classic
>>> format is DSP mode !
>>>
>>> Do you see a problem with that ?
>>>
>>> thanks
>>> Matt
>>> [1] https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
>>> _______________________________________________
>>>
>> Re-reading this document, the bcm2835 PCM IP block SHOULD support real DSP
>> mode, with one BCLK pulsed LRCLK, zero BCLK delay etc...
>> It just need to be properly setup.
> I've re-read the document, too, last week and noticed the framesync
> registers - sorry, I had completely forgotten about these. I guess it
> should be possible to configure the bcm2835 to DSP mode but it'd still be
> limited to 2 channel setups - the hardware only has 2 channel position
> registers for each direction.
>
>> According to the same document, you could program the bmc up to 16 32bits
>> channels when in master mode, so I suspect that you could go up to this
>> limit in slave mode.
>> But as it is designed, it could only use up to two of any channels among the
>> 16.
> I'm not quite sure if I can follow you on this - how would you
> configure 16 channels when there are only 2 channel position registers?
>
> With bclk ratio eg set to 16*32=512 BCM2835 will only transmit 2*32
> bits of data (at configurable bit positions), the remaining 448
> bits will be zero.
>
>
Yes, two arbitrary tdm channels out of 16. And as I and you said, the 
others are not usable.
Could be useful in a TDM chained scenario , but not for what we are 
talking here.

Emmanuel.