[PATCH v2] iio: adc: aspeed: Deassert reset in probe

[PATCH v2] iio: adc: aspeed: Deassert reset in probe

[Joel Stanley]

The ASPEED SoC must deassert a reset in order to use the ADC peripheral.

The device tree bindings are updated to document the resets phandle, and
the example is updated to match what is expected for both the reset and
clock phandle. Note that the bindings should have always had the reset
controller, as the hardware is unusable without it.

Signed-off-by: Joel Stanley <joel@jms.id.au>
---
v2:
 - Ensure disabling path unwinds in opposite order as the enable path
 - Note that the bindings were incorrect without the reset phandle,
 and for the system to be usable we must update them. No one was
 (successfully) using these bindings/driver before without out of tree
 hacks in mach-aspeed, as it would not have worked.

 .../devicetree/bindings/iio/adc/aspeed_adc.txt     |  4 +++-
 drivers/iio/adc/aspeed_adc.c                       | 25 ++++++++++++++++------
 2 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt b/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt
index 674e133b7cd7..034fc2ba100e 100644
--- a/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt
@@ -8,6 +8,7 @@ Required properties:
 - reg: memory window mapping address and length
 - clocks: Input clock used to derive the sample clock. Expected to be the
           SoC's APB clock.
+- resets: Reset controller phandle
 - #io-channel-cells: Must be set to <1> to indicate channels are selected
                      by index.
 
@@ -15,6 +16,7 @@ Example:
 	adc@1e6e9000 {
 		compatible = "aspeed,ast2400-adc";
 		reg = <0x1e6e9000 0xb0>;
-		clocks = <&clk_apb>;
+		clocks = <&syscon ASPEED_CLK_APB>;
+		resets = <&syscon ASPEED_RESET_ADC>;
 		#io-channel-cells = <1>;
 	};
diff --git a/drivers/iio/adc/aspeed_adc.c b/drivers/iio/adc/aspeed_adc.c
index 8a958d5f1905..327a49ba1991 100644
--- a/drivers/iio/adc/aspeed_adc.c
+++ b/drivers/iio/adc/aspeed_adc.c
@@ -17,6 +17,7 @@
 #include <linux/module.h>
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
+#include <linux/reset.h>
 #include <linux/spinlock.h>
 #include <linux/types.h>
 
@@ -53,11 +54,12 @@ struct aspeed_adc_model_data {
 };
 
 struct aspeed_adc_data {
-	struct device	*dev;
-	void __iomem	*base;
-	spinlock_t	clk_lock;
-	struct clk_hw	*clk_prescaler;
-	struct clk_hw	*clk_scaler;
+	struct device		*dev;
+	void __iomem		*base;
+	spinlock_t		clk_lock;
+	struct clk_hw		*clk_prescaler;
+	struct clk_hw		*clk_scaler;
+	struct reset_control	*rst;
 };
 
 #define ASPEED_CHAN(_idx, _data_reg_addr) {			\
@@ -217,6 +219,15 @@ static int aspeed_adc_probe(struct platform_device *pdev)
 		goto scaler_error;
 	}
 
+	data->rst = devm_reset_control_get_exclusive(&pdev->dev, NULL);
+	if (IS_ERR(data->rst)) {
+		dev_err(&pdev->dev,
+			"invalid or missing reset controller device tree entry");
+		ret = PTR_ERR(data->rst);
+		goto reset_error;
+	}
+	reset_control_deassert(data->rst);
+
 	model_data = of_device_get_match_data(&pdev->dev);
 
 	if (model_data->wait_init_sequence) {
@@ -263,9 +274,10 @@ static int aspeed_adc_probe(struct platform_device *pdev)
 	writel(ASPEED_OPERATION_MODE_POWER_DOWN,
 		data->base + ASPEED_REG_ENGINE_CONTROL);
 	clk_disable_unprepare(data->clk_scaler->clk);
+reset_error:
+	reset_control_assert(data->rst);
 clk_enable_error:
 	clk_hw_unregister_divider(data->clk_scaler);
-
 scaler_error:
 	clk_hw_unregister_divider(data->clk_prescaler);
 	return ret;
@@ -280,6 +292,7 @@ static int aspeed_adc_remove(struct platform_device *pdev)
 	writel(ASPEED_OPERATION_MODE_POWER_DOWN,
 		data->base + ASPEED_REG_ENGINE_CONTROL);
 	clk_disable_unprepare(data->clk_scaler->clk);
+	reset_control_assert(data->rst);
 	clk_hw_unregister_divider(data->clk_scaler);
 	clk_hw_unregister_divider(data->clk_prescaler);
 
-- 
2.14.1

Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe

[Philipp Zabel]

On Tue, Oct 31, 2017 at 3:12 AM, Joel Stanley <joel@jms.id.au> wrote:
> The ASPEED SoC must deassert a reset in order to use the ADC peripheral.
>
> The device tree bindings are updated to document the resets phandle, and
> the example is updated to match what is expected for both the reset and
> clock phandle. Note that the bindings should have always had the reset
> controller, as the hardware is unusable without it.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>

It is unfortunate that this has to break DT (theoretical) backwards
compatibility, but given that the old bindings never worked,
this is better than to pretend a required reset is optional.

Reviewed-by: Philipp Zabel <philipp.zabel@gmail.com>

regards
Philipp

> ---
> v2:
>  - Ensure disabling path unwinds in opposite order as the enable path
>  - Note that the bindings were incorrect without the reset phandle,
>  and for the system to be usable we must update them. No one was
>  (successfully) using these bindings/driver before without out of tree
>  hacks in mach-aspeed, as it would not have worked.
>
>  .../devicetree/bindings/iio/adc/aspeed_adc.txt     |  4 +++-
>  drivers/iio/adc/aspeed_adc.c                       | 25 ++++++++++++++++------
>  2 files changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt b/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt
> index 674e133b7cd7..034fc2ba100e 100644
> --- a/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt
> @@ -8,6 +8,7 @@ Required properties:
>  - reg: memory window mapping address and length
>  - clocks: Input clock used to derive the sample clock. Expected to be the
>            SoC's APB clock.
> +- resets: Reset controller phandle
>  - #io-channel-cells: Must be set to <1> to indicate channels are selected
>                       by index.
>
> @@ -15,6 +16,7 @@ Example:
>         adc@1e6e9000 {
>                 compatible = "aspeed,ast2400-adc";
>                 reg = <0x1e6e9000 0xb0>;
> -               clocks = <&clk_apb>;
> +               clocks = <&syscon ASPEED_CLK_APB>;
> +               resets = <&syscon ASPEED_RESET_ADC>;
>                 #io-channel-cells = <1>;
>         };
> diff --git a/drivers/iio/adc/aspeed_adc.c b/drivers/iio/adc/aspeed_adc.c
> index 8a958d5f1905..327a49ba1991 100644
> --- a/drivers/iio/adc/aspeed_adc.c
> +++ b/drivers/iio/adc/aspeed_adc.c
> @@ -17,6 +17,7 @@
>  #include <linux/module.h>
>  #include <linux/of_platform.h>
>  #include <linux/platform_device.h>
> +#include <linux/reset.h>
>  #include <linux/spinlock.h>
>  #include <linux/types.h>
>
> @@ -53,11 +54,12 @@ struct aspeed_adc_model_data {
>  };
>
>  struct aspeed_adc_data {
> -       struct device   *dev;
> -       void __iomem    *base;
> -       spinlock_t      clk_lock;
> -       struct clk_hw   *clk_prescaler;
> -       struct clk_hw   *clk_scaler;
> +       struct device           *dev;
> +       void __iomem            *base;
> +       spinlock_t              clk_lock;
> +       struct clk_hw           *clk_prescaler;
> +       struct clk_hw           *clk_scaler;
> +       struct reset_control    *rst;
>  };
>
>  #define ASPEED_CHAN(_idx, _data_reg_addr) {                    \
> @@ -217,6 +219,15 @@ static int aspeed_adc_probe(struct platform_device *pdev)
>                 goto scaler_error;
>         }
>
> +       data->rst = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> +       if (IS_ERR(data->rst)) {
> +               dev_err(&pdev->dev,
> +                       "invalid or missing reset controller device tree entry");
> +               ret = PTR_ERR(data->rst);
> +               goto reset_error;
> +       }
> +       reset_control_deassert(data->rst);
> +
>         model_data = of_device_get_match_data(&pdev->dev);
>
>         if (model_data->wait_init_sequence) {
> @@ -263,9 +274,10 @@ static int aspeed_adc_probe(struct platform_device *pdev)
>         writel(ASPEED_OPERATION_MODE_POWER_DOWN,
>                 data->base + ASPEED_REG_ENGINE_CONTROL);
>         clk_disable_unprepare(data->clk_scaler->clk);
> +reset_error:
> +       reset_control_assert(data->rst);
>  clk_enable_error:
>         clk_hw_unregister_divider(data->clk_scaler);
> -
>  scaler_error:
>         clk_hw_unregister_divider(data->clk_prescaler);
>         return ret;
> @@ -280,6 +292,7 @@ static int aspeed_adc_remove(struct platform_device *pdev)
>         writel(ASPEED_OPERATION_MODE_POWER_DOWN,
>                 data->base + ASPEED_REG_ENGINE_CONTROL);
>         clk_disable_unprepare(data->clk_scaler->clk);
> +       reset_control_assert(data->rst);
>         clk_hw_unregister_divider(data->clk_scaler);
>         clk_hw_unregister_divider(data->clk_prescaler);
>
> --
> 2.14.1
>

Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe

[Philipp Zabel]

On Tue, Oct 31, 2017 at 3:12 AM, Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org> wrote:
> The ASPEED SoC must deassert a reset in order to use the ADC peripheral.
>
> The device tree bindings are updated to document the resets phandle, and
> the example is updated to match what is expected for both the reset and
> clock phandle. Note that the bindings should have always had the reset
> controller, as the hardware is unusable without it.
>
> Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>

It is unfortunate that this has to break DT (theoretical) backwards
compatibility, but given that the old bindings never worked,
this is better than to pretend a required reset is optional.

Reviewed-by: Philipp Zabel <philipp.zabel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

regards
Philipp

> ---
> v2:
>  - Ensure disabling path unwinds in opposite order as the enable path
>  - Note that the bindings were incorrect without the reset phandle,
>  and for the system to be usable we must update them. No one was
>  (successfully) using these bindings/driver before without out of tree
>  hacks in mach-aspeed, as it would not have worked.
>
>  .../devicetree/bindings/iio/adc/aspeed_adc.txt     |  4 +++-
>  drivers/iio/adc/aspeed_adc.c                       | 25 ++++++++++++++++------
>  2 files changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt b/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt
> index 674e133b7cd7..034fc2ba100e 100644
> --- a/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt
> @@ -8,6 +8,7 @@ Required properties:
>  - reg: memory window mapping address and length
>  - clocks: Input clock used to derive the sample clock. Expected to be the
>            SoC's APB clock.
> +- resets: Reset controller phandle
>  - #io-channel-cells: Must be set to <1> to indicate channels are selected
>                       by index.
>
> @@ -15,6 +16,7 @@ Example:
>         adc@1e6e9000 {
>                 compatible = "aspeed,ast2400-adc";
>                 reg = <0x1e6e9000 0xb0>;
> -               clocks = <&clk_apb>;
> +               clocks = <&syscon ASPEED_CLK_APB>;
> +               resets = <&syscon ASPEED_RESET_ADC>;
>                 #io-channel-cells = <1>;
>         };
> diff --git a/drivers/iio/adc/aspeed_adc.c b/drivers/iio/adc/aspeed_adc.c
> index 8a958d5f1905..327a49ba1991 100644
> --- a/drivers/iio/adc/aspeed_adc.c
> +++ b/drivers/iio/adc/aspeed_adc.c
> @@ -17,6 +17,7 @@
>  #include <linux/module.h>
>  #include <linux/of_platform.h>
>  #include <linux/platform_device.h>
> +#include <linux/reset.h>
>  #include <linux/spinlock.h>
>  #include <linux/types.h>
>
> @@ -53,11 +54,12 @@ struct aspeed_adc_model_data {
>  };
>
>  struct aspeed_adc_data {
> -       struct device   *dev;
> -       void __iomem    *base;
> -       spinlock_t      clk_lock;
> -       struct clk_hw   *clk_prescaler;
> -       struct clk_hw   *clk_scaler;
> +       struct device           *dev;
> +       void __iomem            *base;
> +       spinlock_t              clk_lock;
> +       struct clk_hw           *clk_prescaler;
> +       struct clk_hw           *clk_scaler;
> +       struct reset_control    *rst;
>  };
>
>  #define ASPEED_CHAN(_idx, _data_reg_addr) {                    \
> @@ -217,6 +219,15 @@ static int aspeed_adc_probe(struct platform_device *pdev)
>                 goto scaler_error;
>         }
>
> +       data->rst = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> +       if (IS_ERR(data->rst)) {
> +               dev_err(&pdev->dev,
> +                       "invalid or missing reset controller device tree entry");
> +               ret = PTR_ERR(data->rst);
> +               goto reset_error;
> +       }
> +       reset_control_deassert(data->rst);
> +
>         model_data = of_device_get_match_data(&pdev->dev);
>
>         if (model_data->wait_init_sequence) {
> @@ -263,9 +274,10 @@ static int aspeed_adc_probe(struct platform_device *pdev)
>         writel(ASPEED_OPERATION_MODE_POWER_DOWN,
>                 data->base + ASPEED_REG_ENGINE_CONTROL);
>         clk_disable_unprepare(data->clk_scaler->clk);
> +reset_error:
> +       reset_control_assert(data->rst);
>  clk_enable_error:
>         clk_hw_unregister_divider(data->clk_scaler);
> -
>  scaler_error:
>         clk_hw_unregister_divider(data->clk_prescaler);
>         return ret;
> @@ -280,6 +292,7 @@ static int aspeed_adc_remove(struct platform_device *pdev)
>         writel(ASPEED_OPERATION_MODE_POWER_DOWN,
>                 data->base + ASPEED_REG_ENGINE_CONTROL);
>         clk_disable_unprepare(data->clk_scaler->clk);
> +       reset_control_assert(data->rst);
>         clk_hw_unregister_divider(data->clk_scaler);
>         clk_hw_unregister_divider(data->clk_prescaler);
>
> --
> 2.14.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

Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe

[Joel Stanley]

On Tue, Oct 31, 2017 at 10:28 PM, Philipp Zabel <philipp.zabel@gmail.com> wrote:
> On Tue, Oct 31, 2017 at 3:12 AM, Joel Stanley <joel@jms.id.au> wrote:
>> The ASPEED SoC must deassert a reset in order to use the ADC peripheral.
>>
>> The device tree bindings are updated to document the resets phandle, and
>> the example is updated to match what is expected for both the reset and
>> clock phandle. Note that the bindings should have always had the reset
>> controller, as the hardware is unusable without it.
>>
>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>
> It is unfortunate that this has to break DT (theoretical) backwards
> compatibility, but given that the old bindings never worked,
> this is better than to pretend a required reset is optional.
>
> Reviewed-by: Philipp Zabel <philipp.zabel@gmail.com>

Thanks. I agree that it's unfortunate; this has been my first time
working on an ARM SoC and there were few things we could have done
better in hindsight.

I've got similar patches for the ASPEED hwmon pwm/tach driver, and the
i2c driver that I'll send out now.

Thanks for the review.

Cheers,

Joel

Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe

[Joel Stanley]

On Tue, Oct 31, 2017 at 10:28 PM, Philipp Zabel <philipp.zabel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Tue, Oct 31, 2017 at 3:12 AM, Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org> wrote:
>> The ASPEED SoC must deassert a reset in order to use the ADC peripheral.
>>
>> The device tree bindings are updated to document the resets phandle, and
>> the example is updated to match what is expected for both the reset and
>> clock phandle. Note that the bindings should have always had the reset
>> controller, as the hardware is unusable without it.
>>
>> Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
>
> It is unfortunate that this has to break DT (theoretical) backwards
> compatibility, but given that the old bindings never worked,
> this is better than to pretend a required reset is optional.
>
> Reviewed-by: Philipp Zabel <philipp.zabel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Thanks. I agree that it's unfortunate; this has been my first time
working on an ARM SoC and there were few things we could have done
better in hindsight.

I've got similar patches for the ASPEED hwmon pwm/tach driver, and the
i2c driver that I'll send out now.

Thanks for the review.

Cheers,

Joel
--
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 v2] iio: adc: aspeed: Deassert reset in probe

[Rob Herring]

On Tue, Oct 31, 2017 at 12:42:03PM +1030, Joel Stanley wrote:
> The ASPEED SoC must deassert a reset in order to use the ADC peripheral.
> 
> The device tree bindings are updated to document the resets phandle, and
> the example is updated to match what is expected for both the reset and
> clock phandle. Note that the bindings should have always had the reset
> controller, as the hardware is unusable without it.
> 
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> v2:
>  - Ensure disabling path unwinds in opposite order as the enable path
>  - Note that the bindings were incorrect without the reset phandle,
>  and for the system to be usable we must update them. No one was
>  (successfully) using these bindings/driver before without out of tree
>  hacks in mach-aspeed, as it would not have worked.
> 
>  .../devicetree/bindings/iio/adc/aspeed_adc.txt     |  4 +++-
>  drivers/iio/adc/aspeed_adc.c                       | 25 ++++++++++++++++------
>  2 files changed, 22 insertions(+), 7 deletions(-)

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

Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe

[Jonathan Cameron]

On Wed, 1 Nov 2017 10:15:32 +1030
Joel Stanley <joel@jms.id.au> wrote:

> On Tue, Oct 31, 2017 at 10:28 PM, Philipp Zabel
> <philipp.zabel@gmail.com> wrote:
> > On Tue, Oct 31, 2017 at 3:12 AM, Joel Stanley <joel@jms.id.au>
> > wrote:  
> >> The ASPEED SoC must deassert a reset in order to use the ADC
> >> peripheral.
> >>
> >> The device tree bindings are updated to document the resets
> >> phandle, and the example is updated to match what is expected for
> >> both the reset and clock phandle. Note that the bindings should
> >> have always had the reset controller, as the hardware is unusable
> >> without it.
> >>
> >> Signed-off-by: Joel Stanley <joel@jms.id.au>  
> >
> > It is unfortunate that this has to break DT (theoretical) backwards
> > compatibility, but given that the old bindings never worked,
> > this is better than to pretend a required reset is optional.
> >
> > Reviewed-by: Philipp Zabel <philipp.zabel@gmail.com>  
> 
> Thanks. I agree that it's unfortunate; this has been my first time
> working on an ARM SoC and there were few things we could have done
> better in hindsight.
> 
> I've got similar patches for the ASPEED hwmon pwm/tach driver, and the
> i2c driver that I'll send out now.
> 
> Thanks for the review.
> 
> Cheers,
> 
> Joel
Hi Joel,

IIO is closed for this cycle anyway now.
Otherwise, series looks good.

Will pick up when back with my main PC as traveling for this week and
next.

Thanks,

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

Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe

[Jonathan Cameron]

On Wed, 1 Nov 2017 10:15:32 +1030
Joel Stanley <joel@jms.id.au> wrote:

> On Tue, Oct 31, 2017 at 10:28 PM, Philipp Zabel
> <philipp.zabel@gmail.com> wrote:
> > On Tue, Oct 31, 2017 at 3:12 AM, Joel Stanley <joel@jms.id.au>
> > wrote:  
> >> The ASPEED SoC must deassert a reset in order to use the ADC
> >> peripheral.
> >>
> >> The device tree bindings are updated to document the resets
> >> phandle, and the example is updated to match what is expected for
> >> both the reset and clock phandle. Note that the bindings should
> >> have always had the reset controller, as the hardware is unusable
> >> without it.
> >>
> >> Signed-off-by: Joel Stanley <joel@jms.id.au>  
> >
> > It is unfortunate that this has to break DT (theoretical) backwards
> > compatibility, but given that the old bindings never worked,
> > this is better than to pretend a required reset is optional.
> >
> > Reviewed-by: Philipp Zabel <philipp.zabel@gmail.com>  
> 
> Thanks. I agree that it's unfortunate; this has been my first time
> working on an ARM SoC and there were few things we could have done
> better in hindsight.
> 
> I've got similar patches for the ASPEED hwmon pwm/tach driver, and the
> i2c driver that I'll send out now.
> 
> Thanks for the review.
> 
> Cheers,
> 
> Joel
Hi Joel,

IIO is closed for this cycle anyway now.
Otherwise, series looks good.

Will pick up when back with my main PC as traveling for this week and
next.

Thanks,

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

Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe

[Jonathan Cameron]

On Thu, 2 Nov 2017 14:49:32 +0000
Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:

> On Wed, 1 Nov 2017 10:15:32 +1030
> Joel Stanley <joel@jms.id.au> wrote:
> 
> > On Tue, Oct 31, 2017 at 10:28 PM, Philipp Zabel
> > <philipp.zabel@gmail.com> wrote:  
> > > On Tue, Oct 31, 2017 at 3:12 AM, Joel Stanley <joel@jms.id.au>
> > > wrote:    
> > >> The ASPEED SoC must deassert a reset in order to use the ADC
> > >> peripheral.
> > >>
> > >> The device tree bindings are updated to document the resets
> > >> phandle, and the example is updated to match what is expected for
> > >> both the reset and clock phandle. Note that the bindings should
> > >> have always had the reset controller, as the hardware is unusable
> > >> without it.
> > >>
> > >> Signed-off-by: Joel Stanley <joel@jms.id.au>    
> > >
> > > It is unfortunate that this has to break DT (theoretical) backwards
> > > compatibility, but given that the old bindings never worked,
> > > this is better than to pretend a required reset is optional.
> > >
> > > Reviewed-by: Philipp Zabel <philipp.zabel@gmail.com>    
> > 
> > Thanks. I agree that it's unfortunate; this has been my first time
> > working on an ARM SoC and there were few things we could have done
> > better in hindsight.
> > 
> > I've got similar patches for the ASPEED hwmon pwm/tach driver, and the
> > i2c driver that I'll send out now.
> > 
> > Thanks for the review.
> > 
> > Cheers,
> > 
> > Joel  
> Hi Joel,
> 
> IIO is closed for this cycle anyway now.
> Otherwise, series looks good.
> 
> Will pick up when back with my main PC as traveling for this week and
> next.
Forgot to ask, do you want me to pick this up as a fix?
Also does it make sense to tag it for stable?

If not I can pick it up for the coming cycle. Given the code changes
are small and well isolated I'm happy to do any of the 3 options,
it really depends on whether the rest of the platform works well enough
to be worth rushing these through?

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

Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe

[Jonathan Cameron]

On Thu, 2 Nov 2017 14:49:32 +0000
Jonathan Cameron <Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:

> On Wed, 1 Nov 2017 10:15:32 +1030
> Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org> wrote:
> 
> > On Tue, Oct 31, 2017 at 10:28 PM, Philipp Zabel
> > <philipp.zabel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:  
> > > On Tue, Oct 31, 2017 at 3:12 AM, Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
> > > wrote:    
> > >> The ASPEED SoC must deassert a reset in order to use the ADC
> > >> peripheral.
> > >>
> > >> The device tree bindings are updated to document the resets
> > >> phandle, and the example is updated to match what is expected for
> > >> both the reset and clock phandle. Note that the bindings should
> > >> have always had the reset controller, as the hardware is unusable
> > >> without it.
> > >>
> > >> Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>    
> > >
> > > It is unfortunate that this has to break DT (theoretical) backwards
> > > compatibility, but given that the old bindings never worked,
> > > this is better than to pretend a required reset is optional.
> > >
> > > Reviewed-by: Philipp Zabel <philipp.zabel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>    
> > 
> > Thanks. I agree that it's unfortunate; this has been my first time
> > working on an ARM SoC and there were few things we could have done
> > better in hindsight.
> > 
> > I've got similar patches for the ASPEED hwmon pwm/tach driver, and the
> > i2c driver that I'll send out now.
> > 
> > Thanks for the review.
> > 
> > Cheers,
> > 
> > Joel  
> Hi Joel,
> 
> IIO is closed for this cycle anyway now.
> Otherwise, series looks good.
> 
> Will pick up when back with my main PC as traveling for this week and
> next.
Forgot to ask, do you want me to pick this up as a fix?
Also does it make sense to tag it for stable?

If not I can pick it up for the coming cycle. Given the code changes
are small and well isolated I'm happy to do any of the 3 options,
it really depends on whether the rest of the platform works well enough
to be worth rushing these through?

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

Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe

[Joel Stanley]

On Mon, Nov 20, 2017 at 2:33 AM, Jonathan Cameron <jic23@kernel.org> wrote:
> On Thu, 2 Nov 2017 14:49:32 +0000
> Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
>> IIO is closed for this cycle anyway now.
>> Otherwise, series looks good.
>>
>> Will pick up when back with my main PC as traveling for this week and
>> next.
>
> Forgot to ask, do you want me to pick this up as a fix?
> Also does it make sense to tag it for stable?
>
> If not I can pick it up for the coming cycle. Given the code changes
> are small and well isolated I'm happy to do any of the 3 options,
> it really depends on whether the rest of the platform works well enough
> to be worth rushing these through?

Without the clock driver upstream there's no rush to merge this. I'm
still waiting on review from the clock guys.

Please queue them for 4.16. Thanks!

Cheers,

Joel

Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe

[Joel Stanley]

On Mon, Nov 20, 2017 at 2:33 AM, Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, 2 Nov 2017 14:49:32 +0000
> Jonathan Cameron <Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
>> IIO is closed for this cycle anyway now.
>> Otherwise, series looks good.
>>
>> Will pick up when back with my main PC as traveling for this week and
>> next.
>
> Forgot to ask, do you want me to pick this up as a fix?
> Also does it make sense to tag it for stable?
>
> If not I can pick it up for the coming cycle. Given the code changes
> are small and well isolated I'm happy to do any of the 3 options,
> it really depends on whether the rest of the platform works well enough
> to be worth rushing these through?

Without the clock driver upstream there's no rush to merge this. I'm
still waiting on review from the clock guys.

Please queue them for 4.16. Thanks!

Cheers,

Joel

Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe

[Jonathan Cameron]

On Mon, 20 Nov 2017 15:22:38 +1030
Joel Stanley <joel@jms.id.au> wrote:

> On Mon, Nov 20, 2017 at 2:33 AM, Jonathan Cameron <jic23@kernel.org> wrote:
> > On Thu, 2 Nov 2017 14:49:32 +0000
> > Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:  
> >> IIO is closed for this cycle anyway now.
> >> Otherwise, series looks good.
> >>
> >> Will pick up when back with my main PC as traveling for this week and
> >> next.  
> >
> > Forgot to ask, do you want me to pick this up as a fix?
> > Also does it make sense to tag it for stable?
> >
> > If not I can pick it up for the coming cycle. Given the code changes
> > are small and well isolated I'm happy to do any of the 3 options,
> > it really depends on whether the rest of the platform works well enough
> > to be worth rushing these through?  
> 
> Without the clock driver upstream there's no rush to merge this. I'm
> still waiting on review from the clock guys.
> 
> Please queue them for 4.16. Thanks!
Done - applied to the togreg branch of iio.git which will be pushed
out as testing for the autobuilders to play with it.

Thanks,

Jonathan
> 
> Cheers,
> 
> Joel

Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe

[Jonathan Cameron]

On Mon, 20 Nov 2017 15:22:38 +1030
Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org> wrote:

> On Mon, Nov 20, 2017 at 2:33 AM, Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > On Thu, 2 Nov 2017 14:49:32 +0000
> > Jonathan Cameron <Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:  
> >> IIO is closed for this cycle anyway now.
> >> Otherwise, series looks good.
> >>
> >> Will pick up when back with my main PC as traveling for this week and
> >> next.  
> >
> > Forgot to ask, do you want me to pick this up as a fix?
> > Also does it make sense to tag it for stable?
> >
> > If not I can pick it up for the coming cycle. Given the code changes
> > are small and well isolated I'm happy to do any of the 3 options,
> > it really depends on whether the rest of the platform works well enough
> > to be worth rushing these through?  
> 
> Without the clock driver upstream there's no rush to merge this. I'm
> still waiting on review from the clock guys.
> 
> Please queue them for 4.16. Thanks!
Done - applied to the togreg branch of iio.git which will be pushed
out as testing for the autobuilders to play with it.

Thanks,

Jonathan
> 
> Cheers,
> 
> Joel

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