From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Cc: "richard@nod.at" <richard@nod.at>,
"vigneshr@ti.com" <vigneshr@ti.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mtd: rawnand: marvell: ensure timing values are written
Date: Fri, 26 May 2023 19:10:15 +0200 [thread overview]
Message-ID: <20230526191015.2ea24813@xps-13> (raw)
In-Reply-To: <1c039840-25a4-875c-7dc5-f13c522b8156@alliedtelesis.co.nz>
Hi Chris,
Chris.Packham@alliedtelesis.co.nz wrote on Tue, 23 May 2023 20:42:45
+0000:
> On 23/05/23 21:39, Miquel Raynal wrote:
> > Hi Chris,
> >
> > chris.packham@alliedtelesis.co.nz wrote on Tue, 23 May 2023 15:21:03
> > +1200:
> >
> >> 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.
> >>
> >> Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com>
> >> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> > I believe this patch deserves Fixes+Cc:stable?
>
> I agree. I just wasn't sure what to point at with the fixes tag since
> you mentioned that it's probably a result in some of the core NAND
> infrastructure changing.
>
> Maybe b25251414f6e00 ("mtd: rawnand: marvell: Stop implementing
> ->select_chip()") is the correct change to point at.
Sounds reasonable.
>
> >> ---
> >>
> >> 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).
> >>
> >> 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..3b5e4d5d220f 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 restored in marvell_nfc_select_target().
> >> + */
> > s/restored/updated/ ?
> >
> > Restored feels like the content vanished.
> OK. Will send a v2 later today.
> >> + nfc->selected_chip = NULL;
> >> +
> >> return 0;
> >> }
> >>
> >
> > Thanks,
> > Miquè
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Cc: "richard@nod.at" <richard@nod.at>,
"vigneshr@ti.com" <vigneshr@ti.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mtd: rawnand: marvell: ensure timing values are written
Date: Fri, 26 May 2023 19:10:15 +0200 [thread overview]
Message-ID: <20230526191015.2ea24813@xps-13> (raw)
In-Reply-To: <1c039840-25a4-875c-7dc5-f13c522b8156@alliedtelesis.co.nz>
Hi Chris,
Chris.Packham@alliedtelesis.co.nz wrote on Tue, 23 May 2023 20:42:45
+0000:
> On 23/05/23 21:39, Miquel Raynal wrote:
> > Hi Chris,
> >
> > chris.packham@alliedtelesis.co.nz wrote on Tue, 23 May 2023 15:21:03
> > +1200:
> >
> >> 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.
> >>
> >> Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com>
> >> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> > I believe this patch deserves Fixes+Cc:stable?
>
> I agree. I just wasn't sure what to point at with the fixes tag since
> you mentioned that it's probably a result in some of the core NAND
> infrastructure changing.
>
> Maybe b25251414f6e00 ("mtd: rawnand: marvell: Stop implementing
> ->select_chip()") is the correct change to point at.
Sounds reasonable.
>
> >> ---
> >>
> >> 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).
> >>
> >> 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..3b5e4d5d220f 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 restored in marvell_nfc_select_target().
> >> + */
> > s/restored/updated/ ?
> >
> > Restored feels like the content vanished.
> OK. Will send a v2 later today.
> >> + nfc->selected_chip = NULL;
> >> +
> >> return 0;
> >> }
> >>
> >
> > Thanks,
> > Miquè
Thanks,
Miquèl
next prev parent reply other threads:[~2023-05-26 17:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-23 3:21 [PATCH] mtd: rawnand: marvell: ensure timing values are written Chris Packham
2023-05-23 3:21 ` Chris Packham
2023-05-23 9:39 ` Miquel Raynal
2023-05-23 9:39 ` Miquel Raynal
2023-05-23 20:42 ` Chris Packham
2023-05-23 20:42 ` Chris Packham
2023-05-26 17:10 ` Miquel Raynal [this message]
2023-05-26 17:10 ` Miquel Raynal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230526191015.2ea24813@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=Chris.Packham@alliedtelesis.co.nz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.