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 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
>> Cc: Sekhar Nori
>> Signed-off-by: Luciano Coelho
>> ---
>
> [...]
>
>> @@ -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 wrote: > On Wed, 05 Jun 2013 20:20:39 +0200, Tomasz Figa 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 >>> --- >>> 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 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
> ---
> 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
___
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
> ---
> 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
___
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 Thu, Jun 6, 2013 at 10:50 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 00:26 Thu 06 Jun , Grant Likely wrote: >> On Tue, 09 Apr 2013 00:44:05 +0200, Javier Martinez Canillas >> 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. > > why do you need to known this in you driver this need to be handle in the irq > chip > > I does use irq gpio without at all > > Best Regards, > J. > Yes, in fact as I said on an earlier email on this thread 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. A few months ago when I was testing DT on my OMAP3 board, for some reasons it was not getting the right trigger type. That's why I sent this patch but it seems it was a bug on the GPIO omap irq_chip driver since now is working correctly without this. It is taking the trigger type that was set on the .xlate function handler. 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 means that is going to be used whatever was set on the .xlate function handler is a reason enough to not return the IRQ flags on the struct resource or if someone else is still interested on this patch and filling this information on the struct resource. 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 > 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 > [...] >> 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 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 > 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 v8] ARM: dts: omap4-panda: Update the LED support for the panda DTS
On Fri, May 31, 2013 at 4:48 PM, Dan Murphy 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
> ---
> 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: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 >>>> --- >>>> >>>> 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 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 >> --- >> >> 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 1/2] ARM: dts: omap3-igep0020: Add NAND flash support
On Fri, May 10, 2013 at 9:31 PM, Javier Martinez Canillas 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 > --- > > 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 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
---
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
[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
---
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 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
---
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
Re: [PATCH] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support
On Wed, Apr 17, 2013 at 6:32 PM, Javier Martinez Canillas
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
> ---
> 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
---
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
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
> ---
>
> 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 1/1] of/irq: store IRQ trigger/level in struct resource flags
On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring 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 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
>>>> Signed-off-by: Javier Martinez Canillas
>>>> ---
>>>>
>>>> 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 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
>> Signed-off-by: Javier Martinez Canillas
>> ---
>>
>> 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
[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
---
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
[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
Signed-off-by: Javier Martinez Canillas
---
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
Re: [PATCH v3 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On 04/17/2013 08:33 PM, Jon Hunter wrote:
>
> On 04/17/2013 09:07 AM, Javier Martinez Canillas wrote:
>> 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".
>
> Yes we got lucky here or unlucky as this would have tripped us up
> earlier ;-)
>
indeed :)
>> 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.
>
> Yes I was wondering about that too. However, it does seem simpler to
> just search through the child devices and that would be an easier fix.
>
agreed
>>>> 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
>>>> 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
>>>> ---
>>>> 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);
[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
Signed-off-by: Javier Martinez Canillas
---
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] 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
---
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
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Wed, Apr 17, 2013 at 3:52 PM, Jon Hunter wrote: > > On 04/17/2013 08:42 AM, Javier Martinez Canillas wrote: >> On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter 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-kernel&m=136606204823845&w=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
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Wed, Apr 17, 2013 at 3:52 PM, Jon Hunter wrote: > > On 04/17/2013 08:42 AM, Javier Martinez Canillas wrote: >> On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter 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-kernel&m=136606204823845&w=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 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
>> 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
>> ---
>> 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
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter 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-kernel&m=136606204823845&w=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] [] (unwind_backtrace+0x0/0xf0) from
>> [] (warn_slowpath_common+0x4c/0x68)
>> [0.285552] [] (warn_slowpath_common+0x4c/0x68) from
>> [] (warn_slowpath_null+0x1c/0x24)
>> [0.285614] [] (warn_slowpath_null+0x1c/0x24) from
>> [] (of_device_alloc+0x154/0x168)
>> [0.285675] [] (of_device_alloc+0x154/0x168) from
>> [] (of_platform_device_create_pdata+0x34/0x80)
>> [0.285736] []
>> (of_platform_device_create_pdata+0x34/0x80) from []
>> (gpmc_probe_generic_child+0x180/0x240)
>> [0.285827] [] (gpmc_probe_generic_child+0x180/0x240)
>> from [] (gpmc_probe+0x4b4/0x614)
>> [0.285888] [] (gpmc_probe+0x4b4/0x614) from []
>> (platform_drv_probe+0x18/0x1c)
>> [0.285949] [] (platform_drv_probe+0x18/0x1c) from
>> [] (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
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
---
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 = "reg
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
>>
>>
>> ---
>> 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
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Wed, Apr 17, 2013 at 4:00 AM, Jon Hunter wrote: > > On 04/16/2013 07:41 PM, Javier Martinez Canillas wrote: >> On Wed, Apr 17, 2013 at 1:14 AM, Jon Hunter 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 >> 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 >> --- >> 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) >>
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Wed, Apr 17, 2013 at 1:14 AM, Jon Hunter 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
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
---
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 = intspe
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Sun, Apr 14, 2013 at 10:53 PM, Linus Walleij
wrote:
> On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
> 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: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Fri, Apr 12, 2013 at 12:47 AM, Stephen Warren wrote:
> On 04/11/2013 04:16 PM, Linus Walleij wrote:
>> On Thu, Apr 11, 2013 at 10:30 PM, Stephen Warren
>> 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-kernel&m=136334655902407&w=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
Re: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
On Sat, Apr 13, 2013 at 8:59 PM, Christoph Fritz
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
>> 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 */
>> > + >;
>> > + };
>> > +};
>> > +
>> >
>> > + 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 = <®_vcc3>;
vmmc_aux-supply = <&vdd33a>;
vddvario-supply = <®_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,
Re: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
On Sat, Apr 13, 2013 at 7:42 PM, Christoph Fritz
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
>> #include
>> #include
>> #include
>> @@ -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 */
> + >;
> + };
> +};
> +
>
> + lan9221@1500 {
> + compatible = "smsc,lan9221", "smsc,lan9115";
> + reg = <0x1500 0x400>;
If I understood correctly your smsc et
[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
---
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 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 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 --- 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
[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
---
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 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
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Fri, Apr 12, 2013 at 12:16 AM, Linus Walleij
wrote:
> On Thu, Apr 11, 2013 at 10:30 PM, Stephen Warren
> 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-kernel&m=136334655902407&w=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 10:26 AM, Javier Martinez Canillas wrote: > On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring 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 Tue, Apr 9, 2013 at 4:45 AM, Rob Herring 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 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
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
[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
---
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
/**
- * 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
[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
---
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
/**
- * 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
Re: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
On Mon, Apr 1, 2013 at 6:41 PM, Christoph Fritz
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
#include
#include
#include
@@ -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
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/
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
>>> 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
>>>> Signed-off-by: Javier Martinez Canillas
>>>> Acked-by: Jon Hunter
>>>> ---
>>>>
>>>> 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: [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
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
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Jon Hunter
> ---
>
> 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: Getting kernel uImage build issue on omap2+
On Sat, Mar 16, 2013 at 5:44 AM, Anil Kumar 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
[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
Signed-off-by: Javier Martinez Canillas
Acked-by: Jon Hunter
---
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
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 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
>> 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
>>> Signed-off-by: Javier Martinez Canillas
>>> Acked-by: Jon Hunter
>>> ---
>>>
>>> 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
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
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
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Jon Hunter
> ---
>
> 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 3/5] gpio/omap: Add DT support to GPIO driver
On Fri, Mar 8, 2013 at 12:14 AM, Jon Hunter wrote:
>
> On 03/02/2013 02:05 PM, Grant Likely wrote:
>> On Tue, 26 Feb 2013 17:01:22 -0600, 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:
>>>>> 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 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On Thu, Mar 14, 2013 at 10:29 PM, Jon Hunter wrote: > > On 03/14/2013 04:08 PM, Javier Martinez Canillas wrote: >> >> >> Javier >> >> Hi Jon, >> >> On 14/03/2013, at 21:43, Jon Hunter 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 >>>> --- >>>> >>>> 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 >>
[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
---
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 =
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 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 >> --- >> >> 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
[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
---
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>
Re: [PATCH 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On Thu, Mar 14, 2013 at 7:49 PM, Jon Hunter wrote:
>
> On 03/14/2013 11:37 AM, Javier Martinez Canillas wrote:
>> On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter 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
>>>> ---
>>>> 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].
>
> Yes you are right. Sorry about that ...
>
>> 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;
>> }
>
> Looking at the above, then I don
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 wrote: > On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter 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 >>> --- >>> 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
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 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
>> ---
>> 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 0/9] ARM: dts: Various OMAP2+ device-tree updates
On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson 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
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
---
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
[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
---
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_eac
[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
---
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 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 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 --- 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
Re: [PATCH] arm: dts: Add uart1 and uart2 to igep boards.
On Wed, Mar 13, 2013 at 5:41 PM, Benoit Cousson 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 wrote:
>>> Hi Matthias,
>>>
>>>
>>> On 2/15/2013 10:35 AM, Matthias Brugger wrote:
>>>>
>>>> 2013/1/26 Javier Martinez Canillas :
>>>>>
>>>>> On Sat, Jan 26, 2013 at 4:16 PM, Matthias Brugger
>>>>>
>>>>> wrote:
>>>>>>
>>>>>> Hi Benoit,
>>>>>>
>>>>>> 2012/12/12 Benoit Cousson :
>>>>>>>
>>>>>>> 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
>>>>>>>> ---
>>>>>>>> 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 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
On Tue, Mar 12, 2013 at 3:42 AM, Kumar, Anil wrote:
>
> On Mon, Mar 11, 2013 at 23:23:32, Hunter, Jon wrote:
>>
>> On 03/08/2013 08:25 PM, Anil Kumar wrote:
>> > Hi Jon,
>> >
>> > On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter wrote:
>> >> Adds basic device-tree support for OMAP3430 SDP board which has 256MB
>> >> of RAM and uses the TWL4030 power management IC.
>> >
>> > I think this board support should be in separate patch series with
>> > related patches.
>>
>> Well I wanted to keep them altogether so that I can send a pull request
>> to Benoit and Tony.
>
> Sorry, but can you please tell what makes you to think that you
> can send pull request only when they are altogether ?
>
> Is there any logical dependency with other patches except
> "[PATCH 6/9] ARM: dts: Add OMAP3430 SDP flash memory bindings" is on
> top of this patch ?
>
>>
>> >>
>> >> Signed-off-by: Jon Hunter
>> >> ---
>> >> arch/arm/boot/dts/Makefile |1 +
>> >> arch/arm/boot/dts/omap3430-sdp.dts | 46
>> >>
>> >> 2 files changed, 47 insertions(+)
>> >> create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
>> >>
>> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> >> index 9c62558..89013ed 100644
>> >> --- a/arch/arm/boot/dts/Makefile
>> >> +++ b/arch/arm/boot/dts/Makefile
>> >> @@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
>> >> omap3-beagle-xm.dtb \
>> >> omap3-evm.dtb \
>> >> omap3-tobi.dtb \
>> >> + omap3430-sdp.dtb \
>> >> omap4-panda.dtb \
>> >> omap4-panda-a4.dtb \
>> >> omap4-panda-es.dtb \
>> >> diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
>> >> b/arch/arm/boot/dts/omap3430-sdp.dts
>> >> new file mode 100644
>> >> index 000..be0650d
>> >> --- /dev/null
>> >> +++ b/arch/arm/boot/dts/omap3430-sdp.dts
>> >> @@ -0,0 +1,46 @@
>> >> +/*
>> >> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
>> >> + *
>> >> + * This program is free software; you can redistribute it and/or modify
>> >> + * it under the terms of the GNU General Public License version 2 as
>> >> + * published by the Free Software Foundation.
>> >> + */
>> >> +/dts-v1/;
>> >> +
>> >> +/include/ "omap3.dtsi"
>> >> +
>> >> +/ {
>> >> + model = "TI OMAP3430 SDP";
>> >> + compatible = "ti,omap3430-sdp", "ti,omap3";
>> >
>> > I have not seen any related changes in "board-generic.c" for your board.
>> > So just wanted know, how this board is booting ?
>>
>> If you look at board-generic.c you will see that "ti,omap3" will match
>> the OMAP3 generic machine. So you don't need to modify the board-generic.c.
>
> According to this omap3-beagle.dts and omap3-beagle-xm.dts are also
> booting in some way. So it is not clear to me, why there two
> "DT_MACHINE_START" for omap3. I have seen there is only one
> different in "init_time" for the same.
>
Hi Anil,
You may take a look to commit:
7dd9d50 ARM: OMAP3: Add generic machine descriptor for boards with
OMAP3 GP device
So, the second DT_MACHINE_START is meant to be used by OMAP3 boards
which use GP devices and this is not the case for "ti,omap3430-sdp"
afaiu.
I wonder if instead of adding each OMAP3 board with GP devices such as
"ti,omap3-beagle", is not better to have a "ti,omap3-gp" compatible
property.
The whole point of DT is to decouple the hardware description from the
kernel code so in general we should use the more generic compatible
string ("ti,omap3") unless the hardware has some specifics that have
to be addressed, such as these boards that use GP devices.
>>
>> >> +
>> >> + memory {
>> >> + device_type = "memory";
>> >> + reg = <0x8000 0x1000>; /* 256 MB */
>> >> + };
>> >> +};
>> >> +
>> >> +&i2c1 {
>> >> + clock-frequency = <260>;
>> >> +
>> >> + twl: twl@48 {
>> >> + reg = <0x48>;
>> >> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>> >> + interrupt-parent = <&intc>;
>> >> + };
>> >> +};
>> >> +
>> >> +/include/ "twl4030.dtsi"
>> >> +
>> >> +&mmc1 {
>> >> + vmmc-supply = <&vmmc1>;
>> >> + vmmc_aux-supply = <&vsim>;
>> >> + bus-width = <8>;
>> >> +};
>> >> +
>> >> +&mmc2 {
>> >> + status = "disabled";
>> >> +};
>> >> +
>> >> +&mmc3 {
>> >> + status = "disabled";
>> >> +};
>> >
>> > I think you should disable modules those are not currently used
>> > as they are enabled by default in omap3.dtsi.
>> >
>> > exp:-
>> >
>> > &mcbsp2 {
>> > status = "disabled";
>> > };
>>
>> Well may be we could do that in a follow-up patch. If you look at other
>> omap3 boards we have not gone through and disabled all unused modules
>> either. So although I agree, right now I just want to get minimal
>> support added.
>>
>
> Hmm... But it makes the kernel to call unused driver probe and get failed
> those required some platform date from DT? you can see the kernel boot logs.
>
> Thanks,
>
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 >>>> --- >>>> >>>> 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 >>>> #include >>>> #include >>>> +#include >>>> #include >>>> >>>> #include
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
>> ---
>>
>> 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
>> #include
>> #include
>> +#include
>> #include
>>
>> #include
>> @@ -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_crea
[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
---
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
#include
#include
+#include
#include
#include
@@ -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 V2 11/17] ARM: OMAP2+: Add device-tree support for NOR flash
On Fri, Mar 8, 2013 at 5:58 PM, Jon Hunter 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
> ---
> 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..0
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 wrote:
>
> On 03/08/2013 02:25 PM, Javier Martinez Canillas wrote:
>> On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter wrote:
>>> Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
>>>
>>> Signed-off-by: Jon Hunter
>>> ---
>>> 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
> Cheers
> Jon
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 6:27 PM, Jon Hunter wrote:
> Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
>
> Signed-off-by: Jon Hunter
> ---
> 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
[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
Signed-off-by: Javier Martinez Canillas
Acked-by: Jon Hunter
---
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
Re: [PATCH 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
On Mon, Mar 4, 2013 at 8:23 PM, Jon Hunter wrote: > > On 03/04/2013 12:35 PM, Javier Martinez Canillas wrote: >> 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 >> Signed-off-by: Javier Martinez Canillas >> --- >> .../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: >> > > Thanks. Do you mind putting "interrupt-controller" before > "#interrupt-cells" as I see this is how they have it in > Documenation/devicetree/bindings/interrupt-controller/interrupts.txt? > Otherwise ... > > Acked-by: Jon Hunter > > Cheers > Jon > -- Hi Jon, thanks for the feedback. I just looked at Documentation/devicetree/bindings/gpio/gpio.txt and realized that gpio-controller and #gpio-cells should be flipped as well. Will send a v2 with both changes. Best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[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 Signed-off-by: Javier Martinez Canillas --- .../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
Re: [PATCH] arm: dts: Add uart1 and uart2 to igep boards.
On Fri, Feb 15, 2013 at 11:03 AM, Cousson, Benoit wrote:
> Hi Matthias,
>
>
> On 2/15/2013 10:35 AM, Matthias Brugger wrote:
>>
>> 2013/1/26 Javier Martinez Canillas :
>>>
>>> On Sat, Jan 26, 2013 at 4:16 PM, Matthias Brugger
>>>
>>> wrote:
>>>>
>>>> Hi Benoit,
>>>>
>>>> 2012/12/12 Benoit Cousson :
>>>>>
>>>>> 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
>>>>>> ---
>>>>>> 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
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 wrote: > > On 02/28/2013 06:17 AM, Javier Martinez Canillas wrote: >> On Thu, Feb 28, 2013 at 12:16 AM, Jon Hunter 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_t
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Thu, Feb 28, 2013 at 12:16 AM, Jon Hunter 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 > 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; &g
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Wed, Feb 27, 2013 at 6:50 PM, Stephen Warren wrote: > On 02/26/2013 08:57 PM, Javier Martinez Canillas wrote: >> On Wed, Feb 27, 2013 at 2:07 AM, Jon Hunter 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 Wed, Feb 27, 2013 at 6:47 PM, Stephen Warren 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 2:07 AM, Jon Hunter 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_
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Wed, Feb 27, 2013 at 12:08 AM, 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>;
>
> 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 Tue, Feb 26, 2013 at 11: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.
>
> 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: OMA
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Fri, Feb 24, 2012 at 4:30 PM, Cousson, Benoit 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 Cousson
>> Cc: Tarun Kanti DebBarma
>
>
> One comment below, but otherwise:
>
> Acked-by: Rob Herring
>
>> ---
>>.../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
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
> wrote:
>> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
>> 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 wrote:
> Hi Florian,
>
> On Mon, Jan 28, 2013 at 11:24 PM, Florian Vaussard
> wrote:
>> Add device-tree support for the GPMC controller on the OMAP3.
>>
>> Signed-off-by: Florian Vaussard
>> ---
>> 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
>
> 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 2/7] net: smsc911x: add pinctrl support
On Mon, Feb 11, 2013 at 3:23 PM, Linus Walleij wrote:
> On Sat, Feb 9, 2013 at 9:44 PM, Javier Martinez Canillas
> wrote:
>
>> 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
> (...)
>> + struct pinctrl *pinctrl;
> (...)
>> + 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");
>> + }
>
> NACK.
>
> This will be handled from the device core after the v3.9 merge
> window.
>
> See:
> http://marc.info/?l=linux-kernel&m=135887740715083&w=2
>
Great, I also wondered why it couldn't be part of the device core
since we basically duplicate this in all the DT aware drivers and
pinctrl was not used anywhere after setting to its default state.
This is a nice improvement.
> Yours,
> Linus Walleij
> --
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 12:24 PM, Sascha Hauer 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 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
>> >> 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 3/7] ARM: OMAP: gpmc-smsc911x: add DT dev node init function
On Mon, Feb 11, 2013 at 11:30 AM, Mark Rutland 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 +0000, 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
>> ---
>> .../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
>> #include
>> #include
>> +#include
>>
>> #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)
>> +{
>> + stru
Re: [PATCH RFC 1/7] platform: add a device node
On Mon, Feb 11, 2013 at 9:16 AM, Sascha Hauer 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 >> 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 1/7] platform: add a device node
On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux 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
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
[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
---
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,
&fla
[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
---
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 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
