* [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-02 14:22 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-02 14:22 UTC (permalink / raw) Cc: kernel, Liam Girdwood, Mark Brown, Rob Herring, Timur Tabi, Nicolin Chen, Xiubo Li, Fabio Estevam, Jaroslav Kysela, Takashi Iwai, alsa-devel, devicetree, linux-kernel, linuxppc-dev The current ASRC driver hardcodes the input and output clocks used for sample rate conversions. In order to allow greater flexibility and to cover more use cases, it would be preferable to select the clocks using device-tree properties. This series also fix register configuration and clock assignment so conversion can be conducted effectively in both directions with a good quality. Arnaud Ferraris (4): dt-bindings: sound: fsl,asrc: add properties to select in/out clocks ASoC: fsl_asrc: allow using arbitrary input and output clocks ASoC: fsl_asrc: always use ratio for conversion ASoC: fsl_asrc: swap input and output clocks in capture mode Documentation/devicetree/bindings/sound/fsl,asrc.txt | 8 ++++++++ sound/soc/fsl/fsl_asrc.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----- sound/soc/fsl/fsl_asrc_common.h | 3 +++ 3 files changed, 75 insertions(+), 5 deletions(-) ^ permalink raw reply [flat|nested] 55+ messages in thread
* [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-02 14:22 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-02 14:22 UTC (permalink / raw) Cc: devicetree, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Jaroslav Kysela, Nicolin Chen, Mark Brown, kernel, Fabio Estevam The current ASRC driver hardcodes the input and output clocks used for sample rate conversions. In order to allow greater flexibility and to cover more use cases, it would be preferable to select the clocks using device-tree properties. This series also fix register configuration and clock assignment so conversion can be conducted effectively in both directions with a good quality. Arnaud Ferraris (4): dt-bindings: sound: fsl,asrc: add properties to select in/out clocks ASoC: fsl_asrc: allow using arbitrary input and output clocks ASoC: fsl_asrc: always use ratio for conversion ASoC: fsl_asrc: swap input and output clocks in capture mode Documentation/devicetree/bindings/sound/fsl,asrc.txt | 8 ++++++++ sound/soc/fsl/fsl_asrc.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----- sound/soc/fsl/fsl_asrc_common.h | 3 +++ 3 files changed, 75 insertions(+), 5 deletions(-) ^ permalink raw reply [flat|nested] 55+ messages in thread
* [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-02 14:22 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-02 14:22 UTC (permalink / raw) Cc: devicetree, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Nicolin Chen, Mark Brown, kernel, Fabio Estevam The current ASRC driver hardcodes the input and output clocks used for sample rate conversions. In order to allow greater flexibility and to cover more use cases, it would be preferable to select the clocks using device-tree properties. This series also fix register configuration and clock assignment so conversion can be conducted effectively in both directions with a good quality. Arnaud Ferraris (4): dt-bindings: sound: fsl,asrc: add properties to select in/out clocks ASoC: fsl_asrc: allow using arbitrary input and output clocks ASoC: fsl_asrc: always use ratio for conversion ASoC: fsl_asrc: swap input and output clocks in capture mode Documentation/devicetree/bindings/sound/fsl,asrc.txt | 8 ++++++++ sound/soc/fsl/fsl_asrc.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----- sound/soc/fsl/fsl_asrc_common.h | 3 +++ 3 files changed, 75 insertions(+), 5 deletions(-) ^ permalink raw reply [flat|nested] 55+ messages in thread
* [PATCH 1/4] dt-bindings: sound: fsl,asrc: add properties to select in/out clocks 2020-07-02 14:22 ` Arnaud Ferraris (?) @ 2020-07-02 14:22 ` Arnaud Ferraris -1 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-02 14:22 UTC (permalink / raw) Cc: kernel, Arnaud Ferraris, Liam Girdwood, Mark Brown, Rob Herring, Timur Tabi, Nicolin Chen, Xiubo Li, Fabio Estevam, Jaroslav Kysela, Takashi Iwai, alsa-devel, devicetree, linux-kernel, linuxppc-dev The ASRC peripheral accepts a wide range of input and output clocks, but no mechanism exists at the moment to define those as they are currently hardcoded in the driver. This commit adds new properties allowing selection of arbitrary input and output clocks. Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com> --- Documentation/devicetree/bindings/sound/fsl,asrc.txt | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/fsl,asrc.txt b/Documentation/devicetree/bindings/sound/fsl,asrc.txt index 998b4c8a7f78..e26ce9bad617 100644 --- a/Documentation/devicetree/bindings/sound/fsl,asrc.txt +++ b/Documentation/devicetree/bindings/sound/fsl,asrc.txt @@ -55,6 +55,12 @@ Optional properties: Ends, which can replace the fsl,asrc-width. The value is 2 (S16_LE), or 6 (S24_LE). + - fsl,asrc-input-clock : Input clock ID, defaults to INCLK_NONE + (see enum asrc_inclk in fsl_asrc.h) + + - fsl,asrc-output-clock : Output clock ID, defaults to OUTCLK_ASRCK1_CLK + (see enum asrc_outclk in fsl_asrc.h) + Example: asrc: asrc@2034000 { @@ -77,4 +83,6 @@ asrc: asrc@2034000 { "txa", "txb", "txc"; fsl,asrc-rate = <48000>; fsl,asrc-width = <16>; + fsl,asrc-input-clock = <0x3>; + fsl,asrc-output-clock = <0xf>; }; -- 2.27.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* [PATCH 1/4] dt-bindings: sound: fsl, asrc: add properties to select in/out clocks @ 2020-07-02 14:22 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-02 14:22 UTC (permalink / raw) Cc: alsa-devel, devicetree, Arnaud Ferraris, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Jaroslav Kysela, Nicolin Chen, Mark Brown, kernel, Fabio Estevam The ASRC peripheral accepts a wide range of input and output clocks, but no mechanism exists at the moment to define those as they are currently hardcoded in the driver. This commit adds new properties allowing selection of arbitrary input and output clocks. Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com> --- Documentation/devicetree/bindings/sound/fsl,asrc.txt | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/fsl,asrc.txt b/Documentation/devicetree/bindings/sound/fsl,asrc.txt index 998b4c8a7f78..e26ce9bad617 100644 --- a/Documentation/devicetree/bindings/sound/fsl,asrc.txt +++ b/Documentation/devicetree/bindings/sound/fsl,asrc.txt @@ -55,6 +55,12 @@ Optional properties: Ends, which can replace the fsl,asrc-width. The value is 2 (S16_LE), or 6 (S24_LE). + - fsl,asrc-input-clock : Input clock ID, defaults to INCLK_NONE + (see enum asrc_inclk in fsl_asrc.h) + + - fsl,asrc-output-clock : Output clock ID, defaults to OUTCLK_ASRCK1_CLK + (see enum asrc_outclk in fsl_asrc.h) + Example: asrc: asrc@2034000 { @@ -77,4 +83,6 @@ asrc: asrc@2034000 { "txa", "txb", "txc"; fsl,asrc-rate = <48000>; fsl,asrc-width = <16>; + fsl,asrc-input-clock = <0x3>; + fsl,asrc-output-clock = <0xf>; }; -- 2.27.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* [PATCH 1/4] dt-bindings: sound: fsl, asrc: add properties to select in/out clocks @ 2020-07-02 14:22 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-02 14:22 UTC (permalink / raw) Cc: alsa-devel, devicetree, Arnaud Ferraris, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Nicolin Chen, Mark Brown, kernel, Fabio Estevam The ASRC peripheral accepts a wide range of input and output clocks, but no mechanism exists at the moment to define those as they are currently hardcoded in the driver. This commit adds new properties allowing selection of arbitrary input and output clocks. Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com> --- Documentation/devicetree/bindings/sound/fsl,asrc.txt | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/fsl,asrc.txt b/Documentation/devicetree/bindings/sound/fsl,asrc.txt index 998b4c8a7f78..e26ce9bad617 100644 --- a/Documentation/devicetree/bindings/sound/fsl,asrc.txt +++ b/Documentation/devicetree/bindings/sound/fsl,asrc.txt @@ -55,6 +55,12 @@ Optional properties: Ends, which can replace the fsl,asrc-width. The value is 2 (S16_LE), or 6 (S24_LE). + - fsl,asrc-input-clock : Input clock ID, defaults to INCLK_NONE + (see enum asrc_inclk in fsl_asrc.h) + + - fsl,asrc-output-clock : Output clock ID, defaults to OUTCLK_ASRCK1_CLK + (see enum asrc_outclk in fsl_asrc.h) + Example: asrc: asrc@2034000 { @@ -77,4 +83,6 @@ asrc: asrc@2034000 { "txa", "txb", "txc"; fsl,asrc-rate = <48000>; fsl,asrc-width = <16>; + fsl,asrc-input-clock = <0x3>; + fsl,asrc-output-clock = <0xf>; }; -- 2.27.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* [PATCH 2/4] ASoC: fsl_asrc: allow using arbitrary input and output clocks 2020-07-02 14:22 ` Arnaud Ferraris (?) @ 2020-07-02 14:22 ` Arnaud Ferraris -1 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-02 14:22 UTC (permalink / raw) Cc: kernel, Arnaud Ferraris, Liam Girdwood, Mark Brown, Rob Herring, Timur Tabi, Nicolin Chen, Xiubo Li, Fabio Estevam, Jaroslav Kysela, Takashi Iwai, alsa-devel, devicetree, linux-kernel, linuxppc-dev fsl_asrc currently uses hardcoded input and output clocks, preventing its use for anything other than S/PDIF output. This patch adds the ability to select any clock as input or output (by using new DT properties), making it possible to use this peripheral in a more advanced way. Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com> --- sound/soc/fsl/fsl_asrc.c | 18 ++++++++++++++++-- sound/soc/fsl/fsl_asrc_common.h | 3 +++ 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c index 95f6a9617b0b..75df220e4b51 100644 --- a/sound/soc/fsl/fsl_asrc.c +++ b/sound/soc/fsl/fsl_asrc.c @@ -605,8 +605,8 @@ static int fsl_asrc_dai_hw_params(struct snd_pcm_substream *substream, config.pair = pair->index; config.channel_num = channels; - config.inclk = INCLK_NONE; - config.outclk = OUTCLK_ASRCK1_CLK; + config.inclk = asrc->inclk; + config.outclk = asrc->outclk; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { config.input_format = params_format(params); @@ -1067,6 +1067,20 @@ static int fsl_asrc_probe(struct platform_device *pdev) asrc->channel_avail = 10; + ret = of_property_read_u32(np, "fsl,asrc-input-clock", + &asrc->inclk); + if (ret) { + dev_info(&pdev->dev, "no input clock specified, using none\n"); + asrc->inclk = INCLK_NONE; + } + + ret = of_property_read_u32(np, "fsl,asrc-output-clock", + &asrc->outclk); + if (ret) { + dev_info(&pdev->dev, "no output clock specified, using default\n"); + asrc->outclk = OUTCLK_ASRCK1_CLK; + } + ret = of_property_read_u32(np, "fsl,asrc-rate", &asrc->asrc_rate); if (ret) { diff --git a/sound/soc/fsl/fsl_asrc_common.h b/sound/soc/fsl/fsl_asrc_common.h index 7e1c13ca37f1..1468878fbaca 100644 --- a/sound/soc/fsl/fsl_asrc_common.h +++ b/sound/soc/fsl/fsl_asrc_common.h @@ -89,6 +89,9 @@ struct fsl_asrc { struct fsl_asrc_pair *pair[PAIR_CTX_NUM]; unsigned int channel_avail; + enum asrc_inclk inclk; + enum asrc_outclk outclk; + int asrc_rate; snd_pcm_format_t asrc_format; bool use_edma; -- 2.27.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* [PATCH 2/4] ASoC: fsl_asrc: allow using arbitrary input and output clocks @ 2020-07-02 14:22 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-02 14:22 UTC (permalink / raw) Cc: alsa-devel, devicetree, Arnaud Ferraris, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Jaroslav Kysela, Nicolin Chen, Mark Brown, kernel, Fabio Estevam fsl_asrc currently uses hardcoded input and output clocks, preventing its use for anything other than S/PDIF output. This patch adds the ability to select any clock as input or output (by using new DT properties), making it possible to use this peripheral in a more advanced way. Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com> --- sound/soc/fsl/fsl_asrc.c | 18 ++++++++++++++++-- sound/soc/fsl/fsl_asrc_common.h | 3 +++ 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c index 95f6a9617b0b..75df220e4b51 100644 --- a/sound/soc/fsl/fsl_asrc.c +++ b/sound/soc/fsl/fsl_asrc.c @@ -605,8 +605,8 @@ static int fsl_asrc_dai_hw_params(struct snd_pcm_substream *substream, config.pair = pair->index; config.channel_num = channels; - config.inclk = INCLK_NONE; - config.outclk = OUTCLK_ASRCK1_CLK; + config.inclk = asrc->inclk; + config.outclk = asrc->outclk; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { config.input_format = params_format(params); @@ -1067,6 +1067,20 @@ static int fsl_asrc_probe(struct platform_device *pdev) asrc->channel_avail = 10; + ret = of_property_read_u32(np, "fsl,asrc-input-clock", + &asrc->inclk); + if (ret) { + dev_info(&pdev->dev, "no input clock specified, using none\n"); + asrc->inclk = INCLK_NONE; + } + + ret = of_property_read_u32(np, "fsl,asrc-output-clock", + &asrc->outclk); + if (ret) { + dev_info(&pdev->dev, "no output clock specified, using default\n"); + asrc->outclk = OUTCLK_ASRCK1_CLK; + } + ret = of_property_read_u32(np, "fsl,asrc-rate", &asrc->asrc_rate); if (ret) { diff --git a/sound/soc/fsl/fsl_asrc_common.h b/sound/soc/fsl/fsl_asrc_common.h index 7e1c13ca37f1..1468878fbaca 100644 --- a/sound/soc/fsl/fsl_asrc_common.h +++ b/sound/soc/fsl/fsl_asrc_common.h @@ -89,6 +89,9 @@ struct fsl_asrc { struct fsl_asrc_pair *pair[PAIR_CTX_NUM]; unsigned int channel_avail; + enum asrc_inclk inclk; + enum asrc_outclk outclk; + int asrc_rate; snd_pcm_format_t asrc_format; bool use_edma; -- 2.27.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* [PATCH 2/4] ASoC: fsl_asrc: allow using arbitrary input and output clocks @ 2020-07-02 14:22 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-02 14:22 UTC (permalink / raw) Cc: alsa-devel, devicetree, Arnaud Ferraris, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Nicolin Chen, Mark Brown, kernel, Fabio Estevam fsl_asrc currently uses hardcoded input and output clocks, preventing its use for anything other than S/PDIF output. This patch adds the ability to select any clock as input or output (by using new DT properties), making it possible to use this peripheral in a more advanced way. Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com> --- sound/soc/fsl/fsl_asrc.c | 18 ++++++++++++++++-- sound/soc/fsl/fsl_asrc_common.h | 3 +++ 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c index 95f6a9617b0b..75df220e4b51 100644 --- a/sound/soc/fsl/fsl_asrc.c +++ b/sound/soc/fsl/fsl_asrc.c @@ -605,8 +605,8 @@ static int fsl_asrc_dai_hw_params(struct snd_pcm_substream *substream, config.pair = pair->index; config.channel_num = channels; - config.inclk = INCLK_NONE; - config.outclk = OUTCLK_ASRCK1_CLK; + config.inclk = asrc->inclk; + config.outclk = asrc->outclk; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { config.input_format = params_format(params); @@ -1067,6 +1067,20 @@ static int fsl_asrc_probe(struct platform_device *pdev) asrc->channel_avail = 10; + ret = of_property_read_u32(np, "fsl,asrc-input-clock", + &asrc->inclk); + if (ret) { + dev_info(&pdev->dev, "no input clock specified, using none\n"); + asrc->inclk = INCLK_NONE; + } + + ret = of_property_read_u32(np, "fsl,asrc-output-clock", + &asrc->outclk); + if (ret) { + dev_info(&pdev->dev, "no output clock specified, using default\n"); + asrc->outclk = OUTCLK_ASRCK1_CLK; + } + ret = of_property_read_u32(np, "fsl,asrc-rate", &asrc->asrc_rate); if (ret) { diff --git a/sound/soc/fsl/fsl_asrc_common.h b/sound/soc/fsl/fsl_asrc_common.h index 7e1c13ca37f1..1468878fbaca 100644 --- a/sound/soc/fsl/fsl_asrc_common.h +++ b/sound/soc/fsl/fsl_asrc_common.h @@ -89,6 +89,9 @@ struct fsl_asrc { struct fsl_asrc_pair *pair[PAIR_CTX_NUM]; unsigned int channel_avail; + enum asrc_inclk inclk; + enum asrc_outclk outclk; + int asrc_rate; snd_pcm_format_t asrc_format; bool use_edma; -- 2.27.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [PATCH 2/4] ASoC: fsl_asrc: allow using arbitrary input and output clocks 2020-07-02 14:22 ` Arnaud Ferraris (?) (?) @ 2020-07-02 17:42 ` kernel test robot -1 siblings, 0 replies; 55+ messages in thread From: kernel test robot @ 2020-07-02 17:42 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 7008 bytes --] Hi Arnaud, Thank you for the patch! Yet something to improve: [auto build test ERROR on v5.8-rc3] [cannot apply to asoc/for-next next-20200702] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Arnaud-Ferraris/ASoC-fsl_asrc-allow-selecting-arbitrary-clocks/20200702-222640 base: 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68 config: i386-randconfig-s002-20200702 (attached as .config) compiler: gcc-9 (Debian 9.3.0-14) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-3-gfa153962-dirty # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp@intel.com> All errors (new ones prefixed by >>): In file included from sound/soc/fsl/fsl_asrc.h:13, from sound/soc/fsl/fsl_asrc.c:19: >> sound/soc/fsl/fsl_asrc_common.h:92:18: error: field 'inclk' has incomplete type 92 | enum asrc_inclk inclk; | ^~~~~ >> sound/soc/fsl/fsl_asrc_common.h:93:19: error: field 'outclk' has incomplete type 93 | enum asrc_outclk outclk; | ^~~~~~ -- In file included from sound/soc/fsl/fsl_easrc.h:12, from sound/soc/fsl/fsl_easrc.c:31: >> sound/soc/fsl/fsl_asrc_common.h:92:18: error: field 'inclk' has incomplete type 92 | enum asrc_inclk inclk; | ^~~~~ >> sound/soc/fsl/fsl_asrc_common.h:93:19: error: field 'outclk' has incomplete type 93 | enum asrc_outclk outclk; | ^~~~~~ sound/soc/fsl/fsl_easrc.c: In function 'fsl_easrc_set_rs_ratio': sound/soc/fsl/fsl_easrc.c:182:15: warning: variable 'int_bits' set but not used [-Wunused-but-set-variable] 182 | unsigned int int_bits; | ^~~~~~~~ sound/soc/fsl/fsl_easrc.c: At top level: sound/soc/fsl/fsl_easrc.c:967:5: warning: no previous prototype for 'fsl_easrc_config_context' [-Wmissing-prototypes] 967 | int fsl_easrc_config_context(struct fsl_asrc *easrc, unsigned int ctx_id) | ^~~~~~~~~~~~~~~~~~~~~~~~ sound/soc/fsl/fsl_easrc.c:1128:5: warning: no previous prototype for 'fsl_easrc_set_ctx_format' [-Wmissing-prototypes] 1128 | int fsl_easrc_set_ctx_format(struct fsl_asrc_pair *ctx, | ^~~~~~~~~~~~~~~~~~~~~~~~ sound/soc/fsl/fsl_easrc.c:1201:5: warning: no previous prototype for 'fsl_easrc_set_ctx_organziation' [-Wmissing-prototypes] 1201 | int fsl_easrc_set_ctx_organziation(struct fsl_asrc_pair *ctx) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sound/soc/fsl/fsl_easrc.c: In function 'fsl_easrc_set_ctx_organziation': sound/soc/fsl/fsl_easrc.c:1204:17: warning: variable 'dev' set but not used [-Wunused-but-set-variable] 1204 | struct device *dev; | ^~~ sound/soc/fsl/fsl_easrc.c: At top level: sound/soc/fsl/fsl_easrc.c:1245:5: warning: no previous prototype for 'fsl_easrc_request_context' [-Wmissing-prototypes] 1245 | int fsl_easrc_request_context(int channels, struct fsl_asrc_pair *ctx) | ^~~~~~~~~~~~~~~~~~~~~~~~~ sound/soc/fsl/fsl_easrc.c:1290:6: warning: no previous prototype for 'fsl_easrc_release_context' [-Wmissing-prototypes] 1290 | void fsl_easrc_release_context(struct fsl_asrc_pair *ctx) | ^~~~~~~~~~~~~~~~~~~~~~~~~ sound/soc/fsl/fsl_easrc.c: In function 'fsl_easrc_release_context': sound/soc/fsl/fsl_easrc.c:1294:17: warning: variable 'dev' set but not used [-Wunused-but-set-variable] 1294 | struct device *dev; | ^~~ sound/soc/fsl/fsl_easrc.c: At top level: sound/soc/fsl/fsl_easrc.c:1317:5: warning: no previous prototype for 'fsl_easrc_start_context' [-Wmissing-prototypes] 1317 | int fsl_easrc_start_context(struct fsl_asrc_pair *ctx) | ^~~~~~~~~~~~~~~~~~~~~~~ sound/soc/fsl/fsl_easrc.c:1335:5: warning: no previous prototype for 'fsl_easrc_stop_context' [-Wmissing-prototypes] 1335 | int fsl_easrc_stop_context(struct fsl_asrc_pair *ctx) | ^~~~~~~~~~~~~~~~~~~~~~ sound/soc/fsl/fsl_easrc.c:1382:18: warning: no previous prototype for 'fsl_easrc_get_dma_channel' [-Wmissing-prototypes] 1382 | struct dma_chan *fsl_easrc_get_dma_channel(struct fsl_asrc_pair *ctx, | ^~~~~~~~~~~~~~~~~~~~~~~~~ vim +/inclk +92 sound/soc/fsl/fsl_asrc_common.h 53 54 /** 55 * fsl_asrc: ASRC common data 56 * 57 * @dma_params_rx: DMA parameters for receive channel 58 * @dma_params_tx: DMA parameters for transmit channel 59 * @pdev: platform device pointer 60 * @regmap: regmap handler 61 * @paddr: physical address to the base address of registers 62 * @mem_clk: clock source to access register 63 * @ipg_clk: clock source to drive peripheral 64 * @spba_clk: SPBA clock (optional, depending on SoC design) 65 * @lock: spin lock for resource protection 66 * @pair: pair pointers 67 * @channel_avail: non-occupied channel numbers 68 * @asrc_rate: default sample rate for ASoC Back-Ends 69 * @asrc_format: default sample format for ASoC Back-Ends 70 * @use_edma: edma is used 71 * @get_dma_channel: function pointer 72 * @request_pair: function pointer 73 * @release_pair: function pointer 74 * @get_fifo_addr: function pointer 75 * @pair_priv_size: size of pair private struct. 76 * @private: private data structure 77 */ 78 struct fsl_asrc { 79 struct snd_dmaengine_dai_dma_data dma_params_rx; 80 struct snd_dmaengine_dai_dma_data dma_params_tx; 81 struct platform_device *pdev; 82 struct regmap *regmap; 83 unsigned long paddr; 84 struct clk *mem_clk; 85 struct clk *ipg_clk; 86 struct clk *spba_clk; 87 spinlock_t lock; /* spin lock for resource protection */ 88 89 struct fsl_asrc_pair *pair[PAIR_CTX_NUM]; 90 unsigned int channel_avail; 91 > 92 enum asrc_inclk inclk; > 93 enum asrc_outclk outclk; 94 95 int asrc_rate; 96 snd_pcm_format_t asrc_format; 97 bool use_edma; 98 99 struct dma_chan *(*get_dma_channel)(struct fsl_asrc_pair *pair, bool dir); 100 int (*request_pair)(int channels, struct fsl_asrc_pair *pair); 101 void (*release_pair)(struct fsl_asrc_pair *pair); 102 int (*get_fifo_addr)(u8 dir, enum asrc_pair_index index); 103 size_t pair_priv_size; 104 105 void *private; 106 }; 107 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org [-- Attachment #2: config.gz --] [-- Type: application/gzip, Size: 34696 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 2/4] ASoC: fsl_asrc: allow using arbitrary input and output clocks 2020-07-02 14:22 ` Arnaud Ferraris ` (2 preceding siblings ...) (?) @ 2020-07-02 21:33 ` kernel test robot -1 siblings, 0 replies; 55+ messages in thread From: kernel test robot @ 2020-07-02 21:33 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 21190 bytes --] Hi Arnaud, Thank you for the patch! Yet something to improve: [auto build test ERROR on v5.8-rc3] [cannot apply to asoc/for-next next-20200702] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Arnaud-Ferraris/ASoC-fsl_asrc-allow-selecting-arbitrary-clocks/20200702-222640 base: 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68 config: powerpc64-randconfig-r003-20200701 (attached as .config) compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 003a086ffc0d1affbb8300b36225fb8150a2d40a) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc64 cross compiling tool for clang build # apt-get install binutils-powerpc64-linux-gnu # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp@intel.com> All errors (new ones prefixed by >>): #define __do_outl(val, port) writel(val,(PCI_IO_ADDR)_IO_BASE+port); ~~~~~~~~~~~~~~~~~~~~~^ In file included from sound/soc/fsl/fsl_asrc.c:11: In file included from include/linux/dma-mapping.h:11: In file included from include/linux/scatterlist.h:9: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:43:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insb, (unsigned long p, void *b, unsigned long c), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~~~~~~~~~~~~~ <scratch space>:160:1: note: expanded from here __do_insb ^ arch/powerpc/include/asm/io.h:541:56: note: expanded from macro '__do_insb' #define __do_insb(p, b, n) readsb((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~~~~~~~~~~~~~~~~~~~~~^ In file included from sound/soc/fsl/fsl_asrc.c:11: In file included from include/linux/dma-mapping.h:11: In file included from include/linux/scatterlist.h:9: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~~~~~~~~~~~~~ <scratch space>:162:1: note: expanded from here __do_insw ^ arch/powerpc/include/asm/io.h:542:56: note: expanded from macro '__do_insw' #define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~~~~~~~~~~~~~~~~~~~~~^ In file included from sound/soc/fsl/fsl_asrc.c:11: In file included from include/linux/dma-mapping.h:11: In file included from include/linux/scatterlist.h:9: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~~~~~~~~~~~~~ <scratch space>:164:1: note: expanded from here __do_insl ^ arch/powerpc/include/asm/io.h:543:56: note: expanded from macro '__do_insl' #define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~~~~~~~~~~~~~~~~~~~~~^ In file included from sound/soc/fsl/fsl_asrc.c:11: In file included from include/linux/dma-mapping.h:11: In file included from include/linux/scatterlist.h:9: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~~~~~~~~~~~~~ <scratch space>:166:1: note: expanded from here __do_outsb ^ arch/powerpc/include/asm/io.h:544:58: note: expanded from macro '__do_outsb' #define __do_outsb(p, b, n) writesb((PCI_IO_ADDR)_IO_BASE+(p),(b),(n)) ~~~~~~~~~~~~~~~~~~~~~^ In file included from sound/soc/fsl/fsl_asrc.c:11: In file included from include/linux/dma-mapping.h:11: In file included from include/linux/scatterlist.h:9: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:51:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(outsw, (unsigned long p, const void *b, unsigned long c), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~~~~~~~~~~~~~ <scratch space>:168:1: note: expanded from here __do_outsw ^ arch/powerpc/include/asm/io.h:545:58: note: expanded from macro '__do_outsw' #define __do_outsw(p, b, n) writesw((PCI_IO_ADDR)_IO_BASE+(p),(b),(n)) ~~~~~~~~~~~~~~~~~~~~~^ In file included from sound/soc/fsl/fsl_asrc.c:11: In file included from include/linux/dma-mapping.h:11: In file included from include/linux/scatterlist.h:9: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:53:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(outsl, (unsigned long p, const void *b, unsigned long c), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~~~~~~~~~~~~~ <scratch space>:170:1: note: expanded from here __do_outsl ^ arch/powerpc/include/asm/io.h:546:58: note: expanded from macro '__do_outsl' #define __do_outsl(p, b, n) writesl((PCI_IO_ADDR)_IO_BASE+(p),(b),(n)) ~~~~~~~~~~~~~~~~~~~~~^ In file included from sound/soc/fsl/fsl_asrc.c:19: In file included from sound/soc/fsl/fsl_asrc.h:13: >> sound/soc/fsl/fsl_asrc_common.h:92:18: error: field has incomplete type 'enum asrc_inclk' enum asrc_inclk inclk; ^ sound/soc/fsl/fsl_asrc_common.h:92:7: note: forward declaration of 'enum asrc_inclk' enum asrc_inclk inclk; ^ >> sound/soc/fsl/fsl_asrc_common.h:93:19: error: field has incomplete type 'enum asrc_outclk' enum asrc_outclk outclk; ^ sound/soc/fsl/fsl_asrc_common.h:93:7: note: forward declaration of 'enum asrc_outclk' enum asrc_outclk outclk; ^ 12 warnings and 2 errors generated. -- #define __do_outl(val, port) writel(val,(PCI_IO_ADDR)_IO_BASE+port); ~~~~~~~~~~~~~~~~~~~~~^ In file included from sound/soc/fsl/fsl_easrc.c:7: In file included from include/linux/dma-mapping.h:11: In file included from include/linux/scatterlist.h:9: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:43:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insb, (unsigned long p, void *b, unsigned long c), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~~~~~~~~~~~~~ <scratch space>:164:1: note: expanded from here __do_insb ^ arch/powerpc/include/asm/io.h:541:56: note: expanded from macro '__do_insb' #define __do_insb(p, b, n) readsb((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~~~~~~~~~~~~~~~~~~~~~^ In file included from sound/soc/fsl/fsl_easrc.c:7: In file included from include/linux/dma-mapping.h:11: In file included from include/linux/scatterlist.h:9: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~~~~~~~~~~~~~ <scratch space>:166:1: note: expanded from here __do_insw ^ arch/powerpc/include/asm/io.h:542:56: note: expanded from macro '__do_insw' #define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~~~~~~~~~~~~~~~~~~~~~^ In file included from sound/soc/fsl/fsl_easrc.c:7: In file included from include/linux/dma-mapping.h:11: In file included from include/linux/scatterlist.h:9: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~~~~~~~~~~~~~ <scratch space>:168:1: note: expanded from here __do_insl ^ arch/powerpc/include/asm/io.h:543:56: note: expanded from macro '__do_insl' #define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~~~~~~~~~~~~~~~~~~~~~^ In file included from sound/soc/fsl/fsl_easrc.c:7: In file included from include/linux/dma-mapping.h:11: In file included from include/linux/scatterlist.h:9: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~~~~~~~~~~~~~ <scratch space>:170:1: note: expanded from here __do_outsb ^ arch/powerpc/include/asm/io.h:544:58: note: expanded from macro '__do_outsb' #define __do_outsb(p, b, n) writesb((PCI_IO_ADDR)_IO_BASE+(p),(b),(n)) ~~~~~~~~~~~~~~~~~~~~~^ In file included from sound/soc/fsl/fsl_easrc.c:7: In file included from include/linux/dma-mapping.h:11: In file included from include/linux/scatterlist.h:9: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:51:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(outsw, (unsigned long p, const void *b, unsigned long c), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~~~~~~~~~~~~~ <scratch space>:172:1: note: expanded from here __do_outsw ^ arch/powerpc/include/asm/io.h:545:58: note: expanded from macro '__do_outsw' #define __do_outsw(p, b, n) writesw((PCI_IO_ADDR)_IO_BASE+(p),(b),(n)) ~~~~~~~~~~~~~~~~~~~~~^ In file included from sound/soc/fsl/fsl_easrc.c:7: In file included from include/linux/dma-mapping.h:11: In file included from include/linux/scatterlist.h:9: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:53:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(outsl, (unsigned long p, const void *b, unsigned long c), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~~~~~~~~~~~~~ <scratch space>:174:1: note: expanded from here __do_outsl ^ arch/powerpc/include/asm/io.h:546:58: note: expanded from macro '__do_outsl' #define __do_outsl(p, b, n) writesl((PCI_IO_ADDR)_IO_BASE+(p),(b),(n)) ~~~~~~~~~~~~~~~~~~~~~^ In file included from sound/soc/fsl/fsl_easrc.c:31: In file included from sound/soc/fsl/fsl_easrc.h:12: >> sound/soc/fsl/fsl_asrc_common.h:92:18: error: field has incomplete type 'enum asrc_inclk' enum asrc_inclk inclk; ^ sound/soc/fsl/fsl_asrc_common.h:92:7: note: forward declaration of 'enum asrc_inclk' enum asrc_inclk inclk; ^ >> sound/soc/fsl/fsl_asrc_common.h:93:19: error: field has incomplete type 'enum asrc_outclk' enum asrc_outclk outclk; ^ sound/soc/fsl/fsl_asrc_common.h:93:7: note: forward declaration of 'enum asrc_outclk' enum asrc_outclk outclk; ^ sound/soc/fsl/fsl_easrc.c:967:5: warning: no previous prototype for function 'fsl_easrc_config_context' [-Wmissing-prototypes] int fsl_easrc_config_context(struct fsl_asrc *easrc, unsigned int ctx_id) ^ sound/soc/fsl/fsl_easrc.c:967:1: note: declare 'static' if the function is not intended to be used outside of this translation unit int fsl_easrc_config_context(struct fsl_asrc *easrc, unsigned int ctx_id) ^ static sound/soc/fsl/fsl_easrc.c:1128:5: warning: no previous prototype for function 'fsl_easrc_set_ctx_format' [-Wmissing-prototypes] int fsl_easrc_set_ctx_format(struct fsl_asrc_pair *ctx, ^ sound/soc/fsl/fsl_easrc.c:1128:1: note: declare 'static' if the function is not intended to be used outside of this translation unit int fsl_easrc_set_ctx_format(struct fsl_asrc_pair *ctx, ^ static sound/soc/fsl/fsl_easrc.c:1201:5: warning: no previous prototype for function 'fsl_easrc_set_ctx_organziation' [-Wmissing-prototypes] int fsl_easrc_set_ctx_organziation(struct fsl_asrc_pair *ctx) ^ sound/soc/fsl/fsl_easrc.c:1201:1: note: declare 'static' if the function is not intended to be used outside of this translation unit int fsl_easrc_set_ctx_organziation(struct fsl_asrc_pair *ctx) ^ static sound/soc/fsl/fsl_easrc.c:1245:5: warning: no previous prototype for function 'fsl_easrc_request_context' [-Wmissing-prototypes] int fsl_easrc_request_context(int channels, struct fsl_asrc_pair *ctx) ^ sound/soc/fsl/fsl_easrc.c:1245:1: note: declare 'static' if the function is not intended to be used outside of this translation unit int fsl_easrc_request_context(int channels, struct fsl_asrc_pair *ctx) ^ static sound/soc/fsl/fsl_easrc.c:1290:6: warning: no previous prototype for function 'fsl_easrc_release_context' [-Wmissing-prototypes] void fsl_easrc_release_context(struct fsl_asrc_pair *ctx) ^ sound/soc/fsl/fsl_easrc.c:1290:1: note: declare 'static' if the function is not intended to be used outside of this translation unit void fsl_easrc_release_context(struct fsl_asrc_pair *ctx) ^ static sound/soc/fsl/fsl_easrc.c:1317:5: warning: no previous prototype for function 'fsl_easrc_start_context' [-Wmissing-prototypes] int fsl_easrc_start_context(struct fsl_asrc_pair *ctx) ^ sound/soc/fsl/fsl_easrc.c:1317:1: note: declare 'static' if the function is not intended to be used outside of this translation unit int fsl_easrc_start_context(struct fsl_asrc_pair *ctx) ^ static sound/soc/fsl/fsl_easrc.c:1335:5: warning: no previous prototype for function 'fsl_easrc_stop_context' [-Wmissing-prototypes] int fsl_easrc_stop_context(struct fsl_asrc_pair *ctx) ^ sound/soc/fsl/fsl_easrc.c:1335:1: note: declare 'static' if the function is not intended to be used outside of this translation unit int fsl_easrc_stop_context(struct fsl_asrc_pair *ctx) ^ static sound/soc/fsl/fsl_easrc.c:1382:18: warning: no previous prototype for function 'fsl_easrc_get_dma_channel' [-Wmissing-prototypes] struct dma_chan *fsl_easrc_get_dma_channel(struct fsl_asrc_pair *ctx, ^ sound/soc/fsl/fsl_easrc.c:1382:1: note: declare 'static' if the function is not intended to be used outside of this translation unit struct dma_chan *fsl_easrc_get_dma_channel(struct fsl_asrc_pair *ctx, ^ static 20 warnings and 2 errors generated. vim +92 sound/soc/fsl/fsl_asrc_common.h 53 54 /** 55 * fsl_asrc: ASRC common data 56 * 57 * @dma_params_rx: DMA parameters for receive channel 58 * @dma_params_tx: DMA parameters for transmit channel 59 * @pdev: platform device pointer 60 * @regmap: regmap handler 61 * @paddr: physical address to the base address of registers 62 * @mem_clk: clock source to access register 63 * @ipg_clk: clock source to drive peripheral 64 * @spba_clk: SPBA clock (optional, depending on SoC design) 65 * @lock: spin lock for resource protection 66 * @pair: pair pointers 67 * @channel_avail: non-occupied channel numbers 68 * @asrc_rate: default sample rate for ASoC Back-Ends 69 * @asrc_format: default sample format for ASoC Back-Ends 70 * @use_edma: edma is used 71 * @get_dma_channel: function pointer 72 * @request_pair: function pointer 73 * @release_pair: function pointer 74 * @get_fifo_addr: function pointer 75 * @pair_priv_size: size of pair private struct. 76 * @private: private data structure 77 */ 78 struct fsl_asrc { 79 struct snd_dmaengine_dai_dma_data dma_params_rx; 80 struct snd_dmaengine_dai_dma_data dma_params_tx; 81 struct platform_device *pdev; 82 struct regmap *regmap; 83 unsigned long paddr; 84 struct clk *mem_clk; 85 struct clk *ipg_clk; 86 struct clk *spba_clk; 87 spinlock_t lock; /* spin lock for resource protection */ 88 89 struct fsl_asrc_pair *pair[PAIR_CTX_NUM]; 90 unsigned int channel_avail; 91 > 92 enum asrc_inclk inclk; > 93 enum asrc_outclk outclk; 94 95 int asrc_rate; 96 snd_pcm_format_t asrc_format; 97 bool use_edma; 98 99 struct dma_chan *(*get_dma_channel)(struct fsl_asrc_pair *pair, bool dir); 100 int (*request_pair)(int channels, struct fsl_asrc_pair *pair); 101 void (*release_pair)(struct fsl_asrc_pair *pair); 102 int (*get_fifo_addr)(u8 dir, enum asrc_pair_index index); 103 size_t pair_priv_size; 104 105 void *private; 106 }; 107 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org [-- Attachment #2: config.gz --] [-- Type: application/gzip, Size: 27802 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* [PATCH 3/4] ASoC: fsl_asrc: always use ratio for conversion 2020-07-02 14:22 ` Arnaud Ferraris (?) @ 2020-07-02 14:22 ` Arnaud Ferraris -1 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-02 14:22 UTC (permalink / raw) Cc: kernel, Arnaud Ferraris, Liam Girdwood, Mark Brown, Rob Herring, Timur Tabi, Nicolin Chen, Xiubo Li, Fabio Estevam, Jaroslav Kysela, Takashi Iwai, alsa-devel, devicetree, linux-kernel, linuxppc-dev Even when not in "Ideal Ratio" mode, ASRC can use an internally measured ratio, which greatly improves the conversion quality. This patch ensures we always use at least the internal ratio. Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com> --- sound/soc/fsl/fsl_asrc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c index 75df220e4b51..65e7307a3df0 100644 --- a/sound/soc/fsl/fsl_asrc.c +++ b/sound/soc/fsl/fsl_asrc.c @@ -451,7 +451,7 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate) regmap_update_bits(asrc->regmap, REG_ASRCTR, ASRCTR_ATSi_MASK(index), ASRCTR_ATS(index)); regmap_update_bits(asrc->regmap, REG_ASRCTR, - ASRCTR_USRi_MASK(index), 0); + ASRCTR_USRi_MASK(index), ASRCTR_USR(index)); /* Set the input and output clock sources */ regmap_update_bits(asrc->regmap, REG_ASRCSR, @@ -493,8 +493,7 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate) /* Enable Ideal Ratio mode */ regmap_update_bits(asrc->regmap, REG_ASRCTR, - ASRCTR_IDRi_MASK(index) | ASRCTR_USRi_MASK(index), - ASRCTR_IDR(index) | ASRCTR_USR(index)); + ASRCTR_IDRi_MASK(index), ASRCTR_IDR(index)); fsl_asrc_sel_proc(inrate, outrate, &pre_proc, &post_proc); -- 2.27.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* [PATCH 3/4] ASoC: fsl_asrc: always use ratio for conversion @ 2020-07-02 14:22 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-02 14:22 UTC (permalink / raw) Cc: alsa-devel, devicetree, Arnaud Ferraris, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Jaroslav Kysela, Nicolin Chen, Mark Brown, kernel, Fabio Estevam Even when not in "Ideal Ratio" mode, ASRC can use an internally measured ratio, which greatly improves the conversion quality. This patch ensures we always use at least the internal ratio. Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com> --- sound/soc/fsl/fsl_asrc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c index 75df220e4b51..65e7307a3df0 100644 --- a/sound/soc/fsl/fsl_asrc.c +++ b/sound/soc/fsl/fsl_asrc.c @@ -451,7 +451,7 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate) regmap_update_bits(asrc->regmap, REG_ASRCTR, ASRCTR_ATSi_MASK(index), ASRCTR_ATS(index)); regmap_update_bits(asrc->regmap, REG_ASRCTR, - ASRCTR_USRi_MASK(index), 0); + ASRCTR_USRi_MASK(index), ASRCTR_USR(index)); /* Set the input and output clock sources */ regmap_update_bits(asrc->regmap, REG_ASRCSR, @@ -493,8 +493,7 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate) /* Enable Ideal Ratio mode */ regmap_update_bits(asrc->regmap, REG_ASRCTR, - ASRCTR_IDRi_MASK(index) | ASRCTR_USRi_MASK(index), - ASRCTR_IDR(index) | ASRCTR_USR(index)); + ASRCTR_IDRi_MASK(index), ASRCTR_IDR(index)); fsl_asrc_sel_proc(inrate, outrate, &pre_proc, &post_proc); -- 2.27.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* [PATCH 3/4] ASoC: fsl_asrc: always use ratio for conversion @ 2020-07-02 14:22 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-02 14:22 UTC (permalink / raw) Cc: alsa-devel, devicetree, Arnaud Ferraris, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Nicolin Chen, Mark Brown, kernel, Fabio Estevam Even when not in "Ideal Ratio" mode, ASRC can use an internally measured ratio, which greatly improves the conversion quality. This patch ensures we always use at least the internal ratio. Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com> --- sound/soc/fsl/fsl_asrc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c index 75df220e4b51..65e7307a3df0 100644 --- a/sound/soc/fsl/fsl_asrc.c +++ b/sound/soc/fsl/fsl_asrc.c @@ -451,7 +451,7 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate) regmap_update_bits(asrc->regmap, REG_ASRCTR, ASRCTR_ATSi_MASK(index), ASRCTR_ATS(index)); regmap_update_bits(asrc->regmap, REG_ASRCTR, - ASRCTR_USRi_MASK(index), 0); + ASRCTR_USRi_MASK(index), ASRCTR_USR(index)); /* Set the input and output clock sources */ regmap_update_bits(asrc->regmap, REG_ASRCSR, @@ -493,8 +493,7 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate) /* Enable Ideal Ratio mode */ regmap_update_bits(asrc->regmap, REG_ASRCTR, - ASRCTR_IDRi_MASK(index) | ASRCTR_USRi_MASK(index), - ASRCTR_IDR(index) | ASRCTR_USR(index)); + ASRCTR_IDRi_MASK(index), ASRCTR_IDR(index)); fsl_asrc_sel_proc(inrate, outrate, &pre_proc, &post_proc); -- 2.27.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* [PATCH 4/4] ASoC: fsl_asrc: swap input and output clocks in capture mode 2020-07-02 14:22 ` Arnaud Ferraris (?) @ 2020-07-02 14:22 ` Arnaud Ferraris -1 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-02 14:22 UTC (permalink / raw) Cc: kernel, Arnaud Ferraris, Liam Girdwood, Mark Brown, Rob Herring, Timur Tabi, Nicolin Chen, Xiubo Li, Fabio Estevam, Jaroslav Kysela, Takashi Iwai, alsa-devel, devicetree, linux-kernel, linuxppc-dev The input clock is the reference clock we need to convert the stream to, which therefore has to be the clock of the origin stream/device. When the stream is bi-directional and we want ASRC to act on both directions, we need to swap the input and output clocks between the playback and capture streams. As some of the clocks have different ID's depending on whether they are used as input or output, this requires adding a new function to find the output clock ID corresponding to a given input clock. Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com> --- sound/soc/fsl/fsl_asrc.c | 50 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 48 insertions(+), 2 deletions(-) diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c index 65e7307a3df0..5aeab1fbcdd9 100644 --- a/sound/soc/fsl/fsl_asrc.c +++ b/sound/soc/fsl/fsl_asrc.c @@ -506,6 +506,50 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate) return fsl_asrc_set_ideal_ratio(pair, inrate, outrate); } +/** + * Select the output clock corresponding to a given input clock (and vice-versa) + * + * If we want to setup a capture channel, the input and output clocks have to + * be swapped. + * However, even if most of the clocks have the same index when used as input + * or output, some of them (ESAI, SSI* and SPDIF) are different: + * - the TX output clock has the index of the corresponding RX input clock + * - the RX output clock has the index of the corresponding TX input clock + * + * This function makes sure that we use the proper clock index when swapping + * the input and output clocks. + */ +static enum asrc_outclk fsl_asrc_get_capture_clock(enum asrc_inclk inclk) +{ + enum asrc_outclk outclk; + + switch (inclk) { + case INCLK_ESAI_RX: + case INCLK_SSI1_RX: + case INCLK_SSI2_RX: + case INCLK_SPDIF_RX: + outclk = inclk + 0x8; + break; + case INCLK_SSI3_RX: + outclk = OUTCLK_SSI3_RX; + break; + case INCLK_ESAI_TX: + case INCLK_SSI1_TX: + case INCLK_SSI2_TX: + case INCLK_SPDIF_TX: + outclk = inclk - 0x8; + break; + case INCLK_SSI3_TX: + outclk = OUTCLK_SSI3_TX; + break; + default: + outclk = inclk; + break; + } + + return outclk; +} + /** * Start the assigned ASRC pair * @@ -604,15 +648,17 @@ static int fsl_asrc_dai_hw_params(struct snd_pcm_substream *substream, config.pair = pair->index; config.channel_num = channels; - config.inclk = asrc->inclk; - config.outclk = asrc->outclk; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { + config.inclk = asrc->inclk; + config.outclk = asrc->outclk; config.input_format = params_format(params); config.output_format = asrc->asrc_format; config.input_sample_rate = rate; config.output_sample_rate = asrc->asrc_rate; } else { + config.inclk = fsl_asrc_get_capture_clock(asrc->outclk); + config.outclk = fsl_asrc_get_capture_clock(asrc->inclk); config.input_format = asrc->asrc_format; config.output_format = params_format(params); config.input_sample_rate = asrc->asrc_rate; -- 2.27.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* [PATCH 4/4] ASoC: fsl_asrc: swap input and output clocks in capture mode @ 2020-07-02 14:22 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-02 14:22 UTC (permalink / raw) Cc: alsa-devel, devicetree, Arnaud Ferraris, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Jaroslav Kysela, Nicolin Chen, Mark Brown, kernel, Fabio Estevam The input clock is the reference clock we need to convert the stream to, which therefore has to be the clock of the origin stream/device. When the stream is bi-directional and we want ASRC to act on both directions, we need to swap the input and output clocks between the playback and capture streams. As some of the clocks have different ID's depending on whether they are used as input or output, this requires adding a new function to find the output clock ID corresponding to a given input clock. Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com> --- sound/soc/fsl/fsl_asrc.c | 50 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 48 insertions(+), 2 deletions(-) diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c index 65e7307a3df0..5aeab1fbcdd9 100644 --- a/sound/soc/fsl/fsl_asrc.c +++ b/sound/soc/fsl/fsl_asrc.c @@ -506,6 +506,50 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate) return fsl_asrc_set_ideal_ratio(pair, inrate, outrate); } +/** + * Select the output clock corresponding to a given input clock (and vice-versa) + * + * If we want to setup a capture channel, the input and output clocks have to + * be swapped. + * However, even if most of the clocks have the same index when used as input + * or output, some of them (ESAI, SSI* and SPDIF) are different: + * - the TX output clock has the index of the corresponding RX input clock + * - the RX output clock has the index of the corresponding TX input clock + * + * This function makes sure that we use the proper clock index when swapping + * the input and output clocks. + */ +static enum asrc_outclk fsl_asrc_get_capture_clock(enum asrc_inclk inclk) +{ + enum asrc_outclk outclk; + + switch (inclk) { + case INCLK_ESAI_RX: + case INCLK_SSI1_RX: + case INCLK_SSI2_RX: + case INCLK_SPDIF_RX: + outclk = inclk + 0x8; + break; + case INCLK_SSI3_RX: + outclk = OUTCLK_SSI3_RX; + break; + case INCLK_ESAI_TX: + case INCLK_SSI1_TX: + case INCLK_SSI2_TX: + case INCLK_SPDIF_TX: + outclk = inclk - 0x8; + break; + case INCLK_SSI3_TX: + outclk = OUTCLK_SSI3_TX; + break; + default: + outclk = inclk; + break; + } + + return outclk; +} + /** * Start the assigned ASRC pair * @@ -604,15 +648,17 @@ static int fsl_asrc_dai_hw_params(struct snd_pcm_substream *substream, config.pair = pair->index; config.channel_num = channels; - config.inclk = asrc->inclk; - config.outclk = asrc->outclk; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { + config.inclk = asrc->inclk; + config.outclk = asrc->outclk; config.input_format = params_format(params); config.output_format = asrc->asrc_format; config.input_sample_rate = rate; config.output_sample_rate = asrc->asrc_rate; } else { + config.inclk = fsl_asrc_get_capture_clock(asrc->outclk); + config.outclk = fsl_asrc_get_capture_clock(asrc->inclk); config.input_format = asrc->asrc_format; config.output_format = params_format(params); config.input_sample_rate = asrc->asrc_rate; -- 2.27.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* [PATCH 4/4] ASoC: fsl_asrc: swap input and output clocks in capture mode @ 2020-07-02 14:22 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-02 14:22 UTC (permalink / raw) Cc: alsa-devel, devicetree, Arnaud Ferraris, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Nicolin Chen, Mark Brown, kernel, Fabio Estevam The input clock is the reference clock we need to convert the stream to, which therefore has to be the clock of the origin stream/device. When the stream is bi-directional and we want ASRC to act on both directions, we need to swap the input and output clocks between the playback and capture streams. As some of the clocks have different ID's depending on whether they are used as input or output, this requires adding a new function to find the output clock ID corresponding to a given input clock. Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com> --- sound/soc/fsl/fsl_asrc.c | 50 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 48 insertions(+), 2 deletions(-) diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c index 65e7307a3df0..5aeab1fbcdd9 100644 --- a/sound/soc/fsl/fsl_asrc.c +++ b/sound/soc/fsl/fsl_asrc.c @@ -506,6 +506,50 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate) return fsl_asrc_set_ideal_ratio(pair, inrate, outrate); } +/** + * Select the output clock corresponding to a given input clock (and vice-versa) + * + * If we want to setup a capture channel, the input and output clocks have to + * be swapped. + * However, even if most of the clocks have the same index when used as input + * or output, some of them (ESAI, SSI* and SPDIF) are different: + * - the TX output clock has the index of the corresponding RX input clock + * - the RX output clock has the index of the corresponding TX input clock + * + * This function makes sure that we use the proper clock index when swapping + * the input and output clocks. + */ +static enum asrc_outclk fsl_asrc_get_capture_clock(enum asrc_inclk inclk) +{ + enum asrc_outclk outclk; + + switch (inclk) { + case INCLK_ESAI_RX: + case INCLK_SSI1_RX: + case INCLK_SSI2_RX: + case INCLK_SPDIF_RX: + outclk = inclk + 0x8; + break; + case INCLK_SSI3_RX: + outclk = OUTCLK_SSI3_RX; + break; + case INCLK_ESAI_TX: + case INCLK_SSI1_TX: + case INCLK_SSI2_TX: + case INCLK_SPDIF_TX: + outclk = inclk - 0x8; + break; + case INCLK_SSI3_TX: + outclk = OUTCLK_SSI3_TX; + break; + default: + outclk = inclk; + break; + } + + return outclk; +} + /** * Start the assigned ASRC pair * @@ -604,15 +648,17 @@ static int fsl_asrc_dai_hw_params(struct snd_pcm_substream *substream, config.pair = pair->index; config.channel_num = channels; - config.inclk = asrc->inclk; - config.outclk = asrc->outclk; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { + config.inclk = asrc->inclk; + config.outclk = asrc->outclk; config.input_format = params_format(params); config.output_format = asrc->asrc_format; config.input_sample_rate = rate; config.output_sample_rate = asrc->asrc_rate; } else { + config.inclk = fsl_asrc_get_capture_clock(asrc->outclk); + config.outclk = fsl_asrc_get_capture_clock(asrc->inclk); config.input_format = asrc->asrc_format; config.output_format = params_format(params); config.input_sample_rate = asrc->asrc_rate; -- 2.27.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [PATCH 4/4] ASoC: fsl_asrc: swap input and output clocks in capture mode 2020-07-02 14:22 ` Arnaud Ferraris (?) (?) @ 2020-07-02 19:34 ` kernel test robot -1 siblings, 0 replies; 55+ messages in thread From: kernel test robot @ 2020-07-02 19:34 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 3851 bytes --] Hi Arnaud, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on v5.8-rc3] [cannot apply to asoc/for-next next-20200702] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Arnaud-Ferraris/ASoC-fsl_asrc-allow-selecting-arbitrary-clocks/20200702-222640 base: 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68 config: i386-randconfig-s002-20200702 (attached as .config) compiler: gcc-9 (Debian 9.3.0-14) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-3-gfa153962-dirty # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp@intel.com> sparse warnings: (new ones prefixed by >>) >> sound/soc/fsl/fsl_asrc.c:546:26: sparse: sparse: mixing different enum types: >> sound/soc/fsl/fsl_asrc.c:546:26: sparse: unsigned int enum asrc_inclk >> sound/soc/fsl/fsl_asrc.c:546:26: sparse: unsigned int enum asrc_outclk sound/soc/fsl/fsl_asrc.c:660:63: sparse: sparse: mixing different enum types: sound/soc/fsl/fsl_asrc.c:660:63: sparse: unsigned int enum asrc_outclk sound/soc/fsl/fsl_asrc.c:660:63: sparse: unsigned int enum asrc_inclk sound/soc/fsl/fsl_asrc.c:660:58: sparse: sparse: mixing different enum types: sound/soc/fsl/fsl_asrc.c:660:58: sparse: unsigned int enum asrc_outclk sound/soc/fsl/fsl_asrc.c:660:58: sparse: unsigned int enum asrc_inclk sound/soc/fsl/fsl_asrc.c:1136:60: sparse: sparse: incorrect type in argument 3 (different base types) @@ expected unsigned int [usertype] *out_value @@ got restricted snd_pcm_format_t * @@ sound/soc/fsl/fsl_asrc.c:1136:60: sparse: expected unsigned int [usertype] *out_value sound/soc/fsl/fsl_asrc.c:1136:60: sparse: got restricted snd_pcm_format_t * sound/soc/fsl/fsl_asrc.c:1159:47: sparse: sparse: restricted snd_pcm_format_t degrades to integer vim +546 sound/soc/fsl/fsl_asrc.c 508 509 /** 510 * Select the output clock corresponding to a given input clock (and vice-versa) 511 * 512 * If we want to setup a capture channel, the input and output clocks have to 513 * be swapped. 514 * However, even if most of the clocks have the same index when used as input 515 * or output, some of them (ESAI, SSI* and SPDIF) are different: 516 * - the TX output clock has the index of the corresponding RX input clock 517 * - the RX output clock has the index of the corresponding TX input clock 518 * 519 * This function makes sure that we use the proper clock index when swapping 520 * the input and output clocks. 521 */ 522 static enum asrc_outclk fsl_asrc_get_capture_clock(enum asrc_inclk inclk) 523 { 524 enum asrc_outclk outclk; 525 526 switch (inclk) { 527 case INCLK_ESAI_RX: 528 case INCLK_SSI1_RX: 529 case INCLK_SSI2_RX: 530 case INCLK_SPDIF_RX: 531 outclk = inclk + 0x8; 532 break; 533 case INCLK_SSI3_RX: 534 outclk = OUTCLK_SSI3_RX; 535 break; 536 case INCLK_ESAI_TX: 537 case INCLK_SSI1_TX: 538 case INCLK_SSI2_TX: 539 case INCLK_SPDIF_TX: 540 outclk = inclk - 0x8; 541 break; 542 case INCLK_SSI3_TX: 543 outclk = OUTCLK_SSI3_TX; 544 break; 545 default: > 546 outclk = inclk; 547 break; 548 } 549 550 return outclk; 551 } 552 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org [-- Attachment #2: config.gz --] [-- Type: application/gzip, Size: 34696 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-02 14:22 ` Arnaud Ferraris (?) @ 2020-07-02 18:42 ` Nicolin Chen -1 siblings, 0 replies; 55+ messages in thread From: Nicolin Chen @ 2020-07-02 18:42 UTC (permalink / raw) To: Arnaud Ferraris Cc: kernel, Liam Girdwood, Mark Brown, Rob Herring, Timur Tabi, Xiubo Li, Fabio Estevam, Jaroslav Kysela, Takashi Iwai, alsa-devel, devicetree, linux-kernel, linuxppc-dev Hi Arnaud, On Thu, Jul 02, 2020 at 04:22:31PM +0200, Arnaud Ferraris wrote: > The current ASRC driver hardcodes the input and output clocks used for > sample rate conversions. In order to allow greater flexibility and to > cover more use cases, it would be preferable to select the clocks using > device-tree properties. We recent just merged a new change that auto-selecting internal clocks based on sample rates as the first option -- ideal ratio mode is the fallback mode now. Please refer to: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200702&id=d0250cf4f2abfbea64ed247230f08f5ae23979f0 Having a quick review at your changes, I think the DT part may not be necessary as it's more likely a software configuration. I personally like the new auto-selecting solution more. > This series also fix register configuration and clock assignment so > conversion can be conducted effectively in both directions with a good > quality. If there's any further change that you feel you can improve on the top of mentioned change after rebasing, I'd like to review. Thanks Nic ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-02 18:42 ` Nicolin Chen 0 siblings, 0 replies; 55+ messages in thread From: Nicolin Chen @ 2020-07-02 18:42 UTC (permalink / raw) To: Arnaud Ferraris Cc: devicetree, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Jaroslav Kysela, Mark Brown, kernel, Fabio Estevam Hi Arnaud, On Thu, Jul 02, 2020 at 04:22:31PM +0200, Arnaud Ferraris wrote: > The current ASRC driver hardcodes the input and output clocks used for > sample rate conversions. In order to allow greater flexibility and to > cover more use cases, it would be preferable to select the clocks using > device-tree properties. We recent just merged a new change that auto-selecting internal clocks based on sample rates as the first option -- ideal ratio mode is the fallback mode now. Please refer to: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200702&id=d0250cf4f2abfbea64ed247230f08f5ae23979f0 Having a quick review at your changes, I think the DT part may not be necessary as it's more likely a software configuration. I personally like the new auto-selecting solution more. > This series also fix register configuration and clock assignment so > conversion can be conducted effectively in both directions with a good > quality. If there's any further change that you feel you can improve on the top of mentioned change after rebasing, I'd like to review. Thanks Nic ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-02 18:42 ` Nicolin Chen 0 siblings, 0 replies; 55+ messages in thread From: Nicolin Chen @ 2020-07-02 18:42 UTC (permalink / raw) To: Arnaud Ferraris Cc: devicetree, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Mark Brown, kernel, Fabio Estevam Hi Arnaud, On Thu, Jul 02, 2020 at 04:22:31PM +0200, Arnaud Ferraris wrote: > The current ASRC driver hardcodes the input and output clocks used for > sample rate conversions. In order to allow greater flexibility and to > cover more use cases, it would be preferable to select the clocks using > device-tree properties. We recent just merged a new change that auto-selecting internal clocks based on sample rates as the first option -- ideal ratio mode is the fallback mode now. Please refer to: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200702&id=d0250cf4f2abfbea64ed247230f08f5ae23979f0 Having a quick review at your changes, I think the DT part may not be necessary as it's more likely a software configuration. I personally like the new auto-selecting solution more. > This series also fix register configuration and clock assignment so > conversion can be conducted effectively in both directions with a good > quality. If there's any further change that you feel you can improve on the top of mentioned change after rebasing, I'd like to review. Thanks Nic ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-02 18:42 ` Nicolin Chen @ 2020-07-03 9:38 ` Arnaud Ferraris -1 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-03 9:38 UTC (permalink / raw) To: Nicolin Chen Cc: devicetree, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Mark Brown, kernel, Fabio Estevam Hi Nic, Le 02/07/2020 à 20:42, Nicolin Chen a écrit : > Hi Arnaud, > > On Thu, Jul 02, 2020 at 04:22:31PM +0200, Arnaud Ferraris wrote: >> The current ASRC driver hardcodes the input and output clocks used for >> sample rate conversions. In order to allow greater flexibility and to >> cover more use cases, it would be preferable to select the clocks using >> device-tree properties. > > We recent just merged a new change that auto-selecting internal > clocks based on sample rates as the first option -- ideal ratio > mode is the fallback mode now. Please refer to: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200702&id=d0250cf4f2abfbea64ed247230f08f5ae23979f0 That looks interesting, thanks for pointing this out! I'll rebase and see how it works for my use-case, will keep you informed. Regards, Arnaud ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-03 9:38 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-03 9:38 UTC (permalink / raw) To: Nicolin Chen Cc: devicetree, alsa-devel, Timur Tabi, Xiubo Li, Liam Girdwood, Mark Brown, linux-kernel, Takashi Iwai, Rob Herring, Fabio Estevam, kernel, linuxppc-dev Hi Nic, Le 02/07/2020 à 20:42, Nicolin Chen a écrit : > Hi Arnaud, > > On Thu, Jul 02, 2020 at 04:22:31PM +0200, Arnaud Ferraris wrote: >> The current ASRC driver hardcodes the input and output clocks used for >> sample rate conversions. In order to allow greater flexibility and to >> cover more use cases, it would be preferable to select the clocks using >> device-tree properties. > > We recent just merged a new change that auto-selecting internal > clocks based on sample rates as the first option -- ideal ratio > mode is the fallback mode now. Please refer to: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200702&id=d0250cf4f2abfbea64ed247230f08f5ae23979f0 That looks interesting, thanks for pointing this out! I'll rebase and see how it works for my use-case, will keep you informed. Regards, Arnaud ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-03 9:38 ` Arnaud Ferraris @ 2020-07-14 16:20 ` Arnaud Ferraris -1 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-14 16:20 UTC (permalink / raw) To: Nicolin Chen Cc: alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Mark Brown, kernel, Fabio Estevam Hi Nic, Le 03/07/2020 à 11:38, Arnaud Ferraris a écrit : > Hi Nic, > > Le 02/07/2020 à 20:42, Nicolin Chen a écrit : >> Hi Arnaud, >> >> On Thu, Jul 02, 2020 at 04:22:31PM +0200, Arnaud Ferraris wrote: >>> The current ASRC driver hardcodes the input and output clocks used for >>> sample rate conversions. In order to allow greater flexibility and to >>> cover more use cases, it would be preferable to select the clocks using >>> device-tree properties. >> >> We recent just merged a new change that auto-selecting internal >> clocks based on sample rates as the first option -- ideal ratio >> mode is the fallback mode now. Please refer to: >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200702&id=d0250cf4f2abfbea64ed247230f08f5ae23979f0 > > That looks interesting, thanks for pointing this out! > I'll rebase and see how it works for my use-case, will keep you informed. > > Regards, > Arnaud > I finally got some time to test and debug clock auto-selection on my system, and unfortunately couldn't get it to work. Here's some background about my use case: the i.MX6 board acts as a Bluetooth proxy between a phone and a headset. It has 2 Bluetooth modules (one for each connected device), with audio connected to SSI1 & SSI2. Audio sample rate can be either 8 or 16kHz, and bclk can be either 512 or 1024kHz, all depending of the capabilities of the headset and phone. In our case we want SSI2 to be the input clock to the ASRC and SSI1 the output clock, but there is no way to force that with auto-selection: both clocks are multiples of both 8k and 16k, so the algorithm will always select the SSI1 clock. I don't think auto-selection can be made smart enough to cover this case, which is why I believe we still need a way to manually setup the input and output clocks to be used by ASRC, falling back to auto-selecting the clocks if not setup manually. If not using DT bindings, what do you think would be the best way to implement that? Regards, Arnaud ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-14 16:20 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-14 16:20 UTC (permalink / raw) To: Nicolin Chen Cc: alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Mark Brown, Liam Girdwood, Takashi Iwai, Rob Herring, kernel, Fabio Estevam Hi Nic, Le 03/07/2020 à 11:38, Arnaud Ferraris a écrit : > Hi Nic, > > Le 02/07/2020 à 20:42, Nicolin Chen a écrit : >> Hi Arnaud, >> >> On Thu, Jul 02, 2020 at 04:22:31PM +0200, Arnaud Ferraris wrote: >>> The current ASRC driver hardcodes the input and output clocks used for >>> sample rate conversions. In order to allow greater flexibility and to >>> cover more use cases, it would be preferable to select the clocks using >>> device-tree properties. >> >> We recent just merged a new change that auto-selecting internal >> clocks based on sample rates as the first option -- ideal ratio >> mode is the fallback mode now. Please refer to: >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200702&id=d0250cf4f2abfbea64ed247230f08f5ae23979f0 > > That looks interesting, thanks for pointing this out! > I'll rebase and see how it works for my use-case, will keep you informed. > > Regards, > Arnaud > I finally got some time to test and debug clock auto-selection on my system, and unfortunately couldn't get it to work. Here's some background about my use case: the i.MX6 board acts as a Bluetooth proxy between a phone and a headset. It has 2 Bluetooth modules (one for each connected device), with audio connected to SSI1 & SSI2. Audio sample rate can be either 8 or 16kHz, and bclk can be either 512 or 1024kHz, all depending of the capabilities of the headset and phone. In our case we want SSI2 to be the input clock to the ASRC and SSI1 the output clock, but there is no way to force that with auto-selection: both clocks are multiples of both 8k and 16k, so the algorithm will always select the SSI1 clock. I don't think auto-selection can be made smart enough to cover this case, which is why I believe we still need a way to manually setup the input and output clocks to be used by ASRC, falling back to auto-selecting the clocks if not setup manually. If not using DT bindings, what do you think would be the best way to implement that? Regards, Arnaud ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-14 16:20 ` Arnaud Ferraris @ 2020-07-14 20:15 ` Nicolin Chen -1 siblings, 0 replies; 55+ messages in thread From: Nicolin Chen @ 2020-07-14 20:15 UTC (permalink / raw) To: Arnaud Ferraris Cc: alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Mark Brown, kernel, Fabio Estevam On Tue, Jul 14, 2020 at 06:20:32PM +0200, Arnaud Ferraris wrote: > >>> The current ASRC driver hardcodes the input and output clocks used for > >>> sample rate conversions. In order to allow greater flexibility and to > >>> cover more use cases, it would be preferable to select the clocks using > >>> device-tree properties. > >> > >> We recent just merged a new change that auto-selecting internal > >> clocks based on sample rates as the first option -- ideal ratio > >> mode is the fallback mode now. Please refer to: > >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200702&id=d0250cf4f2abfbea64ed247230f08f5ae23979f0 > I finally got some time to test and debug clock auto-selection on my > system, and unfortunately couldn't get it to work. > > Here's some background about my use case: the i.MX6 board acts as a > Bluetooth proxy between a phone and a headset. It has 2 Bluetooth > modules (one for each connected device), with audio connected to SSI1 & > SSI2. Audio sample rate can be either 8 or 16kHz, and bclk can be either > 512 or 1024kHz, all depending of the capabilities of the headset and phone. > In our case we want SSI2 to be the input clock to the ASRC and SSI1 the > output clock, but there is no way to force that with auto-selection: > both clocks are multiples of both 8k and 16k, so the algorithm will > always select the SSI1 clock. Anything wrong with ASRC selecting SSI1 clock for both cases? The driver calculates the divisors based on the given clock rate, so the final internal rate should be the same. If there's a problem, I feel that's a separate bug. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-14 20:15 ` Nicolin Chen 0 siblings, 0 replies; 55+ messages in thread From: Nicolin Chen @ 2020-07-14 20:15 UTC (permalink / raw) To: Arnaud Ferraris Cc: alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Mark Brown, Liam Girdwood, Takashi Iwai, Rob Herring, kernel, Fabio Estevam On Tue, Jul 14, 2020 at 06:20:32PM +0200, Arnaud Ferraris wrote: > >>> The current ASRC driver hardcodes the input and output clocks used for > >>> sample rate conversions. In order to allow greater flexibility and to > >>> cover more use cases, it would be preferable to select the clocks using > >>> device-tree properties. > >> > >> We recent just merged a new change that auto-selecting internal > >> clocks based on sample rates as the first option -- ideal ratio > >> mode is the fallback mode now. Please refer to: > >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200702&id=d0250cf4f2abfbea64ed247230f08f5ae23979f0 > I finally got some time to test and debug clock auto-selection on my > system, and unfortunately couldn't get it to work. > > Here's some background about my use case: the i.MX6 board acts as a > Bluetooth proxy between a phone and a headset. It has 2 Bluetooth > modules (one for each connected device), with audio connected to SSI1 & > SSI2. Audio sample rate can be either 8 or 16kHz, and bclk can be either > 512 or 1024kHz, all depending of the capabilities of the headset and phone. > In our case we want SSI2 to be the input clock to the ASRC and SSI1 the > output clock, but there is no way to force that with auto-selection: > both clocks are multiples of both 8k and 16k, so the algorithm will > always select the SSI1 clock. Anything wrong with ASRC selecting SSI1 clock for both cases? The driver calculates the divisors based on the given clock rate, so the final internal rate should be the same. If there's a problem, I feel that's a separate bug. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-14 20:15 ` Nicolin Chen @ 2020-07-14 20:27 ` Mark Brown -1 siblings, 0 replies; 55+ messages in thread From: Mark Brown @ 2020-07-14 20:27 UTC (permalink / raw) To: Nicolin Chen Cc: Arnaud Ferraris, alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, kernel, Fabio Estevam [-- Attachment #1: Type: text/plain, Size: 1398 bytes --] On Tue, Jul 14, 2020 at 01:15:45PM -0700, Nicolin Chen wrote: > On Tue, Jul 14, 2020 at 06:20:32PM +0200, Arnaud Ferraris wrote: > > Here's some background about my use case: the i.MX6 board acts as a > > Bluetooth proxy between a phone and a headset. It has 2 Bluetooth > > modules (one for each connected device), with audio connected to SSI1 & > > SSI2. Audio sample rate can be either 8 or 16kHz, and bclk can be either > > 512 or 1024kHz, all depending of the capabilities of the headset and phone. > > In our case we want SSI2 to be the input clock to the ASRC and SSI1 the > > output clock, but there is no way to force that with auto-selection: > > both clocks are multiples of both 8k and 16k, so the algorithm will > > always select the SSI1 clock. > Anything wrong with ASRC selecting SSI1 clock for both cases? The > driver calculates the divisors based on the given clock rate, so > the final internal rate should be the same. If there's a problem, > I feel that's a separate bug. The nominal rate might be the same but if they're in different clock domains then the actual rates might be different (hence the desire for an ASRC I guess). I can see the system wanting to choose one clock or the other on the basis of some system specific property (quality of the clock sources, tolerances of the devices involved or something) though it's a rather fun edge case configuration :/ . [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-14 20:27 ` Mark Brown 0 siblings, 0 replies; 55+ messages in thread From: Mark Brown @ 2020-07-14 20:27 UTC (permalink / raw) To: Nicolin Chen Cc: Arnaud Ferraris, Timur Tabi, alsa-devel, Xiubo Li, Liam Girdwood, linux-kernel, Takashi Iwai, Rob Herring, kernel, Fabio Estevam [-- Attachment #1: Type: text/plain, Size: 1398 bytes --] On Tue, Jul 14, 2020 at 01:15:45PM -0700, Nicolin Chen wrote: > On Tue, Jul 14, 2020 at 06:20:32PM +0200, Arnaud Ferraris wrote: > > Here's some background about my use case: the i.MX6 board acts as a > > Bluetooth proxy between a phone and a headset. It has 2 Bluetooth > > modules (one for each connected device), with audio connected to SSI1 & > > SSI2. Audio sample rate can be either 8 or 16kHz, and bclk can be either > > 512 or 1024kHz, all depending of the capabilities of the headset and phone. > > In our case we want SSI2 to be the input clock to the ASRC and SSI1 the > > output clock, but there is no way to force that with auto-selection: > > both clocks are multiples of both 8k and 16k, so the algorithm will > > always select the SSI1 clock. > Anything wrong with ASRC selecting SSI1 clock for both cases? The > driver calculates the divisors based on the given clock rate, so > the final internal rate should be the same. If there's a problem, > I feel that's a separate bug. The nominal rate might be the same but if they're in different clock domains then the actual rates might be different (hence the desire for an ASRC I guess). I can see the system wanting to choose one clock or the other on the basis of some system specific property (quality of the clock sources, tolerances of the devices involved or something) though it's a rather fun edge case configuration :/ . [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-14 20:27 ` Mark Brown @ 2020-07-14 20:50 ` Nicolin Chen -1 siblings, 0 replies; 55+ messages in thread From: Nicolin Chen @ 2020-07-14 20:50 UTC (permalink / raw) To: Mark Brown Cc: Arnaud Ferraris, alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, kernel, Fabio Estevam Hi Mark, On Tue, Jul 14, 2020 at 09:27:53PM +0100, Mark Brown wrote: > On Tue, Jul 14, 2020 at 01:15:45PM -0700, Nicolin Chen wrote: > > On Tue, Jul 14, 2020 at 06:20:32PM +0200, Arnaud Ferraris wrote: > > > > Here's some background about my use case: the i.MX6 board acts as a > > > Bluetooth proxy between a phone and a headset. It has 2 Bluetooth > > > modules (one for each connected device), with audio connected to SSI1 & > > > SSI2. Audio sample rate can be either 8 or 16kHz, and bclk can be either > > > 512 or 1024kHz, all depending of the capabilities of the headset and phone. > > > In our case we want SSI2 to be the input clock to the ASRC and SSI1 the > > > output clock, but there is no way to force that with auto-selection: > > > both clocks are multiples of both 8k and 16k, so the algorithm will > > > always select the SSI1 clock. > > > Anything wrong with ASRC selecting SSI1 clock for both cases? The > > driver calculates the divisors based on the given clock rate, so > > the final internal rate should be the same. If there's a problem, > > I feel that's a separate bug. > > The nominal rate might be the same but if they're in different clock > domains then the actual rates might be different (hence the desire for > an ASRC I guess). I can see the system wanting to choose one clock or > the other on the basis of some system specific property (quality of the > clock sources, tolerances of the devices involved or something) though > it's a rather fun edge case configuration :/ . Thanks for the input. Fox i.MX6, I don't feel it would be that drastically different though. And both SSI1 and SSI2 can simply select the same root clock source to avoid that happen. Yet, in case that we need to support such an edge case, what's a relatively common practice to allow system select the clock source now? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-14 20:50 ` Nicolin Chen 0 siblings, 0 replies; 55+ messages in thread From: Nicolin Chen @ 2020-07-14 20:50 UTC (permalink / raw) To: Mark Brown Cc: Arnaud Ferraris, Timur Tabi, alsa-devel, Xiubo Li, Liam Girdwood, linux-kernel, Takashi Iwai, Rob Herring, kernel, Fabio Estevam Hi Mark, On Tue, Jul 14, 2020 at 09:27:53PM +0100, Mark Brown wrote: > On Tue, Jul 14, 2020 at 01:15:45PM -0700, Nicolin Chen wrote: > > On Tue, Jul 14, 2020 at 06:20:32PM +0200, Arnaud Ferraris wrote: > > > > Here's some background about my use case: the i.MX6 board acts as a > > > Bluetooth proxy between a phone and a headset. It has 2 Bluetooth > > > modules (one for each connected device), with audio connected to SSI1 & > > > SSI2. Audio sample rate can be either 8 or 16kHz, and bclk can be either > > > 512 or 1024kHz, all depending of the capabilities of the headset and phone. > > > In our case we want SSI2 to be the input clock to the ASRC and SSI1 the > > > output clock, but there is no way to force that with auto-selection: > > > both clocks are multiples of both 8k and 16k, so the algorithm will > > > always select the SSI1 clock. > > > Anything wrong with ASRC selecting SSI1 clock for both cases? The > > driver calculates the divisors based on the given clock rate, so > > the final internal rate should be the same. If there's a problem, > > I feel that's a separate bug. > > The nominal rate might be the same but if they're in different clock > domains then the actual rates might be different (hence the desire for > an ASRC I guess). I can see the system wanting to choose one clock or > the other on the basis of some system specific property (quality of the > clock sources, tolerances of the devices involved or something) though > it's a rather fun edge case configuration :/ . Thanks for the input. Fox i.MX6, I don't feel it would be that drastically different though. And both SSI1 and SSI2 can simply select the same root clock source to avoid that happen. Yet, in case that we need to support such an edge case, what's a relatively common practice to allow system select the clock source now? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-14 20:50 ` Nicolin Chen @ 2020-07-15 14:05 ` Mark Brown -1 siblings, 0 replies; 55+ messages in thread From: Mark Brown @ 2020-07-15 14:05 UTC (permalink / raw) To: Nicolin Chen Cc: Arnaud Ferraris, alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, kernel, Fabio Estevam [-- Attachment #1: Type: text/plain, Size: 1111 bytes --] On Tue, Jul 14, 2020 at 01:50:50PM -0700, Nicolin Chen wrote: > On Tue, Jul 14, 2020 at 09:27:53PM +0100, Mark Brown wrote: > > The nominal rate might be the same but if they're in different clock > > domains then the actual rates might be different (hence the desire for > > an ASRC I guess). I can see the system wanting to choose one clock or > > the other on the basis of some system specific property (quality of the > > clock sources, tolerances of the devices involved or something) though > > it's a rather fun edge case configuration :/ . > Thanks for the input. Fox i.MX6, I don't feel it would be that > drastically different though. And both SSI1 and SSI2 can simply > select the same root clock source to avoid that happen. If you've got two radios that both need to sync to some radio derived frequency it gets a bit more entertaining. > Yet, in case that we need to support such an edge case, what's > a relatively common practice to allow system select the clock > source now? Honestly for anything that fun it tends to be a custom machine driver. A property would seem reasonable though. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-15 14:05 ` Mark Brown 0 siblings, 0 replies; 55+ messages in thread From: Mark Brown @ 2020-07-15 14:05 UTC (permalink / raw) To: Nicolin Chen Cc: Arnaud Ferraris, Timur Tabi, alsa-devel, Xiubo Li, Liam Girdwood, linux-kernel, Takashi Iwai, Rob Herring, kernel, Fabio Estevam [-- Attachment #1: Type: text/plain, Size: 1111 bytes --] On Tue, Jul 14, 2020 at 01:50:50PM -0700, Nicolin Chen wrote: > On Tue, Jul 14, 2020 at 09:27:53PM +0100, Mark Brown wrote: > > The nominal rate might be the same but if they're in different clock > > domains then the actual rates might be different (hence the desire for > > an ASRC I guess). I can see the system wanting to choose one clock or > > the other on the basis of some system specific property (quality of the > > clock sources, tolerances of the devices involved or something) though > > it's a rather fun edge case configuration :/ . > Thanks for the input. Fox i.MX6, I don't feel it would be that > drastically different though. And both SSI1 and SSI2 can simply > select the same root clock source to avoid that happen. If you've got two radios that both need to sync to some radio derived frequency it gets a bit more entertaining. > Yet, in case that we need to support such an edge case, what's > a relatively common practice to allow system select the clock > source now? Honestly for anything that fun it tends to be a custom machine driver. A property would seem reasonable though. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-15 14:05 ` Mark Brown @ 2020-07-15 16:18 ` Arnaud Ferraris -1 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-15 16:18 UTC (permalink / raw) To: Mark Brown, Nicolin Chen Cc: alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, kernel, Fabio Estevam Hi, Le 15/07/2020 à 16:05, Mark Brown a écrit : > On Tue, Jul 14, 2020 at 01:50:50PM -0700, Nicolin Chen wrote: > Anything wrong with ASRC selecting SSI1 clock for both cases? The > driver calculates the divisors based on the given clock rate, so > the final internal rate should be the same. If there's a problem, > I feel that's a separate bug. Calculations are indeed good, but then the clock selection setting in the ASRCSR register would also use SSI1 as the input clock, which doesn't work in our case. >> On Tue, Jul 14, 2020 at 09:27:53PM +0100, Mark Brown wrote: > > If you've got two radios that both need to sync to some radio derived > frequency it gets a bit more entertaining. It was indeed a fun ride trying to make it work for all the use-cases we were targetting. > >> Yet, in case that we need to support such an edge case, what's >> a relatively common practice to allow system select the clock >> source now? > > Honestly for anything that fun it tends to be a custom machine driver. > A property would seem reasonable though. I think so, does my initial implementation of the properties look sensible to you? ("fsl,asrc-input-clock" & "fsl,asrc-output-clock") Regards, Arnaud ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-15 16:18 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-15 16:18 UTC (permalink / raw) To: Mark Brown, Nicolin Chen Cc: alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Liam Girdwood, Takashi Iwai, Rob Herring, kernel, Fabio Estevam Hi, Le 15/07/2020 à 16:05, Mark Brown a écrit : > On Tue, Jul 14, 2020 at 01:50:50PM -0700, Nicolin Chen wrote: > Anything wrong with ASRC selecting SSI1 clock for both cases? The > driver calculates the divisors based on the given clock rate, so > the final internal rate should be the same. If there's a problem, > I feel that's a separate bug. Calculations are indeed good, but then the clock selection setting in the ASRCSR register would also use SSI1 as the input clock, which doesn't work in our case. >> On Tue, Jul 14, 2020 at 09:27:53PM +0100, Mark Brown wrote: > > If you've got two radios that both need to sync to some radio derived > frequency it gets a bit more entertaining. It was indeed a fun ride trying to make it work for all the use-cases we were targetting. > >> Yet, in case that we need to support such an edge case, what's >> a relatively common practice to allow system select the clock >> source now? > > Honestly for anything that fun it tends to be a custom machine driver. > A property would seem reasonable though. I think so, does my initial implementation of the properties look sensible to you? ("fsl,asrc-input-clock" & "fsl,asrc-output-clock") Regards, Arnaud ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-15 16:18 ` Arnaud Ferraris @ 2020-07-15 16:22 ` Mark Brown -1 siblings, 0 replies; 55+ messages in thread From: Mark Brown @ 2020-07-15 16:22 UTC (permalink / raw) To: Arnaud Ferraris Cc: Nicolin Chen, alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, kernel, Fabio Estevam [-- Attachment #1: Type: text/plain, Size: 481 bytes --] On Wed, Jul 15, 2020 at 06:18:38PM +0200, Arnaud Ferraris wrote: > Le 15/07/2020 à 16:05, Mark Brown a écrit : > > Honestly for anything that fun it tends to be a custom machine driver. > > A property would seem reasonable though. > I think so, does my initial implementation of the properties look > sensible to you? ("fsl,asrc-input-clock" & "fsl,asrc-output-clock") Those look reasonable enough off the top of my head, not that I've really looked at the hardware. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-15 16:22 ` Mark Brown 0 siblings, 0 replies; 55+ messages in thread From: Mark Brown @ 2020-07-15 16:22 UTC (permalink / raw) To: Arnaud Ferraris Cc: alsa-devel, Timur Tabi, Xiubo Li, Liam Girdwood, Takashi Iwai, linux-kernel, Nicolin Chen, Rob Herring, kernel, Fabio Estevam [-- Attachment #1: Type: text/plain, Size: 481 bytes --] On Wed, Jul 15, 2020 at 06:18:38PM +0200, Arnaud Ferraris wrote: > Le 15/07/2020 à 16:05, Mark Brown a écrit : > > Honestly for anything that fun it tends to be a custom machine driver. > > A property would seem reasonable though. > I think so, does my initial implementation of the properties look > sensible to you? ("fsl,asrc-input-clock" & "fsl,asrc-output-clock") Those look reasonable enough off the top of my head, not that I've really looked at the hardware. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-15 16:22 ` Mark Brown @ 2020-07-15 16:32 ` Arnaud Ferraris -1 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-15 16:32 UTC (permalink / raw) To: Mark Brown Cc: Nicolin Chen, alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, kernel, Fabio Estevam Le 15/07/2020 à 18:22, Mark Brown a écrit : > > Those look reasonable enough off the top of my head, not that I've > really looked at the hardware. > Alright, thanks for your feedback! Unless Nic has other comments I'll submit a v2 tomorrow then. Regards, Arnaud ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-15 16:32 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-15 16:32 UTC (permalink / raw) To: Mark Brown Cc: alsa-devel, Timur Tabi, Xiubo Li, Liam Girdwood, Takashi Iwai, linux-kernel, Nicolin Chen, Rob Herring, kernel, Fabio Estevam Le 15/07/2020 à 18:22, Mark Brown a écrit : > > Those look reasonable enough off the top of my head, not that I've > really looked at the hardware. > Alright, thanks for your feedback! Unless Nic has other comments I'll submit a v2 tomorrow then. Regards, Arnaud ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-15 16:18 ` Arnaud Ferraris @ 2020-07-15 20:46 ` Nicolin Chen -1 siblings, 0 replies; 55+ messages in thread From: Nicolin Chen @ 2020-07-15 20:46 UTC (permalink / raw) To: Arnaud Ferraris Cc: Mark Brown, alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, kernel, Fabio Estevam On Wed, Jul 15, 2020 at 06:18:38PM +0200, Arnaud Ferraris wrote: > Hi, > > Le 15/07/2020 à 16:05, Mark Brown a écrit : > > On Tue, Jul 14, 2020 at 01:50:50PM -0700, Nicolin Chen wrote: > > Anything wrong with ASRC selecting SSI1 clock for both cases? The > > driver calculates the divisors based on the given clock rate, so > > the final internal rate should be the same. If there's a problem, > > I feel that's a separate bug. > > Calculations are indeed good, but then the clock selection setting in > the ASRCSR register would also use SSI1 as the input clock, which > doesn't work in our case. Could you please elaborate why it doesn't work? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-15 20:46 ` Nicolin Chen 0 siblings, 0 replies; 55+ messages in thread From: Nicolin Chen @ 2020-07-15 20:46 UTC (permalink / raw) To: Arnaud Ferraris Cc: alsa-devel, Timur Tabi, Xiubo Li, Liam Girdwood, Takashi Iwai, Rob Herring, linux-kernel, Mark Brown, kernel, Fabio Estevam On Wed, Jul 15, 2020 at 06:18:38PM +0200, Arnaud Ferraris wrote: > Hi, > > Le 15/07/2020 à 16:05, Mark Brown a écrit : > > On Tue, Jul 14, 2020 at 01:50:50PM -0700, Nicolin Chen wrote: > > Anything wrong with ASRC selecting SSI1 clock for both cases? The > > driver calculates the divisors based on the given clock rate, so > > the final internal rate should be the same. If there's a problem, > > I feel that's a separate bug. > > Calculations are indeed good, but then the clock selection setting in > the ASRCSR register would also use SSI1 as the input clock, which > doesn't work in our case. Could you please elaborate why it doesn't work? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-15 20:46 ` Nicolin Chen @ 2020-07-16 9:54 ` Arnaud Ferraris -1 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-16 9:54 UTC (permalink / raw) To: Nicolin Chen Cc: alsa-devel, Timur Tabi, Xiubo Li, Liam Girdwood, Takashi Iwai, Rob Herring, linux-kernel, Mark Brown, kernel, Fabio Estevam Le 15/07/2020 à 22:46, Nicolin Chen a écrit : >> Calculations are indeed good, but then the clock selection setting in >> the ASRCSR register would also use SSI1 as the input clock, which >> doesn't work in our case. > > Could you please elaborate why it doesn't work? > Hmm, actually it was a userspace issue, kernel-wise it could work fine with SSI1 as input clock, so please ignore this latest comment. Regards, Arnaud ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-16 9:54 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-16 9:54 UTC (permalink / raw) To: Nicolin Chen Cc: alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Mark Brown, Takashi Iwai, Liam Girdwood, Rob Herring, kernel, Fabio Estevam Le 15/07/2020 à 22:46, Nicolin Chen a écrit : >> Calculations are indeed good, but then the clock selection setting in >> the ASRCSR register would also use SSI1 as the input clock, which >> doesn't work in our case. > > Could you please elaborate why it doesn't work? > Hmm, actually it was a userspace issue, kernel-wise it could work fine with SSI1 as input clock, so please ignore this latest comment. Regards, Arnaud ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-15 14:05 ` Mark Brown @ 2020-07-15 21:03 ` Nicolin Chen -1 siblings, 0 replies; 55+ messages in thread From: Nicolin Chen @ 2020-07-15 21:03 UTC (permalink / raw) To: Mark Brown Cc: Arnaud Ferraris, alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, kernel, Fabio Estevam On Wed, Jul 15, 2020 at 03:05:19PM +0100, Mark Brown wrote: > On Tue, Jul 14, 2020 at 01:50:50PM -0700, Nicolin Chen wrote: > > On Tue, Jul 14, 2020 at 09:27:53PM +0100, Mark Brown wrote: > > > > The nominal rate might be the same but if they're in different clock > > > domains then the actual rates might be different (hence the desire for > > > an ASRC I guess). I can see the system wanting to choose one clock or > > > the other on the basis of some system specific property (quality of the > > > clock sources, tolerances of the devices involved or something) though > > > it's a rather fun edge case configuration :/ . > > > Thanks for the input. Fox i.MX6, I don't feel it would be that > > drastically different though. And both SSI1 and SSI2 can simply > > select the same root clock source to avoid that happen. > > If you've got two radios that both need to sync to some radio derived > frequency it gets a bit more entertaining. I'm simply curious what could be a problem. Do you mind educating me a bit? And ASRC here isn't a radio but a sample rate converter working as a BE in DPCM setup, using radio-capture for example... ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-15 21:03 ` Nicolin Chen 0 siblings, 0 replies; 55+ messages in thread From: Nicolin Chen @ 2020-07-15 21:03 UTC (permalink / raw) To: Mark Brown Cc: Arnaud Ferraris, Timur Tabi, alsa-devel, Xiubo Li, Liam Girdwood, linux-kernel, Takashi Iwai, Rob Herring, kernel, Fabio Estevam On Wed, Jul 15, 2020 at 03:05:19PM +0100, Mark Brown wrote: > On Tue, Jul 14, 2020 at 01:50:50PM -0700, Nicolin Chen wrote: > > On Tue, Jul 14, 2020 at 09:27:53PM +0100, Mark Brown wrote: > > > > The nominal rate might be the same but if they're in different clock > > > domains then the actual rates might be different (hence the desire for > > > an ASRC I guess). I can see the system wanting to choose one clock or > > > the other on the basis of some system specific property (quality of the > > > clock sources, tolerances of the devices involved or something) though > > > it's a rather fun edge case configuration :/ . > > > Thanks for the input. Fox i.MX6, I don't feel it would be that > > drastically different though. And both SSI1 and SSI2 can simply > > select the same root clock source to avoid that happen. > > If you've got two radios that both need to sync to some radio derived > frequency it gets a bit more entertaining. I'm simply curious what could be a problem. Do you mind educating me a bit? And ASRC here isn't a radio but a sample rate converter working as a BE in DPCM setup, using radio-capture for example... ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-15 21:03 ` Nicolin Chen @ 2020-07-16 12:18 ` Mark Brown -1 siblings, 0 replies; 55+ messages in thread From: Mark Brown @ 2020-07-16 12:18 UTC (permalink / raw) To: Nicolin Chen Cc: Arnaud Ferraris, alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, kernel, Fabio Estevam [-- Attachment #1: Type: text/plain, Size: 984 bytes --] On Wed, Jul 15, 2020 at 02:03:08PM -0700, Nicolin Chen wrote: > On Wed, Jul 15, 2020 at 03:05:19PM +0100, Mark Brown wrote: > > On Tue, Jul 14, 2020 at 01:50:50PM -0700, Nicolin Chen wrote: > > > Thanks for the input. Fox i.MX6, I don't feel it would be that > > > drastically different though. And both SSI1 and SSI2 can simply > > > select the same root clock source to avoid that happen. > > If you've got two radios that both need to sync to some radio derived > > frequency it gets a bit more entertaining. > I'm simply curious what could be a problem. Do you mind educating > me a bit? And ASRC here isn't a radio but a sample rate converter > working as a BE in DPCM setup, using radio-capture for example... My understanding was that this application was using the ASRC to convert between the sample rates of two different radios - the rates may be nominaly the same but in practice different so the audio will glitch after a while when the clocks drift far enough apart. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-16 12:18 ` Mark Brown 0 siblings, 0 replies; 55+ messages in thread From: Mark Brown @ 2020-07-16 12:18 UTC (permalink / raw) To: Nicolin Chen Cc: Arnaud Ferraris, Timur Tabi, alsa-devel, Xiubo Li, Liam Girdwood, linux-kernel, Takashi Iwai, Rob Herring, kernel, Fabio Estevam [-- Attachment #1: Type: text/plain, Size: 984 bytes --] On Wed, Jul 15, 2020 at 02:03:08PM -0700, Nicolin Chen wrote: > On Wed, Jul 15, 2020 at 03:05:19PM +0100, Mark Brown wrote: > > On Tue, Jul 14, 2020 at 01:50:50PM -0700, Nicolin Chen wrote: > > > Thanks for the input. Fox i.MX6, I don't feel it would be that > > > drastically different though. And both SSI1 and SSI2 can simply > > > select the same root clock source to avoid that happen. > > If you've got two radios that both need to sync to some radio derived > > frequency it gets a bit more entertaining. > I'm simply curious what could be a problem. Do you mind educating > me a bit? And ASRC here isn't a radio but a sample rate converter > working as a BE in DPCM setup, using radio-capture for example... My understanding was that this application was using the ASRC to convert between the sample rates of two different radios - the rates may be nominaly the same but in practice different so the audio will glitch after a while when the clocks drift far enough apart. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-16 12:18 ` Mark Brown @ 2020-07-16 14:26 ` Arnaud Ferraris -1 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-16 14:26 UTC (permalink / raw) To: Mark Brown, Nicolin Chen Cc: alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, kernel, Fabio Estevam Le 16/07/2020 à 14:18, Mark Brown a écrit : > On Wed, Jul 15, 2020 at 02:03:08PM -0700, Nicolin Chen wrote: >> On Wed, Jul 15, 2020 at 03:05:19PM +0100, Mark Brown wrote: >>> On Tue, Jul 14, 2020 at 01:50:50PM -0700, Nicolin Chen wrote: > >>>> Thanks for the input. Fox i.MX6, I don't feel it would be that >>>> drastically different though. And both SSI1 and SSI2 can simply >>>> select the same root clock source to avoid that happen. > >>> If you've got two radios that both need to sync to some radio derived >>> frequency it gets a bit more entertaining. > >> I'm simply curious what could be a problem. Do you mind educating >> me a bit? And ASRC here isn't a radio but a sample rate converter >> working as a BE in DPCM setup, using radio-capture for example... > > My understanding was that this application was using the ASRC to convert > between the sample rates of two different radios - the rates may be > nominaly the same but in practice different so the audio will glitch > after a while when the clocks drift far enough apart. That's part of the issues we had to solve, yes. The other part is more traditional sample rate conversion on an as-needed basis, as we can't assume which rate will be used (iPhone's use 16kHz, Android phones stick to 8kHz, and headsets can use both depending on their capabilities). ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-16 14:26 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-16 14:26 UTC (permalink / raw) To: Mark Brown, Nicolin Chen Cc: alsa-devel, Timur Tabi, Xiubo Li, linux-kernel, Liam Girdwood, Takashi Iwai, Rob Herring, kernel, Fabio Estevam Le 16/07/2020 à 14:18, Mark Brown a écrit : > On Wed, Jul 15, 2020 at 02:03:08PM -0700, Nicolin Chen wrote: >> On Wed, Jul 15, 2020 at 03:05:19PM +0100, Mark Brown wrote: >>> On Tue, Jul 14, 2020 at 01:50:50PM -0700, Nicolin Chen wrote: > >>>> Thanks for the input. Fox i.MX6, I don't feel it would be that >>>> drastically different though. And both SSI1 and SSI2 can simply >>>> select the same root clock source to avoid that happen. > >>> If you've got two radios that both need to sync to some radio derived >>> frequency it gets a bit more entertaining. > >> I'm simply curious what could be a problem. Do you mind educating >> me a bit? And ASRC here isn't a radio but a sample rate converter >> working as a BE in DPCM setup, using radio-capture for example... > > My understanding was that this application was using the ASRC to convert > between the sample rates of two different radios - the rates may be > nominaly the same but in practice different so the audio will glitch > after a while when the clocks drift far enough apart. That's part of the issues we had to solve, yes. The other part is more traditional sample rate conversion on an as-needed basis, as we can't assume which rate will be used (iPhone's use 16kHz, Android phones stick to 8kHz, and headsets can use both depending on their capabilities). ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-02 18:42 ` Nicolin Chen (?) @ 2020-07-17 11:16 ` Arnaud Ferraris -1 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-17 11:16 UTC (permalink / raw) To: Nicolin Chen Cc: kernel, Liam Girdwood, Mark Brown, Rob Herring, Timur Tabi, Xiubo Li, Fabio Estevam, Jaroslav Kysela, Takashi Iwai, alsa-devel, devicetree, linux-kernel, linuxppc-dev Hi Nic, Le 02/07/2020 à 20:42, Nicolin Chen a écrit : > Hi Arnaud, > > On Thu, Jul 02, 2020 at 04:22:31PM +0200, Arnaud Ferraris wrote: >> The current ASRC driver hardcodes the input and output clocks used for >> sample rate conversions. In order to allow greater flexibility and to >> cover more use cases, it would be preferable to select the clocks using >> device-tree properties. > > We recent just merged a new change that auto-selecting internal > clocks based on sample rates as the first option -- ideal ratio > mode is the fallback mode now. Please refer to: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200702&id=d0250cf4f2abfbea64ed247230f08f5ae23979f0 While working on fixing the automatic clock selection (see my v3), I came across another potential issue, which would be better explained with an example: - Input has sample rate 8kHz and uses clock SSI1 with rate 512kHz - Output has sample rate 16kHz and uses clock SSI2 with rate 1024kHz Let's say my v3 patch is merged, then the selected input clock will be SSI1, while the selected output clock will be SSI2. In that case, it's all good, as the driver will calculate the dividers right. Now, suppose a similar board has the input wired to SSI2 and output to SSI1, meaning we're now in the following case: - Input has sample rate 8kHz and uses clock SSI2 with rate 512kHz - Output has sample rate 16kHz and uses clock SSI1 with rate 1024kHz (the same result is achieved during capture with the initial example setup, as input and output properties are then swapped) In that case, the selected clocks will still be SSI1 for input (just because it appears first in the clock table), and SSI2 for output, meaning the calculated dividers will be: - input: 512 / 16 => 32 (should be 64) - output: 1024 / 8 => 128 (should be 64 here too) --- I can't see how the clock selection algorithm could be made smart enough to cover cases such as this one, as it would need to be aware of the exact relationship between the sample rate and the clock rate (my example demonstrates a case where the "sample rate to clock rate" multiplier is identical for both input and output, but this can't be assumed to be always the case). Therefore, I still believe being able to force clock selection using optional DT properties would make sense, while still using the auto-selection by default. Regards, Arnaud > > Having a quick review at your changes, I think the DT part may > not be necessary as it's more likely a software configuration. > I personally like the new auto-selecting solution more. > >> This series also fix register configuration and clock assignment so >> conversion can be conducted effectively in both directions with a good >> quality. > > If there's any further change that you feel you can improve on > the top of mentioned change after rebasing, I'd like to review. > > Thanks > Nic > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-17 11:16 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-17 11:16 UTC (permalink / raw) To: Nicolin Chen Cc: devicetree, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Jaroslav Kysela, Mark Brown, kernel, Fabio Estevam Hi Nic, Le 02/07/2020 à 20:42, Nicolin Chen a écrit : > Hi Arnaud, > > On Thu, Jul 02, 2020 at 04:22:31PM +0200, Arnaud Ferraris wrote: >> The current ASRC driver hardcodes the input and output clocks used for >> sample rate conversions. In order to allow greater flexibility and to >> cover more use cases, it would be preferable to select the clocks using >> device-tree properties. > > We recent just merged a new change that auto-selecting internal > clocks based on sample rates as the first option -- ideal ratio > mode is the fallback mode now. Please refer to: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200702&id=d0250cf4f2abfbea64ed247230f08f5ae23979f0 While working on fixing the automatic clock selection (see my v3), I came across another potential issue, which would be better explained with an example: - Input has sample rate 8kHz and uses clock SSI1 with rate 512kHz - Output has sample rate 16kHz and uses clock SSI2 with rate 1024kHz Let's say my v3 patch is merged, then the selected input clock will be SSI1, while the selected output clock will be SSI2. In that case, it's all good, as the driver will calculate the dividers right. Now, suppose a similar board has the input wired to SSI2 and output to SSI1, meaning we're now in the following case: - Input has sample rate 8kHz and uses clock SSI2 with rate 512kHz - Output has sample rate 16kHz and uses clock SSI1 with rate 1024kHz (the same result is achieved during capture with the initial example setup, as input and output properties are then swapped) In that case, the selected clocks will still be SSI1 for input (just because it appears first in the clock table), and SSI2 for output, meaning the calculated dividers will be: - input: 512 / 16 => 32 (should be 64) - output: 1024 / 8 => 128 (should be 64 here too) --- I can't see how the clock selection algorithm could be made smart enough to cover cases such as this one, as it would need to be aware of the exact relationship between the sample rate and the clock rate (my example demonstrates a case where the "sample rate to clock rate" multiplier is identical for both input and output, but this can't be assumed to be always the case). Therefore, I still believe being able to force clock selection using optional DT properties would make sense, while still using the auto-selection by default. Regards, Arnaud > > Having a quick review at your changes, I think the DT part may > not be necessary as it's more likely a software configuration. > I personally like the new auto-selecting solution more. > >> This series also fix register configuration and clock assignment so >> conversion can be conducted effectively in both directions with a good >> quality. > > If there's any further change that you feel you can improve on > the top of mentioned change after rebasing, I'd like to review. > > Thanks > Nic > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-17 11:16 ` Arnaud Ferraris 0 siblings, 0 replies; 55+ messages in thread From: Arnaud Ferraris @ 2020-07-17 11:16 UTC (permalink / raw) To: Nicolin Chen Cc: devicetree, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Mark Brown, kernel, Fabio Estevam Hi Nic, Le 02/07/2020 à 20:42, Nicolin Chen a écrit : > Hi Arnaud, > > On Thu, Jul 02, 2020 at 04:22:31PM +0200, Arnaud Ferraris wrote: >> The current ASRC driver hardcodes the input and output clocks used for >> sample rate conversions. In order to allow greater flexibility and to >> cover more use cases, it would be preferable to select the clocks using >> device-tree properties. > > We recent just merged a new change that auto-selecting internal > clocks based on sample rates as the first option -- ideal ratio > mode is the fallback mode now. Please refer to: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200702&id=d0250cf4f2abfbea64ed247230f08f5ae23979f0 While working on fixing the automatic clock selection (see my v3), I came across another potential issue, which would be better explained with an example: - Input has sample rate 8kHz and uses clock SSI1 with rate 512kHz - Output has sample rate 16kHz and uses clock SSI2 with rate 1024kHz Let's say my v3 patch is merged, then the selected input clock will be SSI1, while the selected output clock will be SSI2. In that case, it's all good, as the driver will calculate the dividers right. Now, suppose a similar board has the input wired to SSI2 and output to SSI1, meaning we're now in the following case: - Input has sample rate 8kHz and uses clock SSI2 with rate 512kHz - Output has sample rate 16kHz and uses clock SSI1 with rate 1024kHz (the same result is achieved during capture with the initial example setup, as input and output properties are then swapped) In that case, the selected clocks will still be SSI1 for input (just because it appears first in the clock table), and SSI2 for output, meaning the calculated dividers will be: - input: 512 / 16 => 32 (should be 64) - output: 1024 / 8 => 128 (should be 64 here too) --- I can't see how the clock selection algorithm could be made smart enough to cover cases such as this one, as it would need to be aware of the exact relationship between the sample rate and the clock rate (my example demonstrates a case where the "sample rate to clock rate" multiplier is identical for both input and output, but this can't be assumed to be always the case). Therefore, I still believe being able to force clock selection using optional DT properties would make sense, while still using the auto-selection by default. Regards, Arnaud > > Having a quick review at your changes, I think the DT part may > not be necessary as it's more likely a software configuration. > I personally like the new auto-selecting solution more. > >> This series also fix register configuration and clock assignment so >> conversion can be conducted effectively in both directions with a good >> quality. > > If there's any further change that you feel you can improve on > the top of mentioned change after rebasing, I'd like to review. > > Thanks > Nic > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks 2020-07-17 11:16 ` Arnaud Ferraris (?) @ 2020-07-23 5:46 ` Nicolin Chen -1 siblings, 0 replies; 55+ messages in thread From: Nicolin Chen @ 2020-07-23 5:46 UTC (permalink / raw) To: Arnaud Ferraris Cc: kernel, Liam Girdwood, Mark Brown, Rob Herring, Timur Tabi, Xiubo Li, Fabio Estevam, Jaroslav Kysela, Takashi Iwai, alsa-devel, devicetree, linux-kernel, linuxppc-dev On Fri, Jul 17, 2020 at 01:16:42PM +0200, Arnaud Ferraris wrote: > Hi Nic, > > Le 02/07/2020 à 20:42, Nicolin Chen a écrit : > > Hi Arnaud, > > > > On Thu, Jul 02, 2020 at 04:22:31PM +0200, Arnaud Ferraris wrote: > >> The current ASRC driver hardcodes the input and output clocks used for > >> sample rate conversions. In order to allow greater flexibility and to > >> cover more use cases, it would be preferable to select the clocks using > >> device-tree properties. > > > > We recent just merged a new change that auto-selecting internal > > clocks based on sample rates as the first option -- ideal ratio > > mode is the fallback mode now. Please refer to: > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200702&id=d0250cf4f2abfbea64ed247230f08f5ae23979f0 > > While working on fixing the automatic clock selection (see my v3), I > came across another potential issue, which would be better explained > with an example: > - Input has sample rate 8kHz and uses clock SSI1 with rate 512kHz > - Output has sample rate 16kHz and uses clock SSI2 with rate 1024kHz > > Let's say my v3 patch is merged, then the selected input clock will be > SSI1, while the selected output clock will be SSI2. In that case, it's > all good, as the driver will calculate the dividers right. > > Now, suppose a similar board has the input wired to SSI2 and output to > SSI1, meaning we're now in the following case: > - Input has sample rate 8kHz and uses clock SSI2 with rate 512kHz > - Output has sample rate 16kHz and uses clock SSI1 with rate 1024kHz > (the same result is achieved during capture with the initial example > setup, as input and output properties are then swapped) > > In that case, the selected clocks will still be SSI1 for input (just > because it appears first in the clock table), and SSI2 for output, > meaning the calculated dividers will be: > - input: 512 / 16 => 32 (should be 64) > - output: 1024 / 8 => 128 (should be 64 here too) I don't get the 32, 128 and 64 parts. Would you please to elaborate a bit? What you said sounds to me like the driver calculates wrong dividers? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-23 5:46 ` Nicolin Chen 0 siblings, 0 replies; 55+ messages in thread From: Nicolin Chen @ 2020-07-23 5:46 UTC (permalink / raw) To: Arnaud Ferraris Cc: devicetree, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Jaroslav Kysela, Mark Brown, kernel, Fabio Estevam On Fri, Jul 17, 2020 at 01:16:42PM +0200, Arnaud Ferraris wrote: > Hi Nic, > > Le 02/07/2020 à 20:42, Nicolin Chen a écrit : > > Hi Arnaud, > > > > On Thu, Jul 02, 2020 at 04:22:31PM +0200, Arnaud Ferraris wrote: > >> The current ASRC driver hardcodes the input and output clocks used for > >> sample rate conversions. In order to allow greater flexibility and to > >> cover more use cases, it would be preferable to select the clocks using > >> device-tree properties. > > > > We recent just merged a new change that auto-selecting internal > > clocks based on sample rates as the first option -- ideal ratio > > mode is the fallback mode now. Please refer to: > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200702&id=d0250cf4f2abfbea64ed247230f08f5ae23979f0 > > While working on fixing the automatic clock selection (see my v3), I > came across another potential issue, which would be better explained > with an example: > - Input has sample rate 8kHz and uses clock SSI1 with rate 512kHz > - Output has sample rate 16kHz and uses clock SSI2 with rate 1024kHz > > Let's say my v3 patch is merged, then the selected input clock will be > SSI1, while the selected output clock will be SSI2. In that case, it's > all good, as the driver will calculate the dividers right. > > Now, suppose a similar board has the input wired to SSI2 and output to > SSI1, meaning we're now in the following case: > - Input has sample rate 8kHz and uses clock SSI2 with rate 512kHz > - Output has sample rate 16kHz and uses clock SSI1 with rate 1024kHz > (the same result is achieved during capture with the initial example > setup, as input and output properties are then swapped) > > In that case, the selected clocks will still be SSI1 for input (just > because it appears first in the clock table), and SSI2 for output, > meaning the calculated dividers will be: > - input: 512 / 16 => 32 (should be 64) > - output: 1024 / 8 => 128 (should be 64 here too) I don't get the 32, 128 and 64 parts. Would you please to elaborate a bit? What you said sounds to me like the driver calculates wrong dividers? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks @ 2020-07-23 5:46 ` Nicolin Chen 0 siblings, 0 replies; 55+ messages in thread From: Nicolin Chen @ 2020-07-23 5:46 UTC (permalink / raw) To: Arnaud Ferraris Cc: devicetree, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li, linux-kernel, Takashi Iwai, Liam Girdwood, Rob Herring, Mark Brown, kernel, Fabio Estevam On Fri, Jul 17, 2020 at 01:16:42PM +0200, Arnaud Ferraris wrote: > Hi Nic, > > Le 02/07/2020 à 20:42, Nicolin Chen a écrit : > > Hi Arnaud, > > > > On Thu, Jul 02, 2020 at 04:22:31PM +0200, Arnaud Ferraris wrote: > >> The current ASRC driver hardcodes the input and output clocks used for > >> sample rate conversions. In order to allow greater flexibility and to > >> cover more use cases, it would be preferable to select the clocks using > >> device-tree properties. > > > > We recent just merged a new change that auto-selecting internal > > clocks based on sample rates as the first option -- ideal ratio > > mode is the fallback mode now. Please refer to: > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200702&id=d0250cf4f2abfbea64ed247230f08f5ae23979f0 > > While working on fixing the automatic clock selection (see my v3), I > came across another potential issue, which would be better explained > with an example: > - Input has sample rate 8kHz and uses clock SSI1 with rate 512kHz > - Output has sample rate 16kHz and uses clock SSI2 with rate 1024kHz > > Let's say my v3 patch is merged, then the selected input clock will be > SSI1, while the selected output clock will be SSI2. In that case, it's > all good, as the driver will calculate the dividers right. > > Now, suppose a similar board has the input wired to SSI2 and output to > SSI1, meaning we're now in the following case: > - Input has sample rate 8kHz and uses clock SSI2 with rate 512kHz > - Output has sample rate 16kHz and uses clock SSI1 with rate 1024kHz > (the same result is achieved during capture with the initial example > setup, as input and output properties are then swapped) > > In that case, the selected clocks will still be SSI1 for input (just > because it appears first in the clock table), and SSI2 for output, > meaning the calculated dividers will be: > - input: 512 / 16 => 32 (should be 64) > - output: 1024 / 8 => 128 (should be 64 here too) I don't get the 32, 128 and 64 parts. Would you please to elaborate a bit? What you said sounds to me like the driver calculates wrong dividers? ^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2020-07-23 5:48 UTC | newest] Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-07-02 14:22 [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks Arnaud Ferraris 2020-07-02 14:22 ` Arnaud Ferraris 2020-07-02 14:22 ` Arnaud Ferraris 2020-07-02 14:22 ` [PATCH 1/4] dt-bindings: sound: fsl,asrc: add properties to select in/out clocks Arnaud Ferraris 2020-07-02 14:22 ` [PATCH 1/4] dt-bindings: sound: fsl, asrc: " Arnaud Ferraris 2020-07-02 14:22 ` Arnaud Ferraris 2020-07-02 14:22 ` [PATCH 2/4] ASoC: fsl_asrc: allow using arbitrary input and output clocks Arnaud Ferraris 2020-07-02 14:22 ` Arnaud Ferraris 2020-07-02 14:22 ` Arnaud Ferraris 2020-07-02 17:42 ` kernel test robot 2020-07-02 21:33 ` kernel test robot 2020-07-02 14:22 ` [PATCH 3/4] ASoC: fsl_asrc: always use ratio for conversion Arnaud Ferraris 2020-07-02 14:22 ` Arnaud Ferraris 2020-07-02 14:22 ` Arnaud Ferraris 2020-07-02 14:22 ` [PATCH 4/4] ASoC: fsl_asrc: swap input and output clocks in capture mode Arnaud Ferraris 2020-07-02 14:22 ` Arnaud Ferraris 2020-07-02 14:22 ` Arnaud Ferraris 2020-07-02 19:34 ` kernel test robot 2020-07-02 18:42 ` [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks Nicolin Chen 2020-07-02 18:42 ` Nicolin Chen 2020-07-02 18:42 ` Nicolin Chen 2020-07-03 9:38 ` Arnaud Ferraris 2020-07-03 9:38 ` Arnaud Ferraris 2020-07-14 16:20 ` Arnaud Ferraris 2020-07-14 16:20 ` Arnaud Ferraris 2020-07-14 20:15 ` Nicolin Chen 2020-07-14 20:15 ` Nicolin Chen 2020-07-14 20:27 ` Mark Brown 2020-07-14 20:27 ` Mark Brown 2020-07-14 20:50 ` Nicolin Chen 2020-07-14 20:50 ` Nicolin Chen 2020-07-15 14:05 ` Mark Brown 2020-07-15 14:05 ` Mark Brown 2020-07-15 16:18 ` Arnaud Ferraris 2020-07-15 16:18 ` Arnaud Ferraris 2020-07-15 16:22 ` Mark Brown 2020-07-15 16:22 ` Mark Brown 2020-07-15 16:32 ` Arnaud Ferraris 2020-07-15 16:32 ` Arnaud Ferraris 2020-07-15 20:46 ` Nicolin Chen 2020-07-15 20:46 ` Nicolin Chen 2020-07-16 9:54 ` Arnaud Ferraris 2020-07-16 9:54 ` Arnaud Ferraris 2020-07-15 21:03 ` Nicolin Chen 2020-07-15 21:03 ` Nicolin Chen 2020-07-16 12:18 ` Mark Brown 2020-07-16 12:18 ` Mark Brown 2020-07-16 14:26 ` Arnaud Ferraris 2020-07-16 14:26 ` Arnaud Ferraris 2020-07-17 11:16 ` Arnaud Ferraris 2020-07-17 11:16 ` Arnaud Ferraris 2020-07-17 11:16 ` Arnaud Ferraris 2020-07-23 5:46 ` Nicolin Chen 2020-07-23 5:46 ` Nicolin Chen 2020-07-23 5:46 ` Nicolin Chen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.