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

[Stephen Warren]

On 03/22/2017 06:04 AM, Matt Flax wrote:
>
>
> On 22/03/17 20:43, Charles Keepax wrote:
>> On Wed, Mar 22, 2017 at 10:29:33AM +1100, Matt Flax wrote:
>>> On 22/03/17 09:11, Matthias Reichl wrote:
>>>> 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:
>>>>> 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.
>>>>
>>> The document seems to stipulate that the PCM audio device is an AMBA
>>> device
>>> with 2 APB data channels. The first sync edge marks the beginning of
>>> the two
>>> data words. Their frame lengths can be up to 1024+32 bits in length !
>>>
>>> I think the point is that they intended their PCM audio interface to be
>>> configurable, they say in their document "It supports many classic PCM
>>> formats".
>>>
>>> The important point here is that in ALSA we can only have I2S or DSP
>>> modes -
>>> right ?
>>> Unless we want to create a new ALSA mode (which clearly worries
>>> people) then
>>> we need to support the versatility of the bcm2835 PCM hardware using
>>> either
>>> DSP or I2S modes. Now, we have already implemented the I2S mode, so
>>> logically the only available mode left is the DSP mode. Using this
>>> mode, we
>>> can implement more features of this device.
>>>
>>> People seem to want to reserve DSP and I2S modes for strictly I2S and
>>> DSP
>>> protocols. At the same time people don't want to allow a looser "APB"
>>> mode
>>> into ALSA. For that reason, we have a lack of functionality for
>>> perfectly
>>> versatile hardware - the bcm2835 hardware.
>>>
>> Apologies but I am still a little unclear as to what actually happens
>> on the bus here.
>>
>> Are we saying that what gets transmitted on the bus is neither valid
>> I2S or DSP mode data? But as you have your custom hardware block in
>> the middle it interprets this data correctly and converts it to a
>> regular bus format on the other side that goes to the CODEC?
>
> Yes, essentially there is translation between the two data word edge
> triggered ABP (the bcm2835's PCM block) and a Cirrus Logic TDM codec.

Are you really sure about this? I believe the BCM2835 I2S controller is 
a standard I2S controller.

Note that, as was pointed out earlier in this thread, "APB" has nothing 
to do with the audio side of the I2S controller's HW. Rather, the I2S 
controller connects to the SoC's APB bus so that the CPU can program the 
I2S controller's registers, and so that the CPU or DMA engine can 
read/write the audio data stream. The audio side of the I2S controller 
generates/consumes the standard I2S signals of clock, frame sync, data 
in, and data out. As such, I believe standard I2S and DSP modes are 
perfectly possible.

Now the BCM2835 I2S controller does appear to have a few features beyond 
plain I2S/DSP modes, that not all I2S controllers might have, such as:

- Frame length, FS length, channel position, and channel width are 
specified at bit resolution rather than byte/sample/...

- PDM mode (for digital mics).

- Sign extension of RX data.

So, the controller can generate/receive some formats beyond plain 
I2S/DSP, but to be honest I doubt that this level of detail needs to be 
exposed to the ALSA/ASoC core or user-space, nor is it required to 
interface to any typical HW, so it can be hidden in the driver's 
register programming implementation.