From: Pratyush Yadav <ptyadav@amazon.de>
To: liao jaime <jaimeliao.tw@gmail.com>
Cc: Michael Walle <michael@walle.cc>, <linux-mtd@lists.infradead.org>,
<tudor.ambarus@linaro.org>, <pratyush@kernel.org>,
<miquel.raynal@bootlin.com>, <leoyu@mxic.com.tw>,
<jaimeliao@mxic.com.tw>
Subject: Re: [PATCH] mtd: spi-nor: core: Introduce spi_nor_abort_octal_dtr()
Date: Mon, 29 Jan 2024 14:01:11 +0100 [thread overview]
Message-ID: <mafs0frygtht4.fsf@amazon.de> (raw)
In-Reply-To: <CAAQoYRmYxmD8v20_Q=YShj_xv1vsV7fXnAGPYPBSP=XJmoG2-Q@mail.gmail.com> (liao jaime's message of "Wed, 13 Dec 2023 10:37:33 +0800")
Hi,
On Wed, Dec 13 2023, liao jaime wrote:
> Hi Michael
>
>
>>
>> Hi,
>>
>> >> > Some flashes contains 8D_8D_8D information in SFDP but did not enter
>> >> > octal DTR mode if conditions are not satisfied.
>> >>
>> >> What exactly are these conditions? Rather than "abort" the octal mode,
>> >> the flash shouldn't have that capability in the first place.
>> > "Abort" is not a good word.
>> > Is it better for using "discard"?
>> > 3 conditions should be satisfied before enable octal dtr mode.
>> > 1. function hook in nor->params->set_octal_dtr
>> > 2. nor->read_proto and nor->write_proto are SNOR_PROTO_8_8_8_DTR
>> > 3. nor->flags & SNOR_F_IO_MODE_EN_VOLATILE
>> > Flash driver still bring 8D_8D_8D protocol instructions in 1s-1s-1s
>> > mode if
>> > conditions are not satisfied.
>> > In a case, flash ID didn't include in vendor's ID table.
>> > It will be "spi-nor-generic".
>> > 8D-8D-8D information could be parsed in SFDP but
>> > nor->params->set_octal_dtr
>> > didn't hook vendor specific function for enabling octal dtr mode.
>> > So that it still bring 8D protocol in 1s-1s-1s mode and have no chance
>> > to select 1-1-8 protocol.
>> > I think it may better to re-select a suitable protocol for this case.
>>
>> Just that we are on the same page. You are using the spi-nor-generic
>> driver, but that driver will elect the 8d8d8d protocol but that won't
>> work, because we don't have a .set_octal_dtr. Therefore, the fallback
>> is 1s1s1s. Correct?
> Yes.
> Based on my understanding, typically, flash that support the 1-1-8 feature
> also tends to support 8D-8D-8D feature.
> However, in the case of spi-nor-generic, we don't have a .set_octal_dtr.
> Therefore, I believe that if octal DTR mode cannot be enabled due to
> this, it might be necessary to reconsider and choose a suitable feature.
Can't you parse the SCCR to learn how to enable 8D-8D-8D mode for
generic flash drivers? That way you can set octal_enable() for generic
flashes as well.
To be clear, I still think you should implement Michael's suggestions
about masking out SNOR_HWCAPS_8_8_8. This is an enhancement that you can
add on top to enable Octal DTR for generic flashes via SFDP. You seem to
have a flash capable of doing that so might as well enable its full
powers.
[...]
--
Regards,
Pratyush Yadav
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
prev parent reply other threads:[~2024-01-29 13:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-07 7:51 [PATCH] mtd: spi-nor: core: Introduce spi_nor_abort_octal_dtr() Jaime Liao
2023-12-11 10:51 ` Michael Walle
2023-12-12 9:05 ` liao jaime
2023-12-12 13:37 ` Michael Walle
2023-12-13 2:37 ` liao jaime
2023-12-13 8:48 ` Michael Walle
2023-12-13 9:05 ` liao jaime
2023-12-13 9:10 ` Michael Walle
2023-12-13 9:16 ` liao jaime
2024-01-29 13:01 ` Pratyush Yadav [this message]
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=mafs0frygtht4.fsf@amazon.de \
--to=ptyadav@amazon.de \
--cc=jaimeliao.tw@gmail.com \
--cc=jaimeliao@mxic.com.tw \
--cc=leoyu@mxic.com.tw \
--cc=linux-mtd@lists.infradead.org \
--cc=michael@walle.cc \
--cc=miquel.raynal@bootlin.com \
--cc=pratyush@kernel.org \
--cc=tudor.ambarus@linaro.org \
/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.