From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Olivier Sobrie <olivier@sobrie.be>
Cc: Michal Simek <michal.simek@amd.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Andrea Scian <andrea.scian@dave.eu>
Subject: Re: [PATCH] mtd: rawnand: pl353: make sure optimal timings are applied
Date: Mon, 16 Mar 2026 09:46:39 +0100 [thread overview]
Message-ID: <87bjgogo0g.fsf@bootlin.com> (raw)
In-Reply-To: <20260304211823.569972-1-olivier@sobrie.be> (Olivier Sobrie's message of "Wed, 4 Mar 2026 22:18:23 +0100")
Hello Olivier,
+ Andrea
On 04/03/2026 at 22:18:23 +01, Olivier Sobrie <olivier@sobrie.be> wrote:
> Timings of the nand are adjusted by pl35x_nfc_setup_interface() but
> actually applied by the pl35x_nand_select_target() function.
> If there is only one nand chip, the pl35x_nand_select_target() will only
> apply the timings once since the test at its beginning will always be true
> after the first call to this function. As a result, the hardware will
> keep using the default timings set at boot to detect the nand chip, not
> the optimal ones.
>
> With this patch, we program directly the new timings when
> pl35x_nfc_setup_interface() is called.
>
> Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
Nice, this probably will deserve a Fixes tag and Cc: stable.
Andrea, this might be the reason why your NAND chip misbehaves after a
set_feature. Would you mind testing it?
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: Olivier Sobrie <olivier@sobrie.be>
Cc: Michal Simek <michal.simek@amd.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Andrea Scian <andrea.scian@dave.eu>
Subject: Re: [PATCH] mtd: rawnand: pl353: make sure optimal timings are applied
Date: Mon, 16 Mar 2026 09:46:39 +0100 [thread overview]
Message-ID: <87bjgogo0g.fsf@bootlin.com> (raw)
In-Reply-To: <20260304211823.569972-1-olivier@sobrie.be> (Olivier Sobrie's message of "Wed, 4 Mar 2026 22:18:23 +0100")
Hello Olivier,
+ Andrea
On 04/03/2026 at 22:18:23 +01, Olivier Sobrie <olivier@sobrie.be> wrote:
> Timings of the nand are adjusted by pl35x_nfc_setup_interface() but
> actually applied by the pl35x_nand_select_target() function.
> If there is only one nand chip, the pl35x_nand_select_target() will only
> apply the timings once since the test at its beginning will always be true
> after the first call to this function. As a result, the hardware will
> keep using the default timings set at boot to detect the nand chip, not
> the optimal ones.
>
> With this patch, we program directly the new timings when
> pl35x_nfc_setup_interface() is called.
>
> Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
Nice, this probably will deserve a Fixes tag and Cc: stable.
Andrea, this might be the reason why your NAND chip misbehaves after a
set_feature. Would you mind testing it?
Thanks,
Miquèl
next prev parent reply other threads:[~2026-03-16 8:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-04 21:18 [PATCH] mtd: rawnand: pl353: make sure optimal timings are applied Olivier Sobrie
2026-03-04 21:18 ` Olivier Sobrie
2026-03-16 8:46 ` Miquel Raynal [this message]
2026-03-16 8:46 ` Miquel Raynal
2026-03-17 7:05 ` Olivier Sobrie
2026-03-17 7:05 ` Olivier Sobrie
2026-03-17 8:57 ` Miquel Raynal
2026-03-17 8:57 ` Miquel Raynal
2026-03-19 11:35 ` Andrea Scian
2026-03-19 11:35 ` Andrea Scian
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=87bjgogo0g.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=andrea.scian@dave.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=michal.simek@amd.com \
--cc=olivier@sobrie.be \
--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.