All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antoine Tenart <antoine.tenart@free-electrons.com>
To: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Antoine Tenart <antoine.tenart@free-electrons.com>,
	jic23@kernel.org, knaack.h@gmx.de, lars@metafoo.de,
	pmeerw@pmeerw.net, zmxu@marvell.com, jszhang@marvell.com,
	yrliao@marvell.com, linux-iio@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/4] ARM: berlin: add an ADC node for the BG2Q
Date: Tue, 7 Apr 2015 12:20:11 +0200	[thread overview]
Message-ID: <20150407102011.GA19914@kwain> (raw)
In-Reply-To: <551FBC34.4070501@gmail.com>

Sebastian,

On Sat, Apr 04, 2015 at 12:25:56PM +0200, Sebastian Hesselbarth wrote:
> On 03.04.2015 15:06, Antoine Tenart wrote:
> >This patch adds the ADC node for the Berlin BG2Q, using the newly added
> >Berlin IIO ADC driver.
> >
> >Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> >---
> >  arch/arm/boot/dts/berlin2q.dtsi | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> >
> >diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
> >index 187d056f7ad2..72b1c969a99d 100644
> >--- a/arch/arm/boot/dts/berlin2q.dtsi
> >+++ b/arch/arm/boot/dts/berlin2q.dtsi
> >@@ -565,6 +565,14 @@
> >  						function = "twsi3";
> >  					};
> >  				};
> >+
> >+				adc: adc {
> >+					compatible = "marvell,berlin2-adc";
> >+					interrupt-parent = <&sic>;
> >+					interrupts = <12>, <14>;
> >+					interrupt-names = "adc", "tsen";
> >+					status = "disabled";
> >+				};
> 
> nit: there is no gated clock for the ADC, I guess we can just always
> enable it. That will save you the last patch of the series.

Sure, we can just drop the last patch (and the status property).

> BTW, I have the strong feeling that moving berlin's clk drivers to
> regmap will block any subsequent patches you are preparing. How about
> we target the next merge window for moving the clk node but not the
> drivers (except of_iomap of the _parent's_ reg property) and push the
> less controversal patches (pinctrl, reset) with regmap/syscon forward?

The entire clock rework series does not affect this ADC series or any
other on going series. It can be merged latter, without breaking
anything. I just realized I mentioned the clock rework series as a
dependency in the cover letter of this series but it is not, my bad.

So, we can target the next merge window for all series but the clock
rework. In addition to this, I can send a series moving the clock node,
with minor modifications to the driver so we have a proper dt. And then
we can see if moving to a regmap aware clock driver can be done.

To sum up:
- chip/system controller series can be pushed
- this ADC series too, as it does not depend on the clock rework (as
  soon as we have the needed acked-by)
- I need to make a new series to move the clock node
- the clock driver rework series can live in parallel

Agreed?

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

WARNING: multiple messages have this Message-ID (diff)
From: antoine.tenart@free-electrons.com (Antoine Tenart)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/4] ARM: berlin: add an ADC node for the BG2Q
Date: Tue, 7 Apr 2015 12:20:11 +0200	[thread overview]
Message-ID: <20150407102011.GA19914@kwain> (raw)
In-Reply-To: <551FBC34.4070501@gmail.com>

Sebastian,

On Sat, Apr 04, 2015 at 12:25:56PM +0200, Sebastian Hesselbarth wrote:
> On 03.04.2015 15:06, Antoine Tenart wrote:
> >This patch adds the ADC node for the Berlin BG2Q, using the newly added
> >Berlin IIO ADC driver.
> >
> >Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> >---
> >  arch/arm/boot/dts/berlin2q.dtsi | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> >
> >diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
> >index 187d056f7ad2..72b1c969a99d 100644
> >--- a/arch/arm/boot/dts/berlin2q.dtsi
> >+++ b/arch/arm/boot/dts/berlin2q.dtsi
> >@@ -565,6 +565,14 @@
> >  						function = "twsi3";
> >  					};
> >  				};
> >+
> >+				adc: adc {
> >+					compatible = "marvell,berlin2-adc";
> >+					interrupt-parent = <&sic>;
> >+					interrupts = <12>, <14>;
> >+					interrupt-names = "adc", "tsen";
> >+					status = "disabled";
> >+				};
> 
> nit: there is no gated clock for the ADC, I guess we can just always
> enable it. That will save you the last patch of the series.

Sure, we can just drop the last patch (and the status property).

> BTW, I have the strong feeling that moving berlin's clk drivers to
> regmap will block any subsequent patches you are preparing. How about
> we target the next merge window for moving the clk node but not the
> drivers (except of_iomap of the _parent's_ reg property) and push the
> less controversal patches (pinctrl, reset) with regmap/syscon forward?

The entire clock rework series does not affect this ADC series or any
other on going series. It can be merged latter, without breaking
anything. I just realized I mentioned the clock rework series as a
dependency in the cover letter of this series but it is not, my bad.

So, we can target the next merge window for all series but the clock
rework. In addition to this, I can send a series moving the clock node,
with minor modifications to the driver so we have a proper dt. And then
we can see if moving to a regmap aware clock driver can be done.

To sum up:
- chip/system controller series can be pushed
- this ADC series too, as it does not depend on the clock rework (as
  soon as we have the needed acked-by)
- I need to make a new series to move the clock node
- the clock driver rework series can live in parallel

Agreed?

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  reply	other threads:[~2015-04-07 10:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-03 13:06 [PATCH v2 0/4] ARM: berlin: ADC support Antoine Tenart
2015-04-03 13:06 ` Antoine Tenart
2015-04-03 13:06 ` [PATCH v2 1/4] iio: adc: add support for Berlin Antoine Tenart
2015-04-03 13:06   ` Antoine Tenart
2015-04-09 13:58   ` Jonathan Cameron
2015-04-09 13:58     ` Jonathan Cameron
2015-04-03 13:06 ` [PATCH v2 2/4] Documentation: bindings: document the Berlin ADC driver Antoine Tenart
2015-04-03 13:06   ` Antoine Tenart
2015-04-09 14:00   ` Jonathan Cameron
2015-04-09 14:00     ` Jonathan Cameron
2015-04-03 13:06 ` [PATCH v2 3/4] ARM: berlin: add an ADC node for the BG2Q Antoine Tenart
2015-04-03 13:06   ` Antoine Tenart
2015-04-04 10:25   ` Sebastian Hesselbarth
2015-04-04 10:25     ` Sebastian Hesselbarth
2015-04-07 10:20     ` Antoine Tenart [this message]
2015-04-07 10:20       ` Antoine Tenart
2015-04-07 10:25       ` Sebastian Hesselbarth
2015-04-07 10:25         ` Sebastian Hesselbarth
2015-04-03 13:06 ` [PATCH v2 4/4] ARM: berlin: enable the ADC on the BG2Q DMP Antoine Tenart
2015-04-03 13:06   ` Antoine Tenart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150407102011.GA19914@kwain \
    --to=antoine.tenart@free-electrons.com \
    --cc=jic23@kernel.org \
    --cc=jszhang@marvell.com \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=yrliao@marvell.com \
    --cc=zmxu@marvell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.