Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe
On Mon, 20 Nov 2017 15:22:38 +1030 Joel Stanleywrote: > On Mon, Nov 20, 2017 at 2:33 AM, Jonathan Cameron wrote: > > On Thu, 2 Nov 2017 14:49:32 + > > Jonathan Cameron 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
On Mon, 20 Nov 2017 15:22:38 +1030 Joel Stanley wrote: > On Mon, Nov 20, 2017 at 2:33 AM, Jonathan Cameron wrote: > > On Thu, 2 Nov 2017 14:49:32 + > > Jonathan Cameron 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
On Mon, Nov 20, 2017 at 2:33 AM, Jonathan Cameronwrote: > On Thu, 2 Nov 2017 14:49:32 + > Jonathan Cameron 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
On Mon, Nov 20, 2017 at 2:33 AM, Jonathan Cameron wrote: > On Thu, 2 Nov 2017 14:49:32 + > Jonathan Cameron 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
On Thu, 2 Nov 2017 14:49:32 + Jonathan Cameronwrote: > On Wed, 1 Nov 2017 10:15:32 +1030 > Joel Stanley wrote: > > > On Tue, Oct 31, 2017 at 10:28 PM, Philipp Zabel > > wrote: > > > On Tue, Oct 31, 2017 at 3:12 AM, 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 > > > > > > 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 > > > > 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 majord...@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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe
On Thu, 2 Nov 2017 14:49:32 + Jonathan Cameron wrote: > On Wed, 1 Nov 2017 10:15:32 +1030 > Joel Stanley wrote: > > > On Tue, Oct 31, 2017 at 10:28 PM, Philipp Zabel > > wrote: > > > On Tue, Oct 31, 2017 at 3:12 AM, 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 > > > > > > 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 > > > > 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 majord...@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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe
On Wed, 1 Nov 2017 10:15:32 +1030 Joel Stanleywrote: > On Tue, Oct 31, 2017 at 10:28 PM, Philipp Zabel > wrote: > > On Tue, Oct 31, 2017 at 3:12 AM, 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 > > > > 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 > > 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe
On Wed, 1 Nov 2017 10:15:32 +1030 Joel Stanley wrote: > On Tue, Oct 31, 2017 at 10:28 PM, Philipp Zabel > wrote: > > On Tue, Oct 31, 2017 at 3:12 AM, 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 > > > > 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 > > 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe
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> --- > 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
Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe
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 > --- > 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
Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe
On Tue, Oct 31, 2017 at 10:28 PM, Philipp Zabelwrote: > On Tue, Oct 31, 2017 at 3:12 AM, 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 > > 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 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
On Tue, Oct 31, 2017 at 10:28 PM, Philipp Zabel wrote: > On Tue, Oct 31, 2017 at 3:12 AM, 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 > > 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 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
On Tue, Oct 31, 2017 at 3:12 AM, Joel Stanleywrote: > 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 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 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 = <_apb>; > + clocks = < ASPEED_CLK_APB>; > + resets = < 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 > #include > #include > +#include > #include > #include > > @@ -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(>dev, NULL); > + if (IS_ERR(data->rst)) { > + dev_err(>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(>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
On Tue, Oct 31, 2017 at 3:12 AM, 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 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 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 = <_apb>; > + clocks = < ASPEED_CLK_APB>; > + resets = < 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 > #include > #include > +#include > #include > #include > > @@ -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(>dev, NULL); > + if (IS_ERR(data->rst)) { > + dev_err(>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(>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 >
[PATCH v2] iio: adc: aspeed: Deassert reset in probe
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--- 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 = <_apb>; + clocks = < ASPEED_CLK_APB>; + resets = < 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 #include #include +#include #include #include @@ -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(>dev, NULL); + if (IS_ERR(data->rst)) { + dev_err(>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(>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
[PATCH v2] iio: adc: aspeed: Deassert reset in probe
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 --- 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 = <_apb>; + clocks = < ASPEED_CLK_APB>; + resets = < 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 #include #include +#include #include #include @@ -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(>dev, NULL); + if (IS_ERR(data->rst)) { + dev_err(>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(>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