diff mbox

[U-Boot,v2] kirkwood_nand: claim MPP pins on the fly

Message ID 1454369709-5459-1-git-send-email-judge.packham@gmail.com
State Accepted
Commit 46a16bd895144617575c788d9c2554aeef76ac44
Delegated to: Stefan Roese
Headers show

Commit Message

Chris Packham Feb. 1, 2016, 11:35 p.m. UTC
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 <mark.tomlinson@alliedtelesis.co.nz>
Signed-off-by: Chris Packham <judge.packham@gmail.com>
---
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.

Changes in v2:
- make nand_config static const

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

Comments

Stefan Roese March 24, 2016, 8:40 a.m. UTC | #1
On 02.02.2016 00:35, Chris Packham wrote:
> 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 <mark.tomlinson@alliedtelesis.co.nz>
> Signed-off-by: Chris Packham <judge.packham@gmail.com>
> ---
> 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.
>
> 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 April 4, 2016, 10:48 p.m. UTC | #2
On 03/24/2016 03:40 AM, Stefan Roese wrote:
> On 02.02.2016 00:35, Chris Packham wrote:
>> 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 <mark.tomlinson@alliedtelesis.co.nz>
>> Signed-off-by: Chris Packham <judge.packham@gmail.com>
>> ---
>> 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.
>>
>> Changes in v2:
>> - make nand_config static const
> 
> Scott, are you okay with this patch in v2?

Yes.
Acked-by: Scott Wood <oss@buserror.net>

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

Go ahead.

-Scott
Stefan Roese April 6, 2016, 1:42 p.m. UTC | #3
On 05.04.2016 00:48, Scott Wood wrote:
> On 03/24/2016 03:40 AM, Stefan Roese wrote:
>> On 02.02.2016 00:35, Chris Packham wrote:
>>> 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 <mark.tomlinson@alliedtelesis.co.nz>
>>> Signed-off-by: Chris Packham <judge.packham@gmail.com>
>>> ---
>>> 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.
>>>
>>> Changes in v2:
>>> - make nand_config static const
>>
>> Scott, are you okay with this patch in v2?
>
> Yes.
> Acked-by: Scott Wood <oss@buserror.net>
>
>> 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
diff mbox

Patch

diff --git a/drivers/mtd/nand/kirkwood_nand.c b/drivers/mtd/nand/kirkwood_nand.c
index 4fc34d6..d734113 100644
--- a/drivers/mtd/nand/kirkwood_nand.c
+++ b/drivers/mtd/nand/kirkwood_nand.c
@@ -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;