diff mbox

ARM: dts: n900: Include adp1653 device

Message ID 1451086812-3729-1-git-send-email-pali.rohar@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Pali Rohár Dec. 25, 2015, 11:40 p.m. UTC
This patch adds adp1653 device into n900 DT structure. DT support in
adp1653 driver is there since v4.2-rc1 version.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
 arch/arm/boot/dts/omap3-n900.dts |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

Comments

Pavel Machek Dec. 26, 2015, 6:35 p.m. UTC | #1
On Sat 2015-12-26 00:40:12, Pali Rohár wrote:
> This patch adds adp1653 device into n900 DT structure. DT support in
> adp1653 driver is there since v4.2-rc1 version.
> 
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>

Acked-by: Pavel Machek <pavel@ucw.cz>
Pali Rohár Jan. 9, 2016, 10:38 p.m. UTC | #2
On Saturday 26 December 2015 00:40:12 Pali Rohár wrote:
> This patch adds adp1653 device into n900 DT structure. DT support in
> adp1653 driver is there since v4.2-rc1 version.
> 
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
>  arch/arm/boot/dts/omap3-n900.dts |   15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap3-n900.dts
> b/arch/arm/boot/dts/omap3-n900.dts index 5f5e0f3..ba93642 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -522,6 +522,21 @@
>  		amstaos,cover-comp-gain = <16>;
>  	};
> 
> +	adp1653: led-controller@30 {
> +		compatible = "adi,adp1653";
> +		reg = <0x30>;
> +		enable-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
> +
> +		flash {
> +			flash-timeout-us = <500000>;
> +			flash-max-microamp = <320000>;
> +			led-max-microamp = <50000>;
> +		};
> +		indicator {
> +			led-max-microamp = <17500>;
> +		};
> +	};
> +
>  	lp5523: lp5523@32 {
>  		compatible = "national,lp5523";
>  		reg = <0x32>;

Tony, can you take this patch?
Pali Rohár Jan. 21, 2016, 9:12 a.m. UTC | #3
On Saturday 26 December 2015 00:40:12 Pali Rohár wrote:
> This patch adds adp1653 device into n900 DT structure. DT support in
> adp1653 driver is there since v4.2-rc1 version.
> 
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
>  arch/arm/boot/dts/omap3-n900.dts |   15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> index 5f5e0f3..ba93642 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -522,6 +522,21 @@
>  		amstaos,cover-comp-gain = <16>;
>  	};
>  
> +	adp1653: led-controller@30 {
> +		compatible = "adi,adp1653";
> +		reg = <0x30>;
> +		enable-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
> +
> +		flash {
> +			flash-timeout-us = <500000>;
> +			flash-max-microamp = <320000>;
> +			led-max-microamp = <50000>;
> +		};
> +		indicator {
> +			led-max-microamp = <17500>;
> +		};
> +	};
> +
>  	lp5523: lp5523@32 {
>  		compatible = "national,lp5523";
>  		reg = <0x32>;

PING, who can take this patch?

I still do not see it in linus tree nor in others like arm-soc...
Russell King - ARM Linux Jan. 21, 2016, 9:29 a.m. UTC | #4
The merge window is open, which is when development code that was merged
in good time prior to the merge window is sent upstream to Linus.  Linux
maintainers may choose not to merge new code into their tree to avoid
disrupting the utility of linux-next until the merge window has closed.

linux-next is an integration tree to help find merge conflicts, it
exists to assist with the merge windows, not as a general test ground.
Thus, linux-next must only contain code for either the current open
merge window, or if the merge window is closed, the next merge window.

On Thu, Jan 21, 2016 at 10:12:41AM +0100, Pali Rohár wrote:
> On Saturday 26 December 2015 00:40:12 Pali Rohár wrote:
> > This patch adds adp1653 device into n900 DT structure. DT support in
> > adp1653 driver is there since v4.2-rc1 version.
> > 
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > ---
> >  arch/arm/boot/dts/omap3-n900.dts |   15 +++++++++++++++
> >  1 file changed, 15 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> > index 5f5e0f3..ba93642 100644
> > --- a/arch/arm/boot/dts/omap3-n900.dts
> > +++ b/arch/arm/boot/dts/omap3-n900.dts
> > @@ -522,6 +522,21 @@
> >  		amstaos,cover-comp-gain = <16>;
> >  	};
> >  
> > +	adp1653: led-controller@30 {
> > +		compatible = "adi,adp1653";
> > +		reg = <0x30>;
> > +		enable-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
> > +
> > +		flash {
> > +			flash-timeout-us = <500000>;
> > +			flash-max-microamp = <320000>;
> > +			led-max-microamp = <50000>;
> > +		};
> > +		indicator {
> > +			led-max-microamp = <17500>;
> > +		};
> > +	};
> > +
> >  	lp5523: lp5523@32 {
> >  		compatible = "national,lp5523";
> >  		reg = <0x32>;
> 
> PING, who can take this patch?
> 
> I still do not see it in linus tree nor in others like arm-soc...
> 
> -- 
> Pali Rohár
> pali.rohar@gmail.com
Pali Rohár Jan. 21, 2016, 9:50 a.m. UTC | #5
Ok, but for whole month I do not see any response that somebody take
this patch into some queue or tree. Which could means that patch was
either ignored or is living somewhere and could be lost.

On Thursday 21 January 2016 09:29:10 Russell King - ARM Linux wrote:
> The merge window is open, which is when development code that was merged
> in good time prior to the merge window is sent upstream to Linus.  Linux
> maintainers may choose not to merge new code into their tree to avoid
> disrupting the utility of linux-next until the merge window has closed.
> 
> linux-next is an integration tree to help find merge conflicts, it
> exists to assist with the merge windows, not as a general test ground.
> Thus, linux-next must only contain code for either the current open
> merge window, or if the merge window is closed, the next merge window.
> 
> On Thu, Jan 21, 2016 at 10:12:41AM +0100, Pali Rohár wrote:
> > On Saturday 26 December 2015 00:40:12 Pali Rohár wrote:
> > > This patch adds adp1653 device into n900 DT structure. DT support in
> > > adp1653 driver is there since v4.2-rc1 version.
> > > 
> > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > ---
> > >  arch/arm/boot/dts/omap3-n900.dts |   15 +++++++++++++++
> > >  1 file changed, 15 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> > > index 5f5e0f3..ba93642 100644
> > > --- a/arch/arm/boot/dts/omap3-n900.dts
> > > +++ b/arch/arm/boot/dts/omap3-n900.dts
> > > @@ -522,6 +522,21 @@
> > >  		amstaos,cover-comp-gain = <16>;
> > >  	};
> > >  
> > > +	adp1653: led-controller@30 {
> > > +		compatible = "adi,adp1653";
> > > +		reg = <0x30>;
> > > +		enable-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
> > > +
> > > +		flash {
> > > +			flash-timeout-us = <500000>;
> > > +			flash-max-microamp = <320000>;
> > > +			led-max-microamp = <50000>;
> > > +		};
> > > +		indicator {
> > > +			led-max-microamp = <17500>;
> > > +		};
> > > +	};
> > > +
> > >  	lp5523: lp5523@32 {
> > >  		compatible = "national,lp5523";
> > >  		reg = <0x32>;
> > 
> > PING, who can take this patch?
> > 
> > I still do not see it in linus tree nor in others like arm-soc...
> > 
> > -- 
> > Pali Rohár
> > pali.rohar@gmail.com
>
Russell King - ARM Linux Jan. 21, 2016, 10:03 a.m. UTC | #6
On Thu, Jan 21, 2016 at 10:50:04AM +0100, Pali Rohár wrote:
> Ok, but for whole month I do not see any response that somebody take
> this patch into some queue or tree. Which could means that patch was
> either ignored or is living somewhere and could be lost.

You sent it the day after Christmas day, when people were most likely
on their Christmas break doing family stuff, and there was only one
week after the traditional Christmas/New year break before the merge
window opened.

So, discounting Christmas and the merge window, your patch has only
been around for one week - a week where maintainers would have been
stabilising their tree(s) in preparation for the merge window opening.

Please be patient; the merge window closes this Sunday, and I suspect
"normal service" will be resumed shortly thereafter.
Pavel Machek Jan. 21, 2016, 10:18 a.m. UTC | #7
On Thu 2016-01-21 09:29:10, Russell King - ARM Linux wrote:
> The merge window is open, which is when development code that was merged
> in good time prior to the merge window is sent upstream to Linus.  Linux
> maintainers may choose not to merge new code into their tree to avoid
> disrupting the utility of linux-next until the merge window has
> closed.

Support for new hardware is normally allowed after -rc1.
									Pavel
Tony Lindgren Jan. 21, 2016, 4:38 p.m. UTC | #8
* Pavel Machek <pavel@ucw.cz> [160121 02:19]:
> On Thu 2016-01-21 09:29:10, Russell King - ARM Linux wrote:
> > The merge window is open, which is when development code that was merged
> > in good time prior to the merge window is sent upstream to Linus.  Linux
> > maintainers may choose not to merge new code into their tree to avoid
> > disrupting the utility of linux-next until the merge window has
> > closed.
> 
> Support for new hardware is normally allowed after -rc1.

Yeah most maintainers avoid looking at new code until -rc1. Or until
regresssions are out of the way. So patience please. Fixes are
welcome any time though.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Russell King - ARM Linux Jan. 21, 2016, 4:54 p.m. UTC | #9
On Thu, Jan 21, 2016 at 08:38:57AM -0800, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [160121 02:19]:
> > On Thu 2016-01-21 09:29:10, Russell King - ARM Linux wrote:
> > > The merge window is open, which is when development code that was merged
> > > in good time prior to the merge window is sent upstream to Linus.  Linux
> > > maintainers may choose not to merge new code into their tree to avoid
> > > disrupting the utility of linux-next until the merge window has
> > > closed.
> > 
> > Support for new hardware is normally allowed after -rc1.
> 
> Yeah most maintainers avoid looking at new code until -rc1. Or until
> regresssions are out of the way. So patience please. Fixes are
> welcome any time though.

Indeed.  However, unlike Pavel's comment, many maintainers choose not
to merge code for new hardware until the merge window - it's very rare
that support for new hardware is merged during the -rc phase.

If it were otherwise, I would've been able to get the Hummingboard 2
DTS patches in, or the etnaviv team would've been able to get the
Etnaviv GPU DRM driver in during the 4.4-rc cycle, or the Dove PMU
driver, or... etc.

Practically, new code waits for merge windows, because no one wants
to de-stabilise the progression of the -rc series with new code, and
Linus wants to see -rc merges fairly quiet and be mostly bug fixes
so he can feel good about a final release around -rc6 to -rc7 time.
Pali Rohár Jan. 27, 2016, 10:02 a.m. UTC | #10
On Thursday 21 January 2016 16:54:08 Russell King - ARM Linux wrote:
> On Thu, Jan 21, 2016 at 08:38:57AM -0800, Tony Lindgren wrote:
> > * Pavel Machek <pavel@ucw.cz> [160121 02:19]:
> > > On Thu 2016-01-21 09:29:10, Russell King - ARM Linux wrote:
> > > > The merge window is open, which is when development code that was merged
> > > > in good time prior to the merge window is sent upstream to Linus.  Linux
> > > > maintainers may choose not to merge new code into their tree to avoid
> > > > disrupting the utility of linux-next until the merge window has
> > > > closed.
> > > 
> > > Support for new hardware is normally allowed after -rc1.
> > 
> > Yeah most maintainers avoid looking at new code until -rc1. Or until
> > regresssions are out of the way. So patience please. Fixes are
> > welcome any time though.
> 
> Indeed.  However, unlike Pavel's comment, many maintainers choose not
> to merge code for new hardware until the merge window - it's very rare
> that support for new hardware is merged during the -rc phase.
> 
> If it were otherwise, I would've been able to get the Hummingboard 2
> DTS patches in, or the etnaviv team would've been able to get the
> Etnaviv GPU DRM driver in during the 4.4-rc cycle, or the Dove PMU
> driver, or... etc.
> 
> Practically, new code waits for merge windows, because no one wants
> to de-stabilise the progression of the -rc series with new code, and
> Linus wants to see -rc merges fairly quiet and be mostly bug fixes
> so he can feel good about a final release around -rc6 to -rc7 time.
> 

In my opinion this patch is not support for new hardware. It just add
missing DT definition for one specific board for HW which was added to
linux kernel in v4.2-rc1 version. For me it looks like that needed DT
definition was forgotten...
Russell King - ARM Linux Jan. 27, 2016, 11:18 a.m. UTC | #11
On Wed, Jan 27, 2016 at 11:02:37AM +0100, Pali Rohár wrote:
> In my opinion this patch is not support for new hardware. It just add
> missing DT definition for one specific board for HW which was added to
> linux kernel in v4.2-rc1 version. For me it looks like that needed DT
> definition was forgotten...

Opinions differ, but ultimately it's up to whoever is responsible for
accepting the patch, and in the case of ARM SoC based patches, the
arm-soc maintainers.

The arm-soc maintainers close their trees for development changes a
few weeks before hand (a patch of mine which was acked etc by 7th
December never made the 4.5 merge window either, and the alleged
reason I've been told is because arm-soc was already closed by then).
Tony Lindgren Jan. 27, 2016, 4:24 p.m. UTC | #12
* Russell King - ARM Linux <linux@arm.linux.org.uk> [160127 03:19]:
> On Wed, Jan 27, 2016 at 11:02:37AM +0100, Pali Rohár wrote:
> > In my opinion this patch is not support for new hardware. It just add
> > missing DT definition for one specific board for HW which was added to
> > linux kernel in v4.2-rc1 version. For me it looks like that needed DT
> > definition was forgotten...
> 
> Opinions differ, but ultimately it's up to whoever is responsible for
> accepting the patch, and in the case of ARM SoC based patches, the
> arm-soc maintainers.

Yeah. Sorry for long delay as discussed. I'm applying the $subject
patch finally into omap-for-v4.6/dt today.

We still have at least two fixes left to go that both affect also
n900. But at least I can now sanely test adding new stuff with a WIP
fix for the PM runtime regression.

> The arm-soc maintainers close their trees for development changes a
> few weeks before hand (a patch of mine which was acked etc by 7th
> December never made the 4.5 merge window either, and the alleged
> reason I've been told is because arm-soc was already closed by then).

Heh I too have some pending clock framework patches from December
that I did not repost yet as the maintainers notified that they
rather not take new stuff any longer for v4.5 before the holidays.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 5f5e0f3..ba93642 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -522,6 +522,21 @@ 
 		amstaos,cover-comp-gain = <16>;
 	};
 
+	adp1653: led-controller@30 {
+		compatible = "adi,adp1653";
+		reg = <0x30>;
+		enable-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
+
+		flash {
+			flash-timeout-us = <500000>;
+			flash-max-microamp = <320000>;
+			led-max-microamp = <50000>;
+		};
+		indicator {
+			led-max-microamp = <17500>;
+		};
+	};
+
 	lp5523: lp5523@32 {
 		compatible = "national,lp5523";
 		reg = <0x32>;