meson_saradc fixes and minor improvements

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 <[email protected]>

---
 drivers/iio/adc/meson_saradc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/iio/adc/meson_saradc.c +1 -1

index 2e8dbb89c8c9..55611244c799 100644
@@ -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);

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 <[email protected]>

---
 drivers/iio/adc/meson_saradc.c | 33 ++++++++++++++++++++++++++-------
 1 file changed, 26 insertions(+), 7 deletions(-)

drivers/iio/adc/meson_saradc.c +26 -7

index 55611244c799..abe9df879b2a 100644
@@ -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",
 };

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 <[email protected]>

---
 drivers/iio/adc/meson_saradc.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

drivers/iio/adc/meson_saradc.c +15 -2

index abe9df879b2a..7dc7d297a0fc 100644
@@ -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);
 

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 <[email protected]>

---
 drivers/iio/adc/meson_saradc.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

drivers/iio/adc/meson_saradc.c +7 -1

index 7dc7d297a0fc..fa3c1378c2c9 100644
@@ -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,

Quoted 13 lines · On Tue, 31 Oct 2017 21:01:46 +0100 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).

Quoted 1 line

Signed-off-by Martin Blumenstingl <[email protected]>

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

Quoted 58 lines

---
 drivers/iio/adc/meson_saradc.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

drivers/iio/adc/meson_saradc.c +6 -1

index 7dc7d297a0fc..fa3c1378c2c9 100644
@@ -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,

drivers/iio/adc/meson_saradc.c static const struct meson_sar_adc_data meson_sar_adc_gxl_data = { · line 910

Quoted 7 lines

drivers/iio/adc/meson_saradc.c +1 -0

@@ -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 at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

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 <[email protected]>

---
 drivers/iio/adc/meson_saradc.c | 32 +++++++++++++++++++++++++++++---
 1 file changed, 29 insertions(+), 3 deletions(-)

drivers/iio/adc/meson_saradc.c +29 -3

index fa3c1378c2c9..48fb1b642a5e 100644
@@ -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,

Quoted 15 lines · On Tue, 31 Oct 2017 21:01:47 +0100 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.

Quoted 1 line

Signed-off-by Martin Blumenstingl <[email protected]>

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

Quoted 51 lines

---
 drivers/iio/adc/meson_saradc.c | 32 +++++++++++++++++++++++++++++---
 1 file changed, 29 insertions(+), 3 deletions(-)

drivers/iio/adc/meson_saradc.c +22 -3

index fa3c1378c2c9..48fb1b642a5e 100644
@@ -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.
+	 */

drivers/iio/adc/meson_saradc.c static int meson_sar_adc_init(struct iio_dev *indio_dev) · line 709

Quoted 10 lines

drivers/iio/adc/meson_saradc.c +7 -0

+	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 at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

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(-)

Quoted 38 lines · On Tue, 31 Oct 2017 21:01:42 +0100 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

Quoted 4 lines

 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.

Hi Jonathan,

Quoted 45 lines · Jonathan Cameron

Quoted 42 lines · On Tue, 31 Oct 2017 21:01:42 +0100 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(-)

Quoted 2 lines

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
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 49 lines · On Mon, 27 Nov 2017 15:47:14 -0800 Kevin Hilman <[email protected]> wrote:

Hi Jonathan,

Quoted 45 lines · Jonathan Cameron

Quoted 42 lines · On Tue, 31 Oct 2017 21:01:42 +0100 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(-)

Quoted 5 lines

Quoted 2 lines

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)

Hi Jonathan,

Quoted 62 lines · Jonathan Cameron

Quoted 49 lines · On Mon, 27 Nov 2017 15:47:14 -0800 Kevin Hilman <[email protected]> wrote:

Hi Jonathan,

Quoted 45 lines · Jonathan Cameron

Quoted 42 lines · On Tue, 31 Oct 2017 21:01:42 +0100 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(-)

Quoted 5 lines

Quoted 2 lines

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)

Quoted 5 lines

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
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 70 lines · On Sun, 10 Dec 2017 18:48:56 +0100 Martin Blumenstingl…

Hi Jonathan,

Quoted 67 lines · Jonathan Cameron

Quoted 49 lines · On Mon, 27 Nov 2017 15:47:14 -0800 Kevin Hilman <[email protected]> wrote:

Hi Jonathan,

Quoted 45 lines · Jonathan Cameron

Quoted 42 lines · On Tue, 31 Oct 2017 21:01:42 +0100 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(-)

Quoted 5 lines

Quoted 2 lines

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)

Quoted 2 lines

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!