lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3787973.dVgI16VYFl@jernej-laptop>
Date:   Fri, 10 Jul 2020 21:22:34 +0200
From:   Jernej Škrabec <jernej.skrabec@...l.net>
To:     peron.clem@...il.com, Maxime Ripard <mripard@...nel.org>,
        Chen-Yu Tsai <wens@...e.org>, Rob Herring <robh+dt@...nel.org>,
        Mark Brown <broonie@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Samuel Holland <samuel@...lland.org>
Cc:     Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
        Marcus Cooper <codekipper@...il.com>,
        alsa-devel@...a-project.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-sunxi@...glegroups.com
Subject: Re: [linux-sunxi] [PATCH 01/16] ASoC: sun4i-i2s: Add support for H6 I2S

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@...l.net>
> > 
> > H6 I2S is very similar to that in H3, except it supports up to 16
> > channels.
> > 
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@...l.net>
> > Signed-off-by: Marcus Cooper <codekipper@...il.com>
> > Signed-off-by: Clément Péron <peron.clem@...il.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




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ