public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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/

      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox