[PATCH 0/2] Meson8b support for the meson_saradc driver

[PATCH 0/2] Meson8b support for the meson_saradc driver

[Martin Blumenstingl]

The SAR ADC register layout seems to be mostly the same on older SoCs.
Thus basically all functionality is already supported by the existing
driver.

There are two small differences though:
- the adc_clk and adc_div clock are not provided by the clock-controller
  on Meson8b. instead the SAR ADC provides an internal "adc_clk" (this
  behavior is already supported by the driver and requires no changes)
- the newer SoCs are using some register bits only the kernel or the
  BL30 (bootloader) are using the SAR ADC. This is the main change of
  this series: guarding all BL30 specific code with a corresponding
  "if"-block.

This also adds a new DT binding for the SAR ADC in Meson8b because the
driver has to specify (for this older version) that there's no BL30
integration available (and these register bits should not be touched).


Martin Blumenstingl (2):
  Documentation: dt-bindings: add a Meson8b compatible to the SAR ADC
  iio: adc: meson-saradc: add Meson8b SoC compatibility

 .../bindings/iio/adc/amlogic,meson-saradc.txt      |  1 +
 drivers/iio/adc/meson_saradc.c                     | 70 ++++++++++++++--------
 2 files changed, 47 insertions(+), 24 deletions(-)

-- 
2.12.1

[PATCH 0/2] Meson8b support for the meson_saradc driver

[Martin Blumenstingl]

The SAR ADC register layout seems to be mostly the same on older SoCs.
Thus basically all functionality is already supported by the existing
driver.

There are two small differences though:
- the adc_clk and adc_div clock are not provided by the clock-controller
  on Meson8b. instead the SAR ADC provides an internal "adc_clk" (this
  behavior is already supported by the driver and requires no changes)
- the newer SoCs are using some register bits only the kernel or the
  BL30 (bootloader) are using the SAR ADC. This is the main change of
  this series: guarding all BL30 specific code with a corresponding
  "if"-block.

This also adds a new DT binding for the SAR ADC in Meson8b because the
driver has to specify (for this older version) that there's no BL30
integration available (and these register bits should not be touched).


Martin Blumenstingl (2):
  Documentation: dt-bindings: add a Meson8b compatible to the SAR ADC
  iio: adc: meson-saradc: add Meson8b SoC compatibility

 .../bindings/iio/adc/amlogic,meson-saradc.txt      |  1 +
 drivers/iio/adc/meson_saradc.c                     | 70 ++++++++++++++--------
 2 files changed, 47 insertions(+), 24 deletions(-)

-- 
2.12.1

[PATCH 0/2] Meson8b support for the meson_saradc driver

[Martin Blumenstingl]

The SAR ADC register layout seems to be mostly the same on older SoCs.
Thus basically all functionality is already supported by the existing
driver.

There are two small differences though:
- the adc_clk and adc_div clock are not provided by the clock-controller
  on Meson8b. instead the SAR ADC provides an internal "adc_clk" (this
  behavior is already supported by the driver and requires no changes)
- the newer SoCs are using some register bits only the kernel or the
  BL30 (bootloader) are using the SAR ADC. This is the main change of
  this series: guarding all BL30 specific code with a corresponding
  "if"-block.

This also adds a new DT binding for the SAR ADC in Meson8b because the
driver has to specify (for this older version) that there's no BL30
integration available (and these register bits should not be touched).


Martin Blumenstingl (2):
  Documentation: dt-bindings: add a Meson8b compatible to the SAR ADC
  iio: adc: meson-saradc: add Meson8b SoC compatibility

 .../bindings/iio/adc/amlogic,meson-saradc.txt      |  1 +
 drivers/iio/adc/meson_saradc.c                     | 70 ++++++++++++++--------
 2 files changed, 47 insertions(+), 24 deletions(-)

-- 
2.12.1

[PATCH 0/2] Meson8b support for the meson_saradc driver

[Martin Blumenstingl]

The SAR ADC register layout seems to be mostly the same on older SoCs.
Thus basically all functionality is already supported by the existing
driver.

There are two small differences though:
- the adc_clk and adc_div clock are not provided by the clock-controller
  on Meson8b. instead the SAR ADC provides an internal "adc_clk" (this
  behavior is already supported by the driver and requires no changes)
- the newer SoCs are using some register bits only the kernel or the
  BL30 (bootloader) are using the SAR ADC. This is the main change of
  this series: guarding all BL30 specific code with a corresponding
  "if"-block.

This also adds a new DT binding for the SAR ADC in Meson8b because the
driver has to specify (for this older version) that there's no BL30
integration available (and these register bits should not be touched).


Martin Blumenstingl (2):
  Documentation: dt-bindings: add a Meson8b compatible to the SAR ADC
  iio: adc: meson-saradc: add Meson8b SoC compatibility

 .../bindings/iio/adc/amlogic,meson-saradc.txt      |  1 +
 drivers/iio/adc/meson_saradc.c                     | 70 ++++++++++++++--------
 2 files changed, 47 insertions(+), 24 deletions(-)

-- 
2.12.1

[PATCH 1/2] Documentation: dt-bindings: add a Meson8b compatible to the SAR ADC

[Martin Blumenstingl]

The Amlogic Meson SAR ADC driver can be used on Meson8b as well
(probably on earlier SoC generations as well, but I don't have any
hardware available for testing that).
Add a separate compatible for Meson8b because it does not need any of
the BL30 magic (unlike the GX SoCs).

Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
 Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
index f9e3ff2c656e..84a931a0ff1f 100644
--- a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
@@ -2,6 +2,7 @@
 
 Required properties:
 - compatible:	depending on the SoC this should be one of:
+			- "amlogic,meson8b-saradc" for Meson8b
 			- "amlogic,meson-gxbb-saradc" for GXBB
 			- "amlogic,meson-gxl-saradc" for GXL
 			- "amlogic,meson-gxm-saradc" for GXM
-- 
2.12.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] Documentation: dt-bindings: add a Meson8b compatible to the SAR ADC

[Martin Blumenstingl]

The Amlogic Meson SAR ADC driver can be used on Meson8b as well
(probably on earlier SoC generations as well, but I don't have any
hardware available for testing that).
Add a separate compatible for Meson8b because it does not need any of
the BL30 magic (unlike the GX SoCs).

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
 Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
index f9e3ff2c656e..84a931a0ff1f 100644
--- a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
@@ -2,6 +2,7 @@
 
 Required properties:
 - compatible:	depending on the SoC this should be one of:
+			- "amlogic,meson8b-saradc" for Meson8b
 			- "amlogic,meson-gxbb-saradc" for GXBB
 			- "amlogic,meson-gxl-saradc" for GXL
 			- "amlogic,meson-gxm-saradc" for GXM
-- 
2.12.1

[PATCH 1/2] Documentation: dt-bindings: add a Meson8b compatible to the SAR ADC

[Martin Blumenstingl]

The Amlogic Meson SAR ADC driver can be used on Meson8b as well
(probably on earlier SoC generations as well, but I don't have any
hardware available for testing that).
Add a separate compatible for Meson8b because it does not need any of
the BL30 magic (unlike the GX SoCs).

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
 Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
index f9e3ff2c656e..84a931a0ff1f 100644
--- a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
@@ -2,6 +2,7 @@
 
 Required properties:
 - compatible:	depending on the SoC this should be one of:
+			- "amlogic,meson8b-saradc" for Meson8b
 			- "amlogic,meson-gxbb-saradc" for GXBB
 			- "amlogic,meson-gxl-saradc" for GXL
 			- "amlogic,meson-gxm-saradc" for GXM
-- 
2.12.1

[PATCH 1/2] Documentation: dt-bindings: add a Meson8b compatible to the SAR ADC

[Martin Blumenstingl]

The Amlogic Meson SAR ADC driver can be used on Meson8b as well
(probably on earlier SoC generations as well, but I don't have any
hardware available for testing that).
Add a separate compatible for Meson8b because it does not need any of
the BL30 magic (unlike the GX SoCs).

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
 Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
index f9e3ff2c656e..84a931a0ff1f 100644
--- a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
@@ -2,6 +2,7 @@
 
 Required properties:
 - compatible:	depending on the SoC this should be one of:
+			- "amlogic,meson8b-saradc" for Meson8b
 			- "amlogic,meson-gxbb-saradc" for GXBB
 			- "amlogic,meson-gxl-saradc" for GXL
 			- "amlogic,meson-gxm-saradc" for GXM
-- 
2.12.1

[PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Martin Blumenstingl]

Meson GX SoCs however use some magic bits to prevent simultaneous (=
conflicting, because only consumer should use the FIFO buffer with the
ADC results) usage by the Linux kernel and the bootloader (the BL30
bootloader uses the SAR ADC to read the CPU temperature).
This patch changes guards all BL30 functionality so it is skipped on
SoCs which don't have it. Since the hardware itself doesn't know whether
BL30 is available the internal meson_sar_adc_data is extended so this
information can be provided per of_device_id.data inside the driver.

Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
clock-controller itself. "adc_sel" is not available at all. "adc_clk"
is provided by the SAR ADC IP block itself on Meson8b (and earlier).
This is already supported by the meson_saradc driver.

Finally a new of_device_id for the Meson8b SoC is added so it can be
wired up in the corresponding DT.

Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
 drivers/iio/adc/meson_saradc.c | 70 +++++++++++++++++++++++++++---------------
 1 file changed, 46 insertions(+), 24 deletions(-)

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index dd4190b50df6..f78fe66e0ec8 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -220,6 +220,7 @@ enum meson_sar_adc_chan7_mux_sel {
 };
 
 struct meson_sar_adc_data {
+	char					has_bl30_integration;
 	unsigned int				resolution;
 	const char				*name;
 };
@@ -437,19 +438,24 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
 
 	mutex_lock(&indio_dev->mlock);
 
-	/* prevent BL30 from using the SAR ADC while we are using it */
-	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
-			   MESON_SAR_ADC_DELAY_KERNEL_BUSY,
-			   MESON_SAR_ADC_DELAY_KERNEL_BUSY);
-
-	/* wait until BL30 releases it's lock (so we can use the SAR ADC) */
-	do {
-		udelay(1);
-		regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
-	} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
-
-	if (timeout < 0)
-		return -ETIMEDOUT;
+	if (priv->data->has_bl30_integration) {
+		/* prevent BL30 from using the SAR ADC while we are using it */
+		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
+				MESON_SAR_ADC_DELAY_KERNEL_BUSY,
+				MESON_SAR_ADC_DELAY_KERNEL_BUSY);
+
+		/*
+		 * wait until BL30 releases it's lock (so we can use the SAR
+		 * ADC)
+		 */
+		do {
+			udelay(1);
+			regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
+		} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
+
+		if (timeout < 0)
+			return -ETIMEDOUT;
+	}
 
 	return 0;
 }
@@ -458,9 +464,10 @@ static void meson_sar_adc_unlock(struct iio_dev *indio_dev)
 {
 	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
 
-	/* allow BL30 to use the SAR ADC again */
-	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
-			   MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
+	if (priv->data->has_bl30_integration)
+		/* allow BL30 to use the SAR ADC again */
+		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
+				MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
 
 	mutex_unlock(&indio_dev->mlock);
 }
@@ -614,14 +621,16 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
 	 */
 	meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
 
-	/*
-	 * leave sampling delay and the input clocks as configured by BL30 to
-	 * make sure BL30 gets the values it expects when reading the
-	 * temperature sensor.
-	 */
-	regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
-	if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
-		return 0;
+	if (priv->data->has_bl30_integration) {
+		/*
+		 * leave sampling delay and the input clocks as configured by
+		 * BL30 to make sure BL30 gets the values it expects when
+		 * reading the temperature sensor.
+		 */
+		regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
+		if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
+			return 0;
+	}
 
 	meson_sar_adc_stop_sample_engine(indio_dev);
 
@@ -834,23 +843,36 @@ static const struct iio_info meson_sar_adc_iio_info = {
 	.driver_module = THIS_MODULE,
 };
 
+struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
+	.has_bl30_integration = 0,
+	.resolution = 10,
+	.name = "meson-meson8b-saradc",
+};
+
 struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
+	.has_bl30_integration = 1,
 	.resolution = 10,
 	.name = "meson-gxbb-saradc",
 };
 
 struct meson_sar_adc_data meson_sar_adc_gxl_data = {
+	.has_bl30_integration = 1,
 	.resolution = 12,
 	.name = "meson-gxl-saradc",
 };
 
 struct meson_sar_adc_data meson_sar_adc_gxm_data = {
+	.has_bl30_integration = 1,
 	.resolution = 12,
 	.name = "meson-gxm-saradc",
 };
 
 static const struct of_device_id meson_sar_adc_of_match[] = {
 	{
+		.compatible = "amlogic,meson8b-saradc",
+		.data = &meson_sar_adc_meson8b_data,
+	},
+	{
 		.compatible = "amlogic,meson-gxbb-saradc",
 		.data = &meson_sar_adc_gxbb_data,
 	}, {
-- 
2.12.1

[PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Martin Blumenstingl]

Meson GX SoCs however use some magic bits to prevent simultaneous (=
conflicting, because only consumer should use the FIFO buffer with the
ADC results) usage by the Linux kernel and the bootloader (the BL30
bootloader uses the SAR ADC to read the CPU temperature).
This patch changes guards all BL30 functionality so it is skipped on
SoCs which don't have it. Since the hardware itself doesn't know whether
BL30 is available the internal meson_sar_adc_data is extended so this
information can be provided per of_device_id.data inside the driver.

Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
clock-controller itself. "adc_sel" is not available at all. "adc_clk"
is provided by the SAR ADC IP block itself on Meson8b (and earlier).
This is already supported by the meson_saradc driver.

Finally a new of_device_id for the Meson8b SoC is added so it can be
wired up in the corresponding DT.

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

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index dd4190b50df6..f78fe66e0ec8 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -220,6 +220,7 @@ enum meson_sar_adc_chan7_mux_sel {
 };
 
 struct meson_sar_adc_data {
+	char					has_bl30_integration;
 	unsigned int				resolution;
 	const char				*name;
 };
@@ -437,19 +438,24 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
 
 	mutex_lock(&indio_dev->mlock);
 
-	/* prevent BL30 from using the SAR ADC while we are using it */
-	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
-			   MESON_SAR_ADC_DELAY_KERNEL_BUSY,
-			   MESON_SAR_ADC_DELAY_KERNEL_BUSY);
-
-	/* wait until BL30 releases it's lock (so we can use the SAR ADC) */
-	do {
-		udelay(1);
-		regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
-	} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
-
-	if (timeout < 0)
-		return -ETIMEDOUT;
+	if (priv->data->has_bl30_integration) {
+		/* prevent BL30 from using the SAR ADC while we are using it */
+		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
+				MESON_SAR_ADC_DELAY_KERNEL_BUSY,
+				MESON_SAR_ADC_DELAY_KERNEL_BUSY);
+
+		/*
+		 * wait until BL30 releases it's lock (so we can use the SAR
+		 * ADC)
+		 */
+		do {
+			udelay(1);
+			regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
+		} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
+
+		if (timeout < 0)
+			return -ETIMEDOUT;
+	}
 
 	return 0;
 }
@@ -458,9 +464,10 @@ static void meson_sar_adc_unlock(struct iio_dev *indio_dev)
 {
 	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
 
-	/* allow BL30 to use the SAR ADC again */
-	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
-			   MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
+	if (priv->data->has_bl30_integration)
+		/* allow BL30 to use the SAR ADC again */
+		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
+				MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
 
 	mutex_unlock(&indio_dev->mlock);
 }
@@ -614,14 +621,16 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
 	 */
 	meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
 
-	/*
-	 * leave sampling delay and the input clocks as configured by BL30 to
-	 * make sure BL30 gets the values it expects when reading the
-	 * temperature sensor.
-	 */
-	regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
-	if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
-		return 0;
+	if (priv->data->has_bl30_integration) {
+		/*
+		 * leave sampling delay and the input clocks as configured by
+		 * BL30 to make sure BL30 gets the values it expects when
+		 * reading the temperature sensor.
+		 */
+		regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
+		if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
+			return 0;
+	}
 
 	meson_sar_adc_stop_sample_engine(indio_dev);
 
@@ -834,23 +843,36 @@ static const struct iio_info meson_sar_adc_iio_info = {
 	.driver_module = THIS_MODULE,
 };
 
+struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
+	.has_bl30_integration = 0,
+	.resolution = 10,
+	.name = "meson-meson8b-saradc",
+};
+
 struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
+	.has_bl30_integration = 1,
 	.resolution = 10,
 	.name = "meson-gxbb-saradc",
 };
 
 struct meson_sar_adc_data meson_sar_adc_gxl_data = {
+	.has_bl30_integration = 1,
 	.resolution = 12,
 	.name = "meson-gxl-saradc",
 };
 
 struct meson_sar_adc_data meson_sar_adc_gxm_data = {
+	.has_bl30_integration = 1,
 	.resolution = 12,
 	.name = "meson-gxm-saradc",
 };
 
 static const struct of_device_id meson_sar_adc_of_match[] = {
 	{
+		.compatible = "amlogic,meson8b-saradc",
+		.data = &meson_sar_adc_meson8b_data,
+	},
+	{
 		.compatible = "amlogic,meson-gxbb-saradc",
 		.data = &meson_sar_adc_gxbb_data,
 	}, {
-- 
2.12.1

[PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Martin Blumenstingl]

Meson GX SoCs however use some magic bits to prevent simultaneous (=
conflicting, because only consumer should use the FIFO buffer with the
ADC results) usage by the Linux kernel and the bootloader (the BL30
bootloader uses the SAR ADC to read the CPU temperature).
This patch changes guards all BL30 functionality so it is skipped on
SoCs which don't have it. Since the hardware itself doesn't know whether
BL30 is available the internal meson_sar_adc_data is extended so this
information can be provided per of_device_id.data inside the driver.

Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
clock-controller itself. "adc_sel" is not available at all. "adc_clk"
is provided by the SAR ADC IP block itself on Meson8b (and earlier).
This is already supported by the meson_saradc driver.

Finally a new of_device_id for the Meson8b SoC is added so it can be
wired up in the corresponding DT.

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

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index dd4190b50df6..f78fe66e0ec8 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -220,6 +220,7 @@ enum meson_sar_adc_chan7_mux_sel {
 };
 
 struct meson_sar_adc_data {
+	char					has_bl30_integration;
 	unsigned int				resolution;
 	const char				*name;
 };
@@ -437,19 +438,24 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
 
 	mutex_lock(&indio_dev->mlock);
 
-	/* prevent BL30 from using the SAR ADC while we are using it */
-	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
-			   MESON_SAR_ADC_DELAY_KERNEL_BUSY,
-			   MESON_SAR_ADC_DELAY_KERNEL_BUSY);
-
-	/* wait until BL30 releases it's lock (so we can use the SAR ADC) */
-	do {
-		udelay(1);
-		regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
-	} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
-
-	if (timeout < 0)
-		return -ETIMEDOUT;
+	if (priv->data->has_bl30_integration) {
+		/* prevent BL30 from using the SAR ADC while we are using it */
+		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
+				MESON_SAR_ADC_DELAY_KERNEL_BUSY,
+				MESON_SAR_ADC_DELAY_KERNEL_BUSY);
+
+		/*
+		 * wait until BL30 releases it's lock (so we can use the SAR
+		 * ADC)
+		 */
+		do {
+			udelay(1);
+			regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
+		} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
+
+		if (timeout < 0)
+			return -ETIMEDOUT;
+	}
 
 	return 0;
 }
@@ -458,9 +464,10 @@ static void meson_sar_adc_unlock(struct iio_dev *indio_dev)
 {
 	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
 
-	/* allow BL30 to use the SAR ADC again */
-	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
-			   MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
+	if (priv->data->has_bl30_integration)
+		/* allow BL30 to use the SAR ADC again */
+		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
+				MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
 
 	mutex_unlock(&indio_dev->mlock);
 }
@@ -614,14 +621,16 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
 	 */
 	meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
 
-	/*
-	 * leave sampling delay and the input clocks as configured by BL30 to
-	 * make sure BL30 gets the values it expects when reading the
-	 * temperature sensor.
-	 */
-	regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
-	if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
-		return 0;
+	if (priv->data->has_bl30_integration) {
+		/*
+		 * leave sampling delay and the input clocks as configured by
+		 * BL30 to make sure BL30 gets the values it expects when
+		 * reading the temperature sensor.
+		 */
+		regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
+		if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
+			return 0;
+	}
 
 	meson_sar_adc_stop_sample_engine(indio_dev);
 
@@ -834,23 +843,36 @@ static const struct iio_info meson_sar_adc_iio_info = {
 	.driver_module = THIS_MODULE,
 };
 
+struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
+	.has_bl30_integration = 0,
+	.resolution = 10,
+	.name = "meson-meson8b-saradc",
+};
+
 struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
+	.has_bl30_integration = 1,
 	.resolution = 10,
 	.name = "meson-gxbb-saradc",
 };
 
 struct meson_sar_adc_data meson_sar_adc_gxl_data = {
+	.has_bl30_integration = 1,
 	.resolution = 12,
 	.name = "meson-gxl-saradc",
 };
 
 struct meson_sar_adc_data meson_sar_adc_gxm_data = {
+	.has_bl30_integration = 1,
 	.resolution = 12,
 	.name = "meson-gxm-saradc",
 };
 
 static const struct of_device_id meson_sar_adc_of_match[] = {
 	{
+		.compatible = "amlogic,meson8b-saradc",
+		.data = &meson_sar_adc_meson8b_data,
+	},
+	{
 		.compatible = "amlogic,meson-gxbb-saradc",
 		.data = &meson_sar_adc_gxbb_data,
 	}, {
-- 
2.12.1

[PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Martin Blumenstingl]

Meson GX SoCs however use some magic bits to prevent simultaneous (=
conflicting, because only consumer should use the FIFO buffer with the
ADC results) usage by the Linux kernel and the bootloader (the BL30
bootloader uses the SAR ADC to read the CPU temperature).
This patch changes guards all BL30 functionality so it is skipped on
SoCs which don't have it. Since the hardware itself doesn't know whether
BL30 is available the internal meson_sar_adc_data is extended so this
information can be provided per of_device_id.data inside the driver.

Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
clock-controller itself. "adc_sel" is not available at all. "adc_clk"
is provided by the SAR ADC IP block itself on Meson8b (and earlier).
This is already supported by the meson_saradc driver.

Finally a new of_device_id for the Meson8b SoC is added so it can be
wired up in the corresponding DT.

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

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index dd4190b50df6..f78fe66e0ec8 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -220,6 +220,7 @@ enum meson_sar_adc_chan7_mux_sel {
 };
 
 struct meson_sar_adc_data {
+	char					has_bl30_integration;
 	unsigned int				resolution;
 	const char				*name;
 };
@@ -437,19 +438,24 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
 
 	mutex_lock(&indio_dev->mlock);
 
-	/* prevent BL30 from using the SAR ADC while we are using it */
-	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
-			   MESON_SAR_ADC_DELAY_KERNEL_BUSY,
-			   MESON_SAR_ADC_DELAY_KERNEL_BUSY);
-
-	/* wait until BL30 releases it's lock (so we can use the SAR ADC) */
-	do {
-		udelay(1);
-		regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
-	} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
-
-	if (timeout < 0)
-		return -ETIMEDOUT;
+	if (priv->data->has_bl30_integration) {
+		/* prevent BL30 from using the SAR ADC while we are using it */
+		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
+				MESON_SAR_ADC_DELAY_KERNEL_BUSY,
+				MESON_SAR_ADC_DELAY_KERNEL_BUSY);
+
+		/*
+		 * wait until BL30 releases it's lock (so we can use the SAR
+		 * ADC)
+		 */
+		do {
+			udelay(1);
+			regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
+		} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
+
+		if (timeout < 0)
+			return -ETIMEDOUT;
+	}
 
 	return 0;
 }
@@ -458,9 +464,10 @@ static void meson_sar_adc_unlock(struct iio_dev *indio_dev)
 {
 	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
 
-	/* allow BL30 to use the SAR ADC again */
-	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
-			   MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
+	if (priv->data->has_bl30_integration)
+		/* allow BL30 to use the SAR ADC again */
+		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
+				MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
 
 	mutex_unlock(&indio_dev->mlock);
 }
@@ -614,14 +621,16 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
 	 */
 	meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
 
-	/*
-	 * leave sampling delay and the input clocks as configured by BL30 to
-	 * make sure BL30 gets the values it expects when reading the
-	 * temperature sensor.
-	 */
-	regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
-	if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
-		return 0;
+	if (priv->data->has_bl30_integration) {
+		/*
+		 * leave sampling delay and the input clocks as configured by
+		 * BL30 to make sure BL30 gets the values it expects when
+		 * reading the temperature sensor.
+		 */
+		regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
+		if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
+			return 0;
+	}
 
 	meson_sar_adc_stop_sample_engine(indio_dev);
 
@@ -834,23 +843,36 @@ static const struct iio_info meson_sar_adc_iio_info = {
 	.driver_module = THIS_MODULE,
 };
 
+struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
+	.has_bl30_integration = 0,
+	.resolution = 10,
+	.name = "meson-meson8b-saradc",
+};
+
 struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
+	.has_bl30_integration = 1,
 	.resolution = 10,
 	.name = "meson-gxbb-saradc",
 };
 
 struct meson_sar_adc_data meson_sar_adc_gxl_data = {
+	.has_bl30_integration = 1,
 	.resolution = 12,
 	.name = "meson-gxl-saradc",
 };
 
 struct meson_sar_adc_data meson_sar_adc_gxm_data = {
+	.has_bl30_integration = 1,
 	.resolution = 12,
 	.name = "meson-gxm-saradc",
 };
 
 static const struct of_device_id meson_sar_adc_of_match[] = {
 	{
+		.compatible = "amlogic,meson8b-saradc",
+		.data = &meson_sar_adc_meson8b_data,
+	},
+	{
 		.compatible = "amlogic,meson-gxbb-saradc",
 		.data = &meson_sar_adc_gxbb_data,
 	}, {
-- 
2.12.1

Re: [PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Peter Meerwald-Stadler]

On Sat, 25 Mar 2017, Martin Blumenstingl wrote:

nitpicking below

> Meson GX SoCs however use some magic bits to prevent simultaneous (=
> conflicting, because only consumer should use the FIFO buffer with the
> ADC results) usage by the Linux kernel and the bootloader (the BL30
> bootloader uses the SAR ADC to read the CPU temperature).
> This patch changes guards all BL30 functionality so it is skipped on
> SoCs which don't have it. Since the hardware itself doesn't know whether
> BL30 is available the internal meson_sar_adc_data is extended so this
> information can be provided per of_device_id.data inside the driver.
> 
> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
> This is already supported by the meson_saradc driver.
> 
> Finally a new of_device_id for the Meson8b SoC is added so it can be
> wired up in the corresponding DT.
> 
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
>  drivers/iio/adc/meson_saradc.c | 70 +++++++++++++++++++++++++++---------------
>  1 file changed, 46 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index dd4190b50df6..f78fe66e0ec8 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -220,6 +220,7 @@ enum meson_sar_adc_chan7_mux_sel {
>  };
>  
>  struct meson_sar_adc_data {
> +	char					has_bl30_integration;

bool?

>  	unsigned int				resolution;
>  	const char				*name;
>  };
> @@ -437,19 +438,24 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
>  
>  	mutex_lock(&indio_dev->mlock);
>  
> -	/* prevent BL30 from using the SAR ADC while we are using it */
> -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> -
> -	/* wait until BL30 releases it's lock (so we can use the SAR ADC) */
> -	do {
> -		udelay(1);
> -		regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> -	} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> -
> -	if (timeout < 0)
> -		return -ETIMEDOUT;
> +	if (priv->data->has_bl30_integration) {
> +		/* prevent BL30 from using the SAR ADC while we are using it */
> +		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> +
> +		/*
> +		 * wait until BL30 releases it's lock (so we can use the SAR

its

> +		 * ADC)
> +		 */
> +		do {
> +			udelay(1);
> +			regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> +		} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> +
> +		if (timeout < 0)
> +			return -ETIMEDOUT;
> +	}
>  
>  	return 0;
>  }
> @@ -458,9 +464,10 @@ static void meson_sar_adc_unlock(struct iio_dev *indio_dev)
>  {
>  	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
>  
> -	/* allow BL30 to use the SAR ADC again */
> -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
> +	if (priv->data->has_bl30_integration)
> +		/* allow BL30 to use the SAR ADC again */
> +		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
>  
>  	mutex_unlock(&indio_dev->mlock);
>  }
> @@ -614,14 +621,16 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  	 */
>  	meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
>  
> -	/*
> -	 * leave sampling delay and the input clocks as configured by BL30 to
> -	 * make sure BL30 gets the values it expects when reading the
> -	 * temperature sensor.
> -	 */
> -	regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
> -	if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> -		return 0;
> +	if (priv->data->has_bl30_integration) {
> +		/*
> +		 * leave sampling delay and the input clocks as configured by
> +		 * BL30 to make sure BL30 gets the values it expects when
> +		 * reading the temperature sensor.
> +		 */
> +		regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
> +		if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> +			return 0;
> +	}
>  
>  	meson_sar_adc_stop_sample_engine(indio_dev);
>  
> @@ -834,23 +843,36 @@ static const struct iio_info meson_sar_adc_iio_info = {
>  	.driver_module = THIS_MODULE,
>  };
>  
> +struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> +	.has_bl30_integration = 0,

= false

> +	.resolution = 10,
> +	.name = "meson-meson8b-saradc",
> +};
> +
>  struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> +	.has_bl30_integration = 1,

= true

>  	.resolution = 10,
>  	.name = "meson-gxbb-saradc",
>  };
>  
>  struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> +	.has_bl30_integration = 1,
>  	.resolution = 12,
>  	.name = "meson-gxl-saradc",
>  };
>  
>  struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> +	.has_bl30_integration = 1,
>  	.resolution = 12,
>  	.name = "meson-gxm-saradc",
>  };
>  
>  static const struct of_device_id meson_sar_adc_of_match[] = {
>  	{
> +		.compatible = "amlogic,meson8b-saradc",
> +		.data = &meson_sar_adc_meson8b_data,
> +	},
> +	{
>  		.compatible = "amlogic,meson-gxbb-saradc",
>  		.data = &meson_sar_adc_gxbb_data,
>  	}, {
> 

-- 

Peter Meerwald-Stadler
Mobile: +43 664 24 44 418

[PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Peter Meerwald-Stadler]

On Sat, 25 Mar 2017, Martin Blumenstingl wrote:

nitpicking below

> Meson GX SoCs however use some magic bits to prevent simultaneous (=
> conflicting, because only consumer should use the FIFO buffer with the
> ADC results) usage by the Linux kernel and the bootloader (the BL30
> bootloader uses the SAR ADC to read the CPU temperature).
> This patch changes guards all BL30 functionality so it is skipped on
> SoCs which don't have it. Since the hardware itself doesn't know whether
> BL30 is available the internal meson_sar_adc_data is extended so this
> information can be provided per of_device_id.data inside the driver.
> 
> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
> This is already supported by the meson_saradc driver.
> 
> Finally a new of_device_id for the Meson8b SoC is added so it can be
> wired up in the corresponding DT.
> 
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
>  drivers/iio/adc/meson_saradc.c | 70 +++++++++++++++++++++++++++---------------
>  1 file changed, 46 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index dd4190b50df6..f78fe66e0ec8 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -220,6 +220,7 @@ enum meson_sar_adc_chan7_mux_sel {
>  };
>  
>  struct meson_sar_adc_data {
> +	char					has_bl30_integration;

bool?

>  	unsigned int				resolution;
>  	const char				*name;
>  };
> @@ -437,19 +438,24 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
>  
>  	mutex_lock(&indio_dev->mlock);
>  
> -	/* prevent BL30 from using the SAR ADC while we are using it */
> -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> -
> -	/* wait until BL30 releases it's lock (so we can use the SAR ADC) */
> -	do {
> -		udelay(1);
> -		regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> -	} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> -
> -	if (timeout < 0)
> -		return -ETIMEDOUT;
> +	if (priv->data->has_bl30_integration) {
> +		/* prevent BL30 from using the SAR ADC while we are using it */
> +		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> +
> +		/*
> +		 * wait until BL30 releases it's lock (so we can use the SAR

its

> +		 * ADC)
> +		 */
> +		do {
> +			udelay(1);
> +			regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> +		} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> +
> +		if (timeout < 0)
> +			return -ETIMEDOUT;
> +	}
>  
>  	return 0;
>  }
> @@ -458,9 +464,10 @@ static void meson_sar_adc_unlock(struct iio_dev *indio_dev)
>  {
>  	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
>  
> -	/* allow BL30 to use the SAR ADC again */
> -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
> +	if (priv->data->has_bl30_integration)
> +		/* allow BL30 to use the SAR ADC again */
> +		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
>  
>  	mutex_unlock(&indio_dev->mlock);
>  }
> @@ -614,14 +621,16 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  	 */
>  	meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
>  
> -	/*
> -	 * leave sampling delay and the input clocks as configured by BL30 to
> -	 * make sure BL30 gets the values it expects when reading the
> -	 * temperature sensor.
> -	 */
> -	regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
> -	if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> -		return 0;
> +	if (priv->data->has_bl30_integration) {
> +		/*
> +		 * leave sampling delay and the input clocks as configured by
> +		 * BL30 to make sure BL30 gets the values it expects when
> +		 * reading the temperature sensor.
> +		 */
> +		regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
> +		if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> +			return 0;
> +	}
>  
>  	meson_sar_adc_stop_sample_engine(indio_dev);
>  
> @@ -834,23 +843,36 @@ static const struct iio_info meson_sar_adc_iio_info = {
>  	.driver_module = THIS_MODULE,
>  };
>  
> +struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> +	.has_bl30_integration = 0,

= false

> +	.resolution = 10,
> +	.name = "meson-meson8b-saradc",
> +};
> +
>  struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> +	.has_bl30_integration = 1,

= true

>  	.resolution = 10,
>  	.name = "meson-gxbb-saradc",
>  };
>  
>  struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> +	.has_bl30_integration = 1,
>  	.resolution = 12,
>  	.name = "meson-gxl-saradc",
>  };
>  
>  struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> +	.has_bl30_integration = 1,
>  	.resolution = 12,
>  	.name = "meson-gxm-saradc",
>  };
>  
>  static const struct of_device_id meson_sar_adc_of_match[] = {
>  	{
> +		.compatible = "amlogic,meson8b-saradc",
> +		.data = &meson_sar_adc_meson8b_data,
> +	},
> +	{
>  		.compatible = "amlogic,meson-gxbb-saradc",
>  		.data = &meson_sar_adc_gxbb_data,
>  	}, {
> 

-- 

Peter Meerwald-Stadler
Mobile: +43 664 24 44 418

Re: [PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Jonathan Cameron]

On 25/03/17 16:29, Martin Blumenstingl wrote:
> Meson GX SoCs however use some magic bits to prevent simultaneous (=
> conflicting, because only consumer should use the FIFO buffer with the
> ADC results) usage by the Linux kernel and the bootloader (the BL30
> bootloader uses the SAR ADC to read the CPU temperature).
> This patch changes guards all BL30 functionality so it is skipped on
> SoCs which don't have it. Since the hardware itself doesn't know whether
> BL30 is available the internal meson_sar_adc_data is extended so this
> information can be provided per of_device_id.data inside the driver.
> 
> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
> This is already supported by the meson_saradc driver.
> 
> Finally a new of_device_id for the Meson8b SoC is added so it can be
> wired up in the corresponding DT.
> 
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Looks sensible to me. Just fix those bits from Peter and we'll let it sit
a few days on the list to see if anyone else wants to chip in.

Thanks,

Jonathan
> ---
>  drivers/iio/adc/meson_saradc.c | 70 +++++++++++++++++++++++++++---------------
>  1 file changed, 46 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index dd4190b50df6..f78fe66e0ec8 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -220,6 +220,7 @@ enum meson_sar_adc_chan7_mux_sel {
>  };
>  
>  struct meson_sar_adc_data {
> +	char					has_bl30_integration;
>  	unsigned int				resolution;
>  	const char				*name;
>  };
> @@ -437,19 +438,24 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
>  
>  	mutex_lock(&indio_dev->mlock);
>  
> -	/* prevent BL30 from using the SAR ADC while we are using it */
> -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> -
> -	/* wait until BL30 releases it's lock (so we can use the SAR ADC) */
> -	do {
> -		udelay(1);
> -		regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> -	} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> -
> -	if (timeout < 0)
> -		return -ETIMEDOUT;
> +	if (priv->data->has_bl30_integration) {
> +		/* prevent BL30 from using the SAR ADC while we are using it */
> +		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> +
> +		/*
> +		 * wait until BL30 releases it's lock (so we can use the SAR
> +		 * ADC)
> +		 */
> +		do {
> +			udelay(1);
> +			regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> +		} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> +
> +		if (timeout < 0)
> +			return -ETIMEDOUT;
> +	}
>  
>  	return 0;
>  }
> @@ -458,9 +464,10 @@ static void meson_sar_adc_unlock(struct iio_dev *indio_dev)
>  {
>  	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
>  
> -	/* allow BL30 to use the SAR ADC again */
> -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
> +	if (priv->data->has_bl30_integration)
> +		/* allow BL30 to use the SAR ADC again */
> +		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
>  
>  	mutex_unlock(&indio_dev->mlock);
>  }
> @@ -614,14 +621,16 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  	 */
>  	meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
>  
> -	/*
> -	 * leave sampling delay and the input clocks as configured by BL30 to
> -	 * make sure BL30 gets the values it expects when reading the
> -	 * temperature sensor.
> -	 */
> -	regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
> -	if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> -		return 0;
> +	if (priv->data->has_bl30_integration) {
> +		/*
> +		 * leave sampling delay and the input clocks as configured by
> +		 * BL30 to make sure BL30 gets the values it expects when
> +		 * reading the temperature sensor.
> +		 */
> +		regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
> +		if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> +			return 0;
> +	}
>  
>  	meson_sar_adc_stop_sample_engine(indio_dev);
>  
> @@ -834,23 +843,36 @@ static const struct iio_info meson_sar_adc_iio_info = {
>  	.driver_module = THIS_MODULE,
>  };
>  
> +struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> +	.has_bl30_integration = 0,
> +	.resolution = 10,
> +	.name = "meson-meson8b-saradc",
> +};
> +
>  struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> +	.has_bl30_integration = 1,
>  	.resolution = 10,
>  	.name = "meson-gxbb-saradc",
>  };
>  
>  struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> +	.has_bl30_integration = 1,
>  	.resolution = 12,
>  	.name = "meson-gxl-saradc",
>  };
>  
>  struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> +	.has_bl30_integration = 1,
>  	.resolution = 12,
>  	.name = "meson-gxm-saradc",
>  };
>  
>  static const struct of_device_id meson_sar_adc_of_match[] = {
>  	{
> +		.compatible = "amlogic,meson8b-saradc",
> +		.data = &meson_sar_adc_meson8b_data,
> +	},
> +	{
>  		.compatible = "amlogic,meson-gxbb-saradc",
>  		.data = &meson_sar_adc_gxbb_data,
>  	}, {
> 

Re: [PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Jonathan Cameron]

On 25/03/17 16:29, Martin Blumenstingl wrote:
> Meson GX SoCs however use some magic bits to prevent simultaneous (=
> conflicting, because only consumer should use the FIFO buffer with the
> ADC results) usage by the Linux kernel and the bootloader (the BL30
> bootloader uses the SAR ADC to read the CPU temperature).
> This patch changes guards all BL30 functionality so it is skipped on
> SoCs which don't have it. Since the hardware itself doesn't know whether
> BL30 is available the internal meson_sar_adc_data is extended so this
> information can be provided per of_device_id.data inside the driver.
> 
> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
> This is already supported by the meson_saradc driver.
> 
> Finally a new of_device_id for the Meson8b SoC is added so it can be
> wired up in the corresponding DT.
> 
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Looks sensible to me. Just fix those bits from Peter and we'll let it sit
a few days on the list to see if anyone else wants to chip in.

Thanks,

Jonathan
> ---
>  drivers/iio/adc/meson_saradc.c | 70 +++++++++++++++++++++++++++---------------
>  1 file changed, 46 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index dd4190b50df6..f78fe66e0ec8 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -220,6 +220,7 @@ enum meson_sar_adc_chan7_mux_sel {
>  };
>  
>  struct meson_sar_adc_data {
> +	char					has_bl30_integration;
>  	unsigned int				resolution;
>  	const char				*name;
>  };
> @@ -437,19 +438,24 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
>  
>  	mutex_lock(&indio_dev->mlock);
>  
> -	/* prevent BL30 from using the SAR ADC while we are using it */
> -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> -
> -	/* wait until BL30 releases it's lock (so we can use the SAR ADC) */
> -	do {
> -		udelay(1);
> -		regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> -	} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> -
> -	if (timeout < 0)
> -		return -ETIMEDOUT;
> +	if (priv->data->has_bl30_integration) {
> +		/* prevent BL30 from using the SAR ADC while we are using it */
> +		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> +
> +		/*
> +		 * wait until BL30 releases it's lock (so we can use the SAR
> +		 * ADC)
> +		 */
> +		do {
> +			udelay(1);
> +			regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> +		} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> +
> +		if (timeout < 0)
> +			return -ETIMEDOUT;
> +	}
>  
>  	return 0;
>  }
> @@ -458,9 +464,10 @@ static void meson_sar_adc_unlock(struct iio_dev *indio_dev)
>  {
>  	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
>  
> -	/* allow BL30 to use the SAR ADC again */
> -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
> +	if (priv->data->has_bl30_integration)
> +		/* allow BL30 to use the SAR ADC again */
> +		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
>  
>  	mutex_unlock(&indio_dev->mlock);
>  }
> @@ -614,14 +621,16 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  	 */
>  	meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
>  
> -	/*
> -	 * leave sampling delay and the input clocks as configured by BL30 to
> -	 * make sure BL30 gets the values it expects when reading the
> -	 * temperature sensor.
> -	 */
> -	regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
> -	if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> -		return 0;
> +	if (priv->data->has_bl30_integration) {
> +		/*
> +		 * leave sampling delay and the input clocks as configured by
> +		 * BL30 to make sure BL30 gets the values it expects when
> +		 * reading the temperature sensor.
> +		 */
> +		regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
> +		if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> +			return 0;
> +	}
>  
>  	meson_sar_adc_stop_sample_engine(indio_dev);
>  
> @@ -834,23 +843,36 @@ static const struct iio_info meson_sar_adc_iio_info = {
>  	.driver_module = THIS_MODULE,
>  };
>  
> +struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> +	.has_bl30_integration = 0,
> +	.resolution = 10,
> +	.name = "meson-meson8b-saradc",
> +};
> +
>  struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> +	.has_bl30_integration = 1,
>  	.resolution = 10,
>  	.name = "meson-gxbb-saradc",
>  };
>  
>  struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> +	.has_bl30_integration = 1,
>  	.resolution = 12,
>  	.name = "meson-gxl-saradc",
>  };
>  
>  struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> +	.has_bl30_integration = 1,
>  	.resolution = 12,
>  	.name = "meson-gxm-saradc",
>  };
>  
>  static const struct of_device_id meson_sar_adc_of_match[] = {
>  	{
> +		.compatible = "amlogic,meson8b-saradc",
> +		.data = &meson_sar_adc_meson8b_data,
> +	},
> +	{
>  		.compatible = "amlogic,meson-gxbb-saradc",
>  		.data = &meson_sar_adc_gxbb_data,
>  	}, {
> 

[PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Jonathan Cameron]

On 25/03/17 16:29, Martin Blumenstingl wrote:
> Meson GX SoCs however use some magic bits to prevent simultaneous (=
> conflicting, because only consumer should use the FIFO buffer with the
> ADC results) usage by the Linux kernel and the bootloader (the BL30
> bootloader uses the SAR ADC to read the CPU temperature).
> This patch changes guards all BL30 functionality so it is skipped on
> SoCs which don't have it. Since the hardware itself doesn't know whether
> BL30 is available the internal meson_sar_adc_data is extended so this
> information can be provided per of_device_id.data inside the driver.
> 
> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
> This is already supported by the meson_saradc driver.
> 
> Finally a new of_device_id for the Meson8b SoC is added so it can be
> wired up in the corresponding DT.
> 
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Looks sensible to me. Just fix those bits from Peter and we'll let it sit
a few days on the list to see if anyone else wants to chip in.

Thanks,

Jonathan
> ---
>  drivers/iio/adc/meson_saradc.c | 70 +++++++++++++++++++++++++++---------------
>  1 file changed, 46 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index dd4190b50df6..f78fe66e0ec8 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -220,6 +220,7 @@ enum meson_sar_adc_chan7_mux_sel {
>  };
>  
>  struct meson_sar_adc_data {
> +	char					has_bl30_integration;
>  	unsigned int				resolution;
>  	const char				*name;
>  };
> @@ -437,19 +438,24 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
>  
>  	mutex_lock(&indio_dev->mlock);
>  
> -	/* prevent BL30 from using the SAR ADC while we are using it */
> -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> -
> -	/* wait until BL30 releases it's lock (so we can use the SAR ADC) */
> -	do {
> -		udelay(1);
> -		regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> -	} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> -
> -	if (timeout < 0)
> -		return -ETIMEDOUT;
> +	if (priv->data->has_bl30_integration) {
> +		/* prevent BL30 from using the SAR ADC while we are using it */
> +		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> +
> +		/*
> +		 * wait until BL30 releases it's lock (so we can use the SAR
> +		 * ADC)
> +		 */
> +		do {
> +			udelay(1);
> +			regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> +		} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> +
> +		if (timeout < 0)
> +			return -ETIMEDOUT;
> +	}
>  
>  	return 0;
>  }
> @@ -458,9 +464,10 @@ static void meson_sar_adc_unlock(struct iio_dev *indio_dev)
>  {
>  	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
>  
> -	/* allow BL30 to use the SAR ADC again */
> -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
> +	if (priv->data->has_bl30_integration)
> +		/* allow BL30 to use the SAR ADC again */
> +		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
>  
>  	mutex_unlock(&indio_dev->mlock);
>  }
> @@ -614,14 +621,16 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  	 */
>  	meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
>  
> -	/*
> -	 * leave sampling delay and the input clocks as configured by BL30 to
> -	 * make sure BL30 gets the values it expects when reading the
> -	 * temperature sensor.
> -	 */
> -	regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
> -	if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> -		return 0;
> +	if (priv->data->has_bl30_integration) {
> +		/*
> +		 * leave sampling delay and the input clocks as configured by
> +		 * BL30 to make sure BL30 gets the values it expects when
> +		 * reading the temperature sensor.
> +		 */
> +		regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
> +		if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> +			return 0;
> +	}
>  
>  	meson_sar_adc_stop_sample_engine(indio_dev);
>  
> @@ -834,23 +843,36 @@ static const struct iio_info meson_sar_adc_iio_info = {
>  	.driver_module = THIS_MODULE,
>  };
>  
> +struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> +	.has_bl30_integration = 0,
> +	.resolution = 10,
> +	.name = "meson-meson8b-saradc",
> +};
> +
>  struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> +	.has_bl30_integration = 1,
>  	.resolution = 10,
>  	.name = "meson-gxbb-saradc",
>  };
>  
>  struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> +	.has_bl30_integration = 1,
>  	.resolution = 12,
>  	.name = "meson-gxl-saradc",
>  };
>  
>  struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> +	.has_bl30_integration = 1,
>  	.resolution = 12,
>  	.name = "meson-gxm-saradc",
>  };
>  
>  static const struct of_device_id meson_sar_adc_of_match[] = {
>  	{
> +		.compatible = "amlogic,meson8b-saradc",
> +		.data = &meson_sar_adc_meson8b_data,
> +	},
> +	{
>  		.compatible = "amlogic,meson-gxbb-saradc",
>  		.data = &meson_sar_adc_gxbb_data,
>  	}, {
> 

[PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Jonathan Cameron]

On 25/03/17 16:29, Martin Blumenstingl wrote:
> Meson GX SoCs however use some magic bits to prevent simultaneous (=
> conflicting, because only consumer should use the FIFO buffer with the
> ADC results) usage by the Linux kernel and the bootloader (the BL30
> bootloader uses the SAR ADC to read the CPU temperature).
> This patch changes guards all BL30 functionality so it is skipped on
> SoCs which don't have it. Since the hardware itself doesn't know whether
> BL30 is available the internal meson_sar_adc_data is extended so this
> information can be provided per of_device_id.data inside the driver.
> 
> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
> This is already supported by the meson_saradc driver.
> 
> Finally a new of_device_id for the Meson8b SoC is added so it can be
> wired up in the corresponding DT.
> 
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Looks sensible to me. Just fix those bits from Peter and we'll let it sit
a few days on the list to see if anyone else wants to chip in.

Thanks,

Jonathan
> ---
>  drivers/iio/adc/meson_saradc.c | 70 +++++++++++++++++++++++++++---------------
>  1 file changed, 46 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index dd4190b50df6..f78fe66e0ec8 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -220,6 +220,7 @@ enum meson_sar_adc_chan7_mux_sel {
>  };
>  
>  struct meson_sar_adc_data {
> +	char					has_bl30_integration;
>  	unsigned int				resolution;
>  	const char				*name;
>  };
> @@ -437,19 +438,24 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
>  
>  	mutex_lock(&indio_dev->mlock);
>  
> -	/* prevent BL30 from using the SAR ADC while we are using it */
> -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> -
> -	/* wait until BL30 releases it's lock (so we can use the SAR ADC) */
> -	do {
> -		udelay(1);
> -		regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> -	} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> -
> -	if (timeout < 0)
> -		return -ETIMEDOUT;
> +	if (priv->data->has_bl30_integration) {
> +		/* prevent BL30 from using the SAR ADC while we are using it */
> +		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> +
> +		/*
> +		 * wait until BL30 releases it's lock (so we can use the SAR
> +		 * ADC)
> +		 */
> +		do {
> +			udelay(1);
> +			regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> +		} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> +
> +		if (timeout < 0)
> +			return -ETIMEDOUT;
> +	}
>  
>  	return 0;
>  }
> @@ -458,9 +464,10 @@ static void meson_sar_adc_unlock(struct iio_dev *indio_dev)
>  {
>  	struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
>  
> -	/* allow BL30 to use the SAR ADC again */
> -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> -			   MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
> +	if (priv->data->has_bl30_integration)
> +		/* allow BL30 to use the SAR ADC again */
> +		regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> +				MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
>  
>  	mutex_unlock(&indio_dev->mlock);
>  }
> @@ -614,14 +621,16 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  	 */
>  	meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
>  
> -	/*
> -	 * leave sampling delay and the input clocks as configured by BL30 to
> -	 * make sure BL30 gets the values it expects when reading the
> -	 * temperature sensor.
> -	 */
> -	regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
> -	if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> -		return 0;
> +	if (priv->data->has_bl30_integration) {
> +		/*
> +		 * leave sampling delay and the input clocks as configured by
> +		 * BL30 to make sure BL30 gets the values it expects when
> +		 * reading the temperature sensor.
> +		 */
> +		regmap_read(priv->regmap, MESON_SAR_ADC_REG3, &regval);
> +		if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> +			return 0;
> +	}
>  
>  	meson_sar_adc_stop_sample_engine(indio_dev);
>  
> @@ -834,23 +843,36 @@ static const struct iio_info meson_sar_adc_iio_info = {
>  	.driver_module = THIS_MODULE,
>  };
>  
> +struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> +	.has_bl30_integration = 0,
> +	.resolution = 10,
> +	.name = "meson-meson8b-saradc",
> +};
> +
>  struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> +	.has_bl30_integration = 1,
>  	.resolution = 10,
>  	.name = "meson-gxbb-saradc",
>  };
>  
>  struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> +	.has_bl30_integration = 1,
>  	.resolution = 12,
>  	.name = "meson-gxl-saradc",
>  };
>  
>  struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> +	.has_bl30_integration = 1,
>  	.resolution = 12,
>  	.name = "meson-gxm-saradc",
>  };
>  
>  static const struct of_device_id meson_sar_adc_of_match[] = {
>  	{
> +		.compatible = "amlogic,meson8b-saradc",
> +		.data = &meson_sar_adc_meson8b_data,
> +	},
> +	{
>  		.compatible = "amlogic,meson-gxbb-saradc",
>  		.data = &meson_sar_adc_gxbb_data,
>  	}, {
> 

Re: [PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Martin Blumenstingl]

On Sat, Mar 25, 2017 at 7:13 PM, Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On 25/03/17 16:29, Martin Blumenstingl wrote:
>> Meson GX SoCs however use some magic bits to prevent simultaneous (=
>> conflicting, because only consumer should use the FIFO buffer with the
>> ADC results) usage by the Linux kernel and the bootloader (the BL30
>> bootloader uses the SAR ADC to read the CPU temperature).
>> This patch changes guards all BL30 functionality so it is skipped on
>> SoCs which don't have it. Since the hardware itself doesn't know whether
>> BL30 is available the internal meson_sar_adc_data is extended so this
>> information can be provided per of_device_id.data inside the driver.
>>
>> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
>> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
>> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
>> This is already supported by the meson_saradc driver.
>>
>> Finally a new of_device_id for the Meson8b SoC is added so it can be
>> wired up in the corresponding DT.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Looks sensible to me. Just fix those bits from Peter and we'll let it sit
> a few days on the list to see if anyone else wants to chip in.
OK, we'll have to wait for one of the DT-maintainers ACK (on the other
patch) anyways, so I'll re-spin this in a week or so and fix
everything that has come up until then

Re: [PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Martin Blumenstingl]

On Sat, Mar 25, 2017 at 7:13 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> On 25/03/17 16:29, Martin Blumenstingl wrote:
>> Meson GX SoCs however use some magic bits to prevent simultaneous (=
>> conflicting, because only consumer should use the FIFO buffer with the
>> ADC results) usage by the Linux kernel and the bootloader (the BL30
>> bootloader uses the SAR ADC to read the CPU temperature).
>> This patch changes guards all BL30 functionality so it is skipped on
>> SoCs which don't have it. Since the hardware itself doesn't know whether
>> BL30 is available the internal meson_sar_adc_data is extended so this
>> information can be provided per of_device_id.data inside the driver.
>>
>> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
>> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
>> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
>> This is already supported by the meson_saradc driver.
>>
>> Finally a new of_device_id for the Meson8b SoC is added so it can be
>> wired up in the corresponding DT.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Looks sensible to me. Just fix those bits from Peter and we'll let it sit
> a few days on the list to see if anyone else wants to chip in.
OK, we'll have to wait for one of the DT-maintainers ACK (on the other
patch) anyways, so I'll re-spin this in a week or so and fix
everything that has come up until then

[PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Martin Blumenstingl]

On Sat, Mar 25, 2017 at 7:13 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> On 25/03/17 16:29, Martin Blumenstingl wrote:
>> Meson GX SoCs however use some magic bits to prevent simultaneous (=
>> conflicting, because only consumer should use the FIFO buffer with the
>> ADC results) usage by the Linux kernel and the bootloader (the BL30
>> bootloader uses the SAR ADC to read the CPU temperature).
>> This patch changes guards all BL30 functionality so it is skipped on
>> SoCs which don't have it. Since the hardware itself doesn't know whether
>> BL30 is available the internal meson_sar_adc_data is extended so this
>> information can be provided per of_device_id.data inside the driver.
>>
>> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
>> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
>> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
>> This is already supported by the meson_saradc driver.
>>
>> Finally a new of_device_id for the Meson8b SoC is added so it can be
>> wired up in the corresponding DT.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Looks sensible to me. Just fix those bits from Peter and we'll let it sit
> a few days on the list to see if anyone else wants to chip in.
OK, we'll have to wait for one of the DT-maintainers ACK (on the other
patch) anyways, so I'll re-spin this in a week or so and fix
everything that has come up until then

[PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Martin Blumenstingl]

On Sat, Mar 25, 2017 at 7:13 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> On 25/03/17 16:29, Martin Blumenstingl wrote:
>> Meson GX SoCs however use some magic bits to prevent simultaneous (=
>> conflicting, because only consumer should use the FIFO buffer with the
>> ADC results) usage by the Linux kernel and the bootloader (the BL30
>> bootloader uses the SAR ADC to read the CPU temperature).
>> This patch changes guards all BL30 functionality so it is skipped on
>> SoCs which don't have it. Since the hardware itself doesn't know whether
>> BL30 is available the internal meson_sar_adc_data is extended so this
>> information can be provided per of_device_id.data inside the driver.
>>
>> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
>> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
>> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
>> This is already supported by the meson_saradc driver.
>>
>> Finally a new of_device_id for the Meson8b SoC is added so it can be
>> wired up in the corresponding DT.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Looks sensible to me. Just fix those bits from Peter and we'll let it sit
> a few days on the list to see if anyone else wants to chip in.
OK, we'll have to wait for one of the DT-maintainers ACK (on the other
patch) anyways, so I'll re-spin this in a week or so and fix
everything that has come up until then

Re: [PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Jonathan Cameron]

On 25/03/17 18:28, Martin Blumenstingl wrote:
> On Sat, Mar 25, 2017 at 7:13 PM, Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> On 25/03/17 16:29, Martin Blumenstingl wrote:
>>> Meson GX SoCs however use some magic bits to prevent simultaneous (=
>>> conflicting, because only consumer should use the FIFO buffer with the
>>> ADC results) usage by the Linux kernel and the bootloader (the BL30
>>> bootloader uses the SAR ADC to read the CPU temperature).
>>> This patch changes guards all BL30 functionality so it is skipped on
>>> SoCs which don't have it. Since the hardware itself doesn't know whether
>>> BL30 is available the internal meson_sar_adc_data is extended so this
>>> information can be provided per of_device_id.data inside the driver.
>>>
>>> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
>>> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
>>> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
>>> This is already supported by the meson_saradc driver.
>>>
>>> Finally a new of_device_id for the Meson8b SoC is added so it can be
>>> wired up in the corresponding DT.
>>>
>>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>> Looks sensible to me. Just fix those bits from Peter and we'll let it sit
>> a few days on the list to see if anyone else wants to chip in.
> OK, we'll have to wait for one of the DT-maintainers ACK (on the other
> patch) anyways, so I'll re-spin this in a week or so and fix
> everything that has come up until then
There is some flexibility in 'trivial' dt bindings such as this so as
not to waste their time.  But we should allow them the opportunity before
applying it anyway ;)

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

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Jonathan Cameron]

On 25/03/17 18:28, Martin Blumenstingl wrote:
> On Sat, Mar 25, 2017 at 7:13 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>> On 25/03/17 16:29, Martin Blumenstingl wrote:
>>> Meson GX SoCs however use some magic bits to prevent simultaneous (=
>>> conflicting, because only consumer should use the FIFO buffer with the
>>> ADC results) usage by the Linux kernel and the bootloader (the BL30
>>> bootloader uses the SAR ADC to read the CPU temperature).
>>> This patch changes guards all BL30 functionality so it is skipped on
>>> SoCs which don't have it. Since the hardware itself doesn't know whether
>>> BL30 is available the internal meson_sar_adc_data is extended so this
>>> information can be provided per of_device_id.data inside the driver.
>>>
>>> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
>>> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
>>> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
>>> This is already supported by the meson_saradc driver.
>>>
>>> Finally a new of_device_id for the Meson8b SoC is added so it can be
>>> wired up in the corresponding DT.
>>>
>>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> Looks sensible to me. Just fix those bits from Peter and we'll let it sit
>> a few days on the list to see if anyone else wants to chip in.
> OK, we'll have to wait for one of the DT-maintainers ACK (on the other
> patch) anyways, so I'll re-spin this in a week or so and fix
> everything that has come up until then
There is some flexibility in 'trivial' dt bindings such as this so as
not to waste their time.  But we should allow them the opportunity before
applying it anyway ;)

Jonathan
> --
> 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 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Jonathan Cameron]

On 25/03/17 18:28, Martin Blumenstingl wrote:
> On Sat, Mar 25, 2017 at 7:13 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>> On 25/03/17 16:29, Martin Blumenstingl wrote:
>>> Meson GX SoCs however use some magic bits to prevent simultaneous (=
>>> conflicting, because only consumer should use the FIFO buffer with the
>>> ADC results) usage by the Linux kernel and the bootloader (the BL30
>>> bootloader uses the SAR ADC to read the CPU temperature).
>>> This patch changes guards all BL30 functionality so it is skipped on
>>> SoCs which don't have it. Since the hardware itself doesn't know whether
>>> BL30 is available the internal meson_sar_adc_data is extended so this
>>> information can be provided per of_device_id.data inside the driver.
>>>
>>> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
>>> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
>>> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
>>> This is already supported by the meson_saradc driver.
>>>
>>> Finally a new of_device_id for the Meson8b SoC is added so it can be
>>> wired up in the corresponding DT.
>>>
>>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> Looks sensible to me. Just fix those bits from Peter and we'll let it sit
>> a few days on the list to see if anyone else wants to chip in.
> OK, we'll have to wait for one of the DT-maintainers ACK (on the other
> patch) anyways, so I'll re-spin this in a week or so and fix
> everything that has come up until then
There is some flexibility in 'trivial' dt bindings such as this so as
not to waste their time.  But we should allow them the opportunity before
applying it anyway ;)

Jonathan
> --
> 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
> 

[PATCH 2/2] iio: adc: meson-saradc: add Meson8b SoC compatibility

[Jonathan Cameron]

On 25/03/17 18:28, Martin Blumenstingl wrote:
> On Sat, Mar 25, 2017 at 7:13 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>> On 25/03/17 16:29, Martin Blumenstingl wrote:
>>> Meson GX SoCs however use some magic bits to prevent simultaneous (=
>>> conflicting, because only consumer should use the FIFO buffer with the
>>> ADC results) usage by the Linux kernel and the bootloader (the BL30
>>> bootloader uses the SAR ADC to read the CPU temperature).
>>> This patch changes guards all BL30 functionality so it is skipped on
>>> SoCs which don't have it. Since the hardware itself doesn't know whether
>>> BL30 is available the internal meson_sar_adc_data is extended so this
>>> information can be provided per of_device_id.data inside the driver.
>>>
>>> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
>>> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
>>> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
>>> This is already supported by the meson_saradc driver.
>>>
>>> Finally a new of_device_id for the Meson8b SoC is added so it can be
>>> wired up in the corresponding DT.
>>>
>>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> Looks sensible to me. Just fix those bits from Peter and we'll let it sit
>> a few days on the list to see if anyone else wants to chip in.
> OK, we'll have to wait for one of the DT-maintainers ACK (on the other
> patch) anyways, so I'll re-spin this in a week or so and fix
> everything that has come up until then
There is some flexibility in 'trivial' dt bindings such as this so as
not to waste their time.  But we should allow them the opportunity before
applying it anyway ;)

Jonathan
> --
> 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
> 

Re: [PATCH 1/2] Documentation: dt-bindings: add a Meson8b compatible to the SAR ADC

[Rob Herring]

On Sat, Mar 25, 2017 at 05:29:37PM +0100, Martin Blumenstingl wrote:
> The Amlogic Meson SAR ADC driver can be used on Meson8b as well
> (probably on earlier SoC generations as well, but I don't have any
> hardware available for testing that).
> Add a separate compatible for Meson8b because it does not need any of
> the BL30 magic (unlike the GX SoCs).
> 
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 1 +
>  1 file changed, 1 insertion(+)

If you respin, "dt-bindings: iio: adc: ..." for the subject. Otherwise,

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

Re: [PATCH 1/2] Documentation: dt-bindings: add a Meson8b compatible to the SAR ADC

[Rob Herring]

On Sat, Mar 25, 2017 at 05:29:37PM +0100, Martin Blumenstingl wrote:
> The Amlogic Meson SAR ADC driver can be used on Meson8b as well
> (probably on earlier SoC generations as well, but I don't have any
> hardware available for testing that).
> Add a separate compatible for Meson8b because it does not need any of
> the BL30 magic (unlike the GX SoCs).
> 
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
>  Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 1 +
>  1 file changed, 1 insertion(+)

If you respin, "dt-bindings: iio: adc: ..." for the subject. Otherwise,

Acked-by: Rob Herring <robh@kernel.org>

[PATCH 1/2] Documentation: dt-bindings: add a Meson8b compatible to the SAR ADC

[Rob Herring]

On Sat, Mar 25, 2017 at 05:29:37PM +0100, Martin Blumenstingl wrote:
> The Amlogic Meson SAR ADC driver can be used on Meson8b as well
> (probably on earlier SoC generations as well, but I don't have any
> hardware available for testing that).
> Add a separate compatible for Meson8b because it does not need any of
> the BL30 magic (unlike the GX SoCs).
> 
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
>  Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 1 +
>  1 file changed, 1 insertion(+)

If you respin, "dt-bindings: iio: adc: ..." for the subject. Otherwise,

Acked-by: Rob Herring <robh@kernel.org>

[PATCH 1/2] Documentation: dt-bindings: add a Meson8b compatible to the SAR ADC

[Rob Herring]

On Sat, Mar 25, 2017 at 05:29:37PM +0100, Martin Blumenstingl wrote:
> The Amlogic Meson SAR ADC driver can be used on Meson8b as well
> (probably on earlier SoC generations as well, but I don't have any
> hardware available for testing that).
> Add a separate compatible for Meson8b because it does not need any of
> the BL30 magic (unlike the GX SoCs).
> 
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
>  Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 1 +
>  1 file changed, 1 insertion(+)

If you respin, "dt-bindings: iio: adc: ..." for the subject. Otherwise,

Acked-by: Rob Herring <robh@kernel.org>