[PATCH 0/4] ARM: mvebu: minor Armada 370 RD improvements

[PATCH 0/4] ARM: mvebu: minor Armada 370 RD improvements

[Thomas Petazzoni]

Jason, Andrew, Gregory, Sebastian,

Here are four small patches to make minor improvements to the support
of the Armada 370 RD platform.

Thanks,

Thomas

Thomas Petazzoni (4):
  ARM: mvebu: add gpio fan support to Armada 370 RD
  ARM: mvebu: add user LED support of Armada 370 RD
  ARM: mvebu: add LED class support built-in in mvebu_v7_defconfig
  ARM: mvebu: add gpio-fan to mvebu_v7_defconfig

 arch/arm/boot/dts/armada-370-rd.dts | 32 ++++++++++++++++++++++++++++++++
 arch/arm/configs/mvebu_v7_defconfig |  3 ++-
 2 files changed, 34 insertions(+), 1 deletion(-)

-- 
2.0.0

[PATCH 1/4] ARM: mvebu: add gpio fan support to Armada 370 RD

[Thomas Petazzoni]

The Armada 370 RD platform has a GPIO-controlled fan on MPP8, so this
commit adds the relevant hardware description to Armada 370 RD Device
Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/boot/dts/armada-370-rd.dts | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index 4169f40..7af04c4 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -50,6 +50,13 @@
 		};
 
 		internal-regs {
+			pinctrl {
+				fan_pins: fan-pins {
+					marvell,pins = "mpp8";
+					marvell,function = "gpio";
+				};
+			};
+
 			serial at 12000 {
 				status = "okay";
 			};
@@ -106,6 +113,14 @@
 				};
 			};
 
+			gpio-fan {
+				compatible = "gpio-fan";
+				gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
+				gpio-fan,speed-map = <0 0 3000 1>;
+				pinctrl-0 = <&fan_pins>;
+				pinctrl-names = "default";
+			};
+
 			nand at d0000 {
 				status = "okay";
 				num-cs = <1>;
-- 
2.0.0

[PATCH 2/4] ARM: mvebu: add user LED support of Armada 370 RD

[Thomas Petazzoni]

The Armada 370 RD has a GPIO controlled LED connected on MPP32, so
this commit adds the relevant hardware description to Armada 370 RD
Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/boot/dts/armada-370-rd.dts | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index 7af04c4..10a6448 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -55,6 +55,11 @@
 					marvell,pins = "mpp8";
 					marvell,function = "gpio";
 				};
+
+				led_pins: led-pins {
+					marvell,pins = "mpp32";
+					marvell,function = "gpio";
+				};
 			};
 
 			serial at 12000 {
@@ -121,6 +126,18 @@
 				pinctrl-names = "default";
 			};
 
+			gpio_leds {
+				compatible = "gpio-leds";
+				pinctrl-names = "default";
+				pinctrl-0 = <&led_pins>;
+
+				sw_led {
+					label = "370rd:green:sw";
+					gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
+					default-state = "keep";
+				};
+			};
+
 			nand at d0000 {
 				status = "okay";
 				num-cs = <1>;
-- 
2.0.0

[PATCH 3/4] ARM: mvebu: add LED class support built-in in mvebu_v7_defconfig

[Thomas Petazzoni]

For some reason, while all other features are configured built-in, the
LED class support was configured as a module in
mvebu_v7_defconfig. This commit makes it consistent with the other
options, by making this feature built-in.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/configs/mvebu_v7_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
index fdfda1f..3469c3d9 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -98,7 +98,7 @@ CONFIG_MMC_SDHCI_PXAV3=y
 CONFIG_MMC_MVSDIO=y
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_GPIO=y
-CONFIG_LEDS_CLASS=m
+CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_TIMER=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
-- 
2.0.0

[PATCH 4/4] ARM: mvebu: add gpio-fan to mvebu_v7_defconfig

[Thomas Petazzoni]

Since one of the platforms (Armada 370 RD) is now using the gpio-fan
driver, it makes sense to enable it in mvebu_v7_defconfig.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/configs/mvebu_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
index 3469c3d9..61ef899 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -77,6 +77,7 @@ CONFIG_MTD_NAND_PXA3xx=y
 CONFIG_SERIAL_8250_DW=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIO_SYSFS=y
+CONFIG_SENSORS_GPIO_FAN=y
 CONFIG_THERMAL=y
 CONFIG_ARMADA_THERMAL=y
 CONFIG_SOUND=y
-- 
2.0.0

[PATCH 0/4] ARM: mvebu: minor Armada 370 RD improvements

[Andrew Lunn]

On Thu, Sep 11, 2014 at 11:56:55AM +0200, Thomas Petazzoni wrote:
> Jason, Andrew, Gregory, Sebastian,
> 
> Here are four small patches to make minor improvements to the support
> of the Armada 370 RD platform.

All looks O.K. to me

Acked-by: Andrew Lunn <andrew@lunn.ch>

A point for discussion, triggered by 3/4. We have repeatedly seen
issues with modular builds, which we don't see with everything built
in. Can we improve our testing? Is there is way to take for example
mvebu_v7_defconfig and turn any y tristate options into m? Build and
boot? Get this added to the boot test farms?

      Andrew

> 
> Thanks,
> 
> Thomas
> 
> Thomas Petazzoni (4):
>   ARM: mvebu: add gpio fan support to Armada 370 RD
>   ARM: mvebu: add user LED support of Armada 370 RD
>   ARM: mvebu: add LED class support built-in in mvebu_v7_defconfig
>   ARM: mvebu: add gpio-fan to mvebu_v7_defconfig
> 
>  arch/arm/boot/dts/armada-370-rd.dts | 32 ++++++++++++++++++++++++++++++++
>  arch/arm/configs/mvebu_v7_defconfig |  3 ++-
>  2 files changed, 34 insertions(+), 1 deletion(-)
> 
> -- 
> 2.0.0
> 

[PATCH 0/4] ARM: mvebu: minor Armada 370 RD improvements

[Thomas Petazzoni]

Dear Andrew Lunn,

On Thu, 11 Sep 2014 15:43:23 +0200, Andrew Lunn wrote:

> All looks O.K. to me
> 
> Acked-by: Andrew Lunn <andrew@lunn.ch>

Thanks!

> A point for discussion, triggered by 3/4. We have repeatedly seen
> issues with modular builds, which we don't see with everything built
> in. Can we improve our testing? Is there is way to take for example
> mvebu_v7_defconfig and turn any y tristate options into m? Build and
> boot? Get this added to the boot test farms?

I indeed agree that we are not testing much the modular case, but:

 1/ In my case, a mvebu_v7_defconfig where most the stuff would become
    enabled as a module would make mvebu_v7_defconfig pretty much
    useless for my daily work. When I'm doing active development, I
    typically have everything built-in including the initramfs itself,
    so that I don't rely on any storage/network to get the rootfs and
    additional kernel drivers.

 2/ I don't think it would change much in terms of runtime coverage:
    the tests done on the boot farm are just boot tests, I don't think
    they load any kernel module. We could ask Kevin and Olof what
    rootfs they use, but most likely it's some very small rootfs that
    doesn't even have udev/mdev for automatic module loading. So no
    module would be loaded, which would mean that a mvebu_v7_defconfig
    with everything as a module would actually test *less* thing than a
    configuration that has everything built in.

So, I agree on the observation, but I'm unsure the proposed solution
will really solve or even improve the situation :/

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 0/4] ARM: mvebu: minor Armada 370 RD improvements

[Jason Cooper]

+Ian

On Thu, Sep 11, 2014 at 04:00:00PM +0200, Thomas Petazzoni wrote:
> On Thu, 11 Sep 2014 15:43:23 +0200, Andrew Lunn wrote:
> > A point for discussion, triggered by 3/4. We have repeatedly seen
> > issues with modular builds, which we don't see with everything built
> > in. Can we improve our testing? Is there is way to take for example
> > mvebu_v7_defconfig and turn any y tristate options into m? Build and
> > boot? Get this added to the boot test farms?
> 
> I indeed agree that we are not testing much the modular case, but:
> 
>  1/ In my case, a mvebu_v7_defconfig where most the stuff would become
>     enabled as a module would make mvebu_v7_defconfig pretty much
>     useless for my daily work. When I'm doing active development, I
>     typically have everything built-in including the initramfs itself,
>     so that I don't rely on any storage/network to get the rootfs and
>     additional kernel drivers.
> 
>  2/ I don't think it would change much in terms of runtime coverage:
>     the tests done on the boot farm are just boot tests, I don't think
>     they load any kernel module. We could ask Kevin and Olof what
>     rootfs they use, but most likely it's some very small rootfs that
>     doesn't even have udev/mdev for automatic module loading. So no
>     module would be loaded, which would mean that a mvebu_v7_defconfig
>     with everything as a module would actually test *less* thing than a
>     configuration that has everything built in.
> 
> So, I agree on the observation, but I'm unsure the proposed solution
> will really solve or even improve the situation :/

Since debian does modular builds on a regular basis, maybe they have
some recommendations.

My thought is that I doubt we're the only SoC family with this issue.
To avoid the maintenance headache of extra _mod_defconfig's, perhaps we
could add a ./scripts/config toggle to turn the current .config enabled
tristates into modules?

thx,

Jason.

[PATCH 0/4] ARM: mvebu: minor Armada 370 RD improvements

[Jason Cooper]

merf.  It helps if I actually _add_ Ian to the Cc. :)

On Thu, Sep 11, 2014 at 10:26:01AM -0400, Jason Cooper wrote:
> +Ian
> 
> On Thu, Sep 11, 2014 at 04:00:00PM +0200, Thomas Petazzoni wrote:
> > On Thu, 11 Sep 2014 15:43:23 +0200, Andrew Lunn wrote:
> > > A point for discussion, triggered by 3/4. We have repeatedly seen
> > > issues with modular builds, which we don't see with everything built
> > > in. Can we improve our testing? Is there is way to take for example
> > > mvebu_v7_defconfig and turn any y tristate options into m? Build and
> > > boot? Get this added to the boot test farms?
> > 
> > I indeed agree that we are not testing much the modular case, but:
> > 
> >  1/ In my case, a mvebu_v7_defconfig where most the stuff would become
> >     enabled as a module would make mvebu_v7_defconfig pretty much
> >     useless for my daily work. When I'm doing active development, I
> >     typically have everything built-in including the initramfs itself,
> >     so that I don't rely on any storage/network to get the rootfs and
> >     additional kernel drivers.
> > 
> >  2/ I don't think it would change much in terms of runtime coverage:
> >     the tests done on the boot farm are just boot tests, I don't think
> >     they load any kernel module. We could ask Kevin and Olof what
> >     rootfs they use, but most likely it's some very small rootfs that
> >     doesn't even have udev/mdev for automatic module loading. So no
> >     module would be loaded, which would mean that a mvebu_v7_defconfig
> >     with everything as a module would actually test *less* thing than a
> >     configuration that has everything built in.
> > 
> > So, I agree on the observation, but I'm unsure the proposed solution
> > will really solve or even improve the situation :/
> 
> Since debian does modular builds on a regular basis, maybe they have
> some recommendations.
> 
> My thought is that I doubt we're the only SoC family with this issue.
> To avoid the maintenance headache of extra _mod_defconfig's, perhaps we
> could add a ./scripts/config toggle to turn the current .config enabled
> tristates into modules?
> 
> thx,
> 
> Jason.

[PATCH 0/4] ARM: mvebu: minor Armada 370 RD improvements

[Andrew Lunn]

> > Since debian does modular builds on a regular basis, maybe they have
> > some recommendations.
> > 
> > My thought is that I doubt we're the only SoC family with this issue.
> > To avoid the maintenance headache of extra _mod_defconfig's, perhaps we
> > could add a ./scripts/config toggle to turn the current .config enabled
> > tristates into modules?

As Thomas pointed out, that is probably the easy bit. We need a test
system which has access to these modules, and udev in order to get
them loaded. Do any of the current boot farms support this?

What might be possible is to work on top of the new test initiative,
kicked off at the last summit.  That is going to need a more capable
rootfs, so might provide a usable basis. We also need some tests, so
that once we have finished booting, do we at least have all the
devices we expect in /sys. That would of at least found the recent SPI
FLASH breakage.

      Andrew

[PATCH 0/4] ARM: mvebu: minor Armada 370 RD improvements

[Ian Campbell]

On Thu, 2014-09-11 at 10:26 -0400, Jason Cooper wrote:
> merf.  It helps if I actually _add_ Ian to the Cc. :)
> 
> On Thu, Sep 11, 2014 at 10:26:01AM -0400, Jason Cooper wrote:
> > +Ian
> > 
> > On Thu, Sep 11, 2014 at 04:00:00PM +0200, Thomas Petazzoni wrote:
> > > On Thu, 11 Sep 2014 15:43:23 +0200, Andrew Lunn wrote:
> > > > A point for discussion, triggered by 3/4. We have repeatedly seen
> > > > issues with modular builds, which we don't see with everything built
> > > > in. Can we improve our testing? Is there is way to take for example
> > > > mvebu_v7_defconfig and turn any y tristate options into m? Build and
> > > > boot? Get this added to the boot test farms?
> > > 
> > > I indeed agree that we are not testing much the modular case, but:
> > > 
> > >  1/ In my case, a mvebu_v7_defconfig where most the stuff would become
> > >     enabled as a module would make mvebu_v7_defconfig pretty much
> > >     useless for my daily work. When I'm doing active development, I
> > >     typically have everything built-in including the initramfs itself,
> > >     so that I don't rely on any storage/network to get the rootfs and
> > >     additional kernel drivers.
> > > 
> > >  2/ I don't think it would change much in terms of runtime coverage:
> > >     the tests done on the boot farm are just boot tests, I don't think
> > >     they load any kernel module. We could ask Kevin and Olof what
> > >     rootfs they use, but most likely it's some very small rootfs that
> > >     doesn't even have udev/mdev for automatic module loading. So no
> > >     module would be loaded, which would mean that a mvebu_v7_defconfig
> > >     with everything as a module would actually test *less* thing than a
> > >     configuration that has everything built in.
> > > 
> > > So, I agree on the observation, but I'm unsure the proposed solution
> > > will really solve or even improve the situation :/
> > 
> > Since debian does modular builds on a regular basis, maybe they have
> > some recommendations.

Rather than modularising $socfamily_defconfig perhaps this is something
which can be achieved by also testing multiplatform defconfigs builds,
and perhaps making those more modular (if they aren't already)?

It seems like a multiplatform kernel is something which would be more
naturally quite modular anyway, and certainly distros are mostly
interested in moving to configurations which are both multiplatform and
modular (at least in the long run, Debian has some legacy v5 flavours
which may or may not get moved over).

That would avoid needing to mess with mvebu_v7_defconfig, since it seems
quite reasonable and natural for that to be pretty non-modular.

Ian.

[PATCH 0/4] ARM: mvebu: minor Armada 370 RD improvements

[Jason Cooper]

On Thu, Sep 11, 2014 at 11:56:55AM +0200, Thomas Petazzoni wrote:
> Jason, Andrew, Gregory, Sebastian,
> 
> Here are four small patches to make minor improvements to the support
> of the Armada 370 RD platform.
> 
> Thanks,
> 
> Thomas
> 
> Thomas Petazzoni (4):
>   ARM: mvebu: add gpio fan support to Armada 370 RD
>   ARM: mvebu: add user LED support of Armada 370 RD

Applied to mvebu/dt with Andrew's Acks.

>   ARM: mvebu: add LED class support built-in in mvebu_v7_defconfig
>   ARM: mvebu: add gpio-fan to mvebu_v7_defconfig

Applied to mvebu/defconfig with Andrew's Acks.

>  arch/arm/boot/dts/armada-370-rd.dts | 32 ++++++++++++++++++++++++++++++++
>  arch/arm/configs/mvebu_v7_defconfig |  3 ++-
>  2 files changed, 34 insertions(+), 1 deletion(-)

thx,

Jason.