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
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
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 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] ARM: dts: OMAP3: Use MTD constants for OMAP3 boards
On 06/11/2013 04:48 PM, Florian Vaussard wrote:
Use the MTD constants for NAND and OneNAND nodes used in OMAP3
DTS.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3-devkit8000.dts | 10 +-
arch/arm/boot/dts/omap3-igep0020.dts | 10 +-
arch/arm/boot/dts/omap3-igep0030.dts | 10 +-
arch/arm/boot/dts/omap3430-sdp.dts | 28 ++--
4 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts
b/arch/arm/boot/dts/omap3-devkit8000.dts
index 5be71b1..08699cb 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -143,27 +143,27 @@
x-loader@0 {
label = X-Loader;
- reg = 0 0x8;
+ reg = (0 * SZ_128K) (4 * SZ_128K);
};
bootloaders@8 {
label = U-Boot;
- reg = 0x8 0x1e;
+ reg = (4 * SZ_128K) (15 * SZ_128K);
};
bootloaders_env@26 {
label = U-Boot Env;
- reg = 0x26 0x2;
+ reg = (19 * SZ_128K) (1 * SZ_128K);
};
kernel@28 {
label = Kernel;
- reg = 0x28 0x40;
+ reg = (20 * SZ_128K) (32 * SZ_128K);
};
filesystem@68 {
label = File System;
- reg = 0x68 0xf98;
+ reg = (52 * SZ_128K) MTDPART_SIZ_FULL;
};
};
};
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e8c4828..3476b3c 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -97,23 +97,23 @@
partition@0 {
label = SPL;
- reg = 0 0x10;
+ reg = (0 * SZ_256K) (4 * SZ_256K);
};
partition@0x8 {
label = U-Boot;
- reg = 0x10 0x18;
+ reg = (4 * SZ_256K) (6 * SZ_256K);
};
partition@0x1c {
label = Environment;
- reg = 0x28 0x10;
+ reg = (10 * SZ_256K) (4 * SZ_256K);
};
partition@0x28 {
label = Kernel;
- reg = 0x38 0x30;
+ reg = (14 * SZ_256K) (12 * SZ_256K);
};
partition@0x78 {
label = Filesystem;
- reg = 0x68 0x1f98;
+ reg = (26 * SZ_256K) MTDPART_SIZ_FULL;
};
};
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
index 644d053..e4f078c 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -72,23 +72,23 @@
partition@0 {
label = SPL;
- reg = 0 0x10;
+ reg = (0 * SZ_256K) (4 * SZ_256K);
};
partition@0x8 {
label = U-Boot;
- reg = 0x10 0x18;
+ reg = (4 * SZ_256K) (6 * SZ_256K);
};
partition@0x1c {
label = Environment;
- reg = 0x28 0x10;
+ reg = (10 * SZ_256K) (4 * SZ_256K);
};
partition@0x28 {
label = Kernel;
- reg = 0x38 0x30;
+ reg = (14 * SZ_256K) (12 * SZ_256K);
};
partition@0x78 {
label = Filesystem;
- reg = 0x68 0x1f98;
+ reg = (26 * SZ_256K) MTDPART_SIZ_FULL;
};
};
};
Hi Florian,
I don't have access to my IGEP board so I can test it right now but the patch
looks good to me.
In fact I wanted to use MTDPART_SIZ_FULL when added the NAND nodes since not all
IGEP boards have 512MB flash but I didn't know that a value of 0 meant that.
So thanks a lot for doing this!
Acked-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/4] ARM: dts: omap3-tobi: Add SMSC911X node
On 06/11/2013 04:49 PM, Florian Vaussard wrote:
The Tobi expansion boards embeds a SMSC LAN8700 PHY. Add the
corresponding node into the DT. The regulators are not designed
to be turned off.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3-tobi.dts | 48
++
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-tobi.dts
b/arch/arm/boot/dts/omap3-tobi.dts
index c7eebbf..dea726f 100644
--- a/arch/arm/boot/dts/omap3-tobi.dts
+++ b/arch/arm/boot/dts/omap3-tobi.dts
@@ -24,6 +24,54 @@
linux,default-trigger = heartbeat;
};
};
+
+ vddvario: regulator-vddvario {
+ compatible = regulator-fixed;
+ regulator-name = vddvario;
+ regulator-always-on;
+ };
+
+ vdd33a: regulator-vdd33a {
+ compatible = regulator-fixed;
+ regulator-name = vdd33a;
+ regulator-always-on;
+ };
+};
+
+gpmc {
+ ranges = 5 0 0x2c00 0x100;/* CS5 */
+
+ ethernet@5,0 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 5 0 0xff;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 42;
+ gpmc,cs-wr-off-ns = 36;
+ gpmc,adv-on-ns = 6;
+ gpmc,adv-rd-off-ns = 12;
+ gpmc,adv-wr-off-ns = 12;
+ gpmc,oe-on-ns = 0;
+ gpmc,oe-off-ns = 42;
+ gpmc,we-on-ns = 0;
+ gpmc,we-off-ns = 36;
+ gpmc,rd-cycle-ns = 60;
+ gpmc,wr-cycle-ns = 54;
+ gpmc,access-ns = 36;
+ gpmc,page-burst-access-ns = 0;
+ gpmc,bus-turnaround-ns = 0;
+ gpmc,cycle2cycle-delay-ns = 0;
+ gpmc,wr-data-mux-bus-ns = 18;
+ gpmc,wr-access-ns = 42;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ interrupt-parent = gpio6;
+ interrupts = 16 IRQ_TYPE_LEVEL_LOW; /* GPIO 176*/
+ reg-io-width = 4;
+ };
};
i2c3 {
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
On 06/06/2013 01:26 AM, Grant Likely wrote: On Tue, 09 Apr 2013 00:44:05 +0200, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: On 04/09/2013 12:05 AM, Rob Herring wrote: On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote: This means that drivers that need the IRQ type/level flags defined in the DT won't be able to get it. But the interrupt controllers that need the information should be able to get to it via irqd_get_trigger_type. What problem exactly are you trying to fix? What driver would use this? Yes but this is not about the interrupt controller wanting this information but a device driver that is using the IORESOURCE_IRQ struct resource that has the information about the virtual IRQ associated with a GPIO-IRQ. The driver doesn't know neither care if its IRQ line is connected to a line of an real IRQ controller or to a GPIO controller that allows a GPIO line to be used as an IRQ. My understanding of the IORESOURCE_IRQ_xxx (and DMA) bits are they are ISA specific and therefore should not be used on non-ISA buses. Many TI OMAP2+ SoC based boards have an SMSC LAN911x/912x controller (drivers/net/ethernet/smsc/smsc911x.c) that is connected to the OMAP processor through its General-Purpose Memory Controller (GPMC) and this LAN driver obtain its IRQ and I/O address space from a struct resource IORESOURCE_IRQ and IORESOURCE_MEM respectively, that is filled by the DeviceTree core. It does this: irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0); irq_flags = irq_res-flags IRQF_TRIGGER_MASK; Since of_irq_to_resource() doesn't fill the trigger/level flags on the IORESOURCE_IRQ struct resource, irq_flags will always be 0 regarding the value specified on the second cell of the interrupts DT property. A previous discussion about this can be found here [1]. I can't remember if there was ever a reason for not returning the IRQ flags, but I don't have any major objection to doing so if drivers find them useful. The one concern I do have however is if it will cause any problems with drivers that expect flags == IORESOURCE_IRQ without any additional flags. Any users doing that are buggy anyway, but I do want to be careful about breakage. I'll go over your patch and reply with comments. g. It turns out that if you don't pass a trigger type to the request_irq() call, it will use the trigger type set by the irq chip earlier with .xlate For some reasons it was not getting the right trigger type when I sent this patch but now it is working correctly so probably there was a bug on the irq_chip driver I was using (drivers/gpio/gpio-omap.c) and got fixed in the meantime. So I don't need this patch anymore to make the LAN chip work on my board and I don't know if the fact that an empty edge/level flags defaults to what was set using the .xlate function handler and this function is called in irq_create_of_mapping() is a reason enough to not return the IRQ flags on the struct resource. Having said that, if you still think this patch is useful then I can send a v2 that take into account your comments on the patch. Best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
On 06/06/2013 01:34 AM, Grant Likely wrote: On Fri, 5 Apr 2013 09:48:08 +0200, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: [...] irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to the correct xlate function handler according to #interrupt-cells (irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to irq_set_irq_type() to set the IRQ type. But the type is never returned so it can't be saved on the IRQ struct resource flags member. This means that drivers that need the IRQ type/level flags defined in the DT won't be able to get it. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk [...] diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h index 535cecf..98aec57 100644 --- a/include/linux/of_irq.h +++ b/include/linux/of_irq.h @@ -66,6 +66,10 @@ extern int of_irq_map_one(struct device_node *device, int index, extern unsigned int irq_create_of_mapping(struct device_node *controller, const u32 *intspec, unsigned int intsize); +extern unsigned int irq_create_of_mapping_type(struct device_node *controller, + const u32 *intspec, + unsigned int intsize, + unsigned int *otype); Hi Grant, thanks a lot for your feedback. I count 11 users of irq_create_of_mapping(). That's a managable number to update. Yes, but since of_irq_to_resource() doesn't call irq_create_of_mapping() directly but it does though irq_of_parse_and_map(), then this function signature has to be modified too. I'm counting 223 users of irq_of_parse_and_map() so the change is not that small anymore. Another approach is to call of_irq_map_one() and irq_create_of_mapping() directly from of_irq_to_resource() instead of using irq_of_parse_and_map() but I don't like that... Instead of creating a new function, please modify the existing one and split it off into a separate patch. But that won't break git bisect-ability? or do you mean to first just change the functions signatures by adding an argument and update its users and then in a separate patch do the actual change to the functions to store the IRQ? Otherwise the patch looks fine to me. g. Best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/2] ARM: dts: omap3-igep0030: Add NAND flash support
On 05/27/2013 10:40 AM, Benoit Cousson wrote: Hi Javier, Hi Benoit, On 05/10/2013 09:40 PM, Javier Martinez Canillas wrote: The IGEP COM Module has an 512MB NAND flash memory. Add a device node for this NAND and its parition layout. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v1: - I just realized that sent a wrong version of the patch, sorry for the noise And what about the first one? For igep0020? Thanks, Benoit For the igep0020 the first one was already correct. I just sent the wrong one for the igep0030 and that's why I had to send a v2 for this patch. Sorry for the confusion. Best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/2] ARM: dts: omap3-igep0030: Add NAND flash support
On 05/27/2013 10:54 AM, Benoit Cousson wrote: On 05/27/2013 10:50 AM, Javier Martinez Canillas wrote: On 05/27/2013 10:40 AM, Benoit Cousson wrote: Hi Javier, Hi Benoit, On 05/10/2013 09:40 PM, Javier Martinez Canillas wrote: The IGEP COM Module has an 512MB NAND flash memory. Add a device node for this NAND and its parition layout. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v1: - I just realized that sent a wrong version of the patch, sorry for the noise And what about the first one? For igep0020? Thanks, Benoit For the igep0020 the first one was already correct. I just sent the wrong one for the igep0030 and that's why I had to send a v2 for this patch. Sorry for the confusion. OK, I've just applied the v1 igep0020 and v2 igep0030 after fixing the changelog typo parition. Patches are available here: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Regards, Benoit Perfect, thanks a lot! Best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] ARM: dts: omap3-igep0020: Add NAND flash support
On Fri, May 10, 2013 at 9:31 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: The IGEPv2 board has an 512MB NAND flash memory. Add a device node for this NAND and its parition layout. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Benoit, This patch depends on a previous posted patch: [PATCH] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support Best regards, Javier arch/arm/boot/dts/omap3-igep0020.dts | 50 +- 1 files changed, 49 insertions(+), 1 deletions(-) Hello Benoit, Any comments on these patches? Should I resend or if you want I can put all IGEP DT patches on a branch and send a pull request if that's easier for you. Tnaks a lot and best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] ARM: dts: omap3-igep0020: Add NAND flash support
The IGEPv2 board has an 512MB NAND flash memory.
Add a device node for this NAND and its parition layout.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Benoit,
This patch depends on a previous posted patch:
[PATCH] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support
Best regards,
Javier
arch/arm/boot/dts/omap3-igep0020.dts | 50 +-
1 files changed, 49 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index 4bac32e..0ba4313 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -68,7 +68,55 @@
};
gpmc {
- ranges = 5 0 0x2c00 0x100;
+ ranges = 0 0 0x 0x2000,
+5 0 0x2c00 0x0100;
+
+ nand@0,0 {
+ linux,mtd-name= micron,mt29c4g96maz;
+ reg = 0 0 0;
+ nand-bus-width = 16;
+ ti,nand-ecc-opt = bch8;
+
+ gpmc,sync-clk-ps = 0;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 44;
+ gpmc,cs-wr-off-ns = 44;
+ gpmc,adv-on-ns = 6;
+ gpmc,adv-rd-off-ns = 34;
+ gpmc,adv-wr-off-ns = 44;
+ gpmc,we-off-ns = 40;
+ gpmc,oe-off-ns = 54;
+ gpmc,access-ns = 64;
+ gpmc,rd-cycle-ns = 82;
+ gpmc,wr-cycle-ns = 82;
+ gpmc,wr-access-ns = 40;
+ gpmc,wr-data-mux-bus-ns = 0;
+
+ #address-cells = 1;
+ #size-cells = 1;
+
+ partition@0 {
+ label = SPL;
+ reg = 0 0x10;
+ };
+ partition@0x8 {
+ label = U-Boot;
+ reg = 0x10 0x18;
+ };
+ partition@0x1c {
+ label = Environment;
+ reg = 0x28 0x10;
+ };
+ partition@0x28 {
+ label = Kernel;
+ reg = 0x38 0x30;
+ };
+ partition@0x78 {
+ label = Filesystem;
+ reg = 0x68 0x1f98;
+ };
+ };
+
ethernet@5,0 {
pinctrl-names = default;
pinctrl-0 = smsc911x_pins;
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/2] ARM: dts: omap3-igep0030: Add NAND flash support
The IGEP COM Module has an 512MB NAND flash memory.
Add a device node for this NAND and its parition layout.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep0020.dts |1 +
arch/arm/boot/dts/omap3-igep0030.dts | 50 ++
2 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index 0ba4313..6f0ecf4 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -155,3 +155,4 @@
smsc,save-mac-address;
};
};
+
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
index 9dc48d2..6b71656 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -42,3 +42,53 @@
};
};
};
+
+gpmc {
+ ranges = 0 0 0x 0x2000;
+
+ nand@0,0 {
+ linux,mtd-name= micron,mt29c4g96maz;
+ reg = 0 0 0;
+ nand-bus-width = 16;
+ ti,nand-ecc-opt = bch8;
+
+ gpmc,sync-clk-ps = 0;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 44;
+ gpmc,cs-wr-off-ns = 44;
+ gpmc,adv-on-ns = 6;
+ gpmc,adv-rd-off-ns = 34;
+ gpmc,adv-wr-off-ns = 44;
+ gpmc,we-off-ns = 40;
+ gpmc,oe-off-ns = 54;
+ gpmc,access-ns = 64;
+ gpmc,rd-cycle-ns = 82;
+ gpmc,wr-cycle-ns = 82;
+ gpmc,wr-access-ns = 40;
+ gpmc,wr-data-mux-bus-ns = 0;
+
+ #address-cells = 1;
+ #size-cells = 1;
+
+ partition@0 {
+ label = SPL;
+ reg = 0 0x10;
+ };
+ partition@0x8 {
+ label = U-Boot;
+ reg = 0x10 0x18;
+ };
+ partition@0x1c {
+ label = Environment;
+ reg = 0x28 0x10;
+ };
+ partition@0x28 {
+ label = Kernel;
+ reg = 0x38 0x30;
+ };
+ partition@0x78 {
+ label = Filesystem;
+ reg = 0x68 0x1f98;
+ };
+ };
+};
\ No newline at end of file
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 2/2] ARM: dts: omap3-igep0030: Add NAND flash support
The IGEP COM Module has an 512MB NAND flash memory.
Add a device node for this NAND and its parition layout.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1:
- I just realized that sent a wrong version of the patch, sorry for the noise
arch/arm/boot/dts/omap3-igep0030.dts | 50 ++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
index 9dc48d2..f65bc3a 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -42,3 +42,53 @@
};
};
};
+
+gpmc {
+ ranges = 0 0 0x 0x2000;
+
+ nand@0,0 {
+ linux,mtd-name= micron,mt29c4g96maz;
+ reg = 0 0 0;
+ nand-bus-width = 16;
+ ti,nand-ecc-opt = bch8;
+
+ gpmc,sync-clk-ps = 0;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 44;
+ gpmc,cs-wr-off-ns = 44;
+ gpmc,adv-on-ns = 6;
+ gpmc,adv-rd-off-ns = 34;
+ gpmc,adv-wr-off-ns = 44;
+ gpmc,we-off-ns = 40;
+ gpmc,oe-off-ns = 54;
+ gpmc,access-ns = 64;
+ gpmc,rd-cycle-ns = 82;
+ gpmc,wr-cycle-ns = 82;
+ gpmc,wr-access-ns = 40;
+ gpmc,wr-data-mux-bus-ns = 0;
+
+ #address-cells = 1;
+ #size-cells = 1;
+
+ partition@0 {
+ label = SPL;
+ reg = 0 0x10;
+ };
+ partition@0x8 {
+ label = U-Boot;
+ reg = 0x10 0x18;
+ };
+ partition@0x1c {
+ label = Environment;
+ reg = 0x28 0x10;
+ };
+ partition@0x28 {
+ label = Kernel;
+ reg = 0x38 0x30;
+ };
+ partition@0x78 {
+ label = Filesystem;
+ reg = 0x68 0x1f98;
+ };
+ };
+};
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support
On Wed, Apr 17, 2013 at 6:32 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The IGEPv2 board has an SMSC LAN9221i ethernet chip connected to
the OMAP3 processor though the General-Purpose Memory Controller.
This patch adds a device node for the ethernet chip as a GPMC child
and all its dependencies (regulators, GPIO and pin muxs).
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi|6
arch/arm/boot/dts/omap3-igep0020.dts | 53
++
2 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index f8fe3b7..d5cd504 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -62,6 +62,12 @@
0x126 0x0100/* sdmmc1_dat7.sdmmc1_dat7 INPUT |
MODE 0 */
;
};
+
+ smsc911x_pins: pinmux_smsc911x_pins {
+ pinctrl-single,pins =
+0x1a2 0x0104/* mcspi1_cs2.gpio_176 INPUT | MODE4
*/
+ ;
+ };
};
i2c1 {
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e2b9849..4bac32e 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -40,6 +40,18 @@
gpios = twl_gpio 19 1;
};
};
+
+ vddvario: regulator-vddvario {
+ compatible = regulator-fixed;
+ regulator-name = vddvario;
+ regulator-always-on;
+ };
+
+ vdd33a: regulator-vdd33a {
+ compatible = regulator-fixed;
+ regulator-name = vdd33a;
+ regulator-always-on;
+ };
};
i2c3 {
@@ -54,3 +66,44 @@
reg = 0x50;
};
};
+
+gpmc {
+ ranges = 5 0 0x2c00 0x100;
+ ethernet@5,0 {
+ pinctrl-names = default;
+ pinctrl-0 = smsc911x_pins;
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 5 0 0xff;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 186;
+ gpmc,cs-wr-off-ns = 186;
+ gpmc,adv-on-ns = 12;
+ gpmc,adv-rd-off-ns = 48;
+ gpmc,adv-wr-off-ns = 48;
+ gpmc,oe-on-ns = 54;
+ gpmc,oe-off-ns = 168;
+ gpmc,we-on-ns = 54;
+ gpmc,we-off-ns = 168;
+ gpmc,rd-cycle-ns = 186;
+ gpmc,wr-cycle-ns = 186;
+ gpmc,access-ns = 114;
+ gpmc,page-burst-access-ns = 6;
+ gpmc,bus-turnaround-ns = 12;
+ gpmc,cycle2cycle-delay-ns = 18;
+ gpmc,wr-data-mux-bus-ns = 90;
+ gpmc,wr-access-ns = 186;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ interrupt-parent = gpio6;
+ interrupts = 16 8;
+ vmmc-supply = vddvario;
+ vmmc_aux-supply = vdd33a;
+ reg-io-width = 4;
+
+ smsc,save-mac-address;
+ };
+};
--
1.7.7.6
--
Hi Benoit,
Any comments on this patch?
Thanks a lot and best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RESEND] genirq: add function to get IRQ edge/level flags
According to
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the #interrupt-cells property of an interrupt-controller is used
to define the number of cells needed to specify a single interrupt.
A commonly used variant is two cell on which #interrupt-cells = 2
and the first cell defines the index of the interrupt in the controller
while the second cell is used to specify any of the following flags:
- bits[3:0] trigger type and level flags
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
An example of an interrupt controller which use the two cell format is
the OMAP GPIO controller that allows GPIO lines to be used as IRQ
(Documentation/devicetree/bindings/gpio/gpio-omap.txt)
But setting #interrupt-cells = 2 on the OMAP GPIO device node and
specifying the GPIO-IRQ type and level flags on the second cell does not
store this value on the populated IORESOURCE_IRQ struct resource.
This is because when using an IRQ from an interrupt controller and
setting both cells (e.g:)
interrupt-parent = gpio6;
interrupts = 16 8;
A call to of_irq_to_resource() is made and this function calls
irq_of_parse_and_map_type() to get the virtual IRQ mapped to the real
index for this interrupt controller. This IRQ number is populated on
the struct resource:
int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
{
int irq = irq_of_parse_and_map(dev, index);
..
r-start = r-end = irq;
}
irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
the correct xlate function handler according to #interrupt-cells
(irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
irq_set_irq_type() to set the IRQ type.
But the type is never returned so it can't be saved on the IRQ struct
resource flags member.
This means that drivers that want to get the IRQ edge/level flags
defined in the Device Tree from a struct resource will not be able
to get it.
Drivers can get the IRQ flags by using irq_get_irq_data(irq) and
irqd_get_trigger_type(irq_data) but this will unnecessary expose
irq_data to callers and also is more error prone.
So, is better to add an irq_get_trigger_type() function to obtain
the edge/level flags for an IRQ.
Signed-off-by: Javier Martinez Canillas javier.marti...@dowhile0.org
---
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
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/2] genirq: add function to get IRQ edge/level flags
On Sat, Apr 13, 2013 at 3:21 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
According to
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the #interrupt-cells property of an interrupt-controller is used
to define the number of cells needed to specify a single interrupt.
A commonly used variant is two cell on which #interrupt-cells = 2
and the first cell defines the index of the interrupt in the controller
while the second cell is used to specify any of the following flags:
- bits[3:0] trigger type and level flags
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
An example of an interrupt controller which use the two cell format is
the OMAP GPIO controller that allows GPIO lines to be used as IRQ
(Documentation/devicetree/bindings/gpio/gpio-omap.txt)
But setting #interrupt-cells = 2 on the OMAP GPIO device node and
specifying the GPIO-IRQ type and level flags on the second cell does not
store this value on the populated IORESOURCE_IRQ struct resource.
This is because when using an IRQ from an interrupt controller and
setting both cells (e.g:)
interrupt-parent = gpio6;
interrupts = 16 8;
A call to of_irq_to_resource() is made and this function calls
irq_of_parse_and_map_type() to get the virtual IRQ mapped to the real
index for this interrupt controller. This IRQ number is populated on
the struct resource:
int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
{
int irq = irq_of_parse_and_map(dev, index);
..
r-start = r-end = irq;
}
irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
the correct xlate function handler according to #interrupt-cells
(irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
irq_set_irq_type() to set the IRQ type.
But the type is never returned so it can't be saved on the IRQ struct
resource flags member.
This means that drivers that want to get the IRQ edge/level flags
defined in the Device Tree from a struct resource will not be able
to get it.
Drivers can get the IRQ flags by using irq_get_irq_data(irq) and
irqd_get_trigger_type(irq_data) but this will unnecessary expose
irq_data to callers and also is more error prone.
So, is better to add 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
---
Changes since v1:
- use irqd_get_trigger_type() instead of a direct access to
d-state_use_accessors as suggested by Stephen Warren.
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
--
Hello,
Any comments about this patch?
Thanks a lot and best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/2] ARM: OMAP2+: only search for GPMC DT child nodes on probe
On 04/18/2013 12:33 AM, Jon Hunter wrote:
On 04/17/2013 05:10 PM, Javier Martinez Canillas wrote:
On 04/17/2013 11:27 PM, Jon Hunter wrote:
On 04/17/2013 03:34 PM, Javier Martinez Canillas wrote:
The GPMC DT probe function use for_each_node_by_name() to search
child device nodes of the GPMC controller. But this function does
not use the GPMC device node as the root of the search and instead
search across the complete Device Tree.
This means that any device node on the DT that is using any of the
GPMC child nodes names searched for will be returned even if they
are not connected to the GPMC, making the gpmc_probe_xxx_child()
function to fail.
Fix this by using the GPMC device node as the search root so the
search will be restricted to its children.
Reported-by: Lars Poeschel poesc...@lemonage.de
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1 (suggested by Jon Hunter):
- Split the search for GPMC child nodes and only warn if a
child probe fails on two different patches
- Don't probe all childs unnecesary if a previous matched
arch/arm/mach-omap2/gpmc.c | 33 ++---
1 files changed, 10 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ed946df..6166847 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1520,32 +1520,19 @@ static int gpmc_probe_dt(struct platform_device
*pdev)
return ret;
}
- for_each_node_by_name(child, nand) {
- ret = gpmc_probe_nand_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
- }
- }
+ for_each_child_of_node(pdev-dev.of_node, child) {
- for_each_node_by_name(child, onenand) {
- ret = gpmc_probe_onenand_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
- }
- }
+ if (!child-name)
+ continue;
- for_each_node_by_name(child, nor) {
- ret = gpmc_probe_generic_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
- }
- }
+ if (of_node_cmp(child-name, nand) == 0)
+ ret = gpmc_probe_nand_child(pdev, child);
+ else if (of_node_cmp(child-name, onenand) == 0)
+ ret = gpmc_probe_onenand_child(pdev, child);
+ else if (of_node_cmp(child-name, ethernet) == 0 ||
+ of_node_cmp(child-name, nor) == 0)
+ ret = gpmc_probe_generic_child(pdev, child);
- for_each_node_by_name(child, ethernet) {
- ret = gpmc_probe_generic_child(pdev, child);
if (ret 0) {
I think that we need to make sure that ret is initialised to 0 at the
beginning of the function. We should not have a case where the child
Hi Jon,
I didn't set ret to 0 at the beginning of the function since it is assigned
the
return value of a previous call to of_property_read_u32(). So ret should be 0
when execution reaches the for loop.
Yes you are right, I overlooked that.
name does not match but who knows. Actually that raises another point,
should we have an else clause at the end that WARNs on
unknown/unsupported child device?
Actually I thought about it when I was writing that patch and then I decided
to
not add a WARN for that case since nothing really fail in that case.
I mean if we want to check that a DT is well formed then I think we will
need to
add much more checks and I don't know if is worth it.
But I don't have a strong opinion on this so if you want I can add it an
send a v3.
Ok, that's fine. I am happy with this version, so no need then to re-do.
Great, thanks a lot for your feedback!
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring robherri...@gmail.com wrote: On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote: On 04/09/2013 12:16 AM, Stephen Warren wrote: On 04/08/2013 04:05 PM, Rob Herring wrote: On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote: According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt the #interrupt-cells property of an interrupt-controller is used to define the number of cells needed to specify a single interrupt. ... But the type is never returned so it can't be saved on the IRQ struct resource flags member. This means that drivers that need the IRQ type/level flags defined in the DT won't be able to get it. But the interrupt controllers that need the information should be able to get to it via irqd_get_trigger_type. What problem exactly are you trying to fix? What driver would use this? FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking back, I'm not sure if that was the right thing or whether I should have sent this same patch:-) Hi Stephen, I'm glad you agree :-) I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags for the IRQ with irqd_get_trigger_type() but I prefer $subject because: irqd_get_trigger_type probably is not meant for outside of irqchips. Creating an irq_get_irq_type function which takes an irq number would be the right function as that does not expose struct irq_data. Hi Rob, I sent a patch-set a few days ago that adds an irq_get_irq_type() function [1] as you suggested and this function is used on the smsc911x driver probe function to get the edge/level flags [2]. It would be great if I can get your feedback on this. Thanks a lot and best regards, Javier [1]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/97117 [2]: http://permalink.gmane.org/gmane.linux.network/265587 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On 04/17/2013 11:40 AM, Lars Poeschel wrote:
Hi Javier!
On Thursday 14 March 2013 at 22:54:11, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: Javier Martinez Canillas
javier.marti...@collabora.co.uk
---
Changes since v2:
- remove optional #address-cells and #size-cells since are not
relevant for ethernet chips; suggested by Jon Hunter.
Changes since v1:
- Improve the DT binding documentation explaining that even when the
GPMC maximum bus address width is 16-bit, it supports devices with
32-bit registers address width and the device property especifying this
has to be set accordingly; suggested by Jon Hunter.
Documentation/devicetree/bindings/net/gpmc-eth.txt | 97
arch/arm/mach-omap2/gpmc.c
|8 ++
2 files changed, 105 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt
b/Documentation/devicetree/bindings/net/gpmc-eth.txt new file mode
100644
index 000..24cb4e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,97 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM
devices +such as ethernet controllers to processors using the TI GPMC
as a data bus. +
+Ethernet controllers connected to TI GPMC are represented as child
nodes of +the GPMC controller with an ethernet name.
+
+All timing relevant properties as well as generic GPMC child properties
are +explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+For the properties relevant to the ethernet controller connected to the
GPMC +refer to the binding documentation of the device. For example,
the documentation +for the SMSC 911x is
Documentation/devicetree/bindings/net/smsc911x.txt +
+Child nodes need to specify the GPMC bus address width using the
bank-width +property but is possible that an ethernet controller also
has a property to +specify the I/O registers address width. Even when
the GPMC has a maximum 16-bit +address width, it supports devices with
32-bit word registers. +For example with an SMSC LAN911x/912x
controller connected to the TI GPMC on an +OMAP2+ board, bank-width =
2; and reg-io-width = 4;.
+
+Required properties:
+- bank-width: Address width of the device in bytes. GPMC
supports
8-bit + and 16-bit devices and so must be either 1 or 2
bytes.
+- compatible: Compatible string property for the ethernet
child
device. +- gpmc,cs-on: Chip-select assertion time
+- gpmc,cs-rd-off: Chip-select de-assertion time for reads
+- gpmc,cs-wr-off: Chip-select de-assertion time for writes
+- gpmc,oe-on: Output-enable assertion time
+- gpmc,oe-off Output-enable de-assertion time
+- gpmc,we-on: Write-enable assertion time
+- gpmc,we-off: Write-enable de-assertion time
+- gpmc,access: Start cycle to first data capture (read access)
+- gpmc,rd-cycle:Total read cycle time
+- gpmc,wr-cycle:Total write cycle time
+- reg: Chip-select, base address (relative to
chip-select)
+and size of the memory mapped for the device.
+Note that base address will be typically 0 as this
+is the start of the chip-select.
+
+Optional properties:
+- gpmc,XXX Additional GPMC timings and settings parameters. See
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Example:
+
+gpmc: gpmc@6e00 {
+compatible = ti,omap3430-gpmc;
+ti,hwmods = gpmc;
+reg = 0x6e00 0x1000;
+interrupts = 20;
+gpmc,num-cs = 8;
+gpmc,num-waitpins = 4;
+#address-cells = 2;
+#size-cells = 1;
+
+ranges = 5 0 0x2c00 0x100;
+
+ethernet@5,0 {
+compatible = smsc,lan9221, smsc,lan9115;
+reg = 5 0 0xff;
+bank-width = 2;
+
+gpmc,mux-add-data;
+gpmc,cs-on = 0;
+gpmc,cs-rd-off = 186;
+gpmc,cs-wr-off = 186;
+gpmc,adv-on = 12;
+gpmc,adv-rd-off = 48;
+gpmc,adv-wr-off = 48;
+gpmc,oe-on = 54;
+gpmc,oe-off = 168;
+gpmc,we-on = 54;
+gpmc,we-off = 168;
+gpmc,rd-cycle = 186;
+gpmc,wr-cycle = 186;
+gpmc
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter jon-hun...@ti.com wrote:
On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
...
There are so many patches flying around in this thread that I missed it :-)
Sorry about that...
No problem.
I was trying to see if we could find a common solution that everyone
could use as it seems that ideally we should all be requesting the gpio.
Cheers
Jon
[1] http://marc.info/?l=linux-arm-kernelm=136606204823845w=1
btw, I shared the latest patch with only build testing it, but today I
gave a try and I found a problem with this approach. The .xlate
function is being called twice for each GPIO-IRQ so the first time
gpio_request_one() succeeds but the second time it fails returning
-EBUSY.
I tried it and I did not see that. I don't see the below warning either.
weird, I wonder what's different here.
I'll try tonight to test using another branch based on your
omap-daily-testing branch.
This raises a warning on drivers/of/platform.c
(WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq)):
0.285308] [ cut here ]
[0.285369] WARNING: at drivers/of/platform.c:171
of_device_alloc+0x154/0x168()
[0.285430] Modules linked in:
[0.285491] [c001a944] (unwind_backtrace+0x0/0xf0) from
[c0041edc] (warn_slowpath_common+0x4c/0x68)
[0.285552] [c0041edc] (warn_slowpath_common+0x4c/0x68) from
[c0041f14] (warn_slowpath_null+0x1c/0x24)
[0.285614] [c0041f14] (warn_slowpath_null+0x1c/0x24) from
[c041ac3c] (of_device_alloc+0x154/0x168)
[0.285675] [c041ac3c] (of_device_alloc+0x154/0x168) from
[c041ac84] (of_platform_device_create_pdata+0x34/0x80)
[0.285736] [c041ac84]
(of_platform_device_create_pdata+0x34/0x80) from [c0027364]
(gpmc_probe_generic_child+0x180/0x240)
[0.285827] [c0027364] (gpmc_probe_generic_child+0x180/0x240)
from [c00278d8] (gpmc_probe+0x4b4/0x614)
[0.285888] [c00278d8] (gpmc_probe+0x4b4/0x614) from [c0325514]
(platform_drv_probe+0x18/0x1c)
[0.285949] [c0325514] (platform_drv_probe+0x18/0x1c) from
[c0324354] (driver_probe_device+0x108/0x21c)
Any chance you have still have some additional code in your dts to
request the gpio? I recall you made some hacks to make this work before.
Yes, but I remove all those hacks from my DT and gpmc driver. Is the
first thing I thought and I already doble checked that.
I probably won't have time to dig further on this until later this
week but I wanted to share with you in case you know why is being
calling twice and if you thought about a solution.
Care to post your dts file?
I'm using the following patch to add smsc ethernet support to my board
+ adding 'ranges = 5 0 0x2c00 0x100;' to the gpmc device
node on omap3.dtsi:
From 4fe26a40229e6e97c2ab3b80865c9f24e8ff3424 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
Date: Wed, 27 Feb 2013 02:59:29 +0100
Subject: [PATCH 2/2] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support
The IGEPv2 board has an SMSC LAN9221i ethernet chip connected to
the OMAP3 processor though the General-Purpose Memory Controller.
This patch adds a device node for the ethernet chip as a GPMC child
and all its requirements (regulators, GPIO and pin muxs).
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi|6
arch/arm/boot/dts/omap3-igep0020.dts | 52 ++
2 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index f8fe3b7..d5cd504 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -62,6 +62,12 @@
0x126 0x0100/* sdmmc1_dat7.sdmmc1_dat7 INPUT | MODE
0 */
;
};
+
+ smsc911x_pins: pinmux_smsc911x_pins {
+ pinctrl-single,pins =
+0x1a2 0x0104/* mcspi1_cs2.gpio_176 INPUT | MODE4 */
+ ;
+ };
};
i2c1 {
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e2b9849..32a59df 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -40,6 +40,18 @@
gpios = twl_gpio 19 1;
};
};
+
+ vddvario: regulator-vddvario {
+ compatible = regulator-fixed;
+ regulator-name = vddvario;
+ regulator-always-on;
+ };
+
+ vdd33a: regulator-vdd33a {
+ compatible = regulator-fixed;
+ regulator-name = vdd33a;
+ regulator-always-on;
+ };
};
i2c3 {
@@ -54,3 +66,43 @@
reg = 0x50;
};
};
+
+gpmc {
+ ethernet@5,0 {
+ pinctrl-names = default;
+ pinctrl-0 = smsc911x_pins;
+ compatible = smsc,lan9221, smsc,lan9115
Re: [PATCH v3 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On 04/17/2013 03:48 PM, Jon Hunter wrote:
On 04/17/2013 07:05 AM, Javier Martinez Canillas wrote:
...
Yes, in fact I just realized that for_each_node_by_name() expand to:
#define for_each_node_by_name(dn, name) \
for (dn = of_find_node_by_name(NULL, name); dn; \
dn = of_find_node_by_name(dn, name))
which means that it will search for a node with name on the complete
DeviceTree and this is wrong. It should only search on GPMC childs.
Good catch. I guess we could have flash ethernet devices connected to
other interfaces such as SPI.
Yes, in fact this is the case for omap4-sdp.dts which has an ethernet controller
connected through SPI:
mcspi1 {
eth@0 {
compatible = ks8851;
spi-max-frequency = 2400;
reg = 0;
interrupt-parent = gpio2;
interrupts = 2; /* gpio line 34 */
vdd-supply = vdd_eth;
};
};
it just didn't fail because the device node name is eth and not ethernet.
which makes me wonder if is OK to rely on a device node name or we should use
compatible properties instead such as ti,gpmc-{eth,nand,nor,onenand} and do
something like:
for_each_compatible_node(pdev-dev.of_node, NULL, ti,gpmc-eth) and so on.
Could you please test the following patch? If it works for you I'll add a
proper
description and submit it as a PATCH.
Thanks a lot and best regards,
Javier
From d8dab9ae9a0284f17553875c2fddd806d9f6ab2e Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
Date: Wed, 17 Apr 2013 13:50:30 +0200
Subject: [PATCH] ARM: OMAP2+: only search for GPMC DT child nodes on
probe
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2/gpmc.c | 51
---
1 files changed, 24 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ed946df..58e2415 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1520,35 +1520,32 @@ static int gpmc_probe_dt(struct platform_device
*pdev)
return ret;
}
-for_each_node_by_name(child, nand) {
-ret = gpmc_probe_nand_child(pdev, child);
-if (ret 0) {
-of_node_put(child);
-return ret;
-}
-}
-
-for_each_node_by_name(child, onenand) {
-ret = gpmc_probe_onenand_child(pdev, child);
-if (ret 0) {
-of_node_put(child);
-return ret;
-}
-}
+for_each_child_of_node(pdev-dev.of_node, child) {
+if (child-name) {
Minor nit ... how about ...
+ if (!child-name)
continue;
Yes, much better. I just cooked a quick patch so Lars could test it ;-)
+if (of_node_cmp(child-name, nand) == 0) {
+ret = gpmc_probe_nand_child(pdev, child);
+if (ret 0) {
+of_node_put(child);
+return ret;
+}
+}
-for_each_node_by_name(child, nor) {
-ret = gpmc_probe_generic_child(pdev, child);
-if (ret 0) {
-of_node_put(child);
-return ret;
-}
-}
+if (of_node_cmp(child-name, onenand) == 0) {
+ret = gpmc_probe_onenand_child(pdev, child);
+if (ret 0) {
+of_node_put(child);
+return ret;
+}
+}
-for_each_node_by_name(child, ethernet) {
-ret = gpmc_probe_generic_child(pdev, child);
-if (ret 0) {
-of_node_put(child);
-return ret;
+if (of_node_cmp(child-name, ethernet) == 0 ||
+of_node_cmp(child-name, nor) == 0) {
+ret = gpmc_probe_generic_child(pdev, child);
+if (ret 0) {
+of_node_put(child);
+return ret;
+}
+}
}
}
I am also wondering if the probe should fail if one of its children
fails. The panic that Lars reported occurred because the nand
successfully probed and so the nand device was registered, but because
the ethernet device probe failed, the gpmc probe fails, and then when
the nand device is probed by the mtd driver the kernel panics. I wonder
if it would be better to WARN on child devices that fail to probe but
not return error from the gpmc probe.
I wonder
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Wed, Apr 17, 2013 at 3:52 PM, Jon Hunter jon-hun...@ti.com wrote: On 04/17/2013 08:42 AM, Javier Martinez Canillas wrote: On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter jon-hun...@ti.com wrote: On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote: ... There are so many patches flying around in this thread that I missed it :-) Sorry about that... No problem. I was trying to see if we could find a common solution that everyone could use as it seems that ideally we should all be requesting the gpio. Cheers Jon [1] http://marc.info/?l=linux-arm-kernelm=136606204823845w=1 btw, I shared the latest patch with only build testing it, but today I gave a try and I found a problem with this approach. The .xlate function is being called twice for each GPIO-IRQ so the first time gpio_request_one() succeeds but the second time it fails returning -EBUSY. I tried it and I did not see that. I don't see the below warning either. weird, I wonder what's different here. I am testing on an omap4-sdp which uses a spi based ethernet device. However, I could try with the omap3430-sdp which uses gpmc. Thanks, that would be great and it could be a difference. But don't worry I'll to test it more extensively when I have some free time. I just shared here in case you had the same issue. Cheers Jon Thanks a lot for your help, Jaiver ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Wed, Apr 17, 2013 at 3:52 PM, Jon Hunter jon-hun...@ti.com wrote: On 04/17/2013 08:42 AM, Javier Martinez Canillas wrote: On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter jon-hun...@ti.com wrote: On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote: ... There are so many patches flying around in this thread that I missed it :-) Sorry about that... No problem. I was trying to see if we could find a common solution that everyone could use as it seems that ideally we should all be requesting the gpio. Cheers Jon [1] http://marc.info/?l=linux-arm-kernelm=136606204823845w=1 btw, I shared the latest patch with only build testing it, but today I gave a try and I found a problem with this approach. The .xlate function is being called twice for each GPIO-IRQ so the first time gpio_request_one() succeeds but the second time it fails returning -EBUSY. I tried it and I did not see that. I don't see the below warning either. weird, I wonder what's different here. I am testing on an omap4-sdp which uses a spi based ethernet device. However, I could try with the omap3430-sdp which uses gpmc. Cheers Jon Hi Jon, I just created a new branch using your omap-daily-testing as a base and cherry-picked all the required patches and the .xlate function is working correctly. I don't see the WARN anymore neither is called twice. Sorry for the noise.. Best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support
The IGEPv2 board has an SMSC LAN9221i ethernet chip connected to
the OMAP3 processor though the General-Purpose Memory Controller.
This patch adds a device node for the ethernet chip as a GPMC child
and all its dependencies (regulators, GPIO and pin muxs).
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi|6
arch/arm/boot/dts/omap3-igep0020.dts | 53 ++
2 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index f8fe3b7..d5cd504 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -62,6 +62,12 @@
0x126 0x0100/* sdmmc1_dat7.sdmmc1_dat7 INPUT | MODE
0 */
;
};
+
+ smsc911x_pins: pinmux_smsc911x_pins {
+ pinctrl-single,pins =
+0x1a2 0x0104/* mcspi1_cs2.gpio_176 INPUT | MODE4 */
+ ;
+ };
};
i2c1 {
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e2b9849..4bac32e 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -40,6 +40,18 @@
gpios = twl_gpio 19 1;
};
};
+
+ vddvario: regulator-vddvario {
+ compatible = regulator-fixed;
+ regulator-name = vddvario;
+ regulator-always-on;
+ };
+
+ vdd33a: regulator-vdd33a {
+ compatible = regulator-fixed;
+ regulator-name = vdd33a;
+ regulator-always-on;
+ };
};
i2c3 {
@@ -54,3 +66,44 @@
reg = 0x50;
};
};
+
+gpmc {
+ ranges = 5 0 0x2c00 0x100;
+ ethernet@5,0 {
+ pinctrl-names = default;
+ pinctrl-0 = smsc911x_pins;
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 5 0 0xff;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 186;
+ gpmc,cs-wr-off-ns = 186;
+ gpmc,adv-on-ns = 12;
+ gpmc,adv-rd-off-ns = 48;
+ gpmc,adv-wr-off-ns = 48;
+ gpmc,oe-on-ns = 54;
+ gpmc,oe-off-ns = 168;
+ gpmc,we-on-ns = 54;
+ gpmc,we-off-ns = 168;
+ gpmc,rd-cycle-ns = 186;
+ gpmc,wr-cycle-ns = 186;
+ gpmc,access-ns = 114;
+ gpmc,page-burst-access-ns = 6;
+ gpmc,bus-turnaround-ns = 12;
+ gpmc,cycle2cycle-delay-ns = 18;
+ gpmc,wr-data-mux-bus-ns = 90;
+ gpmc,wr-access-ns = 186;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ interrupt-parent = gpio6;
+ interrupts = 16 8;
+ vmmc-supply = vddvario;
+ vmmc_aux-supply = vdd33a;
+ reg-io-width = 4;
+
+ smsc,save-mac-address;
+ };
+};
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] ARM: OMAP2+: only search for GPMC DT child nodes on probe
The GPMC DT probe function use for_each_node_by_name() to search
child device nodes of the GPMC controller. But this function does
not use the GPMC device node as the root of the search and instead
search across the complete Device Tree.
This means that any device node on the DT that is using any of the
GPMC child nodes names searched for will be returned even if they
are not connected to the GPMC, making the gpmc_probe_xxx_child()
function to fail.
Fix this by using the GPMC device node as the search root so the
search will be restricted to its children.
Also, if any of the GPMC child nodes fails, this shouldn't make
the whole gpmc_probe_dt() function to fail. It is better to just
WARN and allow other devices probe function to succeed.
Reported-by: Lars Poeschel poesc...@lemonage.de
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2/gpmc.c | 41 +
1 files changed, 17 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ed946df..f10d735 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1520,35 +1520,28 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
- for_each_node_by_name(child, nand) {
- ret = gpmc_probe_nand_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
- }
- }
+ for_each_child_of_node(pdev-dev.of_node, child) {
+
+ if (!child-name)
+ continue;
- for_each_node_by_name(child, onenand) {
- ret = gpmc_probe_onenand_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
+ if (of_node_cmp(child-name, nand) == 0) {
+ ret = gpmc_probe_nand_child(pdev, child);
+ if (WARN_ON(ret 0))
+ of_node_put(child);
}
- }
- for_each_node_by_name(child, nor) {
- ret = gpmc_probe_generic_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
+ if (of_node_cmp(child-name, onenand) == 0) {
+ ret = gpmc_probe_onenand_child(pdev, child);
+ if (WARN_ON(ret 0))
+ of_node_put(child);
}
- }
- for_each_node_by_name(child, ethernet) {
- ret = gpmc_probe_generic_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
+ if (of_node_cmp(child-name, ethernet) == 0 ||
+ of_node_cmp(child-name, nor) == 0) {
+ ret = gpmc_probe_generic_child(pdev, child);
+ if (WARN_ON(ret 0))
+ of_node_put(child);
}
}
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 1/2] ARM: OMAP2+: only search for GPMC DT child nodes on probe
The GPMC DT probe function use for_each_node_by_name() to search
child device nodes of the GPMC controller. But this function does
not use the GPMC device node as the root of the search and instead
search across the complete Device Tree.
This means that any device node on the DT that is using any of the
GPMC child nodes names searched for will be returned even if they
are not connected to the GPMC, making the gpmc_probe_xxx_child()
function to fail.
Fix this by using the GPMC device node as the search root so the
search will be restricted to its children.
Reported-by: Lars Poeschel poesc...@lemonage.de
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1 (suggested by Jon Hunter):
- Split the search for GPMC child nodes and only warn if a
child probe fails on two different patches
- Don't probe all childs unnecesary if a previous matched
arch/arm/mach-omap2/gpmc.c | 33 ++---
1 files changed, 10 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ed946df..6166847 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1520,32 +1520,19 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
- for_each_node_by_name(child, nand) {
- ret = gpmc_probe_nand_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
- }
- }
+ for_each_child_of_node(pdev-dev.of_node, child) {
- for_each_node_by_name(child, onenand) {
- ret = gpmc_probe_onenand_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
- }
- }
+ if (!child-name)
+ continue;
- for_each_node_by_name(child, nor) {
- ret = gpmc_probe_generic_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
- }
- }
+ if (of_node_cmp(child-name, nand) == 0)
+ ret = gpmc_probe_nand_child(pdev, child);
+ else if (of_node_cmp(child-name, onenand) == 0)
+ ret = gpmc_probe_onenand_child(pdev, child);
+ else if (of_node_cmp(child-name, ethernet) == 0 ||
+of_node_cmp(child-name, nor) == 0)
+ ret = gpmc_probe_generic_child(pdev, child);
- for_each_node_by_name(child, ethernet) {
- ret = gpmc_probe_generic_child(pdev, child);
if (ret 0) {
of_node_put(child);
return ret;
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 2/2] ARM: OMAP2+: only WARN if a GPMC child probe function fail
If any of the GPMC child nodes fails, this shouldn't make the
whole gpmc_probe_dt() function to fail. It is better to just
WARN and allow other devices probe function to succeed.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1 (suggested by Jon Hunter):
- Split the search for GPMC child nodes and only warn if a
child probe fails on two different patches
- Add a warn message to report which GPMC child probe failed
arch/arm/mach-omap2/gpmc.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 6166847..6c4da12 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1533,10 +1533,9 @@ static int gpmc_probe_dt(struct platform_device *pdev)
of_node_cmp(child-name, nor) == 0)
ret = gpmc_probe_generic_child(pdev, child);
- if (ret 0) {
+ if (WARN(ret 0, %s: probing gpmc child %s failed\n,
+__func__, child-full_name))
of_node_put(child);
- return ret;
- }
}
return 0;
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/2] ARM: OMAP2+: only search for GPMC DT child nodes on probe
On 04/17/2013 11:27 PM, Jon Hunter wrote:
On 04/17/2013 03:34 PM, Javier Martinez Canillas wrote:
The GPMC DT probe function use for_each_node_by_name() to search
child device nodes of the GPMC controller. But this function does
not use the GPMC device node as the root of the search and instead
search across the complete Device Tree.
This means that any device node on the DT that is using any of the
GPMC child nodes names searched for will be returned even if they
are not connected to the GPMC, making the gpmc_probe_xxx_child()
function to fail.
Fix this by using the GPMC device node as the search root so the
search will be restricted to its children.
Reported-by: Lars Poeschel poesc...@lemonage.de
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1 (suggested by Jon Hunter):
- Split the search for GPMC child nodes and only warn if a
child probe fails on two different patches
- Don't probe all childs unnecesary if a previous matched
arch/arm/mach-omap2/gpmc.c | 33 ++---
1 files changed, 10 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ed946df..6166847 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1520,32 +1520,19 @@ static int gpmc_probe_dt(struct platform_device
*pdev)
return ret;
}
-for_each_node_by_name(child, nand) {
-ret = gpmc_probe_nand_child(pdev, child);
-if (ret 0) {
-of_node_put(child);
-return ret;
-}
-}
+for_each_child_of_node(pdev-dev.of_node, child) {
-for_each_node_by_name(child, onenand) {
-ret = gpmc_probe_onenand_child(pdev, child);
-if (ret 0) {
-of_node_put(child);
-return ret;
-}
-}
+if (!child-name)
+continue;
-for_each_node_by_name(child, nor) {
-ret = gpmc_probe_generic_child(pdev, child);
-if (ret 0) {
-of_node_put(child);
-return ret;
-}
-}
+if (of_node_cmp(child-name, nand) == 0)
+ret = gpmc_probe_nand_child(pdev, child);
+else if (of_node_cmp(child-name, onenand) == 0)
+ret = gpmc_probe_onenand_child(pdev, child);
+else if (of_node_cmp(child-name, ethernet) == 0 ||
+ of_node_cmp(child-name, nor) == 0)
+ret = gpmc_probe_generic_child(pdev, child);
-for_each_node_by_name(child, ethernet) {
-ret = gpmc_probe_generic_child(pdev, child);
if (ret 0) {
I think that we need to make sure that ret is initialised to 0 at the
beginning of the function. We should not have a case where the child
Hi Jon,
I didn't set ret to 0 at the beginning of the function since it is assigned the
return value of a previous call to of_property_read_u32(). So ret should be 0
when execution reaches the for loop.
name does not match but who knows. Actually that raises another point,
should we have an else clause at the end that WARNs on
unknown/unsupported child device?
Actually I thought about it when I was writing that patch and then I decided to
not add a WARN for that case since nothing really fail in that case.
I mean if we want to check that a DT is well formed then I think we will need to
add much more checks and I don't know if is worth it.
But I don't have a strong opinion on this so if you want I can add it an send a
v3.
of_node_put(child);
return ret;
Otherwise looks great.
Cheers
Jon
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Wed, Apr 17, 2013 at 1:14 AM, Jon Hunter jon-hun...@ti.com wrote:
On 04/16/2013 05:11 PM, Stephen Warren wrote:
On 04/16/2013 01:27 PM, Jon Hunter wrote:
On 04/16/2013 01:40 PM, Stephen Warren wrote:
On 04/15/2013 05:04 PM, Jon Hunter wrote:
...
If some driver is calling gpio_request() directly, then they will most
likely just call gpio_to_irq() when requesting the interrupt and so the
xlate function would not be called in this case (mmc drivers are a good
example). So I don't see that as being a problem. In fact that's the
benefit of this approach as AFAICT it solves this problem.
Oh. That assumption seems very fragile. What about drivers that actually
do have platform data (or DT bindings) that provide both the IRQ and
GPIO IDs, and hence don't use gpio_to_irq()? That's entirely possible.
Right. In the DT case though, if someone does provide the IRQ and GPIO
IDs then at least they would use a different xlate function. Another
option to consider would be defining the #interrupt-cells = 3 where we
would have ...
cell-#1 -- IRQ domain ID
cell-#2 -- Trigger type
cell-#3 -- GPIO ID
Then we could have a generic xlate for 3 cells that would also request
the GPIO. Again not sure if people are against a gpio being requested in
the xlate but just an idea. Or given that irq_of_parse_and_map() calls
the xlate, we could have this function call gpio_request() if the
interrupt controller is a gpio and there are 3 cells.
I rather dislike this approach since:
a) It requires changes to the DT bindings, which are already defined.
Admittedly it's backwards-compatible, but still.
b) There isn't really any need for the DT to represent this; the
GPIO+IRQ driver itself already knows which IRQ ID is which GPIO ID and
vice-versa (if the HW has such a concept), so there's no need for the DT
to contain this information. This seems like pushing Linux's internal
requirements into the design of the DT binding.
Yes, so the only alternative is to use irq_to_gpio to avoid this.
c) I have the feeling that hooking the of_xlate function for this is a
bit of an abuse of the function.
I was wondering about that. So I was grep'ing through the various xlate
implementations and found this [1]. Also you may recall that in the
of_dma_simple_xlate() we call the dma_request_channel() to allocate the
channel, which is very similar. However, I don't wish to get a
reputation as abusing APIs so would be good to know if this really is
abuse or not ;-)
Cheers
Jon
[1] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/195124
I was looking at [1] shared by Jon and come up with the following
patch that does something similar for OMAP GPIO. This has the
advantage that is local to gpio-omap instead changing gpiolib-of and
also doesn't require DT changes
But I don't want to get a reputation for abusing APIs neither :-)
Best regards,
Javier
From 23368eb72b125227fcf4b22be19ea70b4ab94556 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
Date: Wed, 17 Apr 2013 02:03:08 +0200
Subject: [PATCH 1/1] gpio/omap: add custom xlate function handler
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-omap.c | 29 -
1 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 8524ce5..77216f9 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1097,6 +1097,33 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
static const struct of_device_id omap_gpio_match[];
static void omap_gpio_init_context(struct gpio_bank *p);
+static int omap_gpio_irq_domain_xlate(struct irq_domain *d,
+ struct device_node *ctrlr,
+ const u32 *intspec, unsigned int intsize,
+ irq_hw_number_t *out_hwirq,
+ unsigned int *out_type)
+{
+ int ret;
+ struct gpio_bank *bank = d-host_data;
+ int gpio = bank-chip.base + intspec[0];
+
+ if (WARN_ON(intsize 2))
+ return -EINVAL;
+
+ ret = gpio_request_one(gpio, GPIOF_IN, ctrlr-full_name);
+ if (ret)
+ return ret;
+
+ *out_hwirq = intspec[0];
+ *out_type = (intsize 1) ? intspec[1] : IRQ_TYPE_NONE;
+
+ return 0;
+}
+
+static struct irq_domain_ops omap_gpio_irq_ops = {
+ .xlate = omap_gpio_irq_domain_xlate,
+};
+
static int omap_gpio_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
@@ -1144,7 +1171,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
bank-domain = irq_domain_add_linear(node, bank-width,
-irq_domain_simple_ops, NULL);
+omap_gpio_irq_ops, bank);
if (!bank-domain)
return -ENODEV;
--
1.7.7.6
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Sun, Apr 14, 2013 at 10:53 PM, Linus Walleij
linus.wall...@linaro.org wrote:
On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
Is the following inlined patch [1] what you were thinking that would
be the right approach?
Hi Linus, thanks a lot for your feedback.
This looks sort of OK, but I'm still struggling with the question of
what we could do to help other implementations facing the same issue.
Yes, I don't know how we can make it easier to other implementations
(besides adding the irq_request hook to irq_chip) since the logic is
GPIO controller specific.
For example I took a look to drivers/gpio/gpio-tegra.c and if I
understood correctly, the implementation for this driver should be
something like this:
diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index 414ad91..a2d5c3d 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -346,6 +346,11 @@ static int tegra_gpio_wake_enable(struct irq_data
*d, unsigned int enable)
}
#endif
+static int tegra_gpio_irq_request(struct irq_data *d)
+{
+ tegra_gpio_request(NULL, d-hwirq);
+}
+
static struct irq_chip tegra_gpio_irq_chip = {
.name = GPIO,
.irq_ack= tegra_gpio_irq_ack,
@@ -355,6 +360,7 @@ static struct irq_chip tegra_gpio_irq_chip = {
#ifdef CONFIG_PM_SLEEP
.irq_set_wake = tegra_gpio_wake_enable,
#endif
+ .irq_request= tegra_gpio_irq_request,
};
static const struct dev_pm_ops tegra_gpio_pm_ops = {
This is definitely quite similar to the omap-gpio.c change but not the same.
This is a pretty hard design pattern to properly replicate in every such
driver is it not?
H
Is indeed a hard design pattern but I couldn't figure out a more
generic way to handle this.
Maybe we could use [1] for now to solve the issue that we have with
OMAP GPIO and later when the same issue is found on other GPIO
controllers and a similar change is made on these drivers we will see
some form of pattern that emerge allowing us to make a later refactor
to reduce the code duplication.
Or do you have a better idea on how to solve this?
Yours,
Linus Walleij
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
On Sat, Apr 13, 2013 at 7:42 PM, Christoph Fritz
chf.fr...@googlemail.com wrote:
On Mon, 2013-04-01 at 22:05 +0200, Javier Martinez Canillas wrote:
On Mon, Apr 1, 2013 at 6:41 PM, Christoph Fritz
As a quick-fix (hack) I wrote directly to the registers in gpio_probe()
to enable GPIO banks. I now geht this:
[0.214630] omap_gpio_probe, 1133, CM_CLKSEL_PER 0x48005040:
0x00ff
[0.214660] omap_gpio_probe, 1136, CM_ICLKEN_PER 0x48005010:
0x0007
[0.214660] omap_gpio_probe, 1139, CM_FCLKEN_PER 0x48005000:
0x0007
And it works for me. _But_ when I do enable regulator twl4030
(CONFIG_REGULATOR_TWL4030=y) in my config these registers get reset:
[2.935455] smsc911x_open, 1537, CM_CLKSEL_PER 0x48005040: 0x00ff
[2.942291] smsc911x_open, 1540, CM_ICLKEN_PER 0x48005010: 0x00040fff
[2.949066] smsc911x_open, 1543, CM_FCLKEN_PER 0x48005000: 0x
And the IRQ source for the network chip (smsc911x) is disabled :-(
Do you have any idea how to (quick) fix this?
A quick hack is to call gpio_request() explicitly before calling to
irq_set_type() is made.
I've this patch just to make it work until we find a clean solution:
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 90c15ee..d594e1d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -14,6 +14,7 @@
*/
#undef DEBUG
+#include linux/gpio.h
#include linux/irq.h
#include linux/kernel.h
#include linux/init.h
@@ -1528,6 +1529,11 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
+ ret = gpio_request_one(176, GPIOF_IN, smsc911x irq);
+ if (ret) {
+ pr_err(Failed to request IRQ GPIO%d\n, 176);
+ return ret;
+ }
+
for_each_node_by_name(child, nand) {
ret = gpmc_probe_nand_child(pdev, child);
if (ret 0) {
This solves the issue of the non-initialized GPIO bank before that
makes the kernel to hang. Since I've to configure the IRQ polarity as
active low level-sensitive on my board and the flags are not set by
the IRQ core, I've another ugly hack that forces this:
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc
index da5cc9a..27e46f9 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -2390,6 +2390,9 @@ static int smsc911x_drv_probe(struct
platform_device *pdev)
pdata = netdev_priv(dev);
dev-irq = irq_res-start;
-irq_flags = irq_res-flags IRQF_TRIGGER_MASK;
+ irq_flags = IRQF_TRIGGER_LOW;
pdata-ioaddr = ioremap_nocache(res-start, res_size);
pdata-dev = dev;
Thanks
-- Christoph
I hope to find some time this week to work on this and at least find a
solution for the second issue (IORESOURCE_IRQ struct resource flags
not being set).
Any updates on this issue?
Yes, my last approach to solve the IRQ flags not saved on the
IORESOURCE_IRQ struct resource issue is to add a new
irq_get_trigger_type() function to get the edge/level flags from an
IRQ number and use that function on the smsc911x driver probe function
to get the IRQ flags.
The patch-set is composed of these patches:
[PATCH v2 1/2] genirq: add function to get IRQ edge/level flags [1]
[PATCH 2/2] net: smsc911x: get IRQ flags from chip if not present in
IORESOURCE_IRQ [2]
and the cover letter is this [3]
It would be great if you can test these patches and give some feedback.
For me it works when doing this in the device tree:
+omap3_pmx_wkup {
+ pinctrl-names = default;
+
+ lan9221_pins: pinmux_lan9221_pins {
+ pinctrl-single,pins =
+ 0x5A 0x104 /* gpio_129, INPUT | MODE4 */
+ ;
+ };
+};
+
SNIP
+ lan9221@1500 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 0x1500 0x400;
If I understood correctly your smsc ethernet chip is connected to the
OMAP through the GPMC, then you should use a chip-select, base address
and size instead of the physical address and size.
Do you have commit 5330dc161 (ARM: OMAP2+: Add GPMC DT support for
Ethernet child nodes) already on your tree? [4]
+ phy-mode = mii;
+ interrupt-parent = gpio5;
+ interrupts = 1 0x2; /* gpio_129, trigger: falling-edge */
I'm confused here, do you get the IRQ_TYPE_EDGE_FALLING (0x2) trigger
type flag on the smsc911x driver probe function?
+ reg-io-width = 4;
+ vdd33a-supply = reg_vcc3;
+ vddvario-supply = reg_vcc3;
+ pinctrl-names = default;
+ pinctrl-0 = lan9221_pins;
+ };
but in arch/arm/mach-omap2/gpmc.c gpmc_probe_dt() I still need this
hack:
+ ret = gpio_request_one(129, GPIOF_IN, lan9221 irq);
+ if (ret
Re: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
On Sat, Apr 13, 2013 at 8:59 PM, Christoph Fritz
chf.fr...@googlemail.com wrote:
On Sat, 2013-04-13 at 20:30 +0200, Javier Martinez Canillas wrote:
On Sat, Apr 13, 2013 at 7:42 PM, Christoph Fritz
chf.fr...@googlemail.com wrote:
Yes, my last approach to solve the IRQ flags not saved on the
IORESOURCE_IRQ struct resource issue is to add a new
irq_get_trigger_type() function to get the edge/level flags from an
IRQ number and use that function on the smsc911x driver probe function
to get the IRQ flags.
The patch-set is composed of these patches:
[PATCH v2 1/2] genirq: add function to get IRQ edge/level flags [1]
[PATCH 2/2] net: smsc911x: get IRQ flags from chip if not present in
IORESOURCE_IRQ [2]
and the cover letter is this [3]
It would be great if you can test these patches and give some feedback.
For me it works when doing this in the device tree:
+omap3_pmx_wkup {
+ pinctrl-names = default;
+
+ lan9221_pins: pinmux_lan9221_pins {
+ pinctrl-single,pins =
+ 0x5A 0x104 /* gpio_129, INPUT | MODE4 */
+ ;
+ };
+};
+
SNIP
+ lan9221@1500 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 0x1500 0x400;
If I understood correctly your smsc ethernet chip is connected to the
OMAP through the GPMC, then you should use a chip-select, base address
and size instead of the physical address and size.
Yes, it's connected with GPMC.
Do you have commit 5330dc161 (ARM: OMAP2+: Add GPMC DT support for
Ethernet child nodes) already on your tree? [4]
No I haven't.
In that case you should have that commit on your tree. But the GPMC
driver has changed a lot for 3.9 and 3.10, so I recommend you to base
your work on linux-next that has the latest changes.
And then you will need something like this on your DT (in this example
is using the chip-select 5 but adjust according to your board):
gpmc: gpmc@6e00 {
compatible = ti,omap3430-gpmc;
ti,hwmods = gpmc;
reg = 0x6e00 0x1000;
interrupts = 20;
gpmc,num-cs = 8;
gpmc,num-waitpins = 4;
#address-cells = 2;
#size-cells = 1;
ranges = 5 0 0x2c00 0x100;
ethernet@5,0 {
pinctrl-names = default;
pinctrl-0 = lan9221_pins;
compatible = smsc,lan9221, smsc,lan9115;
reg = 5 0 0xff;
bank-width = 2;
gpmc,mux-add-data;
gpmc,cs-on-ns = 0;
gpmc,cs-rd-off-ns = 186;
gpmc,cs-wr-off-ns = 186;
gpmc,adv-on-ns = 12;
gpmc,adv-rd-off-ns = 48;
gpmc,adv-wr-off-ns = 48;
gpmc,oe-on-ns = 54;
gpmc,oe-off-ns = 168;
gpmc,we-on-ns = 54;
gpmc,we-off-ns = 168;
gpmc,rd-cycle-ns = 186;
gpmc,wr-cycle-ns = 186;
gpmc,access-ns = 114;
gpmc,page-burst-access-ns = 6;
gpmc,bus-turnaround-ns = 12;
gpmc,cycle2cycle-delay-ns = 18;
gpmc,wr-data-mux-bus-ns = 90;
gpmc,wr-access-ns = 186;
gpmc,cycle2cycle-samecsen;
gpmc,cycle2cycle-diffcsen;
interrupt-parent = gpio5;
interrupts = 1 0x2;
reg-io-width = 4;
vdd33a-supply = reg_vcc3;
vmmc_aux-supply = vdd33a;
vddvario-supply = reg_vcc3;
};
};
+ phy-mode = mii;
+ interrupt-parent = gpio5;
+ interrupts = 1 0x2; /* gpio_129, trigger: falling-edge
*/
I'm confused here, do you get the IRQ_TYPE_EDGE_FALLING (0x2) trigger
type flag on the smsc911x driver probe function?
I added printks for irq_res-flags and irq_flags:
[1.259857] smsc911x_drv_probe, 2396, irq_res-flags 0x0400
[1.266113] smsc911x_drv_probe, 2397, irq_flags 0x
So the answer is no. But weird that the smsc911x works nevertheless.
Yes, that's what I thought. You will need patch [1] and [2] to allow
smsc911x driver to get the GPIO-IRQ trigger type flags.
With those patches + linux-next + the device node I posted above +
your gpio_request_one() hack on gpmc_probe_dt() should be enough to
have your smsc ethernet chip working on your board.
+ reg-io-width = 4;
+ vdd33a-supply = reg_vcc3;
+ vddvario-supply = reg_vcc3;
+ pinctrl-names = default;
+ pinctrl-0 = lan9221_pins;
+ };
but in arch/arm/mach-omap2/gpmc.c gpmc_probe_dt() I still need this
hack:
+ ret = gpio_request_one(129, GPIOF_IN, lan9221 irq);
+ if (ret) {
+ pr_err(Failed to request IRQ GPIO%d\n, 129);
+ return ret;
+ }
Yes, this hack is still needed until
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Fri, Apr 12, 2013 at 12:47 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 04/11/2013 04:16 PM, Linus Walleij wrote:
On Thu, Apr 11, 2013 at 10:30 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 04/10/2013 03:28 PM, Linus Walleij wrote:
So the only reason I'm rambing on about this is that it breaks the
I'm not sure I understand this paragraph; what is it in the line above.
If it is this patch, then should breaks be re-establishes?
No I'm replying to Javier Martinez Canillas mail in this thread:
http://marc.info/?l=linux-arm-kernelm=136334655902407w=2
which is stating a question to grand, and contains the below
hunk:
+static int gpio_irq_request(struct irq_data *d)
+{
+ struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
+
+ return gpio_request(irq_to_gpio(bank, d-irq), gpio-irq);
+}
irq_to_gpio(). Notice that. not my_funny_driver_irq_to_gpio().
OK, right. sorry for being so confused/confusing.
Yes, that code should certainly call e.g. omap_gpio__irq_to_gpio() not
irq_to_gpio(). Probably gpio_irq_request() wants renaming to something
more like omap_gpio__irq_request() too, so the names don't look like
they'd clash with global functions. (__ added for clarity but probably
only one _ at a time)
Stephen, Linus,
Is the following inlined patch [1] what you were thinking that would
be the right approach?
With this patch an explicit call to call gpio_request() before a call
to chip-irq_set_type() is needed. I've tested both with DT and
without DT where a explicit call to gpio_request() is made and it
works in both cases. So it shouldn't have a functional change for
non-DT cases as far as I know.
If you agree with [1] then I'll split in two patches (one that adds
the irq_request function pointer to irq_chip and another one that adds
the implementation for gpio-omap) and send as a patch-set. I just
thought that it would be easier for you if I posted here an inlined
patch so you could have context.
Thanks a lot for your feedback and best regards,
Javier
[1]
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 685e850..e035e64 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -811,6 +811,13 @@ static void gpio_unmask_irq(struct irq_data *d)
spin_unlock_irqrestore(bank-lock, flags);
}
+static int omap_gpio_irq_request(struct irq_data *d)
+{
+ struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
+
+ return omap_gpio_request(bank-chip, d-hwirq);
+}
+
static struct irq_chip gpio_irq_chip = {
.name = GPIO,
.irq_shutdown = gpio_irq_shutdown,
@@ -819,6 +826,7 @@ static struct irq_chip gpio_irq_chip = {
.irq_unmask = gpio_unmask_irq,
.irq_set_type = gpio_irq_type,
.irq_set_wake = gpio_wake_enable,
+ .irq_request= omap_gpio_irq_request,
};
/*-*/
@@ -1028,6 +1036,7 @@ omap_mpuio_alloc_gc(struct gpio_bank *bank,
unsigned int irq_start,
ct-chip.irq_mask = irq_gc_mask_set_bit;
ct-chip.irq_unmask = irq_gc_mask_clr_bit;
ct-chip.irq_set_type = gpio_irq_type;
+ ct-chip.irq_request = omap_gpio_irq_request;
if (bank-regs-wkup_en)
ct-chip.irq_set_wake = gpio_wake_enable,
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 0e8e3a6..85596cc 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -303,6 +303,7 @@ struct irq_chip {
void(*irq_shutdown)(struct irq_data *data);
void(*irq_enable)(struct irq_data *data);
void(*irq_disable)(struct irq_data *data);
+ int (*irq_request)(struct irq_data *data);
void(*irq_ack)(struct irq_data *data);
void(*irq_mask)(struct irq_data *data);
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index fa17855..a4bd4f7 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -588,6 +588,12 @@ int __irq_set_trigger(struct irq_desc *desc,
unsigned int irq,
unmask = 1;
}
+ if (chip-irq_request) {
+ ret = chip-irq_request(desc-irq_data);
+ if (ret)
+ return ret;
+ }
+
/* caller masked out all except trigger mode flags */
ret = chip-irq_set_type(desc-irq_data, flags);
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/2] net: smsc911x: get IRQ flags from chip if not present in IORESOURCE_IRQ
Hello,
This is the second attempt to solve the issue that IRQ flags when
defined using Device Trees, are not passed to drivers that try
to obtain them from a IORESOURCE_IRQ struct resource.
According to
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the #interrupt-cells property of an interrupt-controller is used
to define the number of cells needed to specify a single interrupt.
A commonly used variant is two cell on which #interrupt-cells = 2
and the first cell defines the index of the interrupt in the controller
while the second cell is used to specify any of the following flags:
- bits[3:0] trigger type and level flags
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
An example of an interrupt controller which use the two cell format is
the OMAP GPIO controller that allows GPIO lines to be used as IRQ
(Documentation/devicetree/bindings/gpio/gpio-omap.txt)
But setting #interrupt-cells = 2 on the OMAP GPIO device node and
specifying the GPIO-IRQ type and level flags on the second cell does not
store this value on the populated IORESOURCE_IRQ struct resource.
This is because when using an IRQ from an interrupt controller and
setting both cells (e.g:)
interrupt-parent = gpio6;
interrupts = 16 8;
A call to of_irq_to_resource() is made and this function calls to
irq_of_parse_and_map_type() to get the virtual IRQ mapped to the real
index for this interrupt controller. This IRQ number is populated on
the struct resource:
int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
{
int irq = irq_of_parse_and_map(dev, index);
..
r-start = r-end = irq;
}
irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
the correct xlate function handler according to #interrupt-cells
(irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
irq_set_irq_type() to set the IRQ type.
But the type is never returned so it can't be saved on the IRQ struct
resource flags member.
This means that drivers that want to get the IRQ edge/level flags
defined in the Device Tree from a struct resource will not be able
to get it.
Drivers can get the IRQ flags by using irq_get_irq_data(irq) and
irqd_get_trigger_type(irq_data) but this will unnecessary expose
irq_data to callers and also is more error prone.
This problem was first discussed here [1] and a first approach to
solved was discussed here [2]. This was by saving the IRQ edge/level
flags on the struct resource but the feedback was that IORESOURCE_IRQ
is not supposed to be used with DT but with architectures supporting ACPI/PnP.
So, this second patch-set is composed of the following patches:
[PATCH 1/2] genirq: add function to get IRQ edge/level flags
[PATCH 2/2] net: smsc911x: get IRQ flags from chip if not present in
IORESOURCE_IRQ
And adds an irq_get_trigger_type() function to obtain the edge/level
flags for an IRQ and use it as a fallback if a driver does not find
the flags on an IORESOURCE_IRQ struct resource.
Thanks a lot and best regards,
Javier
[1]: https://patchwork.kernel.org/patch/2194911/
[2]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/96908
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] genirq: add function to get IRQ edge/level flags
According to
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the #interrupt-cells property of an interrupt-controller is used
to define the number of cells needed to specify a single interrupt.
A commonly used variant is two cell on which #interrupt-cells = 2
and the first cell defines the index of the interrupt in the controller
while the second cell is used to specify any of the following flags:
- bits[3:0] trigger type and level flags
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
An example of an interrupt controller which use the two cell format is
the OMAP GPIO controller that allows GPIO lines to be used as IRQ
(Documentation/devicetree/bindings/gpio/gpio-omap.txt)
But setting #interrupt-cells = 2 on the OMAP GPIO device node and
specifying the GPIO-IRQ type and level flags on the second cell does not
store this value on the populated IORESOURCE_IRQ struct resource.
This is because when using an IRQ from an interrupt controller and
setting both cells (e.g:)
interrupt-parent = gpio6;
interrupts = 16 8;
A call to of_irq_to_resource() is made and this function calls
irq_of_parse_and_map_type() to get the virtual IRQ mapped to the real
index for this interrupt controller. This IRQ number is populated on
the struct resource:
int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
{
int irq = irq_of_parse_and_map(dev, index);
..
r-start = r-end = irq;
}
irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
the correct xlate function handler according to #interrupt-cells
(irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
irq_set_irq_type() to set the IRQ type.
But the type is never returned so it can't be saved on the IRQ struct
resource flags member.
This means that drivers that want to get the IRQ edge/level flags
defined in the Device Tree from a struct resource will not be able
to get it.
Drivers can get the IRQ flags by using irq_get_irq_data(irq) and
irqd_get_trigger_type(irq_data) but this will unnecessary expose
irq_data to callers and also is more error prone.
So, is better to add 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..93231cb 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 ? d-state_use_accessors IRQD_TRIGGER_MASK : 0;
+}
+
int __irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
struct module *owner);
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/2] net: smsc911x: get IRQ flags from chip if not present in IORESOURCE_IRQ
When defining an IRQ trigger type and level flags from a Device Tree a call to of_irq_to_resource() is made to parse the interrupts property cells and return a struct resource. But the flags are not saved on this struct resource which means that drivers that try to obtain this information from an IORESOURCE_IRQ will not be able to get it. So, is more safe to fallback and query this information from the irq chip directly if it was not found on the struct resource. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- drivers/net/ethernet/smsc/smsc911x.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c index da5cc9a..3d535b3 100644 --- a/drivers/net/ethernet/smsc/smsc911x.c +++ b/drivers/net/ethernet/smsc/smsc911x.c @@ -2390,6 +2390,10 @@ static int smsc911x_drv_probe(struct platform_device *pdev) pdata = netdev_priv(dev); dev-irq = irq_res-start; irq_flags = irq_res-flags IRQF_TRIGGER_MASK; + + if (!irq_flags) + irq_flags = irq_get_trigger_type(dev-irq); + pdata-ioaddr = ioremap_nocache(res-start, res_size); pdata-dev = dev; -- 1.7.7.6 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] genirq: add function to get IRQ edge/level flags
On 04/12/2013 11:56 PM, Stephen Warren wrote:
On 04/12/2013 12:05 PM, Javier Martinez Canillas wrote:
...
So, is better to add an irq_get_trigger_type() function to obtain
the edge/level flags for an IRQ.
diff --git a/include/linux/irq.h b/include/linux/irq.h
+static inline u32 irq_get_trigger_type(unsigned int irq)
+{
+struct irq_data *d = irq_get_irq_data(irq);
+return d ? d-state_use_accessors IRQD_TRIGGER_MASK : 0;
Should the direct access to d-state_use_accessors be replaced with a
call to irqd_get_trigger_type()? Perhaps since this is inside the IRQ
code header, there's no need to use the accessor function?
Yes, it's better to use irqd_get_trigger_type() instead of a direct access to
d-state_use_accessors since that function is inline so it should be the same
performance wise and it will be easier to maintain.
I'll send a v2 changing that.
Thanks a lot and best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 1/2] genirq: add function to get IRQ edge/level flags
According to
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the #interrupt-cells property of an interrupt-controller is used
to define the number of cells needed to specify a single interrupt.
A commonly used variant is two cell on which #interrupt-cells = 2
and the first cell defines the index of the interrupt in the controller
while the second cell is used to specify any of the following flags:
- bits[3:0] trigger type and level flags
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
An example of an interrupt controller which use the two cell format is
the OMAP GPIO controller that allows GPIO lines to be used as IRQ
(Documentation/devicetree/bindings/gpio/gpio-omap.txt)
But setting #interrupt-cells = 2 on the OMAP GPIO device node and
specifying the GPIO-IRQ type and level flags on the second cell does not
store this value on the populated IORESOURCE_IRQ struct resource.
This is because when using an IRQ from an interrupt controller and
setting both cells (e.g:)
interrupt-parent = gpio6;
interrupts = 16 8;
A call to of_irq_to_resource() is made and this function calls
irq_of_parse_and_map_type() to get the virtual IRQ mapped to the real
index for this interrupt controller. This IRQ number is populated on
the struct resource:
int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
{
int irq = irq_of_parse_and_map(dev, index);
..
r-start = r-end = irq;
}
irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
the correct xlate function handler according to #interrupt-cells
(irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
irq_set_irq_type() to set the IRQ type.
But the type is never returned so it can't be saved on the IRQ struct
resource flags member.
This means that drivers that want to get the IRQ edge/level flags
defined in the Device Tree from a struct resource will not be able
to get it.
Drivers can get the IRQ flags by using irq_get_irq_data(irq) and
irqd_get_trigger_type(irq_data) but this will unnecessary expose
irq_data to callers and also is more error prone.
So, is better to add 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
---
Changes since v1:
- use irqd_get_trigger_type() instead of a direct access to
d-state_use_accessors as suggested by Stephen Warren.
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
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Fri, Apr 12, 2013 at 12:16 AM, Linus Walleij
linus.wall...@linaro.org wrote:
On Thu, Apr 11, 2013 at 10:30 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 04/10/2013 03:28 PM, Linus Walleij wrote:
So the only reason I'm rambing on about this is that it breaks the
I'm not sure I understand this paragraph; what is it in the line above.
If it is this patch, then should breaks be re-establishes?
No I'm replying to Javier Martinez Canillas mail in this thread:
http://marc.info/?l=linux-arm-kernelm=136334655902407w=2
which is stating a question to grand, and contains the below
hunk:
+static int gpio_irq_request(struct irq_data *d)
+{
+ struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
+
+ return gpio_request(irq_to_gpio(bank, d-irq), gpio-irq);
+}
irq_to_gpio(). Notice that. not my_funny_driver_irq_to_gpio().
It's the same thing you mention below:
If I recall the patch I'm replying to correctly, the idea was to add an
IRQ request operation that would (internally to the GPIO/IRQ driver
itself) map IRQ-GPIO, and call gpio_request(). That would then prevent
exactly the situation you mention above.
So the above does not look like it's internal to the driver does it?
I think this is irq_to_gpio sneaking back in, and requiring that every
driver of this sort follow the same design pattern. And then maybe
you see my persistance ... are we talking about different things?
So I'd be happy with something local to the driver, foo_irq_to_gpio()
and that we also back out a bit and see what the subsystem can do
to avoid this kind of code having to be duplicated everywhere, that's
all.
Hi Linus,
Thanks a lot for your explanation. I didn't know that irq_to_gpio()
was being deprecated and we shouldn't use anymore. Now from this
thread discussion I understand the reasons for this decision.
I'll read the whole thread again and try to implement something that
is local to the gpio-omap driver instead using irq_to_gpio().
Besides using a controller specific mapping instead of irq_to_gpio(),
do you think that is a good idea to add a new irq_request function
pointer to struct irq_chip?
The idea is that GPIO controller drivers can call gpio_request() and
enabling the GPIO bank module before a call to request_irq() is made.
Or do you think that is better to implement the DT gpio hogs that you
were suggesting?
I really want to find a solution to this since currently we can't use
any device that uses an GPIO line as an IRQ on OMAP based boards.
Yours,
Linus Walleij
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring robherri...@gmail.com wrote: On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote: On 04/09/2013 12:16 AM, Stephen Warren wrote: On 04/08/2013 04:05 PM, Rob Herring wrote: On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote: According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt the #interrupt-cells property of an interrupt-controller is used to define the number of cells needed to specify a single interrupt. ... But the type is never returned so it can't be saved on the IRQ struct resource flags member. This means that drivers that need the IRQ type/level flags defined in the DT won't be able to get it. But the interrupt controllers that need the information should be able to get to it via irqd_get_trigger_type. What problem exactly are you trying to fix? What driver would use this? FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking back, I'm not sure if that was the right thing or whether I should have sent this same patch:-) Hi Stephen, I'm glad you agree :-) I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags for the IRQ with irqd_get_trigger_type() but I prefer $subject because: irqd_get_trigger_type probably is not meant for outside of irqchips. Creating an irq_get_irq_type function which takes an irq number would be the right function as that does not expose struct irq_data. Ok, I can add an irqd_get_trigger_type() that just return the flags to the caller without exposing the struct irq_data and using it on the SMSC 911x driver instead using struct resource *irq_res-flags I hope networking folks understand why this change is needed in this driver to get the type/level flags for an IRQ defined on a DT... a) This works in the non-DT case with board files and filling the resources from platform data in arch/arm/mach-omap2/gpmc-smsc911x.c. So this is definitely a bug on the DT core. And hackery/abuse like this: arch/arm/mach-omap2/board-3630sdp.c:32:.flags = GPMC_MUX_ADD_DATA | IORESOURCE_IRQ_LOWLEVEL, b) I don't see why of_irq_to_resource() should discard the type/level flags when filling the IORESOURCE_IRQ if it was specified on the DT. c) We will have to change all drivers that expect to get the IRQ type flags from a IORESOURCE_IRQ struct resource. I'm not convinced that is a high number of drivers. Nearly all the occurrences of IORESOURCE_IRQ_ in drivers/ are for ISA (acpi/pnp) and drivers for ISA devices. If IORESOURCE_IRQ is just supposed to be used for ISA devices drivers that use ACPI/PnP instead DT, then of_irq_to_resource() callers should just use irq_of_parse_and_map() that returns the virtual IRQ number for an index within a controller instead of a struct resource. In fact I wonder what's the point to have an of_irq_to_resource() function at all if IORESOURCE_IRQ is not supposed to be used for devices connected through dumb buses that need a DT and the struct resource will only hold the mapped virtual IRQ number and no the IRQ flags. Rob Best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
On Tue, Apr 9, 2013 at 10:26 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring robherri...@gmail.com wrote: On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote: On 04/09/2013 12:16 AM, Stephen Warren wrote: On 04/08/2013 04:05 PM, Rob Herring wrote: On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote: According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt the #interrupt-cells property of an interrupt-controller is used to define the number of cells needed to specify a single interrupt. ... But the type is never returned so it can't be saved on the IRQ struct resource flags member. This means that drivers that need the IRQ type/level flags defined in the DT won't be able to get it. But the interrupt controllers that need the information should be able to get to it via irqd_get_trigger_type. What problem exactly are you trying to fix? What driver would use this? FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking back, I'm not sure if that was the right thing or whether I should have sent this same patch:-) Hi Stephen, I'm glad you agree :-) I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags for the IRQ with irqd_get_trigger_type() but I prefer $subject because: irqd_get_trigger_type probably is not meant for outside of irqchips. Creating an irq_get_irq_type function which takes an irq number would be the right function as that does not expose struct irq_data. Ok, I can add an irqd_get_trigger_type() that just return the flags to I meant irq_get_irq_type() of course. Best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
On 04/09/2013 12:05 AM, Rob Herring wrote:
On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
According to
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the #interrupt-cells property of an interrupt-controller is used
to define the number of cells needed to specify a single interrupt.
A commonly used variant is two cell on which #interrupt-cells = 2
and the first cell defines the index of the interrupt in the controller
and the second cell is used to specify any of the following flags:
- bits[3:0] trigger type and level flags
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
An example of an interrupt controller which use the two cell format is
the OMAP GPIO controller that allows GPIO lines to be used as IRQ
(Documentation/devicetree/bindings/gpio/gpio-omap.txt)
But setting #interrupt-cells = 2 on the OMAP GPIO device node and
specifying the GPIO-IRQ type and level flags on the second cell does not
store this value on the populated IORESOURCE_IRQ struct resource.
This is because when using an IRQ from an interrupt controller and
setting both cells (e.g:)
interrupt-parent = gpio6;
interrupts = 16 8;
A call to of_irq_to_resource() is made and this function calls to
irq_of_parse_and_map_type() to get the virtual IRQ mapped to the real
index for this interrupt controller. This IRQ number is populated on
the struct resource:
int of_irq_to_resource(struct device_node *dev, int index, struct resource
*r)
{
int irq = irq_of_parse_and_map(dev, index);
..
r-start = r-end = irq;
}
irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
the correct xlate function handler according to #interrupt-cells
(irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
irq_set_irq_type() to set the IRQ type.
But the type is never returned so it can't be saved on the IRQ struct
resource flags member.
This means that drivers that need the IRQ type/level flags defined in
the DT won't be able to get it.
But the interrupt controllers that need the information should be able
to get to it via irqd_get_trigger_type. What problem exactly are you
trying to fix? What driver would use this?
Yes but this is not about the interrupt controller wanting this information but
a device driver that is using the IORESOURCE_IRQ struct resource that has the
information about the virtual IRQ associated with a GPIO-IRQ.
The driver doesn't know neither care if its IRQ line is connected to a line of
an real IRQ controller or to a GPIO controller that allows a GPIO line to be
used as an IRQ.
My understanding of the IORESOURCE_IRQ_xxx (and DMA) bits are they are
ISA specific and therefore should not be used on non-ISA buses.
Many TI OMAP2+ SoC based boards have an SMSC LAN911x/912x controller
(drivers/net/ethernet/smsc/smsc911x.c) that is connected to the OMAP processor
through its General-Purpose Memory Controller (GPMC) and this LAN driver obtain
its IRQ and I/O address space from a struct resource IORESOURCE_IRQ and
IORESOURCE_MEM respectively, that is filled by the DeviceTree core.
It does this:
irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
irq_flags = irq_res-flags IRQF_TRIGGER_MASK;
Since of_irq_to_resource() doesn't fill the trigger/level flags on the
IORESOURCE_IRQ struct resource, irq_flags will always be 0 regarding the value
specified on the second cell of the interrupts DT property.
A previous discussion about this can be found here [1].
Rob
Thanks a lot and best regards,
Javier
[1]: https://patchwork.kernel.org/patch/2194911/
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
On 04/09/2013 12:16 AM, Stephen Warren wrote: On 04/08/2013 04:05 PM, Rob Herring wrote: On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote: According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt the #interrupt-cells property of an interrupt-controller is used to define the number of cells needed to specify a single interrupt. ... But the type is never returned so it can't be saved on the IRQ struct resource flags member. This means that drivers that need the IRQ type/level flags defined in the DT won't be able to get it. But the interrupt controllers that need the information should be able to get to it via irqd_get_trigger_type. What problem exactly are you trying to fix? What driver would use this? FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking back, I'm not sure if that was the right thing or whether I should have sent this same patch:-) Hi Stephen, I'm glad you agree :-) I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags for the IRQ with irqd_get_trigger_type() but I prefer $subject because: a) This works in the non-DT case with board files and filling the resources from platform data in arch/arm/mach-omap2/gpmc-smsc911x.c. So this is definitely a bug on the DT core. b) I don't see why of_irq_to_resource() should discard the type/level flags when filling the IORESOURCE_IRQ if it was specified on the DT. c) We will have to change all drivers that expect to get the IRQ type flags from a IORESOURCE_IRQ struct resource. Thanks a lot and best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
According to
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the #interrupt-cells property of an interrupt-controller is used
to define the number of cells needed to specify a single interrupt.
A commonly used variant is two cell on which #interrupt-cells = 2
and the first cell defines the index of the interrupt in the controller
and the second cell is used to specify any of the following flags:
- bits[3:0] trigger type and level flags
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
An example of an interrupt controller which use the two cell format is
the OMAP GPIO controller that allows GPIO lines to be used as IRQ
(Documentation/devicetree/bindings/gpio/gpio-omap.txt)
But setting #interrupt-cells = 2 on the OMAP GPIO device node and
specifying the GPIO-IRQ type and level flags on the second cell does not
store this value on the populated IORESOURCE_IRQ struct resource.
This is because when using an IRQ from an interrupt controller and
setting both cells (e.g:)
interrupt-parent = gpio6;
interrupts = 16 8;
A call to of_irq_to_resource() is made and this function calls to
irq_of_parse_and_map_type() to get the virtual IRQ mapped to the real
index for this interrupt controller. This IRQ number is populated on
the struct resource:
int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
{
int irq = irq_of_parse_and_map(dev, index);
..
r-start = r-end = irq;
}
irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
the correct xlate function handler according to #interrupt-cells
(irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
irq_set_irq_type() to set the IRQ type.
But the type is never returned so it can't be saved on the IRQ struct
resource flags member.
This means that drivers that need the IRQ type/level flags defined in
the DT won't be able to get it.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/of/irq.c | 30 --
include/linux/of_irq.h |4
kernel/irq/irqdomain.c | 14 --
3 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index a3c1c5a..6f6aa75 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -27,22 +27,39 @@
#include linux/slab.h
/**
- * irq_of_parse_and_map - Parse and map an interrupt into linux virq space
+ * irq_of_parse_and_map_type - Parse and map an interrupt into linux virq space
* @device: Device node of the device whose interrupt is to be mapped
* @index: Index of the interrupt to map
+ * @type: Interrupt trigger type and level flags filled by this function
*
* This function is a wrapper that chains of_irq_map_one() and
* irq_create_of_mapping() to make things easier to callers
*/
-unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
+static unsigned int irq_of_parse_and_map_type(struct device_node *dev,
+ int index, unsigned int *type)
{
struct of_irq oirq;
+ unsigned int virq;
if (of_irq_map_one(dev, index, oirq))
return 0;
- return irq_create_of_mapping(oirq.controller, oirq.specifier,
-oirq.size);
+ virq = irq_create_of_mapping_type(oirq.controller, oirq.specifier,
+ oirq.size, type);
+ return virq;
+}
+
+/**
+ * irq_of_parse_and_map - Parse and map an interrupt into linux virq space
+ * @device: Device node of the device whose interrupt is to be mapped
+ * @index: Index of the interrupt to map
+ *
+ * This function is a wrapper of irq_of_parse_and_map_type() when the IRQ
+ * type and level flags are not needed
+ */
+unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
+{
+ return irq_of_parse_and_map_type(dev, index, NULL);
}
EXPORT_SYMBOL_GPL(irq_of_parse_and_map);
@@ -338,7 +355,8 @@ EXPORT_SYMBOL_GPL(of_irq_map_one);
*/
int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
{
- int irq = irq_of_parse_and_map(dev, index);
+ int type = IRQ_TYPE_NONE;
+ int irq = irq_of_parse_and_map_type(dev, index, type);
/* Only dereference the resource if both the
* resource and the irq are valid. */
@@ -353,7 +371,7 @@ int of_irq_to_resource(struct device_node *dev, int index,
struct resource *r)
name);
r-start = r-end = irq;
- r-flags = IORESOURCE_IRQ;
+ r-flags = (IORESOURCE_IRQ | type);
r-name = name ? name : dev-full_name;
}
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index 535cecf..98aec57 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -66,6 +66,10
[RFC 1/1] of/irq: store IRQ trigger/level in struct resource flags
According to
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the #interrupt-cells property of an interrupt-controller is used
to define the number of cells needed to specify a single interrupt.
A commonly used variant is two cell on which #interrupt-cells = 2
and the first cell defines the index of the interrupt in the controller
and the second cell is used to specify any of the following flags:
- bits[3:0] trigger type and level flags
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
An example of an interrupt controller which use the two cell format is
the OMAP GPIO controller that allows GPIO lines to be used as IRQ
(Documentation/devicetree/bindings/gpio/gpio-omap.txt)
But setting #interrupt-cells = 2 on the OMAP GPIO device node and
specifying the GPIO-IRQ type and level flags on the second cell does not
store this value on the populated IORESOURCE_IRQ struct resource.
This is because when using an IRQ from an interrupt controller and
setting both cells (e.g:)
interrupt-parent = gpio6;
interrupts = 16 8;
A call to of_irq_to_resource() is made and this function calls to
irq_of_parse_and_map_type() to get the virtual IRQ mapped to the real
index for this interrupt controller. This IRQ number is populated on
the struct resource:
int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
{
int irq = irq_of_parse_and_map(dev, index);
..
r-start = r-end = irq;
}
irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
the correct xlate function handler according to #interrupt-cells
(irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
irq_set_irq_type() to set the IRQ type.
But the type is never returned so it can't be saved on the IRQ struct
resource flags member.
This means that drivers that need the IRQ type/level flags defined in
the DT won't be able to get it.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Hello,
This is a RFC since I don't know if this is the best approach to solve
the issue. I've tested this patch a TI OMAP3 DM3735 SoC board and his
working correctly both with and without DeviceTrees.
I've added an indirection level to keep the patch as small as possible
instead of changing dozens of files to update the callers. I think this
make it easier to review the change.
If you agree with this patch I can send a v2 that juse add a type param
to irq_of_parse_and_map() and irq_create_of_mapping(), updating all the
callers of this functions as well.
Thanks a lot and best regards,
drivers/of/irq.c | 30 --
include/linux/of_irq.h |4
kernel/irq/irqdomain.c | 14 --
3 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index a3c1c5a..6f6aa75 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -27,22 +27,39 @@
#include linux/slab.h
/**
- * irq_of_parse_and_map - Parse and map an interrupt into linux virq space
+ * irq_of_parse_and_map_type - Parse and map an interrupt into linux virq space
* @device: Device node of the device whose interrupt is to be mapped
* @index: Index of the interrupt to map
+ * @type: Interrupt trigger type and level flags filled by this function
*
* This function is a wrapper that chains of_irq_map_one() and
* irq_create_of_mapping() to make things easier to callers
*/
-unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
+static unsigned int irq_of_parse_and_map_type(struct device_node *dev,
+ int index, unsigned int *type)
{
struct of_irq oirq;
+ unsigned int virq;
if (of_irq_map_one(dev, index, oirq))
return 0;
- return irq_create_of_mapping(oirq.controller, oirq.specifier,
-oirq.size);
+ virq = irq_create_of_mapping_type(oirq.controller, oirq.specifier,
+ oirq.size, type);
+ return virq;
+}
+
+/**
+ * irq_of_parse_and_map - Parse and map an interrupt into linux virq space
+ * @device: Device node of the device whose interrupt is to be mapped
+ * @index: Index of the interrupt to map
+ *
+ * This function is a wrapper of irq_of_parse_and_map_type() when the IRQ
+ * type and level flags are not needed
+ */
+unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
+{
+ return irq_of_parse_and_map_type(dev, index, NULL);
}
EXPORT_SYMBOL_GPL(irq_of_parse_and_map);
@@ -338,7 +355,8 @@ EXPORT_SYMBOL_GPL(of_irq_map_one);
*/
int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
{
- int irq = irq_of_parse_and_map(dev, index);
+ int type = IRQ_TYPE_NONE;
+ int irq = irq_of_parse_and_map_type(dev, index, type);
/* Only
Re: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
On Mon, Apr 1, 2013 at 6:41 PM, Christoph Fritz
chf.fr...@googlemail.com wrote:
Hi Javier
On Sat, 2013-03-30 at 14:18 +0100, Javier Martinez Canillas wrote:
A call to gpio_request() to enable the GPIO bank is needed before
using a GPIO as an IRQ source, otherwise accesses to the GPIO bank
registers fails making the kernel to hang.
Yes, that is exactly my problem here. I'm using the GPIO as an IRQ
source.
Jon's (added as cc)gpio/omap: warn if bank is not enabled on setting
irq type patch [1] fixes the issue by warning and returning -EINVAL.
This patch will make the kernel to boot but the call to request_irq()
will fail of course. For now, the only solution is to call
gpio_request() before request_irq() in your platform code or device
driver. There is an on going discussion about what's the better way to
address this but we still haven't found a good solution to this
problem, you can see the last email for this discussion here [2]
Also, even when calling gpio_request() before request_irq() this won't
work. When specifying the trigger/level flags on the second cell for
an GPIO-IRQ, this is not set on the IORESOURCE_IRQ struct resource.
The IRQ flag is set on of_irq_to_resource() but it just does:
r-flags = IORESOURCE_IRQ;
and then the call stack is irq_to_parse_and_map() -
irq_set_irq_type() - __irq_set_trigger() - chip-irq_set_type() -
(drivers/gpio/gpio-omap.c) gpio_irq_type().
So, even when gpio_irq_type() receive the correct flags, this are not
returned neither stored on the flags member of the IORESOURCE_IRQ
struct resource that passed to the drivers in their struct
platform_device.
As a quick-fix (hack) I wrote directly to the registers in gpio_probe()
to enable GPIO banks. I now geht this:
[0.214630] omap_gpio_probe, 1133, CM_CLKSEL_PER 0x48005040: 0x00ff
[0.214660] omap_gpio_probe, 1136, CM_ICLKEN_PER 0x48005010: 0x0007
[0.214660] omap_gpio_probe, 1139, CM_FCLKEN_PER 0x48005000: 0x0007
And it works for me. _But_ when I do enable regulator twl4030
(CONFIG_REGULATOR_TWL4030=y) in my config these registers get reset:
[2.935455] smsc911x_open, 1537, CM_CLKSEL_PER 0x48005040: 0x00ff
[2.942291] smsc911x_open, 1540, CM_ICLKEN_PER 0x48005010: 0x00040fff
[2.949066] smsc911x_open, 1543, CM_FCLKEN_PER 0x48005000: 0x
And the IRQ source for the network chip (smsc911x) is disabled :-(
Do you have any idea how to (quick) fix this?
A quick hack is to call gpio_request() explicitly before calling to
irq_set_type() is made.
I've this patch just to make it work until we find a clean solution:
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 90c15ee..d594e1d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -14,6 +14,7 @@
*/
#undef DEBUG
+#include linux/gpio.h
#include linux/irq.h
#include linux/kernel.h
#include linux/init.h
@@ -1528,6 +1529,11 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
+ ret = gpio_request_one(176, GPIOF_IN, smsc911x irq);
+ if (ret) {
+ pr_err(Failed to request IRQ GPIO%d\n, 176);
+ return ret;
+ }
+
for_each_node_by_name(child, nand) {
ret = gpmc_probe_nand_child(pdev, child);
if (ret 0) {
This solves the issue of the non-initialized GPIO bank before that
makes the kernel to hang. Since I've to configure the IRQ polarity as
active low level-sensitive on my board and the flags are not set by
the IRQ core, I've another ugly hack that forces this:
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc
index da5cc9a..27e46f9 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -2390,6 +2390,9 @@ static int smsc911x_drv_probe(struct
platform_device *pdev)
pdata = netdev_priv(dev);
dev-irq = irq_res-start;
-irq_flags = irq_res-flags IRQF_TRIGGER_MASK;
+ irq_flags = IRQF_TRIGGER_LOW;
pdata-ioaddr = ioremap_nocache(res-start, res_size);
pdata-dev = dev;
Thanks
-- Christoph
I hope to find some time this week to work on this and at least find a
solution for the second issue (IORESOURCE_IRQ struct resource flags
not being set).
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
On Sat, Mar 30, 2013 at 9:21 AM, Christoph Fritz
chf.fr...@googlemail.com wrote:
This patch sets gpio #interrupt-cells from a falsely acquired '1' to '2'
referring to Documentation/devicetree/bindings/gpio/gpio-omap.txt:
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.
But using this trigger cell in a board specific devicetree leads to a
non-starting kernel. This is due to not yet enabled gpio-clocks while
kernel/irq/irqdomain.c tries to set this trigger-flag (from the second
interrupt-cell) to gpio-irq-controller.
Any ideas?
Hi Christoph,
A call to gpio_request() to enable the GPIO bank is needed before
using a GPIO as an IRQ source, otherwise accesses to the GPIO bank
registers fails making the kernel to hang. Jon's (added as cc)
gpio/omap: warn if bank is not enabled on setting irq type patch [1]
fixes the issue by warning and returning -EINVAL.
This patch will make the kernel to boot but the call to request_irq()
will fail of course. For now, the only solution is to call
gpio_request() before request_irq() in your platform code or device
driver. There is an on going discussion about what's the better way to
address this but we still haven't found a good solution to this
problem, you can see the last email for this discussion here [2]
Also, even when calling gpio_request() before request_irq() this won't
work. When specifying the trigger/level flags on the second cell for
an GPIO-IRQ, this is not set on the IORESOURCE_IRQ struct resource.
The IRQ flag is set on of_irq_to_resource() but it just does:
r-flags = IORESOURCE_IRQ;
and then the call stack is irq_to_parse_and_map() -
irq_set_irq_type() - __irq_set_trigger() - chip-irq_set_type() -
(drivers/gpio/gpio-omap.c) gpio_irq_type().
So, even when gpio_irq_type() receive the correct flags, this are not
returned neither stored on the flags member of the IORESOURCE_IRQ
struct resource that passed to the drivers in their struct
platform_device.
I have on my TODO to better investigate if this behavior is
intentional or is a bug in the interrupt core but didn't have time to
work on this yet. A relevant discussion about this is here [3].
---
arch/arm/boot/dts/omap3.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1997b41..e8e6b8f 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -99,7 +99,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio2: gpio@4905 {
@@ -108,7 +108,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio3: gpio@49052000 {
@@ -117,7 +117,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio4: gpio@49054000 {
@@ -126,7 +126,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio5: gpio@49056000 {
@@ -135,7 +135,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio6: gpio@49058000 {
@@ -144,7 +144,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
uart1: serial@4806a000 {
--
1.7.10.4
By the way, Jon has already sent a ARM: dts: OMAP3+: Correct gpio
#interrupts-cells property patch [4] that changes #interrupt-cells to
2 for all OMAP platforms.
Best regards,
Javier
[1]: https://patchwork.kernel.org/patch/2202511/
[2]: http://www.spinics.net/lists/linux-omap/msg89247.html
[3]: https://patchwork.kernel.org/patch/2194911/
[4]: https://patchwork.kernel.org/patch/2278081/
___
Re: [PATCH v3 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
On Fri, Mar 15, 2013 at 2:31 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the
#interrupt-cells property listed before #interrupt-controller
property but its description after.
This is confusing so we move #interrupt-cells after the
interrupt-controller property so is followed by its description.
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
and Documentation/devicetree/bindings/gpio/gpio.txt.
According with these docs, the order of the properties for a gpio-omap
device node should be:
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
Changes since v2:
- Fix changelog that explained the opposite of what the patch was doing as
suggested by Benoit Cousson.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- ti,omap2-gpio for OMAP2 controllers
- ti,omap3-gpio for OMAP3 controllers
- ti,omap4-gpio for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
-#gpio-cells = 2;
gpio-controller;
-#interrupt-cells = 2;
+#gpio-cells = 2;
interrupt-controller;
+#interrupt-cells = 2;
};
--
1.7.7.6
Hello,
any comments on this patch?
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
On 03/26/2013 03:29 PM, Benoit Cousson wrote:
On 03/26/2013 03:10 PM, Benoit Cousson wrote:
Hi Javier,
On 03/26/2013 10:33 AM, Javier Martinez Canillas wrote:
On Fri, Mar 15, 2013 at 2:31 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the
#interrupt-cells property listed before #interrupt-controller
property but its description after.
This is confusing so we move #interrupt-cells after the
interrupt-controller property so is followed by its description.
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
and Documentation/devicetree/bindings/gpio/gpio.txt.
According with these docs, the order of the properties for a gpio-omap
device node should be:
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
Changes since v2:
- Fix changelog that explained the opposite of what the patch was doing
as
suggested by Benoit Cousson.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- ti,omap2-gpio for OMAP2 controllers
- ti,omap3-gpio for OMAP3 controllers
- ti,omap4-gpio for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
-#gpio-cells = 2;
gpio-controller;
-#interrupt-cells = 2;
+#gpio-cells = 2;
interrupt-controller;
+#interrupt-cells = 2;
};
--
1.7.7.6
Hello,
any comments on this patch?
That's perfect. I've just applied it in my branch.
OK, in fact it is almost perfect :-)
The patch modified the documentation and not the driver itself, so I modified
the subject to reflect that accurately.
Documentation: dt: gpio-omap: Move interrupt-controller from #interrupt-cell
Sorry about that, this pattern was not evident for me by looking the Git logs.
Now I know for future patches.
Thanks a lot for pointing this out!
Regards,
Benoit
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
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 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Fri, Mar 8, 2013 at 12:14 AM, Jon Hunter jon-hun...@ti.com wrote:
On 03/02/2013 02:05 PM, Grant Likely wrote:
On Tue, 26 Feb 2013 17:01:22 -0600, Jon Hunter jon-hun...@ti.com wrote:
On 02/26/2013 04:44 PM, Stephen Warren wrote:
On 02/26/2013 03:40 PM, Jon Hunter wrote:
On 02/26/2013 04:01 AM, Javier Martinez Canillas wrote:
Are you requesting the gpio anywhere? If not then this is not going to
work as-is. This was discussed fairly recently [1] and the conclusion
was that the gpio needs to be requested before we can use as an interrupt.
That seems wrong; the GPIO/IRQ driver should handle this internally. The
Ethernet driver shouldn't know/care whether the interrupt it's given is
some form of dedicated interrupt or a GPIO-based interrupt, and even if
it somehow did, there's no irq_to_gpio() any more, so the driver can't
tell which GPIO ID it should request, unless it's given yet another
property to represent this.
I agree that ideally this should be handled internally. Did you read the
discussion on the thread that I referenced [1]? If you have any thoughts
we are open to ideas :-)
I'm on an airplane right now, but I agree 100% with Stephen. I'll try to
remember to go read that thread and respond, but this falls firmly in
the its-a-bug category for me. :-)
Grant, did you have chance to review the thread [1]?
I am trying to figure out if we should just take the original patch
proposed in the thread (although Linus had some objections) or look at
alternative solutions such as adding a irq_chip request as Stephen
suggested.
Cheers
Jon
[1] comments.gmane.org/gmane.linux.ports.arm.omap/92192
Hello Grant,
I was wondering if you have any opinions on this issue. As Jon said,
Stephen proposed [2] to add a request callback to irq_chip.
I hacked a very simple and naive patch (just to validate the idea) and
is working. The GPIO bank is requested before calling the gpio-omap
.irq_set_type function handler (gpio_irq_type) when using a GPIO as an
IRQ on a DT. So is not necessary to call it explicitly anymore.
But the patch is obviously wrong (to say the least) since the kernel
runtime locking validator complains that possible circular locking
dependency detected
I just wanted to know if I was on the right track or completely lost here.
Thanks a lot and best regards,
javier
[2]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85592.html
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 159f5c5..f5feb43 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -807,6 +807,13 @@ static void gpio_unmask_irq(struct irq_data *d)
spin_unlock_irqrestore(bank-lock, flags);
}
+static int gpio_irq_request(struct irq_data *d)
+{
+ struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
+
+ return gpio_request(irq_to_gpio(bank, d-irq), gpio-irq);
+}
+
static struct irq_chip gpio_irq_chip = {
.name = GPIO,
.irq_shutdown = gpio_irq_shutdown,
@@ -815,6 +822,7 @@ static struct irq_chip gpio_irq_chip = {
.irq_unmask = gpio_unmask_irq,
.irq_set_type = gpio_irq_type,
.irq_set_wake = gpio_wake_enable,
+ .irq_request= gpio_irq_request,
};
/*-*/
diff --git a/include/linux/irq.h b/include/linux/irq.h
index bc4e066..2aeaa24 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -303,6 +303,7 @@ struct irq_chip {
void(*irq_shutdown)(struct irq_data *data);
void(*irq_enable)(struct irq_data *data);
void(*irq_disable)(struct irq_data *data);
+ int (*irq_request)(struct irq_data *data);
void(*irq_ack)(struct irq_data *data);
void(*irq_mask)(struct irq_data *data);
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index fa17855..07c20f7 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1093,6 +1093,13 @@ __setup_irq(unsigned int irq, struct irq_desc
*desc, struct irqaction *new)
if (!shared) {
init_waitqueue_head(desc-wait_for_threads);
+ if (desc-irq_data.chip-irq_request) {
+ ret = desc-irq_data.chip-irq_request(desc-irq_data);
+
+ if (ret)
+ goto out_mask;
+ }
+
/* Setup the type (level, edge polarity) if configured: */
if (new-flags IRQF_TRIGGER_MASK) {
ret = __irq_set_trigger(desc, irq,
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
On Mon, Mar 4, 2013 at 9:56 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the description
for the #interrupt-cells property after the interrupt-controller.
This is confusing so is better to move the interrupt-controller after
#interrupt-cells description.
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
Documentation/devicetree/bindings/gpio/gpio.txt.
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- ti,omap2-gpio for OMAP2 controllers
- ti,omap3-gpio for OMAP3 controllers
- ti,omap4-gpio for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
-#gpio-cells = 2;
gpio-controller;
-#interrupt-cells = 2;
+#gpio-cells = 2;
interrupt-controller;
+#interrupt-cells = 2;
};
--
1.7.7.6
Hello,
Any comments on this patch?
I know is just a trivial documentation fix but I think it can be quite
helpful for people referring to gpio-omap binding.
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
On Fri, Mar 15, 2013 at 1:56 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Javier,
On 03/15/2013 01:18 PM, Javier Martinez Canillas wrote:
On Mon, Mar 4, 2013 at 9:56 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the description
for the #interrupt-cells property after the interrupt-controller.
This is confusing so is better to move the interrupt-controller after
#interrupt-cells description.
Mmm, your are doing the opposite :-)
I guess what we do want is that:
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
So we move #interrupt-cells after the interrupt-controller description.
Indeed!
I got confused I guess...
I'll send a v3 patch fixing the changelog
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
Documentation/devicetree/bindings/gpio/gpio.txt.
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- ti,omap2-gpio for OMAP2 controllers
- ti,omap3-gpio for OMAP3 controllers
- ti,omap4-gpio for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
-#gpio-cells = 2;
gpio-controller;
-#interrupt-cells = 2;
+#gpio-cells = 2;
interrupt-controller;
+#interrupt-cells = 2;
};
--
1.7.7.6
Hello,
Any comments on this patch?
I know is just a trivial documentation fix but I think it can be quite
helpful for people referring to gpio-omap binding.
I do agree. The patch is good, but the changelog is confusing.
Regards,
Benoit
Thanks a lot for your feedback and best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
The binding documentation for the OMAP GPIO controller has the
#interrupt-cells property listed before #interrupt-controller
property but its description after.
This is confusing so we move #interrupt-cells after the
interrupt-controller property so is followed by its description.
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
and Documentation/devicetree/bindings/gpio/gpio.txt.
According with these docs, the order of the properties for a gpio-omap
device node should be:
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
Changes since v2:
- Fix changelog that explained the opposite of what the patch was doing as
suggested by Benoit Cousson.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- ti,omap2-gpio for OMAP2 controllers
- ti,omap3-gpio for OMAP3 controllers
- ti,omap4-gpio for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
-#gpio-cells = 2;
gpio-controller;
-#interrupt-cells = 2;
+#gpio-cells = 2;
interrupt-controller;
+#interrupt-cells = 2;
};
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/3] ARM: OMAP2+: return -ENODEV if GPMC child device creation fails
gpmc_probe_nor_child() calls of_platform_device_create() to create a platform device for the NOR child. If this function fails the value of ret is returned to the caller but this value is zero since it was assigned the return of a previous call to gpmc_cs_program_settings() that had to succeed or otherwise gpmc_probe_nor_child() would have returned before. This means that if of_platform_device_create() fails, 0 will be returned to the caller instead of an appropriate error code. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/mach-omap2/gpmc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index d594e1d..8799aed 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -1505,6 +1505,7 @@ static int gpmc_probe_nor_child(struct platform_device *pdev, return 0; dev_err(pdev-dev, failed to create gpmc child %s\n, child-name); + ret = -ENODEV; err: gpmc_cs_free(cs); -- 1.7.7.6 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child
Hello Jon, As discussed before [1], this patch-set adds DT support for ethernet controllers connected to a TI GPMC by making gpmc_probe_nor_child() a generic function and reusing it to initialize ethernet child devices nodes too. It also adds documentation about the DT binding. The patch-set is based on top of your omap-gpmc-for-v3.10 branch [2] and is composed of the following patches: [PATCH 1/3] ARM: OMAP2+: return -ENODEV if GPMC child device [PATCH 2/3] ARM: OMAP2+: rename gpmc_probe_nor_child() to gpmc_probe_generic_child() [PATCH 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child This was tested on an TI OMAP3 DM3735 based board (IGEPv2) Thanks a lot and best regards, Javier [1]: https://patchwork.kernel.org/patch/2245111/ [2]: https://github.com/jonhunter/linux/tree/omap-gpmc-for-v3.10 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/3] ARM: OMAP2+: rename gpmc_probe_nor_child() to gpmc_probe_generic_child()
The gpmc_probe_nor_child() function is used in the GPMC driver to
configure the GPMC for a NOR child device node.
But this function is quite generic and all the NOR specific configuration
is made by the driver of the actual NOR flash memory used.
Other Pseudo-SRAM devices such as ethernet controllers need a similar
setup so by making this function generic it can be used for those too.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2/gpmc.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8799aed..898b44d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1439,14 +1439,14 @@ static int gpmc_probe_onenand_child(struct
platform_device *pdev,
#endif
/**
- * gpmc_probe_nor_child - configures the gpmc for a nor device
+ * gpmc_probe_generic_child - configures the gpmc for a child device
* @pdev: pointer to gpmc platform device
- * @child: pointer to device-tree node for nor device
+ * @child: pointer to device-tree node for child device
*
- * Allocates and configures a GPMC chip-select for a NOR flash device.
+ * Allocates and configures a GPMC chip-select for a child device.
* Returns 0 on success and appropriate negative error code on failure.
*/
-static int gpmc_probe_nor_child(struct platform_device *pdev,
+static int gpmc_probe_generic_child(struct platform_device *pdev,
struct device_node *child)
{
struct gpmc_settings gpmc_s;
@@ -1552,7 +1552,7 @@ static int gpmc_probe_dt(struct platform_device *pdev)
}
for_each_node_by_name(child, nor) {
- ret = gpmc_probe_nor_child(pdev, child);
+ ret = gpmc_probe_generic_child(pdev, child);
if (ret 0) {
of_node_put(child);
return ret;
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Documentation/devicetree/bindings/net/gpmc-eth.txt | 90
arch/arm/mach-omap2/gpmc.c |8 ++
2 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt
b/Documentation/devicetree/bindings/net/gpmc-eth.txt
new file mode 100644
index 000..c45363c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,90 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices
+such as ethernet controllers to processors using the TI GPMC as a data bus.
+
+Ethernet controllers connected to TI GPMC are represented as child nodes of
+the GPMC controller with an ethernet name.
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- bank-width: Address width of the device in bytes. GPMC supports
8-bit
+ and 16-bit devices and so must be either 1 or 2 bytes.
+- compatible: Compatible string property for the ethernet child
device.
+- gpmc,cs-on: Chip-select assertion time
+- gpmc,cs-rd-off: Chip-select de-assertion time for reads
+- gpmc,cs-wr-off: Chip-select de-assertion time for writes
+- gpmc,oe-on: Output-enable assertion time
+- gpmc,oe-off Output-enable de-assertion time
+- gpmc,we-on: Write-enable assertion time
+- gpmc,we-off: Write-enable de-assertion time
+- gpmc,access: Start cycle to first data capture (read access)
+- gpmc,rd-cycle: Total read cycle time
+- gpmc,wr-cycle: Total write cycle time
+- reg: Chip-select, base address (relative to chip-select)
+ and size of the memory mapped for the device.
+ Note that base address will be typically 0 as this
+ is the start of the chip-select.
+
+Optional properties:
+- gpmc,XXX Additional GPMC timings and settings parameters. See
+ Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Optional properties for partiton table parsing:
+- #address-cells: should be set to 1
+- #size-cells: should be set to 1
+
+Example:
+
+gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x1000;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ ranges = 5 0 0x2c00 0x100;
+
+ ethernet@5,0 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 5 0 0xff;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 186;
+ gpmc,cs-wr-off = 186;
+ gpmc,adv-on = 12;
+ gpmc,adv-rd-off = 48;
+ gpmc,adv-wr-off = 48;
+ gpmc,oe-on = 54;
+ gpmc,oe-off = 168;
+ gpmc,we-on = 54;
+ gpmc,we-off = 168;
+ gpmc,rd-cycle = 186;
+ gpmc,wr-cycle = 186;
+ gpmc,access = 114;
+ gpmc,page-burst-access = 6;
+ gpmc,bus-turnaround = 12;
+ gpmc,cycle2cycle-delay = 18;
+ gpmc,wr-data-mux-bus = 90;
+ gpmc,wr-access = 186;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ interrupt-parent = gpio6;
+ interrupts = 16;
+ vmmc-supply = vddvario;
+ vmmc_aux-supply = vdd33a;
+ reg-io-width = 2;
+
+ smsc,save-mac-address;
+ };
+};
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 898b44d..2bc276b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1559,6 +1559,14 @@ static int gpmc_probe_dt(struct platform_device *pdev)
}
}
+ for_each_node_by_name(child, ethernet) {
+ ret = gpmc_probe_generic_child(pdev, child);
+ if (ret 0) {
+ of_node_put(child);
+ return ret;
+ }
+ }
+
return 0;
}
#else
--
1.7.7.6
Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson b-cous...@ti.com wrote:
Salut Jon,
On 03/08/2013 06:27 PM, Jon Hunter wrote:
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430 SDP board changes have been sent before
individually but re-sending here as a complete series for v3.10.
This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian
Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2].
[1] https://patchwork.kernel.org/patch/2057111/
I've tried to follow the series review, and it seems that Florian was
considering sending some other patches. It is not clear if this is a new
version of the series or some additional patches.
Hi Benoit,
According to [1] Jon suggested that it was not necessary to map all
the 16MB for the GPMC mapped register address space since in practice
is a very small fraction of that size is used.
I had the following patch but I did never post it because Jon said
that the I/O memory mapping is page-aligned and the minimum page
size for ARM is 4KB anyways, so there is no functional difference
between using 0x1000 or 0x02d0.
But now reading [2] I see that you prefer to do what the documentation
said and don't assume any the page size / alignment.
[2]: https://patchwork.kernel.org/patch/2239741/
From 68edff5a102bb8fc81e006738baa456eb69f080a Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
Date: Wed, 27 Feb 2013 02:30:51 +0100
Subject: [PATCH] ARM: dts: OMAP3: reduce GPMC mapped registers address space
Currently the OMAP General-Purpose Memory Controller (GPMC) device
node maps 16 MB of address space for its hardware registers.
This is because the OMAP Technical Reference Manual says that the
GPMC module register address space size is 16 MB. But in practice
the maximum address offset used by a GPMC register is 0x02d0.
So, there is no need to map such a big address space for GPMC regs.
This change was suggested by Jon Hunter [1].
[1]: https://patchwork.kernel.org/patch/2057111/
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 2ddae38..a60eaf1 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -407,7 +407,7 @@
gpmc: gpmc@6e00 {
compatible = ti,omap3430-gpmc;
ti,hwmods = gpmc;
- reg = 0x6e00 0x100;
+ reg = 0x6e00 0x02d0;
interrupts = 20;
gpmc,num-cs = 8;
gpmc,num-waitpins = 4;
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter jon-hun...@ti.com wrote:
Hi Javier,
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Documentation/devicetree/bindings/net/gpmc-eth.txt | 90
arch/arm/mach-omap2/gpmc.c |8 ++
2 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt
b/Documentation/devicetree/bindings/net/gpmc-eth.txt
new file mode 100644
index 000..c45363c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,90 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices
+such as ethernet controllers to processors using the TI GPMC as a data bus.
+
+Ethernet controllers connected to TI GPMC are represented as child nodes of
+the GPMC controller with an ethernet name.
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- bank-width:Address width of the device in bytes. GPMC
supports 8-bit
+ and 16-bit devices and so must be either 1 or 2 bytes.
I am wondering if we should use reg-io-width here. The smsc driver is
using this to determine the width of the device. And so I am wondering
if this could cause problems.
Obviously this complicates gpmc_probe_generic_child() a little, but may
be would could pass the name of the width property to
gpmc_probe_generic_child() as well. What do you think?
Hi Jon,
Well now I'm confused. I thought that both were needed since a
combination of bank-width 16-bit / reg-io-width 32-bit is also
possible (in fact that is how I'm testing on my IGEPv2) and we have
talked about this before [1].
By reading both the OMAP3 TRM and the smsc LAN9221 data-sheet, it
seems that the reg-io-width is not about the data bus address width
but the CPU address width. The smsc data-sheet says:
The simple, yet highly functional host bus interface provides a
glue-less connection to most common 16-bit microprocessors and
microcontrollers as well as 32-bit microprocessors with a 16-bit
external bus
By looking at the smsc911x driver
(drivers/net/ethernet/smsc/smsc911x.c) I see that if you use
reg-io-width = 4 (SMSC911X_USE_32BIT) then the smsc911x hardware
registers can be read in one operation and if you use reg-io-width =
2 (SMSC911X_USE_16BIT) then you need two operations to read the
register:
static inline u32 __smsc911x_reg_read(struct smsc911x_data *pdata, u32 reg)
{
if (pdata-config.flags SMSC911X_USE_32BIT)
return readl(pdata-ioaddr + reg);
if (pdata-config.flags SMSC911X_USE_16BIT)
return ((readw(pdata-ioaddr + reg) 0x) |
((readw(pdata-ioaddr + reg + 2) 0x) 16));
BUG();
return 0;
}
Also, by reading at the OMAP3 TRM, I understand that even when the
GPMC has a maximum 16-bit address width, it support devices that has
32-bit registers by doing some sort of access adaptation.
So, as far as I understand the bank-width is to configure the GPMC
if is going to use a 8-bit or 16-bit width access and the
reg-io-width is how the smsc911x driver is going to read its
registers. So, I think we need both properties and there is no need to
change gpmc_probe_generic_child() neither pass the child name to it.
But to be honest I can be wrong here since data-sheet and technical
reference manuals can be quite confusing sometimes :-)
Thanks a lot for your feedback and best regards,
Javier
[1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85597.html
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On Thu, Mar 14, 2013 at 5:37 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter jon-hun...@ti.com wrote: Hi Javier, On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote: Besides being used to interface with external memory devices, the General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices such as ethernet controllers to OMAP2+ processors using the TI GPMC as a data bus. This patch allows an ethernet chip to be defined as an GPMC child device node. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Documentation/devicetree/bindings/net/gpmc-eth.txt | 90 arch/arm/mach-omap2/gpmc.c |8 ++ 2 files changed, 98 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt b/Documentation/devicetree/bindings/net/gpmc-eth.txt new file mode 100644 index 000..c45363c --- /dev/null +++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt @@ -0,0 +1,90 @@ +Device tree bindings for Ethernet chip connected to TI GPMC + +Besides being used to interface with external memory devices, the +General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices +such as ethernet controllers to processors using the TI GPMC as a data bus. + +Ethernet controllers connected to TI GPMC are represented as child nodes of +the GPMC controller with an ethernet name. + +All timing relevant properties as well as generic GPMC child properties are +explained in a separate documents. Please refer to +Documentation/devicetree/bindings/bus/ti-gpmc.txt + +Required properties: +- bank-width:Address width of the device in bytes. GPMC supports 8-bit + and 16-bit devices and so must be either 1 or 2 bytes. I am wondering if we should use reg-io-width here. The smsc driver is using this to determine the width of the device. And so I am wondering if this could cause problems. Obviously this complicates gpmc_probe_generic_child() a little, but may be would could pass the name of the width property to gpmc_probe_generic_child() as well. What do you think? Hi Jon, Well now I'm confused. I thought that both were needed since a combination of bank-width 16-bit / reg-io-width 32-bit is also possible (in fact that is how I'm testing on my IGEPv2) and we have talked about this before [1]. By reading both the OMAP3 TRM and the smsc LAN9221 data-sheet, it seems that the reg-io-width is not about the data bus address width but the CPU address width. The smsc data-sheet says: Hi Jon, By the way, here is the smsc LAN9221 data-sheet if you don't have it and want to take it a look: http://www.smsc.com/Downloads/SMSC/Downloads_Public/Data_Sheets/9221.pdf Thanks a lot and best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1:
- Improve the DT binding documentation explaining that even when the GPMC
maximum bus address width is 16-bit, it supports devices with 32-bit
registers address width and the device property especifying this has to
be set accordingly; suggested by Jon Hunter.
Documentation/devicetree/bindings/net/gpmc-eth.txt | 101
arch/arm/mach-omap2/gpmc.c |8 ++
2 files changed, 109 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt
b/Documentation/devicetree/bindings/net/gpmc-eth.txt
new file mode 100644
index 000..8c8be58
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,101 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices
+such as ethernet controllers to processors using the TI GPMC as a data bus.
+
+Ethernet controllers connected to TI GPMC are represented as child nodes of
+the GPMC controller with an ethernet name.
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+For the properties relevant to the ethernet controller connected to the GPMC
+refer to the binding documentation of the device. For example, the
documentation
+for the SMSC 911x is Documentation/devicetree/bindings/net/smsc911x.txt
+
+Child nodes need to specify the GPMC bus address width using the bank-width
+property but is possible that an ethernet controller also has a property to
+specify the I/O registers address width. Even when the GPMC has a maximum
16-bit
+address width, it supports devices with 32-bit word registers.
+For example with an SMSC LAN911x/912x controller connected to the TI GPMC on an
+OMAP2+ board, bank-width = 2; and reg-io-width = 4;.
+
+Required properties:
+- bank-width: Address width of the device in bytes. GPMC supports
8-bit
+ and 16-bit devices and so must be either 1 or 2 bytes.
+- compatible: Compatible string property for the ethernet child
device.
+- gpmc,cs-on: Chip-select assertion time
+- gpmc,cs-rd-off: Chip-select de-assertion time for reads
+- gpmc,cs-wr-off: Chip-select de-assertion time for writes
+- gpmc,oe-on: Output-enable assertion time
+- gpmc,oe-off Output-enable de-assertion time
+- gpmc,we-on: Write-enable assertion time
+- gpmc,we-off: Write-enable de-assertion time
+- gpmc,access: Start cycle to first data capture (read access)
+- gpmc,rd-cycle: Total read cycle time
+- gpmc,wr-cycle: Total write cycle time
+- reg: Chip-select, base address (relative to chip-select)
+ and size of the memory mapped for the device.
+ Note that base address will be typically 0 as this
+ is the start of the chip-select.
+
+Optional properties:
+- gpmc,XXX Additional GPMC timings and settings parameters. See
+ Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Optional properties for partiton table parsing:
+- #address-cells: should be set to 1
+- #size-cells: should be set to 1
+
+Example:
+
+gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x1000;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ ranges = 5 0 0x2c00 0x100;
+
+ ethernet@5,0 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 5 0 0xff;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 186;
+ gpmc,cs-wr-off = 186;
+ gpmc,adv-on = 12;
+ gpmc,adv-rd-off = 48;
+ gpmc,adv-wr-off = 48;
+ gpmc,oe-on = 54;
+ gpmc,oe-off = 168;
+ gpmc,we-on = 54;
+ gpmc,we-off = 168;
+ gpmc,rd-cycle = 186;
+ gpmc,wr-cycle = 186;
+ gpmc,access = 114;
+ gpmc,page-burst-access = 6;
+ gpmc,bus-turnaround = 12;
+ gpmc,cycle2cycle-delay = 18;
+ gpmc,wr-data-mux-bus
Re: [PATCH v2 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
Javier Hi Jon, On 14/03/2013, at 21:43, Jon Hunter jon-hun...@ti.com wrote: On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote: Besides being used to interface with external memory devices, the General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices such as ethernet controllers to OMAP2+ processors using the TI GPMC as a data bus. This patch allows an ethernet chip to be defined as an GPMC child device node. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v1: - Improve the DT binding documentation explaining that even when the GPMC maximum bus address width is 16-bit, it supports devices with 32-bit registers address width and the device property especifying this has to be set accordingly; suggested by Jon Hunter. Documentation/devicetree/bindings/net/gpmc-eth.txt | 101 arch/arm/mach-omap2/gpmc.c |8 ++ 2 files changed, 109 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt b/Documentation/devicetree/bindings/net/gpmc-eth.txt new file mode 100644 index 000..8c8be58 --- /dev/null +++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt @@ -0,0 +1,101 @@ +Device tree bindings for Ethernet chip connected to TI GPMC + +Besides being used to interface with external memory devices, the +General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices +such as ethernet controllers to processors using the TI GPMC as a data bus. + +Ethernet controllers connected to TI GPMC are represented as child nodes of +the GPMC controller with an ethernet name. + +All timing relevant properties as well as generic GPMC child properties are +explained in a separate documents. Please refer to +Documentation/devicetree/bindings/bus/ti-gpmc.txt + +For the properties relevant to the ethernet controller connected to the GPMC +refer to the binding documentation of the device. For example, the documentation +for the SMSC 911x is Documentation/devicetree/bindings/net/smsc911x.txt + +Child nodes need to specify the GPMC bus address width using the bank-width +property but is possible that an ethernet controller also has a property to +specify the I/O registers address width. Even when the GPMC has a maximum 16-bit +address width, it supports devices with 32-bit word registers. +For example with an SMSC LAN911x/912x controller connected to the TI GPMC on an +OMAP2+ board, bank-width = 2; and reg-io-width = 4;. + +Required properties: +- bank-width:Address width of the device in bytes. GPMC supports 8-bit +and 16-bit devices and so must be either 1 or 2 bytes. +- compatible:Compatible string property for the ethernet child device. +- gpmc,cs-on:Chip-select assertion time +- gpmc,cs-rd-off:Chip-select de-assertion time for reads +- gpmc,cs-wr-off:Chip-select de-assertion time for writes +- gpmc,oe-on:Output-enable assertion time +- gpmc,oe-offOutput-enable de-assertion time +- gpmc,we-on:Write-enable assertion time +- gpmc,we-off:Write-enable de-assertion time +- gpmc,access:Start cycle to first data capture (read access) +- gpmc,rd-cycle:Total read cycle time +- gpmc,wr-cycle:Total write cycle time +- reg:Chip-select, base address (relative to chip-select) +and size of the memory mapped for the device. +Note that base address will be typically 0 as this +is the start of the chip-select. + +Optional properties: +- gpmc,XXXAdditional GPMC timings and settings parameters. See +Documentation/devicetree/bindings/bus/ti-gpmc.txt Should we add reg-io-width here and say can be 2 or 4 and to refer to the above description? I'm not sure about that, this property is not used (neither relevant) to the GPMC driver but is used by the smsc911x driver. Other Ethernet chips could not need that (e.g: supports only 32 bit word accesses) or can have a different property. Uses should check the documentation binding for the connected device. + +Optional properties for partiton table parsing: +- #address-cells: should be set to 1 +- #size-cells: should be set to 1 Sorry should have caught this earlier. The above is not relevant for ethernet. I should have catch that before sending the first version! I took the properties from your gpmc-nor.txt documentation and this is a left over. Will send a v3 removing that. Sorry for being so carelessly... Otherwise looks good. Cheers Jon Thanks a lot and best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v2:
- remove optional #address-cells and #size-cells since are not relevant for
ethernet chips; suggested by Jon Hunter.
Changes since v1:
- Improve the DT binding documentation explaining that even when the GPMC
maximum bus address width is 16-bit, it supports devices with 32-bit
registers address width and the device property especifying this has to
be set accordingly; suggested by Jon Hunter.
Documentation/devicetree/bindings/net/gpmc-eth.txt | 97
arch/arm/mach-omap2/gpmc.c |8 ++
2 files changed, 105 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt
b/Documentation/devicetree/bindings/net/gpmc-eth.txt
new file mode 100644
index 000..24cb4e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,97 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices
+such as ethernet controllers to processors using the TI GPMC as a data bus.
+
+Ethernet controllers connected to TI GPMC are represented as child nodes of
+the GPMC controller with an ethernet name.
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+For the properties relevant to the ethernet controller connected to the GPMC
+refer to the binding documentation of the device. For example, the
documentation
+for the SMSC 911x is Documentation/devicetree/bindings/net/smsc911x.txt
+
+Child nodes need to specify the GPMC bus address width using the bank-width
+property but is possible that an ethernet controller also has a property to
+specify the I/O registers address width. Even when the GPMC has a maximum
16-bit
+address width, it supports devices with 32-bit word registers.
+For example with an SMSC LAN911x/912x controller connected to the TI GPMC on an
+OMAP2+ board, bank-width = 2; and reg-io-width = 4;.
+
+Required properties:
+- bank-width: Address width of the device in bytes. GPMC supports
8-bit
+ and 16-bit devices and so must be either 1 or 2 bytes.
+- compatible: Compatible string property for the ethernet child
device.
+- gpmc,cs-on: Chip-select assertion time
+- gpmc,cs-rd-off: Chip-select de-assertion time for reads
+- gpmc,cs-wr-off: Chip-select de-assertion time for writes
+- gpmc,oe-on: Output-enable assertion time
+- gpmc,oe-off Output-enable de-assertion time
+- gpmc,we-on: Write-enable assertion time
+- gpmc,we-off: Write-enable de-assertion time
+- gpmc,access: Start cycle to first data capture (read access)
+- gpmc,rd-cycle: Total read cycle time
+- gpmc,wr-cycle: Total write cycle time
+- reg: Chip-select, base address (relative to chip-select)
+ and size of the memory mapped for the device.
+ Note that base address will be typically 0 as this
+ is the start of the chip-select.
+
+Optional properties:
+- gpmc,XXX Additional GPMC timings and settings parameters. See
+ Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Example:
+
+gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x1000;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ ranges = 5 0 0x2c00 0x100;
+
+ ethernet@5,0 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 5 0 0xff;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 186;
+ gpmc,cs-wr-off = 186;
+ gpmc,adv-on = 12;
+ gpmc,adv-rd-off = 48;
+ gpmc,adv-wr-off = 48;
+ gpmc,oe-on = 54;
+ gpmc,oe-off = 168;
+ gpmc,we-on = 54;
+ gpmc,we-off = 168;
+ gpmc,rd-cycle = 186;
+ gpmc,wr-cycle = 186;
+ gpmc,access = 114;
+ gpmc,page-burst-access = 6;
+ gpmc,bus-turnaround = 12;
+ gpmc,cycle2cycle-delay = 18;
+ gpmc,wr
Re: [PATCH v2 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On Thu, Mar 14, 2013 at 10:29 PM, Jon Hunter jon-hun...@ti.com wrote: On 03/14/2013 04:08 PM, Javier Martinez Canillas wrote: Javier Hi Jon, On 14/03/2013, at 21:43, Jon Hunter jon-hun...@ti.com wrote: On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote: Besides being used to interface with external memory devices, the General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices such as ethernet controllers to OMAP2+ processors using the TI GPMC as a data bus. This patch allows an ethernet chip to be defined as an GPMC child device node. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v1: - Improve the DT binding documentation explaining that even when the GPMC maximum bus address width is 16-bit, it supports devices with 32-bit registers address width and the device property especifying this has to be set accordingly; suggested by Jon Hunter. Documentation/devicetree/bindings/net/gpmc-eth.txt | 101 arch/arm/mach-omap2/gpmc.c |8 ++ 2 files changed, 109 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt b/Documentation/devicetree/bindings/net/gpmc-eth.txt new file mode 100644 index 000..8c8be58 --- /dev/null +++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt @@ -0,0 +1,101 @@ +Device tree bindings for Ethernet chip connected to TI GPMC + +Besides being used to interface with external memory devices, the +General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices +such as ethernet controllers to processors using the TI GPMC as a data bus. + +Ethernet controllers connected to TI GPMC are represented as child nodes of +the GPMC controller with an ethernet name. + +All timing relevant properties as well as generic GPMC child properties are +explained in a separate documents. Please refer to +Documentation/devicetree/bindings/bus/ti-gpmc.txt + +For the properties relevant to the ethernet controller connected to the GPMC +refer to the binding documentation of the device. For example, the documentation +for the SMSC 911x is Documentation/devicetree/bindings/net/smsc911x.txt + +Child nodes need to specify the GPMC bus address width using the bank-width +property but is possible that an ethernet controller also has a property to +specify the I/O registers address width. Even when the GPMC has a maximum 16-bit +address width, it supports devices with 32-bit word registers. +For example with an SMSC LAN911x/912x controller connected to the TI GPMC on an +OMAP2+ board, bank-width = 2; and reg-io-width = 4;. + +Required properties: +- bank-width:Address width of the device in bytes. GPMC supports 8-bit +and 16-bit devices and so must be either 1 or 2 bytes. +- compatible:Compatible string property for the ethernet child device. +- gpmc,cs-on:Chip-select assertion time +- gpmc,cs-rd-off:Chip-select de-assertion time for reads +- gpmc,cs-wr-off:Chip-select de-assertion time for writes +- gpmc,oe-on:Output-enable assertion time +- gpmc,oe-offOutput-enable de-assertion time +- gpmc,we-on:Write-enable assertion time +- gpmc,we-off:Write-enable de-assertion time +- gpmc,access:Start cycle to first data capture (read access) +- gpmc,rd-cycle:Total read cycle time +- gpmc,wr-cycle:Total write cycle time +- reg:Chip-select, base address (relative to chip-select) +and size of the memory mapped for the device. +Note that base address will be typically 0 as this +is the start of the chip-select. + +Optional properties: +- gpmc,XXXAdditional GPMC timings and settings parameters. See +Documentation/devicetree/bindings/bus/ti-gpmc.txt Should we add reg-io-width here and say can be 2 or 4 and to refer to the above description? I'm not sure about that, this property is not used (neither relevant) to the GPMC driver but is used by the smsc911x driver. Other Ethernet chips could not need that (e.g: supports only 32 bit word accesses) or can have a different property. Uses should check the documentation binding for the connected device. Good point. Let's not bother adding that. + +Optional properties for partiton table parsing: +- #address-cells: should be set to 1 +- #size-cells: should be set to 1 Sorry should have caught this earlier. The above is not relevant for ethernet. I should have catch that before sending the first version! I took the properties from your gpmc-nor.txt documentation and this is a left over. Will send a v3 removing that. ok v3 sent removing this left over. Sorry for being so carelessly... No problem. Thanks for getting this done. Now just to figure
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
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] ARM: OMAP: gpmc: request CS address space for ethernet chips
On 03/11/2013 06:13 PM, Jon Hunter wrote:
Hi Jon, thanks a lot for your feedback.
On 03/10/2013 12:18 PM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the GPMC as a data bus.
The actual mapping between the GPMC address space and OMAP2+
address space is made using the GPMC DT ranges property.
But also a explicit call to gpmc_cs_request() is needed.
One problem with gpmc_cs_request() is that it will map the chip-select
to any physical location in the 1GB address space for the gpmc
controller. So in other words, it will ignore the ranges property
altogether. If you look at my code for NOR, I have added a
gpmc_cs_remap() function to remap the cs to the location as specified by
the device-tree.
I see, thanks for pointing this out.
Ideally we should change gpmc_cs_request() so we can pass the desire
base address that we want to map the gpmc cs too. I had started out that
way but it made the code some what messy and so I opted to create a
gpmc_cs_remap() function instead. The goal will be to get rid of
gpmc_cs_remap() once DT migration is completed and we can change
gpmc_cs_request() to map the cs to a specific address (see my FIXME
comment).
By looking at gpmc_probe_onenand_child() and gpmc_probe_nand_child() I see that
these functions just allocates platform data and call gpmc_onenand_init() and
gpmc_nand_init() accordingly. So if I understood right these functions have the
same issue and need to call gpmc_cs_remap() too in order to map to the location
specified on the DT.
Your code probably works today because the cs is setup by the bootloader
and so when you request the cs in the kernel the mapping is not changed
from the bootloader settings. However, if the mapping in DT (ranges
property) is different from that setup by the bootloader then the kernel
would probably crash because the kernel would not remap it as expected.
So, this patch allows an ethernet chip to be defined as an
GPMC child node an its chip-select memory address be requested.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Jon,
This patch assumes that we have solved somehow the issue that a
call to request_irq() is needed before before using a GPIO as an
IRQ and this is no longer the case when using from Device Trees.
Anyway, this is independent as how we solve this, whether is
using Jan's patch [1], adding a .request function pointer to
irq_chip as suggested by Stephen [2], or any other approach.
[1]: https://patchwork.kernel.org/patch/2009331/
[2]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85592.html
arch/arm/mach-omap2/gpmc.c | 45
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 4fe9ee7..d1bf48b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -29,6 +29,7 @@
#include linux/of.h
#include linux/of_mtd.h
#include linux/of_device.h
+#include linux/of_address.h
#include linux/mtd/nand.h
#include linux/platform_data/mtd-nand-omap2.h
@@ -1296,6 +1297,42 @@ static int gpmc_probe_onenand_child(struct
platform_device *pdev,
}
#endif
+static int gpmc_probe_ethernet_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+int ret, cs;
+unsigned long base;
+struct resource res;
+struct platform_device *of_dev;
+
+if (of_property_read_u32(child, reg, cs) 0) {
+dev_err(pdev-dev, %s has no 'reg' property\n,
+child-full_name);
+return -ENODEV;
+}
+
+if (of_address_to_resource(child, 0, res)) {
+dev_err(pdev-dev, %s has malformed 'reg' property\n,
+child-full_name);
+return -ENODEV;
+}
+
+ret = gpmc_cs_request(cs, resource_size(res), base);
+if (IS_ERR_VALUE(ret)) {
+dev_err(pdev-dev, cannot request GPMC CS %d\n, cs);
+return ret;
+}
+
+of_dev = of_platform_device_create(child, NULL, pdev-dev);
+if (!of_dev) {
+dev_err(pdev-dev, cannot create platform device for %s\n,
+child-full_name);
+return -ENODEV;
+}
+
+return 0;
+}
So this function does not setup the cs at all and so that means you are
dependent on having the bootloader configure the cs. I would really like
to get away from that sort of dependency. In fact I am wondering if we
could make the gpmc_probe_nor() function a gpmc_probe_generic() that we
can use for both nor and ethernet as we are doing very similar things
(if we add the timings and gpmc settings to the ethernet binding).
Yes, I also thought about
Re: [PATCH 1/1] ARM: OMAP: gpmc: request CS address space for ethernet chips
On 03/11/2013 07:11 PM, Jon Hunter wrote:
On 03/11/2013 12:57 PM, Javier Martinez Canillas wrote:
On 03/11/2013 06:13 PM, Jon Hunter wrote:
Hi Jon, thanks a lot for your feedback.
On 03/10/2013 12:18 PM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the GPMC as a data bus.
The actual mapping between the GPMC address space and OMAP2+
address space is made using the GPMC DT ranges property.
But also a explicit call to gpmc_cs_request() is needed.
One problem with gpmc_cs_request() is that it will map the chip-select
to any physical location in the 1GB address space for the gpmc
controller. So in other words, it will ignore the ranges property
altogether. If you look at my code for NOR, I have added a
gpmc_cs_remap() function to remap the cs to the location as specified by
the device-tree.
I see, thanks for pointing this out.
Ideally we should change gpmc_cs_request() so we can pass the desire
base address that we want to map the gpmc cs too. I had started out that
way but it made the code some what messy and so I opted to create a
gpmc_cs_remap() function instead. The goal will be to get rid of
gpmc_cs_remap() once DT migration is completed and we can change
gpmc_cs_request() to map the cs to a specific address (see my FIXME
comment).
By looking at gpmc_probe_onenand_child() and gpmc_probe_nand_child() I see
that
these functions just allocates platform data and call gpmc_onenand_init() and
gpmc_nand_init() accordingly. So if I understood right these functions have
the
same issue and need to call gpmc_cs_remap() too in order to map to the
location
specified on the DT.
Ideally they should but it is not critical.
So today for NAND and ONENAND the ranges property is completely ignored
(I just came to realise this recently). However, this works because the
address mapped by gpmc_cs_request() is passed to the NAND/ONENAND
drivers via the platform data. However, NOR (and your ethernet patch) we
can't pass via platform data and therefore we must remap.
This needs to be fixed, but it is not critical in terms that it won't
crash. However, I fear your ethernet patch could :-o
Your code probably works today because the cs is setup by the bootloader
and so when you request the cs in the kernel the mapping is not changed
from the bootloader settings. However, if the mapping in DT (ranges
property) is different from that setup by the bootloader then the kernel
would probably crash because the kernel would not remap it as expected.
So, this patch allows an ethernet chip to be defined as an
GPMC child node an its chip-select memory address be requested.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Jon,
This patch assumes that we have solved somehow the issue that a
call to request_irq() is needed before before using a GPIO as an
IRQ and this is no longer the case when using from Device Trees.
Anyway, this is independent as how we solve this, whether is
using Jan's patch [1], adding a .request function pointer to
irq_chip as suggested by Stephen [2], or any other approach.
[1]: https://patchwork.kernel.org/patch/2009331/
[2]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85592.html
arch/arm/mach-omap2/gpmc.c | 45
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 4fe9ee7..d1bf48b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -29,6 +29,7 @@
#include linux/of.h
#include linux/of_mtd.h
#include linux/of_device.h
+#include linux/of_address.h
#include linux/mtd/nand.h
#include linux/platform_data/mtd-nand-omap2.h
@@ -1296,6 +1297,42 @@ static int gpmc_probe_onenand_child(struct
platform_device *pdev,
}
#endif
+static int gpmc_probe_ethernet_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ int ret, cs;
+ unsigned long base;
+ struct resource res;
+ struct platform_device *of_dev;
+
+ if (of_property_read_u32(child, reg, cs) 0) {
+ dev_err(pdev-dev, %s has no 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ if (of_address_to_resource(child, 0, res)) {
+ dev_err(pdev-dev, %s has malformed 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ ret = gpmc_cs_request(cs, resource_size(res), base);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(pdev-dev, cannot request GPMC CS %d\n, cs);
+ return ret;
+ }
+
+ of_dev = of_platform_device_create(child, NULL, pdev-dev);
+ if (!of_dev) {
+ dev_err(pdev-dev, cannot create platform device
[PATCH 1/1] ARM: OMAP: gpmc: request CS address space for ethernet chips
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the GPMC as a data bus.
The actual mapping between the GPMC address space and OMAP2+
address space is made using the GPMC DT ranges property.
But also a explicit call to gpmc_cs_request() is needed.
So, this patch allows an ethernet chip to be defined as an
GPMC child node an its chip-select memory address be requested.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Jon,
This patch assumes that we have solved somehow the issue that a
call to request_irq() is needed before before using a GPIO as an
IRQ and this is no longer the case when using from Device Trees.
Anyway, this is independent as how we solve this, whether is
using Jan's patch [1], adding a .request function pointer to
irq_chip as suggested by Stephen [2], or any other approach.
[1]: https://patchwork.kernel.org/patch/2009331/
[2]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85592.html
arch/arm/mach-omap2/gpmc.c | 45
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 4fe9ee7..d1bf48b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -29,6 +29,7 @@
#include linux/of.h
#include linux/of_mtd.h
#include linux/of_device.h
+#include linux/of_address.h
#include linux/mtd/nand.h
#include linux/platform_data/mtd-nand-omap2.h
@@ -1296,6 +1297,42 @@ static int gpmc_probe_onenand_child(struct
platform_device *pdev,
}
#endif
+static int gpmc_probe_ethernet_child(struct platform_device *pdev,
+struct device_node *child)
+{
+ int ret, cs;
+ unsigned long base;
+ struct resource res;
+ struct platform_device *of_dev;
+
+ if (of_property_read_u32(child, reg, cs) 0) {
+ dev_err(pdev-dev, %s has no 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ if (of_address_to_resource(child, 0, res)) {
+ dev_err(pdev-dev, %s has malformed 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ ret = gpmc_cs_request(cs, resource_size(res), base);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(pdev-dev, cannot request GPMC CS %d\n, cs);
+ return ret;
+ }
+
+ of_dev = of_platform_device_create(child, NULL, pdev-dev);
+ if (!of_dev) {
+ dev_err(pdev-dev, cannot create platform device for %s\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
static int gpmc_probe_dt(struct platform_device *pdev)
{
int ret;
@@ -1326,6 +1363,14 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
}
+
+ for_each_node_by_name(child, ethernet) {
+ ret = gpmc_probe_ethernet_child(pdev, child);
+ if (ret 0) {
+ of_node_put(child);
+ return ret;
+ }
+ }
return 0;
}
#else
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter jon-hun...@ti.com wrote:
Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 11 +++
arch/arm/boot/dts/omap2430.dtsi | 11 +++
arch/arm/boot/dts/omap4.dtsi| 11 +++
arch/arm/boot/dts/omap5.dtsi| 11 +++
4 files changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index af65609..d4ce6c2 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -29,6 +29,17 @@
pinctrl-single,function-mask = 0x3f;
};
+ gpmc: gpmc@6800a000 {
+ compatible = ti,omap2420-gpmc;
+ reg = 0x6800a000 0x1000;
+ #address-cells = 2;
+ #size-cells = 1;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ ti,hwmods = gpmc;
+ };
+
mcbsp1: mcbsp@48074000 {
compatible = ti,omap2420-mcbsp;
reg = 0x48074000 0xff;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index c392445..832f184 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -29,6 +29,17 @@
pinctrl-single,function-mask = 0x3f;
};
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap2430-gpmc;
+ reg = 0x6e00 0x1000;
+ #address-cells = 2;
+ #size-cells = 1;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ ti,hwmods = gpmc;
+ };
+
mcbsp1: mcbsp@48074000 {
compatible = ti,omap2430-mcbsp;
reg = 0x48074000 0xff;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 827f6f3..726ef11 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -196,6 +196,17 @@
#interrupt-cells = 1;
};
+ gpmc: gpmc@5000 {
+ compatible = ti,omap4430-gpmc;
+ reg = 0x5000 0x1000;
Hi Jon,
By looking at the GPMC Register Summary from both the OMAP4460 and OMAP OMAP35x
Technical Reference Manuals I see that the GPMC register address space
is only 720 bytes length. From base address + 0x0 to base address +
0x02d0.
So shouldn't the regs property be 0x5000 0x2d0 instead?
Of course are only a few kilobytes but still I wonder if it makes
sense to map them when they are not going to be used.
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote:
On 03/08/2013 02:25 PM, Javier Martinez Canillas wrote:
On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter jon-hun...@ti.com wrote:
Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 11 +++
arch/arm/boot/dts/omap2430.dtsi | 11 +++
arch/arm/boot/dts/omap4.dtsi| 11 +++
arch/arm/boot/dts/omap5.dtsi| 11 +++
4 files changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/omap2420.dtsi
b/arch/arm/boot/dts/omap2420.dtsi
index af65609..d4ce6c2 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -29,6 +29,17 @@
pinctrl-single,function-mask = 0x3f;
};
+ gpmc: gpmc@6800a000 {
+ compatible = ti,omap2420-gpmc;
+ reg = 0x6800a000 0x1000;
+ #address-cells = 2;
+ #size-cells = 1;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ ti,hwmods = gpmc;
+ };
+
mcbsp1: mcbsp@48074000 {
compatible = ti,omap2420-mcbsp;
reg = 0x48074000 0xff;
diff --git a/arch/arm/boot/dts/omap2430.dtsi
b/arch/arm/boot/dts/omap2430.dtsi
index c392445..832f184 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -29,6 +29,17 @@
pinctrl-single,function-mask = 0x3f;
};
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap2430-gpmc;
+ reg = 0x6e00 0x1000;
+ #address-cells = 2;
+ #size-cells = 1;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ ti,hwmods = gpmc;
+ };
+
mcbsp1: mcbsp@48074000 {
compatible = ti,omap2430-mcbsp;
reg = 0x48074000 0xff;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 827f6f3..726ef11 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -196,6 +196,17 @@
#interrupt-cells = 1;
};
+ gpmc: gpmc@5000 {
+ compatible = ti,omap4430-gpmc;
+ reg = 0x5000 0x1000;
Hi Jon,
By looking at the GPMC Register Summary from both the OMAP4460 and OMAP
OMAP35x
Technical Reference Manuals I see that the GPMC register address space
is only 720 bytes length. From base address + 0x0 to base address +
0x02d0.
So shouldn't the regs property be 0x5000 0x2d0 instead?
Of course are only a few kilobytes but still I wonder if it makes
sense to map them when they are not going to be used.
Yes you are correct. In general, I have been trying to stay some-what
consistent with what hwmod was doing as this was being auto-generated by
some hardware design specs and I believe they wanted to eventually get
to the point where DT files would be auto-generated too for OMAP.
Furthermore my understanding is that the smallest page that can be
mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or
0x1000 it will map a 4kB page (I could be wrong here).
I don't have any strong feelings here but will do what the consensus
prefers.
Yes, you are right here.
I forget that ioremap() does a page-aligned mapping and since the
minimum page size for ARM is 4KB as you said, there is no difference
between using 0x2d0 and 0x1000. Sorry for the noise.
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cheers
Jon
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 11/17] ARM: OMAP2+: Add device-tree support for NOR flash
On Fri, Mar 8, 2013 at 5:58 PM, Jon Hunter jon-hun...@ti.com wrote:
NOR flash is not currently supported when booting with device-tree
on OMAP2+ devices. Add support to detect and configure NOR devices
when booting with device-tree.
Add documentation for the TI GPMC NOR binding.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Documentation/devicetree/bindings/mtd/gpmc-nor.txt | 98 +
arch/arm/mach-omap2/gpmc.c | 113
2 files changed, 211 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nor.txt
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
new file mode 100644
index 000..8c638fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
@@ -0,0 +1,98 @@
+Device tree bindings for NOR flash connect to TI GPMC
+
+NOR flash connected to the TI GPMC (found on OMAP boards) are represented as
+child nodes of the GPMC controller with a name of nor.
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- bank-width: Width of NOR flash in bytes. GPMC supports 8-bit and
+ 16-bit devices and so must be either 1 or 2 bytes.
+- compatible: Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+- gpmc,cs-on: Chip-select assertion time
+- gpmc,cs-rd-off: Chip-select de-assertion time for reads
+- gpmc,cs-wr-off: Chip-select de-assertion time for writes
+- gpmc,oe-on: Output-enable assertion time
+- gpmc,oe-off Output-enable de-assertion time
+- gpmc,we-on: Write-enable assertion time
+- gpmc,we-off: Write-enable de-assertion time
+- gpmc,access: Start cycle to first data capture (read access)
+- gpmc,rd-cycle: Total read cycle time
+- gpmc,wr-cycle: Total write cycle time
+- linux,mtd-name: Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+- reg: Chip-select, base address (relative to chip-select)
+ and size of NOR flash. Note that base address will be
+ typically 0 as this is the start of the chip-select.
+
+Optional properties:
+- gpmc,XXX Additional GPMC timings and settings parameters. See
+ Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Optional properties for partiton table parsing:
+- #address-cells: should be set to 1
+- #size-cells: should be set to 1
+
+Example:
+
+gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc, simple-bus;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x1000;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ ranges = 0 0 0x1000 0x0800;
+
+ nor@0,0 {
+ compatible = cfi-flash;
+ linux,mtd-name= intel,pf48f6000m0y1be;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0 0 0x0800;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 186;
+ gpmc,cs-wr-off = 186;
+ gpmc,adv-on = 12;
+ gpmc,adv-rd-off = 48;
+ gpmc,adv-wr-off = 48;
+ gpmc,oe-on = 54;
+ gpmc,oe-off = 168;
+ gpmc,we-on = 54;
+ gpmc,we-off = 168;
+ gpmc,rd-cycle = 186;
+ gpmc,wr-cycle = 186;
+ gpmc,access = 114;
+ gpmc,page-burst-access = 6;
+ gpmc,bus-turnaround = 12;
+ gpmc,cycle2cycle-delay = 18;
+ gpmc,wr-data-mux-bus = 90;
+ gpmc,wr-access = 186;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ partition@0 {
+ label = bootloader-nor;
+ reg = 0 0x4;
+ };
+ partition@0x4 {
+ label = params-nor;
+ reg = 0x4 0x4;
+ };
+ partition@0x8 {
+ label = kernel-nor;
+ reg = 0x8 0x20;
+ };
+ partition@0x28 {
+ label = filesystem-nor;
+ reg = 0x24 0x7d8;
+ };
+ };
+};
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 80808ad..05ca0af 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -26,6 +26,7 @@
#include linux/interrupt.h
#include linux/platform_device.h
[PATCH 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
The binding documentation for the OMAP GPIO controller has the description for the #interrupt-cells property after the interrupt-controller definition. This is confusing so is better to move interrupt-controller after the #interrupt-cells description. Reported-by: Stephen Warren swar...@nvidia.com Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- .../devicetree/bindings/gpio/gpio-omap.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt b/Documentation/devicetree/bindings/gpio/gpio-omap.txt index bff51a2..8b9914c 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt @@ -10,7 +10,6 @@ Required properties: - second cell is used to specify optional parameters (unused) - gpio-controller : Marks the device node as a GPIO controller. - #interrupt-cells : Should be 2. -- interrupt-controller: Mark the device node as an interrupt controller The first cell is the GPIO number. The second cell is used to specify flags: bits[3:0] trigger type and level flags: @@ -18,6 +17,7 @@ Required properties: 2 = high-to-low edge triggered. 4 = active high level-sensitive. 8 = active low level-sensitive. +- interrupt-controller: Mark the device node as an interrupt controller. OMAP specific properties: - ti,hwmods: Name of the hwmod associated to the GPIO: -- 1.7.7.6 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
The binding documentation for the OMAP GPIO controller has the description
for the #interrupt-cells property after the interrupt-controller.
This is confusing so is better to move the interrupt-controller after
#interrupt-cells description.
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
Documentation/devicetree/bindings/gpio/gpio.txt.
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- ti,omap2-gpio for OMAP2 controllers
- ti,omap3-gpio for OMAP3 controllers
- ti,omap4-gpio for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
-#gpio-cells = 2;
gpio-controller;
-#interrupt-cells = 2;
+#gpio-cells = 2;
interrupt-controller;
+#interrupt-cells = 2;
};
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
omap: IORESOURCE_IRQ flags not set when defining a GPIO-IRQ from DT
Hi Jon,
NOTE: I'm changing $subject to something more relevant to stop adding
noise on the original thread.
On Thu, Feb 28, 2013 at 9:49 PM, Jon Hunter jon-hun...@ti.com wrote:
On 02/28/2013 06:17 AM, Javier Martinez Canillas wrote:
On Thu, Feb 28, 2013 at 12:16 AM, Jon Hunter jon-hun...@ti.com wrote:
On 02/26/2013 09:57 PM, Javier Martinez Canillas wrote:
[snip]
Something like that would definitely solve the GPIO request issue but
we still have the issue that the current OMAP GPIO controller binding
does not support #interrupt-cells = 2.
So, we can't pass the trigger type and level flags for an IRQ-GPIO
when using an GPIO controller as the interrupt-parent for a device
node.
Do you have any comments on that issue?
Can you elaborate a bit more on why you say this is not supported?
I have been playing with this today on an omap board and if I set the
#interrupt-cells = 2, then I do see that irq_domain_xlate_onetwocell()
is called and the irq number and flags read as expected. Following which
I then see it will call the omap_irq_type() to set type. So AFAICT it works.
Yes, it does.
I (wrongly) assumed that it was not working since the GPIO OMAP
binding documentation says that #interrupt-cells should be 2 but all
OMAP2+ DTs use 1 instead. Also, when trying to change to 2 I had
the kernel hang.
But it was indeed that the GPIO bank was not enabled before calling
gpio_irq_type() and this made the kernel to hang. Your patch fixed the
issue and allowed me to find the cause.
The problem was that when using the DT hack of defining the GPIO in
the ethernet chip regulator, the calls to
irq_domain_xlate_onetwocell() and gpio_irq_type() were made before the
call to gpio_request_one() so the GPIO bank was not enabled.
If gpio_request() is called in gpmc_probe_dt(), then the GPIO bank is
enabled and gpio_irq_type() succeeds.
So, it was just me being stupid and don't understanding the implementation.
No problem. Glad we are on the same page :-)
Please note I do see that when the SMC driver calls request_irq() in
smc_drv_probe() it is also settings the trigger type to
IRQ_TYPE_EDGE_RISING (default). So if you are setting to low-level
sensitive in DT, then this is being overwritten. We could fix this by
setting SMC_IRQ_FLAGS to -1 for OMAP.
Please note that I'm using a SMSC 911x chip and not a SMSC 91x, so the
driver is not smc91x but smc911x. It has the same behaviour though
(IRQ flags overwritten somehow), just to be sure that we are on the
same page.
I don't know if just setting SMC_IRQ_FLAGS to -1 will be enough to fix
the smc91x since request_irq() is just passing whatever value is in
irq_flags.
By looking at the two drivers (smc91x and smsc911x) it seems that the
only difference on how they manage the flags is that smc91x does:
unsigned long irq_flags = SMC_IRQ_FLAGS;
...
if (irq_flags == -1 || ires-flags IRQF_TRIGGER_MASK)
irq_flags = ires-flags IRQF_TRIGGER_MASK;
while smsc911x driver's probe function uses the flags from the
resource unconditionally:
irq_flags = irq_res-flags IRQF_TRIGGER_MASK;
So, at the end both will set irq_flags to whatever is on the
IORESOURCE_IRQ struct resource flags member.
Actually, that's not the case for smc91x. By default SMC_IRQ_FLAGS != -1
(for omap) and so it will not set irq_flags to ires-flags
IRQF_TRIGGER_MASK. However, if I force irq_flags to be -1, then I see
that irq_flags are to 0.
Yes, I meant that the behaviour is the same if you define
SMC_IRQ_FLAGS to -1 for omap.
The real problem is irq_flags to be 0 instead of the value defined on
the second cell of the interrupts property.
So the resource flags for each irq is set in
of_irq_to_resource() which just does ...
r-start = r-end = irq;
r-flags = IORESOURCE_IRQ;
r-name = name ? name : dev-full_name;
of_irq_to_resource() calls irq_to_parse_and_map() which eventually just
calls irq_set_irq_type() but type/flags is not returned and not populated.
I am wondering if this is intentional.
Indeed, I was wondering the same.
The irq_type is being correctly
configured by irq_set_irq_type() when of_irq_to_resource() is called. In
the smc driver, if irq_flags are 0, then when request_irq() is called
the trigger type will not be set again (which is ok). __setup_irq has
the following ...
/* Setup the type (level, edge polarity) if configured: */
if (new-flags IRQF_TRIGGER_MASK) {
ret = __irq_set_trigger(desc, irq,
new-flags IRQF_TRIGGER_MASK);
Cheers
Jon
I'll try to take a deeper look to this later next week.
Thanks a lot for your help!
Regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
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
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Thu, Feb 28, 2013 at 12:16 AM, Jon Hunter jon-hun...@ti.com wrote: On 02/26/2013 09:57 PM, Javier Martinez Canillas wrote: [snip] Something like that would definitely solve the GPIO request issue but we still have the issue that the current OMAP GPIO controller binding does not support #interrupt-cells = 2. So, we can't pass the trigger type and level flags for an IRQ-GPIO when using an GPIO controller as the interrupt-parent for a device node. Do you have any comments on that issue? Can you elaborate a bit more on why you say this is not supported? I have been playing with this today on an omap board and if I set the #interrupt-cells = 2, then I do see that irq_domain_xlate_onetwocell() is called and the irq number and flags read as expected. Following which I then see it will call the omap_irq_type() to set type. So AFAICT it works. Yes, it does. I (wrongly) assumed that it was not working since the GPIO OMAP binding documentation says that #interrupt-cells should be 2 but all OMAP2+ DTs use 1 instead. Also, when trying to change to 2 I had the kernel hang. But it was indeed that the GPIO bank was not enabled before calling gpio_irq_type() and this made the kernel to hang. Your patch fixed the issue and allowed me to find the cause. The problem was that when using the DT hack of defining the GPIO in the ethernet chip regulator, the calls to irq_domain_xlate_onetwocell() and gpio_irq_type() were made before the call to gpio_request_one() so the GPIO bank was not enabled. If gpio_request() is called in gpmc_probe_dt(), then the GPIO bank is enabled and gpio_irq_type() succeeds. So, it was just me being stupid and don't understanding the implementation. Please note I do see that when the SMC driver calls request_irq() in smc_drv_probe() it is also settings the trigger type to IRQ_TYPE_EDGE_RISING (default). So if you are setting to low-level sensitive in DT, then this is being overwritten. We could fix this by setting SMC_IRQ_FLAGS to -1 for OMAP. Please note that I'm using a SMSC 911x chip and not a SMSC 91x, so the driver is not smc91x but smc911x. It has the same behaviour though (IRQ flags overwritten somehow), just to be sure that we are on the same page. I don't know if just setting SMC_IRQ_FLAGS to -1 will be enough to fix the smc91x since request_irq() is just passing whatever value is in irq_flags. By looking at the two drivers (smc91x and smsc911x) it seems that the only difference on how they manage the flags is that smc91x does: unsigned long irq_flags = SMC_IRQ_FLAGS; ... if (irq_flags == -1 || ires-flags IRQF_TRIGGER_MASK) irq_flags = ires-flags IRQF_TRIGGER_MASK; while smsc911x driver's probe function uses the flags from the resource unconditionally: irq_flags = irq_res-flags IRQF_TRIGGER_MASK; So, at the end both will set irq_flags to whatever is on the IORESOURCE_IRQ struct resource flags member. The real problem is irq_flags to be 0 instead of the value defined on the second cell of the interrupts property. when irq_domain_xlate_onetwocell() is called for the ethernet GPIO-IRQ I see that both the cells size and the second cell with the flag values are set correctly (2 and IRQF_TRIGGER_LOW). But even when gpio_irq_type() succeeds it seems that the struct resource IRQ flags passed to the smsc911x driver is still overwritten or not set correctly since flags IRQF_TRIGGER_MASK is always 0. In general we do need to fix the gpio binding for omap to default to #interrupt-cell = 2, as this should work. However, before we can do that we need to fix the issue of ensuring the gpio module is enabled if being used as an interrupt source without having to call gpio_request() first. Indeed, although I still wonder why the flags are not set correctly for the smsc911x driver. I had only tested it with this device so I don't know if this is a general issue of IORESOURCE_IRQ structs not been initialized correctly when using GPIOs as IRQ on OMAP or if is only related to this driver. We should probably add the following patch as well to avoid any hangs if the bank is not enabled, when omap_irq_type is called. commit 5e298de564e09f5ca4148a9bc0ed5d16b4742f14 Author: Jon Hunter jon-hun...@ti.com Date: Wed Feb 27 17:14:11 2013 -0600 gpio/omap: warn if gpio bank is not enabled on setting irq type diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index f1fbedb2..cbdc796 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -421,6 +421,9 @@ static int gpio_irq_type(struct irq_data *d, unsigned type) int retval; unsigned long flags; + if (WARN_ON(!bank-mod_usage)) + return -EINVAL; + #ifdef CONFIG_ARCH_OMAP1 if (d-irq IH_MPUIO_BASE) gpio = OMAP_MPUIO(d-irq - IH_MPUIO_BASE); Cheers Jon Thanks a lot for your help and best regards, Javier ___ devicetree-discuss
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Wed, Feb 27, 2013 at 6:47 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/26/2013 08:33 PM, Javier Martinez Canillas wrote:
...
Yes, I realized that requesting the gpio was necessary so what I did
is to use the regulator-fixed optional property gpio and define
the GPIO used as an IRQ in a regulator used by the SMSC chip. So, I
have this on my board DT:
vddvario: regulator-vddvario {
compatible = regulator-fixed;
regulator-name = vddvario;
regulator-always-on;
gpio = gpio6 16 8; /* gpio line 176 */
enable-active-high;
gpio-open-drain;
While admittedly it's configured as open-drain, that will configure the
GPIO to be an output, whereas for usage as an interrupt, it really
should be configured as an input... Perhaps it makes no difference on
OMAP HW since the I/O paths are separate, but I can easily imagine HW
where this hack wouldn't work.
regulator-boot-on;
};
gpmc {
ethernet@5,0 {
pinctrl-names = default;
pinctrl-0 = smsc911x_pins;
compatible = smsc,lan9221, smsc,lan9115;
reg = 5 0 0xff;
interrupt-parent = gpio6;
interrupts = 16 8; /* gpio line 176 */
interrupt-names = smsc911x irq;
vmmc-supply = vddvario;
vmmc_aux-supply = vdd33a;
reg-io-width = 4;
smsc,save-mac-address;
};
};
That way a call to gpio_request_one() is made and the GPIO is requested.
This look a little hack-ish for me but I've seen this in other
DeviceTrees like omap4-sdp.dts so I thought it was a common DT
pattern.
Indeed; the GPIO is in no way a regulator, so while the above is fine
for testing, it's in no way a solution that can actually be used and
checked in.
Yes, this is just a work-in-progress and is not meant to be taken as a
patch submission.
I'm just doing some testing with DT and figuring out how much effort
will take to have the same hardware support we currently with board
files for IGEP boards.
Thanks a lot for your feedback and best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Wed, Feb 27, 2013 at 6:50 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 02/26/2013 08:57 PM, Javier Martinez Canillas wrote: On Wed, Feb 27, 2013 at 2:07 AM, Jon Hunter jon-hun...@ti.com wrote: On 02/26/2013 06:13 PM, Stephen Warren wrote: On 02/26/2013 04:45 PM, Jon Hunter wrote: ... One issue I see is that by not calling gpio_request, then potentially you could have someone request a gpio via gpio_request() and someone trying to use it as an interrupt source via request_irq(). Now obviously that represents a bug because there is only one physical gpio, but I gather it is something we need to protect against. I'm not sure it's really that much of an issue, but presumably the solution is for a combined GPIO+IRQ driver to simply call gpio_request internally from within some irq_chip function. It looks like struct irq_chip doesn't have a request/free, but perhaps they could be added to solve this? Yes I was wondering if we could do something like that. That would work, may be that's what we should propose. Something like that would definitely solve the GPIO request issue but we still have the issue that the current OMAP GPIO controller binding does not support #interrupt-cells = 2. The binding documentation in Documentation/devicetree/bindings/gpio/gpio-omap.txt indicates that it does. If this doesn't work in practice, it's a driver bug that can presumably be easily fixed. And no need to change any ABI definitions:-) indeed :-) In fact I think that some documentation bits were borrowed from the NVIDIA Tegra GPIO controller bindings but it was never implemented in the OMAP GPIO driver to parse the second interrupt-cell which should specify the flags. BTW, I notice in that binding document that the description of the two cells for #interrupt-cells is actually part of the description of the interrupt-controller property; it should be moved up one line really. Right, will submit a patch to fix this. Best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Fri, Feb 24, 2012 at 4:30 PM, Cousson, Benoit b-cous...@ti.com wrote:
On 2/22/2012 7:29 PM, Stephen Warren wrote:
Rob Herring wrote at Wednesday, February 22, 2012 10:23 AM:
On 02/22/2012 08:31 AM, Cousson, Benoit wrote:
On 2/22/2012 3:23 PM, Rob Herring wrote:
On 02/15/2012 10:04 AM, Benoit Cousson wrote:
Adapt the GPIO driver to retrieve information from a DT file.
Allocate the irq_base dynamically and rename bank-virtual_irq_start
to bank-irq_base.
Change irq_base type to int instead of u16 to match irq_alloc_descs
output.
Add documentation for GPIO properties specific to OMAP.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Tarun Kanti DebBarmatarun.ka...@ti.com
One comment below, but otherwise:
Acked-by: Rob Herringrob.herr...@calxeda.com
---
.../devicetree/bindings/gpio/gpio-omap.txt | 30 +
drivers/gpio/gpio-omap.c | 121
++--
2 files changed, 142 insertions(+), 9 deletions(-)
create mode 100644
Documentation/devicetree/bindings/gpio/gpio-omap.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
new file mode 100644
index 000..c1b3100
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -0,0 +1,30 @@
+OMAP GPIO controller bindings
+
+Required properties:
+- compatible:
+ - ti,omap2-gpio for OMAP2 controllers
+ - ti,omap3-gpio for OMAP3 controllers
+ - ti,omap4-gpio for OMAP4 controllers
+- #gpio-cells : Should be two.
+ - first cell is the pin number
+ - second cell is used to specify optional parameters (unused)
+- gpio-controller : Marks the device node as a GPIO controller.
+- #interrupt-cells : Should be one
There's no level/edge settings for gpios?
That's a good question, because I was wondering as well :-)
I did no see how it was done in other GPIO implementation.
There's not really a good example that I've found. Many gpio nodes don't
even have interrupt-controller set.
So if you have an irq_set_type function for gpio's, then you should have
2 cells.
After checking the OMAP gpio code, I do have a gpio_irq_type and the GPIO do
support the 4 types. I'm not sure yet about the combinations.
Tegra's GPIO IRQ binding (gpio_nvidia.txt in linux-next at least) says:
- #interrupt-cells : Should be 2.
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.
Valid combinations are 1, 2, 3, 4, 8.
Indeed, so I'll just copy / paste Tegra's binding...
Thanks,
Benoit
Hello,
I was wondering if the level/edge settings for gpios is working on OMAP.
I'm adding DT support for an SMSC911x ethernet chip connected to the
GPMC for an OMAP3 SoC based board.
In the smsc911x driver probe function (smsc911x_drv_probe() in
drivers/net/ethernet/smsc/smsc911x.c), a call to request_irq() with
the flag IRQF_TRIGGER_LOW is needed because of the wiring on my board.
Reading the gpio-omap.txt documentation it says that #interrupt-cells
should be 2 and that a value of 8 is active low level-sensitive.
So I tried this:
gpmc {
ethernet@5,0 {
pinctrl-names = default;
pinctrl-0 = smsc911x_pins;
compatible = smsc,lan9221, smsc,lan9115;
reg = 5 0 0xff; /* CS5 */
interrupt-parent = gpio6;
interrupts = 16 8; /* gpio line 176 */
interrupt-names = smsc911x irq;
vmmc-supply = vddvario;
vmmc_aux-supply = vdd33a;
reg-io-width = 4;
smsc,save-mac-address;
};
};
But in the smsc911x probe function:
irq_res-flags IRQF_TRIGGER_MASK;
returns 0 which means that no trigger flags where set.
I took a look to the GPIOs device node definition on omap{3,4,5}.dtsi
and all look like this:
e.g from omap3.dtsi:
gpio6: gpio@49058000 {
compatible = ti,omap3-gpio;
ti,hwmods = gpio6;
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 1;
};
So, even when the documentation says that all the GPIO device nodes in
OMAP2+ should use a #interrupt-cells property value of 2, they are
only using 1. Changing that value to 2 makes hangs the kernel and it
does not boot.
This is not part of my dayjob and I'm working on this in my free time
so it would be great if someone can give me some pointers or at least
confirm that this is a known issue so I can debug/fix/extend
drivers/gpio/gpio-omap.c to parse and pass the IRQF_TRIGGER_* flags
to the IORESOURCE_IRQ resource structure.
Thanks
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Tue, Feb 26, 2013 at 11:40 PM, Jon Hunter jon-hun...@ti.com wrote:
On 02/26/2013 04:01 AM, Javier Martinez Canillas wrote:
[snip]
I was wondering if the level/edge settings for gpios is working on OMAP.
I'm adding DT support for an SMSC911x ethernet chip connected to the
GPMC for an OMAP3 SoC based board.
In the smsc911x driver probe function (smsc911x_drv_probe() in
drivers/net/ethernet/smsc/smsc911x.c), a call to request_irq() with
the flag IRQF_TRIGGER_LOW is needed because of the wiring on my board.
Reading the gpio-omap.txt documentation it says that #interrupt-cells
should be 2 and that a value of 8 is active low level-sensitive.
So I tried this:
gpmc {
ethernet@5,0 {
pinctrl-names = default;
pinctrl-0 = smsc911x_pins;
compatible = smsc,lan9221, smsc,lan9115;
reg = 5 0 0xff; /* CS5 */
interrupt-parent = gpio6;
interrupts = 16 8; /* gpio line 176 */
interrupt-names = smsc911x irq;
vmmc-supply = vddvario;
vmmc_aux-supply = vdd33a;
reg-io-width = 4;
smsc,save-mac-address;
};
};
Are you requesting the gpio anywhere? If not then this is not going to
work as-is. This was discussed fairly recently [1] and the conclusion
was that the gpio needs to be requested before we can use as an interrupt.
I have not seen your latest smsc code for omap, but when you are
requesting the gpmc chip-select you should also request the gpio.
Yes, I realized that requesting the gpio was necessary so what I did
is to use the regulator-fixed optional property gpio and define
the GPIO used as an IRQ in a regulator used by the SMSC chip. So, I
have this on my board DT:
vddvario: regulator-vddvario {
compatible = regulator-fixed;
regulator-name = vddvario;
regulator-always-on;
gpio = gpio6 16 8; /* gpio line 176 */
enable-active-high;
gpio-open-drain;
regulator-boot-on;
};
gpmc {
ethernet@5,0 {
pinctrl-names = default;
pinctrl-0 = smsc911x_pins;
compatible = smsc,lan9221, smsc,lan9115;
reg = 5 0 0xff;
interrupt-parent = gpio6;
interrupts = 16 8; /* gpio line 176 */
interrupt-names = smsc911x irq;
vmmc-supply = vddvario;
vmmc_aux-supply = vdd33a;
reg-io-width = 4;
smsc,save-mac-address;
};
};
That way a call to gpio_request_one() is made and the GPIO is requested.
This look a little hack-ish for me but I've seen this in other
DeviceTrees like omap4-sdp.dts so I thought it was a common DT
pattern.
But in the smsc911x probe function:
irq_res-flags IRQF_TRIGGER_MASK;
returns 0 which means that no trigger flags where set.
I took a look to the GPIOs device node definition on omap{3,4,5}.dtsi
and all look like this:
e.g from omap3.dtsi:
gpio6: gpio@49058000 {
compatible = ti,omap3-gpio;
ti,hwmods = gpio6;
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 1;
};
So, even when the documentation says that all the GPIO device nodes in
OMAP2+ should use a #interrupt-cells property value of 2, they are
only using 1. Changing that value to 2 makes hangs the kernel and it
does not boot.
I will need to take a look at that. Is your code available anywhere so I
can test?
Of course, I pushed a gpmc-smsc911x branch to my github linux repository [2].
The branch is latest Linus' master + Benoit's linux-omap-dt/for_3.9/dts +
ARM: OMAP2+: Prevent potential crash if GPMC probe fails [3] +
ARM: dts: OMAP3: Add GPMC controller [4] + my patches:
Javier Martinez Canillas (5):
ARM: dts: OMAP3: reduce GPMC mapped registers address space
ARM: dts: OMAP3: make GPMC node compatible with simple-bus
ARM: dts: OMAP3: add ranges property for GPMC chip-select 5
ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support
smsc: smc911x: (HACK) force active low polarity for IRQ
The last patch is just an ugly hack that forces the IRQ flags to
active low level-sensitive so the SMSC911x IRQ is triggered on my
board (IGEPv2).
I just added for testing purposes since the omap3-gpio
interrupt-controller #interrupt-cells = 2 seems to not be working
and I can't pass this flag when defining the IRQ in the smsc911x
ethernet device node.
Cheers
Jon
Thanks a lot for your help and best regards,
Javier
[1]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/92192
[2]: https://github.com/martinezjavier/linux.git
[3]: https://patchwork.kernel.org/patch/2118831/
[4]: https://patchwork.kernel.org/patch/2057111/
___
devicetree
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Wed, Feb 27, 2013 at 12:08 AM, Jon Hunter jon-hun...@ti.com wrote:
On 02/26/2013 04:01 AM, Javier Martinez Canillas wrote:
[snip]
I was wondering if the level/edge settings for gpios is working on OMAP.
I'm adding DT support for an SMSC911x ethernet chip connected to the
GPMC for an OMAP3 SoC based board.
In the smsc911x driver probe function (smsc911x_drv_probe() in
drivers/net/ethernet/smsc/smsc911x.c), a call to request_irq() with
the flag IRQF_TRIGGER_LOW is needed because of the wiring on my board.
Reading the gpio-omap.txt documentation it says that #interrupt-cells
should be 2 and that a value of 8 is active low level-sensitive.
So I tried this:
gpmc {
ethernet@5,0 {
pinctrl-names = default;
pinctrl-0 = smsc911x_pins;
compatible = smsc,lan9221, smsc,lan9115;
reg = 5 0 0xff; /* CS5 */
interrupt-parent = gpio6;
interrupts = 16 8; /* gpio line 176 */
interrupt-names = smsc911x irq;
vmmc-supply = vddvario;
vmmc_aux-supply = vdd33a;
reg-io-width = 4;
By the way, reg-io-width for omap does not look correct. The GPMC only
supports 8-bit or 16-bit devices IIRC. I believe all my omap boards use
16-bit.
I thought that even when the GPMC was a 16-bit external memory
controller it could do some access adaptation to support 32-bit
devices.
By looking at the board files for others OMAP3 based boards
(board-{omap3evm,overo,zoom-debugboard}.c) most of them set the struct
omap_smsc911x_platform_data .flags member to SMSC911X_USE_32BIT.
And by looking at Documentation/devicetree/bindings/net/smsc911x.txt I
thought that the corresponding DT property for this flag was
reg-io-width
Anyway, I tried using both reg-io-width = 4 and reg-io-width = 2.
The ethernet chip works with both of them and I don't see too much
difference in performance:
16-bit
round-trip min/avg/max = 0.611/0.738/0.946 ms
32-bit
round-trip min/avg/max = 0.519/0.690/0.976 ms
So, is your call ;-)
Cheers
Jon
Thanks a lot for your help,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Wed, Feb 27, 2013 at 2:07 AM, Jon Hunter jon-hun...@ti.com wrote:
On 02/26/2013 06:13 PM, Stephen Warren wrote:
On 02/26/2013 04:45 PM, Jon Hunter wrote:
On 02/26/2013 05:06 PM, Stephen Warren wrote:
On 02/26/2013 04:01 PM, Jon Hunter wrote:
On 02/26/2013 04:44 PM, Stephen Warren wrote:
On 02/26/2013 03:40 PM, Jon Hunter wrote:
On 02/26/2013 04:01 AM, Javier Martinez Canillas wrote:
[snip]
I was wondering if the level/edge settings for gpios is working on
OMAP.
I'm adding DT support for an SMSC911x ethernet chip connected to the
GPMC for an OMAP3 SoC based board.
In the smsc911x driver probe function (smsc911x_drv_probe() in
drivers/net/ethernet/smsc/smsc911x.c), a call to request_irq() with
the flag IRQF_TRIGGER_LOW is needed because of the wiring on my board.
Reading the gpio-omap.txt documentation it says that #interrupt-cells
should be 2 and that a value of 8 is active low level-sensitive.
So I tried this:
gpmc {
ethernet@5,0 {
pinctrl-names = default;
pinctrl-0 = smsc911x_pins;
compatible = smsc,lan9221, smsc,lan9115;
reg = 5 0 0xff; /* CS5 */
interrupt-parent = gpio6;
interrupts = 16 8; /* gpio line 176 */
interrupt-names = smsc911x irq;
vmmc-supply = vddvario;
vmmc_aux-supply = vdd33a;
reg-io-width = 4;
smsc,save-mac-address;
};
};
Are you requesting the gpio anywhere? If not then this is not going to
work as-is. This was discussed fairly recently [1] and the conclusion
was that the gpio needs to be requested before we can use as an
interrupt.
That seems wrong; the GPIO/IRQ driver should handle this internally. The
Ethernet driver shouldn't know/care whether the interrupt it's given is
some form of dedicated interrupt or a GPIO-based interrupt, and even if
it somehow did, there's no irq_to_gpio() any more, so the driver can't
tell which GPIO ID it should request, unless it's given yet another
property to represent this.
I agree that ideally this should be handled internally. Did you read the
discussion on the thread that I referenced [1]? If you have any thoughts
we are open to ideas :-)
Cheers
Jon
[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/92192
Oh, when I clicked that link the first time, all I saw was the patch,
not any discussion. I guess it must have timed out finding the other
emails or something.
Actually, I sent a slightly different link the 2nd time to ensure you
saw the thread. So my fault ;-)
I disagree that the GPIO needs to be requested, and that a custom DT
property and associated code are needed for that; simply requesting the
IRQ should be enough to make everything work.
In the Tegra GPIO IRQ driver for example, the irq_set_type irq_chip op
goes and configures the base GPIO HW to enable the pin as a GPIO, just
like gpio_request() would. I imagine the OMAP driver can do whatever
similar action it needs.
Yes that is similar to what the patch in the thread was attempting to
do, but this got shot down.
One issue I see is that by not calling gpio_request, then potentially
you could have someone request a gpio via gpio_request() and someone
trying to use it as an interrupt source via request_irq(). Now obviously
that represents a bug because there is only one physical gpio, but I
gather it is something we need to protect against.
I'm not sure it's really that much of an issue, but presumably the
solution is for a combined GPIO+IRQ driver to simply call gpio_request
internally from within some irq_chip function. It looks like struct
irq_chip doesn't have a request/free, but perhaps they could be added to
solve this?
Yes I was wondering if we could do something like that. That would work,
may be that's what we should propose.
Thanks
Jon
Something like that would definitely solve the GPIO request issue but
we still have the issue that the current OMAP GPIO controller binding
does not support #interrupt-cells = 2.
So, we can't pass the trigger type and level flags for an IRQ-GPIO
when using an GPIO controller as the interrupt-parent for a device
node.
Do you have any comments on that issue?
I'll try to check Stephen's pointers but I'm not familiar with the
gpio-omap driver neither gpiolib.
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC 1/7] platform: add a device node
On 02/18/2013 02:51 PM, Grant Likely wrote:
On Sun, Feb 10, 2013 at 11:35 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
I knew this would be controversial and that's why I didn't mean it to be a
patch
but a RFC :)
The problem basically is that you have to associate the platform device
with its
corresponding DT device node because it can be used in the driver probe
function.
When DT is being used, doesn't DT create the platform devices for you,
with the device node already set correctly?
Well they usually do but not always just like usually you have a
platform_device in your board code and call platform_device_register().
But in some configurations you can't just define the platform_device
required resources (I/O memory, IRQ, etc) as static platform data.
In some cases you need a level of indirection.
In this particular case a SMSC ethernet chip is connected to an
OMAP3 processor through its General-Purpose Memory Controller.
You can't just define the I/O memory used by the device since you first
need to request that address to the GPMC. The same happens with the
IRQ line since a OMAP GPIO pin is used so you have to first configure
the GPIO line as input.
So in platform code you call to gpmc_smsc911x_init() passing all the
GPMC specific configurations (GPIO used for IRQ, GPMC chip select, etc)
Then gpmc_smsc911x_init() does all the needed setup, fills a platform_data
for the real platform_device and calls platform_device_register_resndata().
From the smsc911x platform_driver probe function point of view it just have
resources and doesn't know if it's I/O memory is directly mapped or is
through a memory controller as the GPMC. It also doesn't know if the IRQ is
a GPIO or not.
It's still the same difference as far as the device is concerned.
External bus chip-select lines are well understood. The key here is to
encode the CS line number into the reg property of the child node so
that the GPMC driver has the information it needs to configure the
chip selects. You do this by setting #address-cells to '2' in the GPMC
node, and use the ranges property to map from the gpmc address space
to the cpu address space. Like so (if you had 2 Ethernet controllers)
gpmc {
#address-cells = 2; // First cell is CS#, second
cell is offset from CS base
#size-cells = 1;
compatible = ti,gpmc;
ranges = 0 0 0xf100 0x1000, //CS0 mapped to
0xf100..0xf1000fff
1 0 0xf1001000 0x1000; //CS1 mapped
to 0xf1001000..0xf1001fff
ethernet@0,0 {
compatible = smsc,91c111;
reg = 0 0 0x1000;
}
ethernet@1,0 {
compatible = smsc,91c111;
reg = 1 0 0x1000;
}
}
The GPMC driver can use the information in the ranges property for
setting up the chip select mappings. For the smsc,91c111 driver the
mapping becomes transparent.
You can see another example of this in
arch/powerpc/boot/dts/media5200.dts in the localbus node.
g.
Hello Grant,
Thanks a lot for your explanation. Now is very clear to me how this has to be
done. I'll work on an v2 of this patch-set that do it correctly and will resend.
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] ARM: dts: OMAP3: Add GPMC controller
On Sat, Feb 16, 2013 at 2:09 PM, Anil Kumar anilkumar...@gmail.com wrote:
Hi Florian,
On Mon, Jan 28, 2013 at 11:24 PM, Florian Vaussard
florian.vauss...@epfl.ch wrote:
Add device-tree support for the GPMC controller on the OMAP3.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6c63118..2ddae38 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -403,5 +403,16 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+ };
};
};
Tested on devkit8000 (omap3 based board)
Please take my Tested-by: Anil Kumar anilk...@gmail.com
Thanks,
Anil
Hello Tony and Benoit,
Could this patch be merged to one of your branches?
It has already my Reviewed-by and now Anil's Tested-by.
Now that Daniel's OMAP GPMC binding were merged, there seems to be
many people working on adding support on their boards DT for
peripherals connected through the GPMC (NAND, OneNAND, SMSC LAN, etc).
I think it will be easier if people can base their work on top of this
patch instead of duplicating the work and sending the same patch to
add a GPMC device node to omap3.dtsi on each patch-set.
Thanks a lot and best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC 1/7] platform: add a device node
On Mon, Feb 11, 2013 at 9:16 AM, Sascha Hauer s.ha...@pengutronix.de wrote: On Sun, Feb 10, 2013 at 12:35:43PM +0100, Javier Martinez Canillas wrote: On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote: I knew this would be controversial and that's why I didn't mean it to be a patch but a RFC :) The problem basically is that you have to associate the platform device with its corresponding DT device node because it can be used in the driver probe function. When DT is being used, doesn't DT create the platform devices for you, with the device node already set correctly? Well they usually do but not always just like usually you have a platform_device in your board code and call platform_device_register(). But in some configurations you can't just define the platform_device required resources (I/O memory, IRQ, etc) as static platform data. In some cases you need a level of indirection. In this particular case a SMSC ethernet chip is connected to an OMAP3 processor through its General-Purpose Memory Controller. You can't just define the I/O memory used by the device since you first need to request that address to the GPMC. The same happens with the IRQ line since a OMAP GPIO pin is used so you have to first configure the GPIO line as input. For the gpio interrupt you can use, example taken from omap4-var-som.dts: interrupt-parent = gpio6; interrupts = 11; /* gpio line 171 */ Other architectures allow to specify the edge/level hi/low active parameters from the devicetree aswell. The gpio direction should be handled by the gpio driver as necessary, at least that's what done on other architectures. If the SMSC hangs on the GPMC then the SMSC should be a child node of the GPMC. The GPMC would then act as a bus driver and configure the chipselects and timings for its children automatically, maybe based on timing information from the devicetree. I've never tried this before, but I think that's the way things should be. Hi Sasha, The SMSC is already a child node of the GPMC in the device tree but instead using the generic SMSC binding I added a GPMC-specific SMSC binding. Since the SMSC binding doesn't have a chip select property and it expects the I/O memory address to be explicitly defined in the reg property while the GPMC needs to request this memory according to the chip select used. No need to manually create platform devices from the devicetree. Thanks a lot for your feedback, I'll go back and think more about this and try to solve this using a different approach that won't require changing the platform device info structure and reusing the generic SMSC LAN DT binding. Sascha Best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC 3/7] ARM: OMAP: gpmc-smsc911x: add DT dev node init function
On Mon, Feb 11, 2013 at 11:30 AM, Mark Rutland mark.rutl...@arm.com wrote:
Hi,
I have a few comments on the binding and the way it's parsed.
On Sat, Feb 09, 2013 at 08:44:27PM +, Javier Martinez Canillas wrote:
This patch adds a helper function to parse a device node that
contains all the properties needed to initialize an smsc911x
device connected to an OMAP processor through OMAP's GPMC.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
.../devicetree/bindings/net/gpmc-smsc911x.txt | 39
arch/arm/mach-omap2/gpmc-smsc911x.c| 29 +++
arch/arm/mach-omap2/gpmc-smsc911x.h|6 +++
3 files changed, 74 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
new file mode 100644
index 000..8bb0df2
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
@@ -0,0 +1,39 @@
+* GPMC connected Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x
Controller
+
+GPMC connected SMSC LAN911x/912x Controllers are represented as child nodes
+of the OMAP General-Purpose Memory Controller with a name of
gpmc_smsc911x.
+
+All timing relevant properties as well as generic gpmc child properties are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- gpmc,cs : The chip select line the pheripheral is connected to
+- gpmc,gpio_irq : The GPIO pin that is connected to the SMSC LAN IRQ line
In devicetree land, we use '-' in preference of '_' in property names.
So this should be gpio-irq
+
+Optional properties:
+- gpmc,flags : SMSC LAN flags - please refer to include/linux/smsc911x.h
Please don't do this. It should only be necessary to read binding documents
and
hardware datasheets to write a dts. Referring to Linux internals creates a
flaky ABI that's only going to break when things get renamed/moved/modified.
The flags variable used internally by the driver don't have to have a 1-1
correspondence with a single property in the binding. You can have boolean
properties (named, but without a value) in the dt specifying each flag
individually. That way the dts is easier to read, is less tied to linux
internals (and every property is *fully* documented), and it's far easier to
add new flags in future if necessary.
+- gpmc,gpio_reset : The GPIO pin connected to the SMSC LAN reset line
Preferably: gpio-reset.
+
+Note: Besides these properties, the gpmc_smsc911x device node could need
+aditional setup such as pin/pad mux settings and voltage regulators. This
+depend on how the pheripheral is wired and his board specific.
+
+Example (for an OMAP3 board):
+
+gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ gpmc_smsc911x@0 {
+ gpmc,cs = 5;
+ gpmc,gpio_irq = 176;
+ gpmc,flags = 4; /* SMSC911X_USE_32BIT */
Here you could have a boolean property gpmc,use-32bit (or possibly
gpmc,use-bits, which can either be 32 or 16).
+ };
+};
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 5ce00ad2..59a2ee4 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -19,6 +19,7 @@
#include linux/interrupt.h
#include linux/io.h
#include linux/smsc911x.h
+#include linux/of.h
#include gpmc.h
#include gpmc-smsc911x.h
@@ -98,3 +99,31 @@ free1:
pr_err(Could not initialize smsc911x device\n);
}
+
+int gpmc_smsc911x_init_dt(struct device_node *node)
+{
+ struct omap_smsc911x_platform_data gpmc_cfg;
+
+ if (WARN_ON(!node))
+ return -ENODEV;
+
+ if (of_property_read_u32(node, gpmc,cs, gpmc_cfg.cs)) {
+ pr_err(Unable to get GPMC smsc911x chip select\n);
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32(node, gpmc,gpio_irq, gpmc_cfg.gpio_irq)) {
+ pr_err(Unable to get GPMC smsc911x GPIO IRQ\n);
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32(node, gpmc,gpio_reset,
gpmc_cfg.gpio_reset))
+ gpmc_cfg.gpio_reset = -EINVAL;
+
+ if (of_property_read_u32(node, gpmc,flags, gpmc_cfg.flags))
+ gpmc_cfg.flags = 0;
Is no sanity checking required for any of the above properties?
To handle separate flags here, you can use something like:
if (of_property_read_bool(node, gpmc,use-32bit)
flags |= SMSC911X_USE_32BIT
Re: [PATCH RFC 1/7] platform: add a device node
On Mon, Feb 11, 2013 at 12:24 PM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Mon, Feb 11, 2013 at 11:33:19AM +0100, Javier Martinez Canillas wrote:
On Mon, Feb 11, 2013 at 9:16 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Sun, Feb 10, 2013 at 12:35:43PM +0100, Javier Martinez Canillas wrote:
On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas
wrote:
I knew this would be controversial and that's why I didn't mean it to
be a patch
but a RFC :)
The problem basically is that you have to associate the platform
device with its
corresponding DT device node because it can be used in the driver
probe function.
When DT is being used, doesn't DT create the platform devices for you,
with the device node already set correctly?
Well they usually do but not always just like usually you have a
platform_device in your board code and call platform_device_register().
But in some configurations you can't just define the platform_device
required resources (I/O memory, IRQ, etc) as static platform data.
In some cases you need a level of indirection.
In this particular case a SMSC ethernet chip is connected to an
OMAP3 processor through its General-Purpose Memory Controller.
You can't just define the I/O memory used by the device since you first
need to request that address to the GPMC. The same happens with the
IRQ line since a OMAP GPIO pin is used so you have to first configure
the GPIO line as input.
For the gpio interrupt you can use, example taken from omap4-var-som.dts:
interrupt-parent = gpio6;
interrupts = 11; /* gpio line 171 */
Other architectures allow to specify the edge/level hi/low active
parameters from the devicetree aswell. The gpio direction should be
handled by the gpio driver as necessary, at least that's what done on
other architectures.
If the SMSC hangs on the GPMC then the SMSC should be a child node of
the GPMC. The GPMC would then act as a bus driver and configure the
chipselects and timings for its children automatically, maybe based
on timing information from the devicetree. I've never tried this before,
but I think that's the way things should be.
Hi Sasha,
The SMSC is already a child node of the GPMC in the device tree but instead
using the generic SMSC binding I added a GPMC-specific SMSC binding.
Since the SMSC binding doesn't have a chip select property and it expects
the I/O memory address to be explicitly defined in the reg property while
the GPMC needs to request this memory according to the chip select used.
So you probably have this:
gpmc {
compatible = ti,gpmc, simple-bus;
ranges;
smsc911x {
compatible = smsc,91x;
}
}
Yes
If you remove the simple-bus property the gpmc devices would not be
probed. If then you add a driver which matches ti,gpmc you can
configure the chip selects in its probe callback. After this you
can call of_platform_populate() starting from the gpmc device node
to instantiate the gpmc child devices.
Please somebody interrupt me if I'm talking total rubbish here. I never
tried this and only assume it should work like this.
Nice, I haven't thought about that and I don't see why it shouldn't work.
I won't have time to work on this for at least the next 3 weeks but I'll try
once I have more free time and post another RFC if I got things working.
Sascha
Thanks a lot and best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC 1/7] platform: add a device node
On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote: I knew this would be controversial and that's why I didn't mean it to be a patch but a RFC :) The problem basically is that you have to associate the platform device with its corresponding DT device node because it can be used in the driver probe function. When DT is being used, doesn't DT create the platform devices for you, with the device node already set correctly? Well they usually do but not always just like usually you have a platform_device in your board code and call platform_device_register(). But in some configurations you can't just define the platform_device required resources (I/O memory, IRQ, etc) as static platform data. In some cases you need a level of indirection. In this particular case a SMSC ethernet chip is connected to an OMAP3 processor through its General-Purpose Memory Controller. You can't just define the I/O memory used by the device since you first need to request that address to the GPMC. The same happens with the IRQ line since a OMAP GPIO pin is used so you have to first configure the GPIO line as input. So in platform code you call to gpmc_smsc911x_init() passing all the GPMC specific configurations (GPIO used for IRQ, GPMC chip select, etc) Then gpmc_smsc911x_init() does all the needed setup, fills a platform_data for the real platform_device and calls platform_device_register_resndata(). From the smsc911x platform_driver probe function point of view it just have resources and doesn't know if it's I/O memory is directly mapped or is through a memory controller as the GPMC. It also doesn't know if the IRQ is a GPIO or not. Another approach could be extending the current SMSC LAN DT binding with GPMC-specific properties so the platform driver could do this setup when the device node is found and the probe function is called. Manually creating platform devices and adding DT nodes to it sounds like the wrong thing to be doing. -- Yes, I don't like this approach to much either but I didn't find a better way to do it. That was the main point of this RFC. I'm still learning about Device Trees so I hope that someone with more experience with DT or more familiarized with OMAP GPMC and the SMSC driver could take a step forward and help me giving a better idea. Thanks a lot for your feedback and best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RFC 6/7] ARM: dts: OMAP: Add an GPMC node for OMAP3
This patch adds a General-Purpose Memory Controller (GPMC)
device node to be used for OMAP3 based SoC boards.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6c63118..38b52b3 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -403,5 +403,16 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20; /* M_IRQ_20 interrupt */
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+ };
};
};
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RFC 7/7] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support
IGEPv2 boards has an SMSC LAN9221i ethernet chip connected to
the OMAP3 processor though the General-Purpose Memory Controller.
This patch adds a device node for the ethernet chip so the GPMC
driver will call the gpmc-smsc911x setup code.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi|6 ++
arch/arm/boot/dts/omap3-igep0020.dts | 24
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index 100eb41..2f02581 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -48,6 +48,12 @@
0x126 0x0100/* sdmmc1_dat7.sdmmc1_dat7 INPUT | MODE
0 */
;
};
+
+smsc911x_pins: pinmux_smsc911x_pins {
+pinctrl-single,pins =
+0x1a2 0x0104/* mcspi1_cs2.gpio_176 INPUT | MODE4 */
+;
+};
};
i2c1 {
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e2b9849..68b7cf3 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -40,6 +40,18 @@
gpios = twl_gpio 19 1;
};
};
+
+vddvario: regulator-vddvario {
+compatible = regulator-fixed;
+regulator-name = vddvario;
+regulator-always-on;
+};
+
+vdd33a: regulator-vdd33a {
+compatible = regulator-fixed;
+regulator-name = vdd33a;
+regulator-always-on;
+};
};
i2c3 {
@@ -54,3 +66,15 @@
reg = 0x50;
};
};
+
+gpmc {
+ gpmc_smsc911x@0 {
+ pinctrl-names = default;
+ pinctrl-0 = smsc911x_pins;
+ gpmc,cs = 5; /* IGEP2_SMSC911X_CS */
+ gpmc,gpio_irq = 176; /* IGEP2_SMSC911X_GPIO */
+ gpmc,flags = 18; /* SMSC911X_USE_32BIT |
SMSC911X_SAVE_MAC_ADDRESS */
+ vmmc-supply = vddvario;
+ vmmc_aux-supply = vdd33a;
+ };
+};
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RFC 5/7] ARM: OMAP: gpmc: add support for gpmc-smsc911x child nodes
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices to the OMAP processor that use the GPMC
as a data bus. One of these devices is the smsc911x LAN chip.
This patch allows an smsc911x LAN pheripheral to be defined
as an GPMC child node an call its corresponding setup function.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2/gpmc.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index f55b504..fd22c62 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -40,6 +40,7 @@
#include gpmc.h
#include gpmc-nand.h
#include gpmc-onenand.h
+#include gpmc-smsc911x.h
#defineDEVICE_NAME omap-gpmc
@@ -1320,6 +1321,14 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
}
+
+ for_each_node_by_name(child, gpmc_smsc911x) {
+ ret = gpmc_smsc911x_init_dt(child);
+ if (ret 0) {
+ of_node_put(child);
+ return ret;
+ }
+ }
return 0;
}
#else
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RFC 2/7] net: smsc911x: add pinctrl support
If no pinctrl is available just report a warning since
it may not needed in some cases (e.g: non-DT kernels).
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/net/ethernet/smsc/smsc911x.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index e112877..40766c7 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -59,6 +59,7 @@
#include linux/of_device.h
#include linux/of_gpio.h
#include linux/of_net.h
+#include linux/pinctrl/consumer.h
#include smsc911x.h
#define SMSC_CHIPNAME smsc911x
@@ -2352,6 +2353,7 @@ static int smsc911x_drv_probe(struct platform_device
*pdev)
struct smsc911x_data *pdata;
struct smsc911x_platform_config *config = pdev-dev.platform_data;
struct resource *res, *irq_res;
+ struct pinctrl *pinctrl;
unsigned int intcfg = 0;
int res_size, irq_flags;
int retval;
@@ -2381,6 +2383,15 @@ static int smsc911x_drv_probe(struct platform_device
*pdev)
goto out_0;
}
+ pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pinctrl)) {
+ retval = PTR_ERR(pinctrl);
+ if (retval == -EPROBE_DEFER)
+ goto out_0;
+
+ dev_warn(pdev-dev, No pinctrl provided\n);
+ }
+
dev = alloc_etherdev(sizeof(struct smsc911x_data));
if (!dev) {
retval = -ENOMEM;
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RFC 3/7] ARM: OMAP: gpmc-smsc911x: add DT dev node init function
This patch adds a helper function to parse a device node that
contains all the properties needed to initialize an smsc911x
device connected to an OMAP processor through OMAP's GPMC.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
.../devicetree/bindings/net/gpmc-smsc911x.txt | 39
arch/arm/mach-omap2/gpmc-smsc911x.c| 29 +++
arch/arm/mach-omap2/gpmc-smsc911x.h|6 +++
3 files changed, 74 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
new file mode 100644
index 000..8bb0df2
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
@@ -0,0 +1,39 @@
+* GPMC connected Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller
+
+GPMC connected SMSC LAN911x/912x Controllers are represented as child nodes
+of the OMAP General-Purpose Memory Controller with a name of gpmc_smsc911x.
+
+All timing relevant properties as well as generic gpmc child properties are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- gpmc,cs : The chip select line the pheripheral is connected to
+- gpmc,gpio_irq : The GPIO pin that is connected to the SMSC LAN IRQ line
+
+Optional properties:
+- gpmc,flags : SMSC LAN flags - please refer to include/linux/smsc911x.h
+- gpmc,gpio_reset : The GPIO pin connected to the SMSC LAN reset line
+
+Note: Besides these properties, the gpmc_smsc911x device node could need
+aditional setup such as pin/pad mux settings and voltage regulators. This
+depend on how the pheripheral is wired and his board specific.
+
+Example (for an OMAP3 board):
+
+gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ gpmc_smsc911x@0 {
+ gpmc,cs = 5;
+ gpmc,gpio_irq = 176;
+ gpmc,flags = 4; /* SMSC911X_USE_32BIT */
+ };
+};
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 5ce00ad2..59a2ee4 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -19,6 +19,7 @@
#include linux/interrupt.h
#include linux/io.h
#include linux/smsc911x.h
+#include linux/of.h
#include gpmc.h
#include gpmc-smsc911x.h
@@ -98,3 +99,31 @@ free1:
pr_err(Could not initialize smsc911x device\n);
}
+
+int gpmc_smsc911x_init_dt(struct device_node *node)
+{
+ struct omap_smsc911x_platform_data gpmc_cfg;
+
+ if (WARN_ON(!node))
+ return -ENODEV;
+
+ if (of_property_read_u32(node, gpmc,cs, gpmc_cfg.cs)) {
+ pr_err(Unable to get GPMC smsc911x chip select\n);
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32(node, gpmc,gpio_irq, gpmc_cfg.gpio_irq)) {
+ pr_err(Unable to get GPMC smsc911x GPIO IRQ\n);
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32(node, gpmc,gpio_reset, gpmc_cfg.gpio_reset))
+ gpmc_cfg.gpio_reset = -EINVAL;
+
+ if (of_property_read_u32(node, gpmc,flags, gpmc_cfg.flags))
+ gpmc_cfg.flags = 0;
+
+ gpmc_smsc911x_init(gpmc_cfg);
+
+ return 0;
+}
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.h
b/arch/arm/mach-omap2/gpmc-smsc911x.h
index ea6c9c8..bbcb8bc 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.h
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.h
@@ -25,11 +25,17 @@ struct omap_smsc911x_platform_data {
extern void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d);
+extern int gpmc_smsc911x_init_dt(struct device_node *node);
+
#else
static inline void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d)
{
}
+static inline int gpmc_smsc911x_init_dt(struct device_node *node)
+{
+}
+
#endif
#endif
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RFC 0/7] ARM: OMAP: add DT binding for gpmc-smsc911x
Hello, This is an RFC to add Device Tree support for SMSC LAN chips connected to OMAP processors though its General-Purpose Memory Controller. The patch-set is composed of the following patches: [PATCH RFC 1/7] platform: add a device node [PATCH RFC 2/7] net: smsc911x: add pinctrl support [PATCH RFC 3/7] ARM: OMAP: gpmc-smsc911x: add DT dev node init function [PATCH RFC 4/7] ARM: OMAP: gpmc-smsc911x: pass a dev node to platform [PATCH RFC 5/7] ARM: OMAP: gpmc: add support for gpmc-smsc911x child [PATCH RFC 6/7] ARM: dts: OMAP: Add an GPMC node for OMAP3 [PATCH RFC 7/7] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support It is an RFC because I had to modify the platform_device_register_resndata() platform device registration function to allow passing a device node and associate to the platform device after allocation. The patch-set updates all current users and this shouldn't have a function effect on them. I think that the need for platform code to pass the DT device node to the platform registration infraestructure will be needed for other devices too whose probe function needs to access the device node associated with the device. The binding has been tested on an TI OMAP3 based board (IGEPv2) and added support is included on the RFC as an example. It is based on Linus' latest master branch + linux-omap/omap-for-v3.9/gpmc + linux-omap-dt/for_3.9/dts Thanks a lot and best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RFC 4/7] ARM: OMAP: gpmc-smsc911x: pass a dev node to platform registration
The smsc911x driver needs the GPMC smsc911x associated device
node to set the OMAP mux pins using the pinctrl framework.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2/gpmc-smsc911x.c |5 -
arch/arm/mach-omap2/gpmc-smsc911x.h |1 +
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 59a2ee4..9f3b0a5 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -83,7 +83,8 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *gpmc_cfg)
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), NULL);
+gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config),
+gpmc_cfg-of_node);
if (!pdev) {
pr_err(Unable to register platform device\n);
gpio_free(gpmc_cfg-gpio_reset);
@@ -107,6 +108,8 @@ int gpmc_smsc911x_init_dt(struct device_node *node)
if (WARN_ON(!node))
return -ENODEV;
+ gpmc_cfg.of_node = node;
+
if (of_property_read_u32(node, gpmc,cs, gpmc_cfg.cs)) {
pr_err(Unable to get GPMC smsc911x chip select\n);
return -EINVAL;
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.h
b/arch/arm/mach-omap2/gpmc-smsc911x.h
index bbcb8bc..32a7df0 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.h
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.h
@@ -19,6 +19,7 @@ struct omap_smsc911x_platform_data {
int gpio_irq;
int gpio_reset;
u32 flags;
+ struct device_node *of_node;
};
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RFC 1/7] platform: add a device node
When using Device Trees, it is necessary to associate a device node with a platform device. Usually this device node has to used in the device probe function (e.g: to initizalize the pinctrl pads assocaited with the device). So, platform code needs to pass a device node as a platform device info to the platform device registration function. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/mach-imx/devices/platform-gpio-mxc.c |2 +- arch/arm/mach-imx/devices/platform-imx-dma.c |4 ++-- arch/arm/mach-imx/mach-armadillo5x0.c |2 +- arch/arm/mach-imx/mach-imx27_visstrim_m10.c |3 ++- arch/arm/mach-imx/mach-mx1ads.c |2 +- arch/arm/mach-nomadik/cpu-8815.c |2 +- arch/arm/mach-omap2/fb.c |2 +- arch/arm/mach-omap2/gpmc-smsc911x.c |2 +- arch/arm/mach-ux500/board-mop500-audio.c |2 +- arch/arm/mach-ux500/devices-common.c |3 ++- arch/arm/mach-ux500/devices-db8500.h |2 +- arch/unicore32/kernel/puv3-core.c |2 +- arch/unicore32/kernel/puv3-nb0916.c |2 +- drivers/base/platform.c |1 + drivers/leds/leds-gpio-register.c |2 +- drivers/virtio/virtio_mmio.c |2 +- include/linux/platform_device.h |9 ++--- sound/soc/samsung/i2s.c |2 +- 18 files changed, 26 insertions(+), 20 deletions(-) diff --git a/arch/arm/mach-imx/devices/platform-gpio-mxc.c b/arch/arm/mach-imx/devices/platform-gpio-mxc.c index 26483fa..4f4d8f9 100644 --- a/arch/arm/mach-imx/devices/platform-gpio-mxc.c +++ b/arch/arm/mach-imx/devices/platform-gpio-mxc.c @@ -28,5 +28,5 @@ struct platform_device *__init mxc_register_gpio(char *name, int id, }; return platform_device_register_resndata(mxc_aips_bus, - name, id, res, ARRAY_SIZE(res), NULL, 0); + name, id, res, ARRAY_SIZE(res), NULL, 0, NULL); } diff --git a/arch/arm/mach-imx/devices/platform-imx-dma.c b/arch/arm/mach-imx/devices/platform-imx-dma.c index ccdb5dc..1e3838c 100644 --- a/arch/arm/mach-imx/devices/platform-imx-dma.c +++ b/arch/arm/mach-imx/devices/platform-imx-dma.c @@ -28,7 +28,7 @@ struct platform_device __init __maybe_unused *imx_add_imx_dma(char *name, }; return platform_device_register_resndata(mxc_ahb_bus, - name, -1, res, ARRAY_SIZE(res), NULL, 0); + name, -1, res, ARRAY_SIZE(res), NULL, 0, NULL); } struct platform_device __init __maybe_unused *imx_add_imx_sdma(char *name, @@ -47,5 +47,5 @@ struct platform_device __init __maybe_unused *imx_add_imx_sdma(char *name, }; return platform_device_register_resndata(mxc_ahb_bus, name, - -1, res, ARRAY_SIZE(res), pdata, sizeof(*pdata)); + -1, res, ARRAY_SIZE(res), pdata, sizeof(*pdata), NULL); } diff --git a/arch/arm/mach-imx/mach-armadillo5x0.c b/arch/arm/mach-imx/mach-armadillo5x0.c index 59bd6b0..e664681 100644 --- a/arch/arm/mach-imx/mach-armadillo5x0.c +++ b/arch/arm/mach-imx/mach-armadillo5x0.c @@ -519,7 +519,7 @@ static void __init armadillo5x0_init(void) platform_device_register_resndata(NULL, physmap-flash, -1, armadillo5x0_nor_flash_resource, 1, armadillo5x0_nor_flash_pdata, - sizeof(armadillo5x0_nor_flash_pdata)); + sizeof(armadillo5x0_nor_flash_pdata), NULL); /* Register NAND Flash */ imx31_add_mxc_nand(armadillo5x0_nand_board_info); diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c index 318bd8d..5065f67 100644 --- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c +++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c @@ -570,7 +570,8 @@ static void __init visstrim_m10_board_init(void) imx_add_platform_device(mx27vis, 0, NULL, 0, snd_mx27vis_pdata, sizeof(snd_mx27vis_pdata)); platform_device_register_resndata(NULL, soc-camera-pdrv, 0, NULL, 0, - iclink_tvp5150, sizeof(iclink_tvp5150)); + iclink_tvp5150, sizeof(iclink_tvp5150), + NULL); gpio_led_register_device(0, visstrim_m10_led_data); /* Use mother board version to decide what video devices we shall use */ diff --git a/arch/arm/mach-imx/mach-mx1ads.c b/arch/arm/mach-imx/mach-mx1ads.c index 06b4837..9ce64a5 100644 --- a/arch/arm/mach-imx/mach-mx1ads.c +++ b/arch/arm/mach-imx/mach-mx1ads.c @@ -118,7 +118,7 @@ static void __init mx1ads_init(void) /* Physmap flash */ platform_device_register_resndata(NULL, physmap-flash, 0, flash_resource, 1, - mx1ads_flash_data, sizeof
Re: [PATCH RFC 1/7] platform: add a device node
Hi Greg, Thanks a lot for your feedback. On 02/10/2013 02:02 AM, Greg Kroah-Hartman wrote: On Sat, Feb 09, 2013 at 09:44:25PM +0100, Javier Martinez Canillas wrote: When using Device Trees, it is necessary to associate a device node with a platform device. Usually this device node has to used in the device probe function (e.g: to initizalize the pinctrl pads assocaited with the device). So, platform code needs to pass a device node as a platform device info to the platform device registration function. Really? We don't already have enough other pointers in the platform device structure that we need another one? I knew this would be controversial and that's why I didn't mean it to be a patch but a RFC :) The problem basically is that you have to associate the platform device with its corresponding DT device node because it can be used in the driver probe function. But you can't do this before calling platform_device_register_resndata() since the platform_device has not been allocated yet and you can't do it after since by then the driver probe function has been executed already. You could certainly pass the device node as a platform device resource by for example storing the dev node pointer in the struct resource .start member or by adding it to the structure (struct smsc911x_platform_config in this case) that gets copied to the struct platform_device_info void *data. Then in the driver probe function you could get the device node from either the platform_data or a dev-resource. But I expect most users of platform_device_register_resndata() will have a similar issue as more and more platform drivers are migrated to DT. So, to avoid each driver to do the same (encode and decode the DT device node using platform_data or a device resource) I thought that it could make sense to add yet another pointer to the struct platform_device_info structure and set: pdev-dev.of_node = pdevinfo-of_node inside platform_device_register_full(). I don't buy it, sorry. Any reason you didn't run this by Grant as well? No reason at all, it is just me being goofy. I thought that Grant was cc'ed already and I just realized that he wasn't. cc'ing him as well. greg k-h Thanks a lot and best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] ARM: dts: OMAP3: Add GPMC controller
On Tue, Feb 5, 2013 at 6:23 PM, Florian Vaussard florian.vauss...@epfl.ch wrote: Hi Javier, Hi Florian, On 02/04/2013 12:57 PM, Javier Martinez Canillas wrote: [...] Yes, I saw on the list that Tony asked you too extend the GPMC DT support. Flash support is on my TODO list too but I don't know if I'm going to have time to work on this in the next few weeks. Since you are thinking to change the binding, there is something I want to discuss with you. We have two different version for each IGEP board, one that uses NAND memory and another that has OneNAND. With board files this is easy because the flash memory type is hardcoded (in hardware) using sysboot pins [3]. So we check the sysboot value and call board_nand_init() or board_onenand_init() accordingly and pass the same static struct mtd_partition igep_flash_partitions[] in both cases. But with DT this is a little bit trickier since you have to define either a nand@0 or onenand@0 child node for the gpmc device node. So, we will have to create lots of dts and dtsi to handle each combination (IGEPv2 + NAND, IGEPv2 + OneNAND, IGEP COM + NAND, etc). I wonder if we could just have a generic gpmc-flash binding and maybe use a gpmc, flash_type property or something like that to decide if gpmc_onenand_init() or gpmc_nand_init() has to be called. This boils down to the problem where you have an if statement in your board file, and I think no general solution exists. Yes, this is a general issue since DT uses a declarative paradigm. I was just pointing out that I found that particular issue with the flash memory type on IGEP boards. In your suggestion, having a property will force you anyway to write distinct DT files to account for the two versions, so it won't really help if I understand correctly. We would need conditional section inside device trees, at least to test for simple parameters. Or a way to generate several DT blobs based on a single DT source file. Well you will still need a different dtb for each board,flash type combination but it could make your device trees smaller and simpler since you can define your GPMC flash child node on a dtsi where you set all the partition and sizes and export that device node to your boards dts that only set the gpmc, flash_type property to nand or onenand (assuming both your NAND and OneNAND version have the same partition layout and sizes). Otherwise you would have to define the complete onenand or nand child node on your board dts having duplicated definition for your flash partition layouts. Another hackish solution would be to write a meta component, whose probe section would do your test. But this is just a stripped down version of the board file, far from being generic... Yes, and that doesn't fit on the DT model too well. I still don't know what's the best way to do it. I will think on it during my holidays :) great, I hope you enjoy your holidays :-) Regards, Florian Thanks a lot and best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] ARM: dts: OMAP3: Add GPMC controller
Hi Florian,
On Mon, Jan 28, 2013 at 6:54 PM, Florian Vaussard
florian.vauss...@epfl.ch wrote:
Add device-tree support for the GPMC controller on the OMAP3.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6c63118..2ddae38 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -403,5 +403,16 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+ };
};
};
I had the same patch on a tree I was working on to add DT support for
gpmc-smsc911x on an OMAP3 board but I was waiting for Daniel's patches
to hit mainline before sending the RFC. So please feel free to add:
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
