[PATCH 1/1] ARM: OMAP: Add maintainer entry for IGEP machines
Enric and I have been mantained this machine and while we are moving to device trees, it is good that people cc us when reporting bugs or regression on the board file until we have proper DT support. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- MAINTAINERS |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 63ce2a2..6b3c58d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -818,6 +818,14 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/kristoffer/linux-hpc.git F: arch/arm/mach-sa1100/jornada720.c F: arch/arm/mach-sa1100/include/mach/jornada720.h +ARM/IGEP MACHINE SUPPORT +M: Enric Balletbo i Serra eballe...@gmail.com +M: Javier Martinez Canillas jav...@dowhile0.org +L: linux-o...@vger.kernel.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +S: Maintained +F: arch/arm/mach-omap2/board-igep0020.c + ARM/INCOME PXA270 SUPPORT M: Marek Vasut marek.va...@gmail.com L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Getting kernel uImage build issue on omap2+
On Sat, Mar 16, 2013 at 5:44 AM, Anil Kumar anilk...@gmail.com wrote: Hi, I am getting kernel uImage build issue on omap2+ log[1] Taken kernel branch for_3.10/dts from https://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git Taking reference from https://kernel.googlesource.com/pub/scm/linux/kernel/git/tmlind/linux-omap/+/omap-for-v3.9/multiplatform-enable-signed-v2 Am I missing some thing ? [1] anil@anil-laptop:~/Anil/omap3/bcousson$ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n Linux -d zImage-omap2plus uImage-omap2plus mkimage: Can't open zImage-omap2plus: No such file or directory anil@anil-laptop:~/Anil/omap3/bcousson$ Thanks, Anil Hi Anil, It seems that Tony's email assumed that you generated a bunch of zImages for different platforms and then naming them zImage-$platform. e.g: $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- omap2plus_defconfig $ make -j 4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- zImage modules zImage-omap2plus $ cp cp arch/arm/boot/zImage zImage-omap2plus and then you can use the command in [1]: $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n Linux -d zImage-omap2plus uImage-omap2plus anyways, the problem is that zImage-omap2plus does not exist and you have to use the zImage generated by make zImage. What I usually do is just: $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n Linux -d arch/arm/boot/zImage uImage-omap2plus and then copy uImage-omap2plus as uImage on either my board MMC/SD or Flash memory. Also, if you find this inconvenient, you can add CONFIG_CMD_BOOTZ to your board header config file in U-Boot so it can boot a zImage directly instead of an uImage. Not sure when did was introduced on U-Boot but should be available on any decent-ish version. Hope it helps, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: dts: Add uart1 and uart2 to igep boards.
On Wed, Mar 13, 2013 at 5:41 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Javier,
On 03/02/2013 02:52 AM, Javier Martinez Canillas wrote:
On Fri, Feb 15, 2013 at 11:03 AM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Matthias,
On 2/15/2013 10:35 AM, Matthias Brugger wrote:
2013/1/26 Javier Martinez Canillas martinez.jav...@gmail.com:
On Sat, Jan 26, 2013 at 4:16 PM, Matthias Brugger
matthias@gmail.com
wrote:
Hi Benoit,
2012/12/12 Benoit Cousson b-cous...@ti.com:
Hi Matthias,
On 12/12/2012 04:33 PM, Matthias Brugger wrote:
This patch is a follow-up patch for Javier Martinez effort adding
initial
device tree support to IGEP technology devices. [1]
It adds uart1 and uart2 bindings to the generic dtsi for the IGEP
boards.
[1] http://www.spinics.net/lists/linux-omap/msg83409.html
Signed-off-by: Matthias Brugger matthias@gmail.com
---
arch/arm/boot/dts/omap3-igep.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index 125fe00..c02e3c0 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -27,6 +27,20 @@
};
omap3_pmx_core {
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins =
+ 0x152 0x100 /* uart1_rx.uart1_rx INPUT |
MODE0
*/
+ 0x14c 0 /* uart1_tx.uart1_tx OUTPUT |
MODE0 */
+ ;
+ };
+
+ uart2_pins: pinmux_uart2_pins {
+ pinctrl-single,pins =
+ 0x14a 0x100 /* uart2_rx.uart2_rx INPUT |
MODE0
*/
+ 0x148 0 /* uart2_tx.uart2_tx OUTPUT |
MODE0 */
+ ;
+ };
+
uart3_pins: pinmux_uart3_pins {
pinctrl-single,pins =
0x16e 0x100 /* uart3_rx.uart3_rx INPUT |
MODE0
*/
@@ -77,6 +91,16 @@
status = disabled;
};
+uart1 {
+ pinctrl-names = default;
+ pinctrl-0 = uart1_pins;
+};
+
+uart2 {
+ pinctrl-names = default;
+ pinctrl-0 = uart2_pins;
+};
+
uart3 {
pinctrl-names = default;
pinctrl-0 = uart3_pins;
That looks good to me. I'll apply it on top of javier's series for 3.9.
Can you pin-point me to the repository where this patches are in right
now? I tried to figure it out these days, but didn't found where to
clone the repository from.
Thanks,
Matthias
Hi Matthias,
OMAP DT tree is:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
Hi all,
unfortunately I can't find the patch in this tree.
Sorry about that. I've never pushed the latest branch, and was busy the past
month. I'll refresh the branch with all the pending patches.
Regards,
Benoit
Hi Benoit,
I realized that your for_3.9/dts branch has not landed in mainline yet
and we are near to the end of the merge window.
Are you still planing to include those changes for 3.9 or are you
going to wait until the next release?
I'm really sorry about that. I was not available to push it at the proper
time.
No worries, it was just a gentle remainder :-)
I've just rebased it on 3.9-rc2 and pushed it to a new branch.
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.10/dts
It includes the one from Matthias and yours as well. I'm still checking my
inbox to catch up on the new ones I missed.
I'm planning to push this ASAP to avoid missing the deadline again.
Great, thanks a lot for the information
Regards,
Benoit
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] ARM/dts: omap3: Add support for IGEPv2 board
ISEE IGEPv2 is an TI OMAP3 SoC based embedded board.
This patch adds an initial device tree support to boot
an IGEPv2 from the MMC/SD.
Currently is working everything that is supported by DT on OMAP3
SoCs (MMC/SD, GPIO LEDs, EEPROM, TWL4030 audio and pinctrl based mux).
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Matthias Brugger matthias@gmail.com
---
Changes since v1:
- Use default-state = on instead default-trigger = default-on for LED
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3-igep0020.dts | 56 ++
2 files changed, 57 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-igep0020.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f37cf9f..1dc0f39 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -66,6 +66,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
+ omap3-igep0020.dtb \
omap4-panda.dtb \
omap4-pandaES.dtb \
omap4-var_som.dtb \
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
new file mode 100644
index 000..e2b9849
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -0,0 +1,56 @@
+/*
+ * Device Tree Source for IGEPv2 board
+ *
+ * Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
+ * Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.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.
+ */
+
+/include/ omap3-igep.dtsi
+
+/ {
+ model = IGEPv2;
+ compatible = isee,omap3-igep0020, ti,omap3;
+
+ leds {
+ compatible = gpio-leds;
+ boot {
+label = omap3:green:boot;
+gpios = gpio1 26 0;
+default-state = on;
+ };
+
+ user0 {
+label = omap3:red:user0;
+gpios = gpio1 27 0;
+default-state = off;
+ };
+
+ user1 {
+label = omap3:red:user1;
+gpios = gpio1 28 0;
+default-state = off;
+ };
+
+ user2 {
+ label = omap3:green:user1;
+ gpios = twl_gpio 19 1;
+ };
+ };
+};
+
+i2c3 {
+ clock-frequency = 10;
+
+ /*
+* Display monitor features are burnt in the EEPROM
+* as EDID data.
+*/
+ eeprom@50 {
+ compatible = ti,eeprom;
+ reg = 0x50;
+ };
+};
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] ARM/dts: omap3: Add support for IGEP COM Module
ISEE IGEP COM Module is an TI OMAP3 SoC computer on module.
This patch adds an initial device tree support to boot an
IGEP COM Module from the MMC/SD.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Matthias Brugger matthias@gmail.com
---
Changes since v1:
- Use default-state = on instead default-trigger = default-on for LED
- Update GPIO mapping according to latest IGEP COM Module rev.E instead D
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3-igep0030.dts | 44 ++
2 files changed, 45 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-igep0030.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 1dc0f39..78c99bc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -67,6 +67,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
omap3-igep0020.dtb \
+ omap3-igep0030.dtb \
omap4-panda.dtb \
omap4-pandaES.dtb \
omap4-var_som.dtb \
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
new file mode 100644
index 000..9dc48d2
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Source for IGEP COM Module
+ *
+ * Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
+ * Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.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.
+ */
+
+/include/ omap3-igep.dtsi
+
+/ {
+ model = IGEP COM Module;
+ compatible = isee,omap3-igep0030, ti,omap3;
+
+ leds {
+ compatible = gpio-leds;
+ boot {
+label = omap3:green:boot;
+gpios = twl_gpio 13 1;
+default-state = on;
+ };
+
+ user0 {
+label = omap3:red:user0;
+gpios = twl_gpio 18 1; /* LEDA */
+default-state = off;
+ };
+
+ user1 {
+label = omap3:green:user1;
+gpios = twl_gpio 19 1; /* LEDB */
+default-state = off;
+ };
+
+ user2 {
+label = omap3:red:user1;
+gpios = gpio1 16 1;
+default-state = off;
+ };
+ };
+};
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/3] ARM/dts: omap3: Add DT support for IGEP devices
IGEP technology devices are TI OMAP3 SoC based industrial embedded and computer-on-module boards. This patch-set adds initial device tree support for these devices. The device tree allows to boot from an MMC/SD and are working all the components that already have device tree support on OMAP3 SoCs: - MMC/SD - UARTs - GPIO LEDs - TWL4030 codec audio - pinmux/pinconf pinctrl Some peripheral are still not working such as Flash storage and Ethernet but support for these will also be included once the OMAP GPMC device tree binding patches hit mainline. This is a v2 of the patch-set that solves issues pointed out by Enric Balletbo and it is composed of the following patches: [PATCH v2 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices [PATCH v2 2/3] ARM/dts: omap3: Add support for IGEPv2 board [PATCH v2 3/3] ARM/dts: omap3: Add support for IGEP COM Module Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Matthias Brugger matthias@gmail.com
---
arch/arm/boot/dts/omap3-igep.dtsi | 93 +
1 files changed, 93 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-igep.dtsi
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
new file mode 100644
index 000..a093bff
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -0,0 +1,93 @@
+/*
+ * Device Tree Source for IGEP Technology devices
+ *
+ * Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
+ * Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.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/ omap3.dtsi
+
+/ {
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x2000; /* 512 MB */
+ };
+
+ sound {
+ compatible = ti,omap-twl4030;
+ ti,model = igep2;
+ ti,mcbsp = mcbsp2;
+ ti,codec = twl_audio;
+ };
+};
+
+omap3_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ mcbsp2_pins
+ ;
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x16e 0x100 /* uart3_rx.uart3_rx INPUT | MODE0 */
+ 0x170 0 /* uart3_tx.uart3_tx OUTPUT | MODE0 */
+ ;
+ };
+
+ mcbsp2_pins: pinmux_mcbsp2_pins {
+ pinctrl-single,pins =
+ 0x1a2 0x0104/* mcspi1_cs2.gpio_176 INPUT | MODE4 */
+ ;
+ };
+};
+
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+
+ vsim: regulator@10 {
+ compatible = ti,twl4030-vsim;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 300;
+ };
+
+ twl_audio: audio {
+ compatible = ti,twl4030-audio;
+ codec {
+ };
+ };
+ };
+};
+
+/include/ twl4030.dtsi
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+mmc1 {
+ vmmc-supply = vmmc1;
+ vmmc_aux-supply = vsim;
+ bus-width = 8;
+};
+
+mmc2 {
+ status = disabled;
+};
+
+mmc3 {
+ status = disabled;
+};
+
+twl_gpio {
+ ti,use-leds;
+};
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices
On 12/03/2012 12:01 PM, Benoit Cousson wrote:
On 11/30/2012 11:08 AM, Javier Martinez Canillas wrote:
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Matthias Brugger matthias@gmail.com
---
arch/arm/boot/dts/omap3-igep.dtsi | 93
+
1 files changed, 93 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-igep.dtsi
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
new file mode 100644
index 000..a093bff
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -0,0 +1,93 @@
+/*
+ * Device Tree Source for IGEP Technology devices
+ *
+ * Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
+ * Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.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/ omap3.dtsi
+
+/ {
+memory {
+device_type = memory;
+reg = 0x8000 0x2000; /* 512 MB */
+};
+
+sound {
+compatible = ti,omap-twl4030;
+ti,model = igep2;
+ti,mcbsp = mcbsp2;
+ti,codec = twl_audio;
+};
+};
+
+omap3_pmx_core {
+pinctrl-names = default;
+pinctrl-0 =
+ mcbsp2_pins
+;
Tony made a comment to avoid associating these data inside the pmx_core
and instead do that in the dedicated device part.
Hi Benoit,
Thanks a lot for your feedback.
I didn't know about this convention, the OMAP mcspi1_cs2 pin is configured in
gpio_176 mode (OMAP_MUX_MODE4) because this GPIO line is used as the SMSC9221
LAN Ethernet controller IRQ.
But since the ethernet chip is connected to the OMAP3 processor thourgh its GPMC
and the DT support for GPMC is still not merged in mainline, DT support this
this pheripheral is still missing on this initial DT.
So, I'll just removes mcbsp2_pins for now and this can be added again on the
ethernet device part once support for this pheripheral is added.
+
+uart3_pins: pinmux_uart3_pins {
+pinctrl-single,pins =
+0x16e 0x100 /* uart3_rx.uart3_rx INPUT | MODE0 */
+0x170 0 /* uart3_tx.uart3_tx OUTPUT | MODE0 */
+;
+};
+
+mcbsp2_pins: pinmux_mcbsp2_pins {
+pinctrl-single,pins =
+0x1a2 0x0104/* mcspi1_cs2.gpio_176 INPUT | MODE4 */
+;
+};
BTW, in this case, the UART3 does not seems to have any connection with
the pins settings. Sine your don't have it in the pmx_core you should
have it in side the UART3 node.
uart3 {
pinctrl-names = default;
pinctrl-0 = uart3_pins;
};
Yes, I missed that. Thanks for pointing this out.
The rational is that, the mux will be done only if the driver is probed
and not unconditionally during pmx_core probe like it will be the case
otherwise.
Regards,
Benoit
I'll post a v3 with your suggestions.
Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] ARM/dts: omap3: Add DT support for IGEP devices
IGEP technology devices are TI OMAP3 SoC based industrial embedded and computer-on-module boards. This patch-set adds initial device tree support for these devices. The device trees allows to boot from an MMC and are working all the components that already have device tree support on OMAP3 SoCs: - MMC/SD - UARTs - GPIO LEDs - TWL4030 codec audio - pinmux/pinconf pinctrl Some peripheral are still not working such as Flash storage and Ethernet but support for these will also be included once the OMAP GPMC device tree binding patches land on mainline. This is a v3 of the patch-set that solves issues pointed out by Enric Balletbo and Benoit Cousson. The patch-set is composed of the following patches: [PATCH v3 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices [PATCH v3 2/3] ARM/dts: omap3: Add support for IGEPv2 board [PATCH v3 3/3] ARM/dts: omap3: Add support for IGEP COM Module Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] ARM/dts: omap3: Add support for IGEP COM Module
ISEE IGEP COM Module is an TI OMAP3 SoC computer on module.
This patch adds an initial device tree support to boot an
IGEP COM Module from the MMC/SD.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Matthias Brugger matthias@gmail.com
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
---
Changes since v1:
- Use default-state = on instead default-trigger = default-on for LED
- Update GPIO mapping according to latest IGEP COM Module rev.E instead D
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3-igep0030.dts | 44 ++
2 files changed, 45 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-igep0030.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 1dc0f39..78c99bc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -67,6 +67,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
omap3-igep0020.dtb \
+ omap3-igep0030.dtb \
omap4-panda.dtb \
omap4-pandaES.dtb \
omap4-var_som.dtb \
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
new file mode 100644
index 000..9dc48d2
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Source for IGEP COM Module
+ *
+ * Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
+ * Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.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.
+ */
+
+/include/ omap3-igep.dtsi
+
+/ {
+ model = IGEP COM Module;
+ compatible = isee,omap3-igep0030, ti,omap3;
+
+ leds {
+ compatible = gpio-leds;
+ boot {
+label = omap3:green:boot;
+gpios = twl_gpio 13 1;
+default-state = on;
+ };
+
+ user0 {
+label = omap3:red:user0;
+gpios = twl_gpio 18 1; /* LEDA */
+default-state = off;
+ };
+
+ user1 {
+label = omap3:green:user1;
+gpios = twl_gpio 19 1; /* LEDB */
+default-state = off;
+ };
+
+ user2 {
+label = omap3:red:user1;
+gpios = gpio1 16 1;
+default-state = off;
+ };
+ };
+};
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Matthias Brugger matthias@gmail.com
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
---
Changes since v2:
- Associate uart3_pins in uart3 device node.
- Remove mcbsp2_ins for now until SMSC9221 Ethernet support is added.
arch/arm/boot/dts/omap3-igep.dtsi | 87 +
1 files changed, 87 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-igep.dtsi
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
new file mode 100644
index 000..125fe00
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -0,0 +1,87 @@
+/*
+ * Device Tree Source for IGEP Technology devices
+ *
+ * Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
+ * Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.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/ omap3.dtsi
+
+/ {
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x2000; /* 512 MB */
+ };
+
+ sound {
+ compatible = ti,omap-twl4030;
+ ti,model = igep2;
+ ti,mcbsp = mcbsp2;
+ ti,codec = twl_audio;
+ };
+};
+
+omap3_pmx_core {
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x16e 0x100 /* uart3_rx.uart3_rx INPUT | MODE0 */
+ 0x170 0 /* uart3_tx.uart3_tx OUTPUT | MODE0 */
+ ;
+ };
+};
+
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+
+ vsim: regulator@10 {
+ compatible = ti,twl4030-vsim;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 300;
+ };
+
+ twl_audio: audio {
+ compatible = ti,twl4030-audio;
+ codec {
+ };
+ };
+ };
+};
+
+/include/ twl4030.dtsi
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+mmc1 {
+ vmmc-supply = vmmc1;
+ vmmc_aux-supply = vsim;
+ bus-width = 8;
+};
+
+mmc2 {
+ status = disabled;
+};
+
+mmc3 {
+ status = disabled;
+};
+
+uart3 {
+ pinctrl-names = default;
+ pinctrl-0 = uart3_pins;
+};
+
+twl_gpio {
+ ti,use-leds;
+};
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] ARM/dts: omap3: Add support for IGEPv2 board
ISEE IGEPv2 is an TI OMAP3 SoC based embedded board.
This patch adds an initial device tree support to boot
an IGEPv2 from the MMC/SD.
Currently is working everything that is supported by DT
on OMAP3 SoCs (MMC/SD, GPIO LEDs, EEPROM, TWL4030 audio).
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Matthias Brugger matthias@gmail.com
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
---
Changes since v1:
- Use default-state = on instead default-trigger = default-on for LED
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3-igep0020.dts | 56 ++
2 files changed, 57 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-igep0020.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f37cf9f..1dc0f39 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -66,6 +66,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
+ omap3-igep0020.dtb \
omap4-panda.dtb \
omap4-pandaES.dtb \
omap4-var_som.dtb \
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
new file mode 100644
index 000..e2b9849
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -0,0 +1,56 @@
+/*
+ * Device Tree Source for IGEPv2 board
+ *
+ * Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
+ * Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.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.
+ */
+
+/include/ omap3-igep.dtsi
+
+/ {
+ model = IGEPv2;
+ compatible = isee,omap3-igep0020, ti,omap3;
+
+ leds {
+ compatible = gpio-leds;
+ boot {
+label = omap3:green:boot;
+gpios = gpio1 26 0;
+default-state = on;
+ };
+
+ user0 {
+label = omap3:red:user0;
+gpios = gpio1 27 0;
+default-state = off;
+ };
+
+ user1 {
+label = omap3:red:user1;
+gpios = gpio1 28 0;
+default-state = off;
+ };
+
+ user2 {
+ label = omap3:green:user1;
+ gpios = twl_gpio 19 1;
+ };
+ };
+};
+
+i2c3 {
+ clock-frequency = 10;
+
+ /*
+* Display monitor features are burnt in the EEPROM
+* as EDID data.
+*/
+ eeprom@50 {
+ compatible = ti,eeprom;
+ reg = 0x50;
+ };
+};
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: dts: Add uart1 and uart2 to igep boards.
On Fri, Feb 15, 2013 at 11:03 AM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Matthias,
On 2/15/2013 10:35 AM, Matthias Brugger wrote:
2013/1/26 Javier Martinez Canillas martinez.jav...@gmail.com:
On Sat, Jan 26, 2013 at 4:16 PM, Matthias Brugger
matthias@gmail.com
wrote:
Hi Benoit,
2012/12/12 Benoit Cousson b-cous...@ti.com:
Hi Matthias,
On 12/12/2012 04:33 PM, Matthias Brugger wrote:
This patch is a follow-up patch for Javier Martinez effort adding
initial
device tree support to IGEP technology devices. [1]
It adds uart1 and uart2 bindings to the generic dtsi for the IGEP
boards.
[1] http://www.spinics.net/lists/linux-omap/msg83409.html
Signed-off-by: Matthias Brugger matthias@gmail.com
---
arch/arm/boot/dts/omap3-igep.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index 125fe00..c02e3c0 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -27,6 +27,20 @@
};
omap3_pmx_core {
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins =
+ 0x152 0x100 /* uart1_rx.uart1_rx INPUT |
MODE0
*/
+ 0x14c 0 /* uart1_tx.uart1_tx OUTPUT |
MODE0 */
+ ;
+ };
+
+ uart2_pins: pinmux_uart2_pins {
+ pinctrl-single,pins =
+ 0x14a 0x100 /* uart2_rx.uart2_rx INPUT |
MODE0
*/
+ 0x148 0 /* uart2_tx.uart2_tx OUTPUT |
MODE0 */
+ ;
+ };
+
uart3_pins: pinmux_uart3_pins {
pinctrl-single,pins =
0x16e 0x100 /* uart3_rx.uart3_rx INPUT |
MODE0
*/
@@ -77,6 +91,16 @@
status = disabled;
};
+uart1 {
+ pinctrl-names = default;
+ pinctrl-0 = uart1_pins;
+};
+
+uart2 {
+ pinctrl-names = default;
+ pinctrl-0 = uart2_pins;
+};
+
uart3 {
pinctrl-names = default;
pinctrl-0 = uart3_pins;
That looks good to me. I'll apply it on top of javier's series for 3.9.
Can you pin-point me to the repository where this patches are in right
now? I tried to figure it out these days, but didn't found where to
clone the repository from.
Thanks,
Matthias
Hi Matthias,
OMAP DT tree is:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
Hi all,
unfortunately I can't find the patch in this tree.
Sorry about that. I've never pushed the latest branch, and was busy the past
month. I'll refresh the branch with all the pending patches.
Regards,
Benoit
Hi Benoit,
I realized that your for_3.9/dts branch has not landed in mainline yet
and we are near to the end of the merge window.
Are you still planing to include those changes for 3.9 or are you
going to wait until the next release?
Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] Input: cyttsp4 - driver for Cypress TMA4XX touchscreen devices
On Fri, Sep 14, 2012 at 8:46 PM, Henrik Rydberg rydb...@euromail.se wrote: Hi Ferruh, This driver is for Cypress TrueTouch(tm) Standard Product controllers, Generation4 devices. This is second version of driver, code re-structured to match with existing Generation3 driver code. To integrate with the existing gen3 driver is clearly not the same as creating a parallel set of files, which obviously share a lot of code with the gen3 code. For instance, the i2c transfer layer seems more or less identical to the existing one; just look at cyttsp_i2c_write_block_data() versus cyttsp4_i2c_write_block_data(). If different generations of device data cannot even be transported through the same _generic_ interface, something is clearly not right. You can't seriously expect anyone to want to maintain one set of files for every new version. Please make sure to build on what is already there. Thanks. Henrik -- Hi Ferruh, Thanks a lot for taking the time to try to modify your driver to fit wit the existent Gen3 driver but I agree with Henrik that it seems that at least the transport code from the Gen3 driver could be reused. As he said the i2c layer code is almost identical and even when there are some differences on the spi transfer functions I think that the current Gen3 spi transport code could be refactor to support it. These differences seems to be only minor as far as I understood by looking at cyttsp_spi_xfer() and cyttsp4_spi_xfer() functions. Also it seems that you forgot to post your 1/3 patch from your series that adds the Gen4 core driver. At least I couldn't find neither on my mailbox nor on linux-input archives the patch: [PATCH v2 1/3] Input: cyttsp4 - core driver for Cypress TMA4XX touchscreen devices So I couldn't take a look to try to figure out if the current Gen3 core driver can be extended to support the new Gen4 family or if new core driver file is actually needed. Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] Input: cyttsp4 - bus driver for Cypress TMA4XX touchscreen devices
On Tue, Aug 7, 2012 at 3:09 PM, Ferruh Yigit f...@cypress.com wrote: From: Ferruh YIGIT f...@cypress.com This driver is for Cypress TrueTouch(tm) Standard Product controllers, Generation4 devices. Driver consist of four main modules: Bus driver: Linux bus driver implementation, binds other modules. Core driver: Core module that communicate with TTSP controller. MT driver: MultiTouch driver, converts touch information to host specific touch events Adapter driver: Communication adapter between host and controller, like I2C or SPI. This is Cyttsp4 TTSP Bus Driver, Provides binding between Adapter, Core, and TTSP Modules. A complete set of corresponding Adapter, Core, and TTSP module devices and drivers must be registered with the TTSP Bus handler Hi Ferruh, There is already a driver in the kernel that supports Cypress TrueTouch(TM) Standard Product (TTSP) controllers Generation3 (Cypress Txx3xx parts). The driver has a similar architecture that yours and it has a generic driver to control the device and a driver for each communication bus used to communicate with the controller. Drivers for SPI and I2C data buses are already implemented. The drivers are: drivers/input/touchscreen/cyttsp_core.c drivers/input/touchscreen/cyttsp_i2c.c drivers/input/touchscreen/cyttsp_spi.c This driver was original developed by Kevin for Android and used multi-touch protocol type A. Since the hardware is able to track contacts by hardware I added protocol type B support and cleaned the driver to be merged on mainline. I wonder how big is the delta between cyttsp Gen3 and cyttsp Gen4 and if both drivers could be merged or at least refactored to reuse some common code. I don't have the specification for any of the device families but by looking at your code it seems that this may be possible. Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] ARM/dts: omap3: Add DT support for IGEP devices
IGEP technology devices are TI OMAP3 SoC based industrial embedded and computer-on-module boards. This patchset adds initial device tree support for these devices. The device trees allows to boot from an MMC and are working all the components that already have device tree support on OMAP3 SoCs: - MMC/SD - UARTs - GPIO LEDs - TWL4030 codec audio - pinmux/pinconf pinctrl Some peripheral are still not working such as Flash storage and Ethernet but support for these will also be included once the OMAP GPMC device tree binding patches land on mainline. The patchset is composed of the following patches: [PATCH 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices [PATCH 2/3] ARM/dts: omap3: Add support for IGEPv2 board [PATCH 3/3] ARM/dts: omap3: Add support for IGEP COM Module -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM/dts: omap3: Add support for IGEPv2 board
ISEE IGEPv2 is an TI OMAP3 SoC based embedded board.
This patch adds an initial device tree support to boot
an IGEPv2 from the MMC/SD.
Currently is working everything that is supported by DT
on OMAP3 SoCs (MMC/SD, GPIO LEDs, EEPROM, TWL4030 audio).
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3-igep0020.dts | 56 ++
2 files changed, 57 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-igep0020.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f37cf9f..1dc0f39 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -66,6 +66,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
+ omap3-igep0020.dtb \
omap4-panda.dtb \
omap4-pandaES.dtb \
omap4-var_som.dtb \
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
new file mode 100644
index 000..9dd4d22
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -0,0 +1,56 @@
+/*
+ * Device Tree Source for IGEPv2 board
+ *
+ * Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
+ * Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.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.
+ */
+
+/include/ omap3-igep.dtsi
+
+/ {
+ model = IGEPv2;
+ compatible = isee,omap3-igep0020, ti,omap3;
+
+ leds {
+ compatible = gpio-leds;
+ boot {
+label = omap3:green:boot;
+gpios = gpio1 26 0;
+linux,default-trigger = default-on;
+ };
+
+ user0 {
+label = omap3:red:user0;
+gpios = gpio1 27 0;
+default-state = off;
+ };
+
+ user1 {
+label = omap3:red:user1;
+gpios = gpio1 28 0;
+default-state = off;
+ };
+
+ user2 {
+ label = omap3:green:user1;
+ gpios = twl_gpio 19 1;
+ };
+ };
+};
+
+i2c3 {
+ clock-frequency = 10;
+
+ /*
+* Display monitor features are burnt in the EEPROM
+* as EDID data.
+*/
+ eeprom@50 {
+ compatible = ti,eeprom;
+ reg = 0x50;
+ };
+};
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ARM/dts: omap3: Add support for IGEP COM Module
ISEE IGEP COM Module is an TI OMAP3 SoC computer on module.
This patch adds an initial device tree support to boot an
IGEP COM Module from the MMC/SD.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3-igep0030.dts | 43 ++
2 files changed, 44 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-igep0030.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 1dc0f39..78c99bc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -67,6 +67,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
omap3-igep0020.dtb \
+ omap3-igep0030.dtb \
omap4-panda.dtb \
omap4-pandaES.dtb \
omap4-var_som.dtb \
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
new file mode 100644
index 000..5ed7033
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -0,0 +1,43 @@
+/*
+ * Device Tree Source for IGEP COM Module
+ *
+ * Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
+ * Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.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.
+ */
+
+/include/ omap3-igep.dtsi
+
+/ {
+ model = IGEP COM Module;
+ compatible = isee,omap3-igep0030, ti,omap3;
+
+ leds {
+ compatible = gpio-leds;
+ boot {
+label = omap3:green:boot;
+gpios = gpio1 54 0;
+linux,default-trigger = default-on;
+ };
+
+ user0 {
+label = omap3:red:user0;
+gpios = gpio1 53 0;
+default-state = off;
+ };
+
+ user1 {
+label = omap3:red:user1;
+gpios = gpio1 16 0;
+default-state = off;
+ };
+
+ user2 {
+ label = omap3:green:user1;
+ gpios = twl_gpio 19 1;
+ };
+ };
+};
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi | 93 +
1 files changed, 93 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-igep.dtsi
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
new file mode 100644
index 000..a093bff
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -0,0 +1,93 @@
+/*
+ * Device Tree Source for IGEP Technology devices
+ *
+ * Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
+ * Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.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/ omap3.dtsi
+
+/ {
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x2000; /* 512 MB */
+ };
+
+ sound {
+ compatible = ti,omap-twl4030;
+ ti,model = igep2;
+ ti,mcbsp = mcbsp2;
+ ti,codec = twl_audio;
+ };
+};
+
+omap3_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ mcbsp2_pins
+ ;
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x16e 0x100 /* uart3_rx.uart3_rx INPUT | MODE0 */
+ 0x170 0 /* uart3_tx.uart3_tx OUTPUT | MODE0 */
+ ;
+ };
+
+ mcbsp2_pins: pinmux_mcbsp2_pins {
+ pinctrl-single,pins =
+ 0x1a2 0x0104/* mcspi1_cs2.gpio_176 INPUT | MODE4 */
+ ;
+ };
+};
+
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+
+ vsim: regulator@10 {
+ compatible = ti,twl4030-vsim;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 300;
+ };
+
+ twl_audio: audio {
+ compatible = ti,twl4030-audio;
+ codec {
+ };
+ };
+ };
+};
+
+/include/ twl4030.dtsi
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+mmc1 {
+ vmmc-supply = vmmc1;
+ vmmc_aux-supply = vsim;
+ bus-width = 8;
+};
+
+mmc2 {
+ status = disabled;
+};
+
+mmc3 {
+ status = disabled;
+};
+
+twl_gpio {
+ ti,use-leds;
+};
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH] leds: leds-gpio: set devm_gpio_request_one() flags correctly
commit a99d76f leds: leds-gpio: use gpio_request_one
changed the leds-gpio driver to use gpio_request_one() instead
of gpio_request() + gpio_direction_output()
Unfortunately, it also made a semantic change that breaks the
leds-gpio driver.
The gpio_request_one() flags parameter was set to:
GPIOF_DIR_OUT | (led_dat-active_low ^ state)
Since GPIOF_DIR_OUT is 0, the final flags value will just be the
XOR'ed value of led_dat-active_low and state.
This value were used to distinguish between HIGH/LOW output initial
level and call gpio_direction_output() accordingly.
With this new semantic gpio_request_one() will take the flags value
of 1 as a configuration of input direction (GPIOF_DIR_IN) and will
call gpio_direction_input() instead of gpio_direction_output().
int gpio_request_one(unsigned gpio, unsigned long flags, const char *label)
{
..
if (flags GPIOF_DIR_IN)
err = gpio_direction_input(gpio);
else
err = gpio_direction_output(gpio,
(flags GPIOF_INIT_HIGH) ? 1 : 0);
..
}
The right semantic is to evaluate led_dat-active_low ^ state and
set the output initial level explicitly.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
This makes LEDs to work again on my IGEPv2 board (TI OMAP3 based SoC).
I sent this patch before but then realized that I only cc'ed to linux-leds.
So, I'm resending the patch cc'ing linux-omap,linux-arm-kernel and LKML to
reach a broader audience and have more people review/test the patch.
Sorry for the noise if someone got it twice.
drivers/leds/leds-gpio.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index 1885a26..a0d931b 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -127,8 +127,9 @@ static int create_gpio_led(const struct gpio_led *template,
led_dat-cdev.flags |= LED_CORE_SUSPENDRESUME;
ret = devm_gpio_request_one(parent, template-gpio,
- GPIOF_DIR_OUT | (led_dat-active_low ^ state),
- template-name);
+ (led_dat-active_low ^ state) ?
+ GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
+ template-name);
if (ret 0)
return ret;
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH] leds: leds-gpio: set devm_gpio_request_one() flags correctly
On 12/21/2012 06:06 PM, Ezequiel Garcia wrote:
On Fri, Dec 21, 2012 at 12:07 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
commit a99d76f leds: leds-gpio: use gpio_request_one
changed the leds-gpio driver to use gpio_request_one() instead
of gpio_request() + gpio_direction_output()
Unfortunately, it also made a semantic change that breaks the
leds-gpio driver.
The gpio_request_one() flags parameter was set to:
GPIOF_DIR_OUT | (led_dat-active_low ^ state)
Since GPIOF_DIR_OUT is 0, the final flags value will just be the
XOR'ed value of led_dat-active_low and state.
This value were used to distinguish between HIGH/LOW output initial
level and call gpio_direction_output() accordingly.
With this new semantic gpio_request_one() will take the flags value
of 1 as a configuration of input direction (GPIOF_DIR_IN) and will
call gpio_direction_input() instead of gpio_direction_output().
int gpio_request_one(unsigned gpio, unsigned long flags, const char *label)
{
..
if (flags GPIOF_DIR_IN)
err = gpio_direction_input(gpio);
else
err = gpio_direction_output(gpio,
(flags GPIOF_INIT_HIGH) ? 1 : 0);
..
}
The right semantic is to evaluate led_dat-active_low ^ state and
set the output initial level explicitly.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
This makes LEDs to work again on my IGEPv2 board (TI OMAP3 based SoC).
I sent this patch before but then realized that I only cc'ed to linux-leds.
So, I'm resending the patch cc'ing linux-omap,linux-arm-kernel and LKML to
reach a broader audience and have more people review/test the patch.
Sorry for the noise if someone got it twice.
drivers/leds/leds-gpio.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index 1885a26..a0d931b 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -127,8 +127,9 @@ static int create_gpio_led(const struct gpio_led
*template,
led_dat-cdev.flags |= LED_CORE_SUSPENDRESUME;
ret = devm_gpio_request_one(parent, template-gpio,
- GPIOF_DIR_OUT | (led_dat-active_low ^ state),
- template-name);
+ (led_dat-active_low ^ state) ?
+ GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
+ template-name);
if (ret 0)
return ret;
--
1.7.7.6
Without this patch my IGEP v2 LEDs were dead,
and this patch brings them back.
Tested-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Thanks,
Ezequiel
Hello,
Any news on this?
GPIO LEDs support is still not working on latest mainline kernel and other
people report that this patch solves the issue for them.
Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] ARM/dts: omap3: Add DT support for IGEP devices
On Mon, Dec 3, 2012 at 1:41 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: IGEP technology devices are TI OMAP3 SoC based industrial embedded and computer-on-module boards. This patch-set adds initial device tree support for these devices. The device trees allows to boot from an MMC and are working all the components that already have device tree support on OMAP3 SoCs: - MMC/SD - UARTs - GPIO LEDs - TWL4030 codec audio - pinmux/pinconf pinctrl Some peripheral are still not working such as Flash storage and Ethernet but support for these will also be included once the OMAP GPMC device tree binding patches land on mainline. This is a v3 of the patch-set that solves issues pointed out by Enric Balletbo and Benoit Cousson. The patch-set is composed of the following patches: [PATCH v3 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices [PATCH v3 2/3] ARM/dts: omap3: Add support for IGEPv2 board [PATCH v3 3/3] ARM/dts: omap3: Add support for IGEP COM Module Best regards, Javier -- Hi Benoit and Tony, Any comments on these? Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] ARM/dts: omap3: Add DT support for IGEP devices
On Wed, Dec 12, 2012 at 11:11 AM, Benoit Cousson b-cous...@ti.com wrote: Hi Javier, On 12/12/2012 09:25 AM, Javier Martinez Canillas wrote: On Mon, Dec 3, 2012 at 1:41 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: IGEP technology devices are TI OMAP3 SoC based industrial embedded and computer-on-module boards. This patch-set adds initial device tree support for these devices. The device trees allows to boot from an MMC and are working all the components that already have device tree support on OMAP3 SoCs: - MMC/SD - UARTs - GPIO LEDs - TWL4030 codec audio - pinmux/pinconf pinctrl Some peripheral are still not working such as Flash storage and Ethernet but support for these will also be included once the OMAP GPMC device tree binding patches land on mainline. This is a v3 of the patch-set that solves issues pointed out by Enric Balletbo and Benoit Cousson. The patch-set is composed of the following patches: [PATCH v3 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices [PATCH v3 2/3] ARM/dts: omap3: Add support for IGEPv2 board [PATCH v3 3/3] ARM/dts: omap3: Add support for IGEP COM Module Best regards, Javier -- Hi Benoit and Tony, Any comments on these? Nope, that's fine. I'll applied the series for 3.9. Thanks, Benoit Great, thanks a lot for! Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] ARM: OMAP2+: common: remove use of vram
commit 966458f OMAP: remove vram allocator
Removed the OMAP specific vram allocator but OMAP2 common was
still trying to use it and this lead to the following build error:
CC arch/arm/mach-omap2/common.o
arch/arm/mach-omap2/common.c:19:23: fatal error: plat/vram.h: No such file or
directory
compilation terminated.
make[1]: *** [arch/arm/mach-omap2/common.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2/common.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 5c2fd48..2dabb9e 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -16,8 +16,6 @@
#include linux/init.h
#include linux/platform_data/dsp-omap.h
-#include plat/vram.h
-
#include common.h
#include omap-secure.h
@@ -32,7 +30,6 @@ int __weak omap_secure_ram_reserve_memblock(void)
void __init omap_reserve(void)
{
- omap_vram_reserve_sdram_memblock();
omap_dsp_reserve_sdram_memblock();
omap_secure_ram_reserve_memblock();
omap_barrier_reserve_memblock();
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: msm: Add support for MSM8974 Dragonboard
On Tue, Aug 6, 2013 at 1:02 AM, Rohit Vaswani rvasw...@codeaurora.org wrote:
This patch adds basic board support for MSM8974 Dragonboard
which belongs to the Snapdragon 800 family.
For now, just support a basic machine with device tree.
Signed-off-by: Rohit Vaswani rvasw...@codeaurora.org
---
arch/arm/boot/dts/Makefile| 3 ++-
arch/arm/boot/dts/msm8974-db.dts | 26 ++
arch/arm/mach-msm/Kconfig | 21 ++---
arch/arm/mach-msm/Makefile| 1 +
arch/arm/mach-msm/board-dt-8974.c | 23 +++
5 files changed, 70 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/msm8974-db.dts
create mode 100644 arch/arm/mach-msm/board-dt-8974.c
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9a..62cea36 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -97,7 +97,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
kirkwood-openblocks_a6.dtb
dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
- msm8960-cdp.dtb
+ msm8960-cdp.dtb \
+ msm8974-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
armada-370-mirabox.dtb \
armada-370-rd.dtb \
diff --git a/arch/arm/boot/dts/msm8974-db.dts
b/arch/arm/boot/dts/msm8974-db.dts
new file mode 100644
index 000..badfc61
--- /dev/null
+++ b/arch/arm/boot/dts/msm8974-db.dts
@@ -0,0 +1,26 @@
+/dts-v1/;
+
+/include/ skeleton.dtsi
+
+/ {
+ model = Qualcomm MSM8974 Dragonboard;
+ compatible = qcom,msm8974-db, qcom,msm8974;
+ interrupt-parent = intc;
+
+ intc: interrupt-controller@f900 {
+ compatible = qcom,msm-qgic2;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0xf900 0x1000 ,
+ 0xf9002000 0x1000 ;
+ };
+
+ timer {
+ compatible = arm,armv7-timer;
+ interrupts = 1 2 0xf08,
+1 3 0xf08,
+1 4 0xf08,
+1 1 0xf08;
+ clock-frequency = 1920;
+ };
+};
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 614e41e..343675b 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -1,12 +1,12 @@
if ARCH_MSM
comment Qualcomm MSM SoC Type
- depends on (ARCH_MSM8X60 || ARCH_MSM8960)
+ depends on ARCH_MSM_DT
choice
prompt Qualcomm MSM SoC Type
default ARCH_MSM7X00A
- depends on !(ARCH_MSM8X60 || ARCH_MSM8960)
+ depends on !ARCH_MSM_DT
config ARCH_MSM7X00A
bool MSM7x00A / MSM7x01A
@@ -60,6 +60,19 @@ config ARCH_MSM8960
select MSM_SCM if SMP
select USE_OF
+config ARCH_MSM8974
+ bool MSM8974
+ select ARM_GIC
+ select CPU_V7
+ select HAVE_ARM_ARCH_TIMER
+ select HAVE_SMP
+ select MSM_SCM if SMP
+ select USE_OF
+
+config ARCH_MSM_DT
+ def_bool y
+ depends on (ARCH_MSM8X60 || ARCH_MSM8960 || ARCH_MSM8974)
+
config MSM_HAS_DEBUG_UART_HS
bool
@@ -68,6 +81,7 @@ config MSM_SOC_REV_A
config ARCH_MSM_ARM11
bool
+
config ARCH_MSM_SCORPION
bool
@@ -75,6 +89,7 @@ config MSM_VIC
bool
menu Qualcomm MSM Board Type
+ depends on !ARCH_MSM_DT
config MACH_HALIBUT
depends on ARCH_MSM
@@ -121,7 +136,7 @@ config MSM_SMD
bool
config MSM_GPIOMUX
- depends on !(ARCH_MSM8X60 || ARCH_MSM8960)
+ depends on !ARCH_MSM_DT
bool MSM V1 TLMM GPIOMUX architecture
help
Support for MSM V1 TLMM GPIOMUX architecture.
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index d257ff4..80e3b15 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -29,5 +29,6 @@ obj-$(CONFIG_ARCH_MSM7X30) += board-msm7x30.o
devices-msm7x30.o
obj-$(CONFIG_ARCH_QSD8X50) += board-qsd8x50.o devices-qsd8x50.o
obj-$(CONFIG_ARCH_MSM8X60) += board-dt-8660.o
obj-$(CONFIG_ARCH_MSM8960) += board-dt-8960.o
+obj-$(CONFIG_ARCH_MSM8974) += board-dt-8974.o
obj-$(CONFIG_MSM_GPIOMUX) += gpiomux.o
obj-$(CONFIG_ARCH_QSD8X50) += gpiomux-8x50.o
diff --git a/arch/arm/mach-msm/board-dt-8974.c
b/arch/arm/mach-msm/board-dt-8974.c
new file mode 100644
index 000..697623e
--- /dev/null
+++ b/arch/arm/mach-msm/board-dt-8974.c
@@ -0,0 +1,23 @@
+/* Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied
Re: [PATCH] ARM: dts: am33xx: Correct gpio #interrupt-cells property
On Wed, Aug 7, 2013 at 1:06 PM, Lars Poeschel la...@wh2.tu-dresden.de wrote: From: Lars Poeschel poesc...@lemonage.de Following commit ff5c9059 and therefore other omap platforms using the gpio-omap driver correct the #interrupt-cells property on am33xx too. The omap gpio binding documentaion also states that the #interrupt-cells property should be 2. Signed-off-by: Lars Poeschel poesc...@lemonage.de --- arch/arm/boot/dts/am33xx.dtsi |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 38b446b..033c5dd 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -102,7 +102,7 @@ gpio-controller; #gpio-cells = 2; interrupt-controller; - #interrupt-cells = 1; + #interrupt-cells = 2; reg = 0x44e07000 0x1000; interrupts = 96; }; @@ -113,7 +113,7 @@ gpio-controller; #gpio-cells = 2; interrupt-controller; - #interrupt-cells = 1; + #interrupt-cells = 2; reg = 0x4804c000 0x1000; interrupts = 98; }; @@ -124,7 +124,7 @@ gpio-controller; #gpio-cells = 2; interrupt-controller; - #interrupt-cells = 1; + #interrupt-cells = 2; reg = 0x481ac000 0x1000; interrupts = 32; }; @@ -135,7 +135,7 @@ gpio-controller; #gpio-cells = 2; interrupt-controller; - #interrupt-cells = 1; + #interrupt-cells = 2; reg = 0x481ae000 0x1000; interrupts = 62; }; -- 1.7.10.4 Reviewed-by: Javier Martinez Canillas jav...@dowhile0.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the usb tree
[cc'ing Benoit Cousson (OMAP DT maintainer)] On Tue, Aug 27, 2013 at 10:54 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: On 08/27/2013 10:13 AM, Stephen Rothwell wrote: Today's linux-next merge of the arm-soc tree got a conflict in arch/arm/boot/dts/am335x-bone.dts between commit 97238b35d5bb (usb: musb: dsps: use proper child nodes) from the tree and commit 63f6b2550aa0 (ARM: dts: AM33XX: don't redefine OCP bus and device nodes) from the arm-soc tree. I fixed it up (probably incorrectly - see below) and can carry the fix as necessary (no action is required). You added the OCP node back and the USB nodes as I had them which should be fine. How do we solve the conflict for the merge window? Is it possible for the ARM-SOC tree to create a topic branch for this commit? Greg: I do have a pending pull / patches [0] which also change the dts nodes according to the latest feedback + enabling an additional USB port in bone. If you take this in I could update the nodes later (with the topic branch merged) accordingly to the way it has been done in the ARM-SOC tree - unless you have other preferences. I think that the proper way to handle this is to split the patch-set in two and merge all the OMAP DT related changes (arch/arm/boot/dts/am*) through Benoit's tree and the USB changes (drivers/usb/*) through Greg tree to prevent these kind of merge conflicts. Thanks a lot and best regards, Javier [0] http://www.spinics.net/lists/linux-usb/msg92595.html Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] MAINTAINERS: Change maintainer for cyttsp driver
I haven't had time to work on this driver for a long time and Ferruh has been doing a great job making it more generic, adding support for new hardware and providing bug fixes. So, let's make MAINTAINERS reflect reality and add him as the cyttsp maintainer instead of me. Also, since Ferruh works for Cypress, we may change the driver status from Maintained to Supported. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Ferruh, please send your ack if you are willing to take over maintainance of this driver. Also, please confirm that you have been working on behalf of Cypress instead of doing it on your free time. Otherwise we should keep the driver status to maintained instead supported. Thanks a lot and best regards, Javier MAINTAINERS |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9d771d9..4ba996c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2458,9 +2458,9 @@ S:Maintained F: drivers/media/common/cypress_firmware* CYTTSP TOUCHSCREEN DRIVER -M: Javier Martinez Canillas jav...@dowhile0.org +M: Ferruh Yigit f...@cypress.com L: linux-in...@vger.kernel.org -S: Maintained +S: Supported F: drivers/input/touchscreen/cyttsp* F: include/linux/input/cyttsp.h -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] MAINTAINERS: Change maintainer for cyttsp driver
I haven't had time to work on this driver for a long time and Ferruh has been doing a great job making it more generic, adding support for new hardware and providing bug fixes. So, let's make MAINTAINERS reflect reality and add him as the cyttsp maintainer instead of me. Also, since Ferruh works for Cypress, we may change the driver status from Maintained to Supported. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Ferruh, please send your ack if you are willing to take over maintainance of this driver. Also, please confirm that you have been working on behalf of Cypress instead of doing it on your free time. Otherwise we should keep the driver status to maintained instead supported. Thanks a lot and best regards, Javier MAINTAINERS |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9d771d9..4ba996c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2458,9 +2458,9 @@ S:Maintained F: drivers/media/common/cypress_firmware* CYTTSP TOUCHSCREEN DRIVER -M: Javier Martinez Canillas jav...@dowhile0.org +M: Ferruh Yigit f...@cypress.com L: linux-in...@vger.kernel.org -S: Maintained +S: Supported F: drivers/input/touchscreen/cyttsp* F: include/linux/input/cyttsp.h -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
On 09/10/2013 09:00 AM, Joel Fernandes wrote: On 07/31/2013 03:35 AM, Javier Martinez Canillas wrote: On 07/31/2013 01:44 AM, Linus Walleij wrote: On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely grant.lik...@linaro.org wrote: On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij linus.wall...@linaro.org wrote: To solve this dilemma, perform an interrupt consistency check when adding a GPIO chip: if the chip is both gpio-controller and interrupt-controller, walk all children of the device tree, check if these in turn reference the interrupt-controller, and if they do, loop over the interrupts used by that child and perform gpio_reques() and gpio_direction_input() on these, making them unreachable from the GPIO side. Ugh, that's pretty awful, and it doesn't actually solve the root problem of the GPIO and IRQ subsystems not cooperating. It's also a very DT-centric solution even though we're going to see the exact same issue on ACPI machines. The problem is that the patches for OMAP that I applied and now have had to revert solves it in an even uglier way, leading to breaking boards, as was noticed. The approach in this patch has the potential to actually work without regressing a bunch of boards... Whether this is a problem in ACPI or not remains to be seen, but I'm not sure about that. Device trees allows for a GPIO line to be used as an interrupt source and GPIO line orthogonally, and that is the root of this problem. Does ACPI have the same problem, or does it impose natural restrictions on such use cases? I agree with Linus here. The problem is that GPIO controllers that can work as IRQ sources are treated in the kernel as if there where two separate controlers that are rather orthogonal: an irq_chip and a gpio_chip. But DT allows to use a GPIO line as an IRQ just by using an omap-gpio phandle as interrupt-parent. So, there should be a place where both irq_chip and gpio_chip has to be related somehow to properly configure a GPIO (request it and setting it as input) when used as an IRQ by DT. My patch for OMAP used an irq_domain_ops .map function handler to configure the GPIO when a IRQ was mapped since that seemed to me as the best place to do it. This worked well in OMAP2+ platforms but unfortunately broke OMAP1 platforms since they are still using legacy domain mapping thus not call .map. Just wondering- why .map not called for omap1? irq_create_mapping does seem to call - irq_domain_associate which calls map function. For omap case, GPIO driver does call irq_create_mapping, just like omap2+ no? That is what I understood too when writing the patch but I remember someone mentioning legacy domain mapping not calling the .map function handler as a possible cause for the OMAP1 regression and since Linus decided to revert the patches in favor of a more general solution I didn't care to check if that was true or not. Now looking at irq_create_mapping() I see that my assumption was correct so I don't know what was the bug that caused the OMAP1 regression. Further, if for any reason the .map is not called. Can you not call gpio_request yourself direct in omap_gpio_chip_init function? No, since you can't request a GPIO for all GPIO pins in the bank. Users have to do it explicitly (or implicitly in the case of GPIO mapped as IRQ in DT). Does it really matter if you call gpio_request from .map or from the chip_init function? Yes it does, because in DT the core calls irq_create_of_mapping() - irq_create_mapping() - .map(). That way only are requested the GPIO pins that are mapped as IRQ and not all of them. Also on a different note.. this would call gpio_request for *every* gpio line, but isn't that what your original patch that got reverted was doing in omap_gpio_chip_init: + if (!bank-chip.of_node) + for (j = 0; j bank-width; j++) + irq_create_mapping(bank-domain, j); No it won't. This is only needed for the legacy (non-DT) boot since no one calls irq_create_mapping() so it has to be called explicitly. And in that case .map will be called but gpio_request() won't since the call is made only when bank-chip.of_node is not NULL. Just trying to understand your initial patch better. Regards, -Joel Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] gpio: interrupt consistency check for OF GPIO IRQs
On 09/10/2013 10:47 AM, Lars Poeschel wrote:
On Tuesday 10 September 2013 17:19:24, Mark Brown wrote:
On Wed, Sep 04, 2013 at 02:16:36PM -0600, Stephen Warren wrote:
On 09/04/2013 03:05 AM, Lars Poeschel wrote:
The driver that tries to use the GPIO requested by this patch before HAS
to
fail. This is exactly the intention of this patch. We don't want the
GPIO to be requested any more, if it is used as an interrupt pin.
That will break existing drivers. There are drivers that request the
same GPIO and IRQ. IIRC, the SDHCI CD (Card Detect) GPIO is requested
that way.
Yes, plus input devices and audio jack detection among others. This
pattern is very common if the GPIO is actually being used as a GPIO, an
edge triggered interrupt is used to flag when something happens and the
state is determined by reading the GPIO state (often with some
debounce).
And I say it again for those coming into the discussion late, like it has
been
said many many times before: This patch does not break any of this drivers.
They simply request their GPIO from DT and turn it into an irq using
gpio_to_irq, request that irq on their behalf and use it as GPIO and IRQ in
parallel. At least this is not a problem.
I agree with Lars and think that we should stop arguing about the limitations of
this patch and how this doesn't solve:
a) The fact that platform code has to call:
gpio_request()
gpio_direction_input()
request_irq()
b) That there are complex use cases where the same driver can request both a
GPIO and the mapped IRQ.
The only thing that this patch tries to solve is when a driver expect to request
a IRQ and it doesn't care if is a real IRQ line from an interrupt controller or
a GPIO pin mapped as an IRQ.
With board files we used to explicitly do the GPIO setup
(gpio_{request,direction_input}) but with DT these board files are gone and we
need a way to setup a GPIO implicitly when is mapped as an IRQ.
That's the only use case that this patch covers.
In legacy non-DT booting boards files will continue doing whatever are doing now
to ensure that drivers calling request_irq() will succeed and complex drivers
can just not define the GPIO-IRQ mapping in the DT and do whatever they need to
do manually.
Now, if just solving this use case is not enough and we want a more general
solution then we should start discussing how that solution should look like so
it can be implemented.
The most concrete idea so far is the one proposed by Stephen to pass a struct
device to gpiolib functions so GPIO controller drivers know when the same device
or a different one is requesting a GPIO twice to allow sharing a GPIO or not.
Also, it would be great if we can find a temporary solution so we can finally
have ethernet working with DT on most OMAP2+ boards. Since I expect that doing
the mentioned change on gpiolib would take at least a couple of kernel releases.
Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
On 09/10/2013 05:00 PM, Joel Fernandes wrote:
On 09/10/2013 08:17 AM, Javier Martinez Canillas wrote:
On 09/10/2013 09:00 AM, Joel Fernandes wrote:
On 07/31/2013 03:35 AM, Javier Martinez Canillas wrote:
On 07/31/2013 01:44 AM, Linus Walleij wrote:
On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely grant.lik...@linaro.org
wrote:
On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij
linus.wall...@linaro.org wrote:
To solve this dilemma, perform an interrupt consistency check
when adding a GPIO chip: if the chip is both gpio-controller and
interrupt-controller, walk all children of the device tree,
check if these in turn reference the interrupt-controller, and
if they do, loop over the interrupts used by that child and
perform gpio_reques() and gpio_direction_input() on these,
making them unreachable from the GPIO side.
Ugh, that's pretty awful, and it doesn't actually solve the root
problem of the GPIO and IRQ subsystems not cooperating. It's also a
very DT-centric solution even though we're going to see the exact same
issue on ACPI machines.
The problem is that the patches for OMAP that I applied
and now have had to revert solves it in an even uglier way,
leading to breaking boards, as was noticed.
The approach in this patch has the potential to actually
work without regressing a bunch of boards...
Whether this is a problem in ACPI or not remains to be seen,
but I'm not sure about that. Device trees allows for a GPIO line
to be used as an interrupt source and GPIO line orthogonally,
and that is the root of this problem. Does ACPI have the same
problem, or does it impose natural restrictions on such use
cases?
I agree with Linus here. The problem is that GPIO controllers that can
work as
IRQ sources are treated in the kernel as if there where two separate
controlers
that are rather orthogonal: an irq_chip and a gpio_chip.
But DT allows to use a GPIO line as an IRQ just by using an omap-gpio
phandle as
interrupt-parent.
So, there should be a place where both irq_chip and gpio_chip has to be
related
somehow to properly configure a GPIO (request it and setting it as input)
when
used as an IRQ by DT.
My patch for OMAP used an irq_domain_ops .map function handler to
configure the
GPIO when a IRQ was mapped since that seemed to me as the best place to do
it.
This worked well in OMAP2+ platforms but unfortunately broke OMAP1
platforms
since they are still using legacy domain mapping thus not call .map.
Just wondering- why .map not called for omap1? irq_create_mapping does seem
to
call - irq_domain_associate which calls map function. For omap case, GPIO
driver does call irq_create_mapping, just like omap2+ no?
That is what I understood too when writing the patch but I remember someone
mentioning legacy domain mapping not calling the .map function handler as a
possible cause for the OMAP1 regression and since Linus decided to revert the
patches in favor of a more general solution I didn't care to check if that
was
true or not. Now looking at irq_create_mapping() I see that my assumption was
correct so I don't know what was the bug that caused the OMAP1 regression.
Only stuff you deleted from the chip_init function was:
- for (j = 0; j bank-width; j++) {
- int irq = irq_create_mapping(bank-domain, j);
- irq_set_lockdep_class(irq, gpio_lock_class);
- irq_set_chip_data(irq, bank);
- if (bank-is_mpuio) {
- omap_mpuio_alloc_gc(bank, irq, bank-width);
- } else {
- irq_set_chip_and_handler(irq, gpio_irq_chip,
-handle_simple_irq);
- set_irq_flags(irq, IRQF_VALID);
- }
and you moved all of it to the .map function in your patch. Not sure what
could
be breaking OMAP1 cases.
You could potentially add that back with some #ifdef for OMAP1?
Either way, map should be called looks like. If its not called, then the above
block can be explicity called for OMAP1 case in omap_chip_gpio_init.
What was strange is one person reported that mappings were not created for
OMAP1. But I am wondering what you changed could result in not creating that
mapping. Really nothing..
I think your initial patch is much better than fixing up DT but then I may be
missing other problems with your patch that Linus's patch addresses.
Further, if for any reason the .map is not called. Can you not call
gpio_request
yourself direct in omap_gpio_chip_init function?
No, since you can't request a GPIO for all GPIO pins in the bank. Users have
to
do it explicitly (or implicitly in the case of GPIO mapped as IRQ in DT).
Ah since you split the patch up into 2, I missed the gpio_request stuff. Ok,
that makes sense.
Does it really matter if you call gpio_request from .map or from the
chip_init
function?
Yes it does, because in DT
Re: [PATCH v3] gpio: interrupt consistency check for OF GPIO IRQs
On 09/10/2013 09:52 PM, Stephen Warren wrote:
On 09/10/2013 07:56 AM, Javier Martinez Canillas wrote:
...
The only thing that this patch tries to solve is when a driver expect to
request
a IRQ and it doesn't care if is a real IRQ line from an interrupt controller
or
a GPIO pin mapped as an IRQ.
That can be solved in the interrupt chip driver. The fact the previous
attempt didn't work doesn't mean that it's impossible.
Indeed. Unfortunately that patch-set got merged as a fix quite late on the -rc
cycle so it was safer to just revert the patches instead of analyzing the
regression and providing a fix.
If Linus is fond about taking a local fix for gpio-omap then we can try again
as a RFC with a better test coverage than before (although the patches had
several tested and acked-by but no one tested on OMAP1 until the patches were
merged) getting some TI folks in the loop who have access to those ancient OMAP1
devices. That way we can repost as a patch just once we are definitely sure that
it won't cause a regression on any OMAP platform.
With board files we used to explicitly do the GPIO setup
(gpio_{request,direction_input}) but with DT these board files are gone and
we
need a way to setup a GPIO implicitly when is mapped as an IRQ.
Well, that's just an example of hacking around something in a board file
that should have been fixed in the GPIO/IRQ controller.
That's the only use case that this patch covers.
...
Also, it would be great if we can find a temporary solution so we can finally
have ethernet working with DT on most OMAP2+ boards. Since I expect that
doing
the mentioned change on gpiolib would take at least a couple of kernel
releases.
Really? I thought this patch was error-checking to make sure that
different drivers didn't request a GPIO and an IRQ that are actually the
same signal. This patch shouldn't affect any functionality except in
cases where there's a bug in the DT (incorrect GPIO/IRQ passed to some
driver).
Yes, it doesn't do any error-checking neither prevent a driver to request a GPIO
and an IRQ that are the same signal (as long as this is supported by the
GPIO/IRQ controller and its driver). The only thing that Linus patch does is to
auto request a GPIO for pins that are mapped as IRQ in DT (i.e: interrupt-parent
= gpio6).
The name of the function introduced by Linus is
of_gpiochip_interrupt_consistency_check() but probably a better name is
of_gpiochip_autorequest_irq() or something like that.
A similar behavior could be obtained by let's say calling gpio_request() in
irq_create_of_mapping() if you wanted to add the logic in the IRQ chip DT core
instead of doing it in the GPIO chip DT core as Linus does with his patch.
That's why I don't understand why Linus patch could be an issue for drivers that
needs to request both the GPIO and the mapped IRQ.
If this is already supported then nothing will break. If the driver tries to
request the GPIO twice because this is already made by the DT core then I think
is a bug in the driver and has to be fixed to support DT since there won't be
any need to do this manually anymore.
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] gpio: interrupt consistency check for OF GPIO IRQs
On 09/11/2013 12:34 AM, Stephen Warren wrote:
On 09/10/2013 03:37 PM, Mark Brown wrote:
On Tue, Sep 10, 2013 at 01:53:47PM -0600, Stephen Warren wrote:
Doesn't this patch call gpio_request() on the GPIO first, and
hence prevent the driver's own gpio_request() from succeeding,
since the GPIO is already requested? If this is not a problem, it
sounds like a bug in gpio_request() not ensuring mutual exclusion
for the GPIO.
Or at the very least something that's likely to break in the
future.
Looking at the GPIO code, it already prevents double-requests:
if (test_and_set_bit(FLAG_REQUESTED, desc-flags) == 0) {
desc_set_label(desc, label ? : ?);
status = 0;
} else {
status = -EBUSY;
module_put(chip-owner);
goto done;
}
And I tested it in practice, and it really does fail.
I'm a bit confused now. Doesn't the fact that gpio_request() prevents
double-requests mean that the use-case that you say that have not been covered
by this patch can't actually happen?
I mean, if when using board files an explicit call to gpio_request() is made by
platform code then a driver can't call gpio_request() for the same gpio. So this
patch shouldn't cause any regression since is just auto-requesting a GPIO when
is mapped as an IRQ in a DT which basically will be the same that was made by
board files before.
To give you an example of an use-case that this patch is trying to solve:
OMAP SoCs have a General-Purpose Memory Controller (GPMC) that can be used to
interface with Pseudo-SRAM devices such as ethernet controllers. So with board
files we currently have this (arch/arm/mach-omap2/gpmc-smsc911x.c):
void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *gpmc_cfg)
{
if (gpio_request_one(gpmc_cfg-gpio_irq, GPIOF_IN, smsc911x irq)) {
pr_err(Failed to request IRQ GPIO%d\n, gpmc_cfg-gpio_irq);
goto free1;
}
gpmc_smsc911x_resources[1].start = gpio_to_irq(gpmc_cfg-gpio_irq);
...
pdev = platform_device_register_resndata(NULL, smsc911x, gpmc_cfg-id,
gpmc_smsc911x_resources, ARRAY_SIZE(gpmc_smsc911x_resources),
gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config));
...
}
and later in the smsc911x ethernet driver probe function:
static int smsc911x_drv_probe(struct platform_device *pdev)
{
retval = request_irq(dev-irq, smsc911x_irqhandler,
irq_flags | IRQF_SHARED, dev-name, dev);
...
irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
...
dev-irq = irq_res-start;
...
retval = request_irq(dev-irq, smsc911x_irqhandler,
irq_flags | IRQF_SHARED, dev-name, dev);
...
}
The driver just knows that it has to get the IRQ from a struct resource and it
doesn't care if that is a real IRQ line from an interrupt controller or a GPIO
pin mapped as an IRQ. With linus patch I just can define on a DT (GPMC
properties omitted for simplicity):
ethernet@5,0 {
pinctrl-names = default;
pinctrl-0 = smsc911x_pins;
compatible = smsc,lan9221, smsc,lan9115;
reg = 5 0 0xff;
bank-width = 2;
interrupt-parent = gpio6;
interrupts = 16 8;
vmmc-supply = vddvario;
vmmc_aux-supply = vdd33a;
reg-io-width = 4;
smsc,save-mac-address;
};
and it will just work. Without Linus patch the call to request_irq() will fail
because a call to gpio_request() has not been made (and thus the GPIO bank was
not enabled).
Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
On 09/11/2013 05:30 PM, Alexander Holler wrote:
Am 22.08.2013 00:02, schrieb Linus Walleij:
On Tue, Aug 20, 2013 at 12:04 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Wednesday 31 July 2013 01:44:53 Linus Walleij wrote:
I don't see how sharing works here, or how another user, i.e. another one
than the user wanting to recieve the IRQ, can validly request such a line?
What would the usecase for that valid request be?
When the GPIO is wired to a status signal (such as an MMC card detect
signal)
the driver might want to read the state of the signal independently of the
interrupt handler.
That is true. But for such a complex usecase I think it's reasonable that
we only specify the GPIO in the device tree, and the driver utilizing the
IRQ need to take that and perform gpio_to_irq() on it, and then it still
works to use it both ways.
Hmm, the problem is that DT is seen as fixed. So if someone marks a GPIO
as an IRQ, it can never be used otherwise. So if you really go this way,
you should make this pretty clear in the documentation.
DT is fixed because that describes the hardware which is fixed of course. So if
a chip IRQ line is connected to a GPIO pin in a controller that should be
described in the DT and that pin can't be used for anything else.
Looking from the other side, why do you want to mark GPIOs as IRQs in
the DT at all?
Because from the component point-of-view that is wired to the SoC, that GPIO is
an IRQ line and so it has to be described.
And how will this be done? I found the way it was done in
the reverted patch very confusing because it needed an IRQ number. That
IRQ number depends on the mapping and isn't hw specific (and currently
just human doable because of the simple mapping).
That's is not true. You don't define an IRQ number what you define is a GPIO
number that is mapped as IRQ. The GPIO number does not depend on the mapping and
it only depends on the GPIO controller.
This has absolutely nothing to do with the reverted patches and is described in
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
The only difference is that the reverted patches did actually take an action
when a GPIO pin was mapped as an IRQ (requesting the GPIO and as input).
So for example in an OMAP board DT you can define something like this:
ethernet@5,0 {
compatible = smsc,lan9221, smsc,lan9115;
interrupt-parent = gpio6;
interrupts = 16 8;
};
Since each OMAP GPIO bank has 32 GPIO pins, then what you are defining is that
the GPIO 176 (5 * 32 + 16) will be mapped as the IRQ line for the ethernet
controller.
I explained the exact use case I'm trying to solve in the thread Re: [PATCH v3]
gpio: interrupt consistency check for OF GPIO IRQs [1] if you need more
context. I'm sure others cc'ed in this thread have different (but similar)
requirements.
Regards,
Alexander Holler
Thanks a lot and best regards,
Javier
[1]: http://www.kernelhub.org/?p=2msg=326503
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
On 09/12/2013 10:55 AM, Alexander Holler wrote:
Am 11.09.2013 19:42, schrieb Alexander Holler:
Am 11.09.2013 18:14, schrieb Javier Martinez Canillas:
So for example in an OMAP board DT you can define something like this:
ethernet@5,0 {
compatible = smsc,lan9221, smsc,lan9115;
interrupt-parent = gpio6;
interrupts = 16 8;
};
Since each OMAP GPIO bank has 32 GPIO pins, then what you are defining
is that
the GPIO 176 (5 * 32 + 16) will be mapped as the IRQ line for the
ethernet
controller.
By the way, how do you define two GPIOs/IRQs from different
gpio-banks/irq-controllers wuth that scheme?
That is indeed a very good question and I don't have a definite answer.
Would that be like below?
ethernet@5,0 {
compatible = smsc,lan9221, smsc,lan9115;
interrupt-parent = gpio6;
interrupts = 16 8;
interrupt-parent = gpio7;
interrupts = 1 IRQF_TRIGGER_FALLING; /* GPIO7_1 */
};
I just looked at
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and it
doesn't mention that use-case (same device using two different interrupts from
two different interrupt-controller).
So I went and look at the source in drivers/of/irq.c and noticed that the
interrupts property and its interrupt-parent is parsed by the
of_irq_map_one() function.
/**
* of_irq_map_one - Resolve an interrupt for a device
* @device: the device whose interrupt is to be resolved
* @index: index of the interrupt to resolve
* @out_irq: structure of_irq filled by this function
*
* This function resolves an interrupt, walking the tree, for a given
* device-tree node. It's the high level pendant to of_irq_map_raw().
*/
int of_irq_map_one(struct device_node *device, int index, struct of_irq
*out_irq)
{
struct device_node *p;
...
/* Get the interrupts property */
intspec = of_get_property(device, interrupts, intlen);
...
/* Look for the interrupt parent. */
p = of_irq_find_parent(device);
...
}
/**
* of_irq_find_parent - Given a device node, find its interrupt parent node
* @child: pointer to device node
*
* Returns a pointer to the interrupt parent node, or NULL if the interrupt
* parent could not be determined.
*/
struct device_node *of_irq_find_parent(struct device_node *child)
{
struct device_node *p;
const __be32 *parp;
if (!of_node_get(child))
return NULL;
do {
parp = of_get_property(child, interrupt-parent, NULL);
if (parp == NULL)
p = of_get_parent(child);
else {
if (of_irq_workarounds OF_IMAP_NO_PHANDLE)
p = of_node_get(of_irq_dflt_pic);
else
p = of_find_node_by_phandle(be32_to_cpup(parp));
}
of_node_put(child);
child = p;
} while (p of_get_property(p, #interrupt-cells, NULL) == NULL);
return p;
}
So, if I understood the code correctly the DT IRQ core doesn't expect a device
node to have more than one interrupt-parent property.
It *should* work though if you have multiple interrupts properties defined and
all of them have the same interrupt-parent:
interrupt-parent = gpio6;
interrupts = 1 IRQF_TRIGGER_HIGH; /* GPIO6_1 */
interrupts = 2 IRQF_TRIGGER_LOW; /* GPIO6_2 */
since of_irq_map_one() will be called for each interrupts and the correct
interrupt-parent will get obtained by of_irq_find_parent().
So multiple definitions of interrupt-parent are allowed and the order
does matter? And such does work? Sorry for asking, but I'm relatively
new to DT. ;)
No worries, I'm very new to DT too so let's wait for Grant, Stephen or Linus to
give us a definite answer :)
Regards,
Alexander Holler
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
On 07/31/2013 01:44 AM, Linus Walleij wrote: On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely grant.lik...@linaro.org wrote: On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij linus.wall...@linaro.org wrote: To solve this dilemma, perform an interrupt consistency check when adding a GPIO chip: if the chip is both gpio-controller and interrupt-controller, walk all children of the device tree, check if these in turn reference the interrupt-controller, and if they do, loop over the interrupts used by that child and perform gpio_reques() and gpio_direction_input() on these, making them unreachable from the GPIO side. Ugh, that's pretty awful, and it doesn't actually solve the root problem of the GPIO and IRQ subsystems not cooperating. It's also a very DT-centric solution even though we're going to see the exact same issue on ACPI machines. The problem is that the patches for OMAP that I applied and now have had to revert solves it in an even uglier way, leading to breaking boards, as was noticed. The approach in this patch has the potential to actually work without regressing a bunch of boards... Whether this is a problem in ACPI or not remains to be seen, but I'm not sure about that. Device trees allows for a GPIO line to be used as an interrupt source and GPIO line orthogonally, and that is the root of this problem. Does ACPI have the same problem, or does it impose natural restrictions on such use cases? I agree with Linus here. The problem is that GPIO controllers that can work as IRQ sources are treated in the kernel as if there where two separate controlers that are rather orthogonal: an irq_chip and a gpio_chip. But DT allows to use a GPIO line as an IRQ just by using an omap-gpio phandle as interrupt-parent. So, there should be a place where both irq_chip and gpio_chip has to be related somehow to properly configure a GPIO (request it and setting it as input) when used as an IRQ by DT. My patch for OMAP used an irq_domain_ops .map function handler to configure the GPIO when a IRQ was mapped since that seemed to me as the best place to do it. This worked well in OMAP2+ platforms but unfortunately broke OMAP1 platforms since they are still using legacy domain mapping thus not call .map. Linus' approach is much better IMHO since it is both generic and will only try to setup an GPIO when a GPIO bank is added by the DT core. So checking there if a GPIO line is being used as an IRQ and configuring the GPIO seems like a good solution to me. Old platforms like OMAP1 won't break since they don't (and probably never will) have DT support. We have to solve the problem in a better way than that. Rearranging your patch description, here are some of the points you brought up so I can comment on them... This has the following undesired effects: - The GPIOlib subsystem is not aware that the line is in use and willingly lets some other consumer perform gpio_request() on it, leading to a complex resource conflict if it occurs. If a gpio line is being both requested as a gpio and used as an interrupt line, then either a) it's a bug, or b) the gpio line needs to be used as input only so it is compatible with irq usage. b) should be supportable. Yes this is what I'm saying too I think... The bug in (a) manifested itself in the OMAP patch with no real solution in sight. - The GPIO debugfs file claims this GPIO line is free. Surely we can fix this. I still don't see a problem of having the controller request the gpio when it is claimed as an irq if we can get around the problem of another user performing a /valid/ request on the same GPIO line. The solution may be to have a special form of request or flag that allows it to be shared. I don't see how sharing works here, or how another user, i.e. another one than the user wanting to recieve the IRQ, can validly request such a line? What would the usecase for that valid request be? Basically I believe these two things need to be exclusive in the DT world: A: request_irq(a resource passed from interrupts); - core implicitly performs gpio_request() gpio_direction_input() B: gpio_request(a resource passed from gpios); gpio_direction_input() request_irq(gpio_to_irq()) Never both. And IIUC that was what happened in the OMAP case. Actually the OMAP case was not related to resource conflict but I'll explain the issues we had with the OMAP patch in a moment. First I just want to say that I don't think that makes sense that there are two users of a GPIO. There *could* be two users for the same IRQ that is mapped to a GPIO but in that case there will be only one user of the GPIO and that will be the IRQ controller even when in practice is the same chip and the same driver. If the same GPIO line is used for two devices in the DT, then gpio_request_one(gpio, GPIOF_IN, NULL) should be called just once and that state has to be saved somewhere so whoever setups the GPIO won't
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
On Sun, Sep 15, 2013 at 10:44 PM, Sebastian Reichel s...@debian.org wrote:
Add SSI device tree data for OMAP34xx and Nokia N900.
Signed-off-by: Sebastian Reichel s...@debian.org
---
Documentation/devicetree/bindings/hsi/omap_ssi.txt | 73
++
arch/arm/boot/dts/omap3-n900.dts | 8 +++
arch/arm/boot/dts/omap34xx.dtsi| 49 +++
3 files changed, 130 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hsi/omap_ssi.txt
diff --git a/Documentation/devicetree/bindings/hsi/omap_ssi.txt
b/Documentation/devicetree/bindings/hsi/omap_ssi.txt
new file mode 100644
index 000..e3597eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/omap_ssi.txt
@@ -0,0 +1,73 @@
+OMAP SSI controller bindings
+
+Required properties:
+- compatible: Should be set to the following value
+ti,omap3-ssi (applicable to OMAP34xx devices)
+- ti,hwmods: Name of the hwmod associated to the controller, which
+ is ssi.
+- reg: Contains SSI register address range (base address and
+ length).
+- reg-names: Contains the names of the address ranges. It's
+expected, that sys and gdd address ranges are
+ provided.
+- interrupts: Contains the interrupt information for the controller.
+- interrupt-names: Contains the names of the interrupts. It's expected,
+ that gdd_mpu is provided.
+- ranges Required as an empty node
+- #address-cells Should be set to 1
+- #size-cells Should be set to 1
+
+Each port is represented as a sub-node of the ti,omap3-ssi device.
+
+Required Port sub-node properties:
+- compatible: Should be set to the following value
+ti,omap3-ssi-port (applicable to OMAP34xx devices)
+- reg: Contains port's register address range (base address
+ and length).
+- reg-names: Contains the names of the address ranges. It's
+expected, that tx and rx address ranges are
+ provided.
+- interrupt-parent Should be a phandle for the interrupt controller
+- interrupts: Contains the interrupt information for the port.
+- interrupt-names: Contains the names of the interrupts. It's expected,
+ that mpu_irq0 and mpu_irq1 are provided.
+- ti,ssi-cawake-gpio: Defines which GPIO pin is used to signify CAWAKE
+ events for the port. This is an optional
board-specific
+ property. If it's missing the port will not be
+ enabled.
+
+Example for Nokia N900:
+
+ssi-controller@48058000 {
+ compatible = ti,omap3-ssi;
+ ti,hwmods = ssi;
+
+ reg = 0x48058000 0x1000,
+ 0x48059000 0x1000;
+ reg-names = sys,
+ gdd;
+
+ interrupts = 55;
+ interrupt-names = gdd_mpu;
+
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ ssi-port@0 {
+ compatible = ti,omap3-ssi-port;
+
+ reg = 0x4805a000 0x800,
+ 0x4805a800 0x800;
+ reg-names = tx,
+ rx;
+
+ interrupt-parent = intc;
+ interrupts = 51,
+52;
+ interrupt-names = mpu_irq0,
+ mpu_irq1;
+
+ ti,ssi-cawake-gpio = gpio5 23 GPIO_ACTIVE_HIGH; /* 151 */
+ }
+}
diff --git a/arch/arm/boot/dts/omap3-n900.dts
b/arch/arm/boot/dts/omap3-n900.dts
index 0582356..cc4a3e2 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -186,6 +186,14 @@
power = 50;
};
+ssi_port1 {
+ ti,ssi-cawake-gpio = gpio5 23 GPIO_ACTIVE_HIGH; /* 151 */
+};
+
+ssi_port2 {
+ status = disabled;
+};
+
uart1 {
pinctrl-names = default;
pinctrl-0 = uart1_pins;
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 5355d61..393b7a7 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -25,4 +25,53 @@
clock-latency = 30; /* From legacy driver */
};
};
+
+ ocp {
+ ssi: ssi-controller@48058000 {
+ compatible = ti,omap3-ssi;
+ ti,hwmods = ssi;
+
+ reg = 0x48058000 0x1000,
+ 0x48059000 0x1000;
+ reg-names = sys,
+ gdd;
+
+ interrupts = 55;
+ interrupt-names = gdd_mpu;
+
+ #address-cells = 1;
+
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
On Mon, Sep 16, 2013 at 5:01 PM, Sebastian Reichel s...@debian.org wrote: Hi, Is the Synchronous Serial Interface (SSI) only supported by OMAP34xx/OMAP35xx SoC and not by OMAP36xx/OMAP37xx SoC? I'm asking this since if SSI is supported by both we should add the device nodes in omap3.dtsi instead of omap34xx.dtsi. I thought that all OMAP3 SoC supported SSI and all OMAP4 SoC supported HSI but I guess I was wrong... I just do not know. Information about the SSI core is not included in the public OMAP TRM. It only lists the memory space as reserved. Thus I only included it in OMAP34xx, which is used in Nokia N900 and must support SSI. I see... hopefully someone from TI can shed some light on this. -- Sebastian Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed
On Wed, Sep 18, 2013 at 10:20 AM, Pali Rohár pali.ro...@gmail.com wrote:
On Wednesday 18 September 2013 03:49:42 Felipe Balbi wrote:
On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Rohár wrote:
On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
On Tuesday 17 September 2013 17:48:59 you wrote:
On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
More power supply drivers depends on vbus events and
without it they not working. Power supply drivers
using usb_register_notifier, so to deliver events
it is needed to call atomic_notifier_call_chain.
So without atomic notifier power supply driver
isp1704 not retrieving vbus status and reporting
bogus values to userspace and also to board
platform data functions. Without proper data
charger drivers trying to charge battery also when
charger is disconnected or do not start charging
when wallcharger connects.
Atomic notifier in musb driver was used before v3.5
and was replaced with omap mailbox. This patch
adding atomic_notifier_call_chain call from
function omap_musb_set_mailbox.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
drivers/usb/musb/omap2430.c |3 +++
drivers/usb/phy/phy-twl4030-usb.c |2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/usb/musb/omap2430.c
b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
100644 --- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -305,6 +305,9 @@ static void
omap_musb_set_mailbox(struct omap2430_glue *glue)
default:
dev_dbg(dev, ID float\n);
}
+
+ atomic_notifier_call_chain(musb-xceiv-notifier,
+ musb-xceiv-last_event, NULL);
let's add a wrapper for this:
static inline int usb_phy_notify(struct usb phy *x,
unsigned val, void *v) {
return atomic_notifier_call_chain(x-notifier, val,
v);
}
Where to add this wrapper? To omap2430.c? or some
include file?
linux/usb/phy.h
On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
diff --git a/drivers/usb/phy/phy-twl4030-usb.c
b/drivers/usb/phy/phy-twl4030-usb.c index
8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int
twl4030_usb_probe(struct platform_device *pdev)
if (device_create_file(pdev-dev,
dev_attr_vbus))
dev_warn(pdev-dev, could not create sysfs
file\n);
+ ATOMIC_INIT_NOTIFIER_HEAD(twl-phy.notifier);
BTW, this is a bugfix, send separately.
What to send separately?
This full patch 1/4 is bugfix. And I did not understand
what you want. Maybe it could be easier for you to
apply this small 3+2 lines patch how you need.
This hunk here (initializaing notifier head) is a separate
bug fix and needs its own patch.
So will you do that? Or it is needed to resend this one line
hunk again in new email again?
new patch, new email
Guys, WHY ARE YOU SO STUPID AND ARROGANT?
Sorry but, need to copy full isolated patch/hunk from one mail to
another is hassling. So what you want from me? Do all those non
sense working only because yesterday you had bad day? Or what?
Everything needed with described information was in first mail.
Also second hunk has full isolated git diff output, so it is for
you really big problem to copy it? Or you did not see that patch?
I really did not understand what you wanted from me.
BEGINNING OF PATCH
This is bugfix and sending this patch separately from all other patches.
This patch is visibly isolated from all others and could be readable also
by disabled people. For other handicapped people I suggest to increase
font size and other text settings in program which view this patch.
For visually impaired people I suggest to use some text-to-speech software.
This is small 2 lines patch, diff starting after next visible break.
This patch initializing notifier head in tw4030 usb code which is missing.
Initialization code is needed for using any atomic_notifier_* functions.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
===
BEGINNING OF DIFF
===
diff --git a/drivers/usb/phy/phy-twl4030-usb.c
b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed
On Wed, Sep 18, 2013 at 3:30 PM, Pavel Machek pa...@ucw.cz wrote: Hi! So will you do that? Or it is needed to resend this one line hunk again in new email again? new patch, new email Guys, WHY ARE YOU SO STUPID AND ARROGANT? Sorry but, need to copy full isolated patch/hunk from one mail to another is hassling. So what you want from me? Do all those non sense working only because yesterday you had bad day? Or what? ... Hi Pali, There is no need to be rude. Felipe asked you to do the split since he believes that the notifier chain call for musb xceiv and the twl-phy notifier head init should be done in two separate patches. Actually, there is need to be rude, because Felipe fails to act as maintainer. Instead of fixing bugs in his code, he bounces bugfix patches, points people to random READMEs and wastes everyones time. Pavel I don't know what are you talking about (if that happened in another thread then I need more context). Felipe is not bouncing any bugfix but just asked to split the patch in two since the patch was solving two separate issues so is way better to have it in two separate patches for the reasons I explained before. So, as far as I can tell Felipe did exactly what I would expect from a maintainer. He took the time to review the patches sent to him and gave feedback. If the sender doesn't want to take his feedback into account and prefer to send pretty insulting emails instead that is his choice but I would say that is this not the greatest approach to get your code merged (to say the least). Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ADP1653 board code for Nokia RX-51
On Wed, Sep 18, 2013 at 1:50 AM, Tony Lindgren t...@atomide.com wrote: * Aaro Koskinen aaro.koski...@iki.fi [130907 16:10]: Hi, On Fri, Sep 06, 2013 at 10:34:05PM +0200, Pali Rohár wrote: --- /dev/null +++ b/arch/arm/mach-omap2/board-rx51-camera.c [...] Ping, can you review this patch v2? I don't think Tony will accept any new board stuff for RX-51/N900. See for example: http://marc.info/?l=linux-kernelm=137629626213187w=2 There should be initial Nokia N900 DTS file in 3.12-rc1, and we should continue converting this board fully to DT. Yes let's plan on making mach-omap2 to be DT only soonish. AFAIK the only stopper right now for omap3 are the pending pinctrl changes for the wake-up events as otherwise we would have sever PM regressions with off-idle. Hi Tony, I don't know if OMAP2+ DT will happen soon as you said. At least I know about a big issue we had with GPIO pins not being auto-requested when are mapped as IRQ. You can refer to [1] for the latest approach and how this discussion have been going. This is something that we have been trying to solve for a couple of kernel releases by now so it would be great if you can join the discussion. Regards, Tony Thanks a lot and best regards, Javier [1]: https://lkml.org/lkml/2013/8/26/260 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed
On Wed, Sep 18, 2013 at 4:22 PM, Pavel Machek pa...@ucw.cz wrote: Hi! So will you do that? Or it is needed to resend this one line hunk again in new email again? new patch, new email Guys, WHY ARE YOU SO STUPID AND ARROGANT? Sorry but, need to copy full isolated patch/hunk from one mail to another is hassling. So what you want from me? Do all those non sense working only because yesterday you had bad day? Or what? ... Actually, there is need to be rude, because Felipe fails to act as maintainer. Instead of fixing bugs in his code, he bounces bugfix patches, points people to random READMEs and wastes everyones time. I don't know what are you talking about (if that happened in another thread then I need more context). Felipe is not bouncing any bugfix Take a look here: https://lkml.org/lkml/2013/9/17/286 I clearly state that patch can not be tested as required for proper submission, but offer patch anyway. I get irrelevant boilerplate on patch format. Felipe didn't complain about you not being to be able to test the patch (most of the times compile tested if enough) what he said was: Seriously though, read that file, you're commit log has garbage in it which shouldn't go to git history. which is totally true, if you want to comment things that don't have to go to the backlog you can't comment between the --- after your s-o-b and before the first diff. That's were you should puts comments like Hi! or Here's suggested patch. I don't have the hardware, so it is completely untested. but just asked to split the patch in two since the patch was solving two separate issues so is way better to have it in two separate patches for the reasons I explained before. So, as far as I can tell Felipe did exactly what I would expect from a maintainer. He took the time to review the patches sent to him and I'd expect maintainer to, well, maintain code. It means actually fixing bugs in his code, when he's pointed at them. gave feedback. If the sender doesn't want to take his feedback into account and prefer to send pretty insulting emails instead that is his choice but I would say that is this not the greatest approach to get your code merged (to say the least). Clearly not. But Pali found bug in code Felipe should maintain. Instead of thank you for bug report, I applied this one line of your code to fix it, Pali got new patch, new email for his efforts. That is how you train dogs, not how you should treat kernel contributors. No, you misunderstood the role of the maintainers. Maintainers should be custodian of a part of the kernel but not responsible for every single line of code on their sub-systems. If a piece of code is buggy then the people using and that take care of that should be fixing and maintainers should review and suggest improvements to the patches. As long as a piece of code keep compiling then it is harmless even if is buggy and nobody cares about it. If it is so broken that it doesn't even compile then the maintainer can decide to just drop it since no one else seems to care about it. If someone finds a bug on a piece of code is because that people care about that functionality. Maintainers are really busy people and can jump and fix any random bug that someone finds on a piece of code just because it is the subsystem they maintainer neither they have to blindly merge any crappy patch just because they don't have time (or interest) in fixing a reported bug on a piece of code. Now, it is possible that Felipe just has problems with english, as he called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but he appears more arogant than usual over email. Clearly he meant your commit log has garbage instead of you're, that's a typo. Pavel But neither Felipe needs someone to defend him nor I have time to keep arguing with you. Have nice day! Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt on AM335x
On Fri, Oct 18, 2013 at 8:20 AM, NeilBrown ne...@suse.de wrote:
On Sat, 5 Oct 2013 13:17:09 +0200 Andreas Fenkart afenk...@gmail.com wrote:
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, while in runtime
suspend, standard detection of the module block otherwise.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 1136e6b..146f3ad 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling
High Speed
ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
-SDIO irq while in suspend. Fallback to polling. Affected chips are
-am335x,
+SDIO irq while in suspend. The workaround is to reconfigure the dat1 line
as a
+GPIO upon suspend. Beyond this option and the GPIO config, you also need to
set
+named pinctrl states default, active and idle , see example below.
The
+MMC driver will then then toggle between default and idle during the runtime
+Affected chips are am335x,
--
| PRCM |
@@ -49,3 +52,24 @@ Example:
vmmc-supply = vmmc; /* phandle to regulator node */
ti,non-removable;
};
+
+[am335x with with gpio for sdio irq]
+
+ mmc1_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins =
+ 0x0f8 0x3f /* MMC0_DAT1 as GPIO2_28 */
+ ;
+ };
+
+ mmc1: mmc@4806 {
+ ti,non-removable;
+ bus-width = 4;
+ vmmc-supply = ldo2_reg;
+ vmmc_aux-supply = vmmc;
+ ti,quirk-swakeup-missing;
+ pinctrl-names = default, active, idle;
+ pinctrl-0 = mmc1_pins;
+ pinctrl-1 = mmc1_pins;
+ pinctrl-2 = mmc1_cirq_pin;
+ ti,cirq-gpio = gpio3 28 0;
+ };
hi,
I've been trying to get SD irq to work on my OMAP3 DM3730.
I seems to need the magic to catch interrupts while FCLK is off, as
the only way I can get it to work at the moment is to keep FCLK on.
I discovered your patch and tried it out, but it doesn't seem to work for me.
I have a Libertas WIFI chip attached to the second mmc (which is sometimes
called mmc1, and sometimes mmc2 - very confusing!).
Hi Neil,
I have a DM3730 board with the same setup, Libertas (Marvell SD8686)
wifi + bt chip attached to mmc2.
I was going to try to add support for this to the DTS but it would be
great if I can use your as a reference.
Would you be so kind to share your DTS?
Thanks a lot and best regards,
Javier
I added:
mmc2_cirq_pin: pinmux_cirq_pin {
pinctrl-single,pins =
0x012e (PIN_INPUT_PULLUP | MUX_MODE4) /* MMC2_DAT1
as GPIO5_5 */
;
};
and
mmc2 {
ti,quirk-swakeup-missing;
pinctrl-names = default, active, idle;
pinctrl-0 = mmc2_pins;
pinctrl-1 = mmc2_pins;
pinctrl-2 = mmc2_cirq_pin;
ti,cirq-gpio = gpio5 5 0; /* GPIO133 = 128+5 */
};
to my dts file but it doesn't make any apparent difference.
Any idea what I might be doing wrong?
(the base kernel I am applying patches to is from 8th Oct,
commit 0e7a3ed04f0cd4311096d691888f88569310ee6c)
BTW,
- with the default polling, I get about 1Mb/sec with iperf
- with sd-irq enabled and FCLK kept on the whole time, I get 4Mb/sec
- with sd-irq enable, FCLK kept on, and the 5ms polling also
running, I get over 5Mb/sec!
Still much less than the 40Mb/sec that I would like to get...
Thanks,
NeilBrown
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt on AM335x
On Sat, Oct 19, 2013 at 1:14 AM, NeilBrown ne...@suse.de wrote:
On Fri, 18 Oct 2013 12:12:48 +0200 Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
On Fri, Oct 18, 2013 at 8:20 AM, NeilBrown ne...@suse.de wrote:
On Sat, 5 Oct 2013 13:17:09 +0200 Andreas Fenkart afenk...@gmail.com
wrote:
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, while in runtime
suspend, standard detection of the module block otherwise.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 1136e6b..146f3ad 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for
handling High Speed
ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
-SDIO irq while in suspend. Fallback to polling. Affected chips are
-am335x,
+SDIO irq while in suspend. The workaround is to reconfigure the dat1
line as a
+GPIO upon suspend. Beyond this option and the GPIO config, you also need
to set
+named pinctrl states default, active and idle , see example below.
The
+MMC driver will then then toggle between default and idle during the
runtime
+Affected chips are am335x,
--
| PRCM |
@@ -49,3 +52,24 @@ Example:
vmmc-supply = vmmc; /* phandle to regulator node */
ti,non-removable;
};
+
+[am335x with with gpio for sdio irq]
+
+ mmc1_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins =
+ 0x0f8 0x3f /* MMC0_DAT1 as GPIO2_28 */
+ ;
+ };
+
+ mmc1: mmc@4806 {
+ ti,non-removable;
+ bus-width = 4;
+ vmmc-supply = ldo2_reg;
+ vmmc_aux-supply = vmmc;
+ ti,quirk-swakeup-missing;
+ pinctrl-names = default, active, idle;
+ pinctrl-0 = mmc1_pins;
+ pinctrl-1 = mmc1_pins;
+ pinctrl-2 = mmc1_cirq_pin;
+ ti,cirq-gpio = gpio3 28 0;
+ };
hi,
I've been trying to get SD irq to work on my OMAP3 DM3730.
I seems to need the magic to catch interrupts while FCLK is off, as
the only way I can get it to work at the moment is to keep FCLK on.
I discovered your patch and tried it out, but it doesn't seem to work for
me.
I have a Libertas WIFI chip attached to the second mmc (which is sometimes
called mmc1, and sometimes mmc2 - very confusing!).
Hi Neil,
I have a DM3730 board with the same setup, Libertas (Marvell SD8686)
wifi + bt chip attached to mmc2.
I was going to try to add support for this to the DTS but it would be
great if I can use your as a reference.
Would you be so kind to share your DTS?
My DTS is below. It contains an number of things that are not supported in
mainline yet. Details can be found in
git://neil.brown.name/gta04 mainline
and
http://git.neil.brown.name/?p=gta04.git;a=shortlog;h=refs/heads/mainline
(this is my working tree and gets rebased and messed up regularly).
NeilBrown
Hello Neil,
Thanks a lot for your DTS and the pointers to your trees.
Best regards,
Javier
/*
* Copyright (C) 2013 Marek Belisko ma...@goldelico.com
*
* Based on omap3-beagle-xm.dts
*
* 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/;
#define RFKILL_TYPE_GPS 6
#include omap36xx.dtsi
/ {
model = OMAP3 GTA04;
compatible = ti,omap3-gta04, ti,omap3;
chosen {
bootargs = console=ttyO2,115200n8 vram=12M
omapfb.rotate_type=0 omapdss.def_disp=lcd root=/dev/mmcblk0p2 rw
rootfstype=ext3 rootwait twl4030_charger.allow_usb=1
musb_hdrc.preserve_vbus=1 log_buf_len=8M ignore_loglevel no_console_suspend;
};
cpus {
cpu@0 {
cpu0-supply = vcc;
};
};
memory {
device_type = memory;
reg = 0x8000 0x2000; /* 512 MB */
};
aux-keys {
compatible = gpio-keys;
aux-button {
label = aux;
linux,code = 169;
gpios = gpio1 7 GPIO_ACTIVE_HIGH;
gpio-key,wakeup;
};
};
incoming-keys
Re: [RFC 01/23] gpio/omap: raw read and write endian fix
On 11/19/2013 10:29 AM, Linus Walleij wrote: On Sat, Nov 16, 2013 at 1:01 AM, Taras Kondratiuk taras.kondrat...@linaro.org wrote: From: Victor Kamensky victor.kamen...@linaro.org All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first simply reads/writes register, the second will byteswap it if host operates in BE mode. Changes are trivial sed like replacement of __raw_xxx functions with xxx_relaxed variant. Signed-off-by: Victor Kamensky victor.kamen...@linaro.org Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org Since I generally just dislike __raw accessors I went and applied this. If it collides with any of Tony's fixup work I might need to take the patch out again, no big deal. Some ACKs would be nice, but unless there are major objections this stays merged. Looks good to me and also I've tested this patch on a TI DM3730 (Cortex A-8) board in LE mode and found no regressions on devices using a GPIO. Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Yours, Linus Walleij Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
Hi Kishon, On Fri, Dec 6, 2013 at 1:06 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while creating MUSB core device. So in usb_bind_phy (binds the controller with the PHY), the device name of the controller had *.auto* in it. Since with using PLATFORM_DEVID_AUTO, there is no way to know the exact device name in advance, the data given in usb_bind_phy became obsolete and usb_get_phy was failing. So MUSB wrapper was modified not to use PLATFORM_DEVID_AUTO. Corresponding change is done in board file here. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/mach-omap2/board-2430sdp.c|2 +- arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-cm-t35.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |2 +- arch/arm/mach-omap2/board-ldp.c|2 +- arch/arm/mach-omap2/board-omap3beagle.c|2 +- arch/arm/mach-omap2/board-omap3logic.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-omap3stalker.c |2 +- arch/arm/mach-omap2/board-omap3touchbook.c |2 +- arch/arm/mach-omap2/board-overo.c |2 +- arch/arm/mach-omap2/board-rx51.c |2 +- 12 files changed, 12 insertions(+), 12 deletions(-) You can drop this patch since boards files are being removed for v3.14 Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] MIPS: octeon: use irq_get_trigger_type() to get IRQ flags
Use irq_get_trigger_type() to get the IRQ trigger type flags
instead calling irqd_get_trigger_type(irq_desc_get_irq_data(irq))
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/mips/cavium-octeon/octeon-irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/mips/cavium-octeon/octeon-irq.c
b/arch/mips/cavium-octeon/octeon-irq.c
index a22f06a..7181def 100644
--- a/arch/mips/cavium-octeon/octeon-irq.c
+++ b/arch/mips/cavium-octeon/octeon-irq.c
@@ -607,7 +607,7 @@ static void octeon_irq_ciu_gpio_ack(struct irq_data *data)
static void octeon_irq_handle_gpio(unsigned int irq, struct irq_desc *desc)
{
- if (irqd_get_trigger_type(irq_desc_get_irq_data(desc))
IRQ_TYPE_EDGE_BOTH)
+ if (irq_get_trigger_type(irq) IRQ_TYPE_EDGE_BOTH)
handle_edge_irq(irq, desc);
else
handle_level_irq(irq, desc);
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] irqdomain: use irq_get_trigger_type() to get IRQ flags
Use irq_get_trigger_type() to get the IRQ trigger type flags instead calling irqd_get_trigger_type(irq_desc_get_irq_data(virq)) Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- kernel/irq/irqdomain.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c index 54a4d522..ff3eebb 100644 --- a/kernel/irq/irqdomain.c +++ b/kernel/irq/irqdomain.c @@ -698,7 +698,7 @@ unsigned int irq_create_of_mapping(struct device_node *controller, /* Set type if specified and different than the current one */ if (type != IRQ_TYPE_NONE - type != (irqd_get_trigger_type(irq_get_irq_data(virq + type != irq_get_trigger_type(virq)) irq_set_irq_type(virq, type); return virq; } -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] mfd: twl4030-irq: use irq_get_trigger_type() to get IRQ flags
Use irq_get_trigger_type() to get the IRQ trigger type flags
instead calling irqd_get_trigger_type(irq_get_irq_data(irq))
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/mfd/twl4030-irq.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index a5f9888..9d2d1ba 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -537,16 +537,13 @@ static void twl4030_sih_bus_sync_unlock(struct irq_data
*data)
/* Modify only the bits we know must change */
while (edge_change) {
int i = fls(edge_change) - 1;
- struct irq_data *idata;
int byte = i 2;
int off = (i 0x3) * 2;
unsigned inttype;
- idata = irq_get_irq_data(i + agent-irq_base);
-
bytes[byte] = ~(0x03 off);
- type = irqd_get_trigger_type(idata);
+ type = irq_get_trigger_type(i + agent-irq_base);
if (type IRQ_TYPE_EDGE_RISING)
bytes[byte] |= BIT(off + 1);
if (type IRQ_TYPE_EDGE_FALLING)
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] mfd: stmpe: use irq_get_trigger_type() to get IRQ flags
Use irq_get_trigger_type() to get the IRQ trigger type flags
instead calling irqd_get_trigger_type(irq_get_irq_data(irq))
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/mfd/stmpe.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index bbccd51..5d5e6f9 100644
--- a/drivers/mfd/stmpe.c
+++ b/drivers/mfd/stmpe.c
@@ -1208,8 +1208,7 @@ int stmpe_probe(struct stmpe_client_info *ci, int partnum)
}
stmpe-variant = stmpe_noirq_variant_info[stmpe-partnum];
} else if (pdata-irq_trigger == IRQF_TRIGGER_NONE) {
- pdata-irq_trigger =
- irqd_get_trigger_type(irq_get_irq_data(stmpe-irq));
+ pdata-irq_trigger = irq_get_trigger_type(stmpe-irq);
}
ret = stmpe_chip_init(stmpe);
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] genirq: add irq_get_trigger_type() to get IRQ flags
Drivers that want to get the trigger edge/level type flags for a
given interrupt have to first call irq_get_irq_data(irq) to get
the struct irq_data and then irqd_get_trigger_type(irq_data) to
obtain the IRQ flags.
This is not only error prone but also unnecessary exposes the
struct irq_data to callers.
It's better to have an irq_get_trigger_type() function to obtain
the edge/level flags for an IRQ.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
include/linux/irq.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index bc4e066..0e8e3a6 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -579,6 +579,12 @@ static inline struct msi_desc *irq_data_get_msi(struct
irq_data *d)
return d-msi_desc;
}
+static inline u32 irq_get_trigger_type(unsigned int irq)
+{
+ struct irq_data *d = irq_get_irq_data(irq);
+ return d ? irqd_get_trigger_type(d) : 0;
+}
+
int __irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
struct module *owner);
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] arm: orion: use irq_get_trigger_type() to get IRQ flags
Use irq_get_trigger_type() to get the IRQ trigger type flags
instead calling irqd_get_trigger_type(irq_get_irq_data(irq))
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/plat-orion/gpio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-orion/gpio.c b/arch/arm/plat-orion/gpio.c
index 249fe63..6816192 100644
--- a/arch/arm/plat-orion/gpio.c
+++ b/arch/arm/plat-orion/gpio.c
@@ -426,7 +426,7 @@ static void gpio_irq_handler(unsigned irq, struct irq_desc
*desc)
if (!(cause (1 i)))
continue;
- type = irqd_get_trigger_type(irq_get_irq_data(irq));
+ type = irq_get_trigger_type(irq);
if ((type IRQ_TYPE_SENSE_MASK) == IRQ_TYPE_EDGE_BOTH) {
/* Swap polarity (race with GPIO line) */
u32 polarity;
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] genirq: add irq_get_trigger_type() to get IRQ flags
Drivers that want to get the trigger edge/level type flags for a given interrupt have to first call irq_get_irq_data(irq) to get the struct irq_data and then irqd_get_trigger_type(irq_data) to obtain the IRQ flags. This is not only error prone but also unnecessary exposes the struct irq_data to callers. This patch-set adds a new function irq_get_trigger_type() to obtain the edge/level flags for an IRQ and updates the places where irq_get_irq_data(irq) was called just to obtain the flags from the struct irq_data. The patch-set is composed of the following patches: [PATCH 1/7] genirq: add irq_get_trigger_type() to get IRQ flags [PATCH 2/7] gpio: mvebu: use irq_get_trigger_type() to get IRQ flags [PATCH 3/7] mfd: twl4030-irq: use irq_get_trigger_type() to get IRQ flags [PATCH 4/7] mfd: stmpe: use irq_get_trigger_type() to get IRQ flags [PATCH 5/7] arm: orion: use irq_get_trigger_type() to get IRQ flags [PATCH 6/7] MIPS: octeon: use irq_get_trigger_type() to get IRQ flags [PATCH 7/7] irqdomain: use irq_get_trigger_type() to get IRQ flags arch/arm/plat-orion/gpio.c |2 +- arch/mips/cavium-octeon/octeon-irq.c |2 +- drivers/gpio/gpio-mvebu.c|2 +- drivers/mfd/stmpe.c |3 +-- drivers/mfd/twl4030-irq.c|5 + include/linux/irq.h |6 ++ kernel/irq/irqdomain.c |2 +- 7 files changed, 12 insertions(+), 10 deletions(-) Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] gpio: mvebu: use irq_get_trigger_type() to get IRQ flags
Use irq_get_trigger_type() to get the IRQ trigger type flags
instead calling irqd_get_trigger_type(irq_get_irq_data(irq))
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-mvebu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index 3a4816a..80ad35e 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -457,7 +457,7 @@ static void mvebu_gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
if (!(cause (1 i)))
continue;
- type = irqd_get_trigger_type(irq_get_irq_data(irq));
+ type = irq_get_trigger_type(irq);
if ((type IRQ_TYPE_SENSE_MASK) == IRQ_TYPE_EDGE_BOTH) {
/* Swap polarity (race with GPIO line) */
u32 polarity;
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] of: irq: Pass trigger type in IRQ resource flags
On 15/06/2013, at 00:00, Grant Likely grant.lik...@linaro.org wrote: On Wed, 05 Jun 2013 20:20:39 +0200, Tomasz Figa tomasz.f...@gmail.com wrote: Hi, On Sunday 19 of May 2013 00:56:30 Tomasz Figa wrote: Some drivers might rely on availability of trigger flags in IRQ resource, for example to configure the hardware for particular interrupt type. However current code creating IRQ resources from data in device tree does not configure trigger flags in resulting resources. This patch solves the problem, based on the fact that irq_of_parse_and_map() configures the trigger based on DT interrupt specifier, IRQD_TRIGGER_* flags are consistent with IORESOURCE_IRQ_*, and we can get trigger type by calling irqd_get_trigger_type() after mapping the interrupt. Signed-off-by: Tomasz Figa tomasz.f...@gmail.com --- drivers/of/irq.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/of/irq.c b/drivers/of/irq.c index a3c1c5a..79a7a26 100644 --- a/drivers/of/irq.c +++ b/drivers/of/irq.c @@ -355,6 +355,16 @@ int of_irq_to_resource(struct device_node *dev, int index, struct resource *r) r-start = r-end = irq; r-flags = IORESOURCE_IRQ; r-name = name ? name : dev-full_name; + +/* + * Some drivers might rely on availability of trigger flags + * in IRQ resource. Since irq_of_parse_and_map() configures the + * trigger based on interrupt specifier and IRQD_TRIGGER_* + * flags are consistent with IORESOURCE_IRQ_*, we can get + * trigger type that was just set and pass it through resource + * flags as well. + */ +r-flags |= irqd_get_trigger_type(irq_get_irq_data(irq)); } return irq; Any comments on this patch? That's actually a pretty good solution and a whole lot less invasive that the approach that Javier was pursuing. Javier, I'm going to pick up this patch. Please yell if it doesn't solve the problem that you're trying to solve. g. It solves the issue I was trying to solve and the solution is indeed more elegant and simpler than the one I posted. Thanks a lot for pointing this out. Best regards, Javier-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cyttsp: Fix swap of mfg_stat and mfg_cmd registers
On Tue, Jun 4, 2013 at 11:19 PM, Matthias Kaehlcke matthias.l...@kaehlcke.net wrote: The command and status register in the driver were swapped with respect to the order specified in the datasheet (CY8CTMA140). Confirmed with Cypress that the order in the datasheet is correct. Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net --- Acked-by: Javier Martinez Canillas jav...@dowhile0.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/4] Input: cyttsp4 - driver for Cypress TMA4XX touchscreen devices
Hi Ferruh, On Tue, Jun 4, 2013 at 11:34 AM, Ferruh Yigit f...@cypress.com wrote: This driver is for Cypress TrueTouch(tm) Standard Product controllers, Generation4 devices. This is third version of submission code, modifications: - code re-structured to match with existing Generation3 driver code. - common I2C code for Gen3 and Gen4 devices split and shared. Thanks a lot for reusing as much as possible from the existing Gen3 driver. This is exactly what I meant in my feedback on your second version of the driver. Driver consist of three modules: - Core module: Main module, gets data from TTSP controller, sent MT events to Linux - I2C module: Underlying communication with I2C bus - SPI module: Underlying communication with SPI bus Ferruh Yigit (4): Input: cyttsp - I2C driver split into two modules Input: cyttsp4 - Core driver for Cypress TMA4XX touchscreen devices Input: cyttsp4 - I2C driver for Cypress TMA4XX touchscreen devices Input: cyttsp4 - SPI driver for Cypress TMA4XX touchscreen devices For the whole series: Acked-by: Javier Martinez Canillas jav...@dowhile0.org drivers/input/touchscreen/Kconfig | 30 + drivers/input/touchscreen/Makefile|5 +- drivers/input/touchscreen/cyttsp4_core.c | 2173 + drivers/input/touchscreen/cyttsp4_core.h | 472 ++ drivers/input/touchscreen/cyttsp4_i2c.c | 90 + drivers/input/touchscreen/cyttsp4_spi.c | 205 +++ drivers/input/touchscreen/cyttsp_core.c |6 +- drivers/input/touchscreen/cyttsp_core.h | 11 +- drivers/input/touchscreen/cyttsp_i2c.c| 50 +- drivers/input/touchscreen/cyttsp_i2c_common.c | 79 + drivers/input/touchscreen/cyttsp_spi.c| 38 +- include/linux/platform_data/cyttsp4.h | 76 + 12 files changed, 3161 insertions(+), 74 deletions(-) create mode 100644 drivers/input/touchscreen/cyttsp4_core.c create mode 100644 drivers/input/touchscreen/cyttsp4_core.h create mode 100644 drivers/input/touchscreen/cyttsp4_i2c.c create mode 100644 drivers/input/touchscreen/cyttsp4_spi.c create mode 100644 drivers/input/touchscreen/cyttsp_i2c_common.c create mode 100644 include/linux/platform_data/cyttsp4.h -- 1.7.9.5 Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] genirq: add irq_get_trigger_type() to get IRQ flags
On 06/18/2013 12:29 AM, Grant Likely wrote: On Fri, Jun 14, 2013 at 5:40 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Drivers that want to get the trigger edge/level type flags for a given interrupt have to first call irq_get_irq_data(irq) to get the struct irq_data and then irqd_get_trigger_type(irq_data) to obtain the IRQ flags. This is not only error prone but also unnecessary exposes the struct irq_data to callers. This patch-set adds a new function irq_get_trigger_type() to obtain the edge/level flags for an IRQ and updates the places where irq_get_irq_data(irq) was called just to obtain the flags from the struct irq_data. The patch-set is composed of the following patches: [PATCH 1/7] genirq: add irq_get_trigger_type() to get IRQ flags [PATCH 2/7] gpio: mvebu: use irq_get_trigger_type() to get IRQ flags [PATCH 3/7] mfd: twl4030-irq: use irq_get_trigger_type() to get IRQ flags [PATCH 4/7] mfd: stmpe: use irq_get_trigger_type() to get IRQ flags [PATCH 5/7] arm: orion: use irq_get_trigger_type() to get IRQ flags [PATCH 6/7] MIPS: octeon: use irq_get_trigger_type() to get IRQ flags [PATCH 7/7] irqdomain: use irq_get_trigger_type() to get IRQ flags For the whole series: Acked-by: Grant Likely grant.lik...@linaro.org Hello Thomas, Do you have any comments on this patch-set? It has been ack'ed by a lot of people so I wonder if you could take it. Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8] ARM: dts: omap4-panda: Update the LED support for the panda DTS
On Fri, May 31, 2013 at 4:48 PM, Dan Murphy dmur...@ti.com wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v8 - Rebase to latest and use pinctrl macros -
https://patchwork.kernel.org/patch/2629351/
v7 - Update headline to add spaces -
https://patchwork.kernel.org/patch/2583661/
v6 - Review comments updated - https://patchwork.kernel.org/patch/2582771/
v5 - Provide pincrtl phandle to the gpio-led driver -
https://patchwork.kernel.org/patch/2573981/
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 28
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index d5d144a..523a800 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,8 +16,13 @@
reg = 0x8000 0x4000; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = gpio-leds;
+ pinctrl-names = default;
+ pinctrl-0 =
+ led_wkgpio_pins
+ ;
+
heartbeat {
label = pandaboard::status1;
gpios = gpio1 7 GPIO_ACTIVE_HIGH;
@@ -157,6 +162,15 @@
};
};
+omap4_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins =
+ 0x1a (PIN_OUTPUT | MUX_MODE3) /* gpio_wk7 OUTPUT |
MODE 3 */
+ 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 OUTPUT |
MODE 3 */
Hello Dan,
The OUTPUT | MODE 3 in the comments were added so people shouldn't
have to look at the TRM to find what each constant number meant. But
now using the macros this is not needed anymore, so I don't think is
necessary to keep that on the comments.
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Input: cyttsp - fix memcpy size param
Hi Ferruh, On Fri, May 10, 2013 at 3:32 PM, Ferruh Yigit f...@cypress.com wrote: memcpy param is wrong because of offset in bl_cmd, this may corrupt the stack which may cause a crash. Tested-by: Ferruh Yigit f...@cypress.com on TMA300-DVK Signed-off-by: Ferruh Yigit f...@cypress.com Nice catch, thanks for fixing it Acked-by: Javier Martinez Canillas jav...@dowhile0.org --- drivers/input/touchscreen/cyttsp_core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/touchscreen/cyttsp_core.c b/drivers/input/touchscreen/cyttsp_core.c index 8e60437..97ba891 100644 --- a/drivers/input/touchscreen/cyttsp_core.c +++ b/drivers/input/touchscreen/cyttsp_core.c @@ -133,7 +133,7 @@ static int cyttsp_exit_bl_mode(struct cyttsp *ts) memcpy(bl_cmd, bl_command, sizeof(bl_command)); if (ts-pdata-bl_keys) memcpy(bl_cmd[sizeof(bl_command) - CY_NUM_BL_KEYS], - ts-pdata-bl_keys, sizeof(bl_command)); + ts-pdata-bl_keys, CY_NUM_BL_KEYS); error = ttsp_write_block_data(ts, CY_REG_BASE, sizeof(bl_cmd), bl_cmd); -- 1.7.9.5 This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. In the future can you please drop this footer? It has no point to state the above when you send emails to a public mailing list. Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Input: cyttsp - add missing handshake
On Fri, May 10, 2013 at 3:32 PM, Ferruh Yigit f...@cypress.com wrote:
For the devices that has blocking with timeout communication, these
extra handshakes will prevent one timeout delay in startup sequence
Tested-by: Ferruh Yigit f...@cypress.com on TMA300-DVK
Signed-off-by: Ferruh Yigit f...@cypress.com
---
drivers/input/touchscreen/cyttsp_core.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/input/touchscreen/cyttsp_core.c
b/drivers/input/touchscreen/cyttsp_core.c
index 97ba891..7007f58 100644
--- a/drivers/input/touchscreen/cyttsp_core.c
+++ b/drivers/input/touchscreen/cyttsp_core.c
@@ -116,6 +116,13 @@ static int ttsp_send_command(struct cyttsp *ts, u8 cmd)
return ttsp_write_block_data(ts, CY_REG_BASE, sizeof(cmd), cmd);
}
+static int _cyttsp_hndshk(struct cyttsp *ts, u8 hst_mode)
+{
+ if (ts-pdata-use_hndshk)
+ return ttsp_send_command(ts, hst_mode ^ CY_HNDSHK_BIT);
+ return 0;
+}
+
static int cyttsp_load_bl_regs(struct cyttsp *ts)
{
memset(ts-bl_data, 0, sizeof(ts-bl_data));
@@ -167,6 +174,10 @@ static int cyttsp_set_operational_mode(struct cyttsp *ts)
if (error)
return error;
+ error = _cyttsp_hndshk(ts, ts-xy_data.hst_mode);
+ if (error)
+ return error;
+
return ts-xy_data.act_dist == CY_ACT_DIST_DFLT ? -EIO : 0;
}
@@ -188,6 +199,10 @@ static int cyttsp_set_sysinfo_mode(struct cyttsp *ts)
if (error)
return error;
+ error = _cyttsp_hndshk(ts, ts-sysinfo_data.hst_mode);
+ if (error)
+ return error;
+
if (!ts-sysinfo_data.tts_verh !ts-sysinfo_data.tts_verl)
return -EIO;
@@ -344,12 +359,9 @@ static irqreturn_t cyttsp_irq(int irq, void *handle)
goto out;
/* provide flow control handshake */
- if (ts-pdata-use_hndshk) {
- error = ttsp_send_command(ts,
- ts-xy_data.hst_mode ^ CY_HNDSHK_BIT);
- if (error)
- goto out;
- }
+ error = _cyttsp_hndshk(ts, ts-xy_data.hst_mode);
+ if (error)
+ goto out;
if (unlikely(ts-state == CY_IDLE_STATE))
goto out;
--
1.7.9.5
This message and any attachments may contain Cypress (or its subsidiaries)
confidential information. If it has been received in error, please advise the
sender and immediately delete this message.
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] MAINTAINERS: Change maintainer for cyttsp driver
On Tue, Jul 16, 2013 at 8:57 AM, Ferruh Yigit f...@cypress.com wrote: On 07/15/2013 12:41 AM, Javier Martinez Canillas wrote: I haven't had time to work on this driver for a long time and Ferruh has been doing a great job making it more generic, adding support for new hardware and providing bug fixes. Thank you a lot for your work on cyttsp drivers, we would like to see your support back whenever you have time again. Your expertise/know-how on issue is valuable. So, let's make MAINTAINERS reflect reality and add him as the cyttsp maintainer instead of me. Also, since Ferruh works for Cypress, we may change the driver status from Maintained to Supported. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Ferruh, please send your ack if you are willing to take over maintainance of this driver. Acked-by: Ferruh Yigit f...@cypress.com Also, please confirm that you have been working on behalf of Cypress instead of doing it on your free time. Otherwise we should keep the driver status to maintained instead supported. Right, I am a Cypress employee and working on TrueTouch drivers. Thanks a lot and best regards, Javier MAINTAINERS |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9d771d9..4ba996c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2458,9 +2458,9 @@ S:Maintained F:drivers/media/common/cypress_firmware* CYTTSP TOUCHSCREEN DRIVER -M: Javier Martinez Canillas jav...@dowhile0.org +M: Ferruh Yigit f...@cypress.com L:linux-in...@vger.kernel.org -S: Maintained +S: Supported F:drivers/input/touchscreen/cyttsp* F:include/linux/input/cyttsp.h -- Regards, ferruh Hi Dmitry and Henrik, Any comments about this patch? It was sent a couple of months ago... Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the usb tree
On Thu, Aug 29, 2013 at 12:06 PM, Benoit Cousson bcous...@baylibre.com wrote: Hi Felipe On 27/08/2013 21:56, Felipe Balbi wrote: Hi, On Tue, Aug 27, 2013 at 12:30:21PM -0700, Greg KH wrote: On Tue, Aug 27, 2013 at 01:37:32PM -0500, Felipe Balbi wrote: Hi, On Tue, Aug 27, 2013 at 10:37:32AM -0700, Greg KH wrote: On Tue, Aug 27, 2013 at 04:13:23PM +0200, Sebastian Andrzej Siewior wrote: On 08/27/2013 04:05 PM, Benoit Cousson wrote: On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote: On 08/27/2013 03:57 PM, Benoit Cousson wrote: + Kevin, On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote: What do we do now? Cannot you just merge the stable arm-soc/dt branch into your branch before applying your patches? That is up to Greg. This changes sat in his usb-next tree for a while now. And before they hit Greg they were in Felipe's tree for a while. To be exact, last .dts change via USB was: Author: Sebastian Andrzej Siewior bige...@linutronix.de AuthorDate: Thu Jun 20 12:13:04 2013 +0200 Commit: Felipe Balbi ba...@ti.com CommitDate: Fri Aug 9 17:40:16 2013 +0300 usb: musb dma: add cppi41 dma driver Mmm, if that branch is supposed to be stable, I'm not sure it will be doable... Maybe we should do the other way around? And merge usb-next into arm-soc/dt. Kevin, Olof? Please be aware that I have no response so far regarding [0] from Greg. [0] http://www.spinics.net/lists/linux-usb/msg92595.html Nor will you, given that I am not the one to take these patches, Felipe is. I noticed now that you said please route around Felipe, but sorry, no, I'm not going to do that unless there's a really good reason. Felipe seems to be around at the moment, please work with him on this. If you will still take a 'part2' pull request from me, I can send you urgent bugfixes by friday. If I have some time left, I can even try to get that sorted out by tomorrow. For 3.12 stuff, like fixes, sure, I can take them this week, that should give us a week or so for linux-next testing, right? that's correct. I have most of them already queued up, let me just go over my linux-usb maildir again and make sure I got all the important stuff in. cheers, thanks for opening this 'window'. There are two patches in my DTS tree that conflict with the usb-next. I will remove that one (ARM: dts: AM33XX: don't redefine OCP bus and device nodes) , as suggested by Olof, since it is the biggest source of conflict from my tree. Hi Benoit, Should I re-post this patch for 3.13 or do you think that the clean-up is not worth it due the high probability to lead to a merge conflict? I know is an intrusive change but a needed cleanup IMHO. People keep doing copy paste with current am33xx DT and keep duplicating device nodes already existing in the included .dtsi file. I reviewed at least 2 new DTS that had the same issue. Also, this shouldn't had happened if all the OMAP DT patches went through your tree... The second one is easily fixable, and Stephen already did it, but it will be even better it you could take it in your tree. This is the patch you did that I just slightly renamed (ARM: OMAP5: dts: fix reg property size). Regards, Benoit Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] gpio: interrupt consistency check for OF GPIO IRQs
On 08/29/2013 09:26 PM, Linus Walleij wrote: On Tue, Aug 27, 2013 at 10:17 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 08/26/2013 08:07 AM, Lars Poeschel wrote: Currently the kernel is ambigously treating GPIOs and interrupts from a GPIO controller: GPIOs and interrupts are treated as orthogonal. This unfortunately makes it unclear how to actually retrieve and request a GPIO line or interrupt from a GPIO controller in the device tree probe path. I still think that this patch is the wrong approach. Instead, the logic should be hooked into gpio_request() and request_irq(). This patch only addresses DT, and ignores anything else, hence doesn't seem like the right level of abstraction to plug in, since the issue is not related to DT. We tried to do it that way, and it exploded. See commit b4419e1a15905191661ffe75ba2f9e649f5d565e gpio/omap: auto request GPIO as input if used as IRQ via DT Here request_irq() augmented through its irqdomain to issue gpio_request_one(). Why was this patch reverted? It seems this is what has not managed to reach the audience here. The mentioned patch also broke some ancient platforms that have not been (and probably never will) migrated to DT like OMAP1. So, after trying to add this logic by using a custom irq domain .map function handler for the OMAP GPIO driver I agree with Linus that is better to provide a solution at the Device Tree level to not affect platforms that are still using legacy boot. Legacy boot don't need a fix since it does not have this issue. Platform code just request the GPIO and do the setup (gpio_direction_input) before the drivers call to request_irq(). It turns out some drivers were already doing this: request_gpio(gpio); gpio_direction_input(gpio); request_irq(gpio_to_irq(gpio)); Looks perfectly valid right? Not so: after the above change, we tried to request the GPIO a *second time* in the GPIO driver's irq map function, and of course it failed, as it was already taken. So saying that it should be done in the request_irq() function is imposing this other semantic on the kernel instead: you must *NOT* request the GPIO with request_gpio() if you're going to use it as an IRQ. (Also, it force us to implement the same code in each and every driver, but that is a lesser problem.) I don't quite understand what is so hard around this. We cannot get away from restricting the semantics in some way, if gpio-controllers shall also be interrupt-controllers, the current patch is the least intrusive I've seen so far. We have been trying to solve this issue for a few months by now and Linus' approach seems to be the most sensible solution to me. Drivers that request an IRQ and assume that platform code will request and setup the GPIO have been broken since the boards using these drivers were migrated to DT (e.g: smsc911x on OMAP2+ boards). I know is really hard to agree on the better approach to solve this but it would be great if we can find a solution and fix these broken platforms. And I don't even think this is a Linux problem, handing out the same resource with two hands is ambigous and is going to cause problems with any operating system. It is better to restrict this and say in the binding doc that the gpio line cannot be gpio n assigned when there is an interrupt on the same line. Indeed, if a driver wants to manually request a GPIO to be used as an IRQ, then the DT binding for that driver should not use a gpio as interrupt-parent and should leave the driver to handle this manually. On the other hand, if a driver just calls request_irq() and it does not know if the IRQ is a real interrupt line from an interrupt controller or a GPIO line acting as an IRQ, then the DT binding should just have a required interrupt-parent property to define the phandle for the interrupt controller used which could or could not be a GPIO controller. We can start out by printing warnings when we fail to request the corresponding GPIO for an interrupt line though, it will be annoying enough and a kind of compromise. If the GPIO pin is first requested because it is described to be an IRQ in a DT and then a driver tries to request the same GPIO pin, then there is a bug in either the DT or the driver IMHO. The same assumption is made with platform code right now when using legacy boot, I don't understand why is different for the DT case. Or it has to be the GPIO input hogs. Yours, Linus Walleij Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
On Wed, Jul 3, 2013 at 4:15 PM, Luciano Coelho coe...@ti.com wrote:
On Wed, 2013-07-03 at 17:03 +0300, Luciano Coelho wrote:
The platform_quirk element in the platform data was used to change the
way the IRQ is triggered. When set, the EDGE_IRQ quirk would change
the irqflags used and treat edge trigger differently from the rest.
Instead of hiding this irq flag setting behind the quirk, have the
board files set the flags during initialization. This will be more
meaningful than driver-specific quirks when we switch to DT.
Additionally, fix missing gpio_request() calls in the boarding files
(so that setting the flags actually works).
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
---
[...]
@@ -5928,16 +5927,21 @@ static void wlcore_nvs_cb(const struct firmware *fw,
void *context)
wlcore_adjust_conf(wl);
wl-irq = platform_get_irq(pdev, 0);
- wl-platform_quirks = pdata-platform_quirks;
wl-if_ops = pdev_data-if_ops;
- if (wl-platform_quirks WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
- irqflags = IRQF_TRIGGER_RISING;
- else
- irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
+ irq_data = irq_get_irq_data(wl-irq);
+ if (!irq_data) {
+ wl1271_error(couldn't get irq data for irq %d\n, wl-irq);
+ ret = -EINVAL;
+ goto out_free_nvs;
+ }
+
+ wl-irq_flags = irqd_get_trigger_type(irq_data);
BTW, there seems to be a patch on its way to make reading the flags
easier (ie. no need to get the irq_data first):
http://mid.gmane.org/1367945288-5625-1-git-send-email-jav...@dowhile0.org
I'm not sure if this is going to be taken in, but if it does, it would
be nice to change the code here to use the new irq_get_trigger_type()
function.
--
Luca.
Hi Luca
That patch has been already merged in Linus tree as commit 1f6236bf
(genirq: Add irq_get_trigger_type() to get IRQ flags).
So yes, it would be better if you can use irq_get_trigger_type()
instead calling irq_get_irq_data() + irqd_get_trigger_type().
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] gpio/omap: auto-setup a GPIO when used as an IRQ
To use a GPIO pin as an interrupt line, two previous configurations
have to be made:
a) Map the GPIO pin as an interrupt line into the Linux irq space
b) Enable the GPIO bank and configure the GPIO direction as input
Most GPIO/IRQ chip drivers just create a mapping for every single
GPIO pin with irq_create_mapping() on .probe so users usually can
assume a) and only have to do b) by using the following sequence:
gpio_request(gpio, foo IRQ);
gpio_direction_input(gpio);
and then request a IRQ with:
irq = gpio_to_irq(gpio);
request_irq(irq, ...);
Some drivers know that their IRQ line is being driven by a GPIO
and use a similar sequence as the described above but others are
not aware or don't care wether their IRQ is a real line from an
interrupt controller or a GPIO pin acting as an IRQ.
In these cases board files did all the necessary GPIO setup so the
drivers could only call request_irq() on the provided IRQ.
Unfortuntaly this does not work when booting with Device Trees since
the OF irq core does neither request the GPIO nor set its direction.
A DTS just defines the GPIO controller phandle as a interrupt-parent
so drivers get the mapped GPIO-IRQ line but request_irq() fails since
the setup was never made.
The first attemp to solve this issue was by adding a custom .map()
irq_domain_ops function handler in the gpio-omap driver that called
gpio_request_one() to request and setup the GPIO direction as input.
This was made on commits:
0e970cec (gpio/omap: don't create an IRQ mapping for every GPIO on DT)
b4419e1a (gpio/omap: auto request GPIO as input if used as IRQ via DT)
but they got reverted since broke OMAP1 platforms.
This patch solves this issue with a different approach, by doing all
the needed hardware setup on the GPIO/IRQ chip driver when a call to
request_irq() is made.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Hello,
This patch is an attempt to solve the long standing issue that we have been
discussing in thread:
[PATCH v3] gpio: interrupt consistency check for OF GPIO IRQs [1]
The fix is just for OMAP of course and not a kernel wide solution but Linus
approach (which I think is the best general solution proposed so far) has
some resistance so it seems that it won't be merged and we really need a
solution for OMAP if we want to finish our migration to Device Tree soon.
The patch is based on 3.12-rc1 but is not meant to be merged as a fix for
this -rc cycle. I would like it to be tested ideally on every OMAP platform
supported in mainline. So is better to wait until we are sure that this does
not cause a regression on any platform than ending reverting the patch like
it happened last time.
Thanks a lot and best regards,
Javier
[1]: https://lkml.org/lkml/2013/8/26/260
drivers/gpio/gpio-omap.c | 54 +++-
1 file changed, 31 insertions(+), 23 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0ff4355..218ce3d 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -420,6 +420,29 @@ static int _set_gpio_triggering(struct gpio_bank *bank,
int gpio,
return 0;
}
+static void _set_gpio_mode(struct gpio_bank *bank, unsigned offset)
+{
+ if (bank-regs-pinctrl) {
+ void __iomem *reg = bank-base + bank-regs-pinctrl;
+
+ /* Claim the pin for MPU */
+ __raw_writel(__raw_readl(reg) | (1 offset), reg);
+ }
+
+ if (bank-regs-ctrl !bank-mod_usage) {
+ void __iomem *reg = bank-base + bank-regs-ctrl;
+ u32 ctrl;
+
+ ctrl = __raw_readl(reg);
+ /* Module is enabled, clocks are not gated */
+ ctrl = ~GPIO_MOD_CTRL_BIT;
+ __raw_writel(ctrl, reg);
+ bank-context.ctrl = ctrl;
+ }
+
+ bank-mod_usage |= 1 offset;
+}
+
static int gpio_irq_type(struct irq_data *d, unsigned type)
{
struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
@@ -427,8 +450,8 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
int retval;
unsigned long flags;
- if (WARN_ON(!bank-mod_usage))
- return -EINVAL;
+ if (!bank-mod_usage)
+ pm_runtime_get_sync(bank-dev);
#ifdef CONFIG_ARCH_OMAP1
if (d-irq IH_MPUIO_BASE)
@@ -438,6 +461,11 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
if (!gpio)
gpio = irq_to_gpio(bank, d-hwirq);
+ spin_lock_irqsave(bank-lock, flags);
+ _set_gpio_mode(bank, GPIO_INDEX(bank, gpio));
+ _set_gpio_direction(bank, GPIO_INDEX(bank, gpio), 1);
+ spin_unlock_irqrestore(bank-lock, flags);
+
if (type ~IRQ_TYPE_SENSE_MASK)
return -EINVAL;
@@ -611,27 +639,7 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
* request_irq() or set_irq_type().
*/
_set_gpio_triggering(bank, offset
Re: [PATCH v3] gpio: interrupt consistency check for OF GPIO IRQs
On 09/16/2013 07:09 PM, Stephen Warren wrote:
On 09/16/2013 10:03 AM, Lars Poeschel wrote:
On Monday 16 September 2013 13:43:50, Stephen Warren wrote:
On 09/10/2013 06:52 PM, Javier Martinez Canillas wrote:
On 09/11/2013 12:34 AM, Stephen Warren wrote:
On 09/10/2013 03:37 PM, Mark Brown wrote:
On Tue, Sep 10, 2013 at 01:53:47PM -0600, Stephen Warren wrote:
Doesn't this patch call gpio_request() on the GPIO first, and
hence prevent the driver's own gpio_request() from succeeding,
since the GPIO is already requested? If this is not a problem, it
sounds like a bug in gpio_request() not ensuring mutual exclusion
for the GPIO.
Or at the very least something that's likely to break in the
future.
Looking at the GPIO code, it already prevents double-requests:
if (test_and_set_bit(FLAG_REQUESTED, desc-flags) == 0) {
desc_set_label(desc, label ? : ?);
status = 0;
} else {
status = -EBUSY;
module_put(chip-owner);
goto done;
}
And I tested it in practice, and it really does fail.
I'm a bit confused now. Doesn't the fact that gpio_request() prevents
double-requests mean that the use-case that you say that have not been
covered by this patch can't actually happen?
I mean, if when using board files an explicit call to gpio_request() is
made by platform code then a driver can't call gpio_request() for the
same gpio. So this patch shouldn't cause any regression since is just
auto-requesting a GPIO when is mapped as an IRQ in a DT which basically
will be the same that was made by board files before.
I'm not familiar with the board file path; Linus describe this.
It seems Linus is busy, I'll try to help out.
It sounds like that path is for the case where a driver /only/ cares
about using a pin as an IRQ, and hence the driver only calls
request_irq(). The board file is (earlier) calling gpio_request() in
order to set up that input pin to work correctly as an IRQ. Hence, there
is no double-call to gpio_request().
No, a board file is not a path or something. A board file describes the
wirings
and specifics of an (embedded) computer in C code. The complete knowledge of
how things are connected on a board and which drivers to use is in this
piece
of code. Devicetree replaces legacy board files. These two do pretty much
the
same, but board files have more power, because they are executed and can
contain whatever code is needed to setup a board.
But you are right, the driver only calls request_irq(), the board file set
up
the pin before and told the driver which irq to use.
path == code path, or execution path. I'm well aware of what board files
are in general.
I'm just not familiar with board files that employ this particular hack.
The case I said wouldn't work is:
* This patch calls gpio_request() in order to make the pin work as an IRQ.
* Driver uses the pin as both a GPIO and an IRQ, and hence calls
gpio_request() and request_irq().
So, there's a double-call to gpio_request(), which fails, and the driver
fails to probe.
Again, no. In that case you don't define your pin as irq in the device tree,
but only as gpio. The driver knows how to handle gpios and turn them into
irqs
so you have to present it a gpio not an irq. In that case the patch will not
call gpio_request() and there is no double-call to gpio_request().
That is a way to make this patch work, yes. However, there's no
guarantee that every driver or DT binding works this way. Forcing
bindings to work that way is forcing Linux-internal details upon
bindings, which should not be done. Put another way, I don't believe
there's any rule when writing DT bindings that states that bindings must
not describe the same pin as both a GPIO and an IRQ, although admittedly
that may be unusual.
...
I agree with you that it would be the best if the only call would be
request_irq and the chip driver programs the HW appropriately. It would be a
dream, but unfortunately this is not possible at the moment. This is
something
that Linus pointed out very very early in this whole discussion. The gpio
and
irq frameworks don't share any information. The irq framework has no chance
to
program the HW, because it will never find the related gpio.
For this to work the frameworks have to change (and possibly all
drivers/board
files/whatever using request_irq() and/or request_gpio()) have to change.
That is something that I do not dare to do alone.
This is a controller-specific issue, and has nothing to do with the GPIO
or IRQ frameworks. The driver for the combined irq/gpio_chip simply
needs to program the HW when the IRQ is requested or set up. The Tegra
driver already works this way, so there's actual proof that it is
possible to do this in practice.
Hi Stephen,
I finally had some time to look at this and tried
Re: [RFC] gpio/omap: auto-setup a GPIO when used as an IRQ
On 09/23/2013 06:45 PM, Tony Lindgren wrote:
* Javier Martinez Canillas javier.marti...@collabora.co.uk [130922 07:49]:
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -420,6 +420,29 @@ static int _set_gpio_triggering(struct gpio_bank *bank,
int gpio,
return 0;
}
+static void _set_gpio_mode(struct gpio_bank *bank, unsigned offset)
+{
+if (bank-regs-pinctrl) {
+void __iomem *reg = bank-base + bank-regs-pinctrl;
+
+/* Claim the pin for MPU */
+__raw_writel(__raw_readl(reg) | (1 offset), reg);
+}
+
+if (bank-regs-ctrl !bank-mod_usage) {
+void __iomem *reg = bank-base + bank-regs-ctrl;
+u32 ctrl;
+
+ctrl = __raw_readl(reg);
+/* Module is enabled, clocks are not gated */
+ctrl = ~GPIO_MOD_CTRL_BIT;
+__raw_writel(ctrl, reg);
+bank-context.ctrl = ctrl;
+}
+
+bank-mod_usage |= 1 offset;
+}
+
static int gpio_irq_type(struct irq_data *d, unsigned type)
{
struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
@@ -427,8 +450,8 @@ static int gpio_irq_type(struct irq_data *d, unsigned
type)
int retval;
unsigned long flags;
-if (WARN_ON(!bank-mod_usage))
-return -EINVAL;
+if (!bank-mod_usage)
+pm_runtime_get_sync(bank-dev);
#ifdef CONFIG_ARCH_OMAP1
if (d-irq IH_MPUIO_BASE)
@@ -438,6 +461,11 @@ static int gpio_irq_type(struct irq_data *d, unsigned
type)
if (!gpio)
gpio = irq_to_gpio(bank, d-hwirq);
+spin_lock_irqsave(bank-lock, flags);
+_set_gpio_mode(bank, GPIO_INDEX(bank, gpio));
+_set_gpio_direction(bank, GPIO_INDEX(bank, gpio), 1);
+spin_unlock_irqrestore(bank-lock, flags);
+
if (type ~IRQ_TYPE_SENSE_MASK)
return -EINVAL;
Hi Tony, thanks a lot for your feedback.
Hmm does this still work for legacy platform data based
drivers that are doing gpio_request() first?
Yes it still work when booting using board files. I tested on my OMAP3 board and
it worked in both DT and legacy booting mode.
And what's the path for clearing things for PM when free_irq()
gets called? It seems that this would leave the GPIO bank
enabled causing a PM regression?
Indeed, I did set bank-mod_usage |= 1 offset so the bank is enabled if the
device goes to suspended and then resumed but I completely forget about the
clearing path when the IRQ is freed.
Which makes me think that we should probably maintain two usage variables, one
for GPIO and another one for IRQ and check both of them on the suspend/resume pm
functions.
Other than the two concerns above it seems that this might
be the way to go to fix the regression for the -rc cycle.
Regards,
Tony
Great, I'll do these changes when posting as a proper PATCH.
Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] gpio/omap: auto-setup a GPIO when used as an IRQ
On 09/23/2013 06:14 PM, Stephen Warren wrote: On 09/22/2013 08:40 AM, Javier Martinez Canillas wrote: To use a GPIO pin as an interrupt line, two previous configurations have to be made: a) Map the GPIO pin as an interrupt line into the Linux irq space b) Enable the GPIO bank and configure the GPIO direction as input Most GPIO/IRQ chip drivers just create a mapping for every single GPIO pin with irq_create_mapping() on .probe so users usually can assume a) and only have to do b) by using the following sequence: gpio_request(gpio, foo IRQ); gpio_direction_input(gpio); and then request a IRQ with: irq = gpio_to_irq(gpio); request_irq(irq, ...); Some drivers know that their IRQ line is being driven by a GPIO and use a similar sequence as the described above but others are not aware or don't care wether their IRQ is a real line from an interrupt controller or a GPIO pin acting as an IRQ. ... I think that explanation is a bit like retro-actively implying that drivers /should/ be aware of whether their IRQ is a GPIO or not, and should be acting differently. However, they should not. I know the patch description is rather verbose but since we have been discussing this a lot and people have different opinions I wanted to explain some context and the motivation for the patch. I would much rather see a simpler patch description along the lines of: The OMAP GPIO controller HW requires that a pin be configured in GPIO mode in order to operate as an interrupt input. Since drivers should not be aware of whether an interrupt pin is also a GPIO or not, the HW should be fully configured/enabled as an IRQ if a driver solely uses IRQ APIs such as request_irq, and never calls any GPIO-related APIs. As such, add the missing HW setup to the OMAP GPIO controller's irq_chip driver. Thanks for the suggestion, I'll use something like that when I do a proper post as a PATCH and not RFC. The code change looks like it does what I would expect though. Great, let's see what is the feedback from Santosh and Kevin about the implementation since they are the maintainers of this driver. I really hope we can find a solution to this long standing issue. Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] gpio/omap: auto-setup a GPIO when used as an IRQ
On 09/23/2013 10:15 PM, Linus Walleij wrote: On Sun, Sep 22, 2013 at 4:40 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: To use a GPIO pin as an interrupt line, two previous configurations have to be made: a) Map the GPIO pin as an interrupt line into the Linux irq space b) Enable the GPIO bank and configure the GPIO direction as input Most GPIO/IRQ chip drivers just create a mapping for every single GPIO pin with irq_create_mapping() on .probe so users usually can assume a) and only have to do b) by using the following sequence: gpio_request(gpio, foo IRQ); gpio_direction_input(gpio); and then request a IRQ with: irq = gpio_to_irq(gpio); request_irq(irq, ...); I guess I have to live with this approach, but I'd like to - if possible - address my pet issue. - It is OK that the HW get set up as GPIO input by the IRQ request function alone. (Through gpio_irq_type I guess). Yes, this is how is made on this patch indeed. - When a second caller calls omap_gpio_request() it should be OK as well, but only if the flags corresponds to the previously enabled input mode. Else it should be disallowed. - The same should happen for _set_gpio_direction() if a pin previously set up for IRQ gets a request to be used as output. If this cannot be tracked in the driver, it is certainly a candidate for something that gpiolib should be doing. And then I'm open to solutions to how we can do that. Ok, this can be tracked in the driver, will add it when posting v2 soon. If this needs to be applied pronto to fix the regression I'm happy with that too, if we add a big boilerplate stating the above problem and that it needs to be *fixed* at some point. But in either case I want this to be tested on OMAP1 before I apply it, as in a Tested-by tag. Agreed. Even though this is a fix for a long standing issue I prefer it to be tested extensively than applying the patch in a rush just to learn that causes regressions and have to be reverted as it happens last time. So as you said let's wait until we have a few Tested-by tags by people using different OMAP platforms specially OMAP1. Yours, Linus Walleij Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] gpio/omap: auto-setup a GPIO when used as an IRQ
On 09/24/2013 09:39 AM, Sricharan R wrote: Hi, On Monday 23 September 2013 10:37 PM, Tony Lindgren wrote: * Javier Martinez Canillas javier.marti...@collabora.co.uk [130923 10:09]: On 09/23/2013 06:45 PM, Tony Lindgren wrote: Hmm does this still work for legacy platform data based drivers that are doing gpio_request() first? Yes it still work when booting using board files. I tested on my OMAP3 board and it worked in both DT and legacy booting mode. OK great. And what's the path for clearing things for PM when free_irq() gets called? It seems that this would leave the GPIO bank enabled causing a PM regression? Indeed, I did set bank-mod_usage |= 1 offset so the bank is enabled if the device goes to suspended and then resumed but I completely forget about the clearing path when the IRQ is freed. Which makes me think that we should probably maintain two usage variables, one for GPIO and another one for IRQ and check both of them on the suspend/resume pm functions. Yes that it seems that they should be treated separately. To understand, why cant the flag be cleared in gpio_irq_shutdown ? Hi Sricharan, Without this patch today drivers do this: gpio_request(gpio, foo IRQ); // bank-mod_usage |= 1 offset gpio_direction_input(gpio); and then request a IRQ with: irq = gpio_to_irq(gpio); request_irq(irq, ...); later on its cleanup path: free_irq(irq, dev); gpio_free(gpio) // bank-mod_usage = ~(1 offset); So if you clear the flag on gpio_irq_shutdown then bank module won't be enabled after a suspend making drivers using the GPIO after freeing the IRQ to fail. So the idea is to have something like this: a) Drivers that request both the GPIO and IRQ gpio_request(gpio, foo IRQ); // bank-mod_usage |= 1 offset gpio_direction_input(gpio); irq = gpio_to_irq(gpio); request_irq(irq, ...); // bank-irq_usage |= 1 offset free_irq(irq, dev); // bank-irq_usage = ~(1 offset); gpio_free(gpio) // bank-mod_usage = ~(1 offset); b) Drivers that just request the IRQ: irq = gpio_to_irq(gpio); request_irq(irq, ...); // bank-irq_usage |= 1 offset free_irq(irq, dev); // bank-irq_usage = ~(1 offset); So irq_usage or mod_usage is set means that the bank has to be enabled and if both are not set means that the bank module can be disabled. Regards, Sricharan Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ
The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether an interrupt pin is also a GPIO or not,
the HW should be fully configured/enabled as an IRQ if a driver solely
uses IRQ APIs such as request_irq(), and never calls any GPIO-related
APIs. As such, add the missing HW setup to the OMAP GPIO controller's
irq_chip driver.
Since this bypasses the GPIO subsystem we have to ensure that another
caller won't be able to request the same GPIO pin that is used as an
IRQ and set its direction as output. Requesting the GPIO and setting
its direction as input is allowed though.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Tested on a OMAP3 DM3730 board with both legacy and DT based booting.
Changes since v1:
- Simplify patch description as suggested by Stephen Warren.
- Track IRQ and GPIO module usage separately.
- Add clearing path for PM when free_irq() is called to not
leave the bank unnecessary enabled as suggested by Tony Lindgren.
- Check if the line is used as IRQ to not allow a second caller
to set the GPIO direction as output as suggested by Linus Walleij.
drivers/gpio/gpio-omap.c | 158 ++-
1 file changed, 101 insertions(+), 57 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0ff4355..89675f8 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -63,6 +63,7 @@ struct gpio_bank {
struct gpio_chip chip;
struct clk *dbck;
u32 mod_usage;
+ u32 irq_usage;
u32 dbck_enable_mask;
bool dbck_enabled;
struct device *dev;
@@ -86,6 +87,9 @@ struct gpio_bank {
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
#define GPIO_MOD_CTRL_BIT BIT(0)
+#define BANK_USED(bank) (bank-mod_usage || bank-irq_usage)
+#define LINE_USED(line, offset) (line (1 offset))
+
static int irq_to_gpio(struct gpio_bank *bank, unsigned int gpio_irq)
{
return bank-chip.base + gpio_irq;
@@ -420,15 +424,69 @@ static int _set_gpio_triggering(struct gpio_bank *bank,
int gpio,
return 0;
}
+static void _enable_gpio_module(struct gpio_bank *bank, unsigned offset)
+{
+ if (bank-regs-pinctrl) {
+ void __iomem *reg = bank-base + bank-regs-pinctrl;
+
+ /* Claim the pin for MPU */
+ __raw_writel(__raw_readl(reg) | (1 offset), reg);
+ }
+
+ if (bank-regs-ctrl !BANK_USED(bank)) {
+ void __iomem *reg = bank-base + bank-regs-ctrl;
+ u32 ctrl;
+
+ ctrl = __raw_readl(reg);
+ /* Module is enabled, clocks are not gated */
+ ctrl = ~GPIO_MOD_CTRL_BIT;
+ __raw_writel(ctrl, reg);
+ bank-context.ctrl = ctrl;
+ }
+}
+
+static void _disable_gpio_module(struct gpio_bank *bank, unsigned offset)
+{
+ void __iomem *base = bank-base;
+
+ if (bank-regs-wkup_en
+ !LINE_USED(bank-mod_usage, offset)
+ !LINE_USED(bank-irq_usage, offset)) {
+ /* Disable wake-up during idle for dynamic tick */
+ _gpio_rmw(base, bank-regs-wkup_en, 1 offset, 0);
+ bank-context.wake_en =
+ __raw_readl(bank-base + bank-regs-wkup_en);
+ }
+
+ if (bank-regs-ctrl !BANK_USED(bank)) {
+ void __iomem *reg = bank-base + bank-regs-ctrl;
+ u32 ctrl;
+
+ ctrl = __raw_readl(reg);
+ /* Module is disabled, clocks are gated */
+ ctrl |= GPIO_MOD_CTRL_BIT;
+ __raw_writel(ctrl, reg);
+ bank-context.ctrl = ctrl;
+ }
+}
+
+static int gpio_is_input(struct gpio_bank *bank, int mask)
+{
+ void __iomem *reg = bank-base + bank-regs-direction;
+
+ return __raw_readl(reg) mask;
+}
+
static int gpio_irq_type(struct irq_data *d, unsigned type)
{
struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
unsigned gpio = 0;
int retval;
unsigned long flags;
+ unsigned offset;
- if (WARN_ON(!bank-mod_usage))
- return -EINVAL;
+ if (!BANK_USED(bank))
+ pm_runtime_get_sync(bank-dev);
#ifdef CONFIG_ARCH_OMAP1
if (d-irq IH_MPUIO_BASE)
@@ -446,7 +504,17 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
return -EINVAL;
spin_lock_irqsave(bank-lock, flags);
- retval = _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), type);
+ offset = GPIO_INDEX(bank, gpio);
+ retval = _set_gpio_triggering(bank, offset, type);
+ if (!LINE_USED(bank-mod_usage, offset)) {
+ _enable_gpio_module(bank, offset);
+ _set_gpio_direction(bank, offset, 1);
+ } else if (!gpio_is_input(bank, 1 offset)) {
+ spin_unlock_irqrestore(bank-lock
Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ
On 09/24/2013 05:40 PM, Tony Lindgren wrote:
* Javier Martinez Canillas javier.marti...@collabora.co.uk [130924 01:06]:
The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether an interrupt pin is also a GPIO or not,
the HW should be fully configured/enabled as an IRQ if a driver solely
uses IRQ APIs such as request_irq(), and never calls any GPIO-related
APIs. As such, add the missing HW setup to the OMAP GPIO controller's
irq_chip driver.
Since this bypasses the GPIO subsystem we have to ensure that another
caller won't be able to request the same GPIO pin that is used as an
IRQ and set its direction as output. Requesting the GPIO and setting
its direction as input is allowed though.
Also please mention the regression that this fixes. So far we know
that smsc911x for tobi and igep boards in mainline, and also the
MMC card detect for omap4 boards.
Ok, I'll mention that on the next post.
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -63,6 +63,7 @@ struct gpio_bank {
struct gpio_chip chip;
struct clk *dbck;
u32 mod_usage;
+u32 irq_usage;
u32 dbck_enable_mask;
bool dbck_enabled;
struct device *dev;
@@ -86,6 +87,9 @@ struct gpio_bank {
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
#define GPIO_MOD_CTRL_BIT BIT(0)
+#define BANK_USED(bank) (bank-mod_usage || bank-irq_usage)
+#define LINE_USED(line, offset) (line (1 offset))
Hmm this patch is hard to read, maybe break it into two patches?
First you could do a patch to prepare thing by introducing
BANK_USED and LINE_USED.
+static int gpio_is_input(struct gpio_bank *bank, int mask)
+{
+void __iomem *reg = bank-base + bank-regs-direction;
+
+return __raw_readl(reg) mask;
+}
And also move gpio_is_input() around in the first patch.
Then the second patch for the fix would probably be much
easier to read.
Sure will split in more patches, I just wanted to keep in one patch since it was
a RFC but it seems that the change makes sense so I'll post it as a proper
patch-set.
Regards,
Tony
Thanks a lot for your feedback and best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] gpio/omap: maintain GPIO and IRQ usage separately
The GPIO OMAP controller pins can be used as IRQ and GPIO
independently so is necessary to keep track GPIO pins and
IRQ lines usage separately to make sure that the bank will
always be enabled while being used.
Also move gpio_is_input() definition in preparation for the
next patch that setups the controller's irq_chip driver when
a caller requests an interrupt line.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-omap.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0ff4355..a4fe038 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -63,6 +63,7 @@ struct gpio_bank {
struct gpio_chip chip;
struct clk *dbck;
u32 mod_usage;
+ u32 irq_usage;
u32 dbck_enable_mask;
bool dbck_enabled;
struct device *dev;
@@ -86,6 +87,9 @@ struct gpio_bank {
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
#define GPIO_MOD_CTRL_BIT BIT(0)
+#define BANK_USED(bank) (bank-mod_usage || bank-irq_usage)
+#define LINE_USED(line, offset) (line (1 offset))
+
static int irq_to_gpio(struct gpio_bank *bank, unsigned int gpio_irq)
{
return bank-chip.base + gpio_irq;
@@ -420,6 +424,13 @@ static int _set_gpio_triggering(struct gpio_bank *bank,
int gpio,
return 0;
}
+static int gpio_is_input(struct gpio_bank *bank, int mask)
+{
+ void __iomem *reg = bank-base + bank-regs-direction;
+
+ return __raw_readl(reg) mask;
+}
+
static int gpio_irq_type(struct irq_data *d, unsigned type)
{
struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
@@ -427,7 +438,7 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
int retval;
unsigned long flags;
- if (WARN_ON(!bank-mod_usage))
+ if (WARN_ON(!BANK_USED(bank)))
return -EINVAL;
#ifdef CONFIG_ARCH_OMAP1
@@ -447,6 +458,7 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
spin_lock_irqsave(bank-lock, flags);
retval = _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), type);
+ bank-irq_usage |= 1 GPIO_INDEX(bank, gpio);
spin_unlock_irqrestore(bank-lock, flags);
if (type (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH))
@@ -603,7 +615,7 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
* If this is the first gpio_request for the bank,
* enable the bank module.
*/
- if (!bank-mod_usage)
+ if (!BANK_USED(bank))
pm_runtime_get_sync(bank-dev);
spin_lock_irqsave(bank-lock, flags);
@@ -619,7 +631,7 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
__raw_writel(__raw_readl(reg) | (1 offset), reg);
}
- if (bank-regs-ctrl !bank-mod_usage) {
+ if (bank-regs-ctrl !BANK_USED(bank)) {
void __iomem *reg = bank-base + bank-regs-ctrl;
u32 ctrl;
@@ -654,7 +666,7 @@ static void omap_gpio_free(struct gpio_chip *chip, unsigned
offset)
bank-mod_usage = ~(1 offset);
- if (bank-regs-ctrl !bank-mod_usage) {
+ if (bank-regs-ctrl !BANK_USED(bank)) {
void __iomem *reg = bank-base + bank-regs-ctrl;
u32 ctrl;
@@ -672,7 +684,7 @@ static void omap_gpio_free(struct gpio_chip *chip, unsigned
offset)
* If this is the last gpio to be freed in the bank,
* disable the bank module.
*/
- if (!bank-mod_usage)
+ if (!BANK_USED(bank))
pm_runtime_put(bank-dev);
}
@@ -762,8 +774,10 @@ static void gpio_irq_shutdown(struct irq_data *d)
struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
unsigned int gpio = irq_to_gpio(bank, d-hwirq);
unsigned long flags;
+ unsigned offset = GPIO_INDEX(bank, gpio);
spin_lock_irqsave(bank-lock, flags);
+ bank-irq_usage = ~(1 offset);
_reset_gpio(bank, gpio);
spin_unlock_irqrestore(bank-lock, flags);
}
@@ -897,13 +911,6 @@ static int gpio_input(struct gpio_chip *chip, unsigned
offset)
return 0;
}
-static int gpio_is_input(struct gpio_bank *bank, int mask)
-{
- void __iomem *reg = bank-base + bank-regs-direction;
-
- return __raw_readl(reg) mask;
-}
-
static int gpio_get(struct gpio_chip *chip, unsigned offset)
{
struct gpio_bank *bank;
@@ -1400,7 +1407,7 @@ void omap2_gpio_prepare_for_idle(int pwr_mode)
struct gpio_bank *bank;
list_for_each_entry(bank, omap_gpio_list, node) {
- if (!bank-mod_usage || !bank-loses_context)
+ if (!BANK_USED(bank) || !bank-loses_context)
continue;
bank-power_mode = pwr_mode;
@@ -1414,7 +1421,7 @@ void omap2_gpio_resume_after_idle(void)
struct gpio_bank *bank;
list_for_each_entry(bank
[PATCH 2/2] gpio/omap: auto-setup a GPIO when used as an IRQ
The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether an interrupt pin is also a GPIO or not,
the HW should be fully configured/enabled as an IRQ if a driver solely
uses IRQ APIs such as request_irq(), and never calls any GPIO-related
APIs. As such, add the missing HW setup to the OMAP GPIO controller's
irq_chip driver.
Since this bypasses the GPIO subsystem we have to ensure that another
driver won't be able to request the same GPIO pin that is used as an
IRQ and set its direction as output. Requesting the GPIO and setting
its direction as input is allowed though.
This fixes smsc911x ethernet support for tobi and igep OMAP3 boards
and OMAP4 SDP SPI based ethernet that use a GPIO as an interrupt line.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-omap.c | 129 ++-
1 file changed, 83 insertions(+), 46 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index a4fe038..89675f8 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -424,6 +424,52 @@ static int _set_gpio_triggering(struct gpio_bank *bank,
int gpio,
return 0;
}
+static void _enable_gpio_module(struct gpio_bank *bank, unsigned offset)
+{
+ if (bank-regs-pinctrl) {
+ void __iomem *reg = bank-base + bank-regs-pinctrl;
+
+ /* Claim the pin for MPU */
+ __raw_writel(__raw_readl(reg) | (1 offset), reg);
+ }
+
+ if (bank-regs-ctrl !BANK_USED(bank)) {
+ void __iomem *reg = bank-base + bank-regs-ctrl;
+ u32 ctrl;
+
+ ctrl = __raw_readl(reg);
+ /* Module is enabled, clocks are not gated */
+ ctrl = ~GPIO_MOD_CTRL_BIT;
+ __raw_writel(ctrl, reg);
+ bank-context.ctrl = ctrl;
+ }
+}
+
+static void _disable_gpio_module(struct gpio_bank *bank, unsigned offset)
+{
+ void __iomem *base = bank-base;
+
+ if (bank-regs-wkup_en
+ !LINE_USED(bank-mod_usage, offset)
+ !LINE_USED(bank-irq_usage, offset)) {
+ /* Disable wake-up during idle for dynamic tick */
+ _gpio_rmw(base, bank-regs-wkup_en, 1 offset, 0);
+ bank-context.wake_en =
+ __raw_readl(bank-base + bank-regs-wkup_en);
+ }
+
+ if (bank-regs-ctrl !BANK_USED(bank)) {
+ void __iomem *reg = bank-base + bank-regs-ctrl;
+ u32 ctrl;
+
+ ctrl = __raw_readl(reg);
+ /* Module is disabled, clocks are gated */
+ ctrl |= GPIO_MOD_CTRL_BIT;
+ __raw_writel(ctrl, reg);
+ bank-context.ctrl = ctrl;
+ }
+}
+
static int gpio_is_input(struct gpio_bank *bank, int mask)
{
void __iomem *reg = bank-base + bank-regs-direction;
@@ -437,9 +483,10 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
unsigned gpio = 0;
int retval;
unsigned long flags;
+ unsigned offset;
- if (WARN_ON(!BANK_USED(bank)))
- return -EINVAL;
+ if (!BANK_USED(bank))
+ pm_runtime_get_sync(bank-dev);
#ifdef CONFIG_ARCH_OMAP1
if (d-irq IH_MPUIO_BASE)
@@ -457,7 +504,16 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
return -EINVAL;
spin_lock_irqsave(bank-lock, flags);
- retval = _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), type);
+ offset = GPIO_INDEX(bank, gpio);
+ retval = _set_gpio_triggering(bank, offset, type);
+ if (!LINE_USED(bank-mod_usage, offset)) {
+ _enable_gpio_module(bank, offset);
+ _set_gpio_direction(bank, offset, 1);
+ } else if (!gpio_is_input(bank, 1 offset)) {
+ spin_unlock_irqrestore(bank-lock, flags);
+ return -EINVAL;
+ }
+
bank-irq_usage |= 1 GPIO_INDEX(bank, gpio);
spin_unlock_irqrestore(bank-lock, flags);
@@ -620,30 +676,14 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(bank-lock, flags);
/* Set trigger to none. You need to enable the desired trigger with
-* request_irq() or set_irq_type().
+* request_irq() or set_irq_type(). Only do this if the IRQ line has
+* not already been requested.
*/
- _set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
-
- if (bank-regs-pinctrl) {
- void __iomem *reg = bank-base + bank-regs-pinctrl;
-
- /* Claim the pin for MPU */
- __raw_writel(__raw_readl(reg) | (1 offset), reg);
+ if (!LINE_USED(bank-irq_usage, offset)) {
+ _set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
+ _enable_gpio_module(bank, offset);
}
-
- if (bank
[PATCH 2/2] gpio/omap: auto-setup a GPIO when used as an IRQ
The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether an interrupt pin is also a GPIO or not,
the HW should be fully configured/enabled as an IRQ if a driver solely
uses IRQ APIs such as request_irq(), and never calls any GPIO-related
APIs. As such, add the missing HW setup to the OMAP GPIO controller's
irq_chip driver.
Since this bypasses the GPIO subsystem we have to ensure that another
driver won't be able to request the same GPIO pin that is used as an
IRQ and set its direction as output. Requesting the GPIO and setting
its direction as input is allowed though.
This fixes smsc911x ethernet support for tobi and igep OMAP3 boards
and OMAP4 SDP SPI based ethernet that use a GPIO as an interrupt line.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-omap.c | 129 ++-
1 file changed, 83 insertions(+), 46 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index a4fe038..89675f8 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -424,6 +424,52 @@ static int _set_gpio_triggering(struct gpio_bank *bank,
int gpio,
return 0;
}
+static void _enable_gpio_module(struct gpio_bank *bank, unsigned offset)
+{
+ if (bank-regs-pinctrl) {
+ void __iomem *reg = bank-base + bank-regs-pinctrl;
+
+ /* Claim the pin for MPU */
+ __raw_writel(__raw_readl(reg) | (1 offset), reg);
+ }
+
+ if (bank-regs-ctrl !BANK_USED(bank)) {
+ void __iomem *reg = bank-base + bank-regs-ctrl;
+ u32 ctrl;
+
+ ctrl = __raw_readl(reg);
+ /* Module is enabled, clocks are not gated */
+ ctrl = ~GPIO_MOD_CTRL_BIT;
+ __raw_writel(ctrl, reg);
+ bank-context.ctrl = ctrl;
+ }
+}
+
+static void _disable_gpio_module(struct gpio_bank *bank, unsigned offset)
+{
+ void __iomem *base = bank-base;
+
+ if (bank-regs-wkup_en
+ !LINE_USED(bank-mod_usage, offset)
+ !LINE_USED(bank-irq_usage, offset)) {
+ /* Disable wake-up during idle for dynamic tick */
+ _gpio_rmw(base, bank-regs-wkup_en, 1 offset, 0);
+ bank-context.wake_en =
+ __raw_readl(bank-base + bank-regs-wkup_en);
+ }
+
+ if (bank-regs-ctrl !BANK_USED(bank)) {
+ void __iomem *reg = bank-base + bank-regs-ctrl;
+ u32 ctrl;
+
+ ctrl = __raw_readl(reg);
+ /* Module is disabled, clocks are gated */
+ ctrl |= GPIO_MOD_CTRL_BIT;
+ __raw_writel(ctrl, reg);
+ bank-context.ctrl = ctrl;
+ }
+}
+
static int gpio_is_input(struct gpio_bank *bank, int mask)
{
void __iomem *reg = bank-base + bank-regs-direction;
@@ -437,9 +483,10 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
unsigned gpio = 0;
int retval;
unsigned long flags;
+ unsigned offset;
- if (WARN_ON(!BANK_USED(bank)))
- return -EINVAL;
+ if (!BANK_USED(bank))
+ pm_runtime_get_sync(bank-dev);
#ifdef CONFIG_ARCH_OMAP1
if (d-irq IH_MPUIO_BASE)
@@ -457,7 +504,16 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
return -EINVAL;
spin_lock_irqsave(bank-lock, flags);
- retval = _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), type);
+ offset = GPIO_INDEX(bank, gpio);
+ retval = _set_gpio_triggering(bank, offset, type);
+ if (!LINE_USED(bank-mod_usage, offset)) {
+ _enable_gpio_module(bank, offset);
+ _set_gpio_direction(bank, offset, 1);
+ } else if (!gpio_is_input(bank, 1 offset)) {
+ spin_unlock_irqrestore(bank-lock, flags);
+ return -EINVAL;
+ }
+
bank-irq_usage |= 1 GPIO_INDEX(bank, gpio);
spin_unlock_irqrestore(bank-lock, flags);
@@ -620,30 +676,14 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(bank-lock, flags);
/* Set trigger to none. You need to enable the desired trigger with
-* request_irq() or set_irq_type().
+* request_irq() or set_irq_type(). Only do this if the IRQ line has
+* not already been requested.
*/
- _set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
-
- if (bank-regs-pinctrl) {
- void __iomem *reg = bank-base + bank-regs-pinctrl;
-
- /* Claim the pin for MPU */
- __raw_writel(__raw_readl(reg) | (1 offset), reg);
+ if (!LINE_USED(bank-irq_usage, offset)) {
+ _set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
+ _enable_gpio_module(bank, offset);
}
-
- if (bank
Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ
On 09/27/2013 01:18 AM, Stephen Warren wrote: On 09/24/2013 01:58 AM, Javier Martinez Canillas wrote: The OMAP GPIO controller HW requires a pin to be configured in GPIO input mode in order to operate as an interrupt input. Since drivers should not be aware of whether an interrupt pin is also a GPIO or not, the HW should be fully configured/enabled as an IRQ if a driver solely uses IRQ APIs such as request_irq(), and never calls any GPIO-related APIs. As such, add the missing HW setup to the OMAP GPIO controller's irq_chip driver. Since this bypasses the GPIO subsystem we have to ensure that another caller won't be able to request the same GPIO pin that is used as an IRQ and set its direction as output. Requesting the GPIO and setting its direction as input is allowed though. FWIW, the concept of this patch, Acked-by: Stephen Warren swar...@nvidia.com I didn't review the code; just skimmed it to see where the new functionality was implemented. Thanks Stephen, I split the changes as suggested by Tony and posted as a patch-set and not an RFC anymore: [PATCH 1/2] gpio/omap: maintain GPIO and IRQ usage separately [1] [PATCH 2/2] gpio/omap: auto-setup a GPIO when used as an IRQ [2] Linus, Could you please add Stephen Acked-by when taking the patches and also George Cherian Tested-by that sent for this RFC. George it would be great if you can also comment on which OMAP platform you had tested. I cc'ed Aaro Koskinen and Paul Walmsley now which seems to have OMAP1 platforms to test. Could you please test [1] and [2] on a OMAP1 board? These patches solves a long standing issue we have on OMAP2+ when booting with DT and it would be great if you can check that it does not cause regressions on OMAP1 based boards. Thanks a lot and best regards, Javier [1]: https://patchwork.kernel.org/patch/2937351/ [2]: https://patchwork.kernel.org/patch/2937371/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] gpio/omap: maintain GPIO and IRQ usage separately
On 09/27/2013 08:08 PM, Kevin Hilman wrote: Javier Martinez Canillas javier.marti...@collabora.co.uk writes: The GPIO OMAP controller pins can be used as IRQ and GPIO independently so is necessary to keep track GPIO pins and IRQ lines usage separately to make sure that the bank will always be enabled while being used. Also move gpio_is_input() definition in preparation for the next patch that setups the controller's irq_chip driver when a caller requests an interrupt line. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk I'm fine with this appproach. For both patches: Reviewed-by: Kevin Hilman khil...@linaro.org Also, I gave it a spin across a handful of OMAP boards using v3.12-rc2 + these 2 patches. Boot tested successfully with DT boot: omap3530/beagle omap3730/beagle-xm omap3530/overo (Tobi w/GPIO IRQ networking) omap3730/overo STORM (w/GPIO IRQ for networking) am335x/beaglebone am335x/beaglebone black omap4430/panda omap4460/panda-es omap5912/OSK (omap1) I also verified non-DT boot on the OMAP3 platforms that still support legacy boot. So feel free to also add Tested-by: Kevin Hilman khil...@linaro.org Thanks for your persistence in getting a fix for this upstream. Kevin Thanks a lot Kevin for testing on so many boards. Linus, Since this patch-set doesn't cause any regression and fix a long standing issue on OMAP, do you think that it would be possible to include on the -rc series as a bugfix or do you prefer to wait until 3.13? Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] Add Maxim 77802 PMIC support
MAX77802 is a PMIC that contains 10 high efficiency Buck regulators, 32 Low-dropout (LDO) regulators, two 32kHz buffered clock outputs, a Real-Time-Clock (RTC) and a I2C interface to program the individual regulators, clocks and the RTC. This series are based on drivers added by Simon Glass to the Chrome OS kernel and adds support for the Maxim 77802 Power Management IC, their regulators, clocks, RTC and I2C interface. It is composed of patches: [PATCH 1/5] mfd: Add driver for Maxim 77802 Power Management IC [PATCH 2/5] regulator: Add driver for Maxim 77802 PMIC regulators [PATCH 3/5] clk: Add driver for Maxim 77802 PMIC clocks [PATCH 4/5] rtc: Add driver for Maxim 77802 PMIC Real-Time-Clock [PATCH 5/5] ARM: dts: Add max77802 device node for exynos5420-peach-pit Patches 1-4 add support for the different devices and Patch 5 enables the MAX77802 PMIC on the Exynos5420 based Peach pit board. Lee, Patches 2-4 depend on Patch 1 so I think that it makes sense if you take 1-4 through your mfd tree once the relevant maintainers ack the drivers added to the other subsystems (regulator, clk and rtc). Patch 5 can go through Kukjin tree since is just DTS changes. Thanks a lot and best regards, Javier -- 2.0.0.rc2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] regulator: Add driver for Maxim 77802 PMIC regulators
The MAX77802 PMIC has 10 high-efficiency Buck and 32 Low-dropout
(LDO) regulators. This patch adds support for all these regulators
found on the MAX77802 PMIC and is based on a driver added by Simon
Glass to the Chrome OS kernel 3.8 tree.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/regulator/Kconfig| 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/max77802.c | 678 +++
3 files changed, 688 insertions(+)
create mode 100644 drivers/regulator/max77802.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 789eb46..17873d3 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -377,6 +377,15 @@ config REGULATOR_MAX77693
and one current regulator 'CHARGER'. This is suitable for
Exynos-4x12 chips.
+config REGULATOR_MAX77802
+ tristate Maxim 77802 regulator
+ depends on MFD_MAX77802
+ help
+ This driver controls a Maxim 77802 regulator
+ via I2C bus. The provided regulator is suitable for
+ Exynos-5 chips to control various voltages. It includes
+ support for control of voltage and ramp speed.
+
config REGULATOR_MC13XXX_CORE
tristate
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index d461110..2aea4b6 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_REGULATOR_MAX8997) += max8997.o
obj-$(CONFIG_REGULATOR_MAX8998) += max8998.o
obj-$(CONFIG_REGULATOR_MAX77686) += max77686.o
obj-$(CONFIG_REGULATOR_MAX77693) += max77693.o
+obj-$(CONFIG_REGULATOR_MAX77802) += max77802.o
obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
obj-$(CONFIG_REGULATOR_MC13XXX_CORE) += mc13xxx-regulator-core.o
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
new file mode 100644
index 000..93e8f69
--- /dev/null
+++ b/drivers/regulator/max77802.c
@@ -0,0 +1,678 @@
+/*
+ * max77802.c - Regulator driver for the Maxim 77802
+ *
+ * Copyright (C) 2013-2014 Google, Inc
+ * Simon Glass s...@chromium.org
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ * Chiwoong Byun woong.b...@smasung.com
+ * Jonghwa Lee jonghwa3@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * This driver is based on max8997.c
+ */
+
+#include linux/kernel.h
+#include linux/bug.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/slab.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/regulator/of_regulator.h
+#include linux/mfd/max77802.h
+#include linux/mfd/max77802-private.h
+
+/* Default ramp delay in case it is not manually set */
+#define MAX77802_RAMP_DELAY10 /* uV/us */
+
+#define MAX77802_OPMODE_SHIFT_LDO 6
+#define MAX77802_OPMODE_BUCK234_SHIFT 4
+#define MAX77802_OPMODE_MASK 0x3
+
+#define MAX77802_VSEL_MASK 0x3F
+#define MAX77802_DVS_VSEL_MASK 0xFF
+
+#define MAX77802_RAMP_RATE_MASK_2BIT 0xC0
+#define MAX77802_RAMP_RATE_SHIFT_2BIT 6
+#define MAX77802_RAMP_RATE_MASK_4BIT 0xF0
+#define MAX77802_RAMP_RATE_SHIFT_4BIT 4
+
+/* LDO16, LDO22 and LDO31 are not available on MAX77802 */
+#define MAX77802_MAX_REGULATORS(MAX77802_REG_MAX - 3)
+
+/* MAX77802 has two register formats: 2-bit and 4-bit */
+static const unsigned int ramp_table_77802_2bit[] = {
+ 12500,
+ 25000,
+ 5,
+ 10,
+};
+
+static unsigned int ramp_table_77802_4bit[] = {
+ 1000, 2000, 3030, 4000,
+ 5000, 5880, 7140, 8330,
+ 9090, 1, 0, 12500,
+ 16670, 25000, 5, 10,
+};
+
+struct max77802_regulator_prv {
+ int num_regulators;
+ struct regulator_dev *rdev[MAX77802_MAX_REGULATORS];
+ unsigned int opmode[MAX77802_MAX_REGULATORS];
+};
+
+static int max77802_get_opmode_shift(int id)
+{
+ if (id = MAX77802_LDO1 id = MAX77802_LDO35)
+ return MAX77802_OPMODE_SHIFT_LDO;
+ else if (id == MAX77802_BUCK1 || (id = MAX77802_BUCK5
+ id = MAX77802_BUCK10))
+ return 0;
+ else if (id = MAX77802_BUCK2 id = MAX77802_BUCK4)
+ return MAX77802_OPMODE_BUCK234_SHIFT;
+ else
+ return -EINVAL;
+}
+
+/*
+ * Some BUCKS supports Normal[ON/OFF] mode during suspend
+ *
+ * BUCK 1, 6, 2-4, 5
[PATCH 4/5] rtc: Add driver for Maxim 77802 PMIC Real-Time-Clock
The MAX7802 PMIC has a Real-Time-Clock (RTC) with two alarms.
This patch adds support for the RTC and is based on a driver
added by Simon Glass to the Chrome OS kernel 3.8 tree.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/mfd/max77802.c | 3 +
drivers/rtc/Kconfig| 10 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-max77802.c | 632 +
4 files changed, 646 insertions(+)
create mode 100644 drivers/rtc/rtc-max77802.c
diff --git a/drivers/mfd/max77802.c b/drivers/mfd/max77802.c
index 33e8023..62127fb 100644
--- a/drivers/mfd/max77802.c
+++ b/drivers/mfd/max77802.c
@@ -35,6 +35,9 @@
static const struct mfd_cell max77802_devs[] = {
{ .name = max77802-pmic, },
+#if defined(CONFIG_RTC_DRV_MAX77802)
+ { .name = max77802-rtc, },
+#endif
#if defined(CONFIG_COMMON_CLK_MAX77802)
{ .name = max77802-clk, },
#endif
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 0754f5c..e0b6495 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -288,6 +288,16 @@ config RTC_DRV_MAX77686
This driver can also be built as a module. If so, the module
will be called rtc-max77686.
+config RTC_DRV_MAX77802
+ tristate Maxim MAX77802
+ depends on MFD_MAX77802
+ help
+ If you say yes here you will get support for the
+ RTC of Maxim MAX77802 PMIC.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-max77802.
+
config RTC_DRV_RS5C372
tristate Ricoh R2025S/D, RS5C372A/B, RV5C386, RV5C387A
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 70347d0..247de78 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_RTC_DRV_MAX8998) += rtc-max8998.o
obj-$(CONFIG_RTC_DRV_MAX8997) += rtc-max8997.o
obj-$(CONFIG_RTC_DRV_MAX6902) += rtc-max6902.o
obj-$(CONFIG_RTC_DRV_MAX77686) += rtc-max77686.o
+obj-$(CONFIG_RTC_DRV_MAX77802) += rtc-max77802.o
obj-$(CONFIG_RTC_DRV_MC13XXX) += rtc-mc13xxx.o
obj-$(CONFIG_RTC_DRV_MCP795) += rtc-mcp795.o
obj-$(CONFIG_RTC_DRV_MSM6242) += rtc-msm6242.o
diff --git a/drivers/rtc/rtc-max77802.c b/drivers/rtc/rtc-max77802.c
new file mode 100644
index 000..cb85b1d
--- /dev/null
+++ b/drivers/rtc/rtc-max77802.c
@@ -0,0 +1,632 @@
+/*
+ * RTC driver for Maxim MAX77802
+ *
+ * Copyright (C) 2013 Google, Inc
+ *
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ *
+ * based on rtc-max8997.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include linux/slab.h
+#include linux/rtc.h
+#include linux/delay.h
+#include linux/mutex.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/mfd/max77802-private.h
+#include linux/irqdomain.h
+#include linux/regmap.h
+
+/* RTC Control Register */
+#define BCD_EN_SHIFT 0
+#define BCD_EN_MASK(1 BCD_EN_SHIFT)
+#define MODEL24_SHIFT 1
+#define MODEL24_MASK (1 MODEL24_SHIFT)
+/* RTC Update Register1 */
+#define RTC_UDR_SHIFT 0
+#define RTC_UDR_MASK (1 RTC_UDR_SHIFT)
+#define RTC_RBUDR_SHIFT4
+#define RTC_RBUDR_MASK (1 RTC_RBUDR_SHIFT)
+/* WTSR and SMPL Register */
+#define WTSRT_SHIFT0
+#define SMPLT_SHIFT2
+#define WTSR_EN_SHIFT 6
+#define SMPL_EN_SHIFT 7
+#define WTSRT_MASK (3 WTSRT_SHIFT)
+#define SMPLT_MASK (3 SMPLT_SHIFT)
+#define WTSR_EN_MASK (1 WTSR_EN_SHIFT)
+#define SMPL_EN_MASK (1 SMPL_EN_SHIFT)
+/* RTC Hour register */
+#define HOUR_PM_SHIFT 6
+#define HOUR_PM_MASK (1 HOUR_PM_SHIFT)
+/* RTC Alarm Enable */
+#define ALARM_ENABLE_SHIFT 7
+#define ALARM_ENABLE_MASK (1 ALARM_ENABLE_SHIFT)
+
+/* For the RTCAE1 register, we write this value to enable the alarm */
+#define ALARM_ENABLE_VALUE 0x77
+
+#define MAX77802_RTC_UPDATE_DELAY_US 200
+#undef MAX77802_RTC_WTSR_SMPL
+
+enum {
+ RTC_SEC = 0,
+ RTC_MIN,
+ RTC_HOUR,
+ RTC_WEEKDAY,
+ RTC_MONTH,
+ RTC_YEAR,
+ RTC_DATE,
+ RTC_NR_TIME
+};
+
+struct max77802_rtc_info {
+ struct device *dev;
+ struct max77802_dev *max77802;
+ struct i2c_client *rtc;
+ struct rtc_device *rtc_dev;
+ struct mutexlock;
+
+ struct regmap *regmap;
+
+ int virq;
+ int rtc_24hr_mode;
+};
+
+enum MAX77802_RTC_OP {
+ MAX77802_RTC_WRITE,
+ MAX77802_RTC_READ
[PATCH 5/5] ARM: dts: Add max77802 device node for exynos5420-peach-pit
Peach pit board uses a Maxim 77802 Power Management IC to
drive regulators and its Real Time Clock. This patch adds
support for this chip.
These are the device nodes and pinctrl configuration that
is present on the Peach pit DeviceTree source file in the
the Chrome OS kernel 3.8 tree.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 320 +
1 file changed, 320 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 1c5b8f9..cb7d720 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -111,6 +111,13 @@
samsung,pin-drv = 0;
};
+ max77802_irq: max77802-irq {
+ samsung,pins = gpx3-1;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
hdmi_hpd_irq: hdmi-hpd-irq {
samsung,pins = gpx3-7;
samsung,pin-function = 0;
@@ -124,6 +131,29 @@
samsung,pin-pud = 3;
samsung,pin-drv = 0;
};
+
+ pmic_dvs_1: pmic-dvs-1 {
+ samsung,pins = gpy7-6;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+};
+
+pinctrl_2 {
+ pmic_dvs_2: pmic-dvs-2 {
+ samsung,pins = gpj4-2;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ pmic_dvs_3: pmic-dvs-3 {
+ samsung,pins = gpj4-3;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
};
pinctrl_3 {
@@ -140,6 +170,14 @@
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
+
+ pmic_selb: pmic-selb {
+ samsung,pins = gph0-2, gph0-3, gph0-4, gph0-5,
+ gph0-6;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
};
rtc {
@@ -189,6 +227,288 @@
};
};
+hsi2c_4 {
+ status = okay;
+ clock-frequency = 40;
+
+ max77802-pmic@9 {
+ compatible = maxim,max77802;
+ interrupt-parent = gpx3;
+ interrupts = 1 0;
+ pinctrl-names = default;
+ pinctrl-0 = max77802_irq, pmic_selb,
+ pmic_dvs_1, pmic_dvs_2, pmic_dvs_3;
+ wakeup-source;
+ reg = 0x9;
+ #clock-cells = 1;
+
+ /* Using idx 1 means warm reset will get good voltage */
+ max77802,pmic-buck-default-dvs-idx = 1;
+ max77802,pmic-buck-dvs-gpios = gpy7 6 0,
+ gpj4 2 0,
+ gpj4 3 0;
+ max77802,pmic-buck-selb-gpios = gph0 2 0,
+ gph0 3 0,
+ gph0 4 0,
+ gph0 5 0,
+ gph0 6 0;
+
+ voltage-regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = vdd_1v0;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ regulator-always-on;
+ };
+ ldo2_reg: LDO2 {
+ regulator-name = vdd_1v2_2;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ };
+ ldo3_reg: LDO3 {
+ regulator-name = vdd_1v8_3;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ };
+ vqmmc_sdcard: ldo4_reg: LDO4 {
+ regulator-name = vdd_sd;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ };
+ ldo5_reg: LDO5 {
+ regulator-name = vdd_1v8_5;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ };
+ ldo6_reg: LDO6 {
+ regulator-name = vdd_1v8_6
[PATCH 3/5] clk: Add driver for Maxim 77802 PMIC clocks
The MAX77802 PMIC has two 32.768kHz Buffered Clock Outputs with
Low Jitter Mode. This patch adds support for these two clocks.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
.../devicetree/bindings/clock/maxim,max77802.txt | 40
drivers/clk/Kconfig| 6 +
drivers/clk/Makefile | 1 +
drivers/clk/clk-max77802.c | 253 +
drivers/mfd/max77802.c | 3 +
include/dt-bindings/clock/maxim,max77802.h | 22 ++
6 files changed, 325 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/maxim,max77802.txt
create mode 100644 drivers/clk/clk-max77802.c
create mode 100644 include/dt-bindings/clock/maxim,max77802.h
diff --git a/Documentation/devicetree/bindings/clock/maxim,max77802.txt
b/Documentation/devicetree/bindings/clock/maxim,max77802.txt
new file mode 100644
index 000..1d3fb64
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/maxim,max77802.txt
@@ -0,0 +1,40 @@
+Binding for Maxim MAX77802 32k clock generator block
+
+This is a part of device tree bindings of MAX77802 multi-function device.
+More information can be found in bindings/mfd/max77802.txt file.
+
+The MAX77802 contains two 32.768khz clock outputs that can be controlled
+(gated/ungated) over I2C.
+
+Following properties should be presend in main device node of the MFD chip.
+
+Required properties:
+
+- #clock-cells: from common clock binding; shall be set to 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
+
+Clocks are defined as preprocessor macros in dt-bindings/clock/maxim,max77802.h
+header and can be used in device tree sources.
+
+Example: Node of the MFD chip
+
+ max77802: max77802@09 {
+ compatible = maxim,max77802;
+ interrupt-parent = wakeup_eint;
+ interrupts = 26 0;
+ reg = 0x09;
+ #clock-cells = 1;
+
+ /* ... */
+ };
+
+Example: Clock consumer node
+
+ foo@0 {
+ compatible = bar,foo;
+ /* ... */
+ clock-names = 32khz_ap;
+ clocks = max77802 MAX77802_CLK_32K_AP;
+ };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 9f9c5ae..74c71a4 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -38,6 +38,12 @@ config COMMON_CLK_MAX77686
---help---
This driver supports Maxim 77686 crystal oscillator clock.
+config COMMON_CLK_MAX77802
+ tristate Clock driver for Maxim 77802 MFD
+ depends on MFD_MAX77802
+ ---help---
+ This driver supports Maxim 77802 crystal oscillator clock.
+
config COMMON_CLK_SI5351
tristate Clock driver for SiLabs 5351A/B/C
depends on I2C
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 567f102..677692f 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_ARCH_EFM32) += clk-efm32gg.o
obj-$(CONFIG_ARCH_HIGHBANK)+= clk-highbank.o
obj-$(CONFIG_MACH_LOONGSON1) += clk-ls1x.o
obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
+obj-$(CONFIG_COMMON_CLK_MAX77802) += clk-max77802.o
obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
diff --git a/drivers/clk/clk-max77802.c b/drivers/clk/clk-max77802.c
new file mode 100644
index 000..a98fc29
--- /dev/null
+++ b/drivers/clk/clk-max77802.c
@@ -0,0 +1,253 @@
+/*
+ * clk-max77802.c - Clock driver for Maxim 77802
+ *
+ * Copyright (C) 2014 Google, Inc
+ *
+ * Copyright (C) 2012 Samsung Electornics
+ * Jonghwa Lee jonghwa3@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * This driver is based on clk-max77686.c
+ */
+
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/mfd/max77802.h
+#include linux/mfd/max77802-private.h
+#include linux/clk-provider.h
+#include linux/mutex.h
+#include linux/clkdev.h
+
+#include dt-bindings/clock/maxim,max77802.h
+
+#define MAX77802_CLOCK_OPMODE_MASK 0x1
+#define MAX77802_CLOCK_LOW_JITTER_SHIFT 0x3
+
+struct max77802_clk {
+ struct max77802_dev *iodev;
+ u32 mask;
+ struct clk_hw hw;
+ struct clk_lookup *lookup;
+};
+
+static struct
[PATCH 1/5] mfd: Add driver for Maxim 77802 Power Management IC
Maxim MAX77802 is a power management chip that contains 10 high
efficiency Buck regulators, 32 Low-dropout (LDO) regulators used
to power up application processors and peripherals, a 2-channel
32kHz clock outputs, a Real-Time-Clock (RTC) and a I2C interface
to program the individual regulators, clocks outputs and the RTC.
This patch adds the core support for MAX77802 PMIC and is based
on a driver added by Simon Glass to the Chrome OS kernel 3.8 tree.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Documentation/devicetree/bindings/mfd/max77802.txt | 88 ++
drivers/mfd/Kconfig| 13 +
drivers/mfd/Makefile | 1 +
drivers/mfd/max77802-irq.c | 332 +
drivers/mfd/max77802.c | 282 +
include/linux/mfd/max77802-private.h | 291 ++
include/linux/mfd/max77802.h | 124
7 files changed, 1131 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt
create mode 100644 drivers/mfd/max77802-irq.c
create mode 100644 drivers/mfd/max77802.c
create mode 100644 include/linux/mfd/max77802-private.h
create mode 100644 include/linux/mfd/max77802.h
diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt
b/Documentation/devicetree/bindings/mfd/max77802.txt
new file mode 100644
index 000..addf02e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77802.txt
@@ -0,0 +1,88 @@
+Maxim MAX77802 multi-function device
+
+MAX77802 is a Mulitifunction device with PMIC, RTC and Charger on chip. It is
+interfaced to host controller using i2c interface. PMIC, Charger and RTC
+submodules are addressed using same i2c slave address
+
+This document describes the binding for mfd device and PMIC submodule.
+
+Binding for the built-in 32k clock generator block is defined separately
+in bindings/clk/maxim,max77802.txt file.
+
+Required properties:
+- compatible : Must be maxim,max77802;
+- reg : Specifies the i2c slave address of PMIC block.
+- interrupts : This i2c device has an IRQ line connected to the main SoC.
+- interrupt-parent : The parent interrupt controller.
+
+Optional properties:
+- max77802,pmic-buck-default-dvs-idx: We'll always write this DVS index in the
+ PMIC for BUCKs with DVS (Bucks 1-4, 6).
+ NOTE: at the moment these bindings don't include enough details for actual
+ GPIO-DVS--this just lets you choose which single slot to use.
+
+- max77802,pmic-buck-dvs-gpios: The DVS GPIOs. We'll try to set these GPIOs
+ to match pmic-buck-default-dvs-idx at probe time if they are defined. If
+ some or all of these GPIOs are not defined it's assumed that the board has
+ any missing GPIOs hardwired to match pmic-buck-default-dvs-idx.
+
+- max77802,pmic-buck-selb-gpios: GPIOs to enable DVS-GPIO for BUCKs.
+ Should be five values: 1, 2, 3, 4, 6. It is strongly suggested to include
+ these GPIOs if there's any chance that changing DVS GPIOs one line at a
+ time might glitch your DVS values.
+
+Optional node:
+- voltage-regulators : The regulators of max77802 have to be instantiated
+ under subnode named voltage-regulators using the following format.
+
+ regulator_name {
+ regulator-compatible = LDOn/BUCKn
+ standard regulator constraints
+ };
+ refer Documentation/devicetree/bindings/regulator/regulator.txt
+
+ The regulator-compatible property of regulator should initialized with string
+to get matched with their hardware counterparts as follow:
+
+ -LDOn : for LDOs, where n can lie in range 1 to 35.
+ example: LDO1, LDO2, LDO35.
+ -BUCKn : for BUCKs, where n can lie in range 1 to 10.
+ example: BUCK1, BUCK5, BUCK10.
+Example:
+
+ max77802@09 {
+ compatible = maxim,max77802;
+ interrupt-parent = wakeup_eint;
+ interrupts = 26 0;
+ reg = 0x09;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ max77802,pmic-buck-default-dvs-idx = 1;
+ max77802,pmic-buck-dvs-gpios = gpy7 6 0,
+ gpj4 2 0,
+ gpj4 3 0;
+ max77802,pmic-buck-selb-gpios = gph0 2 0,
+ gph0 3 0,
+ gph0 4 0,
+ gph0 5 0,
+ gph0 6 0;
+
+ voltage-regulators {
+ ldo11_reg {
+ regulator-compatible = LDO11;
+ regulator-name = vdd_ldo11;
+ regulator-min-microvolt = 190;
+ regulator-max-microvolt = 190
Re: [PATCH 0/5] Add Maxim 77802 PMIC support
Hello Krzystof, Thanks a lot for your feedback. On 06/09/2014 06:04 PM, Doug Anderson wrote: Krzystof, On Mon, Jun 9, 2014 at 3:16 AM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On pon, 2014-06-09 at 11:37 +0200, Javier Martinez Canillas wrote: MAX77802 is a PMIC that contains 10 high efficiency Buck regulators, 32 Low-dropout (LDO) regulators, two 32kHz buffered clock outputs, a Real-Time-Clock (RTC) and a I2C interface to program the individual regulators, clocks and the RTC. This series are based on drivers added by Simon Glass to the Chrome OS kernel and adds support for the Maxim 77802 Power Management IC, their regulators, clocks, RTC and I2C interface. It is composed of patches: [PATCH 1/5] mfd: Add driver for Maxim 77802 Power Management IC [PATCH 2/5] regulator: Add driver for Maxim 77802 PMIC regulators [PATCH 3/5] clk: Add driver for Maxim 77802 PMIC clocks [PATCH 4/5] rtc: Add driver for Maxim 77802 PMIC Real-Time-Clock [PATCH 5/5] ARM: dts: Add max77802 device node for exynos5420-peach-pit Patches 1-4 add support for the different devices and Patch 5 enables the MAX77802 PMIC on the Exynos5420 based Peach pit board. Hi, The main mfd, mfd irq, clk and rtc drivers look very similar to max77686 drivers. I haven't checked other Maxim drivers but I think there will be a lot of similarities with them also. It is almost common for Maxim chipsets to share components between each other. I think there is no need in duplicating all that stuff once again in new driver for another Maxim-almost-the-same-as-others-XYZ chipset. Just merge it with max77686 (or other better candidate). The only difference is in regulator driver. I am not sure whether this is a result of differences in chip or differences in driver design. Yes, we thought the same thing when we added support for the max77802 in the ChromeOS tree. Unfortunately it didn't work out half as well as we thought it would. When Javier was asking advice about sending things upstream we suggested that perhaps he should split the two up. You can see the result of the combined driver the ChromeOS tree (the code there is older, probably misnamed as max77xxx, and doesn't have the proper clock pieces, but you can get the gist): https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/regulator/max77xxx-regulator.c https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/rtc/rtc-max77xxx.c Specific problems that made it ugly to have a combined driver: * The RTC has many subtle differences between the 77686 and 77802. They expanded it to handle a 200 year timeframe instead of 100 and that meant that they had to shuffle the bits around everywhere. They also moved it to have the same i2c address as the main PMIC so all addresses are different (see max77686_map in the RTC link above). * The regulator itself has similar concepts between the two, but the list of bucks / ldos and how they behave is quite different. Trying to understand the complex tables in https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/regulator/max77xxx-regulator.c was not easy. There are other differences that were not mentioned: - The max77802 uses a single register to enable RTC alarm while max77686 uses 1 bit from a set of registers. - Each chip has some regulators that are not available and you have to take care of those exceptions (e.g: LDO16, LDO22 and LD31 on max77802). - The max77802 has 2 clocks outputs while the max77686 has three. So, as Doug said there are many differences on these two chips besides the regulators. It's true that these two drivers share a lot of the structure and there is code duplication (this applies to most maxim drivers btw) but I have my doubts that the combined approach will make the code more easy to maintain. The biggest problem is the i2c addresses space being different so you need an indirection level to access registers and have duplicated registers definition for each chip. If we really need to write a single driver it certainly can be done, but please look at the above to be sure this is what you want. Yes, if the combined driver is preferred over having a separate driver for max77802 then I will try to find the more elegant way to merge both drivers. But I tried to do it already and I can't say I liked the end result more than having two separate drivers. NOTE: it's possible that things could be more sane with more driver redesign, possibly making things more data driven. The thing that would be really nice to do would be to avoid all of the crazy regulator_zzz_desc_zzz macros, maybe? I'd have to actually try doing it to be sure it's cleaner, though... Another option is to use an hybrid approach. Merge the mfd core, irq and clk drivers but have different platform drivers for rtc and regulators. Still the end result is not great imho but better
Re: [PATCH 1/5] mfd: Add driver for Maxim 77802 Power Management IC
Hello Krzysztof,
On 06/09/2014 12:22 PM, Krzysztof Kozlowski wrote:
On pon, 2014-06-09 at 11:37 +0200, Javier Martinez Canillas wrote:
Maxim MAX77802 is a power management chip that contains 10 high
efficiency Buck regulators, 32 Low-dropout (LDO) regulators used
to power up application processors and peripherals, a 2-channel
32kHz clock outputs, a Real-Time-Clock (RTC) and a I2C interface
to program the individual regulators, clocks outputs and the RTC.
This patch adds the core support for MAX77802 PMIC and is based
on a driver added by Simon Glass to the Chrome OS kernel 3.8 tree.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
(...)
diff --git a/drivers/mfd/max77802-irq.c b/drivers/mfd/max77802-irq.c
new file mode 100644
index 000..38a8ce7
--- /dev/null
+++ b/drivers/mfd/max77802-irq.c
@@ -0,0 +1,332 @@
+/*
+ * max77802-irq.c - Interrupt controller support for MAX77802
+ *
+ * Copyright (C) 2013-2014 Google, Inc
+ *
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * Chiwoong Byun woong.b...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * This driver is based on max8997-irq.c
+ */
+
+#include linux/err.h
+#include linux/irq.h
+#include linux/interrupt.h
+#include linux/gpio.h
+#include linux/mfd/max77802.h
+#include linux/mfd/max77802-private.h
+#include linux/irqdomain.h
+#include linux/regmap.h
+
+enum {
+MAX77802_DEBUG_IRQ_INFO = 1 0,
+MAX77802_DEBUG_IRQ_MASK = 1 1,
+MAX77802_DEBUG_IRQ_INT = 1 2,
+};
+
+static int debug_mask = 0;
+module_param(debug_mask, int, 0);
+MODULE_PARM_DESC(debug_mask, Set debug_mask : 0x0=off 0x1=IRQ_INFO
0x2=IRQ_MASK 0x4=IRQ_INI));
+
+static const u8 max77802_mask_reg[] = {
+[PMIC_INT1] = MAX77802_REG_INT1MSK,
+[PMIC_INT2] = MAX77802_REG_INT2MSK,
+[RTC_INT] = MAX77802_RTC_INTM,
+};
+
+struct max77802_irq_data {
+int mask;
+enum max77802_irq_source group;
+};
+
+#define DECLARE_IRQ(idx, _group, _mask) \
+[(idx)] = { .group = (_group), .mask = (_mask) }
+static const struct max77802_irq_data max77802_irqs[] = {
+DECLARE_IRQ(MAX77802_PMICIRQ_PWRONF,PMIC_INT1, 1 0),
+DECLARE_IRQ(MAX77802_PMICIRQ_PWRONR,PMIC_INT1, 1 1),
+DECLARE_IRQ(MAX77802_PMICIRQ_JIGONBF, PMIC_INT1, 1 2),
+DECLARE_IRQ(MAX77802_PMICIRQ_JIGONBR, PMIC_INT1, 1 3),
+DECLARE_IRQ(MAX77802_PMICIRQ_ACOKBF,PMIC_INT1, 1 4),
+DECLARE_IRQ(MAX77802_PMICIRQ_ACOKBR,PMIC_INT1, 1 5),
+DECLARE_IRQ(MAX77802_PMICIRQ_ONKEY1S, PMIC_INT1, 1 6),
+DECLARE_IRQ(MAX77802_PMICIRQ_MRSTB, PMIC_INT1, 1 7),
+DECLARE_IRQ(MAX77802_PMICIRQ_140C, PMIC_INT2, 1 0),
+DECLARE_IRQ(MAX77802_PMICIRQ_120C, PMIC_INT2, 1 1),
+DECLARE_IRQ(MAX77802_RTCIRQ_RTC60S, RTC_INT, 1 0),
+DECLARE_IRQ(MAX77802_RTCIRQ_RTCA1, RTC_INT, 1 1),
+DECLARE_IRQ(MAX77802_RTCIRQ_RTCA2, RTC_INT, 1 2),
+DECLARE_IRQ(MAX77802_RTCIRQ_SMPL, RTC_INT, 1 3),
+DECLARE_IRQ(MAX77802_RTCIRQ_RTC1S, RTC_INT, 1 4),
+DECLARE_IRQ(MAX77802_RTCIRQ_WTSR, RTC_INT, 1 5),
+};
Why just not use two regmap_irq_chips (for PMIC and RTC blocks)
replacing whole max77802-irq.c file?
Great, I was not aware about regmap_irq_chip. I'll take a look to it for v2.
Best regards,
Krzysztof
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] regulator: Add driver for Maxim 77802 PMIC regulators
Hello Mark,
Thanks a lot for your feedback.
On 06/09/2014 09:38 PM, Mark Brown wrote:
On Mon, Jun 09, 2014 at 11:37:47AM +0200, Javier Martinez Canillas wrote:
+case REGULATOR_MODE_STANDBY:/* switch off */
+if (id != MAX77802_LDO1 id != MAX77802_LDO20
+id != MAX77802_LDO21 id != MAX77802_LDO3) {
+val = MAX77802_OPMODE_STANDBY;
+break;
+}
+/* no break */
This sounds very broken...
The problem is that not all regulators supports the same operational modes. For
instance regulators LDO 1, 20, 21 and 3 does not support REGULATOR_MODE_STANDBY
so if the condition is not met a break is not needed since the default case is
to warn that the mode is not supported.
But I'll rework that logic on v2 to make it cleaner and have a break on each
case and don't rely on case cascading.
+/* OK if some GPIOs aren't defined */
+if (!gpio_is_valid(gpio))
+continue;
+
+/* If a GPIO is valid, we'd better be able to claim it */
+ret = devm_gpio_request_one(dev, gpio, GPIOF_OUT_INIT_HIGH,
+max77802 selb);
+if (ret) {
+dev_err(dev, can't claim gpio[%d]: %d\n, i, ret);
+return ret;
+}
Can this use the GPIO descriptor API?
Ok, I'll use gpiod_request() on v2.
+static void max77802_copy_reg(struct device *dev, struct regmap *regmap,
+ int from_reg, int to_reg)
+{
+int val;
+int ret;
+
+if (from_reg == to_reg)
+return;
+
+ret = regmap_read(regmap, from_reg, val);
+if (!ret)
+ret = regmap_write(regmap, to_reg, val);
+
+if (ret)
+dev_warn(dev, Copy err %d = %d (%d)\n,
+ from_reg, to_reg, ret);
+}
This doesn't look at all device specific, better implement it in generic
code.
Ok, will do.
+if (pdata-num_regulators != MAX77802_MAX_REGULATORS) {
+dev_err(pdev-dev,
+Invalid initial data for regulator's initialiation: \
+expected %d, pdata/dt provided %d\n,
+MAX77802_MAX_REGULATORS,
+pdata-num_regulators);
+return -EINVAL;
+}
Don't split log messages over multiple lines so people can find the log
message in the kernel source with grep, though in any case checking for
this is a bug - the driver should always be at least able to read the
current state from the hardware.
Ok.
+static int __init max77802_pmic_init(void)
+{
+return platform_driver_register(max77802_pmic_driver);
+}
+subsys_initcall(max77802_pmic_init);
module_platform_driver().
Ok.
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] mfd: Add driver for Maxim 77802 Power Management IC
Hello Mark,
On 06/09/2014 09:47 PM, Mark Brown wrote:
On Mon, Jun 09, 2014 at 11:37:46AM +0200, Javier Martinez Canillas wrote:
+Optional node:
+- voltage-regulators : The regulators of max77802 have to be instantiated
+ under subnode named voltage-regulators using the following format.
Every other PMIC calls this node regulators...
Ok, I'll change for consistency.
+regulator_name {
+regulator-compatible = LDOn/BUCKn
regulator-compatible is deprecated, use the node name instead.
Ok.
+config MFD_MAX77802
+bool Maxim Integrated MAX77802 PMIC Support
Why is this bool and not tristate?
I noticed that the majority of the mfd PMIC drivers were bool and not tristate
so I thought it was a convention. But nothing prevents this driver to be built
as a module so I'll change it to tristate.
+int max77802_irq_resume(struct max77802_dev *max77802)
+{
+/*
+ * The IRQ that woke us up may still need to be ACK'ed on resume.
+ * If it isn't ever ACK'ed, future IRQs may not be delivered.
+ */
+if (max77802-irq)
+max77802_irq_thread(0, max77802);
+
+return 0;
+}
As covered in another subthread all this code looks like it should be
regmap-irq.
It seems so, I'll take that into account for v2.
+if (regmap_read(max77802-regmap,
+ MAX77802_REG_DEVICE_ID, data) 0) {
+dev_err(max77802-dev,
+device not found on this channel (this is not an
error)\n);
+return -ENODEV;
If this is not an error why is it printed as dev_err()? It does look
like an error to me, though.
Yeah, it is an error so I'll clean that message.
+} else {
+dev_info(max77802-dev, device found\n);
+}
These sort of prints are just noise, remove this unless there is some
revision information you can display. It's also better practice to
check that the device ID is actually what was expected in case there was
an error in the DT.
Ok, will do.
+static const struct i2c_device_id max77802_i2c_id[] = {
+{ max77802, TYPE_MAX77802 },
+{ }
+};
+MODULE_DEVICE_TABLE(i2c, max77802_i2c_id);
We have type information here but not in the OF ID table (not that we
ever look at it).
Yeah, I'll remove the type information here. It is a left over when trying to
combine both max77802 and max77686 drivers since in a combined driver we need
the type information.
Thanks a lot for your feedback.
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Add Maxim 77802 PMIC support
Hello Krzysztof, On 10/06/2014, at 09:32, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On pon, 2014-06-09 at 09:04 -0700, Doug Anderson wrote: Krzystof, On Mon, Jun 9, 2014 at 3:16 AM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On pon, 2014-06-09 at 11:37 +0200, Javier Martinez Canillas wrote: MAX77802 is a PMIC that contains 10 high efficiency Buck regulators, 32 Low-dropout (LDO) regulators, two 32kHz buffered clock outputs, a Real-Time-Clock (RTC) and a I2C interface to program the individual regulators, clocks and the RTC. This series are based on drivers added by Simon Glass to the Chrome OS kernel and adds support for the Maxim 77802 Power Management IC, their regulators, clocks, RTC and I2C interface. It is composed of patches: [PATCH 1/5] mfd: Add driver for Maxim 77802 Power Management IC [PATCH 2/5] regulator: Add driver for Maxim 77802 PMIC regulators [PATCH 3/5] clk: Add driver for Maxim 77802 PMIC clocks [PATCH 4/5] rtc: Add driver for Maxim 77802 PMIC Real-Time-Clock [PATCH 5/5] ARM: dts: Add max77802 device node for exynos5420-peach-pit Patches 1-4 add support for the different devices and Patch 5 enables the MAX77802 PMIC on the Exynos5420 based Peach pit board. Hi, The main mfd, mfd irq, clk and rtc drivers look very similar to max77686 drivers. I haven't checked other Maxim drivers but I think there will be a lot of similarities with them also. It is almost common for Maxim chipsets to share components between each other. I think there is no need in duplicating all that stuff once again in new driver for another Maxim-almost-the-same-as-others-XYZ chipset. Just merge it with max77686 (or other better candidate). The only difference is in regulator driver. I am not sure whether this is a result of differences in chip or differences in driver design. Yes, we thought the same thing when we added support for the max77802 in the ChromeOS tree. Unfortunately it didn't work out half as well as we thought it would. When Javier was asking advice about sending things upstream we suggested that perhaps he should split the two up. You can see the result of the combined driver the ChromeOS tree (the code there is older, probably misnamed as max77xxx, and doesn't have the proper clock pieces, but you can get the gist): https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/regulator/max77xxx-regulator.c https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/rtc/rtc-max77xxx.c Specific problems that made it ugly to have a combined driver: * The RTC has many subtle differences between the 77686 and 77802. They expanded it to handle a 200 year timeframe instead of 100 and that meant that they had to shuffle the bits around everywhere. They also moved it to have the same i2c address as the main PMIC so all addresses are different (see max77686_map in the RTC link above). The difference in RTC registers seems the biggest but it can be solved in readable manner. I see other differences but there aren't many. It just hurts seeing so much code duplication: $ sed -e 's/max77686/max77802/g' -e 's/MAX77686/MAX77802/g' \ -i drivers/rtc/rtc-max77686.c $ diff -ubB drivers/rtc/rtc-max77686.c drivers/rtc/rtc-max77802.c The combined RTC driver from ChromeOS seems fine to me... but I do not insist. * The regulator itself has similar concepts between the two, but the list of bucks / ldos and how they behave is quite different. Trying to understand the complex tables in https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/regulator/max77xxx-regulator.c was not easy. If we really need to write a single driver it certainly can be done, but please look at the above to be sure this is what you want. Sure, I don't stick to the idea of one merged driver where this increases code size and complexity. I see your point that merging regulator drivers won't bring benefits but please: $ sed -e 's/max77686/max77802/g' -e 's/MAX77686/MAX77802/g' \ -i drivers/clk/clk-max77686.c $ diff -ubB drivers/clk/clk-max77686.c drivers/clk/clk-max77802.c I agree that there is too much duplicated code between those two and others Maxim PMIC drivers. I also agree that at some point we have to stop duplicating code and clean up all this. So, I think that instead of trying to make a single driver support two similar but different PMIC I can factor out the generic code in a max-core driver so the PMIC specific code is small and well contained. I'll work on that and post a v2. Thanks a lot for your feedback and best regards, Javier The difference in number of clocks (2 vs 3) is not an obstacle here. The same applies to main MFD driver and IRQ code. However MAX77686 doesn't use regmap_irq_chip so it needs changes before merging the IRQ code into one piece. Best regards, Krzysztof NOTE: it's possible
Re: [PATCH 00/36] OMAP: GPMC: Restructure and move OMAP GPMC driver out of mach-omap2
Hello Roger, What a great series!! On Wed, Jun 11, 2014 at 10:56 AM, Roger Quadros rog...@ti.com wrote: Hi, This is a complete functional set to get the gpmc driver out of mach-omap2 and into drivers/memory. The DT binding remains the same except for the following minor changes I probably won't have time to do a proper review until at least next week but doing a quick glance it looks very good to me. - compatible property is required for NAND OneNAND nodes This is a minor ABI breakage but I agree with you that it is wrong that these were not introduced in the first place and relied on the dev node so I think is not that bad to break it in this case. - Second register space and interrupts properties are required for NAND controller node - ti,onenand-sync-rw property added for OneNAND node. The series does the following changes - Move GPMC IRQ and NAND register handling to NAND driver. The entire GPMC register space is made available to the NAND driver. - Clean up NAND device tree handling. Don't rely on legacy platform device i.e. don't call gpmc_nand_init() - Add 2 public APIs omap_gpmc_retime() and omap_gpmc_get_clk_period() omap_gpmc_retime() allows to reconfigure the GPMC settings and timings for the specified Chip select region. omap_gpmc_get_clk_period() allows to query the GPMC_CLK (external clock) period, to perform timing calculations. Both functions will be needed by the OneNAND driver since it calculates device timings on the fly and needs to change from Asynchronous mode to Synchronous mode. - Setup OneNAND in Asynchronous mode by default and move Synchronous setting code into OneNAND driver. - Clean up OneNAND device tree handling. Don't rely on legacy platform device i.e. don't call gpmc_onenand_init() - Introduce gpmc_generic_init() that should be used by board files to specify GPMC chip select setting/timing and platform device within that Chip Select. - Stop using all gpmc*() that are meant to be private to GPMC driver. - Move GPMC driver into drivers/memory Tested on: - beagleboard C4: NAND - Nokia N900: OneNAND Do you have a tree somewhere that I can use it to test on the boards I maintain and post patches to update the DTS according the new binding? Changelog: [1] RFC patch - https://lkml.org/lkml/2014/5/21/218 cheers, -roger --- Roger Quadros (36): ARM: OMAP3: hwmod: Fix gpmc memory resource space ARM: dts: OMAP2+: Fix GPMC register space size ARM: OMAP2+: gpmc: Add platform data ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data mtd: nand: omap: Move IRQ handling from GPMC to NAND driver mtd: nand: omap: Move gpmc_update_nand_reg to nand driver mtd: nand: omap: Move NAND write protect code from GPMC to NAND driver mtd: nand: omap: Copy platform data parameters to omap_nand_info data mtd: nand: omap: Clean up device tree support ARM: dts: OMAP2+: Fix NAND device nodes mtd: nand: omap: Update DT binding documentation ARM: dts: omap3-beagle: Add NAND device ARM: OMAP2+: gpmc.c: sanity check bank-width DT property ARM: OMAP2+: gpmc: Allow drivers to reconfigure GPMC settings timings ARM: OMAP2+: gpmc: Allow drivers to query GPMC_CLK period mtd: onenand: omap: Remove regulator management code ARM: OMAP2+: gpmc-onenand: Use Async settings/timings by default ARM: OMAP2+: gpmc-onenand: Move Synchronous setting code to drivers/ mtd: onenand: omap: Use devres managed resources mtd: onenand: omap: Clean up device tree support ARM: dts: OMAP2+: Fix OneNAND device nodes ARM: OMAP2+: gmpc: add gpmc_generic_init() ARM: OMAP2+: gpmc: use platform data to configure CS space and poplulate device ARM: OMAP2+: gpmc: add NAND specific setup ARM: OMAP2+: gpmc: Support multiple Chip Selects per device ARM: OMAP2+: gpmc-smc91x: Get rid of retime() from omap_smc91x_platform_data ARM: OMAP2+: usb-tusb6010: Use omap_gpmc_retime() ARM: OMAP2+: nand: Update gpmc_nand_init() to use generic_gpmc_init() ARM: OMAP2+: gpmc-smc91x: Use gpmc_generic_init() ARM: OMAP2+: gpmc-smsc911x: Use gpmc_generic_init() ARM: OMAP2: usb-tusb6010: Use gpmc_generic_init() ARM: OMAP2+: onenand: Use gpmc_generic_init() ARM: OMAP2+: board-flash: Use gpmc_generic_init() for NOR ARM: OMAP2+: gpmc: Make externally unused functions/defines private ARM: OMAP2+: gpmc: move GPMC driver into drivers/memory ARM: OMAP2+: defconfig: Enable TI GPMC driver .../devicetree/bindings/mtd/gpmc-nand.txt | 16 +- .../devicetree/bindings/mtd/gpmc-onenand.txt |4 + arch/arm/boot/dts/am335x-evm.dts |8 +- arch/arm/boot/dts/am335x-igep0033.dtsi |8 +- arch/arm/boot/dts/am33xx.dtsi |2 +- arch/arm/boot/dts/am4372.dtsi |2 +- arch/arm/boot/dts/am43x-epos-evm.dts |8 +- arch/arm/boot/dts/omap2420-n8x0-common.dtsi
Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420
On Wed, Jun 11, 2014 at 7:32 AM, Tushar Behera tusha...@samsung.com wrote: Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux. As per the user manual, it should be CLK_MAU_EPLL. The problem surfaced when the bootloader in Peach-pit board set the EPLL clock as the parent of AUDSS mux. While booting the kernel, we used to get a system hang during late boot if CLK_MAU_EPLL was disabled. Signed-off-by: Tushar Behera tusha...@samsung.com Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com Reported-by: Kevin Hilman khil...@linaro.org --- arch/arm/boot/dts/exynos5420.dtsi |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi index e385322..79e9119 100644 --- a/arch/arm/boot/dts/exynos5420.dtsi +++ b/arch/arm/boot/dts/exynos5420.dtsi @@ -167,7 +167,7 @@ compatible = samsung,exynos5420-audss-clock; reg = 0x0381 0x0C; #clock-cells = 1; - clocks = clock CLK_FIN_PLL, clock CLK_FOUT_EPLL, + clocks = clock CLK_FIN_PLL, clock CLK_MAU_EPLL, clock CLK_SCLK_MAUDIO0, clock CLK_SCLK_MAUPCM0; clock-names = pll_ref, pll_in, sclk_audio, sclk_pcm_in; }; -- 1.7.9.5 -- Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled
On Wed, Jun 11, 2014 at 7:32 AM, Tushar Behera tusha...@samsung.com wrote:
When the output clock of AUDSS mux is disabled, we are getting kernel
oops while doing a clk_get() on other clocks provided by AUDSS. Though
user manual doesn't specify this dependency, we came across this issue
while disabling the parent of AUDSS mux clocks.
Keeping the parents of AUDSS mux always enabled fixes this issue.
Signed-off-by: Tushar Behera tusha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/clk/samsung/clk-exynos-audss.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos-audss.c
b/drivers/clk/samsung/clk-exynos-audss.c
index 13eae14c..1542f30 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -30,6 +30,8 @@ static struct clk **clk_table;
static void __iomem *reg_base;
static struct clk_onecell_data clk_data;
+static struct clk *pll_ref, *pll_in;
+
#define ASS_CLK_SRC 0x0
#define ASS_CLK_DIV 0x4
#define ASS_CLK_GATE 0x8
@@ -83,7 +85,7 @@ static int exynos_audss_clk_probe(struct platform_device
*pdev)
const char *mout_audss_p[] = {fin_pll, fout_epll};
const char *mout_i2s_p[] = {mout_audss, cdclk0, sclk_audio0};
const char *sclk_pcm_p = sclk_pcm0;
- struct clk *pll_ref, *pll_in, *cdclk, *sclk_audio, *sclk_pcm_in;
+ struct clk *cdclk, *sclk_audio, *sclk_pcm_in;
const struct of_device_id *match;
enum exynos_audss_clk_type variant;
@@ -113,10 +115,14 @@ static int exynos_audss_clk_probe(struct
platform_device *pdev)
pll_ref = devm_clk_get(pdev-dev, pll_ref);
pll_in = devm_clk_get(pdev-dev, pll_in);
- if (!IS_ERR(pll_ref))
+ if (!IS_ERR(pll_ref)) {
mout_audss_p[0] = __clk_get_name(pll_ref);
- if (!IS_ERR(pll_in))
+ clk_prepare_enable(pll_ref);
+ }
+ if (!IS_ERR(pll_in)) {
mout_audss_p[1] = __clk_get_name(pll_in);
+ clk_prepare_enable(pll_in);
+ }
clk_table[EXYNOS_MOUT_AUDSS] = clk_register_mux(NULL, mout_audss,
mout_audss_p, ARRAY_SIZE(mout_audss_p),
CLK_SET_RATE_NO_REPARENT,
@@ -217,6 +223,11 @@ static int exynos_audss_clk_remove(struct
platform_device *pdev)
clk_unregister(clk_table[i]);
}
+ if (!IS_ERR(pll_in))
+ clk_disable_unprepare(pll_in);
+ if (!IS_ERR(pll_ref))
+ clk_disable_unprepare(pll_ref);
+
return 0;
}
--
1.7.9.5
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal
Hello Roger,
On Thu, May 22, 2014 at 10:12 AM, Roger Quadros rog...@ti.com wrote:
Hi Ezequiel,
On 05/21/2014 07:08 PM, Ezequiel Garcia wrote:
Hi Roger,
On 21 May 02:20 PM, Roger Quadros wrote:
For DT boot:
- The GPMC controller node should have a chip select (CS) node for each used
chip select. The CS node must have a child device node for each device
attached to that chip select. Properties for that child are GPMC agnostic.
i.e.
gpmc {
cs0 {
nand0 {
}
};
cs1 {
nor0 {
}
}
...
};
While I agree that the GPMC driver is a bit messy, I'm not sure it's possible
to go through such a complete devicetree binding re-design (breaking
backwards
compatibility) now that the binding is already in production.
Why not? especially if the existing bindings are poorly dones. Is anyone
using these
bindings burning the DT into ROM and can't change it when they update the
kernel?
While I do agree that your DT bindings are much better than the
current ones, there is a policy that DT bindings are an external API
and once are released with a kernel are set in stone and can't be
changed.
The rationale here is that DT only describes hardware and since
hardware does not change, there is no need to change the DT on
subsequent kernel releases.
While that may be true in theory, in practice our understanding of the
hardware keeps evolving. It may be possible that the person adding
those binding didn't understand the hardware fully or did not have
access to all the documentation.
So given that the GPMC bindings are really awful maybe we can make an
exception here? I don't even know who should decide this, if Tony as
OMAP maintainer or the DT maintainers.
I wouldn't bother much about backward compatibility but just focus on not
breaking
functionality with all GPMC users while cleaning up the existing bindings.
AFAIK, TI's SDK 7.0 is released, with a v3.8.x kernel which uses this GPMC
binding. And then you have the ISEE board too, using this binding.
How does this prevent them from not using the new bindings when they update
the kernel?
In the particular case of ISEE boards, the vendor still ships a very
old kernel that uses board files and platform data so probably is not
an issue for mainline users to update their DTB but I see that there
are many users of the GPMC binding in mainline:
$ git grep gpmc[:@_a-zA-Z0-9]* { arch/arm/boot/dts/ | wc -l
36
Also, what's the problem with the current devicetree binding (not that I'm
fan
of it)?
Like Ezequiel said, I'm not a big fan of the current binding neither
but I don't know how safe is to break backward compatibility at this
point.
Best regards,
Javier
The existing binding uses this format
gpmc {
ranges cs-num 0 IO_partition_start IO_partition_size,
cs-num 0 IO_partition_start IO_partition_size,
...
node-name0 {
compatible = id for device on this chip select;
reg = cs-num IO_offset IO_size;
gpmc cs properties;
device specific properties;
};
node-name1 {
...
};
};
with requirements that
- chip select number (cs-num) is encoded in range id
- child's node-name is used to identify device type (NAND, Onenand, etc) and
driver expects that.
All this results in the following issues
- No way to define entire GPMC I/O map (typically 1st 1GB), without assigning
them to a Chip select. i.e. incomplete hardware description.
TI SoCs variants can have different GPMC I/O sizes, some can have 512MB
others can have 1GB. There needs to be a way to specify that.
- No clean way to specify GPMC register map for use by child nodes. NAND
controller which can be one of the children needs to use the GPMC register
map.
- Tricky to define multiple devices within a single chip select region.
- Uses node name to identify device type like nand and onenand. Doesn't use
compatible id for them.
- GPMC CS properties are mixed with device properties, resulting in
unnecessary binding documents like
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/net/gpmc-eth.txt
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
To solve these issues, I'm proposing the following format
gpmc {
ranges 0 0 IO_start IO_size/* entire GPMC I/O
space e.g. 1GB or 512MB */
1 0 Reg_start Reg_size;/* GPMC register
space */
cs0 {
ranges 0 0 IO_partition_start IO_partition_size;
/* CS0 IO partition e.g. 16MB */
Re: [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal
Hello Roger,
On Fri, May 23, 2014 at 10:16 AM, Roger Quadros rog...@ti.com wrote:
Ezequiel Javier,
On 05/22/2014 05:46 PM, Ezequiel Garcia wrote:
On 22 May 01:51 PM, Javier Martinez Canillas wrote:
On Thu, May 22, 2014 at 10:12 AM, Roger Quadros rog...@ti.com wrote:
On 21 May 02:20 PM, Roger Quadros wrote:
For DT boot:
- The GPMC controller node should have a chip select (CS) node for each
used
chip select. The CS node must have a child device node for each device
attached to that chip select. Properties for that child are GPMC
agnostic.
i.e.
gpmc {
cs0 {
nand0 {
}
};
cs1 {
nor0 {
}
}
...
};
While I agree that the GPMC driver is a bit messy, I'm not sure it's
possible
to go through such a complete devicetree binding re-design (breaking
backwards
compatibility) now that the binding is already in production.
Why not? especially if the existing bindings are poorly dones. Is anyone
using these
bindings burning the DT into ROM and can't change it when they update the
kernel?
While I do agree that your DT bindings are much better than the
current ones, there is a policy that DT bindings are an external API
and once are released with a kernel are set in stone and can't be
changed.
Exactly. The DT binding is considered an ABI. Thus, invariant across kernel
versions. Users can't be coherced into a DTB update after a kernel update.
That said, I don't really care if you break compatilibity in this case.
Rather, I'm suggesting that you make sure this change is going to be accepted
upstream, before doing any more work. The DT maintainers are reluctant to do
so.
Appreciate your concern.
Would be really nice if you can review patches 1-12. They have nothing to do
with DT changes.
Thanks.
Overall your patches looks good to me. But I think it's better to wait
until Tony removes the legacy board files for OMAP2+ since AFAIU at
least the following patches could be dropped or trimmed down when
board files are gone:
[RFC PATCH 04/16] ARM: OMAP2+: gpmc: use platform data to configure CS
space and poplulate
[RFC PATCH 06/16] ARM: OMAP2+: gpmc: add NAND specific setup
[RFC PATCH 07/16] ARM: OMAP2+: nand: Update gpmc_nand_init() to use
generic_gpmc_init()
Patches 1-3 and 5 are independent and can be applied in the meantime
as a preparation for further changes following board files removal.
I really like patches 9-12 since those moves some NAND add-hoc code to
the NAND driver where it really belongs. I think that similar changes
can be made for OneNAND and push the special case handling code from
GPMC driver to drivers/mtd/onenand/omap2.c.
Other devices (nor, ethernet, uart, etc) are already using
gpmc_probe_generic_child() so I hope we can isolate the NAND and
OneNAND specific changes and just use a single probe function for all
child devices and possibly get even need the enum gpmc_omap_type you
are adding on your struct gpmc_omap_cs_data.
So what do you think if as a first step we add the platform data as
you propose with all the commons timings and settings there, move all
the possible code to NAND and OneNAND drivers and try to use a single
configuration function for all child devices?
Then once board files are gone we can do further cleanup in the driver
and then we can discuss about changing the DT bindings. Maybe we can
even change it while keeping backwards compatibility? Although I'm not
sure about the last point I think that at least is worth to discuss
it.
cheers,
-roger
Thanks a lot and best regards,
Javier
On the other side, I guess you will also break bisectability while breaking
backward compatibility. Doesn't sound very nice.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: exynos5420: Keep aclk66_peric enabled during boot
Hello Doug,
On 05/29/2014 11:21 PM, Doug Anderson wrote:
Right now if you've got earlyprintk enabled on exynos5420-peach-pit
then you'll get a hang on boot. Here's why:
1. The i2c-s3c2410 driver will probe at subsys_initcall. It will
enable its clock and disable it. This is the clock i2c2.
2. The act of disabling i2c2 will disable its parents. In this case
the parent is aclk66_peric. There are no other children of
aclk66_peric officially enabled, so aclk66_peric will be turned
off (despite being CLK_IGNORE_UNUSED, but that's by design).
3. The next time you try to earlyprintk you'll do so without the UART
clock enabled. That's because the UART clocks are also children of
aclk66_peric. You'll hang.
There's no good place to put a clock enable for earlyprintk, which is
handled by a bunch of assembly code. The best we can do is to handle
this in the clock driver.
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/clk/samsung/clk-exynos5420.c | 24
1 file changed, 24 insertions(+)
I tested your patch and it solves the issue for me, so feel free to add
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Just one trivial comment below:
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 9d7d7ee..1e586be 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -1172,11 +1172,17 @@ static struct of_device_id ext_clk_match[] __initdata
= {
{ },
};
+/* Keep these clocks on until late_initcall */
+static const char *boot_clocks[] __initconst = {
+ aclk66_peric,
+};
+
/* register exynos5420 clocks */
static void __init exynos5x_clk_init(struct device_node *np,
enum exynos5x_soc soc)
{
struct samsung_clk_provider *ctx;
+ int i;
if (np) {
reg_base = of_iomap(np, 0);
@@ -1226,6 +1232,12 @@ static void __init exynos5x_clk_init(struct
device_node *np,
}
exynos5420_clk_sleep_init();
+
+ for (i = 0; i ARRAY_SIZE(boot_clocks); i++) {
+ struct clk *to_enable = __clk_lookup(boot_clocks[i]);
+
+ clk_prepare_enable(to_enable);
+ }
}
static void __init exynos5420_clk_init(struct device_node *np)
@@ -1239,3 +1251,15 @@ static void __init exynos5800_clk_init(struct
device_node *np)
exynos5x_clk_init(np, EXYNOS5800);
}
CLK_OF_DECLARE(exynos5800_clk, samsung,exynos5800-clock,
exynos5800_clk_init);
+
+static int __init exynos5420_clk_late_init(void)
+{
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(boot_clocks); i++) {
+ struct clk *to_disable = __clk_lookup(boot_clocks[i]);
+
+ clk_disable_unprepare(to_disable);
+ }
+}
+late_initcall(exynos5420_clk_late_init);
You should return 0 here.
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who knows when the dtc overlay will
every truly make it mainline, as the capemgr was the only real kernel
user of the i2c/at24 eeprom information.
Sounds like we should keep it disabled though so u-boot can be used
to toggle it while waiting for the capemgr. That's because the board
has a header for pins, so it's not exactly limited to just the capes.
Anybody working on enabling/disabling cape dtb configurations in u-boot?
Well,
Would Tom even approve of that in mainline u-boot? He didn't want my
invert the gpio to enable the usb hub on the older beagle xm A/B..
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
Using fdt set from the bootloader to use the same FDT for similar
boards (like the example with Beagle xM variants) is kind of trying to
replicate what we used to do from boards files where it was possible
to manage a set of boards using the same platform code.
But Device Trees are meant to describe hardware and thus should be
static, if two board are almost identical but slightly different, then
are two different hardware where each need its proper FDT that
describes it.
I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive someone
to madness quite quickly. Moving all of Pantelis' work for dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
etc) sounds like a step in the wrong direction.
Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.
--
Tom
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On Tue, May 13, 2014 at 4:22 PM, Matt Porter matt.por...@linaro.org wrote:
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who knows when the dtc overlay will
every truly make it mainline, as the capemgr was the only real kernel
user of the i2c/at24 eeprom information.
Sounds like we should keep it disabled though so u-boot can be used
to toggle it while waiting for the capemgr. That's because the board
has a header for pins, so it's not exactly limited to just the capes.
Anybody working on enabling/disabling cape dtb configurations in u-boot?
Well,
Would Tom even approve of that in mainline u-boot? He didn't want my
invert the gpio to enable the usb hub on the older beagle xm A/B..
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
Using fdt set from the bootloader to use the same FDT for similar
boards (like the example with Beagle xM variants) is kind of trying to
replicate what we used to do from boards files where it was possible
to manage a set of boards using the same platform code.
But Device Trees are meant to describe hardware and thus should be
static, if two board are almost identical but slightly different, then
are two different hardware where each need its proper FDT that
describes it.
I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive someone
to madness quite quickly. Moving all of Pantelis' work for dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
etc) sounds like a step in the wrong direction.
Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.
It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.
Right, I forgot that the capes were stackable so is indeed not
practical to model every single combination as DTS in mainline. Even
if stacking was not possible there are just too many capes out there
to have a DTS for every single cape.
My point was that someone who wants to use a BBB + a set of capes can
today write a DTS for its own stacked setup.
Unfortunately I don't have a solution but what I'm pretty sure is that
mangling the DTS from the bootloader is not the right one :-)
-Matt
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
Hello Pantelis,
On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
Hi Javier,
On May 13, 2014, at 7:39 AM, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 4:22 PM, Matt Porter matt.por...@linaro.org wrote:
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who knows when the dtc overlay will
every truly make it mainline, as the capemgr was the only real kernel
user of the i2c/at24 eeprom information.
Sounds like we should keep it disabled though so u-boot can be used
to toggle it while waiting for the capemgr. That's because the board
has a header for pins, so it's not exactly limited to just the capes.
Anybody working on enabling/disabling cape dtb configurations in u-boot?
Well,
Would Tom even approve of that in mainline u-boot? He didn't want my
invert the gpio to enable the usb hub on the older beagle xm A/B..
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
Using fdt set from the bootloader to use the same FDT for similar
boards (like the example with Beagle xM variants) is kind of trying to
replicate what we used to do from boards files where it was possible
to manage a set of boards using the same platform code.
But Device Trees are meant to describe hardware and thus should be
static, if two board are almost identical but slightly different, then
are two different hardware where each need its proper FDT that
describes it.
I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive someone
to madness quite quickly. Moving all of Pantelis' work for dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
etc) sounds like a step in the wrong direction.
Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.
It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.
Since this appears to be all coming back to DT overlays, let me try to
address some points.
It seems that you misunderstood my comments. I do think that DT
overlays and the cape manager are a great solution for any hardware
that could be expanded on runtime and I really hope that they can
eventually land into mainline.
In fact if you look on my previous mail you will see that I said:
until device tree overlay and the cape manager find their way into
mainline...
Right, I forgot that the capes were stackable so is indeed not
practical to model every single combination as DTS in mainline. Even
if stacking was not possible there are just too many capes out there
to have a DTS for every single cape.
Each cape does have a DTS as dynamically loaded fragment; it works absolutely
fine.
Trying to come up with a base DTS for all the capes you've stacked up
is an exponential problem.
My point was that someone who wants to use a BBB + a set of capes can
today write a DTS for its own stacked setup.
No, the guy that designs a cape (or learns how to) can not write a DTS for
the base board and the cape in question. Doing that he essentially cuts
himself off from the community.
Let me explain, the point is for people to easily design capes, open-source
their
design as well as their software, and share them to the community.
This requires that things are easily shareable.
Requiring a relative newbie in kernel development not only generate his own
base DT, but also to merge all of the other capes DT into his own is a
nightmare.
BTW, on another tangent, it's not just the BB people that care about dynamic
hardware configuration. There are a number of FPGA people that seem interested
as well.
The notion of hardware as something static that never changes is obsolete
IMHO.
Unfortunately I don't have a solution but what I'm pretty sure is that
mangling the DTS from the bootloader is not the right one :-)
No, it is not. And this is what we're trying to solve here.
What I said that I'm against is modifying a FDT using U-Boot scripts
commands that is something that mentioned in this thread. That is not
a robust way to do it and also is not something that a newbie could do
it neither.
Also, doing these FDT changes in the bootloader has several
disadvantages, besides having to implement on each bootloaders like
Tom said, you need to upgrade your
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
Hello Jhon,
On Wed, May 14, 2014 at 7:44 AM, John Syn john3...@gmail.com wrote:
On 5/13/14, 8:39 PM, Pantelis Antoniou pantelis.anton...@gmail.com
wrote:
Hi John,
On May 13, 2014, at 1:24 PM, John Syn wrote:
On 5/13/14, 10:51 AM, Javier Martinez Canillas jav...@dowhile0.org
wrote:
Hello Pantelis,
On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
Hi Javier,
On May 13, 2014, at 7:39 AM, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 4:22 PM, Matt Porter matt.por...@linaro.org
wrote:
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas
wrote:
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who knows when the dtc
overlay will
every truly make it mainline, as the capemgr was the only real
kernel
user of the i2c/at24 eeprom information.
Sounds like we should keep it disabled though so u-boot can be
used
to toggle it while waiting for the capemgr. That's because the
board
has a header for pins, so it's not exactly limited to just the
capes.
Anybody working on enabling/disabling cape dtb configurations in
u-boot?
Well,
Would Tom even approve of that in mainline u-boot? He didn't want
my
invert the gpio to enable the usb hub on the older beagle xm
A/B..
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
Using fdt set from the bootloader to use the same FDT for similar
boards (like the example with Beagle xM variants) is kind of trying
to
replicate what we used to do from boards files where it was
possible
to manage a set of boards using the same platform code.
But Device Trees are meant to describe hardware and thus should be
static, if two board are almost identical but slightly different,
then
are two different hardware where each need its proper FDT that
describes it.
I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive
someone
to madness quite quickly. Moving all of Pantelis' work for
dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox,
UEFI,
etc) sounds like a step in the wrong direction.
Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if
they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an
dtsi
and not something that can be added on runtime.
It's far more complicated than a SOM plus carrier board. Consider
that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.
Since this appears to be all coming back to DT overlays, let me try to
address some points.
It seems that you misunderstood my comments. I do think that DT
overlays and the cape manager are a great solution for any hardware
that could be expanded on runtime and I really hope that they can
eventually land into mainline.
In fact if you look on my previous mail you will see that I said:
until device tree overlay and the cape manager find their way into
mainline...
Right, I forgot that the capes were stackable so is indeed not
practical to model every single combination as DTS in mainline. Even
if stacking was not possible there are just too many capes out there
to have a DTS for every single cape.
Each cape does have a DTS as dynamically loaded fragment; it works
absolutely fine.
Trying to come up with a base DTS for all the capes you've stacked up
is an exponential problem.
My point was that someone who wants to use a BBB + a set of capes can
today write a DTS for its own stacked setup.
No, the guy that designs a cape (or learns how to) can not write a DTS
for
the base board and the cape in question. Doing that he essentially
cuts
himself off from the community.
Let me explain, the point is for people to easily design capes,
open-source their
design as well as their software, and share them to the community.
This requires that things are easily shareable.
Requiring a relative newbie in kernel development not only generate
his
own
base DT, but also to merge all of the other capes DT into his own is a
nightmare.
BTW, on another tangent, it's not just the BB people that care about
dynamic
hardware configuration. There are a number of FPGA people that seem
interested
as well.
The notion of hardware as something static that never changes is
obsolete IMHO.
Unfortunately I don't have a solution but what I'm pretty sure is
that
mangling the DTS from the bootloader is not the right one :-)
No, it is not. And this is what we're trying to solve here.
What I said that I'm against is modifying a FDT using U-Boot scripts
