| Message ID | 20171203204157.20829-5-anarsoul@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Dec 03, 2017 at 12:41:52PM -0800, Vasily Khoruzhick wrote: > Digital part of audio codec block in the A64 is very similar to what > is used by the A33(sun8i) devices. However, it uses different LRCK > divider. > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> What makes it impossible to derive from the sample rate and number of channels? Have you tried other sampling rates? Maxime
On Tue, Dec 5, 2017 at 12:04 AM, Maxime Ripard <maxime.ripard@free-electrons.com> wrote: > On Sun, Dec 03, 2017 at 12:41:52PM -0800, Vasily Khoruzhick wrote: >> Digital part of audio codec block in the A64 is very similar to what >> is used by the A33(sun8i) devices. However, it uses different LRCK >> divider. >> >> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> > > What makes it impossible to derive from the sample rate and number of > channels? It's BCLK / LRCK ratio as per A64 user manual, so it doesn't depend on sample rate. BSP driver always uses a fixed value of 64 here. > Have you tried other sampling rates? I tried speaker-test with a number of sampling rates and had no issues. I couldn't try it in mono, since sun4i-i2s supports minimum of 2 channels. > > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com
On Tue, Dec 05, 2017 at 03:17:39PM -0800, Vasily Khoruzhick wrote: > On Tue, Dec 5, 2017 at 12:04 AM, Maxime Ripard > <maxime.ripard@free-electrons.com> wrote: > > On Sun, Dec 03, 2017 at 12:41:52PM -0800, Vasily Khoruzhick wrote: > >> Digital part of audio codec block in the A64 is very similar to what > >> is used by the A33(sun8i) devices. However, it uses different LRCK > >> divider. > >> > >> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> > > > > What makes it impossible to derive from the sample rate and number of > > channels? > > It's BCLK / LRCK ratio as per A64 user manual, so it doesn't depend on > sample rate. BSP driver always uses a fixed value of 64 here. Well, it kind of does. BCLK is sample rate * sample size * channels, and LRCK is running at the sample rate. So the ratio is the sample size * channels. Anything deviating from those standard i2s concepts should at least be documented, with arguments to back them off. Maxime
On Wed, Dec 06, 2017 at 04:32:05PM +0100, Maxime Ripard wrote: > BCLK is sample rate * sample size * channels, and LRCK is running at > the sample rate. So the ratio is the sample size * channels. > Anything deviating from those standard i2s concepts should at least be > documented, with arguments to back them off. BCLK can be higher than the minimum there in most formats, though some hardware is more restrictive so we tend to go for the minimum clock rate.
On Wed, Dec 06, 2017 at 03:48:10PM +0000, Mark Brown wrote: > On Wed, Dec 06, 2017 at 04:32:05PM +0100, Maxime Ripard wrote: > > > BCLK is sample rate * sample size * channels, and LRCK is running at > > the sample rate. So the ratio is the sample size * channels. > > > Anything deviating from those standard i2s concepts should at least be > > documented, with arguments to back them off. > > BCLK can be higher than the minimum there in most formats, though some > hardware is more restrictive so we tend to go for the minimum clock rate. How does that work in such a case? Is LRCK faster as well, and we're keeping the same ratio, or will the codec buffer the current sample until the next word? Is it usually a property of the codec or the DAI? Thanks! Maxime
On Wed, Dec 06, 2017 at 07:53:08PM +0100, Maxime Ripard wrote: > On Wed, Dec 06, 2017 at 03:48:10PM +0000, Mark Brown wrote: > > BCLK can be higher than the minimum there in most formats, though some > > hardware is more restrictive so we tend to go for the minimum clock rate. > How does that work in such a case? Is LRCK faster as well, and we're > keeping the same ratio, or will the codec buffer the current sample > until the next word? No, the extra clock cycles just get ignored - most of the formats define the location of the data in terms of LRCLK edges, any extra BCLK edges shouldn't do anything. > Is it usually a property of the codec or the DAI? Things that require extra cycles for some reason tend to be CODECs, but this can also be done just because whatever the clock master is doesn't have very flexible dividers.
diff --git a/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt b/Documentation/devicetree/bindings/sound/sun8i-codec.txt similarity index 91% rename from Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt rename to Documentation/devicetree/bindings/sound/sun8i-codec.txt index 2ca3d138528e..ffcf9079a67c 100644 --- a/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt +++ b/Documentation/devicetree/bindings/sound/sun8i-codec.txt @@ -1,7 +1,7 @@ Allwinner SUN8I audio codec ------------------------------------ -On Sun8i-A33 SoCs, the audio is separated in different parts: +On Sun8i-A33 and Sun50i-A64 SoCs, the audio is separated in different parts: - A DAI driver. It uses the "sun4i-i2s" driver which is documented here: Documentation/devicetree/bindings/sound/sun4i-i2s.txt @@ -16,7 +16,9 @@ On Sun8i-A33 SoCs, the audio is separated in different parts: This bindings documentation exposes Sun8i codec (digital part). Required properties: -- compatible: must be "allwinner,sun8i-a33-codec" +- compatible: should be one of the following: + - "allwinner,sun8i-a33-codec" + - "allwinner,sun50i-a64-codec" - reg: must contain the registers location and length - interrupts: must contain the codec interrupt - clocks: a list of phandle + clock-specifer pairs, one for each entry diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c index 054201d1de03..0e2a5adcfb96 100644 --- a/sound/soc/sunxi/sun8i-codec.c +++ b/sound/soc/sunxi/sun8i-codec.c @@ -52,6 +52,7 @@ #define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV 9 #define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV 6 #define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_16 (1 << 6) +#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_64 (2 << 6) #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ 4 #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_16 (1 << 4) #define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT 2 @@ -456,6 +457,10 @@ static const struct sun8i_codec_quirks sun8i_a33_codec_quirks = { .aif1_lrck_div = SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_16, }; +static const struct sun8i_codec_quirks sun50i_a64_codec_quirks = { + .aif1_lrck_div = SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_64, +}; + static int sun8i_codec_probe(struct platform_device *pdev) { struct resource *res_base; @@ -551,6 +556,10 @@ static const struct of_device_id sun8i_codec_of_match[] = { .compatible = "allwinner,sun8i-a33-codec", .data = &sun8i_a33_codec_quirks, }, + { + .compatible = "allwinner,sun50i-a64-codec", + .data = &sun50i_a64_codec_quirks, + }, {} }; MODULE_DEVICE_TABLE(of, sun8i_codec_of_match);
Digital part of audio codec block in the A64 is very similar to what is used by the A33(sun8i) devices. However, it uses different LRCK divider. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> --- .../bindings/sound/{sun8i-a33-codec.txt => sun8i-codec.txt} | 6 ++++-- sound/soc/sunxi/sun8i-codec.c | 9 +++++++++ 2 files changed, 13 insertions(+), 2 deletions(-) rename Documentation/devicetree/bindings/sound/{sun8i-a33-codec.txt => sun8i-codec.txt} (91%)