Re: DT GPMC SRAM and NOR flash support ?
Hi Jon,
Yet more questions :-) See below...
On Wed, Feb 13, 2013 at 7:07 PM, Jon Hunter jon-hun...@ti.com wrote:
You don't need this extra entry if you add simple-bus to
the gpmc node compatible string.
+ gpmc: gpmc@6800a000 {
+ compatible = ti,omap2420-gpmc, simple-bus;
+ ti,hwmods = gpmc;
+ reg = 0x6800a000 0x1000;
+ interrupts = 20;
+
This simple-bus trick is great and very clean!
I'm working on a new driver, similar to gpmc, called device-bus for Marvell SoC.
One remarkable difference is that I need to *setup* the address space
(sort of allocate the address region) for a child device, before I can
access it.
Using simple-bus is a very clean solution. However I'm facing a strange issue:
the child (physmap driver) probe() is being called *before* the parent
(device-bus driver)
probe(), and so the flash device address space cannot get accessed because
it hasn't been setup yet.
Am I doing something wrong? Or is this the expected behavior?
In the latter case, I won't be able to use a compatible simple-bus
at all, right?
--
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: DT GPMC SRAM and NOR flash support ?
On Fri, Mar 1, 2013 at 6:08 PM, Ezequiel Garcia elezegar...@gmail.com wrote:
Hi Jon,
Yet more questions :-) See below...
On Wed, Feb 13, 2013 at 7:07 PM, Jon Hunter jon-hun...@ti.com wrote:
You don't need this extra entry if you add simple-bus to
the gpmc node compatible string.
+ gpmc: gpmc@6800a000 {
+ compatible = ti,omap2420-gpmc, simple-bus;
+ ti,hwmods = gpmc;
+ reg = 0x6800a000 0x1000;
+ interrupts = 20;
+
This simple-bus trick is great and very clean!
I'm working on a new driver, similar to gpmc, called device-bus for Marvell
SoC.
One remarkable difference is that I need to *setup* the address space
(sort of allocate the address region) for a child device, before I can
access it.
Using simple-bus is a very clean solution. However I'm facing a strange issue:
the child (physmap driver) probe() is being called *before* the parent
(device-bus driver)
probe(), and so the flash device address space cannot get accessed because
it hasn't been setup yet.
Ok, now I think I understand that my problem has nothing to do with simple-bus,
but instead related to the driver probing order.
The physmap driver is just being probed before the device bus driver, and so it
won't work.
Now: is there any clean solution?
--
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: DT GPMC SRAM and NOR flash support ?
On 03/01/2013 03:42 PM, Ezequiel Garcia wrote:
On Fri, Mar 1, 2013 at 6:08 PM, Ezequiel Garcia elezegar...@gmail.com wrote:
Hi Jon,
Yet more questions :-) See below...
On Wed, Feb 13, 2013 at 7:07 PM, Jon Hunter jon-hun...@ti.com wrote:
You don't need this extra entry if you add simple-bus to
the gpmc node compatible string.
+ gpmc: gpmc@6800a000 {
+ compatible = ti,omap2420-gpmc, simple-bus;
+ ti,hwmods = gpmc;
+ reg = 0x6800a000 0x1000;
+ interrupts = 20;
+
This simple-bus trick is great and very clean!
I'm working on a new driver, similar to gpmc, called device-bus for Marvell
SoC.
One remarkable difference is that I need to *setup* the address space
(sort of allocate the address region) for a child device, before I can
access it.
Using simple-bus is a very clean solution. However I'm facing a strange
issue:
the child (physmap driver) probe() is being called *before* the parent
(device-bus driver)
probe(), and so the flash device address space cannot get accessed because
it hasn't been setup yet.
Ok, now I think I understand that my problem has nothing to do with
simple-bus,
but instead related to the driver probing order.
The physmap driver is just being probed before the device bus driver, and so
it
won't work.
Now: is there any clean solution?
I can't say I understand why if it is a child device. I have just posted
a series this week to enable NOR support for OMAP with DT [1].
Cheers
Jon
[1] http://permalink.gmane.org/gmane.linux.ports.arm.omap/94378
--
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: DT GPMC SRAM and NOR flash support ?
Hi Jon,
I'm working on a similar memory controller for plat-orion.
I have a few questions about your approach.
On Wed, Feb 13, 2013 at 03:07:06PM -0600, Jon Hunter wrote:
On 02/07/2013 03:51 AM, Mark Jackson wrote:
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (gpmc_probe_dt(), etc) so it now
handles setting up the
chip selects and timings for NOR devices, e.g.
gpmc: gpmc@5000 {
status = okay;
ranges = 0 0 0x0800 0x0800; /* CS0: NOR 16M
*/
Is that really 16M? Looks more like 128M :-)
nor@0,0 {
compatible = spansion,s29gl064n90t,
cfi-flash;
reg = 0 0 0;
I think that cfi-flash is expecting a length here. Here is
what I have ...
+gpmc {
+ ranges = 0 0 0x0800 0x0400;
+
+ nor@0,0 {
+ compatible = cfi-flash;
+ linux,mtd-name= intel,ge28f256l18b85;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0 0 0x0400;
+ bank-width = 2;
+
+ partition@0 {
+ label = bootloader;
+ reg = 0 0x2;
+ };
+ partition@0x2 {
+ label = params;
+ reg = 0x2 0x2;
+ };
+ partition@0x4 {
+ label = kernel;
+ reg = 0x4 0x20;
+ };
+ partition@0x24 {
+ label = file-system;
+ reg = 0x24 0x3dc;
+ };
+ };
nor-flash@0800 {
compatible = spansion,s29gl064n90t, cfi-flash;
reg = 0x0800 0x0080;
bank-width = 2;
};
You don't need this extra entry if you add simple-bus to
the gpmc node compatible string.
That would be nice. However, I wonder what happens if cfi-flash probing
fails: will the gpmc cs request by undone? See below...
+ gpmc: gpmc@6800a000 {
+ compatible = ti,omap2420-gpmc, simple-bus;
+ ti,hwmods = gpmc;
+ reg = 0x6800a000 0x1000;
+ interrupts = 20;
+
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+ };
Currently I have the following and this is working for me.
Please note that on my board the bootloader is configuring
the timings for me and so this is missing from the below
implementation and still needs to be added.
Cheers
Jon
From c0ede833fad704ab452b116154177e3a59166c7e Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Fri, 8 Feb 2013 16:46:13 -0600
Subject: [PATCH] ARM: OMAP2+: Add device-tree support for NOR flash
---
arch/arm/mach-omap2/gpmc.c | 69
1 file changed, 69 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index bc90155..421320b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -26,6 +26,7 @@
#include linux/interrupt.h
#include linux/platform_device.h
#include linux/of.h
+#include linux/of_address.h
#include linux/of_mtd.h
#include linux/of_device.h
#include linux/mtd/nand.h
@@ -517,6 +518,26 @@ static int gpmc_cs_delete_mem(int cs)
return r;
}
+static int gpmc_cs_remap(int cs, u32 base)
+{
+ int r;
+ u32 old_base, size;
+
+ gpmc_cs_get_memconf(cs, old_base, size);
+ if (base == old_base)
+ return 0;
+ gpmc_cs_disable_mem(cs);
+ r = gpmc_cs_delete_mem(cs);
+ if (IS_ERR_VALUE(r))
+ return r;
+ r = gpmc_cs_insert_mem(cs, base, size);
+ if (IS_ERR_VALUE(r))
+ return r;
+ gpmc_cs_enable_mem(cs, base, size);
+
+ return 0;
+}
+
int gpmc_cs_request(int cs, unsigned long size, unsigned long *base)
{
struct resource *res = gpmc_cs_mem[cs];
@@ -1305,6 +1326,45 @@ static int gpmc_probe_onenand_child(struct
platform_device *pdev,
}
#endif
+static int gpmc_probe_nor_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ struct resource res;
+ unsigned long base;
+ int rc, 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;
Re: DT GPMC SRAM and NOR flash support ?
On 02/14/2013 04:18 AM, Ezequiel Garcia wrote:
Hi Jon,
I'm working on a similar memory controller for plat-orion.
I have a few questions about your approach.
On Wed, Feb 13, 2013 at 03:07:06PM -0600, Jon Hunter wrote:
On 02/07/2013 03:51 AM, Mark Jackson wrote:
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (gpmc_probe_dt(), etc) so it now
handles setting up the
chip selects and timings for NOR devices, e.g.
gpmc: gpmc@5000 {
status = okay;
ranges = 0 0 0x0800 0x0800; /* CS0: NOR 16M
*/
Is that really 16M? Looks more like 128M :-)
nor@0,0 {
compatible = spansion,s29gl064n90t,
cfi-flash;
reg = 0 0 0;
I think that cfi-flash is expecting a length here. Here is
what I have ...
+gpmc {
+ ranges = 0 0 0x0800 0x0400;
+
+ nor@0,0 {
+ compatible = cfi-flash;
+ linux,mtd-name= intel,ge28f256l18b85;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0 0 0x0400;
+ bank-width = 2;
+
+ partition@0 {
+ label = bootloader;
+ reg = 0 0x2;
+ };
+ partition@0x2 {
+ label = params;
+ reg = 0x2 0x2;
+ };
+ partition@0x4 {
+ label = kernel;
+ reg = 0x4 0x20;
+ };
+ partition@0x24 {
+ label = file-system;
+ reg = 0x24 0x3dc;
+ };
+ };
nor-flash@0800 {
compatible = spansion,s29gl064n90t, cfi-flash;
reg = 0x0800 0x0080;
bank-width = 2;
};
You don't need this extra entry if you add simple-bus to
the gpmc node compatible string.
That would be nice. However, I wonder what happens if cfi-flash probing
fails: will the gpmc cs request by undone? See below...
+ gpmc: gpmc@6800a000 {
+ compatible = ti,omap2420-gpmc, simple-bus;
+ ti,hwmods = gpmc;
+ reg = 0x6800a000 0x1000;
+ interrupts = 20;
+
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+ };
Currently I have the following and this is working for me.
Please note that on my board the bootloader is configuring
the timings for me and so this is missing from the below
implementation and still needs to be added.
Cheers
Jon
From c0ede833fad704ab452b116154177e3a59166c7e Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Fri, 8 Feb 2013 16:46:13 -0600
Subject: [PATCH] ARM: OMAP2+: Add device-tree support for NOR flash
---
arch/arm/mach-omap2/gpmc.c | 69
1 file changed, 69 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index bc90155..421320b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -26,6 +26,7 @@
#include linux/interrupt.h
#include linux/platform_device.h
#include linux/of.h
+#include linux/of_address.h
#include linux/of_mtd.h
#include linux/of_device.h
#include linux/mtd/nand.h
@@ -517,6 +518,26 @@ static int gpmc_cs_delete_mem(int cs)
return r;
}
+static int gpmc_cs_remap(int cs, u32 base)
+{
+int r;
+u32 old_base, size;
+
+gpmc_cs_get_memconf(cs, old_base, size);
+if (base == old_base)
+return 0;
+gpmc_cs_disable_mem(cs);
+r = gpmc_cs_delete_mem(cs);
+if (IS_ERR_VALUE(r))
+return r;
+r = gpmc_cs_insert_mem(cs, base, size);
+if (IS_ERR_VALUE(r))
+return r;
+gpmc_cs_enable_mem(cs, base, size);
+
+return 0;
+}
+
int gpmc_cs_request(int cs, unsigned long size, unsigned long *base)
{
struct resource *res = gpmc_cs_mem[cs];
@@ -1305,6 +1326,45 @@ static int gpmc_probe_onenand_child(struct
platform_device *pdev,
}
#endif
+static int gpmc_probe_nor_child(struct platform_device *pdev,si
+struct device_node *child)
+{
+struct resource res;
+unsigned long base;
+int rc, 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;
+
Re: DT GPMC SRAM and NOR flash support ?
On 02/07/2013 03:51 AM, Mark Jackson wrote:
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (gpmc_probe_dt(), etc) so it now
handles setting up the
chip selects and timings for NOR devices, e.g.
gpmc: gpmc@5000 {
status = okay;
ranges = 0 0 0x0800 0x0800; /* CS0: NOR 16M
*/
Is that really 16M? Looks more like 128M :-)
nor@0,0 {
compatible = spansion,s29gl064n90t,
cfi-flash;
reg = 0 0 0;
I think that cfi-flash is expecting a length here. Here is
what I have ...
+gpmc {
+ ranges = 0 0 0x0800 0x0400;
+
+ nor@0,0 {
+ compatible = cfi-flash;
+ linux,mtd-name= intel,ge28f256l18b85;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0 0 0x0400;
+ bank-width = 2;
+
+ partition@0 {
+ label = bootloader;
+ reg = 0 0x2;
+ };
+ partition@0x2 {
+ label = params;
+ reg = 0x2 0x2;
+ };
+ partition@0x4 {
+ label = kernel;
+ reg = 0x4 0x20;
+ };
+ partition@0x24 {
+ label = file-system;
+ reg = 0x24 0x3dc;
+ };
+ };
nor-flash@0800 {
compatible = spansion,s29gl064n90t, cfi-flash;
reg = 0x0800 0x0080;
bank-width = 2;
};
You don't need this extra entry if you add simple-bus to
the gpmc node compatible string.
+ gpmc: gpmc@6800a000 {
+ compatible = ti,omap2420-gpmc, simple-bus;
+ ti,hwmods = gpmc;
+ reg = 0x6800a000 0x1000;
+ interrupts = 20;
+
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+ };
Currently I have the following and this is working for me.
Please note that on my board the bootloader is configuring
the timings for me and so this is missing from the below
implementation and still needs to be added.
Cheers
Jon
From c0ede833fad704ab452b116154177e3a59166c7e Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Fri, 8 Feb 2013 16:46:13 -0600
Subject: [PATCH] ARM: OMAP2+: Add device-tree support for NOR flash
---
arch/arm/mach-omap2/gpmc.c | 69
1 file changed, 69 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index bc90155..421320b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -26,6 +26,7 @@
#include linux/interrupt.h
#include linux/platform_device.h
#include linux/of.h
+#include linux/of_address.h
#include linux/of_mtd.h
#include linux/of_device.h
#include linux/mtd/nand.h
@@ -517,6 +518,26 @@ static int gpmc_cs_delete_mem(int cs)
return r;
}
+static int gpmc_cs_remap(int cs, u32 base)
+{
+ int r;
+ u32 old_base, size;
+
+ gpmc_cs_get_memconf(cs, old_base, size);
+ if (base == old_base)
+ return 0;
+ gpmc_cs_disable_mem(cs);
+ r = gpmc_cs_delete_mem(cs);
+ if (IS_ERR_VALUE(r))
+ return r;
+ r = gpmc_cs_insert_mem(cs, base, size);
+ if (IS_ERR_VALUE(r))
+ return r;
+ gpmc_cs_enable_mem(cs, base, size);
+
+ return 0;
+}
+
int gpmc_cs_request(int cs, unsigned long size, unsigned long *base)
{
struct resource *res = gpmc_cs_mem[cs];
@@ -1305,6 +1326,45 @@ static int gpmc_probe_onenand_child(struct
platform_device *pdev,
}
#endif
+static int gpmc_probe_nor_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ struct resource res;
+ unsigned long base;
+ int rc, 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;
+ }
+
+ rc = gpmc_cs_request(cs, res.end - res.start, base);
+ if (rc 0)
+ pr_err(%s: cannot request GPMC CS %d\n, __func__, cs);
+
+ /*
+* gpmc_cs_request() will map the CS to an arbitary location
+* in the gpmc address space. When booting with device-tree we
+* want the NOR flash to be mapped to the location
Re: DT GPMC SRAM and NOR flash support ?
Hi Jon On Mon, Feb 11, 2013 at 7:21 PM, Jon Hunter jon-hun...@ti.com wrote: This is being call from the mach-omap2/board-generic.c file on boot. Where are you suggesting this is called from? I was suggesting this could be called in gpmc_probe_dt() in gpmc.c. Instead of using for_each_node_by_name() and initialize manually each node, it should be possibly (perhaps with some ugly hack) to use of_platform_populate() to initialize gpmc child devices. But I'm not exactly sure how this would work. -- 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: DT GPMC SRAM and NOR flash support ?
On 02/09/2013 07:27 AM, Ezequiel Garcia wrote:
Hi Mark,
On Thu, Feb 7, 2013 at 6:51 AM, Mark Jackson mpfj-l...@mimc.co.uk wrote:
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (gpmc_probe_dt(), etc) so it now
handles setting up the
chip selects and timings for NOR devices, e.g.
gpmc: gpmc@5000 {
status = okay;
ranges = 0 0 0x0800 0x0800; /* CS0: NOR
16M */
nor@0,0 {
compatible = spansion,s29gl064n90t,
cfi-flash;
reg = 0 0 0;
bank-width = 2;
gpmc,sync-clk = 0;
gpmc,cs-on = 10;
gpmc,cs-rd-off = 150;
gpmc,cs-wr-off = 150;
gpmc,adv-on = 10;
gpmc,adv-rd-off = 10;
gpmc,adv-wr-off = 10;
gpmc,oe-on = 30;
gpmc,oe-off = 150;
gpmc,we-on = 30;
gpmc,we-off = 150;
gpmc,rd-cycle = 150;
gpmc,wr-cycle = 150;
gpmc,access = 130;
gpmc,page-burst-access = 10;
gpmc,cycle2cycle-diff = 1;
gpmc,cycle2cycle-same = 1;
gpmc,cycle2cycle-delay = 10;
gpmc,wr-data-mux-bus = 60;
};
};
But the physmap driver (of_flash_probe()) is unable to use this information.
It seems that although
I can call of_flash_probe() from my NOR setup code, the platform_device
being reference is wrong.
By the way, you shouldn't be calling of_flash_probe directly. If we
register the device correctly this should be called for us. See below on
how to fix the registering of the device.
The platform_device passed to my gpmc_probe_nor_child() routine from
gpmc_probe_dt() points to my
gpmc entry (above), but the physmap probe requires its own DT entry (rather
than a node child such
as my NOR entry with the GPMC device entry).
I think you can call something like:
of_platform_populate();
This is being call from the mach-omap2/board-generic.c file on boot.
Where are you suggesting this is called from?
On your GPMC node and have the child initialize.
This way you don't need to have separate cfi-flash compatible nodes,
you can have them as childs.
Although I'm not sure this is a sane approach, I'm almost sure this should
work.
From looking at the DT code and playing around with my omap2 board, if
we add simple-bus to the compatible string for the gpmc controller,
then DT will register the cfi-flash device as implemented above and you
don't need the extra node. For example ...
gpmc: gpmc@6800a000 {
- compatible = ti,omap2420-gpmc;
+ compatible = ti,omap2420-gpmc, simple-bus;
ti,hwmods = gpmc;
reg = 0x6800a000 0x1000;
interrupts = 20;
I am also concerned about how gpmc_cs_request() is implemented when we
are booting with device-tree. This function is mapping the CS where ever
it has space available and is not looking at the DTS to see where you
want the flash to be. So this needs to be addressed too.
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: DT GPMC SRAM and NOR flash support ?
Hi Mark,
On Thu, Feb 7, 2013 at 6:51 AM, Mark Jackson mpfj-l...@mimc.co.uk wrote:
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (gpmc_probe_dt(), etc) so it now
handles setting up the
chip selects and timings for NOR devices, e.g.
gpmc: gpmc@5000 {
status = okay;
ranges = 0 0 0x0800 0x0800; /* CS0: NOR
16M */
nor@0,0 {
compatible = spansion,s29gl064n90t,
cfi-flash;
reg = 0 0 0;
bank-width = 2;
gpmc,sync-clk = 0;
gpmc,cs-on = 10;
gpmc,cs-rd-off = 150;
gpmc,cs-wr-off = 150;
gpmc,adv-on = 10;
gpmc,adv-rd-off = 10;
gpmc,adv-wr-off = 10;
gpmc,oe-on = 30;
gpmc,oe-off = 150;
gpmc,we-on = 30;
gpmc,we-off = 150;
gpmc,rd-cycle = 150;
gpmc,wr-cycle = 150;
gpmc,access = 130;
gpmc,page-burst-access = 10;
gpmc,cycle2cycle-diff = 1;
gpmc,cycle2cycle-same = 1;
gpmc,cycle2cycle-delay = 10;
gpmc,wr-data-mux-bus = 60;
};
};
But the physmap driver (of_flash_probe()) is unable to use this information.
It seems that although
I can call of_flash_probe() from my NOR setup code, the platform_device being
reference is wrong.
The platform_device passed to my gpmc_probe_nor_child() routine from
gpmc_probe_dt() points to my
gpmc entry (above), but the physmap probe requires its own DT entry (rather
than a node child such
as my NOR entry with the GPMC device entry).
I think you can call something like:
of_platform_populate();
On your GPMC node and have the child initialize.
This way you don't need to have separate cfi-flash compatible nodes,
you can have them as childs.
Although I'm not sure this is a sane approach, I'm almost sure this should work.
--
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: DT GPMC SRAM and NOR flash support ?
On 02/07/2013 03:51 AM, Mark Jackson wrote:
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (gpmc_probe_dt(), etc) so it now
handles setting up the
chip selects and timings for NOR devices, e.g.
gpmc: gpmc@5000 {
status = okay;
ranges = 0 0 0x0800 0x0800; /* CS0: NOR 16M
*/
nor@0,0 {
compatible = spansion,s29gl064n90t,
cfi-flash;
reg = 0 0 0;
bank-width = 2;
gpmc,sync-clk = 0;
gpmc,cs-on = 10;
gpmc,cs-rd-off = 150;
gpmc,cs-wr-off = 150;
gpmc,adv-on = 10;
gpmc,adv-rd-off = 10;
gpmc,adv-wr-off = 10;
gpmc,oe-on = 30;
gpmc,oe-off = 150;
gpmc,we-on = 30;
gpmc,we-off = 150;
gpmc,rd-cycle = 150;
gpmc,wr-cycle = 150;
gpmc,access = 130;
gpmc,page-burst-access = 10;
gpmc,cycle2cycle-diff = 1;
gpmc,cycle2cycle-same = 1;
gpmc,cycle2cycle-delay = 10;
gpmc,wr-data-mux-bus = 60;
};
};
But the physmap driver (of_flash_probe()) is unable to use this information.
It seems that although
I can call of_flash_probe() from my NOR setup code, the platform_device being
reference is wrong.
The platform_device passed to my gpmc_probe_nor_child() routine from
gpmc_probe_dt() points to my
gpmc entry (above), but the physmap probe requires its own DT entry (rather
than a node child such
as my NOR entry with the GPMC device entry).
So I need to have any extra entry in the DT file as follows:-
nor-flash@0800 {
compatible = spansion,s29gl064n90t, cfi-flash;
reg = 0x0800 0x0080;
bank-width = 2;
};
So the GPMC entry handles all the chip select and timing setup, but the 2nd
entry is the only one
the physmap driver can see.
Would it be acceptable to re-code of_flash_probe() to allow either a child
device_node to be passed
or a platform_device ?
Ideally, it should be a child device of the gpmc so that if the gpmc
device fails to init correctly, the child is not registered.
I need to think about this some more to figure out the best way to
handle nor.
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: DT GPMC SRAM and NOR flash support ?
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (gpmc_probe_dt(), etc) so it now
handles setting up the
chip selects and timings for NOR devices, e.g.
gpmc: gpmc@5000 {
status = okay;
ranges = 0 0 0x0800 0x0800; /* CS0: NOR 16M
*/
nor@0,0 {
compatible = spansion,s29gl064n90t,
cfi-flash;
reg = 0 0 0;
bank-width = 2;
gpmc,sync-clk = 0;
gpmc,cs-on = 10;
gpmc,cs-rd-off = 150;
gpmc,cs-wr-off = 150;
gpmc,adv-on = 10;
gpmc,adv-rd-off = 10;
gpmc,adv-wr-off = 10;
gpmc,oe-on = 30;
gpmc,oe-off = 150;
gpmc,we-on = 30;
gpmc,we-off = 150;
gpmc,rd-cycle = 150;
gpmc,wr-cycle = 150;
gpmc,access = 130;
gpmc,page-burst-access = 10;
gpmc,cycle2cycle-diff = 1;
gpmc,cycle2cycle-same = 1;
gpmc,cycle2cycle-delay = 10;
gpmc,wr-data-mux-bus = 60;
};
};
But the physmap driver (of_flash_probe()) is unable to use this information.
It seems that although
I can call of_flash_probe() from my NOR setup code, the platform_device being
reference is wrong.
The platform_device passed to my gpmc_probe_nor_child() routine from
gpmc_probe_dt() points to my
gpmc entry (above), but the physmap probe requires its own DT entry (rather
than a node child such
as my NOR entry with the GPMC device entry).
So I need to have any extra entry in the DT file as follows:-
nor-flash@0800 {
compatible = spansion,s29gl064n90t, cfi-flash;
reg = 0x0800 0x0080;
bank-width = 2;
};
So the GPMC entry handles all the chip select and timing setup, but the 2nd
entry is the only one
the physmap driver can see.
Would it be acceptable to re-code of_flash_probe() to allow either a child
device_node to be passed
or a platform_device ?
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: DT GPMC SRAM and NOR flash support ?
On 07/02/13 09:51, Mark Jackson wrote:
Okay ... I have made some progress, but it's not ideal.
snip
But the physmap driver (of_flash_probe()) is unable to use this information.
It seems that although
I can call of_flash_probe() from my NOR setup code, the platform_device being
reference is wrong.
The platform_device passed to my gpmc_probe_nor_child() routine from
gpmc_probe_dt() points to my
gpmc entry (above), but the physmap probe requires its own DT entry (rather
than a node child such
as my NOR entry with the GPMC device entry).
So I need to have any extra entry in the DT file as follows:-
nor-flash@0800 {
compatible = spansion,s29gl064n90t, cfi-flash;
reg = 0x0800 0x0080;
bank-width = 2;
};
So the GPMC entry handles all the chip select and timing setup, but the 2nd
entry is the only one
the physmap driver can see.
Would it be acceptable to re-code of_flash_probe() to allow either a child
device_node to be passed
or a platform_device ?
Or is it acceptable to simply state the gpmc portion is for setting up the chip
access, and you *do*
need a separate physmap section ?
That's certainly easier, and it works without any changes to the physmap driver.
Regards
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: DT GPMC SRAM and NOR flash support ?
On 01/02/13 19:39, Mark Jackson wrote: On 01/02/13 17:12, Jon Hunter wrote: Hi Mark, On 02/01/2013 10:56 AM, Mark Jackson wrote: There's plenty of DT support going in for NAND flash, but is there any work going on to support NOR flash ? What board and device are you working that is using NOR? I have a OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but I don't spend much time on it. Eventually it will have to be done but it is always good to know if there is a pressing need. We have a custom AM335x CPU board (arriving on my desk within the next few weeks) that has both NAND and NOR Flash. And how about SRAM chips or other memory mapped devices ? Not sure about SRAM (trying to think if I have a board with SRAM even), but definitely, boards using the GPMC to interface to ethernet chips need to be added. The board also contains an FRAM chip (which is just treated as SRAM). If you'd anything in the pipeline, I'm glad to help in any testing. I've created a custom cape board for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not waiting for the new hardware to arrive. I've experimented with trying to add a mtd-physmap device, but no joy. I'm guessing that the current mtd-physmap code is (in some way) currently incompatible with the GPMC device ? 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: DT GPMC SRAM and NOR flash support ?
On 02/05/2013 10:16 AM, Mark Jackson wrote: On 01/02/13 19:39, Mark Jackson wrote: On 01/02/13 17:12, Jon Hunter wrote: Hi Mark, On 02/01/2013 10:56 AM, Mark Jackson wrote: There's plenty of DT support going in for NAND flash, but is there any work going on to support NOR flash ? What board and device are you working that is using NOR? I have a OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but I don't spend much time on it. Eventually it will have to be done but it is always good to know if there is a pressing need. We have a custom AM335x CPU board (arriving on my desk within the next few weeks) that has both NAND and NOR Flash. And how about SRAM chips or other memory mapped devices ? Not sure about SRAM (trying to think if I have a board with SRAM even), but definitely, boards using the GPMC to interface to ethernet chips need to be added. The board also contains an FRAM chip (which is just treated as SRAM). If you'd anything in the pipeline, I'm glad to help in any testing. I've created a custom cape board for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not waiting for the new hardware to arrive. Sorry for the delay. I personally don't have anything in the pipe. Afzal, do you know of anyone looking at this? I've experimented with trying to add a mtd-physmap device, but no joy. I'm guessing that the current mtd-physmap code is (in some way) currently incompatible with the GPMC device ? I am not familiar with mtd-physmap to comment. Is that DT specific? 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: DT GPMC SRAM and NOR flash support ?
On 05/02/13 16:35, Jon Hunter wrote:
On 02/05/2013 10:16 AM, Mark Jackson wrote:
On 01/02/13 19:39, Mark Jackson wrote:
On 01/02/13 17:12, Jon Hunter wrote:
Hi Mark,
On 02/01/2013 10:56 AM, Mark Jackson wrote:
There's plenty of DT support going in for NAND flash, but is there any
work going on to support NOR
flash ?
What board and device are you working that is using NOR? I have a
OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but
I don't spend much time on it. Eventually it will have to be done but it
is always good to know if there is a pressing need.
We have a custom AM335x CPU board (arriving on my desk within the next few
weeks) that has both NAND
and NOR Flash.
And how about SRAM chips or other memory mapped devices ?
Not sure about SRAM (trying to think if I have a board with SRAM even),
but definitely, boards using the GPMC to interface to ethernet chips
need to be added.
The board also contains an FRAM chip (which is just treated as SRAM).
If you'd anything in the pipeline, I'm glad to help in any testing. I've
created a custom cape board
for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not
waiting for the new
hardware to arrive.
Sorry for the delay. I personally don't have anything in the pipe.
Afzal, do you know of anyone looking at this?
I've experimented with trying to add a mtd-physmap device, but no joy.
I'm guessing that the current mtd-physmap code is (in some way) currently
incompatible with the GPMC
device ?
I am not familiar with mtd-physmap to comment. Is that DT specific?
Well, it's documented in Documentation/devicetree/bindings/mtd/mtd-physmap.txt,
showing you can
specify cfi-flash or mtd-ram devices, eg (taken from mtd-physmap.txt):-
flash@ff00 {
compatible = amd,am29lv128ml, cfi-flash;
reg = ff00 0100;
bank-width = 4;
device-width = 1;
#address-cells = 1;
#size-cells = 1;
fs@0 {
label = fs;
reg = 0 f8;
};
firmware@f8 {
label =firmware;
reg = f8 8;
read-only;
};
};
sram@2,0 {
compatible = samsung,k6f1616u6a, mtd-ram;
reg = 2 0 0x0020;
bank-width = 2;
};
But I guess the GPMC needs to be configured to enable chip selects, data
widths, etc.
I did get *something* on the address / data bus by adding the patches below,
but I'm getting bus
contention, so something else needs setting up in the GPMC.
I'm no great device driver writer, but if anyone can give me some pointers, I'm
happy to keep digging.
Cheers
Mark J.
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index a37e1c9..8f45d18 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1265,10 +1265,13 @@ static int gpmc_probe_dt(struct platform_device *pdev)
struct device_node *child;
const struct of_device_id *of_id =
of_match_device(gpmc_dt_ids, pdev-dev);
+ unsigned long base;
if (!of_id)
return 0;
+ gpmc_cs_request(0, SZ_16M, base);
+
for_each_node_by_name(child, nand) {
ret = gpmc_probe_nand_child(pdev, child);
of_node_put(child);
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..ad89446 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -26,7 +26,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = user_leds_s0;
+ pinctrl-0 = user_leds_s0 gpmc_pins_s0;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins =
@@ -36,6 +36,49 @@
0x60 0x17 /* gpmc_a8.gpio1_24,
OUTPUT_PULLUP | MODE7 */
;
};
+
+ gpmc_pins_s0: gpmc_pins_s0 {
+ pinctrl-single,pins =
+ 0x0 0x30/* gpmc_ad0.gpmc_ad0, INPUT |
PULLUP | MODE0 */
+ 0x4 0x30/* gpmc_ad1.gpmc_ad1, INPUT |
PULLUP | MODE0 */
+ 0x8 0x30/* gpmc_ad2.gpmc_ad2, INPUT |
PULLUP | MODE0 */
+ 0xc 0x30/* gpmc_ad3.gpmc_ad3, INPUT |
PULLUP | MODE0 */
+ 0x10 0x30 /* gpmc_ad4.gpmc_ad4, INPUT |
PULLUP | MODE0 */
+ 0x14 0x30 /* gpmc_ad5.gpmc_ad5, INPUT |
PULLUP | MODE0 */
+ 0x18 0x30 /* gpmc_ad6.gpmc_ad6, INPUT |
PULLUP | MODE0 */
+ 0x1c 0x30 /*
Re: DT GPMC SRAM and NOR flash support ?
On 02/05/2013 10:48 AM, Mark Jackson wrote:
On 05/02/13 16:35, Jon Hunter wrote:
On 02/05/2013 10:16 AM, Mark Jackson wrote:
On 01/02/13 19:39, Mark Jackson wrote:
On 01/02/13 17:12, Jon Hunter wrote:
Hi Mark,
On 02/01/2013 10:56 AM, Mark Jackson wrote:
There's plenty of DT support going in for NAND flash, but is there any
work going on to support NOR
flash ?
What board and device are you working that is using NOR? I have a
OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but
I don't spend much time on it. Eventually it will have to be done but it
is always good to know if there is a pressing need.
We have a custom AM335x CPU board (arriving on my desk within the next few
weeks) that has both NAND
and NOR Flash.
And how about SRAM chips or other memory mapped devices ?
Not sure about SRAM (trying to think if I have a board with SRAM even),
but definitely, boards using the GPMC to interface to ethernet chips
need to be added.
The board also contains an FRAM chip (which is just treated as SRAM).
If you'd anything in the pipeline, I'm glad to help in any testing. I've
created a custom cape board
for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not
waiting for the new
hardware to arrive.
Sorry for the delay. I personally don't have anything in the pipe.
Afzal, do you know of anyone looking at this?
I've experimented with trying to add a mtd-physmap device, but no joy.
I'm guessing that the current mtd-physmap code is (in some way) currently
incompatible with the GPMC
device ?
I am not familiar with mtd-physmap to comment. Is that DT specific?
Well, it's documented in
Documentation/devicetree/bindings/mtd/mtd-physmap.txt, showing you can
specify cfi-flash or mtd-ram devices, eg (taken from mtd-physmap.txt):-
flash@ff00 {
compatible = amd,am29lv128ml, cfi-flash;
reg = ff00 0100;
bank-width = 4;
device-width = 1;
#address-cells = 1;
#size-cells = 1;
fs@0 {
label = fs;
reg = 0 f8;
};
firmware@f8 {
label =firmware;
reg = f8 8;
read-only;
};
};
sram@2,0 {
compatible = samsung,k6f1616u6a, mtd-ram;
reg = 2 0 0x0020;
bank-width = 2;
};
Ok, I see that the NOR flash on my omap2420 H4 is named physmap-flash
(I have not ported to DT yet). So the GPMC should work with it.
But I guess the GPMC needs to be configured to enable chip selects, data
widths, etc.
Exactly.
I did get *something* on the address / data bus by adding the patches below,
but I'm getting bus
contention, so something else needs setting up in the GPMC.
I'm no great device driver writer, but if anyone can give me some pointers,
I'm happy to keep digging.
Cheers
Mark J.
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index a37e1c9..8f45d18 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1265,10 +1265,13 @@ static int gpmc_probe_dt(struct platform_device *pdev)
struct device_node *child;
const struct of_device_id *of_id =
of_match_device(gpmc_dt_ids, pdev-dev);
+ unsigned long base;
if (!of_id)
return 0;
+ gpmc_cs_request(0, SZ_16M, base);
+
You should check what gpmc_cs_request returns.
Where are the NOR flash timings setup? Or are they already configured by
the bootloader? If so then that is probably ok for now.
for_each_node_by_name(child, nand) {
ret = gpmc_probe_nand_child(pdev, child);
of_node_put(child);
If you look at the gpmc_probe_nand_child(), this function is setting up
the NAND timings for the GPMC.
Ideally, we would have a similar function for nor (ie.
gpmc_probe_nor_child()), that would read the NOR information
(chip-select, size, timings, etc) from DT. However, I understand that
the above is just for test purposes.
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: DT GPMC SRAM and NOR flash support ?
Hi Jon, On Tue, Feb 05, 2013 at 22:05:20, Hunter, Jon wrote: On 02/05/2013 10:16 AM, Mark Jackson wrote: There's plenty of DT support going in for NAND flash, but is there any work going on to support NOR flash ? If you'd anything in the pipeline, I'm glad to help in any testing. I've created a custom cape board for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not waiting for the new hardware to arrive. Sorry for the delay. I personally don't have anything in the pipe. Afzal, do you know of anyone looking at this? I am not aware of anyone working on it. Regards Afzal
Re: DT GPMC SRAM and NOR flash support ?
Hi Mark, On 02/01/2013 10:56 AM, Mark Jackson wrote: There's plenty of DT support going in for NAND flash, but is there any work going on to support NOR flash ? What board and device are you working that is using NOR? I have a OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but I don't spend much time on it. Eventually it will have to be done but it is always good to know if there is a pressing need. And how about SRAM chips or other memory mapped devices ? Not sure about SRAM (trying to think if I have a board with SRAM even), but definitely, boards using the GPMC to interface to ethernet chips need to be added. 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: DT GPMC SRAM and NOR flash support ?
On 01/02/13 17:12, Jon Hunter wrote: Hi Mark, On 02/01/2013 10:56 AM, Mark Jackson wrote: There's plenty of DT support going in for NAND flash, but is there any work going on to support NOR flash ? What board and device are you working that is using NOR? I have a OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but I don't spend much time on it. Eventually it will have to be done but it is always good to know if there is a pressing need. We have a custom AM335x CPU board (arriving on my desk within the next few weeks) that has both NAND and NOR Flash. And how about SRAM chips or other memory mapped devices ? Not sure about SRAM (trying to think if I have a board with SRAM even), but definitely, boards using the GPMC to interface to ethernet chips need to be added. The board also contains an FRAM chip (which is just treated as SRAM). If you'd anything in the pipeline, I'm glad to help in any testing. I've created a custom cape board for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not waiting for the new hardware to arrive. 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
