[PATCH 0/5] meson_saradc fixes and minor improvements

[PATCH 0/5] meson_saradc fixes and minor improvements

[Martin Blumenstingl]

Meson8 and Meson8b require that the driver initializes the registers
correctly, while on GXBB and newer this is done by the firmware.
Thus the changes from this series are only relevant for Meson8 and
Meson8b.

The first two patches are bugfixes:
- the first patch fixes an issue where the SAR ADC would not work at
  all
- the second patch initializes the bandgrap register on Meson8 and
  Meson8b (which is required for the SAR ADC to operate)

The third patch is mainly a cosmetic fix because we don't want to
read/write registers that are not documented.

Patch four is purely cosmetic so the mainline driver uses the same
settings as Amlogic's vendor kernel driver.

The last patch initializes the channel muxes. There are sane defaults
for these in the hardware itself. However, some bootloaders are
setting strange values - the result is that reading the ADC gives
garbage values.
I did not tag this as "fix" since in my opinion it's a feature for
fixing broken bootloaders.

Tested on:
- a Meson8m2 board (compatible with Meson8)
- a Meson8b EC-100
- on a Khadas VIM to ensure that the newer SoCs are still working


Martin Blumenstingl (5):
  iio: adc: meson-saradc: fix the bit_idx of the adc_en clock
  iio: adc: meson-saradc: initialize the bandgap correctly on older SoCs
  iio: adc: meson-saradc: Meson8 and Meson8b do not have REG11 and REG13
  iio: adc: meson-saradc: fix the clock frequency on Meson8 and Meson8b
  iio: adc: meson-saradc: program the channel muxes during
    initialization

 drivers/iio/adc/meson_saradc.c | 92 +++++++++++++++++++++++++++++++++++-------
 1 file changed, 78 insertions(+), 14 deletions(-)

-- 
2.15.0

[PATCH 1/5] iio: adc: meson-saradc: fix the bit_idx of the adc_en clock

[Martin Blumenstingl]

Meson8 and Meson8b SoCs use the the SAR ADC gate clock provided by the
MESON_SAR_ADC_REG3 register within the SAR ADC register area.
According to the datasheet (and the existing MESON_SAR_ADC_REG3_CLK_EN
definition) the gate is on bit 30.
The fls() function returns the last set bit, which is "bit index + 1"
(fls(MESON_SAR_ADC_REG3_CLK_EN) returns 31). Fix this by switching to
__ffs() which returns the first set bit, which is bit 30 in our case.

This off by one error results in the ADC not being usable on devices
where the bootloader did not enable the clock.

Fixes: 3adbf3427330 ("iio: adc: add a driver for the SAR ADC found in Amlogic Meson SoCs")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
 drivers/iio/adc/meson_saradc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index 2e8dbb89c8c9..55611244c799 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -600,7 +600,7 @@ static int meson_sar_adc_clk_init(struct iio_dev *indio_dev,
 	init.num_parents = 1;
 
 	priv->clk_gate.reg = base + MESON_SAR_ADC_REG3;
-	priv->clk_gate.bit_idx = fls(MESON_SAR_ADC_REG3_CLK_EN);
+	priv->clk_gate.bit_idx = __ffs(MESON_SAR_ADC_REG3_CLK_EN);
 	priv->clk_gate.hw.init = &init;
 
 	priv->adc_clk = devm_clk_register(&indio_dev->dev, &priv->clk_gate.hw);
-- 
2.15.0

Re: [PATCH 1/5] iio: adc: meson-saradc: fix the bit_idx of the adc_en clock

[Jonathan Cameron]

On Tue, 31 Oct 2017 21:01:43 +0100
Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:

> Meson8 and Meson8b SoCs use the the SAR ADC gate clock provided by the
> MESON_SAR_ADC_REG3 register within the SAR ADC register area.
> According to the datasheet (and the existing MESON_SAR_ADC_REG3_CLK_EN
> definition) the gate is on bit 30.
> The fls() function returns the last set bit, which is "bit index + 1"
> (fls(MESON_SAR_ADC_REG3_CLK_EN) returns 31). Fix this by switching to
> __ffs() which returns the first set bit, which is bit 30 in our case.
> 
> This off by one error results in the ADC not being usable on devices
> where the bootloader did not enable the clock.
> 
> Fixes: 3adbf3427330 ("iio: adc: add a driver for the SAR ADC found in Amlogic Meson SoCs")
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Applied to the fixes-togreg branch of iio.git and marked for stable.

Thanks,

Jonathan
> ---
>  drivers/iio/adc/meson_saradc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index 2e8dbb89c8c9..55611244c799 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -600,7 +600,7 @@ static int meson_sar_adc_clk_init(struct iio_dev *indio_dev,
>  	init.num_parents = 1;
>  
>  	priv->clk_gate.reg = base + MESON_SAR_ADC_REG3;
> -	priv->clk_gate.bit_idx = fls(MESON_SAR_ADC_REG3_CLK_EN);
> +	priv->clk_gate.bit_idx = __ffs(MESON_SAR_ADC_REG3_CLK_EN);
>  	priv->clk_gate.hw.init = &init;
>  
>  	priv->adc_clk = devm_clk_register(&indio_dev->dev, &priv->clk_gate.hw);

[PATCH 2/5] iio: adc: meson-saradc: initialize the bandgap correctly on older SoCs

[Martin Blumenstingl]

Meson8 and Meson8b do not have the MESON_SAR_ADC_REG11 register. The
bandgap setting for these SoCs is configured in the
MESON_SAR_ADC_DELTA_10 register instead.
Make the driver aware of this difference and use the correct bandgap
register depending on the SoC.
This has worked fine on Meson8 and Meson8b because the bootloader is
already initializing the bandgap setting.

Fixes: 6c76ed31cd05 ("iio: adc: meson-saradc: add Meson8b SoC compatibility")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
 drivers/iio/adc/meson_saradc.c | 33 ++++++++++++++++++++++++++-------
 1 file changed, 26 insertions(+), 7 deletions(-)

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index 55611244c799..abe9df879b2a 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -221,6 +221,7 @@ enum meson_sar_adc_chan7_mux_sel {
 
 struct meson_sar_adc_data {
 	bool					has_bl30_integration;
+	u32					bandgap_reg;
 	unsigned int				resolution;
 	const char				*name;
 };
@@ -685,6 +686,20 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
 	return 0;
 }
 
+static void meson_sar_adc_set_bandgap(struct iio_dev *indio_dev, bool on_off)
+{
+	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
+	u32 enable_mask;
+
+	if (priv->data->bandgap_reg == MESON_SAR_ADC_REG11)
+		enable_mask = MESON_SAR_ADC_REG11_BANDGAP_EN;
+	else
+		enable_mask = MESON_SAR_ADC_DELTA_10_TS_VBG_EN;
+
+	regmap_update_bits(priv->regmap, priv->data->bandgap_reg, enable_mask,
+			   on_off ? enable_mask : 0);
+}
+
 static int meson_sar_adc_hw_enable(struct iio_dev *indio_dev)
 {
 	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
@@ -717,9 +732,9 @@ static int meson_sar_adc_hw_enable(struct iio_dev *indio_dev)
 	regval = FIELD_PREP(MESON_SAR_ADC_REG0_FIFO_CNT_IRQ_MASK, 1);
 	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG0,
 			   MESON_SAR_ADC_REG0_FIFO_CNT_IRQ_MASK, regval);
-	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11,
-			   MESON_SAR_ADC_REG11_BANDGAP_EN,
-			   MESON_SAR_ADC_REG11_BANDGAP_EN);
+
+	meson_sar_adc_set_bandgap(indio_dev, true);
+
 	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3,
 			   MESON_SAR_ADC_REG3_ADC_EN,
 			   MESON_SAR_ADC_REG3_ADC_EN);
@@ -739,8 +754,7 @@ static int meson_sar_adc_hw_enable(struct iio_dev *indio_dev)
 err_adc_clk:
 	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3,
 			   MESON_SAR_ADC_REG3_ADC_EN, 0);
-	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11,
-			   MESON_SAR_ADC_REG11_BANDGAP_EN, 0);
+	meson_sar_adc_set_bandgap(indio_dev, false);
 	clk_disable_unprepare(priv->sana_clk);
 err_sana_clk:
 	clk_disable_unprepare(priv->core_clk);
@@ -765,8 +779,8 @@ static int meson_sar_adc_hw_disable(struct iio_dev *indio_dev)
 
 	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3,
 			   MESON_SAR_ADC_REG3_ADC_EN, 0);
-	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11,
-			   MESON_SAR_ADC_REG11_BANDGAP_EN, 0);
+
+	meson_sar_adc_set_bandgap(indio_dev, false);
 
 	clk_disable_unprepare(priv->sana_clk);
 	clk_disable_unprepare(priv->core_clk);
@@ -845,30 +859,35 @@ static const struct iio_info meson_sar_adc_iio_info = {
 
 static const struct meson_sar_adc_data meson_sar_adc_meson8_data = {
 	.has_bl30_integration = false,
+	.bandgap_reg = MESON_SAR_ADC_DELTA_10,
 	.resolution = 10,
 	.name = "meson-meson8-saradc",
 };
 
 static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
 	.has_bl30_integration = false,
+	.bandgap_reg = MESON_SAR_ADC_DELTA_10,
 	.resolution = 10,
 	.name = "meson-meson8b-saradc",
 };
 
 static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
 	.has_bl30_integration = true,
+	.bandgap_reg = MESON_SAR_ADC_REG11,
 	.resolution = 10,
 	.name = "meson-gxbb-saradc",
 };
 
 static const struct meson_sar_adc_data meson_sar_adc_gxl_data = {
 	.has_bl30_integration = true,
+	.bandgap_reg = MESON_SAR_ADC_REG11,
 	.resolution = 12,
 	.name = "meson-gxl-saradc",
 };
 
 static const struct meson_sar_adc_data meson_sar_adc_gxm_data = {
 	.has_bl30_integration = true,
+	.bandgap_reg = MESON_SAR_ADC_REG11,
 	.resolution = 12,
 	.name = "meson-gxm-saradc",
 };
-- 
2.15.0

Re: [PATCH 2/5] iio: adc: meson-saradc: initialize the bandgap correctly on older SoCs

[Jonathan Cameron]

On Tue, 31 Oct 2017 21:01:44 +0100
Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:

> Meson8 and Meson8b do not have the MESON_SAR_ADC_REG11 register. The
> bandgap setting for these SoCs is configured in the
> MESON_SAR_ADC_DELTA_10 register instead.
> Make the driver aware of this difference and use the correct bandgap
> register depending on the SoC.
> This has worked fine on Meson8 and Meson8b because the bootloader is
> already initializing the bandgap setting.
> 
> Fixes: 6c76ed31cd05 ("iio: adc: meson-saradc: add Meson8b SoC compatibility")
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Applied to the fixes-togreg branch of iio.git and marked for stable.

Thanks,

Jonathan
> ---
>  drivers/iio/adc/meson_saradc.c | 33 ++++++++++++++++++++++++++-------
>  1 file changed, 26 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index 55611244c799..abe9df879b2a 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -221,6 +221,7 @@ enum meson_sar_adc_chan7_mux_sel {
>  
>  struct meson_sar_adc_data {
>  	bool					has_bl30_integration;
> +	u32					bandgap_reg;
>  	unsigned int				resolution;
>  	const char				*name;
>  };
> @@ -685,6 +686,20 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  	return 0;
>  }
>  
> +static void meson_sar_adc_set_bandgap(struct iio_dev *indio_dev, bool on_off)
> +{
> +	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
> +	u32 enable_mask;
> +
> +	if (priv->data->bandgap_reg == MESON_SAR_ADC_REG11)
> +		enable_mask = MESON_SAR_ADC_REG11_BANDGAP_EN;
> +	else
> +		enable_mask = MESON_SAR_ADC_DELTA_10_TS_VBG_EN;
> +
> +	regmap_update_bits(priv->regmap, priv->data->bandgap_reg, enable_mask,
> +			   on_off ? enable_mask : 0);
> +}
> +
>  static int meson_sar_adc_hw_enable(struct iio_dev *indio_dev)
>  {
>  	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
> @@ -717,9 +732,9 @@ static int meson_sar_adc_hw_enable(struct iio_dev *indio_dev)
>  	regval = FIELD_PREP(MESON_SAR_ADC_REG0_FIFO_CNT_IRQ_MASK, 1);
>  	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG0,
>  			   MESON_SAR_ADC_REG0_FIFO_CNT_IRQ_MASK, regval);
> -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11,
> -			   MESON_SAR_ADC_REG11_BANDGAP_EN,
> -			   MESON_SAR_ADC_REG11_BANDGAP_EN);
> +
> +	meson_sar_adc_set_bandgap(indio_dev, true);
> +
>  	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3,
>  			   MESON_SAR_ADC_REG3_ADC_EN,
>  			   MESON_SAR_ADC_REG3_ADC_EN);
> @@ -739,8 +754,7 @@ static int meson_sar_adc_hw_enable(struct iio_dev *indio_dev)
>  err_adc_clk:
>  	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3,
>  			   MESON_SAR_ADC_REG3_ADC_EN, 0);
> -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11,
> -			   MESON_SAR_ADC_REG11_BANDGAP_EN, 0);
> +	meson_sar_adc_set_bandgap(indio_dev, false);
>  	clk_disable_unprepare(priv->sana_clk);
>  err_sana_clk:
>  	clk_disable_unprepare(priv->core_clk);
> @@ -765,8 +779,8 @@ static int meson_sar_adc_hw_disable(struct iio_dev *indio_dev)
>  
>  	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3,
>  			   MESON_SAR_ADC_REG3_ADC_EN, 0);
> -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11,
> -			   MESON_SAR_ADC_REG11_BANDGAP_EN, 0);
> +
> +	meson_sar_adc_set_bandgap(indio_dev, false);
>  
>  	clk_disable_unprepare(priv->sana_clk);
>  	clk_disable_unprepare(priv->core_clk);
> @@ -845,30 +859,35 @@ static const struct iio_info meson_sar_adc_iio_info = {
>  
>  static const struct meson_sar_adc_data meson_sar_adc_meson8_data = {
>  	.has_bl30_integration = false,
> +	.bandgap_reg = MESON_SAR_ADC_DELTA_10,
>  	.resolution = 10,
>  	.name = "meson-meson8-saradc",
>  };
>  
>  static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
>  	.has_bl30_integration = false,
> +	.bandgap_reg = MESON_SAR_ADC_DELTA_10,
>  	.resolution = 10,
>  	.name = "meson-meson8b-saradc",
>  };
>  
>  static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
>  	.has_bl30_integration = true,
> +	.bandgap_reg = MESON_SAR_ADC_REG11,
>  	.resolution = 10,
>  	.name = "meson-gxbb-saradc",
>  };
>  
>  static const struct meson_sar_adc_data meson_sar_adc_gxl_data = {
>  	.has_bl30_integration = true,
> +	.bandgap_reg = MESON_SAR_ADC_REG11,
>  	.resolution = 12,
>  	.name = "meson-gxl-saradc",
>  };
>  
>  static const struct meson_sar_adc_data meson_sar_adc_gxm_data = {
>  	.has_bl30_integration = true,
> +	.bandgap_reg = MESON_SAR_ADC_REG11,
>  	.resolution = 12,
>  	.name = "meson-gxm-saradc",
>  };

[PATCH 3/5] iio: adc: meson-saradc: Meson8 and Meson8b do not have REG11 and REG13

[Martin Blumenstingl]

The Meson GXBB and newer SoCs have a few more registers than the older
Meson8 and Meson8b SoCs.
Use a separate regmap config to limit the older SoCs to the DELTA_10
register.

Fixes: 6c76ed31cd05 ("iio: adc: meson-saradc: add Meson8b SoC compatibility")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
 drivers/iio/adc/meson_saradc.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index abe9df879b2a..7dc7d297a0fc 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -224,6 +224,7 @@ struct meson_sar_adc_data {
 	u32					bandgap_reg;
 	unsigned int				resolution;
 	const char				*name;
+	const struct regmap_config		*regmap_config;
 };
 
 struct meson_sar_adc_priv {
@@ -243,13 +244,20 @@ struct meson_sar_adc_priv {
 	int					calibscale;
 };
 
-static const struct regmap_config meson_sar_adc_regmap_config = {
+static const struct regmap_config meson_sar_adc_regmap_config_gxbb = {
 	.reg_bits = 8,
 	.val_bits = 32,
 	.reg_stride = 4,
 	.max_register = MESON_SAR_ADC_REG13,
 };
 
+static const struct regmap_config meson_sar_adc_regmap_config_meson8 = {
+	.reg_bits = 8,
+	.val_bits = 32,
+	.reg_stride = 4,
+	.max_register = MESON_SAR_ADC_DELTA_10,
+};
+
 static unsigned int meson_sar_adc_get_fifo_count(struct iio_dev *indio_dev)
 {
 	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
@@ -860,6 +868,7 @@ static const struct iio_info meson_sar_adc_iio_info = {
 static const struct meson_sar_adc_data meson_sar_adc_meson8_data = {
 	.has_bl30_integration = false,
 	.bandgap_reg = MESON_SAR_ADC_DELTA_10,
+	.regmap_config = &meson_sar_adc_regmap_config_meson8,
 	.resolution = 10,
 	.name = "meson-meson8-saradc",
 };
@@ -867,6 +876,7 @@ static const struct meson_sar_adc_data meson_sar_adc_meson8_data = {
 static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
 	.has_bl30_integration = false,
 	.bandgap_reg = MESON_SAR_ADC_DELTA_10,
+	.regmap_config = &meson_sar_adc_regmap_config_meson8,
 	.resolution = 10,
 	.name = "meson-meson8b-saradc",
 };
@@ -874,6 +884,7 @@ static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
 static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
 	.has_bl30_integration = true,
 	.bandgap_reg = MESON_SAR_ADC_REG11,
+	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
 	.resolution = 10,
 	.name = "meson-gxbb-saradc",
 };
@@ -881,6 +892,7 @@ static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
 static const struct meson_sar_adc_data meson_sar_adc_gxl_data = {
 	.has_bl30_integration = true,
 	.bandgap_reg = MESON_SAR_ADC_REG11,
+	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
 	.resolution = 12,
 	.name = "meson-gxl-saradc",
 };
@@ -888,6 +900,7 @@ static const struct meson_sar_adc_data meson_sar_adc_gxl_data = {
 static const struct meson_sar_adc_data meson_sar_adc_gxm_data = {
 	.has_bl30_integration = true,
 	.bandgap_reg = MESON_SAR_ADC_REG11,
+	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
 	.resolution = 12,
 	.name = "meson-gxm-saradc",
 };
@@ -965,7 +978,7 @@ static int meson_sar_adc_probe(struct platform_device *pdev)
 		return ret;
 
 	priv->regmap = devm_regmap_init_mmio(&pdev->dev, base,
-					     &meson_sar_adc_regmap_config);
+					     priv->data->regmap_config);
 	if (IS_ERR(priv->regmap))
 		return PTR_ERR(priv->regmap);
 
-- 
2.15.0

Re: [PATCH 3/5] iio: adc: meson-saradc: Meson8 and Meson8b do not have REG11 and REG13

[Jonathan Cameron]

On Tue, 31 Oct 2017 21:01:45 +0100
Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:

> The Meson GXBB and newer SoCs have a few more registers than the older
> Meson8 and Meson8b SoCs.
> Use a separate regmap config to limit the older SoCs to the DELTA_10
> register.
> 
> Fixes: 6c76ed31cd05 ("iio: adc: meson-saradc: add Meson8b SoC compatibility")
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>

While this may not have any obvious symptoms, I think it is better to make sure
it is fixed in stable so it doesn't bite us in unexpected ways later.

Applied to the fixes-togreg branch of iio.git and marked for stable.
> ---
>  drivers/iio/adc/meson_saradc.c | 17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index abe9df879b2a..7dc7d297a0fc 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -224,6 +224,7 @@ struct meson_sar_adc_data {
>  	u32					bandgap_reg;
>  	unsigned int				resolution;
>  	const char				*name;
> +	const struct regmap_config		*regmap_config;
>  };
>  
>  struct meson_sar_adc_priv {
> @@ -243,13 +244,20 @@ struct meson_sar_adc_priv {
>  	int					calibscale;
>  };
>  
> -static const struct regmap_config meson_sar_adc_regmap_config = {
> +static const struct regmap_config meson_sar_adc_regmap_config_gxbb = {
>  	.reg_bits = 8,
>  	.val_bits = 32,
>  	.reg_stride = 4,
>  	.max_register = MESON_SAR_ADC_REG13,
>  };
>  
> +static const struct regmap_config meson_sar_adc_regmap_config_meson8 = {
> +	.reg_bits = 8,
> +	.val_bits = 32,
> +	.reg_stride = 4,
> +	.max_register = MESON_SAR_ADC_DELTA_10,
> +};
> +
>  static unsigned int meson_sar_adc_get_fifo_count(struct iio_dev *indio_dev)
>  {
>  	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
> @@ -860,6 +868,7 @@ static const struct iio_info meson_sar_adc_iio_info = {
>  static const struct meson_sar_adc_data meson_sar_adc_meson8_data = {
>  	.has_bl30_integration = false,
>  	.bandgap_reg = MESON_SAR_ADC_DELTA_10,
> +	.regmap_config = &meson_sar_adc_regmap_config_meson8,
>  	.resolution = 10,
>  	.name = "meson-meson8-saradc",
>  };
> @@ -867,6 +876,7 @@ static const struct meson_sar_adc_data meson_sar_adc_meson8_data = {
>  static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
>  	.has_bl30_integration = false,
>  	.bandgap_reg = MESON_SAR_ADC_DELTA_10,
> +	.regmap_config = &meson_sar_adc_regmap_config_meson8,
>  	.resolution = 10,
>  	.name = "meson-meson8b-saradc",
>  };
> @@ -874,6 +884,7 @@ static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
>  static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
>  	.has_bl30_integration = true,
>  	.bandgap_reg = MESON_SAR_ADC_REG11,
> +	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
>  	.resolution = 10,
>  	.name = "meson-gxbb-saradc",
>  };
> @@ -881,6 +892,7 @@ static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
>  static const struct meson_sar_adc_data meson_sar_adc_gxl_data = {
>  	.has_bl30_integration = true,
>  	.bandgap_reg = MESON_SAR_ADC_REG11,
> +	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
>  	.resolution = 12,
>  	.name = "meson-gxl-saradc",
>  };
> @@ -888,6 +900,7 @@ static const struct meson_sar_adc_data meson_sar_adc_gxl_data = {
>  static const struct meson_sar_adc_data meson_sar_adc_gxm_data = {
>  	.has_bl30_integration = true,
>  	.bandgap_reg = MESON_SAR_ADC_REG11,
> +	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
>  	.resolution = 12,
>  	.name = "meson-gxm-saradc",
>  };
> @@ -965,7 +978,7 @@ static int meson_sar_adc_probe(struct platform_device *pdev)
>  		return ret;
>  
>  	priv->regmap = devm_regmap_init_mmio(&pdev->dev, base,
> -					     &meson_sar_adc_regmap_config);
> +					     priv->data->regmap_config);
>  	if (IS_ERR(priv->regmap))
>  		return PTR_ERR(priv->regmap);
>  

[PATCH 4/5] iio: adc: meson-saradc: fix the clock frequency on Meson8 and Meson8b

[Martin Blumenstingl]

GX SoCs use a 1.2 MHz ADC clock, while the older SoCs use a 1.14 MHz
clock.

A comment in the driver from Amlogic's GPL kernel says that it's
running at 1.28 MHz. However, it's actually programming a divider of
20 + 1. With a XTAL clock of 24 MHz this results in a frequency of
1.14 MHz. (their calculation might be based on a 27 MHz XTAL clock,
but this is not what we have on the Meson8 and Meson8b SoCs).

The ADC was still working with the 1.2MHz clock. In my own tests I did
not see a difference between 1.2 and 1.14 MHz (regardless of the clock
frequency used, the ADC results were identical).

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
 drivers/iio/adc/meson_saradc.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index 7dc7d297a0fc..fa3c1378c2c9 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -221,6 +221,7 @@ enum meson_sar_adc_chan7_mux_sel {
 
 struct meson_sar_adc_data {
 	bool					has_bl30_integration;
+	unsigned long				clock_rate;
 	u32					bandgap_reg;
 	unsigned int				resolution;
 	const char				*name;
@@ -684,7 +685,7 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
 		return ret;
 	}
 
-	ret = clk_set_rate(priv->adc_clk, 1200000);
+	ret = clk_set_rate(priv->adc_clk, priv->data->clock_rate);
 	if (ret) {
 		dev_err(indio_dev->dev.parent,
 			"failed to set adc clock rate\n");
@@ -867,6 +868,7 @@ static const struct iio_info meson_sar_adc_iio_info = {
 
 static const struct meson_sar_adc_data meson_sar_adc_meson8_data = {
 	.has_bl30_integration = false,
+	.clock_rate = 1150000,
 	.bandgap_reg = MESON_SAR_ADC_DELTA_10,
 	.regmap_config = &meson_sar_adc_regmap_config_meson8,
 	.resolution = 10,
@@ -875,6 +877,7 @@ static const struct meson_sar_adc_data meson_sar_adc_meson8_data = {
 
 static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
 	.has_bl30_integration = false,
+	.clock_rate = 1150000,
 	.bandgap_reg = MESON_SAR_ADC_DELTA_10,
 	.regmap_config = &meson_sar_adc_regmap_config_meson8,
 	.resolution = 10,
@@ -883,6 +886,7 @@ static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
 
 static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
 	.has_bl30_integration = true,
+	.clock_rate = 1200000,
 	.bandgap_reg = MESON_SAR_ADC_REG11,
 	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
 	.resolution = 10,
@@ -891,6 +895,7 @@ static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
 
 static const struct meson_sar_adc_data meson_sar_adc_gxl_data = {
 	.has_bl30_integration = true,
+	.clock_rate = 1200000,
 	.bandgap_reg = MESON_SAR_ADC_REG11,
 	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
 	.resolution = 12,
@@ -899,6 +904,7 @@ static const struct meson_sar_adc_data meson_sar_adc_gxl_data = {
 
 static const struct meson_sar_adc_data meson_sar_adc_gxm_data = {
 	.has_bl30_integration = true,
+	.clock_rate = 1200000,
 	.bandgap_reg = MESON_SAR_ADC_REG11,
 	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
 	.resolution = 12,
-- 
2.15.0

Re: [PATCH 4/5] iio: adc: meson-saradc: fix the clock frequency on Meson8 and Meson8b

[Jonathan Cameron]

On Tue, 31 Oct 2017 21:01:46 +0100
Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:

> GX SoCs use a 1.2 MHz ADC clock, while the older SoCs use a 1.14 MHz
> clock.
> 
> A comment in the driver from Amlogic's GPL kernel says that it's
> running at 1.28 MHz. However, it's actually programming a divider of
> 20 + 1. With a XTAL clock of 24 MHz this results in a frequency of
> 1.14 MHz. (their calculation might be based on a 27 MHz XTAL clock,
> but this is not what we have on the Meson8 and Meson8b SoCs).
> 
> The ADC was still working with the 1.2MHz clock. In my own tests I did
> not see a difference between 1.2 and 1.14 MHz (regardless of the clock
> frequency used, the ADC results were identical).
> 
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>

Hmm. This will have to wait until the other patches have gotten into
mainline and back to my upstream.  Let me know if I seem to have lost
it. 

Thanks,

 
Jonathan

> ---
>  drivers/iio/adc/meson_saradc.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index 7dc7d297a0fc..fa3c1378c2c9 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -221,6 +221,7 @@ enum meson_sar_adc_chan7_mux_sel {
>  
>  struct meson_sar_adc_data {
>  	bool					has_bl30_integration;
> +	unsigned long				clock_rate;
>  	u32					bandgap_reg;
>  	unsigned int				resolution;
>  	const char				*name;
> @@ -684,7 +685,7 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  		return ret;
>  	}
>  
> -	ret = clk_set_rate(priv->adc_clk, 1200000);
> +	ret = clk_set_rate(priv->adc_clk, priv->data->clock_rate);
>  	if (ret) {
>  		dev_err(indio_dev->dev.parent,
>  			"failed to set adc clock rate\n");
> @@ -867,6 +868,7 @@ static const struct iio_info meson_sar_adc_iio_info = {
>  
>  static const struct meson_sar_adc_data meson_sar_adc_meson8_data = {
>  	.has_bl30_integration = false,
> +	.clock_rate = 1150000,
>  	.bandgap_reg = MESON_SAR_ADC_DELTA_10,
>  	.regmap_config = &meson_sar_adc_regmap_config_meson8,
>  	.resolution = 10,
> @@ -875,6 +877,7 @@ static const struct meson_sar_adc_data meson_sar_adc_meson8_data = {
>  
>  static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
>  	.has_bl30_integration = false,
> +	.clock_rate = 1150000,
>  	.bandgap_reg = MESON_SAR_ADC_DELTA_10,
>  	.regmap_config = &meson_sar_adc_regmap_config_meson8,
>  	.resolution = 10,
> @@ -883,6 +886,7 @@ static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
>  
>  static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
>  	.has_bl30_integration = true,
> +	.clock_rate = 1200000,
>  	.bandgap_reg = MESON_SAR_ADC_REG11,
>  	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
>  	.resolution = 10,
> @@ -891,6 +895,7 @@ static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
>  
>  static const struct meson_sar_adc_data meson_sar_adc_gxl_data = {
>  	.has_bl30_integration = true,
> +	.clock_rate = 1200000,
>  	.bandgap_reg = MESON_SAR_ADC_REG11,
>  	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
>  	.resolution = 12,
> @@ -899,6 +904,7 @@ static const struct meson_sar_adc_data meson_sar_adc_gxl_data = {
>  
>  static const struct meson_sar_adc_data meson_sar_adc_gxm_data = {
>  	.has_bl30_integration = true,
> +	.clock_rate = 1200000,
>  	.bandgap_reg = MESON_SAR_ADC_REG11,
>  	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
>  	.resolution = 12,

Re: [PATCH 4/5] iio: adc: meson-saradc: fix the clock frequency on Meson8 and Meson8b

[Jonathan Cameron]

On Sun, 19 Nov 2017 15:55:48 +0000
Jonathan Cameron <jic23@kernel.org> wrote:

> On Tue, 31 Oct 2017 21:01:46 +0100
> Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
> 
> > GX SoCs use a 1.2 MHz ADC clock, while the older SoCs use a 1.14 MHz
> > clock.
> > 
> > A comment in the driver from Amlogic's GPL kernel says that it's
> > running at 1.28 MHz. However, it's actually programming a divider of
> > 20 + 1. With a XTAL clock of 24 MHz this results in a frequency of
> > 1.14 MHz. (their calculation might be based on a 27 MHz XTAL clock,
> > but this is not what we have on the Meson8 and Meson8b SoCs).
> > 
> > The ADC was still working with the 1.2MHz clock. In my own tests I did
> > not see a difference between 1.2 and 1.14 MHz (regardless of the clock
> > frequency used, the ADC results were identical).
> > 
> > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>  
> 
> Hmm. This will have to wait until the other patches have gotten into
> mainline and back to my upstream.  Let me know if I seem to have lost
> it. 
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan
> 
> Thanks,
> 
>  
> Jonathan
> 
> > ---
> >  drivers/iio/adc/meson_saradc.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> > index 7dc7d297a0fc..fa3c1378c2c9 100644
> > --- a/drivers/iio/adc/meson_saradc.c
> > +++ b/drivers/iio/adc/meson_saradc.c
> > @@ -221,6 +221,7 @@ enum meson_sar_adc_chan7_mux_sel {
> >  
> >  struct meson_sar_adc_data {
> >  	bool					has_bl30_integration;
> > +	unsigned long				clock_rate;
> >  	u32					bandgap_reg;
> >  	unsigned int				resolution;
> >  	const char				*name;
> > @@ -684,7 +685,7 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
> >  		return ret;
> >  	}
> >  
> > -	ret = clk_set_rate(priv->adc_clk, 1200000);
> > +	ret = clk_set_rate(priv->adc_clk, priv->data->clock_rate);
> >  	if (ret) {
> >  		dev_err(indio_dev->dev.parent,
> >  			"failed to set adc clock rate\n");
> > @@ -867,6 +868,7 @@ static const struct iio_info meson_sar_adc_iio_info = {
> >  
> >  static const struct meson_sar_adc_data meson_sar_adc_meson8_data = {
> >  	.has_bl30_integration = false,
> > +	.clock_rate = 1150000,
> >  	.bandgap_reg = MESON_SAR_ADC_DELTA_10,
> >  	.regmap_config = &meson_sar_adc_regmap_config_meson8,
> >  	.resolution = 10,
> > @@ -875,6 +877,7 @@ static const struct meson_sar_adc_data meson_sar_adc_meson8_data = {
> >  
> >  static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> >  	.has_bl30_integration = false,
> > +	.clock_rate = 1150000,
> >  	.bandgap_reg = MESON_SAR_ADC_DELTA_10,
> >  	.regmap_config = &meson_sar_adc_regmap_config_meson8,
> >  	.resolution = 10,
> > @@ -883,6 +886,7 @@ static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> >  
> >  static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> >  	.has_bl30_integration = true,
> > +	.clock_rate = 1200000,
> >  	.bandgap_reg = MESON_SAR_ADC_REG11,
> >  	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
> >  	.resolution = 10,
> > @@ -891,6 +895,7 @@ static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> >  
> >  static const struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> >  	.has_bl30_integration = true,
> > +	.clock_rate = 1200000,
> >  	.bandgap_reg = MESON_SAR_ADC_REG11,
> >  	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
> >  	.resolution = 12,
> > @@ -899,6 +904,7 @@ static const struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> >  
> >  static const struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> >  	.has_bl30_integration = true,
> > +	.clock_rate = 1200000,
> >  	.bandgap_reg = MESON_SAR_ADC_REG11,
> >  	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
> >  	.resolution = 12,  
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] iio: adc: meson-saradc: program the channel muxes during initialization

[Martin Blumenstingl]

On some Meson8 devices the channel muxes are not programmed. This
results in garbage values when trying to read channels that are not set
up.
Fix this by initializing the channel 0 and 1 muxes in
MESON_SAR_ADC_CHAN_10_SW as well as the muxes for all other channels in
MESON_SAR_ADC_AUX_SW based on what the vendor driver does (which is
simply a 1:1 mapping of channel number and channel mux).
This only showed up on Meson8 devices, because for GXBB and newer BL30
is taking care of initializing the channel muxes.

This additionally fixes a typo in the
MESON_SAR_ADC_AUX_SW_MUX_SEL_CHAN_MASK macro because the old definition
assumed that the register fields were 2 bit wide, while they are
actually 3 bit wide.

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
 drivers/iio/adc/meson_saradc.c | 32 +++++++++++++++++++++++++++++---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index fa3c1378c2c9..48fb1b642a5e 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -96,8 +96,8 @@
 	#define MESON_SAR_ADC_FIFO_RD_SAMPLE_VALUE_MASK		GENMASK(11, 0)
 
 #define MESON_SAR_ADC_AUX_SW					0x1c
-	#define MESON_SAR_ADC_AUX_SW_MUX_SEL_CHAN_MASK(_chan)	\
-					(GENMASK(10, 8) << (((_chan) - 2) * 2))
+	#define MESON_SAR_ADC_AUX_SW_MUX_SEL_CHAN_SHIFT(_chan)	\
+					(8 + (((_chan) - 2) * 3))
 	#define MESON_SAR_ADC_AUX_SW_VREF_P_MUX			BIT(6)
 	#define MESON_SAR_ADC_AUX_SW_VREF_N_MUX			BIT(5)
 	#define MESON_SAR_ADC_AUX_SW_MODE_SEL			BIT(4)
@@ -623,7 +623,7 @@ static int meson_sar_adc_clk_init(struct iio_dev *indio_dev,
 static int meson_sar_adc_init(struct iio_dev *indio_dev)
 {
 	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
-	int regval, ret;
+	int regval, i, ret;
 
 	/*
 	 * make sure we start at CH7 input since the other muxes are only used
@@ -678,6 +678,32 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
 			   FIELD_PREP(MESON_SAR_ADC_DELAY_INPUT_DLY_SEL_MASK,
 				      1));
 
+	/*
+	 * set up the input channel muxes in MESON_SAR_ADC_CHAN_10_SW
+	 * (0 = SAR_ADC_CH0, 1 = SAR_ADC_CH1)
+	 */
+	regval = FIELD_PREP(MESON_SAR_ADC_CHAN_10_SW_CHAN0_MUX_SEL_MASK, 0);
+	regmap_update_bits(priv->regmap, MESON_SAR_ADC_CHAN_10_SW,
+			   MESON_SAR_ADC_CHAN_10_SW_CHAN0_MUX_SEL_MASK,
+			   regval);
+	regval = FIELD_PREP(MESON_SAR_ADC_CHAN_10_SW_CHAN1_MUX_SEL_MASK, 1);
+	regmap_update_bits(priv->regmap, MESON_SAR_ADC_CHAN_10_SW,
+			   MESON_SAR_ADC_CHAN_10_SW_CHAN1_MUX_SEL_MASK,
+			   regval);
+
+	/*
+	 * set up the input channel muxes in MESON_SAR_ADC_AUX_SW
+	 * (2 = SAR_ADC_CH2, 3 = SAR_ADC_CH3, ...) and enable
+	 * MESON_SAR_ADC_AUX_SW_YP_DRIVE_SW and
+	 * MESON_SAR_ADC_AUX_SW_XP_DRIVE_SW like the vendor driver.
+	 */
+	regval = 0;
+	for (i = 2; i <= 7; i++)
+		regval |= i << MESON_SAR_ADC_AUX_SW_MUX_SEL_CHAN_SHIFT(i);
+	regval |= MESON_SAR_ADC_AUX_SW_YP_DRIVE_SW;
+	regval |= MESON_SAR_ADC_AUX_SW_XP_DRIVE_SW;
+	regmap_write(priv->regmap, MESON_SAR_ADC_AUX_SW, regval);
+
 	ret = clk_set_parent(priv->adc_sel_clk, priv->clkin);
 	if (ret) {
 		dev_err(indio_dev->dev.parent,
-- 
2.15.0

Re: [PATCH 5/5] iio: adc: meson-saradc: program the channel muxes during initialization

[Jonathan Cameron]

On Tue, 31 Oct 2017 21:01:47 +0100
Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:

> On some Meson8 devices the channel muxes are not programmed. This
> results in garbage values when trying to read channels that are not set
> up.
> Fix this by initializing the channel 0 and 1 muxes in
> MESON_SAR_ADC_CHAN_10_SW as well as the muxes for all other channels in
> MESON_SAR_ADC_AUX_SW based on what the vendor driver does (which is
> simply a 1:1 mapping of channel number and channel mux).
> This only showed up on Meson8 devices, because for GXBB and newer BL30
> is taking care of initializing the channel muxes.
> 
> This additionally fixes a typo in the
> MESON_SAR_ADC_AUX_SW_MUX_SEL_CHAN_MASK macro because the old definition
> assumed that the register fields were 2 bit wide, while they are
> actually 3 bit wide.
> 
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>

I'll go with your opinion on this.   We can always request that it is
added to stable after it has gone in during the next merge window.

Let me know if I seem to have forgotten this once the fixes have
come back round the loop to my togreg branch.

Thanks,

Jonathan
> ---
>  drivers/iio/adc/meson_saradc.c | 32 +++++++++++++++++++++++++++++---
>  1 file changed, 29 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index fa3c1378c2c9..48fb1b642a5e 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -96,8 +96,8 @@
>  	#define MESON_SAR_ADC_FIFO_RD_SAMPLE_VALUE_MASK		GENMASK(11, 0)
>  
>  #define MESON_SAR_ADC_AUX_SW					0x1c
> -	#define MESON_SAR_ADC_AUX_SW_MUX_SEL_CHAN_MASK(_chan)	\
> -					(GENMASK(10, 8) << (((_chan) - 2) * 2))
> +	#define MESON_SAR_ADC_AUX_SW_MUX_SEL_CHAN_SHIFT(_chan)	\
> +					(8 + (((_chan) - 2) * 3))
>  	#define MESON_SAR_ADC_AUX_SW_VREF_P_MUX			BIT(6)
>  	#define MESON_SAR_ADC_AUX_SW_VREF_N_MUX			BIT(5)
>  	#define MESON_SAR_ADC_AUX_SW_MODE_SEL			BIT(4)
> @@ -623,7 +623,7 @@ static int meson_sar_adc_clk_init(struct iio_dev *indio_dev,
>  static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  {
>  	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
> -	int regval, ret;
> +	int regval, i, ret;
>  
>  	/*
>  	 * make sure we start at CH7 input since the other muxes are only used
> @@ -678,6 +678,32 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  			   FIELD_PREP(MESON_SAR_ADC_DELAY_INPUT_DLY_SEL_MASK,
>  				      1));
>  
> +	/*
> +	 * set up the input channel muxes in MESON_SAR_ADC_CHAN_10_SW
> +	 * (0 = SAR_ADC_CH0, 1 = SAR_ADC_CH1)
> +	 */
> +	regval = FIELD_PREP(MESON_SAR_ADC_CHAN_10_SW_CHAN0_MUX_SEL_MASK, 0);
> +	regmap_update_bits(priv->regmap, MESON_SAR_ADC_CHAN_10_SW,
> +			   MESON_SAR_ADC_CHAN_10_SW_CHAN0_MUX_SEL_MASK,
> +			   regval);
> +	regval = FIELD_PREP(MESON_SAR_ADC_CHAN_10_SW_CHAN1_MUX_SEL_MASK, 1);
> +	regmap_update_bits(priv->regmap, MESON_SAR_ADC_CHAN_10_SW,
> +			   MESON_SAR_ADC_CHAN_10_SW_CHAN1_MUX_SEL_MASK,
> +			   regval);
> +
> +	/*
> +	 * set up the input channel muxes in MESON_SAR_ADC_AUX_SW
> +	 * (2 = SAR_ADC_CH2, 3 = SAR_ADC_CH3, ...) and enable
> +	 * MESON_SAR_ADC_AUX_SW_YP_DRIVE_SW and
> +	 * MESON_SAR_ADC_AUX_SW_XP_DRIVE_SW like the vendor driver.
> +	 */
> +	regval = 0;
> +	for (i = 2; i <= 7; i++)
> +		regval |= i << MESON_SAR_ADC_AUX_SW_MUX_SEL_CHAN_SHIFT(i);
> +	regval |= MESON_SAR_ADC_AUX_SW_YP_DRIVE_SW;
> +	regval |= MESON_SAR_ADC_AUX_SW_XP_DRIVE_SW;
> +	regmap_write(priv->regmap, MESON_SAR_ADC_AUX_SW, regval);
> +
>  	ret = clk_set_parent(priv->adc_sel_clk, priv->clkin);
>  	if (ret) {
>  		dev_err(indio_dev->dev.parent,

Re: [PATCH 5/5] iio: adc: meson-saradc: program the channel muxes during initialization

[Jonathan Cameron]

On Sun, 19 Nov 2017 15:57:01 +0000
Jonathan Cameron <jic23@kernel.org> wrote:

> On Tue, 31 Oct 2017 21:01:47 +0100
> Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
> 
> > On some Meson8 devices the channel muxes are not programmed. This
> > results in garbage values when trying to read channels that are not set
> > up.
> > Fix this by initializing the channel 0 and 1 muxes in
> > MESON_SAR_ADC_CHAN_10_SW as well as the muxes for all other channels in
> > MESON_SAR_ADC_AUX_SW based on what the vendor driver does (which is
> > simply a 1:1 mapping of channel number and channel mux).
> > This only showed up on Meson8 devices, because for GXBB and newer BL30
> > is taking care of initializing the channel muxes.
> > 
> > This additionally fixes a typo in the
> > MESON_SAR_ADC_AUX_SW_MUX_SEL_CHAN_MASK macro because the old definition
> > assumed that the register fields were 2 bit wide, while they are
> > actually 3 bit wide.
> > 
> > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>  
> 
> I'll go with your opinion on this.   We can always request that it is
> added to stable after it has gone in during the next merge window.
> 
> Let me know if I seem to have forgotten this once the fixes have
> come back round the loop to my togreg branch.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan 

> 
> Thanks,
> 
> Jonathan
> > ---
> >  drivers/iio/adc/meson_saradc.c | 32 +++++++++++++++++++++++++++++---
> >  1 file changed, 29 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> > index fa3c1378c2c9..48fb1b642a5e 100644
> > --- a/drivers/iio/adc/meson_saradc.c
> > +++ b/drivers/iio/adc/meson_saradc.c
> > @@ -96,8 +96,8 @@
> >  	#define MESON_SAR_ADC_FIFO_RD_SAMPLE_VALUE_MASK		GENMASK(11, 0)
> >  
> >  #define MESON_SAR_ADC_AUX_SW					0x1c
> > -	#define MESON_SAR_ADC_AUX_SW_MUX_SEL_CHAN_MASK(_chan)	\
> > -					(GENMASK(10, 8) << (((_chan) - 2) * 2))
> > +	#define MESON_SAR_ADC_AUX_SW_MUX_SEL_CHAN_SHIFT(_chan)	\
> > +					(8 + (((_chan) - 2) * 3))
> >  	#define MESON_SAR_ADC_AUX_SW_VREF_P_MUX			BIT(6)
> >  	#define MESON_SAR_ADC_AUX_SW_VREF_N_MUX			BIT(5)
> >  	#define MESON_SAR_ADC_AUX_SW_MODE_SEL			BIT(4)
> > @@ -623,7 +623,7 @@ static int meson_sar_adc_clk_init(struct iio_dev *indio_dev,
> >  static int meson_sar_adc_init(struct iio_dev *indio_dev)
> >  {
> >  	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
> > -	int regval, ret;
> > +	int regval, i, ret;
> >  
> >  	/*
> >  	 * make sure we start at CH7 input since the other muxes are only used
> > @@ -678,6 +678,32 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
> >  			   FIELD_PREP(MESON_SAR_ADC_DELAY_INPUT_DLY_SEL_MASK,
> >  				      1));
> >  
> > +	/*
> > +	 * set up the input channel muxes in MESON_SAR_ADC_CHAN_10_SW
> > +	 * (0 = SAR_ADC_CH0, 1 = SAR_ADC_CH1)
> > +	 */
> > +	regval = FIELD_PREP(MESON_SAR_ADC_CHAN_10_SW_CHAN0_MUX_SEL_MASK, 0);
> > +	regmap_update_bits(priv->regmap, MESON_SAR_ADC_CHAN_10_SW,
> > +			   MESON_SAR_ADC_CHAN_10_SW_CHAN0_MUX_SEL_MASK,
> > +			   regval);
> > +	regval = FIELD_PREP(MESON_SAR_ADC_CHAN_10_SW_CHAN1_MUX_SEL_MASK, 1);
> > +	regmap_update_bits(priv->regmap, MESON_SAR_ADC_CHAN_10_SW,
> > +			   MESON_SAR_ADC_CHAN_10_SW_CHAN1_MUX_SEL_MASK,
> > +			   regval);
> > +
> > +	/*
> > +	 * set up the input channel muxes in MESON_SAR_ADC_AUX_SW
> > +	 * (2 = SAR_ADC_CH2, 3 = SAR_ADC_CH3, ...) and enable
> > +	 * MESON_SAR_ADC_AUX_SW_YP_DRIVE_SW and
> > +	 * MESON_SAR_ADC_AUX_SW_XP_DRIVE_SW like the vendor driver.
> > +	 */
> > +	regval = 0;
> > +	for (i = 2; i <= 7; i++)
> > +		regval |= i << MESON_SAR_ADC_AUX_SW_MUX_SEL_CHAN_SHIFT(i);
> > +	regval |= MESON_SAR_ADC_AUX_SW_YP_DRIVE_SW;
> > +	regval |= MESON_SAR_ADC_AUX_SW_XP_DRIVE_SW;
> > +	regmap_write(priv->regmap, MESON_SAR_ADC_AUX_SW, regval);
> > +
> >  	ret = clk_set_parent(priv->adc_sel_clk, priv->clkin);
> >  	if (ret) {
> >  		dev_err(indio_dev->dev.parent,  
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] meson_saradc fixes and minor improvements

[Jonathan Cameron]

On Tue, 31 Oct 2017 21:01:42 +0100
Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:

> Meson8 and Meson8b require that the driver initializes the registers
> correctly, while on GXBB and newer this is done by the firmware.
> Thus the changes from this series are only relevant for Meson8 and
> Meson8b.
> 
> The first two patches are bugfixes:
> - the first patch fixes an issue where the SAR ADC would not work at
>   all
> - the second patch initializes the bandgrap register on Meson8 and
>   Meson8b (which is required for the SAR ADC to operate)
> 
> The third patch is mainly a cosmetic fix because we don't want to
> read/write registers that are not documented.
> 
> Patch four is purely cosmetic so the mainline driver uses the same
> settings as Amlogic's vendor kernel driver.
> 
> The last patch initializes the channel muxes. There are sane defaults
> for these in the hardware itself. However, some bootloaders are
> setting strange values - the result is that reading the ADC gives
> garbage values.
> I did not tag this as "fix" since in my opinion it's a feature for
> fixing broken bootloaders.
> 
> Tested on:
> - a Meson8m2 board (compatible with Meson8)
> - a Meson8b EC-100
> - on a Khadas VIM to ensure that the newer SoCs are still working
> 
> 
> Martin Blumenstingl (5):
>   iio: adc: meson-saradc: fix the bit_idx of the adc_en clock
>   iio: adc: meson-saradc: initialize the bandgap correctly on older
> SoCs iio: adc: meson-saradc: Meson8 and Meson8b do not have REG11 and
> REG13 iio: adc: meson-saradc: fix the clock frequency on Meson8 and
> Meson8b iio: adc: meson-saradc: program the channel muxes during
>     initialization
> 
>  drivers/iio/adc/meson_saradc.c | 92
> +++++++++++++++++++++++++++++++++++------- 1 file changed, 78
> insertions(+), 14 deletions(-)
> 
Series seems fine to me.  If no one else raises anything I'll pick this
up when I'm am back in the UK the week after next.

Thanks,

Jonathan

Re: [PATCH 0/5] meson_saradc fixes and minor improvements

[Kevin Hilman]

Hi Jonathan,

Jonathan Cameron <Jonathan.Cameron@huawei.com> writes:

> On Tue, 31 Oct 2017 21:01:42 +0100
> Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
>
>> Meson8 and Meson8b require that the driver initializes the registers
>> correctly, while on GXBB and newer this is done by the firmware.
>> Thus the changes from this series are only relevant for Meson8 and
>> Meson8b.
>> 
>> The first two patches are bugfixes:
>> - the first patch fixes an issue where the SAR ADC would not work at
>>   all
>> - the second patch initializes the bandgrap register on Meson8 and
>>   Meson8b (which is required for the SAR ADC to operate)
>> 
>> The third patch is mainly a cosmetic fix because we don't want to
>> read/write registers that are not documented.
>> 
>> Patch four is purely cosmetic so the mainline driver uses the same
>> settings as Amlogic's vendor kernel driver.
>> 
>> The last patch initializes the channel muxes. There are sane defaults
>> for these in the hardware itself. However, some bootloaders are
>> setting strange values - the result is that reading the ADC gives
>> garbage values.
>> I did not tag this as "fix" since in my opinion it's a feature for
>> fixing broken bootloaders.
>> 
>> Tested on:
>> - a Meson8m2 board (compatible with Meson8)
>> - a Meson8b EC-100
>> - on a Khadas VIM to ensure that the newer SoCs are still working
>> 
>> 
>> Martin Blumenstingl (5):
>>   iio: adc: meson-saradc: fix the bit_idx of the adc_en clock
>>   iio: adc: meson-saradc: initialize the bandgap correctly on older
>> SoCs iio: adc: meson-saradc: Meson8 and Meson8b do not have REG11 and
>> REG13 iio: adc: meson-saradc: fix the clock frequency on Meson8 and
>> Meson8b iio: adc: meson-saradc: program the channel muxes during
>>     initialization
>> 
>>  drivers/iio/adc/meson_saradc.c | 92
>> +++++++++++++++++++++++++++++++++++------- 1 file changed, 78
>> insertions(+), 14 deletions(-)
>> 
> Series seems fine to me.  If no one else raises anything I'll pick this
> up when I'm am back in the UK the week after next.

Just a gentle ping on the status of this series as I'm not seeing it in
linux-next.

Thanks,

Kevin

Re: [PATCH 0/5] meson_saradc fixes and minor improvements

[Jonathan Cameron]

On Mon, 27 Nov 2017 15:47:14 -0800
Kevin Hilman <khilman@baylibre.com> wrote:

> Hi Jonathan,
> 
> Jonathan Cameron <Jonathan.Cameron@huawei.com> writes:
> 
> > On Tue, 31 Oct 2017 21:01:42 +0100
> > Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
> >  
> >> Meson8 and Meson8b require that the driver initializes the registers
> >> correctly, while on GXBB and newer this is done by the firmware.
> >> Thus the changes from this series are only relevant for Meson8 and
> >> Meson8b.
> >> 
> >> The first two patches are bugfixes:
> >> - the first patch fixes an issue where the SAR ADC would not work at
> >>   all
> >> - the second patch initializes the bandgrap register on Meson8 and
> >>   Meson8b (which is required for the SAR ADC to operate)
> >> 
> >> The third patch is mainly a cosmetic fix because we don't want to
> >> read/write registers that are not documented.
> >> 
> >> Patch four is purely cosmetic so the mainline driver uses the same
> >> settings as Amlogic's vendor kernel driver.
> >> 
> >> The last patch initializes the channel muxes. There are sane defaults
> >> for these in the hardware itself. However, some bootloaders are
> >> setting strange values - the result is that reading the ADC gives
> >> garbage values.
> >> I did not tag this as "fix" since in my opinion it's a feature for
> >> fixing broken bootloaders.
> >> 
> >> Tested on:
> >> - a Meson8m2 board (compatible with Meson8)
> >> - a Meson8b EC-100
> >> - on a Khadas VIM to ensure that the newer SoCs are still working
> >> 
> >> 
> >> Martin Blumenstingl (5):
> >>   iio: adc: meson-saradc: fix the bit_idx of the adc_en clock
> >>   iio: adc: meson-saradc: initialize the bandgap correctly on older
> >> SoCs iio: adc: meson-saradc: Meson8 and Meson8b do not have REG11 and
> >> REG13 iio: adc: meson-saradc: fix the clock frequency on Meson8 and
> >> Meson8b iio: adc: meson-saradc: program the channel muxes during
> >>     initialization
> >> 
> >>  drivers/iio/adc/meson_saradc.c | 92
> >> +++++++++++++++++++++++++++++++++++------- 1 file changed, 78
> >> insertions(+), 14 deletions(-)
> >>   
> > Series seems fine to me.  If no one else raises anything I'll pick this
> > up when I'm am back in the UK the week after next.  
> 
> Just a gentle ping on the status of this series as I'm not seeing it in
> linux-next.

Sure, I'll be sending out a pull request including the first couple
of patches later today at which time they'll hit Greg's tree and show
up in linux-next. (patches 1, 2 and 3)

The series was a spit of fixes and improvements that will take longer
as we'll have to wait for the fixes to go up to mainline and come
back to me - so will be a few weeks before I can apply those and they
won't hit linux-next for perhaps a week after that.
(this covers patches 4 and 5)

Jonathan

> 
> Thanks,
> 
> Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] meson_saradc fixes and minor improvements

[Martin Blumenstingl]

Hi Jonathan,

On Sat, Dec 2, 2017 at 12:30 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> On Mon, 27 Nov 2017 15:47:14 -0800
> Kevin Hilman <khilman@baylibre.com> wrote:
>
>> Hi Jonathan,
>>
>> Jonathan Cameron <Jonathan.Cameron@huawei.com> writes:
>>
>> > On Tue, 31 Oct 2017 21:01:42 +0100
>> > Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
>> >
>> >> Meson8 and Meson8b require that the driver initializes the registers
>> >> correctly, while on GXBB and newer this is done by the firmware.
>> >> Thus the changes from this series are only relevant for Meson8 and
>> >> Meson8b.
>> >>
>> >> The first two patches are bugfixes:
>> >> - the first patch fixes an issue where the SAR ADC would not work at
>> >>   all
>> >> - the second patch initializes the bandgrap register on Meson8 and
>> >>   Meson8b (which is required for the SAR ADC to operate)
>> >>
>> >> The third patch is mainly a cosmetic fix because we don't want to
>> >> read/write registers that are not documented.
>> >>
>> >> Patch four is purely cosmetic so the mainline driver uses the same
>> >> settings as Amlogic's vendor kernel driver.
>> >>
>> >> The last patch initializes the channel muxes. There are sane defaults
>> >> for these in the hardware itself. However, some bootloaders are
>> >> setting strange values - the result is that reading the ADC gives
>> >> garbage values.
>> >> I did not tag this as "fix" since in my opinion it's a feature for
>> >> fixing broken bootloaders.
>> >>
>> >> Tested on:
>> >> - a Meson8m2 board (compatible with Meson8)
>> >> - a Meson8b EC-100
>> >> - on a Khadas VIM to ensure that the newer SoCs are still working
>> >>
>> >>
>> >> Martin Blumenstingl (5):
>> >>   iio: adc: meson-saradc: fix the bit_idx of the adc_en clock
>> >>   iio: adc: meson-saradc: initialize the bandgap correctly on older
>> >> SoCs iio: adc: meson-saradc: Meson8 and Meson8b do not have REG11 and
>> >> REG13 iio: adc: meson-saradc: fix the clock frequency on Meson8 and
>> >> Meson8b iio: adc: meson-saradc: program the channel muxes during
>> >>     initialization
>> >>
>> >>  drivers/iio/adc/meson_saradc.c | 92
>> >> +++++++++++++++++++++++++++++++++++------- 1 file changed, 78
>> >> insertions(+), 14 deletions(-)
>> >>
>> > Series seems fine to me.  If no one else raises anything I'll pick this
>> > up when I'm am back in the UK the week after next.
>>
>> Just a gentle ping on the status of this series as I'm not seeing it in
>> linux-next.
>
> Sure, I'll be sending out a pull request including the first couple
> of patches later today at which time they'll hit Greg's tree and show
> up in linux-next. (patches 1, 2 and 3)
>
> The series was a spit of fixes and improvements that will take longer
> as we'll have to wait for the fixes to go up to mainline and come
> back to me - so will be a few weeks before I can apply those and they
> won't hit linux-next for perhaps a week after that.
> (this covers patches 4 and 5)
do you want me to re-send patches 4 and 5 (or do you want to take them
as they are) now that patches 0-3 are back in linux-next?


Regards
Martin

Re: [PATCH 0/5] meson_saradc fixes and minor improvements

[Jonathan Cameron]

On Sun, 10 Dec 2017 18:48:56 +0100
Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:

> Hi Jonathan,
> 
> On Sat, Dec 2, 2017 at 12:30 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> > On Mon, 27 Nov 2017 15:47:14 -0800
> > Kevin Hilman <khilman@baylibre.com> wrote:
> >  
> >> Hi Jonathan,
> >>
> >> Jonathan Cameron <Jonathan.Cameron@huawei.com> writes:
> >>  
> >> > On Tue, 31 Oct 2017 21:01:42 +0100
> >> > Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
> >> >  
> >> >> Meson8 and Meson8b require that the driver initializes the registers
> >> >> correctly, while on GXBB and newer this is done by the firmware.
> >> >> Thus the changes from this series are only relevant for Meson8 and
> >> >> Meson8b.
> >> >>
> >> >> The first two patches are bugfixes:
> >> >> - the first patch fixes an issue where the SAR ADC would not work at
> >> >>   all
> >> >> - the second patch initializes the bandgrap register on Meson8 and
> >> >>   Meson8b (which is required for the SAR ADC to operate)
> >> >>
> >> >> The third patch is mainly a cosmetic fix because we don't want to
> >> >> read/write registers that are not documented.
> >> >>
> >> >> Patch four is purely cosmetic so the mainline driver uses the same
> >> >> settings as Amlogic's vendor kernel driver.
> >> >>
> >> >> The last patch initializes the channel muxes. There are sane defaults
> >> >> for these in the hardware itself. However, some bootloaders are
> >> >> setting strange values - the result is that reading the ADC gives
> >> >> garbage values.
> >> >> I did not tag this as "fix" since in my opinion it's a feature for
> >> >> fixing broken bootloaders.
> >> >>
> >> >> Tested on:
> >> >> - a Meson8m2 board (compatible with Meson8)
> >> >> - a Meson8b EC-100
> >> >> - on a Khadas VIM to ensure that the newer SoCs are still working
> >> >>
> >> >>
> >> >> Martin Blumenstingl (5):
> >> >>   iio: adc: meson-saradc: fix the bit_idx of the adc_en clock
> >> >>   iio: adc: meson-saradc: initialize the bandgap correctly on older
> >> >> SoCs iio: adc: meson-saradc: Meson8 and Meson8b do not have REG11 and
> >> >> REG13 iio: adc: meson-saradc: fix the clock frequency on Meson8 and
> >> >> Meson8b iio: adc: meson-saradc: program the channel muxes during
> >> >>     initialization
> >> >>
> >> >>  drivers/iio/adc/meson_saradc.c | 92
> >> >> +++++++++++++++++++++++++++++++++++------- 1 file changed, 78
> >> >> insertions(+), 14 deletions(-)
> >> >>  
> >> > Series seems fine to me.  If no one else raises anything I'll pick this
> >> > up when I'm am back in the UK the week after next.  
> >>
> >> Just a gentle ping on the status of this series as I'm not seeing it in
> >> linux-next.  
> >
> > Sure, I'll be sending out a pull request including the first couple
> > of patches later today at which time they'll hit Greg's tree and show
> > up in linux-next. (patches 1, 2 and 3)
> >
> > The series was a spit of fixes and improvements that will take longer
> > as we'll have to wait for the fixes to go up to mainline and come
> > back to me - so will be a few weeks before I can apply those and they
> > won't hit linux-next for perhaps a week after that.
> > (this covers patches 4 and 5)  
> do you want me to re-send patches 4 and 5 (or do you want to take them
> as they are) now that patches 0-3 are back in linux-next?
I got them from this thread.  Now applied.  Thanks for pointing out
I could now do this.  I'd failed to notice / check yet!

Jonathan

> 
> 
> Regards
> Martin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] meson_saradc fixes and minor improvements

[Martin Blumenstingl]

On Sun, Dec 10, 2017 at 8:50 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> On Sun, 10 Dec 2017 18:48:56 +0100
> Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
>
>> Hi Jonathan,
>>
>> On Sat, Dec 2, 2017 at 12:30 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>> > On Mon, 27 Nov 2017 15:47:14 -0800
>> > Kevin Hilman <khilman@baylibre.com> wrote:
>> >
>> >> Hi Jonathan,
>> >>
>> >> Jonathan Cameron <Jonathan.Cameron@huawei.com> writes:
>> >>
>> >> > On Tue, 31 Oct 2017 21:01:42 +0100
>> >> > Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
>> >> >
>> >> >> Meson8 and Meson8b require that the driver initializes the registers
>> >> >> correctly, while on GXBB and newer this is done by the firmware.
>> >> >> Thus the changes from this series are only relevant for Meson8 and
>> >> >> Meson8b.
>> >> >>
>> >> >> The first two patches are bugfixes:
>> >> >> - the first patch fixes an issue where the SAR ADC would not work at
>> >> >>   all
>> >> >> - the second patch initializes the bandgrap register on Meson8 and
>> >> >>   Meson8b (which is required for the SAR ADC to operate)
>> >> >>
>> >> >> The third patch is mainly a cosmetic fix because we don't want to
>> >> >> read/write registers that are not documented.
>> >> >>
>> >> >> Patch four is purely cosmetic so the mainline driver uses the same
>> >> >> settings as Amlogic's vendor kernel driver.
>> >> >>
>> >> >> The last patch initializes the channel muxes. There are sane defaults
>> >> >> for these in the hardware itself. However, some bootloaders are
>> >> >> setting strange values - the result is that reading the ADC gives
>> >> >> garbage values.
>> >> >> I did not tag this as "fix" since in my opinion it's a feature for
>> >> >> fixing broken bootloaders.
>> >> >>
>> >> >> Tested on:
>> >> >> - a Meson8m2 board (compatible with Meson8)
>> >> >> - a Meson8b EC-100
>> >> >> - on a Khadas VIM to ensure that the newer SoCs are still working
>> >> >>
>> >> >>
>> >> >> Martin Blumenstingl (5):
>> >> >>   iio: adc: meson-saradc: fix the bit_idx of the adc_en clock
>> >> >>   iio: adc: meson-saradc: initialize the bandgap correctly on older
>> >> >> SoCs iio: adc: meson-saradc: Meson8 and Meson8b do not have REG11 and
>> >> >> REG13 iio: adc: meson-saradc: fix the clock frequency on Meson8 and
>> >> >> Meson8b iio: adc: meson-saradc: program the channel muxes during
>> >> >>     initialization
>> >> >>
>> >> >>  drivers/iio/adc/meson_saradc.c | 92
>> >> >> +++++++++++++++++++++++++++++++++++------- 1 file changed, 78
>> >> >> insertions(+), 14 deletions(-)
>> >> >>
>> >> > Series seems fine to me.  If no one else raises anything I'll pick this
>> >> > up when I'm am back in the UK the week after next.
>> >>
>> >> Just a gentle ping on the status of this series as I'm not seeing it in
>> >> linux-next.
>> >
>> > Sure, I'll be sending out a pull request including the first couple
>> > of patches later today at which time they'll hit Greg's tree and show
>> > up in linux-next. (patches 1, 2 and 3)
>> >
>> > The series was a spit of fixes and improvements that will take longer
>> > as we'll have to wait for the fixes to go up to mainline and come
>> > back to me - so will be a few weeks before I can apply those and they
>> > won't hit linux-next for perhaps a week after that.
>> > (this covers patches 4 and 5)
>> do you want me to re-send patches 4 and 5 (or do you want to take them
>> as they are) now that patches 0-3 are back in linux-next?
> I got them from this thread.  Now applied.  Thanks for pointing out
> I could now do this.  I'd failed to notice / check yet!
perfect - thank you!


Martin