public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Tudor Ambarus <tudor.ambarus@microchip.com>
To: Marek Vasut <marek.vasut@gmail.com>,
	<cyrille.pitchen@microchip.com>, <dwmw2@infradead.org>,
	<computersforpeace@gmail.com>, <boris.brezillon@bootlin.com>,
	<richard@nod.at>
Cc: <linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<nicolas.ferre@microchip.com>, <Cristian.Birsan@microchip.com>
Subject: Re: [RFC PATCH] mtd: spi-nor: add support to non-uniform SPI NOR flash memories
Date: Thu, 24 May 2018 12:32:38 +0300	[thread overview]
Message-ID: <d4e73ccb-58d2-f7fb-5303-15dc3dbd63aa@microchip.com> (raw)
In-Reply-To: <aa083709-c3e2-f075-1a99-c31399a1cb77@gmail.com>

Hi, Marek,

On 05/23/2018 03:54 PM, Marek Vasut wrote:
> On 05/23/2018 02:52 PM, Tudor Ambarus wrote:
>> Hi, Marek,
> 
> Hi,
> 
>> On 05/23/2018 12:56 PM, Marek Vasut wrote:
>> [...]
>>>>> [...]
>>>>>
>>>>>>>> +    while (len) {
>>>>>>>> +        cmd = spi_nor_find_best_erase_cmd(map, region, addr, len);
>>>>>>>> +        if (!cmd)
>>>>>>>> +            return -EINVAL;
>>>>>>> What would happen if you realize mid-way that you cannot erase some
>>>>>>> sector , do you end up with partial erase ?
>>>>>> Is this possible? In non-overlaid regions, the address is aligned with
>>>>>> at least one of the erase commands, else -EINVAL. For overlaid regions
>>>>>> alignment doesn't matter. But yes, if this is possible, in this case,
>>>>>> this proposal will do a partial erase.
>>>>> Shouldn't we fail up front instead ?
>>>> It will be great if we can do this without having performance penalties.
>>>> Can we loose the conditions for the last erase command? If one wants to
>>>> erase 80k chunk starting from offset 0 and only 32k and 64k erase type
>>>> are supported, can we erase 96k?
>>> No. But can you maybe build a list of erase commands to be executed once
>>> you validate that the erase can be performed for example ?
>>
>> My second choice was an array witch saves u8 opcode and u32 erasesize.
>> There are flashes of 256MB, in the worst case scenario with 4k erase
>> type, we will end up with 64K entries.
> 
> Some RLE encoding might help here ?

Nice.

> 
>> How about enforcing the length to be multiple of mtd->erasesize, like we
>> do in uniform_erase? With this, the problem disappears.
> 
> What is the erase size for the 4k-sector 256MiB flash ?

S70FS01GS[1] is a 128 MByte flash with non-uniform erase support. It
supports 4k and 256k erase types. I would have to enforce the address
and the length to be multiple of 256k in order to vanish the issue. But
the whole point of non-uniform erase will vanish too, I guess.

I don't have any other good :) idea, so I'll implement your suggestion
with the list of erase commands and RLE encoding.

Thanks,
ta

[1] http://www.cypress.com/file/215911/download

      reply	other threads:[~2018-05-24  9:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-18  9:32 [RFC PATCH] mtd: spi-nor: add support to non-uniform SPI NOR flash memories Tudor Ambarus
2018-05-21 11:35 ` Marek Vasut
2018-05-21 16:42   ` Tudor Ambarus
2018-05-21 16:59     ` Marek Vasut
2018-05-22  5:01       ` Tudor Ambarus
2018-05-23  9:56         ` Marek Vasut
2018-05-23 12:52           ` Tudor Ambarus
2018-05-23 12:54             ` Marek Vasut
2018-05-24  9:32               ` Tudor Ambarus [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=d4e73ccb-58d2-f7fb-5303-15dc3dbd63aa@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=Cristian.Birsan@microchip.com \
    --cc=boris.brezillon@bootlin.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@microchip.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=nicolas.ferre@microchip.com \
    --cc=richard@nod.at \
    /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