All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.