All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Flax <flatmax@flatmax.org>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org,
	Stephen Warren <swarren@wwwdotorg.org>,
	Lee Jones <lee@kernel.org>,
	phil@raspberrypi.org, Eric Anholt <eric@anholt.net>,
	Florian Meier <florian.meier@koalo.de>,
	linux-rpi-kernel@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ASoC: bcm2835: Increase channels_max to 8
Date: Mon, 6 Feb 2017 07:37:03 +1100	[thread overview]
Message-ID: <aa6b9cbd-e033-eee6-d7f8-8ba8c8e611ab@flatmax.org> (raw)
In-Reply-To: <20170205163451.4x3svwbqdqlfc7t4@sirena.org.uk>

On 06/02/17 03:34, Mark Brown wrote:
> On Sun, Feb 05, 2017 at 12:26:31PM +1100, Matt Flax wrote:
>> On 05/02/17 02:49, Mark Brown wrote:
>>> On Thu, Feb 02, 2017 at 10:37:44AM +1100, Matt Flax wrote:
>>> I can't understand how this works.  We're programming the hardware in an
>>> identical fashion for both channel counts, that means that what we're
>> I am not surprised it is confusing, to my knowledge this is the first time
>> that someone has demonstrated this type of I2S signalling.
> More than stereo I2S?  That is actually a thing, while most people use
> DSP modes for higher channel counts it's fairly common to have the
> support especially in CODECs that also support DSP mode since the
> hardware implementation is fairly straightforward if you abstracted in
> the bus interface.
>
>> In this case BCM2835 is a clock slave and not concerned with generating the
>> I2S clocks, only receiving - think of all clocks and synchrony being
>> generated/managed in hardware on the sound card.
>> In short the BCM2835 silicon is only concerned with shifting bits into two
>> hardware registers which (after DMA) are interpreted by ALSA according to
>> the specified channel count.
> Sure, that's what all audio controllers do.  But there's a few problems.
> One is that nothing in your code that prevents this running in master
> mode.  Another is that if this *is* for I2S mode then when doing
> multichannel I2S you usually still respect the left/right indication in
> LRCLK so you will end up with the data in the in memory format:
>
>    L1 R1 L2 R2 L3 R3 L4 R4
>
> but multi channel I2S would usually be rendered with all the left
> channels and all the right channels grouped together so you get:
>
>    L1 L2 L3 L4 R1 R2 R3 R4
>
> It'll also require exact clocking with no spare bits in order to sync
> the right channels with the LRCLK switch but that's not so unusual.
> Looking at the driver it may be possible for the hardware to do DSP
> modes at which point this gets much easier but right now it only has I2S
> support, I've got a feeling that the other end of the link may actually
> be running in a DSP mode.
You've got it !

This can also work with the BCM2835 in master mode, no reason at this 
point to limit it to slave mode only.

I haven't looked into why, but I am getting the correct channel mapping 
under the hood. To me that is a concern of the higher up levels of the 
ALSA driver - it was a pleasant surprise when it worked nicely, because 
to me it indicated a robustly coded system.

My next patch is to allow DSP modes in this I2S driver. I wanted to make 
sure that this got through first however.

The majority of these other concerns you mention are controlled at the 
machine driver level.

Matt

WARNING: multiple messages have this Message-ID (diff)
From: flatmax@flatmax.org (Matt Flax)
To: linux-arm-kernel@lists.infradead.org
Subject: [alsa-devel] [PATCH] ASoC: bcm2835: Increase channels_max to 8
Date: Mon, 6 Feb 2017 07:37:03 +1100	[thread overview]
Message-ID: <aa6b9cbd-e033-eee6-d7f8-8ba8c8e611ab@flatmax.org> (raw)
In-Reply-To: <20170205163451.4x3svwbqdqlfc7t4@sirena.org.uk>

On 06/02/17 03:34, Mark Brown wrote:
> On Sun, Feb 05, 2017 at 12:26:31PM +1100, Matt Flax wrote:
>> On 05/02/17 02:49, Mark Brown wrote:
>>> On Thu, Feb 02, 2017 at 10:37:44AM +1100, Matt Flax wrote:
>>> I can't understand how this works.  We're programming the hardware in an
>>> identical fashion for both channel counts, that means that what we're
>> I am not surprised it is confusing, to my knowledge this is the first time
>> that someone has demonstrated this type of I2S signalling.
> More than stereo I2S?  That is actually a thing, while most people use
> DSP modes for higher channel counts it's fairly common to have the
> support especially in CODECs that also support DSP mode since the
> hardware implementation is fairly straightforward if you abstracted in
> the bus interface.
>
>> In this case BCM2835 is a clock slave and not concerned with generating the
>> I2S clocks, only receiving - think of all clocks and synchrony being
>> generated/managed in hardware on the sound card.
>> In short the BCM2835 silicon is only concerned with shifting bits into two
>> hardware registers which (after DMA) are interpreted by ALSA according to
>> the specified channel count.
> Sure, that's what all audio controllers do.  But there's a few problems.
> One is that nothing in your code that prevents this running in master
> mode.  Another is that if this *is* for I2S mode then when doing
> multichannel I2S you usually still respect the left/right indication in
> LRCLK so you will end up with the data in the in memory format:
>
>    L1 R1 L2 R2 L3 R3 L4 R4
>
> but multi channel I2S would usually be rendered with all the left
> channels and all the right channels grouped together so you get:
>
>    L1 L2 L3 L4 R1 R2 R3 R4
>
> It'll also require exact clocking with no spare bits in order to sync
> the right channels with the LRCLK switch but that's not so unusual.
> Looking at the driver it may be possible for the hardware to do DSP
> modes at which point this gets much easier but right now it only has I2S
> support, I've got a feeling that the other end of the link may actually
> be running in a DSP mode.
You've got it !

This can also work with the BCM2835 in master mode, no reason at this 
point to limit it to slave mode only.

I haven't looked into why, but I am getting the correct channel mapping 
under the hood. To me that is a concern of the higher up levels of the 
ALSA driver - it was a pleasant surprise when it worked nicely, because 
to me it indicated a robustly coded system.

My next patch is to allow DSP modes in this I2S driver. I wanted to make 
sure that this got through first however.

The majority of these other concerns you mention are controlled at the 
machine driver level.

Matt

  reply	other threads:[~2017-02-05 20:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-01 23:37 [PATCH] ASoC: bcm2835: Increase channels_max to 8 Matt Flax
2017-02-01 23:37 ` Matt Flax
2017-02-04 15:49 ` Mark Brown
2017-02-04 15:49   ` Mark Brown
2017-02-05  1:26   ` Matt Flax
2017-02-05  1:26     ` [alsa-devel] " Matt Flax
2017-02-05 10:20     ` Florian Kauer
2017-02-05 10:20       ` Florian Kauer
2017-02-05 10:55       ` Matt Flax
2017-02-05 10:55         ` [alsa-devel] " Matt Flax
2017-02-05 16:34     ` Mark Brown
2017-02-05 16:34       ` [alsa-devel] " Mark Brown
2017-02-05 20:37       ` Matt Flax [this message]
2017-02-05 20:37         ` Matt Flax
2017-02-05 22:49         ` Matt Flax
2017-02-05 22:49           ` [alsa-devel] " Matt Flax
2017-02-06 16:43         ` Mark Brown
2017-02-06 16:43           ` [alsa-devel] " Mark Brown
2017-02-06 20:25           ` Matt Flax
2017-02-06 20:25             ` [alsa-devel] " Matt Flax

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aa6b9cbd-e033-eee6-d7f8-8ba8c8e611ab@flatmax.org \
    --to=flatmax@flatmax.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=eric@anholt.net \
    --cc=florian.meier@koalo.de \
    --cc=lee@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=phil@raspberrypi.org \
    --cc=swarren@wwwdotorg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.