Re: [RFC PATCH 1/4] alsa: make hw_params negotiation infrastructure 'bclk_ratio aware'

From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>
Cc: Sven Van Asbroeck <thesven73@gmail.com>,
	alsa-devel@alsa-project.org,
	Russell King - ARM Linux admin <linux@armlinux.org.uk>
Subject: Re: [RFC PATCH 1/4] alsa: make hw_params negotiation infrastructure 'bclk_ratio aware'
Date: Wed, 13 Mar 2019 14:57:26 +0900	[thread overview]
Message-ID: <20190313055726.GB13393@workstation> (raw)
In-Reply-To: <20190312150300.GE6983@sirena.org.uk>

Hi,

On Tue, Mar 12, 2019 at 03:03:00PM +0000, Mark Brown wrote:
> On Mon, Mar 11, 2019 at 04:43:39PM +0100, Jaroslav Kysela wrote:
> 
> > I would not use any of the "user space" ioctl API to represent the
> > hardware bclk requirements. The applications should know just the DMA
> > memory layout.
> 
> > Also, think about the multiple simultaneous paths for the audio output
> > in the sound controller (so one DMA from the user space to the
> > controller, but the controller can do multiple simultaneous outputs
> > using different clocks combining different wire buses or so). Yes, it's
> > the corner case, but it's another reason to have the bclk code totally
> > separated from the user space ALSA's PCM API.
> 
> There's also a range of devices that either don't have visible buses at
> all due to integration or which are on buses that look nothing like the
> I2S/DSP mode style of bus, rendering the parameters meaningless.

Indeed. That's resonable to add no changes to ALSA PCM interface. When
suggesting usage of 'rate_num' and 'rate_den', I assumed to change
ALSA SoC part internal to have constraints and rules for them, with no
changes of ALSA PCM inteface itself. I agree that the dicision of
on-wire format should not be exposed to userspace as well.

[1] https://mailman.alsa-project.org/pipermail/alsa-devel/2019-March/146261.html

Thanks

Takashi Sakamoto