Re: [PATCH v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
Hi Pekon,
On 05/16/2014 02:03 PM, Pekon Gupta wrote:
Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
am437x-gp-evm board.
(1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
eMMC or NAND can be enabled. Selection between eMMC and NAND is
controlled:
(a) By dynamically driving following GPIO pin from software
SPI2_CS0(GPIO) == 0 NAND is selected (default)
SPI2_CS0(GPIO) == 1 eMMC is selected
(b) By statically using Jumper (J89) on the board
(2) As NAND device connnected to this board has page-size=4K and oob-size=224,
So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for
NAND boot.
Signed-off-by: Pekon Gupta pe...@ti.com
Reviewed-by: Javier Martinez Canillas jav...@dowhile0.org
---
arch/arm/boot/dts/am437x-gp-evm.dts | 108
1 file changed, 108 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 30ace1b..97b71e6 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -150,6 +150,27 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
;
};
+
+ nand_flash_x8: nand_flash_x8 {
+ pinctrl-single,pins =
+ 0x26c(PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
spi2_cs0.gpio/eMMCorNANDsel */
+ 0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0.gpmc_ad0 */
+ 0x4 (PIN_INPUT | MUX_MODE0) /* gpmc_ad1.gpmc_ad1 */
+ 0x8 (PIN_INPUT | MUX_MODE0) /* gpmc_ad2.gpmc_ad2 */
+ 0xc (PIN_INPUT | MUX_MODE0) /* gpmc_ad3.gpmc_ad3 */
+ 0x10 (PIN_INPUT | MUX_MODE0) /* gpmc_ad4.gpmc_ad4 */
+ 0x14 (PIN_INPUT | MUX_MODE0) /* gpmc_ad5.gpmc_ad5 */
+ 0x18 (PIN_INPUT | MUX_MODE0) /* gpmc_ad6.gpmc_ad6 */
+ 0x1c (PIN_INPUT | MUX_MODE0) /* gpmc_ad7.gpmc_ad7 */
+ 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_wait0.gpmc_wait0 */
+ 0x74 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_wpn.gpmc_wpn */
+ 0x7c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_csn0.gpmc_csn0 */
+ 0x90 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_wen.gpmc_wen */
+ 0x9c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_be0n_cle.gpmc_be0n_cle */
+ ;
+ };
};
i2c0 {
@@ -246,3 +267,90 @@
phy_id = davinci_mdio, 0;
phy-mode = rgmii;
};
+
+elm {
+ status = okay;
+};
+
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x8;
+ ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+ nand@0,0 {
+ reg = 0 0 0x37c; /* device IO registers */
This register space is used by the parent GPMC node as well as the NAND
controller. So doing a request_and_ioremap() on this space will fail as it is
already taken by the GPMC driver.
Further, the GPMC register space doesn't map to the GPMC memory map created by
this Chip select but it is mapped to L3_IO space. i.e. (physical address 0x6e00
)
We could have split the GPMC register space into GPMC part and NAND part but to
add to the complexity, the register spaces for GPMC vs NAND are interleaved so
it can't be easily split up. The way the NAND driver is currently written is
that it expects the register addresses to come via platform data, primarily to
get around this address interleaving issue.
Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC
memory map for I/O, and that is something that could be reflected here.
e.g.
reg = 0 0 4; /* NAND I/O space */
But still, the start address can't be 0 and has to be assigned when this CS
region is mapped. It is still unclear to me how that can be done.
cheers,
-roger
+ ti,nand-ecc-opt = bch8;
+ ti,elm-id = elm;
+ nand-bus-width = 8;
+ gpmc,device-width = 1;
+ gpmc,sync-clk-ps = 0;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 40;
+ gpmc,cs-wr-off-ns = 40;
+ gpmc,adv-on-ns = 0;
+ gpmc,adv-rd-off-ns = 25;
+ gpmc,adv-wr-off-ns = 25;
+ gpmc,we-on-ns = 0;
+ gpmc,we-off-ns = 20;
+ gpmc,oe-on-ns = 3;
+ gpmc,oe-off-ns = 30;
+ gpmc,access-ns = 30;
+ gpmc,rd-cycle-ns = 40;
+ gpmc,wr-cycle-ns = 40;
+ gpmc,wait-pin = 0;
+ gpmc,wait-on-read;
+
RE: [PATCH v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
Hi Roger,
From: Quadros, Roger
[...]
+gpmc {
+status = okay;
+pinctrl-names = default;
+pinctrl-0 = nand_flash_x8;
+ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+nand@0,0 {
+reg = 0 0 0x37c; /* device IO registers */
This register space is used by the parent GPMC node as well as the NAND
controller. So doing a
request_and_ioremap() on this space will fail as it is already taken by the
GPMC driver.
Further, the GPMC register space doesn't map to the GPMC memory map created by
this Chip select
but it is mapped to L3_IO space. i.e. (physical address 0x6e00 )
We could have split the GPMC register space into GPMC part and NAND part but
to add to the
complexity, the register spaces for GPMC vs NAND are interleaved so it can't
be easily split up.
Sorry I din't get this part.
NAND is one of the devices supported by GPMC controller.
Hardware wise the it's the same engine is used for NAND, NOR and OneNAND
and even other parallel interfaces like Camera, Ethernet, etc..
So how can be NAND and GPMC registers space be splitted ?
I see gpmc.c as generic controller driver, which just does initializations
and registering the device. Then it's upto the individual protocol drivers
to probe the device and attach it to respective sub-system; like;
(a) drivers/mtd/nand/omap2.c for NAND
(b) drivers/mtd/chips/cfi_probe.c for NOR
...
The way
the NAND driver is currently written is that it expects the register addresses
to come via platform data,
primarily to get around this address interleaving issue.
Yes, that is right.
I don't know the historical reasons but that is correct also because,
(1) large set of GPMC register configurations are common across all
types of devices (like NAND, NOR, OneNAND, Ethernet). These
register configurations define the signal timings and physical attributes
of device (like device width, etc).
(2) Individual protocol drivers (a) and (b) only uses a sub-set of registers
for transferring data, much of which is based on type of protocol.
So, large part of GPMC configurations remains static and can be
Shared across all types of devices, hence those are put in gpmc.c
Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC
memory map for I/O,
and that is something that could be reflected here.
e.g.
reg = 0 0 4; /* NAND I/O space */
But still, the start address can't be 0 and has to be assigned when this CS
region is mapped. It is still
unclear to me how that can be done.
Yes, NAND is not directly mapped. So only 4-bytes of I/O size will do.
But where to map these 4 bytes ? and which 4-bytes to map.
So I have included complete GPMC register space-size.
Also since GPMC has a constrain that every chip-select must have
minimum of 16MB memory. So we specify it via range property
to keep GPMC mapping consistent across all NAND, NOR, OneNAND, etc..
If you have any better approach in mind for keeping consistent
memory mapping across different types of devices, then please suggest ..
I'll try to get this done in next set of patches, if not these.
Or
May be you can take over as part of GPMC transition.
cheers,
-roger
with regards, pekon
--
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 v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
On 05/16/2014 04:58 PM, Gupta, Pekon wrote:
Hi Roger,
From: Quadros, Roger
[...]
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x8;
+ ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+ nand@0,0 {
+ reg = 0 0 0x37c; /* device IO registers */
This register space is used by the parent GPMC node as well as the NAND
controller. So doing a
request_and_ioremap() on this space will fail as it is already taken by the
GPMC driver.
Further, the GPMC register space doesn't map to the GPMC memory map created
by this Chip select
but it is mapped to L3_IO space. i.e. (physical address 0x6e00 )
We could have split the GPMC register space into GPMC part and NAND part but
to add to the
complexity, the register spaces for GPMC vs NAND are interleaved so it can't
be easily split up.
Sorry I din't get this part.
NAND is one of the devices supported by GPMC controller.
Hardware wise the it's the same engine is used for NAND, NOR and OneNAND
But GPMC register space is only used for 2 things, Chip Select configuration
and NAND driver.
GPMC registers are not used for NOR, OneNAND or other memory accessible
devices. They don't need GPMC registers because their registers are mapped in
the GPMC I/O space.
and even other parallel interfaces like Camera, Ethernet, etc..
So how can be NAND and GPMC registers space be splitted ?
- all Chip select configuration registers i.e. GPMC_CONFIG* should go to GPMC
device
- all the GPMC_NAND_*, GPMC_ECC_, and GPMC_BCH_* registers go to NAND device
The tricky part is that all these registers are interleaved among each other
and so the register map is fragmented.
I see gpmc.c as generic controller driver, which just does initializations
and registering the device. Then it's upto the individual protocol drivers
to probe the device and attach it to respective sub-system; like;
(a) drivers/mtd/nand/omap2.c for NAND
(b) drivers/mtd/chips/cfi_probe.c for NOR
...
omap2.c needs GPMC registers, but cfi_probe.c and others don't need them.
The way
the NAND driver is currently written is that it expects the register
addresses to come via platform data,
primarily to get around this address interleaving issue.
Yes, that is right.
I don't know the historical reasons but that is correct also because,
(1) large set of GPMC register configurations are common across all
types of devices (like NAND, NOR, OneNAND, Ethernet). These
register configurations define the signal timings and physical attributes
of device (like device width, etc).
(2) Individual protocol drivers (a) and (b) only uses a sub-set of registers
for transferring data, much of which is based on type of protocol.
So, large part of GPMC configurations remains static and can be
Shared across all types of devices, hence those are put in gpmc.c
Right, so just the GPMC configuration part needs to be with GPMC driver. The
NAND controller bits don't need to be.
Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC
memory map for I/O,
and that is something that could be reflected here.
e.g.
reg = 0 0 4; /* NAND I/O space */
But still, the start address can't be 0 and has to be assigned when this CS
region is mapped. It is still
unclear to me how that can be done.
Yes, NAND is not directly mapped. So only 4-bytes of I/O size will do.
But where to map these 4 bytes ? and which 4-bytes to map.
So I have included complete GPMC register space-size.
That is not the right solution. The mapping is done in the gpmc driver in
gpmc_cs_request()/gpmc_cs_remap().
If a random address (meeting GPMC alignment needs) is specified within the GPMC
1GB space, the GPMC driver should configure the CS to map
to that address. If 0 is specified then the GPMC must map it automatically to a
sane address and then update the reg property before instantiating the child
node's platform device.
For the NAND controller, we don't even create a child device based on the OF
node but instead legacy platform device, so this reg property isn't being even
used.
Also since GPMC has a constrain that every chip-select must have
minimum of 16MB memory. So we specify it via range property
to keep GPMC mapping consistent across all NAND, NOR, OneNAND, etc..
If you have any better approach in mind for keeping consistent
memory mapping across different types of devices, then please suggest ..
I'll try to get this done in next set of patches, if not these.
Or
May be you can take over as part of GPMC transition.
As the driver doesn't rely on the reg address portion (at least for the NAND
driver), you can leave this option out for now.
cheers,
-roger
--
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 v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
* Roger Quadros rog...@ti.com [140516 05:23]:
On 05/16/2014 02:03 PM, Pekon Gupta wrote:
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x8;
+ ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+ nand@0,0 {
+ reg = 0 0 0x37c; /* device IO registers */
This register space is used by the parent GPMC node as well as the NAND
controller. So doing a request_and_ioremap() on this space will fail as it is
already taken by the GPMC driver.
Further, the GPMC register space doesn't map to the GPMC memory map created
by this Chip select but it is mapped to L3_IO space. i.e. (physical address
0x6e00 )
We could have split the GPMC register space into GPMC part and NAND part but
to add to the complexity, the register spaces for GPMC vs NAND are
interleaved so it can't be easily split up. The way the NAND driver is
currently written is that it expects the register addresses to come via
platform data, primarily to get around this address interleaving issue.
Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC
memory map for I/O, and that is something that could be reflected here.
e.g.
reg = 0 0 4; /* NAND I/O space */
Guys, the reg size here is size of the IO region for the
NAND driver, it should not have anything to do with the GPMC
registers for the GPMC functions that the NAND driver may call.
So it sounds like 0x37c is wrong, and 4 is the right value if
the NAND chip has only one IO register.
But still, the start address can't be 0 and has to be assigned when this CS
region is mapped. It is still unclear to me how that can be done.
If the offset for the NAND driver needs to be different from 0,
it can be in the offset. For example, the smsc,lan91c94 driver
wants the IO address space to be at offset 0x300 to avoid some
extra warnings during the boot. So for that, the reg entry is:
reg = 1 0x300 0xf;
Where we have:
1 = chip select
0x300 = offset of smsc device register IO space from the start of
16MB minimum GPMC partition
0xf = size of smsc device register IO space that the Ethernet
driver ioremaps
Regards,
Tony
--
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 v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
Hi Tony, Roger,
From: Tony Lindgren [mailto:t...@atomide.com]
* Roger Quadros rog...@ti.com [140516 05:23]:
On 05/16/2014 02:03 PM, Pekon Gupta wrote:
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x8;
+ ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+ nand@0,0 {
+ reg = 0 0 0x37c; /* device IO registers */
This register space is used by the parent GPMC node as well as the NAND
controller. So doing a
request_and_ioremap() on this space will fail as it is already taken by the
GPMC driver.
Further, the GPMC register space doesn't map to the GPMC memory map created
by this Chip select
but it is mapped to L3_IO space. i.e. (physical address 0x6e00 )
We could have split the GPMC register space into GPMC part and NAND part but
to add to the
complexity, the register spaces for GPMC vs NAND are interleaved so it can't
be easily split up. The way
the NAND driver is currently written is that it expects the register addresses
to come via platform data,
primarily to get around this address interleaving issue.
Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC
memory map for
I/O, and that is something that could be reflected here.
e.g.
reg = 0 0 4; /* NAND I/O space */
Guys, the reg size here is size of the IO region for the
NAND driver, it should not have anything to do with the GPMC
registers for the GPMC functions that the NAND driver may call.
So it sounds like 0x37c is wrong, and 4 is the right value if
the NAND chip has only one IO register.
Yes, Roger and myself both agree on the actual size of 4.
But what I'm not sure is what should be offset for a io-remapped region.
Apologies for my ignorance here, as I'm not good in this memory mapping
concept..
- I understand that for 'memory mapped' device offset is with respect to
base-address of chip-select.
- But for indirectly mapped device (like NAND) how is offset calculated?
Example: For CS0 in GPMC ..
GPMC_NAND_COMMAND_0 = 0x007c
GPMC_NAND_ADDRESS_0 = 0x0080
GPMC_NAND_DATA_0 = 0x0084
(1) Now, should the 'offset' for reg property used for NAND node
connected at CS=0. reg = 0 ?? 4
(a) Should it be equal to 'GPMC_NAND_ADDRESS_0'?
OR
(b) There is no relation between 'GPMC register' and 'NAND partition' offset?
(2) If considering (a) then should size consider only GPMC_NAND_ADDRESS_0
or also include GPMC_NAND_COMMAND_0 and GPMC_NAND_DATA_0?
This is why I used the size of complete GPMC register space for NAND region
also.
But still, the start address can't be 0 and has to be assigned when this CS
region is mapped. It is still
unclear to me how that can be done.
If the offset for the NAND driver needs to be different from 0,
it can be in the offset. For example, the smsc,lan91c94 driver
wants the IO address space to be at offset 0x300 to avoid some
extra warnings during the boot. So for that, the reg entry is:
reg = 1 0x300 0xf;
Where we have:
1 = chip select
0x300 = offset of smsc device register IO space from the start of
16MB minimum GPMC partition
This is where my confusion lies, where is the 0x300 coming from?
Is this the offset of I/O register in given Ethernet IP register space?
0xf = size of smsc device register IO space that the Ethernet
driver ioremaps
with regards, pekon
--
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 v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
Pekon,
On 05/16/2014 09:52 PM, Gupta, Pekon wrote:
Hi Tony, Roger,
From: Tony Lindgren [mailto:t...@atomide.com]
* Roger Quadros rog...@ti.com [140516 05:23]:
On 05/16/2014 02:03 PM, Pekon Gupta wrote:
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_flash_x8;
+ ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+ nand@0,0 {
+ reg = 0 0 0x37c; /* device IO registers */
This register space is used by the parent GPMC node as well as the NAND
controller. So doing a
request_and_ioremap() on this space will fail as it is already taken by the
GPMC driver.
Further, the GPMC register space doesn't map to the GPMC memory map created
by this Chip select
but it is mapped to L3_IO space. i.e. (physical address 0x6e00 )
We could have split the GPMC register space into GPMC part and NAND part
but to add to the
complexity, the register spaces for GPMC vs NAND are interleaved so it can't
be easily split up. The way
the NAND driver is currently written is that it expects the register
addresses to come via platform data,
primarily to get around this address interleaving issue.
Apart from the GPMC register space, the NAND controller uses 4 bytes of
GPMC memory map for
I/O, and that is something that could be reflected here.
e.g.
reg = 0 0 4; /* NAND I/O space */
Guys, the reg size here is size of the IO region for the
NAND driver, it should not have anything to do with the GPMC
registers for the GPMC functions that the NAND driver may call.
So it sounds like 0x37c is wrong, and 4 is the right value if
the NAND chip has only one IO register.
Yes, Roger and myself both agree on the actual size of 4.
But what I'm not sure is what should be offset for a io-remapped region.
Apologies for my ignorance here, as I'm not good in this memory mapping
concept..
- I understand that for 'memory mapped' device offset is with respect to
base-address of chip-select.
- But for indirectly mapped device (like NAND) how is offset calculated?
This would depend on what the NAND driver expects. In the current OMAP nand
driver it expects only the memory mapped NAND I/O resource.
Example: For CS0 in GPMC ..
GPMC_NAND_COMMAND_0 = 0x007c
GPMC_NAND_ADDRESS_0 = 0x0080
GPMC_NAND_DATA_0 = 0x0084
OK, let's say that we want to update that NAND driver to accept a second memory
resource which would be the GPMC registers starting from GPMC_NAND_COMMAND_0
(phy.addr 0x6e00 007c), then we need to define a new address in the ranges
property of the gpmc node.
Something like so
ranges = 0 0 0x 0x0100 /* GPMC external map */
1 0 0x6e00 0x037c; /* GPMC register map */
nand@0,0 {
reg = 0 0 4/* NAND I/O space */
1 0x7c 3/* NAND controller registers */
Since range 1 started from 0x6e00 we specify offset as 0x7c.
But at the moment the NAND driver doesn't directly access the GPMC register map
so it should be sufficient to just specify the I/O space.
(1) Now, should the 'offset' for reg property used for NAND node
connected at CS=0. reg = 0 ?? 4
(a) Should it be equal to 'GPMC_NAND_ADDRESS_0'?
OR
(b) There is no relation between 'GPMC register' and 'NAND partition'
offset?
(2) If considering (a) then should size consider only GPMC_NAND_ADDRESS_0
or also include GPMC_NAND_COMMAND_0 and GPMC_NAND_DATA_0?
This is why I used the size of complete GPMC register space for NAND region
also.
But still, the start address can't be 0 and has to be assigned when this CS
region is mapped. It is still
unclear to me how that can be done.
If the offset for the NAND driver needs to be different from 0,
it can be in the offset. For example, the smsc,lan91c94 driver
wants the IO address space to be at offset 0x300 to avoid some
extra warnings during the boot. So for that, the reg entry is:
reg = 1 0x300 0xf;
Where we have:
1 = chip select
0x300 = offset of smsc device register IO space from the start of
16MB minimum GPMC partition
This is where my confusion lies, where is the 0x300 coming from?
Is this the offset of I/O register in given Ethernet IP register space?
I'm not sure about 0x300 but this is my guess.
The smsc register addresses start at 0x300. In theory this could be aligned to
the CS start address and we could have worked with 0 offset. But because of the
16MB min. granularity requirement for the GPMC CS start address, A23:A0 have to
be 0. As CS start address can never be aligned to 0x300 we can't have 0 offset.
cheers,
-roger
--
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 v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
* Roger Quadros rog...@ti.com [140516 13:30]:
Pekon,
On 05/16/2014 09:52 PM, Gupta, Pekon wrote:
Hi Tony, Roger,
From: Tony Lindgren [mailto:t...@atomide.com]
* Roger Quadros rog...@ti.com [140516 05:23]:
On 05/16/2014 02:03 PM, Pekon Gupta wrote:
+gpmc {
+status = okay;
+pinctrl-names = default;
+pinctrl-0 = nand_flash_x8;
+ranges = 0 0 0 0x0100;/* minimum GPMC partition =
16MB */
+nand@0,0 {
+reg = 0 0 0x37c; /* device IO registers */
This register space is used by the parent GPMC node as well as the NAND
controller. So doing a
request_and_ioremap() on this space will fail as it is already taken by
the GPMC driver.
Further, the GPMC register space doesn't map to the GPMC memory map
created by this Chip select
but it is mapped to L3_IO space. i.e. (physical address 0x6e00 )
We could have split the GPMC register space into GPMC part and NAND part
but to add to the
complexity, the register spaces for GPMC vs NAND are interleaved so it
can't be easily split up. The way
the NAND driver is currently written is that it expects the register
addresses to come via platform data,
primarily to get around this address interleaving issue.
Apart from the GPMC register space, the NAND controller uses 4 bytes of
GPMC memory map for
I/O, and that is something that could be reflected here.
e.g.
reg = 0 0 4; /* NAND I/O space */
Guys, the reg size here is size of the IO region for the
NAND driver, it should not have anything to do with the GPMC
registers for the GPMC functions that the NAND driver may call.
So it sounds like 0x37c is wrong, and 4 is the right value if
the NAND chip has only one IO register.
Yes, Roger and myself both agree on the actual size of 4.
But what I'm not sure is what should be offset for a io-remapped region.
Apologies for my ignorance here, as I'm not good in this memory mapping
concept..
- I understand that for 'memory mapped' device offset is with respect to
base-address of chip-select.
- But for indirectly mapped device (like NAND) how is offset calculated?
This would depend on what the NAND driver expects. In the current OMAP nand
driver it expects only the memory mapped NAND I/O resource.
Example: For CS0 in GPMC ..
GPMC_NAND_COMMAND_0 = 0x007c
GPMC_NAND_ADDRESS_0 = 0x0080
GPMC_NAND_DATA_0 = 0x0084
OK, let's say that we want to update that NAND driver to accept a second
memory resource which would be the GPMC registers starting from
GPMC_NAND_COMMAND_0 (phy.addr 0x6e00 007c), then we need to define a new
address in the ranges property of the gpmc node.
Something like so
ranges = 0 0 0x 0x0100 /* GPMC external map */
1 0 0x6e00 0x037c; /* GPMC register map */
nand@0,0 {
reg = 0 0 4/* NAND I/O space */
1 0x7c 3/* NAND controller registers */
Since range 1 started from 0x6e00 we specify offset as 0x7c.
But at the moment the NAND driver doesn't directly access the GPMC register
map so it should be sufficient to just specify the I/O space.
(1) Now, should the 'offset' for reg property used for NAND node
connected at CS=0. reg = 0 ?? 4
(a) Should it be equal to 'GPMC_NAND_ADDRESS_0'?
OR
(b) There is no relation between 'GPMC register' and 'NAND partition'
offset?
(2) If considering (a) then should size consider only GPMC_NAND_ADDRESS_0
or also include GPMC_NAND_COMMAND_0 and GPMC_NAND_DATA_0?
This is why I used the size of complete GPMC register space for NAND region
also.
The NAND driver should only ioremap the NAND register(s). The
GPMC driver has the GPMC registers ioremapped, and should allow
the NAND driver to use those registers via some functions in the
GPMC code. Those functions should be ideally made available to
the NAND driver by some Linux generic framework rather than
custom exported functions.
But still, the start address can't be 0 and has to be assigned when this
CS region is mapped. It is still
unclear to me how that can be done.
If the offset for the NAND driver needs to be different from 0,
it can be in the offset. For example, the smsc,lan91c94 driver
wants the IO address space to be at offset 0x300 to avoid some
extra warnings during the boot. So for that, the reg entry is:
reg = 1 0x300 0xf;
Where we have:
1 = chip select
0x300 = offset of smsc device register IO space from the start of
16MB minimum GPMC partition
This is where my confusion lies, where is the 0x300 coming from?
Is this the offset of I/O register in given Ethernet IP register space?
I'm not sure about 0x300 but this is my guess.
The smsc register addresses start at 0x300. In theory this could be aligned
to the CS start address and we
