From: Ryan Mallon <ryan@bluewatersys.com>
To: H Hartley Sweeten <hartleys@visionengravers.com>
Cc: Linus Walleij <linus.ml.walleij@gmail.com>,
linux kernel <linux-kernel@vger.kernel.org>,
linux-mtd@lists.infradead.org, mike@steroidmicros.com,
spi-devel-general@lists.sourceforge.net,
akpm@linux-foundation.org, David Woodhouse <dwmw2@infradead.org>
Subject: Re: [spi-devel-general] [PATCH] SST25L (non JEDEC) SPI Flash driver
Date: Thu, 25 Jun 2009 14:52:58 +1200 [thread overview]
Message-ID: <4A42E68A.3020702@bluewatersys.com> (raw)
In-Reply-To: <BD79186B4FD85F4B8E60E381CAEE1909019BE1D5@mi8nycmail19.Mi8.com>
H Hartley Sweeten wrote:
> On Wednesday, June 24, 2009 7:06 PM, Ryan Mallon wrote:
>> H Hartley Sweeten wrote:
>>> On Sunday, June 21, 2009 8:59 PM, Ryan Mallon wrote:
> I think you could still support the block erase and chip erase internal
> to the driver for performance. Maybe something like the following?
>
> static int sst25l_erase(struct mtd_info *mtd, struct erase_info *instr)
> {
...
> if (instr->len == mtd->size) {
> err = __sst25l_erase(flash, addr, SST25L_CMD_CHIP_ERASE);
> if (err) {
> mutex_unlock(&flash->lock);
> instr->state = MTD_ERASE_FAILED;
> dev_err(&flash->spi->dev, "Erase failed\n");
> return err;
> }
> } else {
> while (addr < end) {
> u32 erasesize;
>
> if (addr % block || addr + block > end) {
> erasesize = sector;
> err = __sst25l_erase(flash, addr,
> SST25L_CMD_SECTOR_ERASE);
> } else {
> erasesize = block;
> err = __sst25l_erase(flash, addr,
> SST25L_CMD_BLOCK_ERASE);
> }
> if (err) {
> mutex_unlock(&flash->lock);
> instr->state = MTD_ERASE_FAILED;
> dev_err(&flash->spi->dev, "Erase failed\n");
> return err;
> }
>
> addr += erasesize;
> }
> }
>
> You would need to add sector_size and block_size to the ss25l_flash
> and flash_info structs and modify flash_info as appropriate. Then copy
> those over during the probe and use sector_size for mtd.erasesize.
>
> That way we get the 4K erase size but still get the performance increase
> for block and chip erase.
We discussed this, but it adds additional complexity to what is
otherwise quite a simple driver. The 4K sector erase will work in all
cases, and the speed difference shouldn't be a massive problem. I would
venture a guess that most people using the chips have reasonably
non-volatile storage on them, and don't get erased very often. We use
ours for the Bootloader and boot environment.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon Unit 5, Amuri Park
Phone: +64 3 3779127 404 Barbadoes St
Fax: +64 3 3779135 PO Box 13 889
Email: ryan@bluewatersys.com Christchurch, 8013
Web: http://www.bluewatersys.com New Zealand
Freecall Australia 1800 148 751 USA 1800 261 2934
WARNING: multiple messages have this Message-ID (diff)
From: Ryan Mallon <ryan@bluewatersys.com>
To: H Hartley Sweeten <hartleys@visionengravers.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
linux-mtd@lists.infradead.org,
spi-devel-general@lists.sourceforge.net, mike@steroidmicros.com,
linux kernel <linux-kernel@vger.kernel.org>,
Linus Walleij <linus.ml.walleij@gmail.com>,
akpm@linux-foundation.org
Subject: Re: [spi-devel-general] [PATCH] SST25L (non JEDEC) SPI Flash driver
Date: Thu, 25 Jun 2009 14:52:58 +1200 [thread overview]
Message-ID: <4A42E68A.3020702@bluewatersys.com> (raw)
In-Reply-To: <BD79186B4FD85F4B8E60E381CAEE1909019BE1D5@mi8nycmail19.Mi8.com>
H Hartley Sweeten wrote:
> On Wednesday, June 24, 2009 7:06 PM, Ryan Mallon wrote:
>> H Hartley Sweeten wrote:
>>> On Sunday, June 21, 2009 8:59 PM, Ryan Mallon wrote:
> I think you could still support the block erase and chip erase internal
> to the driver for performance. Maybe something like the following?
>
> static int sst25l_erase(struct mtd_info *mtd, struct erase_info *instr)
> {
...
> if (instr->len == mtd->size) {
> err = __sst25l_erase(flash, addr, SST25L_CMD_CHIP_ERASE);
> if (err) {
> mutex_unlock(&flash->lock);
> instr->state = MTD_ERASE_FAILED;
> dev_err(&flash->spi->dev, "Erase failed\n");
> return err;
> }
> } else {
> while (addr < end) {
> u32 erasesize;
>
> if (addr % block || addr + block > end) {
> erasesize = sector;
> err = __sst25l_erase(flash, addr,
> SST25L_CMD_SECTOR_ERASE);
> } else {
> erasesize = block;
> err = __sst25l_erase(flash, addr,
> SST25L_CMD_BLOCK_ERASE);
> }
> if (err) {
> mutex_unlock(&flash->lock);
> instr->state = MTD_ERASE_FAILED;
> dev_err(&flash->spi->dev, "Erase failed\n");
> return err;
> }
>
> addr += erasesize;
> }
> }
>
> You would need to add sector_size and block_size to the ss25l_flash
> and flash_info structs and modify flash_info as appropriate. Then copy
> those over during the probe and use sector_size for mtd.erasesize.
>
> That way we get the 4K erase size but still get the performance increase
> for block and chip erase.
We discussed this, but it adds additional complexity to what is
otherwise quite a simple driver. The 4K sector erase will work in all
cases, and the speed difference shouldn't be a massive problem. I would
venture a guess that most people using the chips have reasonably
non-volatile storage on them, and don't get erased very often. We use
ours for the Bootloader and boot environment.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon Unit 5, Amuri Park
Phone: +64 3 3779127 404 Barbadoes St
Fax: +64 3 3779135 PO Box 13 889
Email: ryan@bluewatersys.com Christchurch, 8013
Web: http://www.bluewatersys.com New Zealand
Freecall Australia 1800 148 751 USA 1800 261 2934
next prev parent reply other threads:[~2009-06-25 2:50 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-22 3:58 [PATCH] SST25L (non JEDEC) SPI Flash driver Ryan Mallon
2009-06-22 4:14 ` [spi-devel-general] " Baruch Siach
2009-06-22 4:14 ` Baruch Siach
2009-06-22 4:25 ` Ryan Mallon
2009-06-22 4:25 ` Ryan Mallon
2009-06-22 8:15 ` Artem Bityutskiy
2009-06-22 8:15 ` Artem Bityutskiy
2009-06-22 8:22 ` Linus Walleij
2009-06-22 8:22 ` Linus Walleij
2009-06-22 21:56 ` Ryan Mallon
2009-06-22 21:56 ` Ryan Mallon
2009-06-23 7:04 ` Linus Walleij
2009-06-23 7:04 ` Linus Walleij
2009-06-23 20:48 ` Ryan Mallon
2009-06-23 20:48 ` Ryan Mallon
2009-06-24 22:43 ` Linus Walleij
2009-06-24 22:43 ` Linus Walleij
2009-06-24 22:49 ` Ryan Mallon
2009-06-24 22:49 ` Ryan Mallon
2009-06-24 23:49 ` Linus Walleij
2009-06-24 23:49 ` Linus Walleij
2009-06-25 1:39 ` [spi-devel-general] " H Hartley Sweeten
2009-06-25 1:39 ` H Hartley Sweeten
2009-06-25 2:06 ` Ryan Mallon
2009-06-25 2:06 ` Ryan Mallon
2009-06-25 2:30 ` H Hartley Sweeten
2009-06-25 2:30 ` H Hartley Sweeten
2009-06-25 2:52 ` Ryan Mallon [this message]
2009-06-25 2:52 ` Ryan Mallon
2009-06-25 7:49 ` Linus Walleij
2009-06-25 7:49 ` Linus Walleij
2009-06-25 7:49 ` Linus Walleij
-- strict thread matches above, loose matches on Subject: below --
2009-06-24 23:59 Ryan Mallon
2009-06-25 0:08 ` Linus Walleij
2009-07-03 0:50 ` [spi-devel-general] " David Brownell
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=4A42E68A.3020702@bluewatersys.com \
--to=ryan@bluewatersys.com \
--cc=akpm@linux-foundation.org \
--cc=dwmw2@infradead.org \
--cc=hartleys@visionengravers.com \
--cc=linus.ml.walleij@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mike@steroidmicros.com \
--cc=spi-devel-general@lists.sourceforge.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.