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: Mon, 13 Apr 2015 04:54:39 +0000
Message-ID: <87r3ro7hnu.wl%kuninori.morimoto.gx@renesas.com>
References: <87twwsttp5.wl%kuninori.morimoto.gx@renesas.com>
 <20150408180118.GG6023@sirena.org.uk>
 <87a8yg8nko.wl%kuninori.morimoto.gx@renesas.com>
 <20150410154338.GL6023@sirena.org.uk>
 <87twwk7tz4.wl%kuninori.morimoto.gx@renesas.com>
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 relmlie1.idc.renesas.com (relmlor2.renesas.com
 [210.160.252.172])
 by alsa0.perex.cz (Postfix) with ESMTP id D96432614E3
 for <alsa-devel@alsa-project.org>; Mon, 13 Apr 2015 06:54:47 +0200 (CEST)
In-Reply-To: <87twwk7tz4.wl%kuninori.morimoto.gx@renesas.com>
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, Lars again

> > > 	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 ?
> > 
> > My point is that it's not happening and you're going to need to add that
> > support.  It's slightly more complex than your picture as most things
> > that do DPCM can rewrite the format so we normally don't want to
> > constrain with the back end constraints.  Like I said in my eariler
> > reply I think we want to change things so that if there's no front end
> > constraint we take the back end one instead.

In my debug, I guess key function is dpcm_init_runtime_hw()
But, I would like to know about concept about this.

If my understanding is correct, the information which userland
can get is setuped in .open

In non-DPCM case

 soc_pcm_open()
  - soc_pcm_init_runtime_hw() /* setup runtime->hw */

In DPCM case

 dpcm_fe_dai_open()
  - dpcm_fe_dai_startup()
   - dpcm_be_dai_startup()
    - soc_pcm_open()          /* don't care runtime->hw */
   - soc_pcm_open()           /* don't care runtime-hw */
   - dpcm_set_fe_runtime()
    - dpcm_init_runtime_hw()  /* setup runtime->hw */

I guess my issue will be solved if I added code here which cares BE.
But, I wounder non-DPCM case, runtime->hw has cpu/codec merged information
in soc_pcm_init_runtime_hw().
But, DPCM cases, it cares only cpu information. why it doesn't care codec ?

If my understanding was correct, corrent image is...

non-DPCM
 hw = cpu & codec

DPCM
 hw = fe_cpu

I guess DPCM should be...

 FE.hw = fe_cpu & fe_codec
 BE.hw = be_cpu & be_codec

And, if no FE constraint, final image will be

 hw = FE.hw & BE.hw

But, am I misunderstanding ?

Best regards
---
Kuninori Morimoto