On Fri, Feb 28, 2020 at 10:54:02AM +0800, Shengjiu Wang wrote: > Hi > > On Fri, Feb 28, 2020 at 1:45 AM Nicolin Chen <nicoleotsuka@xxxxxxxxx> wrote: > > > > On Thu, Feb 27, 2020 at 01:10:19PM +0800, Shengjiu Wang wrote: > > > On Thu, Feb 27, 2020 at 11:43 AM Nicolin Chen <nicoleotsuka@xxxxxxxxx> wrote: > > > > > > > > On Thu, Feb 27, 2020 at 10:41:55AM +0800, Shengjiu Wang wrote: > > > > > asrc_format is more inteligent variable, which is align > > > > > with the alsa definition snd_pcm_format_t. > > > > > > > > > > Signed-off-by: Shengjiu Wang <shengjiu.wang@xxxxxxx> > > > > > --- > > > > > sound/soc/fsl/fsl_asrc.c | 23 +++++++++++------------ > > > > > sound/soc/fsl/fsl_asrc.h | 4 ++-- > > > > > sound/soc/fsl/fsl_asrc_dma.c | 2 +- > > > > > 3 files changed, 14 insertions(+), 15 deletions(-) > > > > > > > > > > diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c > > > > > index 0dcebc24c312..2b6a1643573c 100644 > > > > > --- a/sound/soc/fsl/fsl_asrc.c > > > > > +++ b/sound/soc/fsl/fsl_asrc.c > > > > > > > > > @@ -600,11 +599,6 @@ static int fsl_asrc_dai_hw_params(struct snd_pcm_substream *substream, > > > > > > > > > > pair->config = &config; > > > > > > > > > > - if (asrc_priv->asrc_width == 16) > > > > > - format = SNDRV_PCM_FORMAT_S16_LE; > > > > > - else > > > > > - format = SNDRV_PCM_FORMAT_S24_LE; > > > > > > > > It feels better to me that we have format settings in hw_params(). > > > > > > > > Why not let fsl_easrc align with this? Any reason that I'm missing? > > > > > > because the asrc_width is not formal, in the future we can direct > > > > Hmm..that's our DT binding. And I don't feel it is a problem > > to be ASoC irrelative. > > > > > input the format from the dts. format involve the info about width. > > > > Is there such any formal ASoC binding? I don't see those PCM > > formats under include/dt-bindings/ folder. How are we going > > to involve those formats in DT? > > There is no formal binding of this case. > > I think it is not good to convert width to format, because, for example The thing is that fsl_easrc does the conversion too... It just does in the probe instead of hw_params(), and then copies them in the hw_params(). So I don't see obvious benefit by doing so. > width = 24, there is two option, we can select format S24_LE, or > format S24_3LE, width is ambiguous for selecting. > > In EASRC, it support other two 24bit format U24_LE, U24_3LE . I understood the reason here, but am not seeing the necessity, at this point. > if we use the format in DT, then it is clear for usage in driver. I think this is the thing that we should address first. If we have such a binding being added with the new fsl_easrc driver, I'd love to see the old driver aligning with the new one. Otherwise, we can keep the old way, and change it when the new binding is ready.
