kirkwood_nand: claim MPP pins on the fly

RFC PATCH New Chris Packham 4 participants 7 messages Jan 15, 2016 – Apr 6, 2016

Subsystems (2)

Memory technology devices (MTD) NAND flash

lore

Share & tools

lore

Chris Packham

author

2016-01-15 04:22 UTC #0 lore raw

RFC PATCH 1/1 kirkwood_nand: claim MPP pins on the fly

Claim the MPP pins for the NAND flash controller only when it's actually being used. This allows the pins to be shared with the SPI interface which already supports an equivalent on-access MPP reconfiguration.

Reviewed-by Mark Tomlinson <[email protected]>

Signed-off-by Chris Packham <[email protected]>

---
I haven't wrapped this with a configuration option because I think it should be safe to enable by default. It will either re-apply the same MPP configuration that has already been done in the board init or put the MPP pins into the correct mode to access NAND.

I've only got access to one kirkwood based board with NAND flash so I'd appreciate some feedback from someone with access to a few different boards.

From the datasheets I have access to it looks like there is only one possible MPP configuration for NF_IO[0-7] so that is what I've implemented. I'm not aware of anything using this driver that needs a different MPP config.

 drivers/mtd/nand/kirkwood_nand.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

drivers/mtd/nand/kirkwood_nand.c +19 -0

index 4fc34d6..ff81212 100644
@@ -9,6 +9,7 @@
 #include <common.h>
 #include <asm/io.h>
 #include <asm/arch/soc.h>
+#include <asm/arch/mpp.h>
 #include <nand.h>
 
 /* NAND Flash Soc registers */

@@ -22,6 +23,8 @@ struct kwnandf_registers {
 static struct kwnandf_registers *nf_reg =
 	(struct kwnandf_registers *)KW_NANDF_BASE;
 
+static u32 nand_mpp_backup[9] = { 0 };
+
 /*
  * hardware specific access to control-lines/bits
  */

@@ -49,6 +52,22 @@ static void kw_nand_hwcontrol(struct mtd_info *mtd, int cmd,
 void kw_nand_select_chip(struct mtd_info *mtd, int chip)
 {
 	u32 data;
+	u32 nand_config[] = {
+		MPP0_NF_IO2,
+		MPP1_NF_IO3,
+		MPP2_NF_IO4,
+		MPP3_NF_IO5,
+		MPP4_NF_IO6,
+		MPP5_NF_IO7,
+		MPP18_NF_IO0,
+		MPP19_NF_IO1,
+		0
+	};
+
+	if (chip >= 0)
+		kirkwood_mpp_conf(nand_config, nand_mpp_backup);
+	else
+		kirkwood_mpp_conf(nand_mpp_backup, NULL);
 
 	data = readl(&nf_reg->ctrl);
 	data |= NAND_ACTCEBOOT_BIT;

Signature · 1 line

2.7.0

Scott Wood

2016-01-22 20:11 UTC #1 lore raw

RFC PATCH 1/1 kirkwood_nand: claim MPP pins on the fly

Quoted 38 lines · Chris Packham

Claim the MPP pins for the NAND flash controller only when it's actually being used. This allows the pins to be shared with the SPI interface which already supports an equivalent on-access MPP reconfiguration.
Reviewed-by Mark Tomlinson <[email protected]>
Signed-off-by Chris Packham <[email protected]>
---
I haven't wrapped this with a configuration option because I think it should be safe to enable by default. It will either re-apply the same MPP configuration that has already been done in the board init or put the MPP pins into the correct mode to access NAND.
I've only got access to one kirkwood based board with NAND flash so I'd appreciate some feedback from someone with access to a few different boards.
From the datasheets I have access to it looks like there is only one possible MPP configuration for NF_IO[0-7] so that is what I've implemented. I'm not aware of anything using this driver that needs a different MPP config.
 drivers/mtd/nand/kirkwood_nand.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
drivers/mtd/nand/kirkwood_nand.c +1 -0
index 4fc34d6..ff81212 100644
@@ -9,6 +9,7 @@
 #include <common.h>
 #include <asm/io.h>
 #include <asm/arch/soc.h>
+#include <asm/arch/mpp.h>
 #include <nand.h>
 
 /* NAND Flash Soc registers */

drivers/mtd/nand/kirkwood_nand.c struct kwnandf_registers { · line 26

Quoted 4 lines

drivers/mtd/nand/kirkwood_nand.c +1 -0

@@ -22,6 +23,8 @@ struct kwnandf_registers {
 static struct kwnandf_registers *nf_reg =
 	(struct kwnandf_registers *)KW_NANDF_BASE;
 
+static u32 nand_mpp_backup[9] = { 0 };

There's a non-static nand_mpp_backup[] in drivers/spi/kirkwood_spi.c, with a different length. And the length assumed by kirkwood_mpp_conf seems to be different still (and larger than the spi array).

Quoted 10 lines

drivers/mtd/nand/kirkwood_nand.c +2 -0

+
 /*
  * hardware specific access to control-lines/bits
  */

@@ -49,6 +52,22 @@ static void kw_nand_hwcontrol(struct mtd_info *mtd, int
 cmd,
 void kw_nand_select_chip(struct mtd_info *mtd, int chip)
 {
 	u32 data;
+	u32 nand_config[] = {

drivers/mtd/nand/kirkwood_nand.c static void kw_nand_hwcontrol(struct mtd_info *mtd, int · line 66

Quoted 10 lines

drivers/mtd/nand/kirkwood_nand.c +10 -0

+		MPP0_NF_IO2,
+		MPP1_NF_IO3,
+		MPP2_NF_IO4,
+		MPP3_NF_IO5,
+		MPP4_NF_IO6,
+		MPP5_NF_IO7,
+		MPP18_NF_IO0,
+		MPP19_NF_IO1,
+		0
+	};

If you make this static const the compiler won't need to create the table at runtime.

-Scott

Chris Packham

author

2016-01-23 08:44 UTC #2 lore raw

RFC PATCH 1/1 kirkwood_nand: claim MPP pins on the fly

Hi Scott,

Quoted 42 lines · Scott Wood

Quoted 41 lines · Chris Packham
Claim the MPP pins for the NAND flash controller only when it's actually being used. This allows the pins to be shared with the SPI interface which already supports an equivalent on-access MPP reconfiguration.
Reviewed-by Mark Tomlinson <[email protected]>
Signed-off-by Chris Packham <[email protected]>
---
I haven't wrapped this with a configuration option because I think it should be safe to enable by default. It will either re-apply the same MPP configuration that has already been done in the board init or put the MPP pins into the correct mode to access NAND.
I've only got access to one kirkwood based board with NAND flash so I'd appreciate some feedback from someone with access to a few different boards.
From the datasheets I have access to it looks like there is only one possible MPP configuration for NF_IO[0-7] so that is what I've implemented. I'm not aware of anything using this driver that needs a different MPP config.
 drivers/mtd/nand/kirkwood_nand.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
drivers/mtd/nand/kirkwood_nand.c +1 -0
index 4fc34d6..ff81212 100644
@@ -9,6 +9,7 @@
 #include <common.h>
 #include <asm/io.h>
 #include <asm/arch/soc.h>
+#include <asm/arch/mpp.h>
 #include <nand.h>
 
 /* NAND Flash Soc registers */
@@ -22,6 +23,8 @@ struct kwnandf_registers {
 static struct kwnandf_registers *nf_reg =
      (struct kwnandf_registers *)KW_NANDF_BASE;
 

Quoted 5 lines

drivers/mtd/nand/kirkwood_nand.c struct kwnandf_registers { · line 26
Quoted 1 line
drivers/mtd/nand/kirkwood_nand.c +1 -0
+static u32 nand_mpp_backup[9] = { 0 };
There's a non-static nand_mpp_backup[] in drivers/spi/kirkwood_spi.c, with a different length. And the length assumed by kirkwood_mpp_conf seems to be different still (and larger than the spi array).

I assume you mean "u32 spi_mpp_backup[4];". The length of the backup reflects the pins that are being changed. In kirkwood_spi it's configuring SPI_CK, SPI_MSIO, SPI_MOSI. So spi_mpp_config[4] reflects these 3 pin settings plus an empty end marker, spi_mpp_backup[4] is symmetrical although possibly only 3 are necessary.

In the nand case there are 8 NF_IO pins, hence the array sizes are 8+1.

kirkwood_mpp_conf doesn't enforce any particular size for mpp_save it is required to be at least as big as mpp_list.

Quoted 16 lines

drivers/mtd/nand/kirkwood_nand.c +7 -0

+
 /*
  * hardware specific access to control-lines/bits
  */

@@ -49,6 +52,22 @@ static void kw_nand_hwcontrol(struct mtd_info *mtd, int
 cmd,
 void kw_nand_select_chip(struct mtd_info *mtd, int chip)
 {
      u32 data;
+     u32 nand_config[] = {
+             MPP0_NF_IO2,
+             MPP1_NF_IO3,
+             MPP2_NF_IO4,
+             MPP3_NF_IO5,
+             MPP4_NF_IO6,

Quoted 8 lines

drivers/mtd/nand/kirkwood_nand.c static void kw_nand_hwcontrol(struct mtd_info *mtd, int cmd, · line 65
Quoted 5 lines
drivers/mtd/nand/kirkwood_nand.c +5 -0
+             MPP5_NF_IO7,
+             MPP18_NF_IO0,
+             MPP19_NF_IO1,
+             0
+     };
If you make this static const the compiler won't need to create the table at runtime.

Agreed. Will do in v2.

Quoted 3 lines

-Scott

Chris Packham

author

2016-02-01 23:35 UTC #3 lore raw

PATCH v2 1/1 kirkwood_nand: claim MPP pins on the fly

Reviewed-by Mark Tomlinson <[email protected]>

Signed-off-by Chris Packham <[email protected]>

I've only got access to one kirkwood based board with NAND flash so I'd appreciate some feedback from someone with access to a few different boards.

Changes in v2:
- make nand_config static const

 drivers/mtd/nand/kirkwood_nand.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

drivers/mtd/nand/kirkwood_nand.c +19 -0

index 4fc34d6..d734113 100644
@@ -9,6 +9,7 @@
 #include <common.h>
 #include <asm/io.h>
 #include <asm/arch/soc.h>
+#include <asm/arch/mpp.h>
 #include <nand.h>
 
 /* NAND Flash Soc registers */

@@ -22,6 +23,8 @@ struct kwnandf_registers {
 static struct kwnandf_registers *nf_reg =
 	(struct kwnandf_registers *)KW_NANDF_BASE;
 
+static u32 nand_mpp_backup[9] = { 0 };
+
 /*
  * hardware specific access to control-lines/bits
  */

@@ -49,6 +52,22 @@ static void kw_nand_hwcontrol(struct mtd_info *mtd, int cmd,
 void kw_nand_select_chip(struct mtd_info *mtd, int chip)
 {
 	u32 data;
+	static const u32 nand_config[] = {
+		MPP0_NF_IO2,
+		MPP1_NF_IO3,
+		MPP2_NF_IO4,
+		MPP3_NF_IO5,
+		MPP4_NF_IO6,
+		MPP5_NF_IO7,
+		MPP18_NF_IO0,
+		MPP19_NF_IO1,
+		0
+	};
+
+	if (chip >= 0)
+		kirkwood_mpp_conf(nand_config, nand_mpp_backup);
+	else
+		kirkwood_mpp_conf(nand_mpp_backup, NULL);
 
 	data = readl(&nf_reg->ctrl);
 	data |= NAND_ACTCEBOOT_BIT;

Signature · 1 line

2.7.0

Stefan Roese

2016-03-24 08:40 UTC #4 lore raw

PATCH v2 1/1 kirkwood_nand: claim MPP pins on the fly

Quoted 16 lines · Chris Packham

Claim the MPP pins for the NAND flash controller only when it's actually being used. This allows the pins to be shared with the SPI interface which already supports an equivalent on-access MPP reconfiguration.
Reviewed-by Mark Tomlinson <[email protected]>
Signed-off-by Chris Packham <[email protected]>
---
I haven't wrapped this with a configuration option because I think it should be safe to enable by default. It will either re-apply the same MPP configuration that has already been done in the board init or put the MPP pins into the correct mode to access NAND.
I've only got access to one kirkwood based board with NAND flash so I'd appreciate some feedback from someone with access to a few different boards.

Quoted 7 lines

From the datasheets I have access to it looks like there is only one
possible MPP configuration for NF_IO[0-7] so that is what I've implemented. I'm not aware of anything using this driver that needs a different MPP config.
Changes in v2:
- make nand_config static const

Scott, are you okay with this patch in v2? If yes, will you pull it? Or should I include it in a marvell pull request?

Thanks,
Stefan

Scott Wood

2016-04-04 22:48 UTC #5 lore raw

PATCH v2 1/1 kirkwood_nand: claim MPP pins on the fly

Quoted 22 lines · Stefan Roese

Quoted 21 lines · Chris Packham
Claim the MPP pins for the NAND flash controller only when it's actually being used. This allows the pins to be shared with the SPI interface which already supports an equivalent on-access MPP reconfiguration.
Reviewed-by Mark Tomlinson <[email protected]>
Signed-off-by Chris Packham <[email protected]>
---
I haven't wrapped this with a configuration option because I think it should be safe to enable by default. It will either re-apply the same MPP configuration that has already been done in the board init or put the MPP pins into the correct mode to access NAND.
I've only got access to one kirkwood based board with NAND flash so I'd appreciate some feedback from someone with access to a few different boards.
From the datasheets I have access to it looks like there is only one
possible MPP configuration for NF_IO[0-7] so that is what I've implemented. I'm not aware of anything using this driver that needs a different MPP config.

Quoted 4 lines

Quoted 2 lines
Changes in v2:
- make nand_config static const
Scott, are you okay with this patch in v2?

Yes.

Acked-by Scott Wood <[email protected]>

Quoted 2 lines

If yes, will you pull it?
Or should I include it in a marvell pull request?

Go ahead.

-Scott

Stefan Roese

2016-04-06 13:42 UTC #6 lore raw

PATCH v2 1/1 kirkwood_nand: claim MPP pins on the fly

Quoted 28 lines · Scott Wood

Quoted 22 lines · Stefan Roese
Quoted 21 lines · Chris Packham
Claim the MPP pins for the NAND flash controller only when it's actually being used. This allows the pins to be shared with the SPI interface which already supports an equivalent on-access MPP reconfiguration.
Reviewed-by Mark Tomlinson <[email protected]>
Signed-off-by Chris Packham <[email protected]>
---
I haven't wrapped this with a configuration option because I think it should be safe to enable by default. It will either re-apply the same MPP configuration that has already been done in the board init or put the MPP pins into the correct mode to access NAND.
I've only got access to one kirkwood based board with NAND flash so I'd appreciate some feedback from someone with access to a few different boards.
From the datasheets I have access to it looks like there is only one
possible MPP configuration for NF_IO[0-7] so that is what I've implemented. I'm not aware of anything using this driver that needs a different MPP config.
Quoted 4 lines
Quoted 2 lines
Changes in v2:
- make nand_config static const
Scott, are you okay with this patch in v2?

Quoted 7 lines

Yes.
Acked-by Scott Wood <[email protected]>
Quoted 2 lines
If yes, will you pull it?
Or should I include it in a marvell pull request?
Go ahead.

Applied to u-boot-marvell/master.

Thanks,
Stefan