linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marek Vasut <marek.vasut@gmail.com>
To: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
	Cyrille Pitchen <cyrille.pitchen@atmel.com>
Cc: boris.brezillon@free-electrons.com, computersforpeace@gmail.com,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	richard@nod.at
Subject: Re: [PATCH 1/1] mtd: spi-nor: remove WARN_ONCE() message in spi_nor_write()
Date: Wed, 7 Dec 2016 04:07:05 +0100	[thread overview]
Message-ID: <7dd7fecc-7f03-659a-ef00-a1ad69daceca@gmail.com> (raw)
In-Reply-To: <0b871c04-c105-ec94-441c-481e9773f19e@wedev4u.fr>

On 12/07/2016 12:38 AM, Cyrille Pitchen wrote:
> Le 06/12/2016 à 20:00, Marek Vasut a écrit :
>> On 12/06/2016 06:14 PM, Cyrille Pitchen wrote:
>>> This patch removes the WARN_ONCE() test in spi_nor_write().
>>> This macro triggers the display of a warning message almost every time we
>>> use a UBI file-system because a write operation is performed at offset 64,
>>> which is in the middle of the SPI NOR memory page. This is a valid
>>> operation for ubifs.
>>
>> Is that a valid operation for all spi nors ?
>>
> 
> AFAIK, yes, it is. First we need to erase a sector or a block, then we
> can send page program commands to write data into the memory. We cannot
> write more than a page size within a single page program command but you
> can write less and start in the middle of a page if you want.

I wasn't aware this partial and even unaligned programming was available
on all chips, OK.

> I don't know whether we could cross the page boundary if we start
> writing from the middle of a page as long as we write less data than a
> single page size. However spi_nor_write() don't do so, this is why it
> computes
> page_remain = min_t(size_t, nor->page_size - page_offset, len - i)

No, I don't think we can, I believe the PP would wrap around and program
the same page from the beginning.

> Well, now looking at the Spansion S25FL127S datasheet, the address is
> wrapped if we cross the page boundary:

Yeah, this matches my mental model.

> "Depending on the device configuration, the page size can either be 256
> or 512 bytes. Up to a page can be provided on SI after the 3-byte
> address with instruction 02h or 4-byte address with instruction 12h has
> been provided. If the 9 least significant address bits (A8-A0) are not
> all 0, all transmitted data that goes beyond the end of the current page
> are programmed from the start address of the same page (from the address
> whose 9 least significant bits (A8-A0) are all 0) i.e. the address wraps
> within the page aligned address boundaries. This is a result of only
> requiring the user to enter one single page address to cover the entire
> page boundary."
> 
> Then from Adesto AT25DF321A datasheet:
> "If the starting memory address denoted by A23-A0 does not fall on an
> even 256-byte page boundary (A7-A0 are not all 0), then special
> circumstances regarding which memory locations to be programmed will
> apply. In this situation, any data that is sent to the device that goes
> beyond the end of the page will wrap around back to the beginning of the
> same page. For example, if the starting address denoted by A23-A0 is
> 0000FEh, and three bytes of data are sent to the device, then the first
> two bytes of data will be programmed at addresses 0000FEh and 0000FFh
> while the last byte of data will be programmed at address 000000h. The
> remaining bytes in the page (addresses 000001h through 0000FDh) will not
> be programmed and will remain in the erased state (FFh). In addition, if
> more than 256-bytes of data are sent to the device, then only the last
> 256-bytes sent will be latched into the internal buffer."
> 
> 
> Besides, the wear leveling is handled by the ubi layer I guess, at the
> spi-nor level we write raw data. Maybe Richard and Boris could tell us
> more but talking with them I've understood that's it is normal for the
> ubi layer to write at offset 64.

I'd understand RMW, but pure write seems a bit odd.


-- 
Best regards,
Marek Vasut

  reply	other threads:[~2016-12-07  5:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-06 17:14 [PATCH 1/1] mtd: spi-nor: remove WARN_ONCE() message in spi_nor_write() Cyrille Pitchen
2016-12-06 19:00 ` Marek Vasut
2016-12-06 23:38   ` Cyrille Pitchen
2016-12-07  3:07     ` Marek Vasut [this message]
2016-12-07  6:21       ` Krzeminski, Marcin (Nokia - PL/Wroclaw)
2016-12-07 13:07         ` Cyrille Pitchen
2016-12-07 13:50           ` Krzeminski, Marcin (Nokia - PL/Wroclaw)
2016-12-07  7:40       ` Boris Brezillon
2016-12-08 15:31 ` Boris Brezillon
2016-12-13 16:43   ` Cyrille Pitchen
2017-02-09  2:23     ` Brian Norris
2017-02-09 13:50       ` Cyrille Pitchen
2017-02-10 18:29         ` Brian Norris

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=7dd7fecc-7f03-659a-ef00-a1ad69daceca@gmail.com \
    --to=marek.vasut@gmail.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@atmel.com \
    --cc=cyrille.pitchen@wedev4u.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --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;
as well as URLs for NNTP newsgroup(s).