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

Matt Flax flatmax at flatmax.org
Wed Mar 22 05:04:34 PDT 2017



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.

Matt



More information about the linux-rpi-kernel mailing list