public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Richard Retanubun <RichardRetanubun@ruggedcom.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [U-boot] sf: API for spi_flash_get_sector_size
Date: Tue, 8 Feb 2011 10:33:04 -0500	[thread overview]
Message-ID: <4D516230.8090802@RuggedCom.com> (raw)
In-Reply-To: <20110208151925.0E54214B9A0D@gemini.denx.de>

On 02/08/11 10:19, Wolfgang Denk wrote:
> Dear Richard Retanubun,
>
> In message<4D515D06.7020209@RuggedCom.com>  you wrote:
>>
>> If by "how NOR flash in handled" you mean cmd_flash.c::flash_sect_roundb() then yes, I do want to do this
>> but I need to know what number to round it to, no?
>
> The code needs to know that, you don't ;-)
>
>> In the context of cmd_flash, it has access to flash_info_t
>> which contains the sector_size information. Also cfi_flash.c also provides a function called flash_sector_size()
>> that is called by other components that needs to know. If I have misunderstood what you mean, sorry, please clarify.
>
> You are right.

<sensing a wavering in your resolve> ;-)

Thus we come to my original question, in the same way that cfi_flash.c provides flash_sector_size();

I propose we add spi_flash.c::spi_flash_sector_size() which returns the same information so that other code
can validate (or round up if requested) the length of the operation to the nearest sector size.

right now (unless I misunderstood), there is no easy way to get the spi flash sector_size, no?

would this be acceptable?

>
>> To have SPI flash do this, for example; stmicro.c::stmicro_erase() function will auto round up to the nearest sector_size.
>> Which is indeed the simpler way. Right now, most drivers/mtd/spi/*.c just does this check:
>>
>> <quoted_code>
>> sector_size = stm->params->page_size * stm->params->pages_per_sector;
>>
>> if (offset % sector_size || len % sector_size) {
>> 	debug("SF: Erase offset/length not multiple of sector size\n");
>> 	return -1;
>> }
>> </quoted_code>
>
> This is ok if an explicit size is given - you will see the same
> behaviour on NOR flash when trying something like
>
> 	erase 40000000 40002345

Understood. So the spi flash driver erase function itself should only validate the args and not auto round up.
This means that the decision of [warn or auto-round-up] should be handled by other code that parses the user's commands
that is operating on spi flash.

To do this, they need a way to ask the spi flash driver what the sector size to round up to is.

>
>> I am worried about unintentionally erasing more than what the caller requested.
>> Would it be better to round up manually and then calls the erase?
>
> No.  If the caller uses the "+<size>" notation he explictly requests
> to round up.  He is supposed to know what he is doing.
>
> Being able to use "+${filesize}" allows for many powerful solutions
> to standard tasks that without this would result in cumbersome
> manipulation of the size - which would then probably break if you
> issue a new revision of your hardware with different flash chips fit.

This is a cool convention. Should we add this to "sf erase command?" if it is not there already.
if so, what command (or better yet, git commit) shows how to add handling of "+N"

Thanks!

- Richard

  reply	other threads:[~2011-02-08 15:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-08 14:13 [U-Boot] [U-boot] sf: API for spi_flash_get_sector_size Richard Retanubun
2011-02-08 14:40 ` Wolfgang Denk
2011-02-08 15:11   ` Richard Retanubun
2011-02-08 15:19     ` Wolfgang Denk
2011-02-08 15:33       ` Richard Retanubun [this message]
2011-02-09 21:16       ` [U-Boot] [PATCH] [RFC] SF: Add "sf erase offset +len" command handler Richard Retanubun
2011-02-15  9:34         ` Mike Frysinger
2011-02-16 20:27           ` [U-Boot] (no subject) Richard Retanubun
2011-02-17  5:46             ` Mike Frysinger
2011-02-16 20:27           ` [U-Boot] [PATCH 1/2] SPI: Add struct spi_flash.sector_size parameter Richard Retanubun
2011-02-16 21:00             ` Wolfgang Denk
2011-02-16 20:27           ` [U-Boot] [PATCH 2/2] cmd_sf: Add handler for +len arg for erase command Richard Retanubun
2011-02-16 21:06             ` Wolfgang Denk
2011-02-16 21:37               ` [U-Boot] [PATCH 1/2] SPI: Add struct spi_flash.sector_size parameter Richard Retanubun
2011-04-12  6:34                 ` Mike Frysinger
2011-02-16 21:39               ` [U-Boot] [PATCH 2/2] cmd_sf: Add handler for +len arg for erase command Richard Retanubun
2011-02-16 21:47             ` Scott Wood

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=4D516230.8090802@RuggedCom.com \
    --to=richardretanubun@ruggedcom.com \
    --cc=u-boot@lists.denx.de \
    /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