public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: <Tudor.Ambarus@microchip.com>
To: <Yaliang.Wang@windriver.com>, <vigneshr@ti.com>,
	<miquel.raynal@bootlin.com>, <richard@nod.at>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] mtd: spi-nor: Use CLSR command for FL-L chips
Date: Wed, 24 Feb 2021 16:30:41 +0000	[thread overview]
Message-ID: <2966c209-190c-750b-9313-605157e20604@microchip.com> (raw)
In-Reply-To: <17a9226e-7d95-f3e6-7d94-ce6415ccd991@windriver.com>

On 2/24/21 6:24 PM, Yaliang.Wang wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi, Tudor
> 
> On 2/24/21 1:31 AM, Tudor.Ambarus@microchip.com wrote:
>> [Please note: This e-mail is from an EXTERNAL e-mail address]
>>
>> On 2/23/21 6:36 PM, Yaliang.Wang wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> Hi, Tudor
>> Hi, Yaliang,
>>> So sorry to reply so late, now I'm committed to solving this problem.
>>> After checking over sixty datasheets and almost at least one datasheet
>>> for each family of the manufacturers, I can finally deviler some
>>> conclusions.
>> Great! Thanks for doing this!
>>
>>> 1. RDSR2(07H) instruction is just used by Spansion manufacturer.
>> Then we can define it as
>> #define SPINOR_OP_SPANSION_SR2          0x07h
>>
>> and define its related static function in spansion.c.
>>
>>> As for all other manufacturers, most common instructions for reading SR2
>>> is "35H",  and "15H" is for reading SR3. Some manufactures have specific
>>> registers that are similar to status register, such as "Information
>>> Register", "Suspend Status Register", "Extended Read Register",
>>> "Security Register", "Flag Status Register" and also have specific
>>> instructions for reading them, such as"2BH/09H/81H/2BH/70H".
>> Are these common to more manufacturers? If yes, it will help us to inform
>> us to which manufacturers all these ops are common, it will spare us to
>> skim through datasheets later on.
> If not considering the number of chips we supported in each manufacture
> , "35H" and "15H" are more common instructions used among manufactures .
> "35H" to read SR2 is used in "spansion", "atmel", "esmt", "gigadevice",
> "winbond" manufactures.
> "15H" to read SR3 is used in "gigadevice", "winbond" manufactures.
> "33H" to read SR3 is used in "spansion" manufacture.
> "09H" to read SR2 and "95H" to read SR3 are used in "xmc" manufacture.
> 
> As for SR-similar registers, they always used by manufactures acting as
> a supplement of Status Register, but with a different name.
> "eon" uses "2BH""09H" to read "Information Register" and "Suspend Status
> Register"
> "issi" uses "81H" to read "Extended Read Register"
> "macronix" uses "2BH" to read "Security Register"
> "micron" and "st" uses "70H" to read "Extended Read Register"
>>> 2. RDSR2(07H) instruction is not just existed in Spansion "S25FL-L"
>>> family, also existed in Spansion"S79FL-S, S70FS-S, S25FL-S, S25FS-S,
>>> CYRS, CY15B/V-SN" families. We just haven't use it before, it has been
>>> there for a long time.
>> Cool, it can reside in spansion.c then.
>>
>>> 3. Many manufacturers are using CLSR(30H) instruction, but the functions
>>> are different.
>>> The most common function of "30H" instruction is  to resume the
>>> suspended bits, but in many Spansion's products , the function is to
>>> clear P_ERR and E_ERR bits. In some other Spansion's products(such as
>>> S25FS-S), Spansion provided a configure register, which can make "30H"
>>> instruction execute the alternative resuming suspended bits function
>>> like other manufacturers.
>> Which other manufacturers? It will help us later on.
> Spansion "S79FS-S""S70FS-S""S25FS-S" families provided the alternative
> resuming function for "30H" instruction, it can be configured with
> Configuration Register 3.
> Spansion "S79FL-S","S25FL-S","S25FL-P","S25FL-L","CYRS16B" families use
> "30H" instruction just to clear P_ERR AND E_ERR bits
> Spansion "S25FL-K", "S25FL-A", "CY15B/V-SN" families even don't use
> "30H" instruction.
>>
>> We can define the op that clears the P_ERR and E_ERR bits in spansion.c:
>> #define SPINOR_OP_SPANSION_CLSR          0x30h
>> with static function in spansion.c
>>
>> The op that is used at resume, can be latter added in the SPI NOR core.
>>
>>> 4. P_ERR and E_ERR bits are existed in many manufacturers, reside in
>>> specific register, such as "Information Register""Flag Status Register"
>>> and so on, and the instructions for reading those register and clearing
>>> the ERR bits varies according to the different manufacturer.
>> Again, if this is fresh in your mind, it would help to say which manufacturer
>> and what instructions.
> Check above comments.

Great, thanks!

>>> Based on the facts above, and to resolve the original "sr_ready" problem
>>> within "S25FL-L" family of Spansion, I think the solution is not much
>>> different. We need a "sr_ready" function pointer and maybe a new flag to
>>> mark the twisted status  register.  Actually I have made a rough fix
>> sr_ready function pointer should be enough. The default value for it will
>> be initialized in the SPI NOR core, and for your use-case, you can update
>> it in your manufacturer driver.
>>
>>> based on that(not include fixing spi_nor_xread_sr and
>>> spi_nor_fsr_ready). Would like to learn your suggestions before going
>>> further.
>> we should be good. Try a small patch and air it.
> So, maybe I can continue the fixing work now ? Basing on the  macro and
> the strategy you suggested above.
> Optimizing the original "sr_ready" function won't be too difficult I think.
> 

Yes, please. Let us know how it goes.

Cheers,
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2021-02-24 16:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-16 15:39 [PATCH] mtd: spi-nor: Use CLSR command for FL-L chips yaliang.wang
2021-01-23 17:45 ` Tudor.Ambarus
2021-01-24  6:12   ` Vignesh Raghavendra
2021-01-26  2:06     ` Wang, Yaliang
2021-01-26  8:51       ` Tudor.Ambarus
2021-02-23 16:36         ` Yaliang.Wang
2021-02-23 17:31           ` Tudor.Ambarus
2021-02-24 16:24             ` Yaliang.Wang
2021-02-24 16:30               ` Tudor.Ambarus [this message]
2021-03-29 13:12                 ` Tudor.Ambarus
2021-03-29 16:53                   ` Wang, Yaliang

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=2966c209-190c-750b-9313-605157e20604@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=Yaliang.Wang@windriver.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox