| Message ID | 1359395648-2137-2-git-send-email-florian.vaussard@epfl.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Florian, On Mon, Jan 28, 2013 at 6:54 PM, Florian Vaussard <florian.vaussard@epfl.ch> wrote: > Add device-tree support for the GPMC controller on the OMAP3. > > Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> > --- > arch/arm/boot/dts/omap3.dtsi | 11 +++++++++++ > 1 files changed, 11 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi > index 6c63118..2ddae38 100644 > --- a/arch/arm/boot/dts/omap3.dtsi > +++ b/arch/arm/boot/dts/omap3.dtsi > @@ -403,5 +403,16 @@ > ti,timer-alwon; > ti,timer-secure; > }; > + > + gpmc: gpmc@6e000000 { > + compatible = "ti,omap3430-gpmc"; > + ti,hwmods = "gpmc"; > + reg = <0x6e000000 0x1000000>; > + interrupts = <20>; > + gpmc,num-cs = <8>; > + gpmc,num-waitpins = <4>; > + #address-cells = <2>; > + #size-cells = <1>; > + }; > }; > }; I had the same patch on a tree I was working on to add DT support for gpmc-smsc911x on an OMAP3 board but I was waiting for Daniel's patches to hit mainline before sending the RFC. So please feel free to add: Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Javier, On 02/04/2013 10:27 AM, Javier Martinez Canillas wrote: > Hi Florian, > > On Mon, Jan 28, 2013 at 6:54 PM, Florian Vaussard > <florian.vaussard@epfl.ch> wrote: >> Add device-tree support for the GPMC controller on the OMAP3. >> >> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> >> --- >> arch/arm/boot/dts/omap3.dtsi | 11 +++++++++++ >> 1 files changed, 11 insertions(+), 0 deletions(-) >> >> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi >> index 6c63118..2ddae38 100644 >> --- a/arch/arm/boot/dts/omap3.dtsi >> +++ b/arch/arm/boot/dts/omap3.dtsi >> @@ -403,5 +403,16 @@ >> ti,timer-alwon; >> ti,timer-secure; >> }; >> + >> + gpmc: gpmc@6e000000 { >> + compatible = "ti,omap3430-gpmc"; >> + ti,hwmods = "gpmc"; >> + reg = <0x6e000000 0x1000000>; >> + interrupts = <20>; >> + gpmc,num-cs = <8>; >> + gpmc,num-waitpins = <4>; >> + #address-cells = <2>; >> + #size-cells = <1>; >> + }; >> }; >> }; > > I had the same patch on a tree I was working on to add DT support for > gpmc-smsc911x on an OMAP3 board but I was waiting for Daniel's patches > to hit mainline before sending the RFC. So please feel free to add: > > Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> > Great, the smsc911x was on my TODO list, I can cross it out :) BTW, do you have a public git for this, so I can test your work on my setup? For the GPMC support, I will have to make a few more more as discussed with Tony, and as I will be away for more than 2 weeks, feel free to go ahead before me. This patchset was only at an RFC stage. Regards, Florian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 4, 2013 at 11:36 AM, Florian Vaussard <florian.vaussard@epfl.ch> wrote: > Hi Javier, > > Hi Florian, > On 02/04/2013 10:27 AM, Javier Martinez Canillas wrote: >> >> Hi Florian, >> >> On Mon, Jan 28, 2013 at 6:54 PM, Florian Vaussard >> <florian.vaussard@epfl.ch> wrote: >>> >>> Add device-tree support for the GPMC controller on the OMAP3. >>> >>> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> >>> --- >>> arch/arm/boot/dts/omap3.dtsi | 11 +++++++++++ >>> 1 files changed, 11 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi >>> index 6c63118..2ddae38 100644 >>> --- a/arch/arm/boot/dts/omap3.dtsi >>> +++ b/arch/arm/boot/dts/omap3.dtsi >>> @@ -403,5 +403,16 @@ >>> ti,timer-alwon; >>> ti,timer-secure; >>> }; >>> + >>> + gpmc: gpmc@6e000000 { >>> + compatible = "ti,omap3430-gpmc"; >>> + ti,hwmods = "gpmc"; >>> + reg = <0x6e000000 0x1000000>; >>> + interrupts = <20>; >>> + gpmc,num-cs = <8>; >>> + gpmc,num-waitpins = <4>; >>> + #address-cells = <2>; >>> + #size-cells = <1>; >>> + }; >>> }; >>> }; >> >> >> I had the same patch on a tree I was working on to add DT support for >> gpmc-smsc911x on an OMAP3 board but I was waiting for Daniel's patches >> to hit mainline before sending the RFC. So please feel free to add: >> >> Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> >> > > Great, the smsc911x was on my TODO list, I can cross it out :) BTW, > do you have a public git for this, so I can test your work on my setup? > Yes, it is the gpmc-smsc911x-wip branch on my github linux tree [1] That branch is Linus master tree + linux-omap/omap-for-v3.9/gpmc + linux-omap-dt/for_3.9/dts plus these patches: Javier Martinez Canillas (4): ARM: OMAP: gpmc-smsc911x: add DT dev node init function ARM: OMAP: gpmc: add support for gpmc-smsc911x child nodes ARM: dts: OMAP: Add an GPMC node for OMAP3 ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support You can browse these patches here [2]. With these patches I have ethernet working on my IGEPv2 but this board uses an OMAP GPIO pin as the smsc911x IRQ line, so it needs to set a mux pin (mcspi1_cs2.gpio_176 INPUT | MODE4) or it will fallback on poll mode. For some reasons I still couldn't figure out (I'm still learning about Device Trees) adding: pinctrl = devm_pinctrl_get_select_default(&pdev->dev); to the gpmc-smsc911x child node parse function (gpmc_smsc911x_init_dt) didn't have a functional effect and I had to initialize the defined pinctrl-single pins for the smsc911x in the omap3_pmx_core device node instead of pmc_smsc911x@0 as I do for other devices (mmc, uarts, etc). So I just removed the devm_pinctrl_get_select_default() call in gpmc_smsc911x_init_dt() in for this RFC. I don't know if this is because arch/arm/mach-omap2/gpmc-smsc911x.c is not a real platform driver (is just a wrapper/helper function) and doesn't have a probe function. Which brings me to the question if my approach of adding a binding for gpmc-smsc911x is correct or if we should extend/use the binding that already exist for smsc911x (Documentation/devicetree/bindings/net/smsc911x.txt). > For the GPMC support, I will have to make a few more more as discussed with > Tony, and as I will be away for more than 2 weeks, feel free to go ahead > before me. This patchset was only at an RFC stage. > > Regards, > > Florian > Yes, I saw on the list that Tony asked you too extend the GPMC DT support. Flash support is on my TODO list too but I don't know if I'm going to have time to work on this in the next few weeks. Since you are thinking to change the binding, there is something I want to discuss with you. We have two different version for each IGEP board, one that uses NAND memory and another that has OneNAND. With board files this is easy because the flash memory type is hardcoded (in hardware) using sysboot pins [3]. So we check the sysboot value and call board_nand_init() or board_onenand_init() accordingly and pass the same static struct mtd_partition igep_flash_partitions[] in both cases. But with DT this is a little bit trickier since you have to define either a nand@0 or onenand@0 child node for the gpmc device node. So, we will have to create lots of dts and dtsi to handle each combination (IGEPv2 + NAND, IGEPv2 + OneNAND, IGEP COM + NAND, etc). I wonder if we could just have a generic gpmc-flash binding and maybe use a "gpmc, flash_type" property or something like that to decide if gpmc_onenand_init() or gpmc_nand_init() has to be called. Thanks a lot and best regards, Javier [1]: git://github.com/martinezjavier/linux.git [2]: https://github.com/martinezjavier/linux/commits/gpmc-smsc911x-wip [3]: http://omappedia.org/wiki/Bootloader_Project#SYSBOOT_Pins -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Javier Martinez Canillas <javier@dowhile0.org> [130204 04:00]: > On Mon, Feb 4, 2013 at 11:36 AM, Florian Vaussard > > Great, the smsc911x was on my TODO list, I can cross it out :) BTW, > > do you have a public git for this, so I can test your work on my setup? > > > > Yes, it is the gpmc-smsc911x-wip branch on my github linux tree [1] > > That branch is Linus master tree + linux-omap/omap-for-v3.9/gpmc + > linux-omap-dt/for_3.9/dts > > plus these patches: > > Javier Martinez Canillas (4): > ARM: OMAP: gpmc-smsc911x: add DT dev node init function > ARM: OMAP: gpmc: add support for gpmc-smsc911x child nodes > ARM: dts: OMAP: Add an GPMC node for OMAP3 > ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support > > You can browse these patches here [2]. > > With these patches I have ethernet working on my IGEPv2 but this board > uses an OMAP GPIO pin as the smsc911x IRQ line, so it needs to set a > mux pin (mcspi1_cs2.gpio_176 INPUT | MODE4) or it will fallback on > poll mode. Great, that's good news :) > For some reasons I still couldn't figure out (I'm still learning about > Device Trees) adding: > > pinctrl = devm_pinctrl_get_select_default(&pdev->dev); > > to the gpmc-smsc911x child node parse function (gpmc_smsc911x_init_dt) > didn't have a functional effect and I had to initialize the defined > pinctrl-single pins for the smsc911x in the omap3_pmx_core device node > instead of pmc_smsc911x@0 as I do for other devices (mmc, uarts, etc). Maybe this is related to the initcall ordering.. > So I just removed the devm_pinctrl_get_select_default() call in > gpmc_smsc911x_init_dt() in for this RFC. > > I don't know if this is because arch/arm/mach-omap2/gpmc-smsc911x.c is > not a real platform driver (is just a wrapper/helper function) and > doesn't have a probe function. ..that function just initializes the pdata for smsc911x driver, and should not be a driver. You need to add devm_pinctrl_get_select_default() to the probe of smsc911x or the GPMC probe. > Which brings me to the question if my approach of adding a binding for > gpmc-smsc911x is correct or if we should extend/use the binding that > already exist for smsc911x > (Documentation/devicetree/bindings/net/smsc911x.txt). We should use the existing smsc911x binding, then have a separate GPMC binding for the GPMC driver. Regards, Tony > [1]: git://github.com/martinezjavier/linux.git > [2]: https://github.com/martinezjavier/linux/commits/gpmc-smsc911x-wip > [3]: http://omappedia.org/wiki/Bootloader_Project#SYSBOOT_Pins -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 4, 2013 at 6:32 PM, Tony Lindgren <tony@atomide.com> wrote: > * Javier Martinez Canillas <javier@dowhile0.org> [130204 04:00]: >> On Mon, Feb 4, 2013 at 11:36 AM, Florian Vaussard >> > Great, the smsc911x was on my TODO list, I can cross it out :) BTW, >> > do you have a public git for this, so I can test your work on my setup? >> > >> >> Yes, it is the gpmc-smsc911x-wip branch on my github linux tree [1] >> >> That branch is Linus master tree + linux-omap/omap-for-v3.9/gpmc + >> linux-omap-dt/for_3.9/dts >> >> plus these patches: >> >> Javier Martinez Canillas (4): >> ARM: OMAP: gpmc-smsc911x: add DT dev node init function >> ARM: OMAP: gpmc: add support for gpmc-smsc911x child nodes >> ARM: dts: OMAP: Add an GPMC node for OMAP3 >> ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support >> >> You can browse these patches here [2]. >> >> With these patches I have ethernet working on my IGEPv2 but this board >> uses an OMAP GPIO pin as the smsc911x IRQ line, so it needs to set a >> mux pin (mcspi1_cs2.gpio_176 INPUT | MODE4) or it will fallback on >> poll mode. > > Great, that's good news :) > it's a start at least :-) >> For some reasons I still couldn't figure out (I'm still learning about >> Device Trees) adding: >> >> pinctrl = devm_pinctrl_get_select_default(&pdev->dev); >> >> to the gpmc-smsc911x child node parse function (gpmc_smsc911x_init_dt) >> didn't have a functional effect and I had to initialize the defined >> pinctrl-single pins for the smsc911x in the omap3_pmx_core device node >> instead of pmc_smsc911x@0 as I do for other devices (mmc, uarts, etc). > > Maybe this is related to the initcall ordering.. > I don't think so since I added the gpmc@6e000000 device node as the last child node for ocp in omap3.dtsi. So, is way after omap3_pmx_core child node is defined. Btw, there is a way to specify the initialization order or the dependencies between device nodes (e.g: gpmc depends on omap3_pmx_core) or is just because of the position inside the DT? >> So I just removed the devm_pinctrl_get_select_default() call in >> gpmc_smsc911x_init_dt() in for this RFC. >> >> I don't know if this is because arch/arm/mach-omap2/gpmc-smsc911x.c is >> not a real platform driver (is just a wrapper/helper function) and >> doesn't have a probe function. > > ..that function just initializes the pdata for smsc911x driver, and > should not be a driver. You need to add devm_pinctrl_get_select_default() > to the probe of smsc911x or the GPMC probe. > Yes, that's what I meant. In that case I would have something like this on my board dts: &gpmc { pinctrl-names = "default"; pinctrl-0 = <&smsc911x_pins>; gpmc_smsc911x@0 { gpmc,cs = <5>; /* IGEP2_SMSC911X_CS */ gpmc,gpio_irq = <176>; /* IGEP2_SMSC911X_GPIO */ gpmc,flags = <18>; /* SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS */ vmmc-supply = <&vddvario>; vmmc_aux-supply = <&vdd33a>; }; }; Are you ok with tha approach? Certainly is better than initializing in omap3_pmx_core node but still is not consistent with other devices where the pinctrl pins are defined inside the node of the device that requires them. >> Which brings me to the question if my approach of adding a binding for >> gpmc-smsc911x is correct or if we should extend/use the binding that >> already exist for smsc911x >> (Documentation/devicetree/bindings/net/smsc911x.txt). > > We should use the existing smsc911x binding, then have a separate GPMC > binding for the GPMC driver. > You mean a binding for GPMC or a binding for gpmc-smsc911x? I don't think that we can use the smsc911x binding directly since gpmc_smsc911x_init() not only initializes the platform data but also does some setup such as requesting a memory range for a specific chip select (gpmc_cs_request), claiming a GPIO and configuring as input (gpio_request_one), etc. You can't just calculate the I/O space address for the GPMC cs your peripheral is connected to and set it on the reg property of the current smsc911x binding, right?. The same can be said for the nic IRQ. Or did I get wrong? > Regards, > > Tony > Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Javier, On 02/04/2013 12:57 PM, Javier Martinez Canillas wrote: [...] > > Yes, I saw on the list that Tony asked you too extend the GPMC DT > support. Flash support is on my TODO list too but I don't know if I'm > going to have time to work on this in the next few weeks. > > Since you are thinking to change the binding, there is something I > want to discuss with you. > > We have two different version for each IGEP board, one that uses NAND > memory and another that has OneNAND. > > With board files this is easy because the flash memory type is > hardcoded (in hardware) using sysboot pins [3]. So we check the > sysboot value and call board_nand_init() or board_onenand_init() > accordingly and pass the same static struct mtd_partition > igep_flash_partitions[] in both cases. > > But with DT this is a little bit trickier since you have to define > either a nand@0 or onenand@0 child node for the gpmc device node. So, > we will have to create lots of dts and dtsi to handle each combination > (IGEPv2 + NAND, IGEPv2 + OneNAND, IGEP COM + NAND, etc). > > I wonder if we could just have a generic gpmc-flash binding and maybe > use a "gpmc, flash_type" property or something like that to decide if > gpmc_onenand_init() or gpmc_nand_init() has to be called. > This boils down to the problem where you have an "if" statement in your board file, and I think no general solution exists. In your suggestion, having a property will force you anyway to write distinct DT files to account for the two versions, so it won't really help if I understand correctly. We would need conditional section inside device trees, at least to test for simple parameters. Or a way to generate several DT blobs based on a single DT source file. Another hackish solution would be to write a meta component, whose probe section would do your test. But this is just a stripped down version of the board file, far from being generic... I will think on it during my holidays :) Regards, Florian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 5, 2013 at 6:23 PM, Florian Vaussard <florian.vaussard@epfl.ch> wrote: > Hi Javier, > Hi Florian, > On 02/04/2013 12:57 PM, Javier Martinez Canillas wrote: > > [...] > > >> >> Yes, I saw on the list that Tony asked you too extend the GPMC DT >> support. Flash support is on my TODO list too but I don't know if I'm >> going to have time to work on this in the next few weeks. >> >> Since you are thinking to change the binding, there is something I >> want to discuss with you. >> >> We have two different version for each IGEP board, one that uses NAND >> memory and another that has OneNAND. >> >> With board files this is easy because the flash memory type is >> hardcoded (in hardware) using sysboot pins [3]. So we check the >> sysboot value and call board_nand_init() or board_onenand_init() >> accordingly and pass the same static struct mtd_partition >> igep_flash_partitions[] in both cases. >> >> But with DT this is a little bit trickier since you have to define >> either a nand@0 or onenand@0 child node for the gpmc device node. So, >> we will have to create lots of dts and dtsi to handle each combination >> (IGEPv2 + NAND, IGEPv2 + OneNAND, IGEP COM + NAND, etc). >> >> I wonder if we could just have a generic gpmc-flash binding and maybe >> use a "gpmc, flash_type" property or something like that to decide if >> gpmc_onenand_init() or gpmc_nand_init() has to be called. >> > > This boils down to the problem where you have an "if" statement in > your board file, and I think no general solution exists. > Yes, this is a general issue since DT uses a declarative paradigm. I was just pointing out that I found that particular issue with the flash memory type on IGEP boards. > In your suggestion, having a property will force you anyway to write > distinct DT files to account for the two versions, so it won't really > help if I understand correctly. We would need conditional > section inside device trees, at least to test for simple parameters. > Or a way to generate several DT blobs based on a single DT source file. > Well you will still need a different dtb for each <board,flash type> combination but it could make your device trees smaller and simpler since you can define your GPMC flash child node on a dtsi where you set all the partition and sizes and export that device node to your boards dts that only set the "gpmc, flash_type" property to nand or onenand (assuming both your NAND and OneNAND version have the same partition layout and sizes). Otherwise you would have to define the complete onenand or nand child node on your board dts having duplicated definition for your flash partition layouts. > Another hackish solution would be to write a meta component, whose > probe section would do your test. But this is just a stripped down version > of the board file, far from being generic... > Yes, and that doesn't fit on the DT model too well. I still don't know what's the best way to do it. > I will think on it during my holidays :) > great, I hope you enjoy your holidays :-) > Regards, > > Florian > Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Florian, On Mon, Jan 28, 2013 at 11:24 PM, Florian Vaussard <florian.vaussard@epfl.ch> wrote: > Add device-tree support for the GPMC controller on the OMAP3. > > Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> > --- > arch/arm/boot/dts/omap3.dtsi | 11 +++++++++++ > 1 files changed, 11 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi > index 6c63118..2ddae38 100644 > --- a/arch/arm/boot/dts/omap3.dtsi > +++ b/arch/arm/boot/dts/omap3.dtsi > @@ -403,5 +403,16 @@ > ti,timer-alwon; > ti,timer-secure; > }; > + > + gpmc: gpmc@6e000000 { > + compatible = "ti,omap3430-gpmc"; > + ti,hwmods = "gpmc"; > + reg = <0x6e000000 0x1000000>; > + 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 <anilk4.v@gmail.com> Thanks, Anil -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Feb 16, 2013 at 2:09 PM, Anil Kumar <anilkumar880@gmail.com> wrote: > Hi Florian, > > On Mon, Jan 28, 2013 at 11:24 PM, Florian Vaussard > <florian.vaussard@epfl.ch> wrote: >> Add device-tree support for the GPMC controller on the OMAP3. >> >> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> >> --- >> arch/arm/boot/dts/omap3.dtsi | 11 +++++++++++ >> 1 files changed, 11 insertions(+), 0 deletions(-) >> >> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi >> index 6c63118..2ddae38 100644 >> --- a/arch/arm/boot/dts/omap3.dtsi >> +++ b/arch/arm/boot/dts/omap3.dtsi >> @@ -403,5 +403,16 @@ >> ti,timer-alwon; >> ti,timer-secure; >> }; >> + >> + gpmc: gpmc@6e000000 { >> + compatible = "ti,omap3430-gpmc"; >> + ti,hwmods = "gpmc"; >> + reg = <0x6e000000 0x1000000>; >> + 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 <anilk4.v@gmail.com> > > Thanks, > Anil > Hello Tony and Benoit, Could this patch be merged to one of your branches? It has already my Reviewed-by and now Anil's Tested-by. Now that Daniel's OMAP GPMC binding were merged, there seems to be many people working on adding support on their boards DT for peripherals connected through the GPMC (NAND, OneNAND, SMSC LAN, etc). I think it will be easier if people can base their work on top of this patch instead of duplicating the work and sending the same patch to add a GPMC device node to omap3.dtsi on each patch-set. Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Javier, On 2/16/2013 5:44 PM, Javier Martinez Canillas wrote: > On Sat, Feb 16, 2013 at 2:09 PM, Anil Kumar <anilkumar880@gmail.com> wrote: >> Hi Florian, >> >> On Mon, Jan 28, 2013 at 11:24 PM, Florian Vaussard >> <florian.vaussard@epfl.ch> wrote: >>> Add device-tree support for the GPMC controller on the OMAP3. >>> >>> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> >>> --- >>> arch/arm/boot/dts/omap3.dtsi | 11 +++++++++++ >>> 1 files changed, 11 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi >>> index 6c63118..2ddae38 100644 >>> --- a/arch/arm/boot/dts/omap3.dtsi >>> +++ b/arch/arm/boot/dts/omap3.dtsi >>> @@ -403,5 +403,16 @@ >>> ti,timer-alwon; >>> ti,timer-secure; >>> }; >>> + >>> + gpmc: gpmc@6e000000 { >>> + compatible = "ti,omap3430-gpmc"; >>> + ti,hwmods = "gpmc"; >>> + reg = <0x6e000000 0x1000000>; >>> + 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 <anilk4.v@gmail.com> >> >> Thanks, >> Anil >> > > Hello Tony and Benoit, > > Could this patch be merged to one of your branches? I'll take it. > 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. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/28/2013 11:54 AM, Florian Vaussard wrote: > Add device-tree support for the GPMC controller on the OMAP3. > > Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> > --- > arch/arm/boot/dts/omap3.dtsi | 11 +++++++++++ > 1 files changed, 11 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi > index 6c63118..2ddae38 100644 > --- a/arch/arm/boot/dts/omap3.dtsi > +++ b/arch/arm/boot/dts/omap3.dtsi > @@ -403,5 +403,16 @@ > ti,timer-alwon; > ti,timer-secure; > }; > + > + gpmc: gpmc@6e000000 { > + compatible = "ti,omap3430-gpmc"; > + ti,hwmods = "gpmc"; > + reg = <0x6e000000 0x1000000>; Can you make this size smaller? Although the reference manual states 16MB, the registers use less than 1KB of address space. Hence, it is pointless mapping all this address space for the gpmc registers. > + interrupts = <20>; > + gpmc,num-cs = <8>; > + gpmc,num-waitpins = <4>; > + #address-cells = <2>; > + #size-cells = <1>; > + }; > }; > }; Otherwise ... Reviewed-by: Jon Hunter <jon-hunter@ti.com> Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Florian, On 01/28/2013 06:54 PM, Florian Vaussard wrote: > Add device-tree support for the GPMC controller on the OMAP3. > > Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> Applied and pushed. git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@6e000000 { + compatible = "ti,omap3430-gpmc"; + ti,hwmods = "gpmc"; + reg = <0x6e000000 0x1000000>; + interrupts = <20>; + gpmc,num-cs = <8>; + gpmc,num-waitpins = <4>; + #address-cells = <2>; + #size-cells = <1>; + }; }; };
Add device-tree support for the GPMC controller on the OMAP3. Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> --- arch/arm/boot/dts/omap3.dtsi | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-)