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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux