[PATCH 11/25] ASoC: sun8i-codec: Enable all supported clock inversions
Maxime Ripard
maxime at cerno.tech
Thu Oct 8 14:59:46 CEST 2020
On Mon, Oct 05, 2020 at 11:29:51PM -0500, Samuel Holland wrote:
>
> On 10/5/20 6:30 AM, Maxime Ripard wrote:
> > On Wed, Sep 30, 2020 at 09:11:34PM -0500, Samuel Holland wrote:
> > > When using the I2S, LEFT_J, or RIGHT_J format, the hardware supports
> > > independent BCLK and LRCK inversion control. When using DSP_A or DSP_B,
> > > LRCK inversion is not supported. The register bit is repurposed to
> > > select between DSP_A and DSP_B. Extend the driver to support this.
> > >
> > > Signed-off-by: Samuel Holland <samuel at sholland.org>
> > > ---
> > > sound/soc/sunxi/sun8i-codec.c | 57 +++++++++++++++++++++++------------
> > > 1 file changed, 37 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
> > > index 0b713b2a2028..506420fb355c 100644
> > > --- a/sound/soc/sunxi/sun8i-codec.c
> > > +++ b/sound/soc/sunxi/sun8i-codec.c
> > > @@ -39,18 +39,17 @@
> > > #define SUN8I_MOD_RST_CTL_AIF1 15
> > > #define SUN8I_MOD_RST_CTL_ADC 3
> > > #define SUN8I_MOD_RST_CTL_DAC 2
> > > #define SUN8I_SYS_SR_CTRL 0x018
> > > #define SUN8I_SYS_SR_CTRL_AIF1_FS 12
> > > #define SUN8I_SYS_SR_CTRL_AIF2_FS 8
> > > #define SUN8I_AIF1CLK_CTRL 0x040
> > > #define SUN8I_AIF1CLK_CTRL_AIF1_MSTR_MOD 15
> > > -#define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV 14
> > > -#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV 13
> > > +#define SUN8I_AIF1CLK_CTRL_AIF1_CLK_INV 13
> > > #define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV 9
> > > #define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV 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
> > > #define SUN8I_AIF1_ADCDAT_CTRL 0x044
> > > #define SUN8I_AIF1_ADCDAT_CTRL_AIF1_AD0L_ENA 15
> > > #define SUN8I_AIF1_ADCDAT_CTRL_AIF1_AD0R_ENA 14
> > > @@ -85,16 +84,17 @@
> > > #define SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF1DA1R 10
> > > #define SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF2DACR 9
> > > #define SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR 8
> > > #define SUN8I_SYSCLK_CTL_AIF1CLK_SRC_MASK GENMASK(9, 8)
> > > #define SUN8I_SYSCLK_CTL_AIF2CLK_SRC_MASK GENMASK(5, 4)
> > > #define SUN8I_SYS_SR_CTRL_AIF1_FS_MASK GENMASK(15, 12)
> > > #define SUN8I_SYS_SR_CTRL_AIF2_FS_MASK GENMASK(11, 8)
> > > +#define SUN8I_AIF1CLK_CTRL_AIF1_CLK_INV_MASK GENMASK(14, 13)
> > > #define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV_MASK GENMASK(12, 9)
> > > #define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_MASK GENMASK(8, 6)
> > > #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_MASK GENMASK(5, 4)
> > > #define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT_MASK GENMASK(3, 2)
> > > enum {
> > > AIF1,
> > > NAIFS
> > > @@ -168,17 +168,17 @@ static int sun8i_codec_get_hw_rate(struct snd_pcm_hw_params *params)
> > > default:
> > > return -EINVAL;
> > > }
> > > }
> > > static int sun8i_codec_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
> > > {
> > > struct sun8i_codec *scodec = snd_soc_dai_get_drvdata(dai);
> > > - u32 format, value;
> > > + u32 format, invert, value;
> > > /* clock masters */
> > > switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
> > > case SND_SOC_DAIFMT_CBS_CFS: /* Codec slave, DAI master */
> > > value = 0x1;
> > > break;
> > > case SND_SOC_DAIFMT_CBM_CFM: /* Codec Master, DAI slave */
> > > value = 0x0;
> > > @@ -197,55 +197,72 @@ static int sun8i_codec_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
> > > break;
> > > case SND_SOC_DAIFMT_LEFT_J:
> > > format = 0x1;
> > > break;
> > > case SND_SOC_DAIFMT_RIGHT_J:
> > > format = 0x2;
> > > break;
> > > case SND_SOC_DAIFMT_DSP_A:
> > > + format = 0x3;
> > > + invert = 0x0; /* Set LRCK_INV to 0 */
> > > + break;
> > > case SND_SOC_DAIFMT_DSP_B:
> > > format = 0x3;
> > > + invert = 0x1; /* Set LRCK_INV to 1 */
> > > break;
> > > default:
> > > return -EINVAL;
> > > }
> > > regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
> > > SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT_MASK,
> > > format << SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT);
> > > /* clock inversion */
> > > switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
> > > case SND_SOC_DAIFMT_NB_NF: /* Normal */
> > > value = 0x0;
> > > break;
> > > - case SND_SOC_DAIFMT_IB_IF: /* Inversion */
> > > + case SND_SOC_DAIFMT_NB_IF: /* Inverted LRCK */
> > > value = 0x1;
> > > break;
> > > + case SND_SOC_DAIFMT_IB_NF: /* Inverted BCLK */
> > > + value = 0x2;
> > > + break;
> > > + case SND_SOC_DAIFMT_IB_IF: /* Both inverted */
> > > + value = 0x3;
> > > + break;
> > > default:
> > > return -EINVAL;
> > > }
> > > - regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
> > > - BIT(SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV),
> > > - value << SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV);
> > > - /*
> > > - * It appears that the DAI and the codec in the A33 SoC don't
> > > - * share the same polarity for the LRCK signal when they mean
> > > - * 'normal' and 'inverted' in the datasheet.
> > > - *
> > > - * Since the DAI here is our regular i2s driver that have been
> > > - * tested with way more codecs than just this one, it means
> > > - * that the codec probably gets it backward, and we have to
> > > - * invert the value here.
> > > - */
> > > - value ^= scodec->quirks->lrck_inversion;
> > > + if (format == 0x3) {
> >
> > Could we use a define here? That would be more readable
>
> Yes, I can do that.
>
> > > + /* Inverted LRCK is not available in DSP mode. */
> > > + if (value & BIT(0))
> > > + return -EINVAL;
> >
> > And same thing here, explicitly testing both for DSP_A and DSP_B would
> > be more readable.
>
> Here, `value & BIT(0)` means SND_SOC_DAIFMT_NB_IF ||
> SND_SOC_DAIFMT_IB_IF, not selecting the DSP format.
>
> > (And I guess value isn't such a great variable name anymore either)
>
> If I rename `invert` to `dsp_format`, and replace `value` here with
> `invert`, I think that would be more clear.
Yep, definitely :)
Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20201008/92c0710e/attachment-0001.sig>
More information about the Alsa-devel
mailing list