On Fri, Feb 28, 2020 at 2:40 PM Nicolin Chen nicoleotsuka@gmail.com wrote:
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.
ok, I will change the binding this time in next version.
best regards wang shengjiu