From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Subject: Re: How to correct params_format on DPCM ?
Date: Fri, 10 Apr 2015 07:12:28 +0000
Message-ID: <87a8yg8nko.wl%kuninori.morimoto.gx@renesas.com>
References: <87twwsttp5.wl%kuninori.morimoto.gx@renesas.com>	<20150408180118.GG6023@sirena.org.uk>
Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <alsa-devel-bounces@alsa-project.org>
Received: from relmlie3.idc.renesas.com (relmlor4.renesas.com
 [210.160.252.174])
 by alsa0.perex.cz (Postfix) with ESMTP id 4C139260502
 for <alsa-devel@alsa-project.org>; Fri, 10 Apr 2015 09:12:35 +0200 (CEST)
In-Reply-To: <20150408180118.GG6023@sirena.org.uk>
List-Unsubscribe: <http://mailman.alsa-project.org/mailman/options/alsa-devel>,
 <mailto:alsa-devel-request@alsa-project.org?subject=unsubscribe>
List-Archive: <http://mailman.alsa-project.org/pipermail/alsa-devel/>
List-Post: <mailto:alsa-devel@alsa-project.org>
List-Help: <mailto:alsa-devel-request@alsa-project.org?subject=help>
List-Subscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
 <mailto:alsa-devel-request@alsa-project.org?subject=subscribe>
Errors-To: alsa-devel-bounces@alsa-project.org
Sender: alsa-devel-bounces@alsa-project.org
To: Mark Brown <broonie@kernel.org>
Cc: Linux-ALSA <alsa-devel@alsa-project.org>, Lars-Peter Clausen <lars@metafoo.de>, Liam Girdwood <lgirdwood@gmail.com>, Simon <horms@verge.net.au>
List-Id: alsa-devel@alsa-project.org


Hi Mark

> > 	rsnd:   SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S16_LE
> > 	ak4642: SNDRV_PCM_FMTBIT_S16_LE
(snip)
> 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.

Now I'm debuging about this issue, but it is very complex.
I need your help. where should I check/debug ?

My problem is...

In non-DPCM case

cpu  : rsnd  : SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE
codec: ak4642: SNDRV_PCM_FMTBIT_S16_LE
-----------------------------------------
 SNDRV_PCM_FMTBIT_S16_LE is used, this is OK

In DPCM case

FE cpu  : rsnd  : SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE
FE codec: dummy : SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE | ...

BE cpu  : dummy : SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE | ...
BE codec: ak4642: SNDRV_PCM_FMTBIT_S16_LE

SNDRV_PCM_FMTBIT_S24_LE is used on FE,
SNDRV_PCM_FMTBIT_S16_LE is used on BE.
this means FE send S24 data, but BE can't use it.

Which function/method controls format ?
I guess it is doning some kind of

	format = cpu->formats & codec->formats;

DPCM case need to care about FE/BE, and maybe this is lost item.

	format = fe_cpu->formats & fe_codec->formats &
	         be_cpu->formats & be_codec->formats;

I guess it is done before hw_param() (?),
or snd_soc_instantiate_card() timing. but I couldn't find it.
It is very confusable/complex. which function is doing this ?

Best regards
---
Kuninori Morimoto