Re: [PATCH] omap: Add devicetree for Gumstix Pepper board
Hi Ash,
On 06/06/2014 10:51 PM, Ash Charles wrote:
This adds the Gumstix Pepper[1] single-board computer based on the
TI AM335x processor. Schematics are available [2].
[1] https://store.gumstix.com/index.php/products/344/
[2] https://pubs.gumstix.com/boards/PEPPER/
Signed-off-by: Ash Charles ashchar...@gmail.com
---
MAINTAINERS | 6 +
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/am335x-pepper.dts | 661
3 files changed, 669 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am335x-pepper.dts
diff --git a/MAINTAINERS b/MAINTAINERS
index 51ebb77..d44e2e3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6427,6 +6427,12 @@ L: linux-omap@vger.kernel.org
S: Maintained
F: arch/arm/boot/dts/am335x-nano.dts
+OMAP/GUMSTIX PEPPER MACHINE SUPPORT
+M: Ash Charles ashchar...@gmail.com
+L: linux-omap@vger.kernel.org
+S: Maintained
+F: arch/arm/boot/dts/am335x-pepper.dts
+
It is not very common to add oneself as the maintainer of a single .dts
file. I could only found the am335x-nano.dts with such a way of doing.
Usually get_maintainer.pl will also take into account the commit author
and properly handle this case.
OMFS FILESYSTEM
M: Bob Copeland m...@bobcopeland.com
L: linux-karma-de...@lists.sourceforge.net
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a81a24c..9e0352f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -277,7 +277,8 @@ dtb-$(CONFIG_SOC_AM33XX) += am335x-base0033.dtb \
am335x-boneblack.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
- am335x-nano.dtb
+ am335x-nano.dtb \
+ am335x-pepper.dtb
dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
diff --git a/arch/arm/boot/dts/am335x-pepper.dts
b/arch/arm/boot/dts/am335x-pepper.dts
new file mode 100644
index 000..27d9b75
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -0,0 +1,661 @@
+/*
+ * Copyright (C) 2014 Gumstix, Inc. - https://www.gumstix.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include am33xx.dtsi
+
+/ {
+ model = Gumstix Pepper;
+ compatible = gumstix,am335x-pepper, ti,am33xx;
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = dcdc3_reg;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x2000; /* 512 MB */
+ };
+
+ buttons: user_buttons {
+ compatible = gpio-keys;
+ };
+
For all the boards that I have seen, all the properties of a new node
are declared at the same place, where you put some of them at the end. I
have not a strong opinion on this, but I find it a bit more difficult to
read.
+ leds: user_leds {
+ compatible = gpio-leds;
+ };
+
+ panel: lcd_panel {
+ compatible = ti,tilcdc,panel;
+ };
+
+ sound: sound_iface {
+ compatible = ti,da830-evm-audio;
+ };
+
+ vbat: fixedregulator@0 {
+ compatible = regulator-fixed;
+ };
+
+ v3v3c_reg: fixedregulator@1 {
+ compatible = regulator-fixed;
+ };
+
+ vdd5_reg: fixedregulator@2 {
+ compatible = regulator-fixed;
+ };
+};
+
+/* I2C Busses */
+i2c0 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c0_pins;
+
+ clock-frequency = 40;
+
+ tps: tps@24 {
+ reg = 0x24;
+ };
+
+ eeprom: eeprom@50 {
+ compatible = at,24c256;
+ reg = 0x50;
+ };
+
+ audio_codec: tlv320aic3106@1b {
+ compatible = ti,tlv320aic3106;
+ reg = 0x1b;
+ };
+
+ accel: lis331dlh@1d {
+ compatible = st,lis3lv02d;
+ reg = 0x1d;
+ };
+};
+
+i2c1 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c1_pins;
+ clock-frequency = 40;
+};
+
+am33xx_pinmux {
+ i2c0_pins: pinmux_i2c0 {
+ pinctrl-single,pins =
+ 0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_sda.i2c0_sda */
+ 0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_scl.i2c0_scl */
+ ;
+ };
+ i2c1_pins: pinmux_i2c1 {
+ pinctrl-single,pins =
+ 0x10C (PIN_INPUT_PULLUP | MUX_MODE3)/*
mii1_crs,i2c1_sda */
+ 0x110 (PIN_INPUT_PULLUP | MUX_MODE3)/*
mii1_rxerr,i2c1_scl */
+ ;
+ };
+};
+
Splitting the pinmux is also unusual, but in this case I found it more
readable.
+/* Accelerometer */
+accel {
+ pinctrl-names = default;
Unifying cape overlays into boot .dtb for BeagleBoard.org boards
I'd like to discuss moving our current library of cape devicetree overlay sources into a single tree, including the boot .dtb files for BeagleBoard.org boards and moving towards enabling as much of the cape support into a single boot-time .dtb file with an approach similar to the cape-universal overlay (https://github.com/cdsteinkuehler/beaglebone-universal-io), but not in an overlay. First of all, I want to note this doesn't change my view on the importance of mainline support for devicetree overlays. They are still absolutely critical and highly useful, solving problems that cannot be solved through boot-time devicetrees. I'm simply looking for an approach that will complement the availability of overlays and provide the best user experience. Robert has been talking about the actions required to clean-up Debian Jessie support in another thread (https://groups.google.com/d/msg/beagleboard/2b8rArtfABY/A8d1JzmJa4IJ) and I suggested we should add a bit of a detour by cleaning up the cape support for the mainline kernel and switching away our primary process of supporting capes from using overlays to using a single devicetree file provided at boot. I promised a pull-request and hadn't gotten around to sending it until now (below). No architecture changes have been made in my pull-request, just bringing in the kernel devicetree source history. This suggestion is based on several assumptions, any number of which might be wrong. The assumptions (for which I'm looking for feedback/corrections): * The overlays pretty much all need to be compiled into the kernel if they are going to be loaded using kernel command-line arguments or /etc/capemgr for the majority of distros. While many cape devicetree use cases are perfectly happy with loading at run-time rather than boot-time, it seems there should be a mechanism for pushing cape support into the category of being available at boot-time across distributions. * The devicetree sources, including the primary boot .dts files, will eventually be removed from the kernel source tree. I'm not too sure if and when it'll really happen, but starting up a project to maintain the definitive beagleboard.org board devicetree files outside the kernel seems to make sense. Given the interdependency of the boot .dtb and the overlay .dtbo files, combining them into a single repository where every distribution can pick them up seems like a natural and obvious choice. There are of course some dependencies on kernel versions, but I believe most of those have settled out by now and we should be OK moving forward. * There seems to be little or no interest in my previous proposal to use cape EEPROMs to store the overlay fragments. Given some churn in the devicetree node definitions, it is likely this would have failed in bad ways anyway. It seems mostly reasonable to expect users to update their kernel and firmware to gain support for new add-on hardware and we mostly try to avoid regressions (with the seemingly ever-living exception of 3D graphics support), so I think I'm better aligned with the community to drop my older suggestion. Some people, including CircuitCo, are building capes without configuration EEPROMs now, so a different recommended mechanism seems like a requirement. * With the patches in our vendor 3.8 kernels and with all recent mainline kernels, performing userspace muxing operations has become easy again. It seems to be possible to turn on drivers not currently in use without an unacceptable level of bloat or conflict. This has been partially proven out using Charles' universal cape (https://github.com/cdsteinkuehler/beaglebone-universal-io), though I still have some concerns about conflicts. The result might be that there is still some number of overlays, but the approach of minimizing the overlays and instead relying on the existing loading/unloading mechanisms of the mainline drivers as much as possible feels right to me. * It will still be some time before devicetree overlay support is adopted in the mainline kernel. While I still see a strong need to have devicetree overlay support and CapeMgr in the mainline, the desire here is to optimize the user experience in the shortest term possible. Users get really confused by the errors that get generated by loading incorrect devicetree overlays and it is always nice when you can avoid confusing users. My suggestion is: * Maintain the source for .dtb and .dtbo files for all BeagleBoard.org boards at http://github.com/beagleboard/devicetree-source, overriding the sources in the mainline kernel when performing kernel builds. We can host pre-built .dtb and .dtbo files at a normailzed location outside the source repository for those that don't want to perform the builds, since I don't believe the binary format is changing any time soon other than the overlay support we utilize. Any patches accepted into mainline as long as these files still exist there as well should be merged to try to keep these in-line as long as
re: usb: musb: omap: Add device tree support for omap musb glue
Hello Kishon Vijay Abraham I, The patch 00a0b1d58af873d8: usb: musb: omap: Add device tree support for omap musb glue, from Sep 11 2012, leads to the following static checker warning: drivers/usb/musb/omap2430.c:569 omap2430_probe() warn: does endianness matter for 'config-num_eps'? drivers/usb/musb/omap2430.c 565 566 of_property_read_u32(np, mode, (u32 *)pdata-mode); 567 of_property_read_u32(np, interface-type, 568 (u32 *)data-interface_type); 569 of_property_read_u32(np, num-eps, (u32 *)config-num_eps); ^^^ This is not endian safe, but more importantly -num_eps is a u8 so when we write 32 bits to it, we are corrupting -dma_channels, -dyn_fifo_size, and -vendor_ctrl. On little endian, it's going to be setting them to zero so it might not cause and immediate problem. The way to do this is to use a 32 bit temporary variable and then save the value to -num_eps afterward. Create a small function to do this in a nice way. All the casts here are a bit scary. 570 of_property_read_u32(np, ram-bits, (u32 *)config-ram_bits); 571 of_property_read_u32(np, power, (u32 *)pdata-power); regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: drop unused function
gic_init_irq() is no longer used as of:
commit b42b918194c4791510ac049e3d507169a7de8544
Author: Tony Lindgren t...@atomide.com
Date: Thu May 30 12:53:05 2013 -0700
ARM: OMAP2+: Remove board-omap4panda.c
Drop it.
Signed-off-by: Brian Norris computersforpe...@gmail.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
---
arch/arm/mach-omap2/common.h | 1 -
arch/arm/mach-omap2/omap4-common.c | 20
2 files changed, 21 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index ff029737c8f0..51f6897418b7 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -241,7 +241,6 @@ static inline void __iomem *omap4_get_scu_base(void)
}
#endif
-extern void __init gic_init_irq(void);
extern void gic_dist_disable(void);
extern void gic_dist_enable(void);
extern bool gic_dist_disabled(void);
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 326cd982a3cb..539e8106eb96 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -102,26 +102,6 @@ void __init omap_barriers_init(void)
{}
#endif
-void __init gic_init_irq(void)
-{
- void __iomem *omap_irq_base;
-
- /* Static mapping, never released */
- gic_dist_base_addr = ioremap(OMAP44XX_GIC_DIST_BASE, SZ_4K);
- BUG_ON(!gic_dist_base_addr);
-
- twd_base = ioremap(OMAP44XX_LOCAL_TWD_BASE, SZ_4K);
- BUG_ON(!twd_base);
-
- /* Static mapping, never released */
- omap_irq_base = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_512);
- BUG_ON(!omap_irq_base);
-
- omap_wakeupgen_init();
-
- gic_init(0, 29, gic_dist_base_addr, omap_irq_base);
-}
-
void gic_dist_disable(void)
{
if (gic_dist_base_addr)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: Add devicetree for Gumstix Pepper board
On Tue, Jun 10, 2014 at 8:59 AM, Florian Vaussard
florian.vauss...@epfl.ch wrote:
It is not very common to add oneself as the maintainer of a single .dts
file. I could only found the am335x-nano.dts with such a way of doing.
Usually get_maintainer.pl will also take into account the commit author
and properly handle this case.
Okay--I'll remove this. Ironically, I was looking at the nano to make
sure I'd done everything I needed to ;-).
...
For all the boards that I have seen, all the properties of a new node
are declared at the same place, where you put some of them at the end. I
have not a strong opinion on this, but I find it a bit more difficult to
read.
...
Splitting the pinmux is also unusual, but in this case I found it more
readable.
My goal both by moving the properties and the pinmux was to separate
out chunks of functionality into discrete sections. It makes it easy
to resolve an issue with a specific board feature (e.g. LEDs) or adapt
for a new board version as the pinmux and any node properties are
grouped together.
I recognize this is something of a personal bias though so I can
certainly re-organize if this is stylistically bad.
...
+am33xx_pinmux {
+ accel_pins: pinmux_accel {
+ pinctrl-single,pins =
+ 0x98 (PIN_INPUT_PULLUP | MUX_MODE7) /*
gpmc_wen.gpio2_4 */
The INT pin of the LIS33 chip seems to be push-pull, thus enabling the
pullup on the SoC side will increase the current consumption when held down.
Good catch.
...
+am33xx_pinmux {
+ audio_pins: pinmux_audio {
+ pinctrl-single,pins =
+ 0x1AC (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
mcasp0_ahcklx.mcasp0_ahclkx */
+ 0x194 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
mcasp0_fsx.mcasp0_fsx */
+ 0x190 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
mcasp0_aclkx.mcasp0_aclkx */
+ 0x198 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
mcasp0_axr0.mcasp0_axr0 */
+ 0x1A8 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
mcasp0_axr1.mcasp0_axr1 */
+ 0x40 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_a0.gpio1_16 */
You already have an external pullup in your design, so this one seems
superfluous.
You're correct. Changed.
...
+/* Power */
+vbat {
+ regulator-name = vbat;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
removed regulator-always-on
+};
+
+v3v3c_reg {
+ regulator-name = v3v3c_reg;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ vin-supply = vbat;
+ regulator-always-on;
removed regulator-always-on
+};
+
+vdd5_reg {
+ regulator-name = vdd5_reg;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
removed regulator-always-on
+ vin-supply = vbat;
+};
+
+/include/ tps65217.dtsi
+
+tps {
+ backlight {
+ isel = 1; /* ISET1 */
+ fdim = 200; /* TPS65217_BL_FDIM_200HZ */
+ default-brightness = 80;
+ };
+
+ regulators {
+ dcdc1_reg: regulator@0 {
+ /* VDD_1V8 system supply */
+ regulator-always-on;
removed regulator-always-on
+ };
+
+ dcdc2_reg: regulator@1 {
+ /* VDD_CORE voltage limits 0.95V - 1.26V with +/-4%
tolerance */
+ regulator-name = vdd_core;
+ regulator-min-microvolt = 925000;
+ regulator-max-microvolt = 1325000;
+ regulator-boot-on;
+ regulator-always-on;
removed regulator-always-on
+ };
+
+ dcdc3_reg: regulator@2 {
+ /* VDD_MPU voltage limits 0.95V - 1.1V with +/-4%
tolerance */
+ regulator-name = vdd_mpu;
+ regulator-min-microvolt = 925000;
+ regulator-max-microvolt = 115;
+ regulator-boot-on;
+ regulator-always-on;
removed regulator-always-on
+ };
+
+ ldo1_reg: regulator@3 {
+ /* VRTC 1.8V always-on supply */
+ regulator-always-on;
This is the backup supply shouldn't be switched off.
+ };
+
+ ldo2_reg: regulator@4 {
+ /* 3.3V rail */
+ regulator-always-on;
removed regulator-always-on
+ };
+
+ ldo3_reg: regulator@5 {
+ /* VDD_3V3A 3.3V rail */
+ regulator-always-on;
removed regulator-always-on
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
+
+ ldo4_reg: regulator@6 {
+ /* VDD_3V3B 3.3V rail */
+
[Patch v2] omap: Add devicetree for Gumstix Pepper board
This adds the Gumstix Pepper[1] single-board computer based on the
TI AM335x processor. Schematics are available [2].
[1] https://store.gumstix.com/index.php/products/344/
[2] https://pubs.gumstix.com/boards/PEPPER/
Signed-off-by: Ash Charles ashchar...@gmail.com
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/am335x-pepper.dts | 653
2 files changed, 655 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am335x-pepper.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a81a24c..9e0352f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -277,7 +277,8 @@ dtb-$(CONFIG_SOC_AM33XX) += am335x-base0033.dtb \
am335x-boneblack.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
- am335x-nano.dtb
+ am335x-nano.dtb \
+ am335x-pepper.dtb
dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
diff --git a/arch/arm/boot/dts/am335x-pepper.dts
b/arch/arm/boot/dts/am335x-pepper.dts
new file mode 100644
index 000..0d35ab6
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -0,0 +1,653 @@
+/*
+ * Copyright (C) 2014 Gumstix, Inc. - https://www.gumstix.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include dt-bindings/input/input.h
+#include am33xx.dtsi
+
+/ {
+ model = Gumstix Pepper;
+ compatible = gumstix,am335x-pepper, ti,am33xx;
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = dcdc3_reg;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x2000; /* 512 MB */
+ };
+
+ buttons: user_buttons {
+ compatible = gpio-keys;
+ };
+
+ leds: user_leds {
+ compatible = gpio-leds;
+ };
+
+ panel: lcd_panel {
+ compatible = ti,tilcdc,panel;
+ };
+
+ sound: sound_iface {
+ compatible = ti,da830-evm-audio;
+ };
+
+ vbat: fixedregulator@0 {
+ compatible = regulator-fixed;
+ };
+
+ v3v3c_reg: fixedregulator@1 {
+ compatible = regulator-fixed;
+ };
+
+ vdd5_reg: fixedregulator@2 {
+ compatible = regulator-fixed;
+ };
+};
+
+/* I2C Busses */
+i2c0 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c0_pins;
+
+ clock-frequency = 40;
+
+ tps: tps@24 {
+ reg = 0x24;
+ };
+
+ eeprom: eeprom@50 {
+ compatible = at,24c256;
+ reg = 0x50;
+ };
+
+ audio_codec: tlv320aic3106@1b {
+ compatible = ti,tlv320aic3106;
+ reg = 0x1b;
+ };
+
+ accel: lis331dlh@1d {
+ compatible = st,lis3lv02d;
+ reg = 0x1d;
+ };
+};
+
+i2c1 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c1_pins;
+ clock-frequency = 40;
+};
+
+am33xx_pinmux {
+ i2c0_pins: pinmux_i2c0 {
+ pinctrl-single,pins =
+ 0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_sda.i2c0_sda */
+ 0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_scl.i2c0_scl */
+ ;
+ };
+ i2c1_pins: pinmux_i2c1 {
+ pinctrl-single,pins =
+ 0x10C (PIN_INPUT_PULLUP | MUX_MODE3)/*
mii1_crs,i2c1_sda */
+ 0x110 (PIN_INPUT_PULLUP | MUX_MODE3)/*
mii1_rxerr,i2c1_scl */
+ ;
+ };
+};
+
+/* Accelerometer */
+accel {
+ pinctrl-names = default;
+ pinctrl-0 = accel_pins;
+
+ Vdd-supply = ldo3_reg;
+ Vdd_IO-supply = ldo3_reg;
+ st,irq1-click;
+ st,wakeup-x-lo;
+ st,wakeup-x-hi;
+ st,wakeup-y-lo;
+ st,wakeup-y-hi;
+ st,wakeup-z-lo;
+ st,wakeup-z-hi;
+ st,min-limit-x = 92;
+ st,max-limit-x = 14;
+ st,min-limit-y = 14;
+ st,max-limit-y = 92;
+ st,min-limit-z = 92;
+ st,max-limit-z = 14;
+};
+
+am33xx_pinmux {
+ accel_pins: pinmux_accel {
+ pinctrl-single,pins =
+ 0x98 (PIN_INPUT | MUX_MODE7) /* gpmc_wen.gpio2_4 */
+ ;
+ };
+};
+
+/* Audio */
+audio_codec {
+ status = okay;
+
+ gpio-reset = gpio1 16 GPIO_ACTIVE_LOW;
+ AVDD-supply = ldo3_reg;
+ IOVDD-supply = ldo3_reg;
+ DRVDD-supply = ldo3_reg;
+ DVDD-supply = dcdc1_reg;
+};
+
+sound {
+ ti,model = AM335x-EVM;
+ ti,audio-codec = audio_codec;
+ ti,mcasp-controller = mcasp0;
+ ti,codec-clock-rate = 1200;
+ ti,audio-routing =
+ Headphone Jack, HPLOUT,
+
[RFC] irqchip: gic: always mask interrupts during suspend
The core kernel IRQ code will disable all non-wakeup interrupts before
suspend, but because the GIC uses lazy masking (i.e., it doesn't mask
interrupts, but only disables them logically), we still might be
processing interrupts after the last call for interrupts
(check_wakeup_irqs()). This can cause various problems, so let's just
always mask our interrupts before suspend.
Several platforms already tweak the GIC irqchip flags to do this (and
I'm working on bringing up another platform that needs this), so let's
just set IRQCHIP_MASK_ON_SUSPEND by default.
Signed-off-by: Brian Norris computersforpe...@gmail.com
Cc: Tony Lindgren t...@atomide.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Thierry Reding thierry.red...@gmail.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Michal Simek michal.si...@xilinx.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Jason Cooper ja...@lakedaemon.net
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
---
This is just an RFC. If it is acceptable, I'll need to break it up for
application to each sub-arch tree.
I really don't like the gic_arch_extn approach to customizing the GIC driver,
so I thought this was one opportunity to unify some platform code. If this
approach isn't accpetable, I can simply add this flag to my own machine init
code. But I thought this was a good starting place for discussion about this
odd piece of code.
Other random thought: it seems like any irqchip driver which does lazy IRQ
masking ought to use IRQCHIP_MASK_ON_SUSPEND. So maybe the IRQ core should just
do something like:
if (!chip-irq_disable)
chip-flags |= IRQCHIP_MASK_ON_SUSPEND;
arch/arm/mach-omap2/omap-wakeupgen.c | 2 +-
arch/arm/mach-tegra/irq.c| 1 -
arch/arm/mach-ux500/cpu.c| 2 +-
arch/arm/mach-zynq/common.c | 2 +-
drivers/irqchip/irq-gic.c| 1 +
5 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
b/arch/arm/mach-omap2/omap-wakeupgen.c
index 37843a7d3639..c9c12ea6dd09 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -440,7 +440,7 @@ int __init omap_wakeupgen_init(void)
*/
gic_arch_extn.irq_mask = wakeupgen_mask;
gic_arch_extn.irq_unmask = wakeupgen_unmask;
- gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND | IRQCHIP_SKIP_SET_WAKE;
+ gic_arch_extn.flags = IRQCHIP_SKIP_SET_WAKE;
/*
* FIXME: Add support to set_smp_affinity() once the core
diff --git a/arch/arm/mach-tegra/irq.c b/arch/arm/mach-tegra/irq.c
index 1a74d562dca1..6f0529021520 100644
--- a/arch/arm/mach-tegra/irq.c
+++ b/arch/arm/mach-tegra/irq.c
@@ -281,7 +281,6 @@ void __init tegra_init_irq(void)
gic_arch_extn.irq_unmask = tegra_unmask;
gic_arch_extn.irq_retrigger = tegra_retrigger;
gic_arch_extn.irq_set_wake = tegra_set_wake;
- gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND;
/*
* Check if there is a devicetree present, since the GIC will be
diff --git a/arch/arm/mach-ux500/cpu.c b/arch/arm/mach-ux500/cpu.c
index db16b5a04ad5..ce2bfe39dd82 100644
--- a/arch/arm/mach-ux500/cpu.c
+++ b/arch/arm/mach-ux500/cpu.c
@@ -52,7 +52,7 @@ void ux500_restart(enum reboot_mode mode, const char *cmd)
*/
void __init ux500_init_irq(void)
{
- gic_arch_extn.flags = IRQCHIP_SKIP_SET_WAKE | IRQCHIP_MASK_ON_SUSPEND;
+ gic_arch_extn.flags = IRQCHIP_SKIP_SET_WAKE;
irqchip_init();
/*
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 31a6fa40ba37..6defcea545d6 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -182,7 +182,7 @@ static void __init zynq_map_io(void)
static void __init zynq_irq_init(void)
{
- gic_arch_extn.flags = IRQCHIP_SKIP_SET_WAKE | IRQCHIP_MASK_ON_SUSPEND;
+ gic_arch_extn.flags = IRQCHIP_SKIP_SET_WAKE;
irqchip_init();
}
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 7e11c9d6ae8c..0117e36a3bbd 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -1032,6 +1032,7 @@ void __init gic_init_bases(unsigned int gic_nr, int
irq_start,
}
gic_chip.flags |= gic_arch_extn.flags;
+ gic_chip.flags |= IRQCHIP_MASK_ON_SUSPEND;
gic_dist_init(gic);
gic_cpu_init(gic);
gic_pm_init(gic);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] irqchip: gic: always mask interrupts during suspend
On Tue, 10 Jun 2014, Brian Norris wrote: Other random thought: it seems like any irqchip driver which does lazy IRQ masking ought to use IRQCHIP_MASK_ON_SUSPEND. So maybe the IRQ core should just do something like: if (!chip-irq_disable) chip-flags |= IRQCHIP_MASK_ON_SUSPEND; No. Lazy irq disable and the suspend logic are different beasts. That's up to the platform to decide this. Just for the record: there is a world outside of ARM... But that brings me to a different question: Why are you not putting that customization into the device tree instead of trying to add this to some random arch/arm/mach-foo files? Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] irqchip: gic: always mask interrupts during suspend
On Wed, Jun 11, 2014 at 01:34:39AM +0200, Thomas Gleixner wrote: On Tue, 10 Jun 2014, Brian Norris wrote: Other random thought: it seems like any irqchip driver which does lazy IRQ masking ought to use IRQCHIP_MASK_ON_SUSPEND. So maybe the IRQ core should just do something like: if (!chip-irq_disable) chip-flags |= IRQCHIP_MASK_ON_SUSPEND; No. Lazy irq disable and the suspend logic are different beasts. OK, fair enough. Drop that random thought then. It's not in the patch content anyway. That's up to the platform to decide this. Just for the record: there is a world outside of ARM... OK. But GIC is ARM-specific, so we can still constrain this patch and related topics to the world of ARM. But that brings me to a different question: Why are you not putting that customization into the device tree instead of trying to add this to some random arch/arm/mach-foo files? I'm not adding customization to arch/arm/mach-foo files. I'm trying to remove it. This property could be added to device tree, if there was really a valid use case for a GIC which leaves its interrupts unmasked for suspend. My question in this patch is essentially: does such a use case exist? Brian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
Adding devicetree and linux-arm-kernel lists based on feedback on IRC... On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner jkrid...@gmail.com wrote: I'd like to discuss moving our current library of cape devicetree overlay sources into a single tree, including the boot .dtb files for BeagleBoard.org boards and moving towards enabling as much of the cape support into a single boot-time .dtb file with an approach similar to the cape-universal overlay (https://github.com/cdsteinkuehler/beaglebone-universal-io), but not in an overlay. First of all, I want to note this doesn't change my view on the importance of mainline support for devicetree overlays. They are still absolutely critical and highly useful, solving problems that cannot be solved through boot-time devicetrees. I'm simply looking for an approach that will complement the availability of overlays and provide the best user experience. Robert has been talking about the actions required to clean-up Debian Jessie support in another thread (https://groups.google.com/d/msg/beagleboard/2b8rArtfABY/A8d1JzmJa4IJ) and I suggested we should add a bit of a detour by cleaning up the cape support for the mainline kernel and switching away our primary process of supporting capes from using overlays to using a single devicetree file provided at boot. I promised a pull-request and hadn't gotten around to sending it until now (below). No architecture changes have been made in my pull-request, just bringing in the kernel devicetree source history. This suggestion is based on several assumptions, any number of which might be wrong. The assumptions (for which I'm looking for feedback/corrections): * The overlays pretty much all need to be compiled into the kernel if they are going to be loaded using kernel command-line arguments or /etc/capemgr for the majority of distros. While many cape devicetree use cases are perfectly happy with loading at run-time rather than boot-time, it seems there should be a mechanism for pushing cape support into the category of being available at boot-time across distributions. * The devicetree sources, including the primary boot .dts files, will eventually be removed from the kernel source tree. I'm not too sure if and when it'll really happen, but starting up a project to maintain the definitive beagleboard.org board devicetree files outside the kernel seems to make sense. Given the interdependency of the boot .dtb and the overlay .dtbo files, combining them into a single repository where every distribution can pick them up seems like a natural and obvious choice. There are of course some dependencies on kernel versions, but I believe most of those have settled out by now and we should be OK moving forward. * There seems to be little or no interest in my previous proposal to use cape EEPROMs to store the overlay fragments. Given some churn in the devicetree node definitions, it is likely this would have failed in bad ways anyway. It seems mostly reasonable to expect users to update their kernel and firmware to gain support for new add-on hardware and we mostly try to avoid regressions (with the seemingly ever-living exception of 3D graphics support), so I think I'm better aligned with the community to drop my older suggestion. Some people, including CircuitCo, are building capes without configuration EEPROMs now, so a different recommended mechanism seems like a requirement. * With the patches in our vendor 3.8 kernels and with all recent mainline kernels, performing userspace muxing operations has become easy again. It seems to be possible to turn on drivers not currently in use without an unacceptable level of bloat or conflict. This has been partially proven out using Charles' universal cape (https://github.com/cdsteinkuehler/beaglebone-universal-io), though I still have some concerns about conflicts. The result might be that there is still some number of overlays, but the approach of minimizing the overlays and instead relying on the existing loading/unloading mechanisms of the mainline drivers as much as possible feels right to me. * It will still be some time before devicetree overlay support is adopted in the mainline kernel. While I still see a strong need to have devicetree overlay support and CapeMgr in the mainline, the desire here is to optimize the user experience in the shortest term possible. Users get really confused by the errors that get generated by loading incorrect devicetree overlays and it is always nice when you can avoid confusing users. My suggestion is: * Maintain the source for .dtb and .dtbo files for all BeagleBoard.org boards at http://github.com/beagleboard/devicetree-source, overriding the sources in the mainline kernel when performing kernel builds. We can host pre-built .dtb and .dtbo files at a normailzed location outside the source repository for those that don't want to perform the builds, since I don't believe the binary
