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@gmail.com 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@gmail.com 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@nxp.com
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;elseformat = 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.