Message ID | 1454369709-5459-1-git-send-email-judge.packham@gmail.com |
---|---|
State | Accepted |
Commit | 46a16bd895144617575c788d9c2554aeef76ac44 |
Delegated to: | Stefan Roese |
Headers | show |
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
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
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 --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;