Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On Wed, Mar 6, 2013 at 1:54 PM, Ezequiel Garcia wrote: > On Wed, Mar 6, 2013 at 1:46 PM, Jon Hunter wrote: >> >> On 03/06/2013 05:58 AM, Ezequiel Garcia wrote: >>> I'll submit this driver by the end of this week, in case you want >>> to take a look at it. >> >> Ok, but this is not for omap right? >> > > No, this is a new driver for a memory controller that's available on > some Marvell SoC. It will be located in drivers/memory/. > Slightly OT: if anyone wants to see the memory-controller driver for mvebu platforms, I just posted in lakml. It's this patchset: "[PATCH 0/5] Device Bus support for Marvell EBU SoC" -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 03/06/2013 11:00 AM, Jon Hunter wrote:
>
> On 03/06/2013 10:48 AM, Mark Jackson wrote:
>> On 06/03/13 16:44, Jon Hunter wrote:
>>>
>>> On 03/06/2013 07:30 AM, Mark Jackson wrote:
On 06/03/13 10:23, Mark Jackson wrote:
>>
>>
>>
> [1.541884] gpmc_probe_nor_child 1
> [1.545483] GPMC_CS_CONFIG7_0 : 0f48
> [1.549621] GPMC_CS_CONFIG7_1 : 0f58
> [1.553812] GPMC_CS_CONFIG7_2 : 0f00
> [1.557951] GPMC_CS_CONFIG7_3 : 0c5a
0x0c5a is an invalid mode !!
I'm trying to use a 64MB address space but not on a 64MB boundary ... oops.
>>>
>>> Good catch. So this is now working for you then?
>>
>> Not yet ... I got distracted by something else !?!
>>
>> I'll take another look tomorrow.
>>
>> Do you think it might be worth adding some sanity checking to the cs config
>> routines to trap similar errors ?
>
> Yes, I see what you mean. We should check to ensure that the the base is
> aligned on a boundary that matches the size being configured.
>
> I can add some checking for this case.
How about something like ...
Cheers
Jon
>From 4d6396ef49e34b06085a4036b795ab6faf29509c Mon Sep 17 00:00:00 2001
From: Jon Hunter
Date: Wed, 6 Mar 2013 12:00:10 -0600
Subject: [PATCH] ARM: OMAP2+: Detect incorrectly aligned GPMC base address
---
arch/arm/mach-omap2/gpmc.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8e6f019..aeef0a2 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -410,11 +410,18 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
return 0;
}
-static void gpmc_cs_enable_mem(int cs, u32 base, u32 size)
+static int gpmc_cs_enable_mem(int cs, u32 base, u32 size)
{
u32 l;
u32 mask;
+ /*
+* Ensure that base address is aligned
+* on a boundary greater than size.
+*/
+ if (base & (size - 1))
+ return -EINVAL;
+
mask = (1 << GPMC_SECTION_SHIFT) - size;
l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7);
l &= ~0x3f;
@@ -423,6 +430,8 @@ static void gpmc_cs_enable_mem(int cs, u32 base, u32 size)
l |= ((mask >> GPMC_CHUNK_SHIFT) & 0x0f) << 8;
l |= GPMC_CONFIG7_CSVALID;
gpmc_cs_write_reg(cs, GPMC_CS_CONFIG7, l);
+
+ return 0;
}
static void gpmc_cs_disable_mem(int cs)
@@ -541,7 +550,9 @@ static int gpmc_cs_remap(int cs, u32 base)
ret = gpmc_cs_insert_mem(cs, base, size);
if (IS_ERR_VALUE(ret))
return ret;
- gpmc_cs_enable_mem(cs, base, size);
+ ret = gpmc_cs_enable_mem(cs, base, size);
+ if (IS_ERR_VALUE(ret))
+ return ret;
return 0;
}
@@ -571,7 +582,12 @@ int gpmc_cs_request(int cs, unsigned long size, unsigned
long *base)
if (r < 0)
goto out;
- gpmc_cs_enable_mem(cs, res->start, resource_size(res));
+ r = gpmc_cs_enable_mem(cs, res->start, resource_size(res));
+ if (IS_ERR_VALUE(r)) {
+ release_resource(res);
+ goto out;
+ }
+
*base = res->start;
gpmc_cs_set_reserved(cs, 1);
out:
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 03/06/2013 10:48 AM, Mark Jackson wrote: > On 06/03/13 16:44, Jon Hunter wrote: >> >> On 03/06/2013 07:30 AM, Mark Jackson wrote: >>> On 06/03/13 10:23, Mark Jackson wrote: > > > [1.541884] gpmc_probe_nor_child 1 [1.545483] GPMC_CS_CONFIG7_0 : 0f48 [1.549621] GPMC_CS_CONFIG7_1 : 0f58 [1.553812] GPMC_CS_CONFIG7_2 : 0f00 [1.557951] GPMC_CS_CONFIG7_3 : 0c5a >>> >>> 0x0c5a is an invalid mode !! >>> >>> I'm trying to use a 64MB address space but not on a 64MB boundary ... oops. >> >> Good catch. So this is now working for you then? > > Not yet ... I got distracted by something else !?! > > I'll take another look tomorrow. > > Do you think it might be worth adding some sanity checking to the cs config > routines to trap similar errors ? Yes, I see what you mean. We should check to ensure that the the base is aligned on a boundary that matches the size being configured. I can add some checking for this case. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On Wed, Mar 6, 2013 at 1:46 PM, Jon Hunter wrote: > > On 03/06/2013 05:58 AM, Ezequiel Garcia wrote: >> I'll submit this driver by the end of this week, in case you want >> to take a look at it. > > Ok, but this is not for omap right? > No, this is a new driver for a memory controller that's available on some Marvell SoC. It will be located in drivers/memory/. I don't have any omap boards with a NOR device to test this, but the discussion and the patches were really helpful! Thanks, -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 06/03/13 16:44, Jon Hunter wrote: > > On 03/06/2013 07:30 AM, Mark Jackson wrote: >> On 06/03/13 10:23, Mark Jackson wrote: >>> [1.541884] gpmc_probe_nor_child 1 >>> [1.545483] GPMC_CS_CONFIG7_0 : 0f48 >>> [1.549621] GPMC_CS_CONFIG7_1 : 0f58 >>> [1.553812] GPMC_CS_CONFIG7_2 : 0f00 >>> [1.557951] GPMC_CS_CONFIG7_3 : 0c5a >> >> 0x0c5a is an invalid mode !! >> >> I'm trying to use a 64MB address space but not on a 64MB boundary ... oops. > > Good catch. So this is now working for you then? Not yet ... I got distracted by something else !?! I'll take another look tomorrow. Do you think it might be worth adding some sanity checking to the cs config routines to trap similar errors ? Cheers Mark J. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 03/06/2013 05:58 AM, Ezequiel Garcia wrote: > Jon, > > On Tue, Mar 5, 2013 at 6:34 PM, Jon Hunter wrote: >> >> By the way, with this version you should remove "simple-bus" from your >> gpmc node compatible strings. I now call of_platform_device_create() to >> create the child device during the GPMC probe. I think that this is a >> safer approach. >> > > FWIW, using of_platform_device_create() works for my driver. > It seems as simple as using a compatible 'simple-bus', > with the advantage that it allows to create and probe the > child device from its parent. Yes and I think that is safer for these type of drivers. > I'll submit this driver by the end of this week, in case you want > to take a look at it. Ok, but this is not for omap right? Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 03/06/2013 07:30 AM, Mark Jackson wrote: > On 06/03/13 10:23, Mark Jackson wrote: >> On 05/03/13 21:34, Jon Hunter wrote: >>> >>> On 03/05/2013 11:30 AM, Jon Hunter wrote: On 03/05/2013 10:20 AM, Mark Jackson wrote: >>> >>> [snip] >>> > But I can see in physmap_of.c that the device gets registered without any > call to > devm_pinctrl_get_select_default() and hence no probe deferring takes > place is the > pinctrl device hasn't yet been started (which it hasn't). > > Does probe deferral need adding to physmap_of.c, or should the pinctrl > device really > be registered sooner ? I see, so the pinctrl driver is not getting probed until later. >>> >>> Can you give this version of the patch a go? I have re-worked the patch >>> so the NOR device will only be registered after the GPMC probe completes. >>> >>> By the way, with this version you should remove "simple-bus" from your >>> gpmc node compatible strings. I now call of_platform_device_create() to >>> create the child device during the GPMC probe. I think that this is a >>> safer approach. >> >> This is better in that the probe *is* now delayed until the gpmc has been >> setup, >> but I still get an oops. >> >> However, this time it's in the actual cfi query code. >> >> I've traced it down to when it tries to physically access the memory >> associated >> with the chip select in question (in this case CS3 @ 0x1a00). >> >> I printed some debug info to show that the GPMC CONFIG7 register is being >> setup >> correctly, and I show the physical to virtual memory mapping values, as >> performed >> in of_flash_probe(), but when I try to do a test raw_readw() on the virtual >> address, >> I get the following:- >> >> [1.222950] omap-gpmc 5000.gpmc: GPMC revision 6.0 >> [1.229002] gpmc_read_settings_dt: read/write wait monitoring not enabled! >> [1.237916] enabling NAND BCH ecc with 8-bit correction >> [1.243843] ONFI param page 0 valid >> [1.247531] ONFI flash detected >> [1.250856] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron >> MT29F2G08ABAEAWP), 256MiB, page size: 2048, OOB size: 64 >> [1.263149] 8 ofpart partitions found on MTD device omap2-nand.0 >> [1.269492] Creating 8 MTD partitions on "omap2-nand.0": >> [1.275150] 0x-0x0002 : "spl1" >> [1.282593] 0x0002-0x0004 : "spl2" >> [1.288524] 0x0004-0x0006 : "spl3" >> [1.294456] 0x0006-0x0008 : "spl4" >> [1.300270] 0x0008-0x001e : "boot" >> [1.307224] 0x001e-0x0020 : "env" >> [1.313093] 0x0020-0x0420 : "rootfs" >> [1.373589] 0x0420-0x1000 : "data" >> [1.541884] gpmc_probe_nor_child 1 >> [1.545483] GPMC_CS_CONFIG7_0 : 0f48 >> [1.549621] GPMC_CS_CONFIG7_1 : 0f58 >> [1.553812] GPMC_CS_CONFIG7_2 : 0f00 >> [1.557951] GPMC_CS_CONFIG7_3 : 0c5a > > 0x0c5a is an invalid mode !! > > I'm trying to use a 64MB address space but not on a 64MB boundary ... oops. Good catch. So this is now working for you then? Thanks Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 06/03/13 10:23, Mark Jackson wrote: > On 05/03/13 21:34, Jon Hunter wrote: >> >> On 03/05/2013 11:30 AM, Jon Hunter wrote: >>> On 03/05/2013 10:20 AM, Mark Jackson wrote: >> >> [snip] >> But I can see in physmap_of.c that the device gets registered without any call to devm_pinctrl_get_select_default() and hence no probe deferring takes place is the pinctrl device hasn't yet been started (which it hasn't). Does probe deferral need adding to physmap_of.c, or should the pinctrl device really be registered sooner ? >>> >>> I see, so the pinctrl driver is not getting probed until later. >> >> Can you give this version of the patch a go? I have re-worked the patch >> so the NOR device will only be registered after the GPMC probe completes. >> >> By the way, with this version you should remove "simple-bus" from your >> gpmc node compatible strings. I now call of_platform_device_create() to >> create the child device during the GPMC probe. I think that this is a >> safer approach. > > This is better in that the probe *is* now delayed until the gpmc has been > setup, > but I still get an oops. > > However, this time it's in the actual cfi query code. > > I've traced it down to when it tries to physically access the memory > associated > with the chip select in question (in this case CS3 @ 0x1a00). > > I printed some debug info to show that the GPMC CONFIG7 register is being > setup > correctly, and I show the physical to virtual memory mapping values, as > performed > in of_flash_probe(), but when I try to do a test raw_readw() on the virtual > address, > I get the following:- > > [1.222950] omap-gpmc 5000.gpmc: GPMC revision 6.0 > [1.229002] gpmc_read_settings_dt: read/write wait monitoring not enabled! > [1.237916] enabling NAND BCH ecc with 8-bit correction > [1.243843] ONFI param page 0 valid > [1.247531] ONFI flash detected > [1.250856] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron > MT29F2G08ABAEAWP), 256MiB, page size: 2048, OOB size: 64 > [1.263149] 8 ofpart partitions found on MTD device omap2-nand.0 > [1.269492] Creating 8 MTD partitions on "omap2-nand.0": > [1.275150] 0x-0x0002 : "spl1" > [1.282593] 0x0002-0x0004 : "spl2" > [1.288524] 0x0004-0x0006 : "spl3" > [1.294456] 0x0006-0x0008 : "spl4" > [1.300270] 0x0008-0x001e : "boot" > [1.307224] 0x001e-0x0020 : "env" > [1.313093] 0x0020-0x0420 : "rootfs" > [1.373589] 0x0420-0x1000 : "data" > [1.541884] gpmc_probe_nor_child 1 > [1.545483] GPMC_CS_CONFIG7_0 : 0f48 > [1.549621] GPMC_CS_CONFIG7_1 : 0f58 > [1.553812] GPMC_CS_CONFIG7_2 : 0f00 > [1.557951] GPMC_CS_CONFIG7_3 : 0c5a 0x0c5a is an invalid mode !! I'm trying to use a 64MB address space but not on a 64MB boundary ... oops. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
Jon, On Tue, Mar 5, 2013 at 6:34 PM, Jon Hunter wrote: > > By the way, with this version you should remove "simple-bus" from your > gpmc node compatible strings. I now call of_platform_device_create() to > create the child device during the GPMC probe. I think that this is a > safer approach. > FWIW, using of_platform_device_create() works for my driver. It seems as simple as using a compatible 'simple-bus', with the advantage that it allows to create and probe the child device from its parent. I'll submit this driver by the end of this week, in case you want to take a look at it. Thanks a lot, -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 05/03/13 21:34, Jon Hunter wrote: > > On 03/05/2013 11:30 AM, Jon Hunter wrote: >> On 03/05/2013 10:20 AM, Mark Jackson wrote: > > [snip] > >>> But I can see in physmap_of.c that the device gets registered without any >>> call to >>> devm_pinctrl_get_select_default() and hence no probe deferring takes place >>> is the >>> pinctrl device hasn't yet been started (which it hasn't). >>> >>> Does probe deferral need adding to physmap_of.c, or should the pinctrl >>> device really >>> be registered sooner ? >> >> I see, so the pinctrl driver is not getting probed until later. > > Can you give this version of the patch a go? I have re-worked the patch > so the NOR device will only be registered after the GPMC probe completes. > > By the way, with this version you should remove "simple-bus" from your > gpmc node compatible strings. I now call of_platform_device_create() to > create the child device during the GPMC probe. I think that this is a > safer approach. This is better in that the probe *is* now delayed until the gpmc has been setup, but I still get an oops. However, this time it's in the actual cfi query code. I've traced it down to when it tries to physically access the memory associated with the chip select in question (in this case CS3 @ 0x1a00). I printed some debug info to show that the GPMC CONFIG7 register is being setup correctly, and I show the physical to virtual memory mapping values, as performed in of_flash_probe(), but when I try to do a test raw_readw() on the virtual address, I get the following:- [1.222950] omap-gpmc 5000.gpmc: GPMC revision 6.0 [1.229002] gpmc_read_settings_dt: read/write wait monitoring not enabled! [1.237916] enabling NAND BCH ecc with 8-bit correction [1.243843] ONFI param page 0 valid [1.247531] ONFI flash detected [1.250856] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron MT29F2G08ABAEAWP), 256MiB, page size: 2048, OOB size: 64 [1.263149] 8 ofpart partitions found on MTD device omap2-nand.0 [1.269492] Creating 8 MTD partitions on "omap2-nand.0": [1.275150] 0x-0x0002 : "spl1" [1.282593] 0x0002-0x0004 : "spl2" [1.288524] 0x0004-0x0006 : "spl3" [1.294456] 0x0006-0x0008 : "spl4" [1.300270] 0x0008-0x001e : "boot" [1.307224] 0x001e-0x0020 : "env" [1.313093] 0x0020-0x0420 : "rootfs" [1.373589] 0x0420-0x1000 : "data" [1.541884] gpmc_probe_nor_child 1 [1.545483] GPMC_CS_CONFIG7_0 : 0f48 [1.549621] GPMC_CS_CONFIG7_1 : 0f58 [1.553812] GPMC_CS_CONFIG7_2 : 0f00 [1.557951] GPMC_CS_CONFIG7_3 : 0c5a [1.564789] of_flash_probe ioremap : phys 1a00 -> virt d300 [1.571468] of_flash_probe test read d300 ... [1.576440] Unhandled fault: external abort on non-linefetch (0x1028) at 0xd300 [1.584525] Internal error: : 1028 [#1] ARM [1.588946] CPU: 0Not tainted (3.9.0-rc1-12191-ga00d6d1-dirty #57) [1.595943] PC is at of_flash_probe+0x22c/0x5dc [1.600724] LR is at of_flash_probe+0x228/0x5dc [1.605506] pc : []lr : []psr: 2113 [1.605506] sp : cf077ba0 ip : cf06c080 fp : c0492150 [1.617621] r10: 0400 r9 : cf2ac6d0 r8 : [1.623135] r7 : cf2ac6d0 r6 : cf2b9010 r5 : cf2b9000 r4 : c0c81f60 [1.630027] r3 : d300 r2 : r1 : cf06c4d8 r0 : 0025 [1.636921] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [1.644635] Control: 10c5387d Table: 80004019 DAC: 0015 [1.650703] Process kworker/u:0 (pid: 6, stack limit = 0xcf076238) [1.657225] Stack: (0xcf077ba0 to 0xcf078000) Any ideas ? Cheers Mark J. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 03/05/2013 11:30 AM, Jon Hunter wrote:
> On 03/05/2013 10:20 AM, Mark Jackson wrote:
[snip]
>> But I can see in physmap_of.c that the device gets registered without any
>> call to
>> devm_pinctrl_get_select_default() and hence no probe deferring takes place
>> is the
>> pinctrl device hasn't yet been started (which it hasn't).
>>
>> Does probe deferral need adding to physmap_of.c, or should the pinctrl
>> device really
>> be registered sooner ?
>
> I see, so the pinctrl driver is not getting probed until later.
Can you give this version of the patch a go? I have re-worked the patch
so the NOR device will only be registered after the GPMC probe completes.
By the way, with this version you should remove "simple-bus" from your
gpmc node compatible strings. I now call of_platform_device_create() to
create the child device during the GPMC probe. I think that this is a
safer approach.
Cheers
Jon
>From 278ef0ac538da720fc15896ad6c3666e0f518633 Mon Sep 17 00:00:00 2001
From: Jon Hunter
Date: Fri, 8 Feb 2013 16:46:13 -0600
Subject: [PATCH] ARM: OMAP2+: Add device-tree support for NOR flash
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>;
+
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 03/05/2013 11:43 AM, Ezequiel Garcia wrote: > Hi Jon, > > On Tue, Mar 5, 2013 at 2:30 PM, Jon Hunter wrote: >> >> This really highlights a weakness in the GPMC driver, particularly >> for NOR, where the child device can only be probed once the parent >> is probed. I don't see this as being DT specific issue, because >> even on older OMAP boards we always registered the NOR flash device >> independently of the GPMC device. So we have always been susceptible to >> this problem AFAICT. >> >> This is admittedly a hack, but I am curious if you add the pinctrl >> properties to the NOR node, if this would also defer the probe on the >> NOR device? >> >> Ideally it would be great to defer the probing of the child until the >> parent has been probed successfully. >> > > This seems related to the probing parent-child ordering probing > I pointed out in a previous mail, isn't it? Yes in this case. However, I have no idea what the problem you are having is. So I cannot comment if your problem represents a real scenario or not. > (which by the way, I'll answer when I can gather some more convincing > feedback). Thanks. > I don't have OMAP NOR boards, so I'm not entirely familiar to the > way GPMC registers the NOR device. However, by looking > into board-flash.c:board_nor_init() function, it seems to me that: > > 1. first we request the CS with gpmc_cs_request() and > 2. later we register the NOR device explicitly with > platform_device_register(). > > So, unless I'm missing something, we force the NOR device > to be probed *after* the GPMC device. > > This is definitely the way NAND, OneNAND is handled. > > On the otherside, by using 'simple-bus' you create your devices > first, when the whole device-tree is parsed and later the drivers > are probed at module_initcall time. > > So, AFAIK, this problem is DT specific. This assumes that the GPMC driver is registered (and probed) before 1 and 2 above occur. What is DT specific about when the driver is registered? What happens in the non-DT case when the GPMC probe is deferred or fails? We would never register the GPMC devices, right? For the deferred case that is not so good. So the current implementation is flawed if the probe is deferred. However, it would not crash which is a plus. So my point is in Mark's example, if someone were to add pinctrl support to the existing GPMC driver which caused the GPMC probe to be deferred then none of the GPMC child devices would ever be registered. I don't see that being related to DT either. What you are also missing is that in the probe_nor() function, if we fail to allocate the required resources, then I disable the child node and the child is not registered and hence not probed. I have tested this and for me this works. I was hoping this would be sufficient to handle failure cases and avoid crashes. > On the other side, when you say we should defer the probing > of the child. Do you mean changing something in physmap/NAND/etc. drivers? Not necessarily. > Please keep in mind, I have nothing against using simple-bus, > since it's a very clean solution. It's just that it seems to me it will > be problematic. > Moreover, the fix shouldn't be too complicated (still working on this). I am interested to know what your approach will be. One alternative is to call of_platform_device_create() from the GPMC driver. I could see this as being a safe option. > I'll try to post my Device Bus driver soon (similar to GPMC) > and also I'll try to answer the previous discussion with some > information on why I think this won't work. > > (I hope I'm not making too much noise with this) No it is all good inputs. I am just frustrated to be told that this implementation is flawed without being able to tell me exactly why or the scenario where it would not work. The probe deferred case is a good example where this implementation will have problems. I see that as legitimate. However, I have no idea if what you are reporting is also legitimate or not. May be it is, I just don't know. Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
Hi Jon, On Tue, Mar 5, 2013 at 2:30 PM, Jon Hunter wrote: > > This really highlights a weakness in the GPMC driver, particularly > for NOR, where the child device can only be probed once the parent > is probed. I don't see this as being DT specific issue, because > even on older OMAP boards we always registered the NOR flash device > independently of the GPMC device. So we have always been susceptible to > this problem AFAICT. > > This is admittedly a hack, but I am curious if you add the pinctrl > properties to the NOR node, if this would also defer the probe on the > NOR device? > > Ideally it would be great to defer the probing of the child until the > parent has been probed successfully. > This seems related to the probing parent-child ordering probing I pointed out in a previous mail, isn't it? (which by the way, I'll answer when I can gather some more convincing feedback). I don't have OMAP NOR boards, so I'm not entirely familiar to the way GPMC registers the NOR device. However, by looking into board-flash.c:board_nor_init() function, it seems to me that: 1. first we request the CS with gpmc_cs_request() and 2. later we register the NOR device explicitly with platform_device_register(). So, unless I'm missing something, we force the NOR device to be probed *after* the GPMC device. This is definitely the way NAND, OneNAND is handled. On the otherside, by using 'simple-bus' you create your devices first, when the whole device-tree is parsed and later the drivers are probed at module_initcall time. So, AFAIK, this problem is DT specific. On the other side, when you say we should defer the probing of the child. Do you mean changing something in physmap/NAND/etc. drivers? Please keep in mind, I have nothing against using simple-bus, since it's a very clean solution. It's just that it seems to me it will be problematic. Moreover, the fix shouldn't be too complicated (still working on this). I'll try to post my Device Bus driver soon (similar to GPMC) and also I'll try to answer the previous discussion with some information on why I think this won't work. (I hope I'm not making too much noise with this) -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 03/05/2013 10:20 AM, Mark Jackson wrote:
> On 05/03/13 14:46, Jon Hunter wrote:
>>
>> On 03/05/2013 08:34 AM, Mark Jackson wrote:
>>> On 26/02/13 17:30, 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
>>>
>>> I'm trying to test this series, and am unable get my NOR device recognised.
>>>
>>> If I remove all reference to NOR (and keep only my NAND device definition),
>>> then
>>> everything seems to boot fine (so I'm assuming I've got at least the basics
>>> of
>>> the patch set working).
>>>
>>> My GPMC tree looks like this:-
>
>
>
>>> nor@1,0 {
>>> reg = <3 0x 0x0400>;
>>> compatible = "cfi-flash";
>>> linux,mtd-name = "spansion,s29gl064n90t";
>>> bank-width = <2>;
>>>
>>> gpmc,device-width = <1>;
>>
>> Only bank-width should be necessary for NOR (per the binding
>> documentation). However, if you do specify both, then they should match.
>> Do you have two 8-bits devices? If so may be I need to update the
>> documentation to make it clear this is the total width of all devices
>> for a given chip-select.
>
> No ... that was wrong, so I've fixed that.
Ok, I may update the documentation to make this clearer anyway.
>
>
>>> Booting with this NOR device produces the following oops:-
>>>
>>> [0.00] Booting Linux on physical CPU 0x0
>>> [0.00] Linux version 3.9.0-rc1-12191-ga00d6d1-dirty
>>> (mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #33 Tue Mar 5
>>> 13:08:25 GMT 2013
>>> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
>>> cr=10c53c7d
>
>
>
>>> [0.236730] omap-gpmc 5000.gpmc: could not find pctldev for node
>>> /pinmux@44e10800/gpmc_pins, deferring probe
>>> [0.236781] platform 5000.gpmc: Driver omap-gpmc requests probe
>>> deferral
>>
>> This look like your problem. I would figure out why this is failing and
>> try again.
>
> H ... I get this even when I've no NOR device defined and the board boots
> up fine.
So for NAND, the device does not get registered until the GPMC probe
completes. However, in the case of NOR, DT is registering the GPMC
and its child devices and so it is working slightly different in
this case.
> But I can see in physmap_of.c that the device gets registered without any
> call to
> devm_pinctrl_get_select_default() and hence no probe deferring takes place is
> the
> pinctrl device hasn't yet been started (which it hasn't).
>
> Does probe deferral need adding to physmap_of.c, or should the pinctrl device
> really
> be registered sooner ?
I see, so the pinctrl driver is not getting probed until later.
This really highlights a weakness in the GPMC driver, particularly
for NOR, where the child device can only be probed once the parent
is probed. I don't see this as being DT specific issue, because
even on older OMAP boards we always registered the NOR flash device
independently of the GPMC device. So we have always been susceptible to
this problem AFAICT.
This is admittedly a hack, but I am curious if you add the pinctrl
properties to the NOR node, if this would also defer the probe on the
NOR device?
Ideally it would be great to defer the probing of the child until the
parent has been probed successfully.
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 05/03/13 14:46, Jon Hunter wrote:
>
> On 03/05/2013 08:34 AM, Mark Jackson wrote:
>> On 26/02/13 17:30, 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
>>
>> I'm trying to test this series, and am unable get my NOR device recognised.
>>
>> If I remove all reference to NOR (and keep only my NAND device definition),
>> then
>> everything seems to boot fine (so I'm assuming I've got at least the basics
>> of
>> the patch set working).
>>
>> My GPMC tree looks like this:-
>> nor@1,0 {
>> reg = <3 0x 0x0400>;
>> compatible = "cfi-flash";
>> linux,mtd-name = "spansion,s29gl064n90t";
>> bank-width = <2>;
>>
>> gpmc,device-width = <1>;
>
> Only bank-width should be necessary for NOR (per the binding
> documentation). However, if you do specify both, then they should match.
> Do you have two 8-bits devices? If so may be I need to update the
> documentation to make it clear this is the total width of all devices
> for a given chip-select.
No ... that was wrong, so I've fixed that.
>> Booting with this NOR device produces the following oops:-
>>
>> [0.00] Booting Linux on physical CPU 0x0
>> [0.00] Linux version 3.9.0-rc1-12191-ga00d6d1-dirty
>> (mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #33 Tue Mar 5
>> 13:08:25 GMT 2013
>> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
>> cr=10c53c7d
>> [0.236730] omap-gpmc 5000.gpmc: could not find pctldev for node
>> /pinmux@44e10800/gpmc_pins, deferring probe
>> [0.236781] platform 5000.gpmc: Driver omap-gpmc requests probe
>> deferral
>
> This look like your problem. I would figure out why this is failing and
> try again.
H ... I get this even when I've no NOR device defined and the board boots
up fine.
But I can see in physmap_of.c that the device gets registered without any call
to
devm_pinctrl_get_select_default() and hence no probe deferring takes place is
the
pinctrl device hasn't yet been started (which it hasn't).
Does probe deferral need adding to physmap_of.c, or should the pinctrl device
really
be registered sooner ?
Cheers
Mark J.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 03/05/2013 08:34 AM, Mark Jackson wrote:
> On 26/02/13 17:30, 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
>
> I'm trying to test this series, and am unable get my NOR device recognised.
>
> If I remove all reference to NOR (and keep only my NAND device definition),
> then
> everything seems to boot fine (so I'm assuming I've got at least the basics of
> the patch set working).
>
> My GPMC tree looks like this:-
>
> gpmc: gpmc@5000 {
> compatible = "ti,am3352-gpmc", "simple-bus";
> ti,hwmods = "gpmc";
> status = "okay";
> gpmc,num-waitpins = <2>;
> pinctrl-names = "default";
> pinctrl-0 = <&gpmc_pins>;
>
> #address-cells = <2>;
> #size-cells = <1>;
> ranges = <0 0 0x0800 0x1000>, /* CS0: NAND 256M */
><3 0 0x1a00 0x0400>; /* CS3: NOR 64M */
>
> nand@0,0 {
> linux,mtd-name= "micron,mt29f2g08abaea";
> reg = <0 0x 0x1000>; /* CS0, offset 0 */
> nand-bus-width = <8>;
> ti,nand-ecc-opt = "bch8";
>
> gpmc,device-nand;
> gpmc,device-width = <1>;
> gpmc,wait-pin = <0>;
>
> gpmc,sync-clk = <0>;
> gpmc,cs-on = <0>;
> gpmc,cs-rd-off = <44>;
> gpmc,cs-wr-off = <44>;
> gpmc,adv-on = <6>;
> gpmc,adv-rd-off = <34>;
> gpmc,adv-wr-off = <44>;
> gpmc,we-off = <40>;
> gpmc,oe-off = <54>;
> gpmc,access = <64>;
> gpmc,rd-cycle = <82>;
> gpmc,wr-cycle = <82>;
> gpmc,wr-access = <40>;
> gpmc,wr-data-mux-bus = <0>;
>
> #address-cells = <1>;
> #size-cells = <1>;
> elm_id = <&elm>;
>
> /*
> MTD partition table
> ===
> ++-->0x-> SPL start (SPL copy on
> 1st block)
> ||
> ||-->0x0001-> SPL end
> ||-->0x0002-> SPL.backup1 start (SPL copy on
> 2nd block)
> ||
> ||-->0x0003-> SPL.backup1 end
> ||-->0x0004-> SPL.backup2 start (SPL copy on
> 3rd block)
> ||
> ||-->0x0005-> SPL.backup2 end
> ||-->0x0006-> SPL.backup3 start (SPL copy on
> 4th block)
> ||
> ||-->0x0007-> SPL.backup3 end
> ||-->0x0008-> U-Boot start
> ||
> ||-->0x001D-> U-Boot end
> ||-->0x001E-> ENV start
> ||
> ||-->0x001F-> ENV end
> ||-->0x0020-> File system start
> ||
> ||-->0x041F-> File system end
> ||-->0x0420-> Data storage start
> ||
> ++-->0x1000-> NAND end (Free end)
> */
> partition@0 {
> label = "spl1";
> reg = <0x 0x0002>; /* 128KB */
> };
>
> partition@1 {
> label = "spl2";
> reg = <0x0002 0x0002>; /* 128KB */
> };
>
> partition@2 {
> label = "spl3";
> reg = <0x0004 0x0002>; /* 128KB */
> };
>
> partition@3 {
> label = "spl4";
> reg = <0x0006 0x0002>; /* 128KB */
> };
>
> partition@4 {
> label = "boot";
> reg = <0x0008 0x0016>; /* 1408KB */
> };
>
> partition@5 {
> label = "env";
> reg = <0x001e 0x0002>; /* 128KB */
> };
>
> partition@6 {
> label = "rootfs";
> reg = <0x0020 0x0400>; /* 64MB */
> };
>
> partition@7 {
> label = "data";
> reg = <0x0420 0x0be0>; /* 190MB */
> };
> };
>
> nor@1,0 {
> reg = <3 0x 0x0400>;
> compatible = "cfi-flash";
> linux,mtd-name = "spansion,s29gl
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 26/02/13 17:30, 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
I'm trying to test this series, and am unable get my NOR device recognised.
If I remove all reference to NOR (and keep only my NAND device definition), then
everything seems to boot fine (so I'm assuming I've got at least the basics of
the patch set working).
My GPMC tree looks like this:-
gpmc: gpmc@5000 {
compatible = "ti,am3352-gpmc", "simple-bus";
ti,hwmods = "gpmc";
status = "okay";
gpmc,num-waitpins = <2>;
pinctrl-names = "default";
pinctrl-0 = <&gpmc_pins>;
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x0800 0x1000>, /* CS0: NAND 256M */
<3 0 0x1a00 0x0400>; /* CS3: NOR 64M */
nand@0,0 {
linux,mtd-name= "micron,mt29f2g08abaea";
reg = <0 0x 0x1000>; /* CS0, offset 0 */
nand-bus-width = <8>;
ti,nand-ecc-opt = "bch8";
gpmc,device-nand;
gpmc,device-width = <1>;
gpmc,wait-pin = <0>;
gpmc,sync-clk = <0>;
gpmc,cs-on = <0>;
gpmc,cs-rd-off = <44>;
gpmc,cs-wr-off = <44>;
gpmc,adv-on = <6>;
gpmc,adv-rd-off = <34>;
gpmc,adv-wr-off = <44>;
gpmc,we-off = <40>;
gpmc,oe-off = <54>;
gpmc,access = <64>;
gpmc,rd-cycle = <82>;
gpmc,wr-cycle = <82>;
gpmc,wr-access = <40>;
gpmc,wr-data-mux-bus = <0>;
#address-cells = <1>;
#size-cells = <1>;
elm_id = <&elm>;
/*
MTD partition table
===
++-->0x-> SPL start (SPL copy on
1st block)
||
||-->0x0001-> SPL end
||-->0x0002-> SPL.backup1 start (SPL copy on
2nd block)
||
||-->0x0003-> SPL.backup1 end
||-->0x0004-> SPL.backup2 start (SPL copy on
3rd block)
||
||-->0x0005-> SPL.backup2 end
||-->0x0006-> SPL.backup3 start (SPL copy on
4th block)
||
||-->0x0007-> SPL.backup3 end
||-->0x0008-> U-Boot start
||
||-->0x001D-> U-Boot end
||-->0x001E-> ENV start
||
||-->0x001F-> ENV end
||-->0x0020-> File system start
||
||-->0x041F-> File system end
||-->0x0420-> Data storage start
||
++-->0x1000-> NAND end (Free end)
*/
partition@0 {
label = "spl1";
reg = <0x 0x0002>; /* 128KB */
};
partition@1 {
label = "spl2";
reg = <0x0002 0x0002>; /* 128KB */
};
partition@2 {
label = "spl3";
reg = <0x0004 0x0002>; /* 128KB */
};
partition@3 {
label = "spl4";
reg = <0x0006 0x0002>; /* 128KB */
};
partition@4 {
label = "boot";
reg = <0x0008 0x0016>; /* 1408KB */
};
partition@5 {
label = "env";
reg = <0x001e 0x0002>; /* 128KB */
};
partition@6 {
label = "rootfs";
reg = <0x0020 0x0400>; /* 64MB */
};
partition@7 {
label = "data";
reg = <0x0420 0x0be0>; /* 190MB */
};
};
nor@1,0 {
reg = <3 0x 0x0400>;
compatible = "cfi-flash";
linux,mtd-name = "spansion,s29gl064n90t";
bank-width = <2>;
gpmc,device-width = <1>;
gpmc,mux-
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 03/04/2013 11:51 AM, Jon Hunter wrote:
>
> On 03/04/2013 05:57 AM, Ezequiel Garcia wrote:
>> Hi Jon,
>>
>> On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter wrote:
>>> +
>>> +Example:
>>> +
>>> +gpmc: gpmc@6e00 {
>>> + compatible = "ti,omap3430-gpmc", "simple-bus";
>>
>> I'm concern about using simple-bus, and I'm not entirely sure this will work.
>>
>> AFAIK, you can't correlate a parent-child relationship in the device tree
>> to the order in which drivers will be probed,
>> so it's only a matter of coincidence if this is working for you right now.
>
> Ummm, I am not sure I am convinced. Have you looked at
> of_platform_bus_create() which creates the devices? It is clearly
> creating the child devices after creating the parent device.
Sorry you said order by which drivers are probed. Yes I would agree that
you cannot control the order drivers are probed, but just the order
devices are registered.
However, I don't see this as being a device-tree specific issue. Even
when not using device-tree you would need to ensure that probing the
parent happens before the child for the GPMC.
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 03/04/2013 05:57 AM, Ezequiel Garcia wrote:
> Hi Jon,
>
> On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter wrote:
>> +
>> +Example:
>> +
>> +gpmc: gpmc@6e00 {
>> + compatible = "ti,omap3430-gpmc", "simple-bus";
>
> I'm concern about using simple-bus, and I'm not entirely sure this will work.
>
> AFAIK, you can't correlate a parent-child relationship in the device tree
> to the order in which drivers will be probed,
> so it's only a matter of coincidence if this is working for you right now.
Ummm, I am not sure I am convinced. Have you looked at
of_platform_bus_create() which creates the devices? It is clearly
creating the child devices after creating the parent device.
> The GPMC code is in "arch/arm/mach-omap2", is located *before* the mtd code
> in the Makefile, and thus the GPMC driver loads *before* the MTD code.
But shouldn't it only matter in the order in which devices are
registered? Unless you have a situation in which the devices are
registered in order (parent then child) but only the driver for the
child is registered before the parent and child devices are registered.
I could see that being a problem.
The only other thing that I can think of is if you happen to be creating
a device both via device-tree and may be you are creating a duplicate
device and calling platform_device_register() somewhere else in your code.
> Morevore, I believe that when we move GPMC from arch/arm/mach-omap2
> to drivers/memory where it should be, this 'simple-bus' will stop
> working properly.
Why? I don't see how the location of files would change this.
> Of course, I can be wrong, but I think you will have to find some other way
> to initialize the GPMC's childs.
Well isn't this how device-tree is meant to work?
It would be great if you could debug your problem and fully understand
why this is not working for you, so we can see if there is a real
problem here. Otherwise this appears to be just guess work.
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
Hi Jon,
On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter wrote:
> +
> +Example:
> +
> +gpmc: gpmc@6e00 {
> + compatible = "ti,omap3430-gpmc", "simple-bus";
I'm concern about using simple-bus, and I'm not entirely sure this will work.
AFAIK, you can't correlate a parent-child relationship in the device tree
to the order in which drivers will be probed,
so it's only a matter of coincidence if this is working for you right now.
The GPMC code is in "arch/arm/mach-omap2", is located *before* the mtd code
in the Makefile, and thus the GPMC driver loads *before* the MTD code.
Morevore, I believe that when we move GPMC from arch/arm/mach-omap2
to drivers/memory where it should be, this 'simple-bus' will stop
working properly.
Of course, I can be wrong, but I think you will have to find some other way
to initialize the GPMC's childs.
--
Ezequiel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On 03/01/2013 03:25 PM, Ezequiel Garcia wrote:
> Hi Jon,
>
> On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter wrote:
> [...]
>> +static int gpmc_probe_nor_child(struct platform_device *pdev,
>> + struct device_node *child)
>> +{
>> + struct gpmc_settings gpmc_s;
>> + struct gpmc_timings gpmc_t;
>> + struct resource res;
>> + unsigned long base;
>> + int ret, cs;
>> +
>> + 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, res.end - res.start, &base);
>
> How about using resource_size() above?
>
> BTW, I believe it's size = end - start + 1.
Thanks, yes I can update.
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
Hi Jon,
On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter wrote:
[...]
> +static int gpmc_probe_nor_child(struct platform_device *pdev,
> + struct device_node *child)
> +{
> + struct gpmc_settings gpmc_s;
> + struct gpmc_timings gpmc_t;
> + struct resource res;
> + unsigned long base;
> + int ret, cs;
> +
> + 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, res.end - res.start, &base);
How about using resource_size() above?
BTW, I believe it's size = end - start + 1.
--
Ezequiel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
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 | 120
2 files changed, 218 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 e822d2b..eb167b3 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -513,6 +514,37 @@ static int gpmc_cs_delete_mem(int cs)
return r;
}
+/**
+ * gpmc_cs_remap - remaps a c
