Re: How to correct params_format on DPCM ?

From: Mark Brown <broonie@kernel.org>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Linux-ALSA <alsa-devel@alsa-project.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Liam Girdwood <lgirdwood@gmail.com>, Simon <horms@verge.net.au>
Subject: Re: How to correct params_format on DPCM ?
Date: Wed, 8 Apr 2015 19:01:18 +0100	[thread overview]
Message-ID: <20150408180118.GG6023@sirena.org.uk> (raw)
In-Reply-To: <87twwsttp5.wl%kuninori.morimoto.gx@renesas.com>

[-- Attachment #1.1: Type: text/plain, Size: 1106 bytes --]

On Tue, Apr 07, 2015 at 05:05:34AM +0000, Kuninori Morimoto wrote:

> Here, SNDRV_PCM_FMTBIT_S16_LE is always selected on non-DPCM card.
> This is OK.

> 	rsnd:   SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S16_LE
> 	ak4642: SNDRV_PCM_FMTBIT_S16_LE

> On DPCM card, FE gets S24, BE gets S16 if aplay selects S24 wav.
> But, FE needs S16, same as non-DPCM card.
> I know we can fixup BE side via dai_link.be_hw_params_fixup,
> but this is FE side.

> It can't use correct sound playback in corrent DPCM card.
> But, how to solve this issue ?? 

I'm not sure what exactly was intended here but this seems to need
fixing in the core - I think the assumption in the DPCM code is that
the sort of hardware that uses it will have rewriting support that makes
the back end constraints irrelevant to the front end.  I think what we
want here is some way to signal to the framework that the front end
constraints aren't used and it should use the back end ones instead -
perhaps just omit the constraints that aren't rewritten and then have
the framework take those from the backend instead.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]