| Message ID | 20200704113902.336911-1-peron.clem@gmail.com |
|---|---|
| Headers | show |
| Series | Add Allwinner H3/H5/H6/A64 HDMI audio | expand |
Hi, On Sat, Jul 04, 2020 at 01:38:47PM +0200, Clément Péron wrote: > From: Jernej Skrabec <jernej.skrabec@siol.net> > > H6 I2S is very similar to that in H3, except it supports up to 16 > channels. > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > Signed-off-by: Clément Péron <peron.clem@gmail.com> > --- > sound/soc/sunxi/sun4i-i2s.c | 227 ++++++++++++++++++++++++++++++++++++ > 1 file changed, 227 insertions(+) > > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > index d0a8d5810c0a..9690389cb68e 100644 > --- a/sound/soc/sunxi/sun4i-i2s.c > +++ b/sound/soc/sunxi/sun4i-i2s.c > @@ -124,6 +124,21 @@ > #define SUN8I_I2S_RX_CHAN_SEL_REG 0x54 > #define SUN8I_I2S_RX_CHAN_MAP_REG 0x58 > > +/* Defines required for sun50i-h6 support */ > +#define SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET_MASK GENMASK(21, 20) > +#define SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET(offset) ((offset) << 20) > +#define SUN50I_H6_I2S_TX_CHAN_SEL_MASK GENMASK(19, 16) > +#define SUN50I_H6_I2S_TX_CHAN_SEL(chan) ((chan - 1) << 16) > +#define SUN50I_H6_I2S_TX_CHAN_EN_MASK GENMASK(15, 0) > +#define SUN50I_H6_I2S_TX_CHAN_EN(num_chan) (((1 << num_chan) - 1)) > + > +#define SUN50I_H6_I2S_TX_CHAN_MAP0_REG 0x44 > +#define SUN50I_H6_I2S_TX_CHAN_MAP1_REG 0x48 > + > +#define SUN50I_H6_I2S_RX_CHAN_SEL_REG 0x64 > +#define SUN50I_H6_I2S_RX_CHAN_MAP0_REG 0x68 > +#define SUN50I_H6_I2S_RX_CHAN_MAP1_REG 0x6C > + > struct sun4i_i2s; > > /** > @@ -466,6 +481,65 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s, > return 0; > } > > +static int sun50i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s, > + const struct snd_pcm_hw_params *params) We should have sun50i_h6 as prefix. The A64 is also part of the sun50i family and supported through the sun8i callbacks, so it's pretty confusing if you don't have the soc name in there. Maxime
On Sat, Jul 04, 2020 at 01:38:50PM +0200, Clément Péron wrote: > From: Marcus Cooper <codekipper@gmail.com> > > On the newer SoCs such as the H3 and A64 this is set by default > to transfer a 0 after each sample in each slot. However the A10 > and A20 SoCs that this driver was developed on had a default > setting where it padded the audio gain with zeros. > > This isn't a problem while we have only support for 16bit audio > but with larger sample resolution rates in the pipeline then SEXT > bits should be cleared so that they also pad at the LSB. Without > this the audio gets distorted. > > Set sign extend sample for all the sunxi generations even if they > are not affected. This will keep coherency and avoid relying on > default. Isn't it coherence? But I guess consistency would be a better fit here. Maxime
On Sat, Jul 04, 2020 at 01:38:51PM +0200, Clément Péron wrote: > From: Marcus Cooper <codekipper@gmail.com> > > Extend the functionality of the driver to include support of 20 and > 24 bits per sample. > > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > Signed-off-by: Clément Péron <peron.clem@gmail.com> Acked-by: Maxime Ripard <mripard@kernel.org> Thanks! Maxime
On Sat, Jul 04, 2020 at 01:38:52PM +0200, Clément Péron wrote: > From: Marcus Cooper <codekipper@gmail.com> > > Bypass the regmap cache when flushing or reading the i2s FIFOs. > > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > Signed-off-by: Clément Péron <peron.clem@gmail.com> Acked-by: Maxime Ripard <mripard@kernel.org> Thanks Maxime
On Sat, Jul 04, 2020 at 01:38:53PM +0200, Clément Péron wrote: > The FIFO TX reg is volatile and sun8i i2s register > mapping is different from sun4i. > > Even if in this case it's doesn't create an issue, > Avoid setting some regs that are undefined in sun8i. > > Signed-off-by: Clément Péron <peron.clem@gmail.com> Acked-by: Maxime Ripard <mripard@kernel.org> Maxime
Hi, On Sat, Jul 04, 2020 at 01:38:54PM +0200, Clément Péron wrote: > From: Jernej Skrabec <jernej.skrabec@siol.net> > > Add a simple-soundcard to link audio between HDMI and I2S. > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > Signed-off-by: Clément Péron <peron.clem@gmail.com> > --- > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 33 ++++++++++++++++++++ > 1 file changed, 33 insertions(+) > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi > index 78b1361dfbb9..ae169d07b939 100644 > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi > @@ -67,6 +67,25 @@ de: display-engine { > status = "disabled"; > }; > > + hdmi_sound: hdmi-sound { > + compatible = "simple-audio-card"; > + simple-audio-card,format = "i2s"; > + simple-audio-card,name = "sun50i-h6-hdmi"; > + simple-audio-card,mclk-fs = <128>; > + simple-audio-card,frame-inversion; Have you figured that one out? > + status = "disabled"; > + > + simple-audio-card,codec { > + sound-dai = <&hdmi>; > + }; > + > + simple-audio-card,cpu { > + sound-dai = <&i2s1>; > + dai-tdm-slot-num = <2>; > + dai-tdm-slot-width = <32>; I'm not sure why you need to use the TDM stuff here. IIRC the HDMI controller can output on up to 6 channels, so how would that work out? Maxime
On Sat, Jul 04, 2020 at 01:38:59PM +0200, Clément Péron wrote: > From: Marcus Cooper <codekipper@gmail.com> > > Add a simple-soundcard to link audio between HDMI and I2S. > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > Signed-off-by: Clément Péron <peron.clem@gmail.com> > --- > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 21 +++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > index c662f6a170ce..6a321fdc8e90 100644 > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > @@ -102,6 +102,25 @@ de: display-engine { > status = "disabled"; > }; > > + hdmi_sound: hdmi-sound { > + compatible = "simple-audio-card"; > + simple-audio-card,format = "i2s"; > + simple-audio-card,name = "sun50i-a64-hdmi"; > + simple-audio-card,mclk-fs = <128>; > + simple-audio-card,frame-inversion; > + status = "disabled"; > + > + simple-audio-card,codec { > + sound-dai = <&hdmi>; > + }; > + > + simple-audio-card,cpu { > + sound-dai = <&i2s2>; > + dai-tdm-slot-num = <2>; > + dai-tdm-slot-width = <32>; > + }; > + }; > + > osc24M: osc24M_clk { > #clock-cells = <0>; > compatible = "fixed-clock"; > @@ -856,6 +875,7 @@ i2s2: i2s@1c22800 { > resets = <&ccu RST_BUS_I2S2>; > dma-names = "tx"; > dmas = <&dma 27>; > + allwinner,playback-channels = <8>; This isn't documented anywhere Maxime
Hi! Dne ponedeljek, 06. julij 2020 ob 07:31:23 CEST je Maxime Ripard napisal(a): > On Sat, Jul 04, 2020 at 01:38:59PM +0200, Clément Péron wrote: > > From: Marcus Cooper <codekipper@gmail.com> > > > > Add a simple-soundcard to link audio between HDMI and I2S. > > > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> > > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > > Signed-off-by: Clément Péron <peron.clem@gmail.com> > > --- > > > > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 21 +++++++++++++++++++ > > 1 file changed, 21 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > > b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi index > > c662f6a170ce..6a321fdc8e90 100644 > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > > @@ -102,6 +102,25 @@ de: display-engine { > > > > status = "disabled"; > > > > }; > > > > + hdmi_sound: hdmi-sound { > > + compatible = "simple-audio-card"; > > + simple-audio-card,format = "i2s"; > > + simple-audio-card,name = "sun50i-a64-hdmi"; > > + simple-audio-card,mclk-fs = <128>; > > + simple-audio-card,frame-inversion; > > + status = "disabled"; > > + > > + simple-audio-card,codec { > > + sound-dai = <&hdmi>; > > + }; > > + > > + simple-audio-card,cpu { > > + sound-dai = <&i2s2>; > > + dai-tdm-slot-num = <2>; > > + dai-tdm-slot-width = <32>; > > + }; > > + }; > > + > > > > osc24M: osc24M_clk { > > > > #clock-cells = <0>; > > compatible = "fixed-clock"; > > > > @@ -856,6 +875,7 @@ i2s2: i2s@1c22800 { > > > > resets = <&ccu RST_BUS_I2S2>; > > dma-names = "tx"; > > dmas = <&dma 27>; > > > > + allwinner,playback-channels = <8>; > > This isn't documented anywhere This can be safely dropped. It is just leftover from multi-channel (>2) work, which will have to be redesigned anyway. Best regards, Jernej
Hi! Dne ponedeljek, 06. julij 2020 ob 07:29:37 CEST je Maxime Ripard napisal(a): > Hi, > > On Sat, Jul 04, 2020 at 01:38:54PM +0200, Clément Péron wrote: > > From: Jernej Skrabec <jernej.skrabec@siol.net> > > > > Add a simple-soundcard to link audio between HDMI and I2S. > > > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> > > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > > Signed-off-by: Clément Péron <peron.clem@gmail.com> > > --- > > > > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 33 ++++++++++++++++++++ > > 1 file changed, 33 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi > > b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi index > > 78b1361dfbb9..ae169d07b939 100644 > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi > > @@ -67,6 +67,25 @@ de: display-engine { > > > > status = "disabled"; > > > > }; > > > > + hdmi_sound: hdmi-sound { > > + compatible = "simple-audio-card"; > > + simple-audio-card,format = "i2s"; > > + simple-audio-card,name = "sun50i-h6-hdmi"; > > + simple-audio-card,mclk-fs = <128>; > > + simple-audio-card,frame-inversion; > > Have you figured that one out? > > > + status = "disabled"; > > + > > + simple-audio-card,codec { > > + sound-dai = <&hdmi>; > > + }; > > + > > + simple-audio-card,cpu { > > + sound-dai = <&i2s1>; > > + dai-tdm-slot-num = <2>; > > + dai-tdm-slot-width = <32>; > > I'm not sure why you need to use the TDM stuff here. IIRC the HDMI > controller can output on up to 6 channels, so how would that work out? dai-tdm-slot-width is needed to override automatic slot width selection. It should always be 32 for HDMI, no matter what is actual physical sample width. In this case this property is abused to set width also for I2S mode of operation. IMO there is no sense to duplicate code because I2S variant would work exactly the same, except name would be different. I'm not sure about dai-tdm-slot-num. Marcus, can you explain the need for this property? Would it be better to implement separate link driver instead of using simple- card to hide all this properties into the code? Best regards, Jernej
On 7/4/20 6:38 AM, Clément Péron wrote: > From: Jernej Skrabec <jernej.skrabec@siol.net> > > H6 I2S is very similar to that in H3, except it supports up to 16 > channels. > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > Signed-off-by: Clément Péron <peron.clem@gmail.com> > --- > sound/soc/sunxi/sun4i-i2s.c | 227 ++++++++++++++++++++++++++++++++++++ > 1 file changed, 227 insertions(+) > > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > index d0a8d5810c0a..9690389cb68e 100644 > --- a/sound/soc/sunxi/sun4i-i2s.c > +++ b/sound/soc/sunxi/sun4i-i2s.c > @@ -124,6 +124,21 @@ > #define SUN8I_I2S_RX_CHAN_SEL_REG 0x54 > #define SUN8I_I2S_RX_CHAN_MAP_REG 0x58 > > +/* Defines required for sun50i-h6 support */ > +#define SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET_MASK GENMASK(21, 20) > +#define SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET(offset) ((offset) << 20) > +#define SUN50I_H6_I2S_TX_CHAN_SEL_MASK GENMASK(19, 16) > +#define SUN50I_H6_I2S_TX_CHAN_SEL(chan) ((chan - 1) << 16) > +#define SUN50I_H6_I2S_TX_CHAN_EN_MASK GENMASK(15, 0) > +#define SUN50I_H6_I2S_TX_CHAN_EN(num_chan) (((1 << num_chan) - 1)) > + > +#define SUN50I_H6_I2S_TX_CHAN_MAP0_REG 0x44 > +#define SUN50I_H6_I2S_TX_CHAN_MAP1_REG 0x48 > + > +#define SUN50I_H6_I2S_RX_CHAN_SEL_REG 0x64 > +#define SUN50I_H6_I2S_RX_CHAN_MAP0_REG 0x68 > +#define SUN50I_H6_I2S_RX_CHAN_MAP1_REG 0x6C > + > struct sun4i_i2s; > > /** > @@ -466,6 +481,65 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s, > return 0; > } > > +static int sun50i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s, > + const struct snd_pcm_hw_params *params) > +{ > + unsigned int channels = params_channels(params); > + unsigned int slots = channels; > + unsigned int lrck_period; > + > + if (i2s->slots) > + slots = i2s->slots; > + > + /* Map the channels for playback and capture */ > + regmap_write(i2s->regmap, SUN50I_H6_I2S_TX_CHAN_MAP1_REG, 0x76543210); > + regmap_write(i2s->regmap, SUN50I_H6_I2S_RX_CHAN_MAP1_REG, 0x76543210); > + > + /* Configure the channels */ > + regmap_update_bits(i2s->regmap, SUN8I_I2S_TX_CHAN_SEL_REG, > + SUN50I_H6_I2S_TX_CHAN_SEL_MASK, > + SUN50I_H6_I2S_TX_CHAN_SEL(channels)); > + regmap_update_bits(i2s->regmap, SUN50I_H6_I2S_RX_CHAN_SEL_REG, > + SUN50I_H6_I2S_TX_CHAN_SEL_MASK, > + SUN50I_H6_I2S_TX_CHAN_SEL(channels)); > + > + regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG, > + SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM_MASK, > + SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM(channels)); > + regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG, > + SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM_MASK, > + SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM(channels)); > + > + switch (i2s->format & SND_SOC_DAIFMT_FORMAT_MASK) { > + case SND_SOC_DAIFMT_DSP_A: > + case SND_SOC_DAIFMT_DSP_B: > + case SND_SOC_DAIFMT_LEFT_J: > + case SND_SOC_DAIFMT_RIGHT_J: According to the manual, LEFT_J and RIGHT_J should use the same calculation as I2S, not the one for PCM/DSP. > + lrck_period = params_physical_width(params) * slots; > + break; > + > + case SND_SOC_DAIFMT_I2S: > + lrck_period = params_physical_width(params); > + break; > + > + default: > + return -EINVAL; > + } > + > + if (i2s->slot_width) > + lrck_period = i2s->slot_width; > + > + regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG, > + SUN8I_I2S_FMT0_LRCK_PERIOD_MASK, > + SUN8I_I2S_FMT0_LRCK_PERIOD(lrck_period)); From the description in the manual, this looks off by one. The number of BCLKs per LRCK is LRCK_PERIOD + 1. > + > + regmap_update_bits(i2s->regmap, SUN8I_I2S_TX_CHAN_SEL_REG, > + SUN50I_H6_I2S_TX_CHAN_EN_MASK, > + SUN50I_H6_I2S_TX_CHAN_EN(channels)); > + > + return 0; > +} > + > static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream, > struct snd_pcm_hw_params *params, > struct snd_soc_dai *dai) > @@ -691,6 +765,108 @@ static int sun8i_i2s_set_soc_fmt(const struct sun4i_i2s *i2s, > return 0; > } > > +static int sun50i_i2s_set_soc_fmt(const struct sun4i_i2s *i2s, > + unsigned int fmt) > +{ > + u32 mode, val; > + u8 offset; > + > + /* > + * DAI clock polarity > + * > + * The setup for LRCK contradicts the datasheet, but under a > + * scope it's clear that the LRCK polarity is reversed > + * compared to the expected polarity on the bus. > + */ This comment makes us sound a lot more confident than I think we actually are. Regards, Samuel
On 7/4/20 6:38 AM, Clément Péron wrote: > From: Marcus Cooper <codekipper@gmail.com> > > Some codecs such as i2s based HDMI audio and the Pine64 DAC require > a different amount of bit clocks per frame than what is calculated > by the sample width. Use the values obtained by the tdm slot bindings > to adjust the LRCLK width accordingly. > > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > Signed-off-by: Clément Péron <peron.clem@gmail.com> > Acked-by: Maxime Ripard <maxime@cerno.tech> > --- > sound/soc/sunxi/sun4i-i2s.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > index 9690389cb68e..8bae97efea30 100644 > --- a/sound/soc/sunxi/sun4i-i2s.c > +++ b/sound/soc/sunxi/sun4i-i2s.c > @@ -470,6 +470,9 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s, > return -EINVAL; > } > > + if (i2s->slot_width) > + lrck_period = i2s->slot_width; > + > regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG, > SUN8I_I2S_FMT0_LRCK_PERIOD_MASK, > SUN8I_I2S_FMT0_LRCK_PERIOD(lrck_period)); > It looks like the existing code would have the same problem, that this should be lrck_period - 1 according to the manual (I checked H3). Regards, Samuel
On 7/4/20 6:38 AM, Clément Péron wrote: > From: Marcus Cooper <codekipper@gmail.com> > > On the newer SoCs such as the H3 and A64 this is set by default > to transfer a 0 after each sample in each slot. However the A10 > and A20 SoCs that this driver was developed on had a default > setting where it padded the audio gain with zeros. > > This isn't a problem while we have only support for 16bit audio > but with larger sample resolution rates in the pipeline then SEXT > bits should be cleared so that they also pad at the LSB. Without > this the audio gets distorted. > > Set sign extend sample for all the sunxi generations even if they > are not affected. This will keep coherency and avoid relying on > default. > > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > Signed-off-by: Clément Péron <peron.clem@gmail.com> > --- > sound/soc/sunxi/sun4i-i2s.c | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > index 8bae97efea30..f78167e152ce 100644 > --- a/sound/soc/sunxi/sun4i-i2s.c > +++ b/sound/soc/sunxi/sun4i-i2s.c > @@ -48,6 +48,9 @@ > #define SUN4I_I2S_FMT0_FMT_I2S (0 << 0) > > #define SUN4I_I2S_FMT1_REG 0x08 > +#define SUN4I_I2S_FMT1_REG_SEXT_MASK BIT(8) > +#define SUN4I_I2S_FMT1_REG_SEXT(sext) ((sext) << 8) > + > #define SUN4I_I2S_FIFO_TX_REG 0x0c > #define SUN4I_I2S_FIFO_RX_REG 0x10 > > @@ -105,6 +108,9 @@ > #define SUN8I_I2S_FMT0_BCLK_POLARITY_INVERTED (1 << 7) > #define SUN8I_I2S_FMT0_BCLK_POLARITY_NORMAL (0 << 7) > > +#define SUN8I_I2S_FMT1_REG_SEXT_MASK GENMASK(5, 4) > +#define SUN8I_I2S_FMT1_REG_SEXT(sext) ((sext) << 4) > + > #define SUN8I_I2S_INT_STA_REG 0x0c > #define SUN8I_I2S_FIFO_TX_REG 0x20 > > @@ -663,6 +669,12 @@ static int sun4i_i2s_set_soc_fmt(const struct sun4i_i2s *i2s, > } > regmap_update_bits(i2s->regmap, SUN4I_I2S_CTRL_REG, > SUN4I_I2S_CTRL_MODE_MASK, val); > + > + /* Set sign extension to pad out LSB with 0 */ > + regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT1_REG, > + SUN4I_I2S_FMT1_REG_SEXT_MASK, > + SUN4I_I2S_FMT1_REG_SEXT(0)); > + This is just a note; I'm not suggesting a change here: This does nothing, because SUN4I_I2S_FMT1_REG only affects PCM mode, which is not implemented in the driver for the sun4i generation of hardware. PCM mode requires setting bit 4 of SUN4I_I2S_CTRL_REG, and then configuring SUN4I_I2S_FMT1_REG instead of SUN4I_I2S_FMT0_REG. Regards, Samuel
On 7/4/20 6:38 AM, Clément Péron wrote: > From: Marcus Cooper <codekipper@gmail.com> > > Extend the functionality of the driver to include support of 20 and > 24 bits per sample. > > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > Signed-off-by: Clément Péron <peron.clem@gmail.com> > --- > sound/soc/sunxi/sun4i-i2s.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > index f78167e152ce..bc7f9343bc7a 100644 > --- a/sound/soc/sunxi/sun4i-i2s.c > +++ b/sound/soc/sunxi/sun4i-i2s.c > @@ -577,6 +577,9 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream, > case 16: > width = DMA_SLAVE_BUSWIDTH_2_BYTES; > break; > + case 32: > + width = DMA_SLAVE_BUSWIDTH_4_BYTES; > + break; This breaks the sun4i variants, because sun4i_i2s_get_wss returns 4 for a 32 bit width, but it needs to return 3. As a side note, I wonder why we use the physical width (the spacing between samples in RAM) to drive the slot width. S24_LE takes up 4 bytes per sample in RAM, which we need for DMA. But I don't see why we would want to transmit the padding over the wire. I would expect it to be transmitted the same as S24_3LE (which has no padding). It did not matter before, because the only supported format had no padding. Regards, Samuel > default: > dev_err(dai->dev, "Unsupported physical sample width: %d\n", > params_physical_width(params)); > @@ -1063,6 +1066,10 @@ static int sun4i_i2s_dai_probe(struct snd_soc_dai *dai) > return 0; > } > > +#define SUN4I_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \ > + SNDRV_PCM_FMTBIT_S20_LE | \ > + SNDRV_PCM_FMTBIT_S24_LE) > + > static struct snd_soc_dai_driver sun4i_i2s_dai = { > .probe = sun4i_i2s_dai_probe, > .capture = { > @@ -1070,14 +1077,14 @@ static struct snd_soc_dai_driver sun4i_i2s_dai = { > .channels_min = 1, > .channels_max = 8, > .rates = SNDRV_PCM_RATE_8000_192000, > - .formats = SNDRV_PCM_FMTBIT_S16_LE, > + .formats = SUN4I_FORMATS, > }, > .playback = { > .stream_name = "Playback", > .channels_min = 1, > .channels_max = 8, > .rates = SNDRV_PCM_RATE_8000_192000, > - .formats = SNDRV_PCM_FMTBIT_S16_LE, > + .formats = SUN4I_FORMATS, > }, > .ops = &sun4i_i2s_dai_ops, > .symmetric_rates = 1, >
Hi Samuel! Dne petek, 10. julij 2020 ob 07:44:33 CEST je Samuel Holland napisal(a): > On 7/4/20 6:38 AM, Clément Péron wrote: > > From: Jernej Skrabec <jernej.skrabec@siol.net> > > > > H6 I2S is very similar to that in H3, except it supports up to 16 > > channels. > > > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> > > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > > Signed-off-by: Clément Péron <peron.clem@gmail.com> > > --- > > > > sound/soc/sunxi/sun4i-i2s.c | 227 ++++++++++++++++++++++++++++++++++++ > > 1 file changed, 227 insertions(+) > > > > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > > index d0a8d5810c0a..9690389cb68e 100644 > > --- a/sound/soc/sunxi/sun4i-i2s.c > > +++ b/sound/soc/sunxi/sun4i-i2s.c > > @@ -124,6 +124,21 @@ > > > > #define SUN8I_I2S_RX_CHAN_SEL_REG 0x54 > > #define SUN8I_I2S_RX_CHAN_MAP_REG 0x58 > > > > +/* Defines required for sun50i-h6 support */ > > +#define SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET_MASK GENMASK(21, 20) > > +#define SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET(offset) ((offset) << 20) > > +#define SUN50I_H6_I2S_TX_CHAN_SEL_MASK GENMASK(19, 16) > > +#define SUN50I_H6_I2S_TX_CHAN_SEL(chan) ((chan - 1) << 16) > > +#define SUN50I_H6_I2S_TX_CHAN_EN_MASK GENMASK(15, 0) > > +#define SUN50I_H6_I2S_TX_CHAN_EN(num_chan) (((1 << num_chan) - 1)) > > + > > +#define SUN50I_H6_I2S_TX_CHAN_MAP0_REG 0x44 > > +#define SUN50I_H6_I2S_TX_CHAN_MAP1_REG 0x48 > > + > > +#define SUN50I_H6_I2S_RX_CHAN_SEL_REG 0x64 > > +#define SUN50I_H6_I2S_RX_CHAN_MAP0_REG 0x68 > > +#define SUN50I_H6_I2S_RX_CHAN_MAP1_REG 0x6C > > + > > > > struct sun4i_i2s; > > > > /** > > > > @@ -466,6 +481,65 @@ static int sun8i_i2s_set_chan_cfg(const struct > > sun4i_i2s *i2s,> > > return 0; > > > > } > > > > +static int sun50i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s, > > + const struct snd_pcm_hw_params *params) > > +{ > > + unsigned int channels = params_channels(params); > > + unsigned int slots = channels; > > + unsigned int lrck_period; > > + > > + if (i2s->slots) > > + slots = i2s->slots; > > + > > + /* Map the channels for playback and capture */ > > + regmap_write(i2s->regmap, SUN50I_H6_I2S_TX_CHAN_MAP1_REG, 0x76543210); > > + regmap_write(i2s->regmap, SUN50I_H6_I2S_RX_CHAN_MAP1_REG, 0x76543210); > > + > > + /* Configure the channels */ > > + regmap_update_bits(i2s->regmap, SUN8I_I2S_TX_CHAN_SEL_REG, > > + SUN50I_H6_I2S_TX_CHAN_SEL_MASK, > > + SUN50I_H6_I2S_TX_CHAN_SEL(channels)); > > + regmap_update_bits(i2s->regmap, SUN50I_H6_I2S_RX_CHAN_SEL_REG, > > + SUN50I_H6_I2S_TX_CHAN_SEL_MASK, > > + SUN50I_H6_I2S_TX_CHAN_SEL(channels)); > > + > > + regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG, > > + SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM_MASK, > > + SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM(channels)); > > + regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG, > > + SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM_MASK, > > + SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM(channels)); > > + > > + switch (i2s->format & SND_SOC_DAIFMT_FORMAT_MASK) { > > + case SND_SOC_DAIFMT_DSP_A: > > + case SND_SOC_DAIFMT_DSP_B: > > + case SND_SOC_DAIFMT_LEFT_J: > > > + case SND_SOC_DAIFMT_RIGHT_J: > According to the manual, LEFT_J and RIGHT_J should use the same calculation > as I2S, not the one for PCM/DSP. > > > + lrck_period = params_physical_width(params) * slots; > > + break; > > + > > + case SND_SOC_DAIFMT_I2S: > > + lrck_period = params_physical_width(params); > > + break; > > + > > + default: > > + return -EINVAL; > > + } > > + > > + if (i2s->slot_width) > > + lrck_period = i2s->slot_width; > > + > > + regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG, > > + SUN8I_I2S_FMT0_LRCK_PERIOD_MASK, > > + SUN8I_I2S_FMT0_LRCK_PERIOD(lrck_period)); > > From the description in the manual, this looks off by one. The number of > BCLKs per LRCK is LRCK_PERIOD + 1. Are you sure? Macro SUN8I_I2S_FMT0_LRCK_PERIOD() is defined as follows: #define SUN8I_I2S_FMT0_LRCK_PERIOD(period) ((period - 1) << 8) which already lowers value by 1. Best regards, Jernej > > > + > > + regmap_update_bits(i2s->regmap, SUN8I_I2S_TX_CHAN_SEL_REG, > > + SUN50I_H6_I2S_TX_CHAN_EN_MASK, > > + SUN50I_H6_I2S_TX_CHAN_EN(channels)); > > + > > + return 0; > > +} > > + > > > > static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream, > > > > struct snd_pcm_hw_params *params, > > struct snd_soc_dai *dai) > > > > @@ -691,6 +765,108 @@ static int sun8i_i2s_set_soc_fmt(const struct > > sun4i_i2s *i2s,> > > return 0; > > > > } > > > > +static int sun50i_i2s_set_soc_fmt(const struct sun4i_i2s *i2s, > > + unsigned int fmt) > > +{ > > + u32 mode, val; > > + u8 offset; > > + > > + /* > > + * DAI clock polarity > > + * > > + * The setup for LRCK contradicts the datasheet, but under a > > + * scope it's clear that the LRCK polarity is reversed > > + * compared to the expected polarity on the bus. > > + */ > > This comment makes us sound a lot more confident than I think we actually > are. > > Regards, > Samuel
Jernej, On 7/10/20 2:22 PM, Jernej Škrabec wrote: >> From the description in the manual, this looks off by one. The number of >> BCLKs per LRCK is LRCK_PERIOD + 1. > > Are you sure? Macro SUN8I_I2S_FMT0_LRCK_PERIOD() is defined as follows: > > #define SUN8I_I2S_FMT0_LRCK_PERIOD(period) ((period - 1) << 8) > > which already lowers value by 1. No, sorry, I had missed the subtraction happening in the macro. So there's no problem here. Thanks, Samuel
Clément, On 7/4/20 6:38 AM, Clément Péron wrote: > From: Marcus Cooper <codekipper@gmail.com> > > Add the new DAI block for I2S2 which is used for HDMI audio. > > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > Signed-off-by: Clément Péron <peron.clem@gmail.com> > --- > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi > index 22d533d18992..9be13378d4df 100644 > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi > @@ -662,6 +662,19 @@ i2s1: i2s@1c22400 { > status = "disabled"; > }; > > + i2s2: i2s@1c22800 { > + #sound-dai-cells = <0>; > + compatible = "allwinner,sun8i-h3-i2s"; > + reg = <0x01c22800 0x400>; > + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&ccu CLK_BUS_I2S2>, <&ccu CLK_I2S2>; > + clock-names = "apb", "mod"; > + dmas = <&dma 27>; > + resets = <&ccu RST_BUS_I2S2>; > + dma-names = "tx"; `make dtbs_check` reports: i2s@1c22800: dma-names:0: 'rx' was expected i2s@1c22800: dma-names: ['tx'] is too short i2s@1c22800: dmas: [[28, 27]] is too short Regards, Samuel > + status = "disabled"; > + }; > + > codec: codec@1c22c00 { > #sound-dai-cells = <0>; > compatible = "allwinner,sun8i-h3-codec"; >
Hi Samuel, On Fri, 10 Jul 2020 at 07:44, Samuel Holland <samuel@sholland.org> wrote: > > On 7/4/20 6:38 AM, Clément Péron wrote: > > From: Jernej Skrabec <jernej.skrabec@siol.net> > > > > H6 I2S is very similar to that in H3, except it supports up to 16 > > channels. > > > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> > > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > > Signed-off-by: Clément Péron <peron.clem@gmail.com> > > --- > > sound/soc/sunxi/sun4i-i2s.c | 227 ++++++++++++++++++++++++++++++++++++ > > 1 file changed, 227 insertions(+) > > > > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > > index d0a8d5810c0a..9690389cb68e 100644 > > --- a/sound/soc/sunxi/sun4i-i2s.c > > +++ b/sound/soc/sunxi/sun4i-i2s.c > > @@ -124,6 +124,21 @@ > > #define SUN8I_I2S_RX_CHAN_SEL_REG 0x54 > > #define SUN8I_I2S_RX_CHAN_MAP_REG 0x58 > > > > +/* Defines required for sun50i-h6 support */ > > +#define SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET_MASK GENMASK(21, 20) > > +#define SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET(offset) ((offset) << 20) > > +#define SUN50I_H6_I2S_TX_CHAN_SEL_MASK GENMASK(19, 16) > > +#define SUN50I_H6_I2S_TX_CHAN_SEL(chan) ((chan - 1) << 16) > > +#define SUN50I_H6_I2S_TX_CHAN_EN_MASK GENMASK(15, 0) > > +#define SUN50I_H6_I2S_TX_CHAN_EN(num_chan) (((1 << num_chan) - 1)) > > + > > +#define SUN50I_H6_I2S_TX_CHAN_MAP0_REG 0x44 > > +#define SUN50I_H6_I2S_TX_CHAN_MAP1_REG 0x48 > > + > > +#define SUN50I_H6_I2S_RX_CHAN_SEL_REG 0x64 > > +#define SUN50I_H6_I2S_RX_CHAN_MAP0_REG 0x68 > > +#define SUN50I_H6_I2S_RX_CHAN_MAP1_REG 0x6C > > + > > struct sun4i_i2s; > > > > /** > > @@ -466,6 +481,65 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s, > > return 0; > > } > > > > +static int sun50i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s, > > + const struct snd_pcm_hw_params *params) > > +{ > > + unsigned int channels = params_channels(params); > > + unsigned int slots = channels; > > + unsigned int lrck_period; > > + > > + if (i2s->slots) > > + slots = i2s->slots; > > + > > + /* Map the channels for playback and capture */ > > + regmap_write(i2s->regmap, SUN50I_H6_I2S_TX_CHAN_MAP1_REG, 0x76543210); > > + regmap_write(i2s->regmap, SUN50I_H6_I2S_RX_CHAN_MAP1_REG, 0x76543210); > > + > > + /* Configure the channels */ > > + regmap_update_bits(i2s->regmap, SUN8I_I2S_TX_CHAN_SEL_REG, > > + SUN50I_H6_I2S_TX_CHAN_SEL_MASK, > > + SUN50I_H6_I2S_TX_CHAN_SEL(channels)); > > + regmap_update_bits(i2s->regmap, SUN50I_H6_I2S_RX_CHAN_SEL_REG, > > + SUN50I_H6_I2S_TX_CHAN_SEL_MASK, > > + SUN50I_H6_I2S_TX_CHAN_SEL(channels)); > > + > > + regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG, > > + SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM_MASK, > > + SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM(channels)); > > + regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG, > > + SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM_MASK, > > + SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM(channels)); > > + > > + switch (i2s->format & SND_SOC_DAIFMT_FORMAT_MASK) { > > + case SND_SOC_DAIFMT_DSP_A: > > + case SND_SOC_DAIFMT_DSP_B: > > + case SND_SOC_DAIFMT_LEFT_J: > > + case SND_SOC_DAIFMT_RIGHT_J: > > According to the manual, LEFT_J and RIGHT_J should use the same calculation as > I2S, not the one for PCM/DSP. > > > + lrck_period = params_physical_width(params) * slots; > > + break; > > + > > + case SND_SOC_DAIFMT_I2S: > > + lrck_period = params_physical_width(params); > > + break; > > + > > + default: > > + return -EINVAL; > > + } > > + > > + if (i2s->slot_width) > > + lrck_period = i2s->slot_width; > > + > > + regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG, > > + SUN8I_I2S_FMT0_LRCK_PERIOD_MASK, > > + SUN8I_I2S_FMT0_LRCK_PERIOD(lrck_period)); > > From the description in the manual, this looks off by one. The number of BCLKs > per LRCK is LRCK_PERIOD + 1. > > > + > > + regmap_update_bits(i2s->regmap, SUN8I_I2S_TX_CHAN_SEL_REG, > > + SUN50I_H6_I2S_TX_CHAN_EN_MASK, > > + SUN50I_H6_I2S_TX_CHAN_EN(channels)); > > + > > + return 0; > > +} > > + > > static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream, > > struct snd_pcm_hw_params *params, > > struct snd_soc_dai *dai) > > @@ -691,6 +765,108 @@ static int sun8i_i2s_set_soc_fmt(const struct sun4i_i2s *i2s, > > return 0; > > } > > > > +static int sun50i_i2s_set_soc_fmt(const struct sun4i_i2s *i2s, > > + unsigned int fmt) > > +{ > > + u32 mode, val; > > + u8 offset; > > + > > + /* > > + * DAI clock polarity > > + * > > + * The setup for LRCK contradicts the datasheet, but under a > > + * scope it's clear that the LRCK polarity is reversed > > + * compared to the expected polarity on the bus. > > + */ > > This comment makes us sound a lot more confident than I think we actually are. That's a comment that needs to be checked using a Logic analyzer (that I don't have). It's a copy paste from the previous generation. But this seems wrong as we need to specify "simple-audio-card,frame-inversion;" in the device-tree. Regards, Clement > > Regards, > Samuel
Hi Samuel, On Fri, 10 Jul 2020 at 07:44, Samuel Holland <samuel@sholland.org> wrote: > > On 7/4/20 6:38 AM, Clément Péron wrote: > > From: Marcus Cooper <codekipper@gmail.com> > > > > On the newer SoCs such as the H3 and A64 this is set by default > > to transfer a 0 after each sample in each slot. However the A10 > > and A20 SoCs that this driver was developed on had a default > > setting where it padded the audio gain with zeros. > > > > This isn't a problem while we have only support for 16bit audio > > but with larger sample resolution rates in the pipeline then SEXT > > bits should be cleared so that they also pad at the LSB. Without > > this the audio gets distorted. > > > > Set sign extend sample for all the sunxi generations even if they > > are not affected. This will keep coherency and avoid relying on > > default. > > > > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > > Signed-off-by: Clément Péron <peron.clem@gmail.com> > > --- > > sound/soc/sunxi/sun4i-i2s.c | 22 ++++++++++++++++++++++ > > 1 file changed, 22 insertions(+) > > > > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > > index 8bae97efea30..f78167e152ce 100644 > > --- a/sound/soc/sunxi/sun4i-i2s.c > > +++ b/sound/soc/sunxi/sun4i-i2s.c > > @@ -48,6 +48,9 @@ > > #define SUN4I_I2S_FMT0_FMT_I2S (0 << 0) > > > > #define SUN4I_I2S_FMT1_REG 0x08 > > +#define SUN4I_I2S_FMT1_REG_SEXT_MASK BIT(8) > > +#define SUN4I_I2S_FMT1_REG_SEXT(sext) ((sext) << 8) > > + > > #define SUN4I_I2S_FIFO_TX_REG 0x0c > > #define SUN4I_I2S_FIFO_RX_REG 0x10 > > > > @@ -105,6 +108,9 @@ > > #define SUN8I_I2S_FMT0_BCLK_POLARITY_INVERTED (1 << 7) > > #define SUN8I_I2S_FMT0_BCLK_POLARITY_NORMAL (0 << 7) > > > > +#define SUN8I_I2S_FMT1_REG_SEXT_MASK GENMASK(5, 4) > > +#define SUN8I_I2S_FMT1_REG_SEXT(sext) ((sext) << 4) > > + > > #define SUN8I_I2S_INT_STA_REG 0x0c > > #define SUN8I_I2S_FIFO_TX_REG 0x20 > > > > @@ -663,6 +669,12 @@ static int sun4i_i2s_set_soc_fmt(const struct sun4i_i2s *i2s, > > } > > regmap_update_bits(i2s->regmap, SUN4I_I2S_CTRL_REG, > > SUN4I_I2S_CTRL_MODE_MASK, val); > > + > > + /* Set sign extension to pad out LSB with 0 */ > > + regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT1_REG, > > + SUN4I_I2S_FMT1_REG_SEXT_MASK, > > + SUN4I_I2S_FMT1_REG_SEXT(0)); > > + > > This is just a note; I'm not suggesting a change here: > > This does nothing, because SUN4I_I2S_FMT1_REG only affects PCM mode, which is > not implemented in the driver for the sun4i generation of hardware. PCM mode > requires setting bit 4 of SUN4I_I2S_CTRL_REG, and then configuring > SUN4I_I2S_FMT1_REG instead of SUN4I_I2S_FMT0_REG. Thanks for the catch, So i will drop it for sun4i. Regards, Clement > > Regards, > Samuel
Hi Samuel! Dne petek, 10. julij 2020 ob 07:44:51 CEST je Samuel Holland napisal(a): > On 7/4/20 6:38 AM, Clément Péron wrote: > > From: Marcus Cooper <codekipper@gmail.com> > > > > Extend the functionality of the driver to include support of 20 and > > 24 bits per sample. > > > > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > > Signed-off-by: Clément Péron <peron.clem@gmail.com> > > --- > > > > sound/soc/sunxi/sun4i-i2s.c | 11 +++++++++-- > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > > index f78167e152ce..bc7f9343bc7a 100644 > > --- a/sound/soc/sunxi/sun4i-i2s.c > > +++ b/sound/soc/sunxi/sun4i-i2s.c > > @@ -577,6 +577,9 @@ static int sun4i_i2s_hw_params(struct > > snd_pcm_substream *substream,> > > case 16: > > width = DMA_SLAVE_BUSWIDTH_2_BYTES; > > break; > > > > + case 32: > > + width = DMA_SLAVE_BUSWIDTH_4_BYTES; > > + break; > > This breaks the sun4i variants, because sun4i_i2s_get_wss returns 4 for a 32 > bit width, but it needs to return 3. I'm not sure what has WSS with physical width and DMA? > > As a side note, I wonder why we use the physical width (the spacing between > samples in RAM) to drive the slot width. S24_LE takes up 4 bytes per sample > in RAM, which we need for DMA. But I don't see why we would want to > transmit the padding over the wire. I would expect it to be transmitted the > same as S24_3LE (which has no padding). It did not matter before, because > the only supported format had no padding. Allwinner DMA engines support only 1, 2, 4 and sometimes 8 bytes for bus width, so if sample is 24 bits in size, we have no other way but to transmit padding too. Best regards, Jernej > > Regards, > Samuel > > > default: > > dev_err(dai->dev, "Unsupported physical sample width: %d\n", > > > > params_physical_width(params)); > > > > @@ -1063,6 +1066,10 @@ static int sun4i_i2s_dai_probe(struct snd_soc_dai > > *dai)> > > return 0; > > > > } > > > > +#define SUN4I_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \ > > + SNDRV_PCM_FMTBIT_S20_LE | \ > > + SNDRV_PCM_FMTBIT_S24_LE) > > + > > > > static struct snd_soc_dai_driver sun4i_i2s_dai = { > > > > .probe = sun4i_i2s_dai_probe, > > .capture = { > > > > @@ -1070,14 +1077,14 @@ static struct snd_soc_dai_driver sun4i_i2s_dai = { > > > > .channels_min = 1, > > .channels_max = 8, > > .rates = SNDRV_PCM_RATE_8000_192000, > > > > - .formats = SNDRV_PCM_FMTBIT_S16_LE, > > + .formats = SUN4I_FORMATS, > > > > }, > > .playback = { > > > > .stream_name = "Playback", > > .channels_min = 1, > > .channels_max = 8, > > .rates = SNDRV_PCM_RATE_8000_192000, > > > > - .formats = SNDRV_PCM_FMTBIT_S16_LE, > > + .formats = SUN4I_FORMATS, > > > > }, > > .ops = &sun4i_i2s_dai_ops, > > .symmetric_rates = 1,
On 9/2/20 1:10 PM, Jernej Škrabec wrote: > Hi Samuel! > > Dne petek, 10. julij 2020 ob 07:44:51 CEST je Samuel Holland napisal(a): >> On 7/4/20 6:38 AM, Clément Péron wrote: >>> From: Marcus Cooper <codekipper@gmail.com> >>> >>> Extend the functionality of the driver to include support of 20 and >>> 24 bits per sample. >>> >>> Signed-off-by: Marcus Cooper <codekipper@gmail.com> >>> Signed-off-by: Clément Péron <peron.clem@gmail.com> >>> --- >>> >>> sound/soc/sunxi/sun4i-i2s.c | 11 +++++++++-- >>> 1 file changed, 9 insertions(+), 2 deletions(-) >>> >>> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c >>> index f78167e152ce..bc7f9343bc7a 100644 >>> --- a/sound/soc/sunxi/sun4i-i2s.c >>> +++ b/sound/soc/sunxi/sun4i-i2s.c >>> @@ -577,6 +577,9 @@ static int sun4i_i2s_hw_params(struct >>> snd_pcm_substream *substream,> >>> case 16: >>> width = DMA_SLAVE_BUSWIDTH_2_BYTES; >>> break; >>> >>> + case 32: >>> + width = DMA_SLAVE_BUSWIDTH_4_BYTES; >>> + break; >> >> This breaks the sun4i variants, because sun4i_i2s_get_wss returns 4 for a 32 >> bit width, but it needs to return 3. > > I'm not sure what has WSS with physical width and DMA? This is the change where creating a S24_LE stream no longer fails with -EINVAL. So this is the change where userspace stops downsampling 24-bit audio sources. So this is the change where playback of 24-bit audio sources breaks, because WSS is programmed wrong. >> As a side note, I wonder why we use the physical width (the spacing between >> samples in RAM) to drive the slot width. S24_LE takes up 4 bytes per sample >> in RAM, which we need for DMA. But I don't see why we would want to >> transmit the padding over the wire. I would expect it to be transmitted the >> same as S24_3LE (which has no padding). It did not matter before, because >> the only supported format had no padding. > > Allwinner DMA engines support only 1, 2, 4 and sometimes 8 bytes for bus > width, so if sample is 24 bits in size, we have no other way but to transmit > padding too. I understand why we do 4 byte DMA from RAM <=> I2S FIFO; that was not my question. I'm referring to the actual wire format (FIFO <=> PCM_DIN/DOUT). The sample is already truncated from 32 bits to 24 bits in the FIFO -- that's what TXIM and RXOM in FIFO_CTRL control. If a sample is 24 bits wide, why would we send 32 BCLKs for every LRCK? I would expect the slot width to match the sample resolution by default. But yet we have this code in the driver: unsigned int word_size = params_width(params); unsigned int slot_width = params_physical_width(params); I think slot_width should be the same as word_size, and I suggest changing it before adding 20/24-bit support. > Best regards, > Jernej Regards, Samuel >>> default: >>> dev_err(dai->dev, "Unsupported physical sample width: > %d\n", >>> >>> params_physical_width(params)); >>> >>> @@ -1063,6 +1066,10 @@ static int sun4i_i2s_dai_probe(struct snd_soc_dai >>> *dai)> >>> return 0; >>> >>> } >>> >>> +#define SUN4I_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \ >>> + SNDRV_PCM_FMTBIT_S20_LE | \ >>> + SNDRV_PCM_FMTBIT_S24_LE) >>> + >>> >>> static struct snd_soc_dai_driver sun4i_i2s_dai = { >>> >>> .probe = sun4i_i2s_dai_probe, >>> .capture = { >>> >>> @@ -1070,14 +1077,14 @@ static struct snd_soc_dai_driver sun4i_i2s_dai = { >>> >>> .channels_min = 1, >>> .channels_max = 8, >>> .rates = SNDRV_PCM_RATE_8000_192000, >>> >>> - .formats = SNDRV_PCM_FMTBIT_S16_LE, >>> + .formats = SUN4I_FORMATS, >>> >>> }, >>> .playback = { >>> >>> .stream_name = "Playback", >>> .channels_min = 1, >>> .channels_max = 8, >>> .rates = SNDRV_PCM_RATE_8000_192000, >>> >>> - .formats = SNDRV_PCM_FMTBIT_S16_LE, >>> + .formats = SUN4I_FORMATS, >>> >>> }, >>> .ops = &sun4i_i2s_dai_ops, >>> .symmetric_rates = 1, > > > >
On Wed, Sep 02, 2020 at 09:22:33PM -0500, Samuel Holland wrote: > On 9/2/20 1:10 PM, Jernej Škrabec wrote: > > Hi Samuel! > > > > Dne petek, 10. julij 2020 ob 07:44:51 CEST je Samuel Holland napisal(a): > >> On 7/4/20 6:38 AM, Clément Péron wrote: > >>> From: Marcus Cooper <codekipper@gmail.com> > >>> > >>> Extend the functionality of the driver to include support of 20 and > >>> 24 bits per sample. > >>> > >>> Signed-off-by: Marcus Cooper <codekipper@gmail.com> > >>> Signed-off-by: Clément Péron <peron.clem@gmail.com> > >>> --- > >>> > >>> sound/soc/sunxi/sun4i-i2s.c | 11 +++++++++-- > >>> 1 file changed, 9 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > >>> index f78167e152ce..bc7f9343bc7a 100644 > >>> --- a/sound/soc/sunxi/sun4i-i2s.c > >>> +++ b/sound/soc/sunxi/sun4i-i2s.c > >>> @@ -577,6 +577,9 @@ static int sun4i_i2s_hw_params(struct > >>> snd_pcm_substream *substream,> > >>> case 16: > >>> width = DMA_SLAVE_BUSWIDTH_2_BYTES; > >>> break; > >>> > >>> + case 32: > >>> + width = DMA_SLAVE_BUSWIDTH_4_BYTES; > >>> + break; > >> > >> This breaks the sun4i variants, because sun4i_i2s_get_wss returns 4 for a 32 > >> bit width, but it needs to return 3. > > > > I'm not sure what has WSS with physical width and DMA? > > This is the change where creating a S24_LE stream no longer fails with -EINVAL. > So this is the change where userspace stops downsampling 24-bit audio sources. > So this is the change where playback of 24-bit audio sources breaks, because WSS > is programmed wrong. > > >> As a side note, I wonder why we use the physical width (the spacing between > >> samples in RAM) to drive the slot width. S24_LE takes up 4 bytes per sample > >> in RAM, which we need for DMA. But I don't see why we would want to > >> transmit the padding over the wire. I would expect it to be transmitted the > >> same as S24_3LE (which has no padding). It did not matter before, because > >> the only supported format had no padding. > > > > Allwinner DMA engines support only 1, 2, 4 and sometimes 8 bytes for bus > > width, so if sample is 24 bits in size, we have no other way but to transmit > > padding too. > > I understand why we do 4 byte DMA from RAM <=> I2S FIFO; that was not my > question. I'm referring to the actual wire format (FIFO <=> PCM_DIN/DOUT). The > sample is already truncated from 32 bits to 24 bits in the FIFO -- that's what > TXIM and RXOM in FIFO_CTRL control. > > If a sample is 24 bits wide, why would we send 32 BCLKs for every LRCK? I would > expect the slot width to match the sample resolution by default. But yet we have > this code in the driver: > > unsigned int word_size = params_width(params); > unsigned int slot_width = params_physical_width(params); > > I think slot_width should be the same as word_size, and I suggest changing it > before adding 20/24-bit support. Generally speaking, the slot width doesn't necessarily match the physical width. With TDM for example you may very well have slots larger than their samples. That being said, S24 is explicitly a format where you send a sample of 24 bits in a 32-bit word (in the lowest three bytes, little endian) See: https://elixir.bootlin.com/linux/v5.9-rc3/source/sound/core/pcm_misc.c#L75 https://mailman.alsa-project.org/pipermail/alsa-devel/2013-April/061073.html 24 bits of data over three bytes like you suggest is S24_3LE Maxime
On Thu, Sep 03, 2020 at 09:40:23AM +0200, Maxime Ripard wrote: > On Wed, Sep 02, 2020 at 09:22:33PM -0500, Samuel Holland wrote: > > On 9/2/20 1:10 PM, Jernej Škrabec wrote: > > > Hi Samuel! > > > > > > Dne petek, 10. julij 2020 ob 07:44:51 CEST je Samuel Holland napisal(a): > > >> On 7/4/20 6:38 AM, Clément Péron wrote: > > >>> From: Marcus Cooper <codekipper@gmail.com> > > >>> > > >>> Extend the functionality of the driver to include support of 20 and > > >>> 24 bits per sample. > > >>> > > >>> Signed-off-by: Marcus Cooper <codekipper@gmail.com> > > >>> Signed-off-by: Clément Péron <peron.clem@gmail.com> > > >>> --- > > >>> > > >>> sound/soc/sunxi/sun4i-i2s.c | 11 +++++++++-- > > >>> 1 file changed, 9 insertions(+), 2 deletions(-) > > >>> > > >>> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > > >>> index f78167e152ce..bc7f9343bc7a 100644 > > >>> --- a/sound/soc/sunxi/sun4i-i2s.c > > >>> +++ b/sound/soc/sunxi/sun4i-i2s.c > > >>> @@ -577,6 +577,9 @@ static int sun4i_i2s_hw_params(struct > > >>> snd_pcm_substream *substream,> > > >>> case 16: > > >>> width = DMA_SLAVE_BUSWIDTH_2_BYTES; > > >>> break; > > >>> > > >>> + case 32: > > >>> + width = DMA_SLAVE_BUSWIDTH_4_BYTES; > > >>> + break; > > >> > > >> This breaks the sun4i variants, because sun4i_i2s_get_wss returns 4 for a 32 > > >> bit width, but it needs to return 3. > > > > > > I'm not sure what has WSS with physical width and DMA? > > > > This is the change where creating a S24_LE stream no longer fails with -EINVAL. > > So this is the change where userspace stops downsampling 24-bit audio sources. > > So this is the change where playback of 24-bit audio sources breaks, because WSS > > is programmed wrong. > > > > >> As a side note, I wonder why we use the physical width (the spacing between > > >> samples in RAM) to drive the slot width. S24_LE takes up 4 bytes per sample > > >> in RAM, which we need for DMA. But I don't see why we would want to > > >> transmit the padding over the wire. I would expect it to be transmitted the > > >> same as S24_3LE (which has no padding). It did not matter before, because > > >> the only supported format had no padding. > > > > > > Allwinner DMA engines support only 1, 2, 4 and sometimes 8 bytes for bus > > > width, so if sample is 24 bits in size, we have no other way but to transmit > > > padding too. > > > > I understand why we do 4 byte DMA from RAM <=> I2S FIFO; that was not my > > question. I'm referring to the actual wire format (FIFO <=> PCM_DIN/DOUT). The > > sample is already truncated from 32 bits to 24 bits in the FIFO -- that's what > > TXIM and RXOM in FIFO_CTRL control. > > > > If a sample is 24 bits wide, why would we send 32 BCLKs for every LRCK? I would > > expect the slot width to match the sample resolution by default. But yet we have > > this code in the driver: > > > > unsigned int word_size = params_width(params); > > unsigned int slot_width = params_physical_width(params); > > > > I think slot_width should be the same as word_size, and I suggest changing it > > before adding 20/24-bit support. > > Generally speaking, the slot width doesn't necessarily match the > physical width. With TDM for example you may very well have slots > larger than their samples. > > That being said, S24 is explicitly a format where you send a sample of > 24 bits in a 32-bit word (in the lowest three bytes, little endian) > > See: > https://elixir.bootlin.com/linux/v5.9-rc3/source/sound/core/pcm_misc.c#L75 > https://mailman.alsa-project.org/pipermail/alsa-devel/2013-April/061073.html > > 24 bits of data over three bytes like you suggest is S24_3LE > My understanding is physical_width refers to the in memory representation, but shouldn't be used to control the slot width on the bus. If not specified otherwise (say through the set_tdm callback), and if the appropriate BCLK is supported, then the slot should be just large enough to hold the data. Thanks, Charles
On Fri, Sep 04, 2020 at 04:16:49PM +0000, Charles Keepax wrote: > My understanding is physical_width refers to the in memory > representation, but shouldn't be used to control the slot width > on the bus. If not specified otherwise (say through the set_tdm > callback), and if the appropriate BCLK is supported, then the slot > should be just large enough to hold the data. Indeed. The framework isn't great here in tying the memory and wire formats together, ideally there would be more support for them being unrelated without DPCM.