Message ID | 20230524000551.581491-1-chris.packham@alliedtelesis.co.nz |
---|---|
State | Changes Requested |
Delegated to: | Miquel Raynal |
Headers | show |
Series | [v2] mtd: rawnand: marvell: ensure timing values are written | expand |
On 24/05/23 12:05, Chris Packham wrote: > When new timing values are calculated in marvell_nfc_setup_interface() > ensure that they will be applied in marvell_nfc_select_target() by > clearing the selected_chip pointer. > > Fixes: b25251414f6e ("mtd: rawnand: marvell: Stop implementing ->select_chip()") > Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com> > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > --- > > Notes: > This at least gets me to a point where I can illustrated the problem > reported to me. It appears that despite the chip correctly reporting > support for SDR timing modes up to 4 the observed tWC is 20ns. I've not > seen any actual problem running in this state the only complaint is that > the datasheet says the minimum tWC is 25ns. > > If I make a change to my bootloader such that the NAND Clock Frequency > Select bit (0xF2440700:0) to 1 before booting the kernel _and_ I remove > the extra factor of 2 from the period_ns calculation I observe tWC of > about 60ns. If I don't remove the factor of 2 the NAND interface doesn't > work (can't write BBT). > > Changes in v2: > - reword comment per suggestion from Miquel, add fixes tag Actually thinking about this I should probably also include a change to drop the unconditional NAND Clock Frequency select. Some marvell_nand users probably aren't getting the best timings without this change but those with a system controller will probably end up with timings faster than intended (which may work depending on design tolerances). > > drivers/mtd/nand/raw/marvell_nand.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/mtd/nand/raw/marvell_nand.c b/drivers/mtd/nand/raw/marvell_nand.c > index afb424579f0b..f1fcf136ad03 100644 > --- a/drivers/mtd/nand/raw/marvell_nand.c > +++ b/drivers/mtd/nand/raw/marvell_nand.c > @@ -2457,6 +2457,12 @@ static int marvell_nfc_setup_interface(struct nand_chip *chip, int chipnr, > NDTR1_WAIT_MODE; > } > > + /* > + * Reset nfc->selected_chip so the next command will cause the timing > + * registers to be updated in marvell_nfc_select_target(). > + */ > + nfc->selected_chip = NULL; > + > return 0; > } >
diff --git a/drivers/mtd/nand/raw/marvell_nand.c b/drivers/mtd/nand/raw/marvell_nand.c index afb424579f0b..f1fcf136ad03 100644 --- a/drivers/mtd/nand/raw/marvell_nand.c +++ b/drivers/mtd/nand/raw/marvell_nand.c @@ -2457,6 +2457,12 @@ static int marvell_nfc_setup_interface(struct nand_chip *chip, int chipnr, NDTR1_WAIT_MODE; } + /* + * Reset nfc->selected_chip so the next command will cause the timing + * registers to be updated in marvell_nfc_select_target(). + */ + nfc->selected_chip = NULL; + return 0; }
When new timing values are calculated in marvell_nfc_setup_interface() ensure that they will be applied in marvell_nfc_select_target() by clearing the selected_chip pointer. Fixes: b25251414f6e ("mtd: rawnand: marvell: Stop implementing ->select_chip()") Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> --- Notes: This at least gets me to a point where I can illustrated the problem reported to me. It appears that despite the chip correctly reporting support for SDR timing modes up to 4 the observed tWC is 20ns. I've not seen any actual problem running in this state the only complaint is that the datasheet says the minimum tWC is 25ns. If I make a change to my bootloader such that the NAND Clock Frequency Select bit (0xF2440700:0) to 1 before booting the kernel _and_ I remove the extra factor of 2 from the period_ns calculation I observe tWC of about 60ns. If I don't remove the factor of 2 the NAND interface doesn't work (can't write BBT). Changes in v2: - reword comment per suggestion from Miquel, add fixes tag drivers/mtd/nand/raw/marvell_nand.c | 6 ++++++ 1 file changed, 6 insertions(+)