1
0
Fork 0
alistair23-linux/drivers/mtd/devices/m25p80.c

1359 lines
38 KiB
C
Raw Normal View History

/*
* MTD SPI driver for ST M25Pxx (and similar) serial flash chips
*
* Author: Mike Lavender, mike@steroidmicros.com
*
* Copyright (c) 2005, Intec Automation Inc.
*
* Some parts are based on lart.c by Abraham Van Der Merwe
*
* Cleaned up and generalized based on mtd_dataflash.c
*
* This code is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
*/
#include <linux/err.h>
#include <linux/errno.h>
#include <linux/module.h>
#include <linux/device.h>
#include <linux/interrupt.h>
#include <linux/mutex.h>
#include <linux/math64.h>
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 02:04:11 -06:00
#include <linux/slab.h>
#include <linux/sched.h>
#include <linux/mod_devicetable.h>
#include <linux/mtd/cfi.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
#include <linux/of_platform.h>
#include <linux/spi/spi.h>
#include <linux/spi/flash.h>
/* Flash opcodes. */
#define OPCODE_WREN 0x06 /* Write enable */
#define OPCODE_RDSR 0x05 /* Read status register */
#define OPCODE_WRSR 0x01 /* Write status register 1 byte */
#define OPCODE_NORM_READ 0x03 /* Read data bytes (low frequency) */
#define OPCODE_FAST_READ 0x0b /* Read data bytes (high frequency) */
#define OPCODE_DUAL_READ 0x3b /* Read data bytes (Dual SPI) */
#define OPCODE_QUAD_READ 0x6b /* Read data bytes (Quad SPI) */
#define OPCODE_PP 0x02 /* Page program (up to 256 bytes) */
#define OPCODE_BE_4K 0x20 /* Erase 4KiB block */
mtd: chips: Add support for PMC SPI Flash chips in m25p80.c Add support for PMC (now Chingis, part of ISSI) Pm25LV512 (512 Kib), Pm25LV010 (1 Mib) and Pm25LQ032 (32 Mib) SPI Flash chips. This patch addresses two generations of PMC SPI Flash chips: - Pm25LV512 and Pm25LV010: these have 4KiB sectors and 32KiB blocks. The 4KiB sector erase uses a non-standard opcode (0xd7). They do not support JEDEC RDID (0x9f), and so they can only be detected by matching their name string with pre-configured platform data. Because of the cascaded acquisitions, the datasheet is no longer available on the current manufacturer's website, although it is still commonly used in some recent wireless routers (<https://forum.openwrt.org/viewtopic.php?pid=186360#p186360>). The only public datasheet available seems to be on GeoCities: <http://www.geocities.jp/scottle556/pdf/Pm25LV512-010.pdf> - Pm25LQ032: a newer generation flash, with 4KiB sectors and 64KiB blocks. It uses the standard erase and JEDEC read-ID opcodes. Manufacturer's datasheet is here: <http://www.chingistek.com/img/Product_Files/Pm25LQ032C%20datasheet%20v1.6.1.pdf> This patch is resent in order to take into account both Brian Norris remarks and this upstream patch: commit e534ee4f9ca29fdb38eea4b0c53f2154fbd8c1ee Author: Krzysztof Mazur <krzysiek@podlesie.net> Date: Fri Feb 22 15:51:05 2013 +0100 mtd: m25p80: introduce SST_WRITE flag for SST byte programming Not all SST devices implement the SST byte programming command. Some devices (like SST25VF064C) implement only standard m25p80 page write command. Now SPI flash devices that need sst_write() are explicitly marked with new SST_WRITE flag and the decision to use sst_write() is based on this flag instead of manufacturer id. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: Michel Stempin <michel.stempin@wanadoo.fr> [Brian: fixed conflict] Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-07-15 04:13:56 -06:00
#define OPCODE_BE_4K_PMC 0xd7 /* Erase 4KiB block on PMC chips */
#define OPCODE_BE_32K 0x52 /* Erase 32KiB block */
#define OPCODE_CHIP_ERASE 0xc7 /* Erase whole flash chip */
#define OPCODE_SE 0xd8 /* Sector erase (usually 64KiB) */
#define OPCODE_RDID 0x9f /* Read JEDEC ID */
#define OPCODE_RDCR 0x35 /* Read configuration register */
mtd: m25p80: utilize dedicated 4-byte addressing commands Traditionally, the command set used by SPI flash only supported a 3-byte address. However, large SPI flash (>= 32MiB, or 256Mib) require 4 bytes to address the entire flash. Most manufacturers have supplied a mode switch (via a "bank register writer", or a "enable 4-byte mode" command), which tells the flash to expect 4 address cycles from now on, instead of 3. This mode remains until power is cut, the reset line is triggered (on packages where present), or a command is sent to reset the flash or to reset the 3-byte addressing mode. As an alternative, some flash manufacturers have developed a new command set that accept a full 4-byte address. They can be used orthogonally to any of the modes; that is, they can be used when the flash is in either 3-byte or 4-byte address mode. Now, there are a number of reasons why the "stateful" 4-byte address mode switch may not be acceptable. For instance, some SoC's perform a dumb boot sequence in which they only send 3-byte read commands to the flash. However, if an unexpected reset occurs, the flash chip cannot be guaranteed to return to its 3-byte mode. Thus, the SoC controller and flash will not understand each other. (One might consider hooking up the aforementioned reset pin to the system reset line so that any system reset will reset the flash to 3-byte mode, but some packages do not provide this pin. And in some other packages, one must choose between having a reset pin and having enough pins for 4-output QSPI support. It is an error prone process choosing a flash that will support a hardware reset pin!) This patch provides support for the new stateless command set, so that we can avoid the problems that come with a stateful addressing mode change. The flash can be left in "3-byte mode" while still accessing the entire flash. Note that Spansion supports this command set on all its large flash (e.g, S25FL512S), and Macronix has begun supporting this command set on some new flash (e.g., MX25L25635F). For the moment, I don't know how to differentiate the Macronix that don't support this command set (e.g., MX25L25635E) from those that do, so this patch only supports Spansion. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-04-11 02:34:57 -06:00
/* 4-byte address opcodes - used on Spansion and some Macronix flashes. */
#define OPCODE_NORM_READ_4B 0x13 /* Read data bytes (low frequency) */
#define OPCODE_FAST_READ_4B 0x0c /* Read data bytes (high frequency) */
#define OPCODE_DUAL_READ_4B 0x3c /* Read data bytes (Dual SPI) */
#define OPCODE_QUAD_READ_4B 0x6c /* Read data bytes (Quad SPI) */
mtd: m25p80: utilize dedicated 4-byte addressing commands Traditionally, the command set used by SPI flash only supported a 3-byte address. However, large SPI flash (>= 32MiB, or 256Mib) require 4 bytes to address the entire flash. Most manufacturers have supplied a mode switch (via a "bank register writer", or a "enable 4-byte mode" command), which tells the flash to expect 4 address cycles from now on, instead of 3. This mode remains until power is cut, the reset line is triggered (on packages where present), or a command is sent to reset the flash or to reset the 3-byte addressing mode. As an alternative, some flash manufacturers have developed a new command set that accept a full 4-byte address. They can be used orthogonally to any of the modes; that is, they can be used when the flash is in either 3-byte or 4-byte address mode. Now, there are a number of reasons why the "stateful" 4-byte address mode switch may not be acceptable. For instance, some SoC's perform a dumb boot sequence in which they only send 3-byte read commands to the flash. However, if an unexpected reset occurs, the flash chip cannot be guaranteed to return to its 3-byte mode. Thus, the SoC controller and flash will not understand each other. (One might consider hooking up the aforementioned reset pin to the system reset line so that any system reset will reset the flash to 3-byte mode, but some packages do not provide this pin. And in some other packages, one must choose between having a reset pin and having enough pins for 4-output QSPI support. It is an error prone process choosing a flash that will support a hardware reset pin!) This patch provides support for the new stateless command set, so that we can avoid the problems that come with a stateful addressing mode change. The flash can be left in "3-byte mode" while still accessing the entire flash. Note that Spansion supports this command set on all its large flash (e.g, S25FL512S), and Macronix has begun supporting this command set on some new flash (e.g., MX25L25635F). For the moment, I don't know how to differentiate the Macronix that don't support this command set (e.g., MX25L25635E) from those that do, so this patch only supports Spansion. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-04-11 02:34:57 -06:00
#define OPCODE_PP_4B 0x12 /* Page program (up to 256 bytes) */
#define OPCODE_SE_4B 0xdc /* Sector erase (usually 64KiB) */
/* Used for SST flashes only. */
#define OPCODE_BP 0x02 /* Byte program */
#define OPCODE_WRDI 0x04 /* Write disable */
#define OPCODE_AAI_WP 0xad /* Auto address increment word program */
/* Used for Macronix and Winbond flashes. */
#define OPCODE_EN4B 0xb7 /* Enter 4-byte mode */
#define OPCODE_EX4B 0xe9 /* Exit 4-byte mode */
/* Used for Spansion flashes only. */
#define OPCODE_BRWR 0x17 /* Bank register write */
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
/* meaning of other SR_* bits may differ between vendors */
#define SR_BP0 4 /* Block protect 0 */
#define SR_BP1 8 /* Block protect 1 */
#define SR_BP2 0x10 /* Block protect 2 */
#define SR_SRWD 0x80 /* SR write protect */
#define SR_QUAD_EN_MX 0x40 /* Macronix Quad I/O */
/* Configuration Register bits. */
#define CR_QUAD_EN_SPAN 0x2 /* Spansion Quad I/O */
/* Define max times to check status register before we give up. */
#define MAX_READY_WAIT_JIFFIES (40 * HZ) /* M25P16 specs 40s max chip erase */
#define MAX_CMD_SIZE 6
#define JEDEC_MFR(_jedec_id) ((_jedec_id) >> 16)
/****************************************************************************/
enum read_type {
M25P80_NORMAL = 0,
M25P80_FAST,
M25P80_DUAL,
M25P80_QUAD,
};
struct m25p {
struct spi_device *spi;
struct mutex lock;
struct mtd_info mtd;
u16 page_size;
u16 addr_width;
u8 erase_opcode;
mtd: m25p80: utilize dedicated 4-byte addressing commands Traditionally, the command set used by SPI flash only supported a 3-byte address. However, large SPI flash (>= 32MiB, or 256Mib) require 4 bytes to address the entire flash. Most manufacturers have supplied a mode switch (via a "bank register writer", or a "enable 4-byte mode" command), which tells the flash to expect 4 address cycles from now on, instead of 3. This mode remains until power is cut, the reset line is triggered (on packages where present), or a command is sent to reset the flash or to reset the 3-byte addressing mode. As an alternative, some flash manufacturers have developed a new command set that accept a full 4-byte address. They can be used orthogonally to any of the modes; that is, they can be used when the flash is in either 3-byte or 4-byte address mode. Now, there are a number of reasons why the "stateful" 4-byte address mode switch may not be acceptable. For instance, some SoC's perform a dumb boot sequence in which they only send 3-byte read commands to the flash. However, if an unexpected reset occurs, the flash chip cannot be guaranteed to return to its 3-byte mode. Thus, the SoC controller and flash will not understand each other. (One might consider hooking up the aforementioned reset pin to the system reset line so that any system reset will reset the flash to 3-byte mode, but some packages do not provide this pin. And in some other packages, one must choose between having a reset pin and having enough pins for 4-output QSPI support. It is an error prone process choosing a flash that will support a hardware reset pin!) This patch provides support for the new stateless command set, so that we can avoid the problems that come with a stateful addressing mode change. The flash can be left in "3-byte mode" while still accessing the entire flash. Note that Spansion supports this command set on all its large flash (e.g, S25FL512S), and Macronix has begun supporting this command set on some new flash (e.g., MX25L25635F). For the moment, I don't know how to differentiate the Macronix that don't support this command set (e.g., MX25L25635E) from those that do, so this patch only supports Spansion. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-04-11 02:34:57 -06:00
u8 read_opcode;
u8 program_opcode;
u8 *command;
enum read_type flash_read;
};
static inline struct m25p *mtd_to_m25p(struct mtd_info *mtd)
{
return container_of(mtd, struct m25p, mtd);
}
/****************************************************************************/
/*
* Internal helper functions
*/
/*
* Read the status register, returning its value in the location
* Return the status register value.
* Returns negative if error occurred.
*/
static int read_sr(struct m25p *flash)
{
ssize_t retval;
u8 code = OPCODE_RDSR;
u8 val;
retval = spi_write_then_read(flash->spi, &code, 1, &val, 1);
if (retval < 0) {
dev_err(&flash->spi->dev, "error %d reading SR\n",
(int) retval);
return retval;
}
return val;
}
/*
* Read configuration register, returning its value in the
* location. Return the configuration register value.
* Returns negative if error occured.
*/
static int read_cr(struct m25p *flash)
{
u8 code = OPCODE_RDCR;
int ret;
u8 val;
ret = spi_write_then_read(flash->spi, &code, 1, &val, 1);
if (ret < 0) {
dev_err(&flash->spi->dev, "error %d reading CR\n", ret);
return ret;
}
return val;
}
/*
* Write status register 1 byte
* Returns negative if error occurred.
*/
static int write_sr(struct m25p *flash, u8 val)
{
flash->command[0] = OPCODE_WRSR;
flash->command[1] = val;
return spi_write(flash->spi, flash->command, 2);
}
/*
* Set write enable latch with Write Enable command.
* Returns negative if error occurred.
*/
static inline int write_enable(struct m25p *flash)
{
u8 code = OPCODE_WREN;
return spi_write_then_read(flash->spi, &code, 1, NULL, 0);
}
/*
* Send write disble instruction to the chip.
*/
static inline int write_disable(struct m25p *flash)
{
u8 code = OPCODE_WRDI;
return spi_write_then_read(flash->spi, &code, 1, NULL, 0);
}
/*
* Enable/disable 4-byte addressing mode.
*/
static inline int set_4byte(struct m25p *flash, u32 jedec_id, int enable)
{
int status;
bool need_wren = false;
switch (JEDEC_MFR(jedec_id)) {
2013-08-17 13:16:29 -06:00
case CFI_MFR_ST: /* Micron, actually */
/* Some Micron need WREN command; all will accept it */
need_wren = true;
case CFI_MFR_MACRONIX:
case 0xEF /* winbond */:
if (need_wren)
write_enable(flash);
flash->command[0] = enable ? OPCODE_EN4B : OPCODE_EX4B;
status = spi_write(flash->spi, flash->command, 1);
if (need_wren)
write_disable(flash);
return status;
default:
/* Spansion style */
flash->command[0] = OPCODE_BRWR;
flash->command[1] = enable << 7;
return spi_write(flash->spi, flash->command, 2);
}
}
/*
* Service routine to read status register until ready, or timeout occurs.
* Returns non-zero if error.
*/
static int wait_till_ready(struct m25p *flash)
{
unsigned long deadline;
int sr;
deadline = jiffies + MAX_READY_WAIT_JIFFIES;
do {
if ((sr = read_sr(flash)) < 0)
break;
else if (!(sr & SR_WIP))
return 0;
cond_resched();
} while (!time_after_eq(jiffies, deadline));
return 1;
}
/*
* Write status Register and configuration register with 2 bytes
* The first byte will be written to the status register, while the
* second byte will be written to the configuration register.
* Return negative if error occured.
*/
static int write_sr_cr(struct m25p *flash, u16 val)
{
flash->command[0] = OPCODE_WRSR;
flash->command[1] = val & 0xff;
flash->command[2] = (val >> 8);
return spi_write(flash->spi, flash->command, 3);
}
static int macronix_quad_enable(struct m25p *flash)
{
int ret, val;
u8 cmd[2];
cmd[0] = OPCODE_WRSR;
val = read_sr(flash);
cmd[1] = val | SR_QUAD_EN_MX;
write_enable(flash);
spi_write(flash->spi, &cmd, 2);
if (wait_till_ready(flash))
return 1;
ret = read_sr(flash);
if (!(ret > 0 && (ret & SR_QUAD_EN_MX))) {
dev_err(&flash->spi->dev, "Macronix Quad bit not set\n");
return -EINVAL;
}
return 0;
}
static int spansion_quad_enable(struct m25p *flash)
{
int ret;
int quad_en = CR_QUAD_EN_SPAN << 8;
write_enable(flash);
ret = write_sr_cr(flash, quad_en);
if (ret < 0) {
dev_err(&flash->spi->dev,
"error while writing configuration register\n");
return -EINVAL;
}
/* read back and check it */
ret = read_cr(flash);
if (!(ret > 0 && (ret & CR_QUAD_EN_SPAN))) {
dev_err(&flash->spi->dev, "Spansion Quad bit not set\n");
return -EINVAL;
}
return 0;
}
static int set_quad_mode(struct m25p *flash, u32 jedec_id)
{
int status;
switch (JEDEC_MFR(jedec_id)) {
case CFI_MFR_MACRONIX:
status = macronix_quad_enable(flash);
if (status) {
dev_err(&flash->spi->dev,
"Macronix quad-read not enabled\n");
return -EINVAL;
}
return status;
default:
status = spansion_quad_enable(flash);
if (status) {
dev_err(&flash->spi->dev,
"Spansion quad-read not enabled\n");
return -EINVAL;
}
return status;
}
}
/*
* Erase the whole flash memory
*
* Returns 0 if successful, non-zero otherwise.
*/
static int erase_chip(struct m25p *flash)
{
pr_debug("%s: %s %lldKiB\n", dev_name(&flash->spi->dev), __func__,
(long long)(flash->mtd.size >> 10));
/* Wait until finished previous write command. */
if (wait_till_ready(flash))
return 1;
/* Send write enable, then erase commands. */
write_enable(flash);
/* Set up command buffer. */
flash->command[0] = OPCODE_CHIP_ERASE;
spi_write(flash->spi, flash->command, 1);
return 0;
}
static void m25p_addr2cmd(struct m25p *flash, unsigned int addr, u8 *cmd)
{
/* opcode is in cmd[0] */
cmd[1] = addr >> (flash->addr_width * 8 - 8);
cmd[2] = addr >> (flash->addr_width * 8 - 16);
cmd[3] = addr >> (flash->addr_width * 8 - 24);
cmd[4] = addr >> (flash->addr_width * 8 - 32);
}
static int m25p_cmdsz(struct m25p *flash)
{
return 1 + flash->addr_width;
}
/*
* Erase one sector of flash memory at offset ``offset'' which is any
* address within the sector which should be erased.
*
* Returns 0 if successful, non-zero otherwise.
*/
static int erase_sector(struct m25p *flash, u32 offset)
{
pr_debug("%s: %s %dKiB at 0x%08x\n", dev_name(&flash->spi->dev),
__func__, flash->mtd.erasesize / 1024, offset);
/* Wait until finished previous write command. */
if (wait_till_ready(flash))
return 1;
/* Send write enable, then erase commands. */
write_enable(flash);
/* Set up command buffer. */
flash->command[0] = flash->erase_opcode;
m25p_addr2cmd(flash, offset, flash->command);
spi_write(flash->spi, flash->command, m25p_cmdsz(flash));
return 0;
}
/****************************************************************************/
/*
* MTD implementation
*/
/*
* Erase an address range on the flash chip. The address range may extend
* one or more erase sectors. Return an error is there is a problem erasing.
*/
static int m25p80_erase(struct mtd_info *mtd, struct erase_info *instr)
{
struct m25p *flash = mtd_to_m25p(mtd);
u32 addr,len;
uint32_t rem;
pr_debug("%s: %s at 0x%llx, len %lld\n", dev_name(&flash->spi->dev),
__func__, (long long)instr->addr,
(long long)instr->len);
div_u64_rem(instr->len, mtd->erasesize, &rem);
if (rem)
return -EINVAL;
addr = instr->addr;
len = instr->len;
mutex_lock(&flash->lock);
/* whole-chip erase? */
if (len == flash->mtd.size) {
if (erase_chip(flash)) {
instr->state = MTD_ERASE_FAILED;
mutex_unlock(&flash->lock);
return -EIO;
}
/* REVISIT in some cases we could speed up erasing large regions
* by using OPCODE_SE instead of OPCODE_BE_4K. We may have set up
* to use "small sector erase", but that's not always optimal.
*/
/* "sector"-at-a-time erase */
} else {
while (len) {
if (erase_sector(flash, addr)) {
instr->state = MTD_ERASE_FAILED;
mutex_unlock(&flash->lock);
return -EIO;
}
addr += mtd->erasesize;
len -= mtd->erasesize;
}
}
mutex_unlock(&flash->lock);
instr->state = MTD_ERASE_DONE;
mtd_erase_callback(instr);
return 0;
}
/*
* Dummy Cycle calculation for different type of read.
* It can be used to support more commands with
* different dummy cycle requirements.
*/
static inline int m25p80_dummy_cycles_read(struct m25p *flash)
{
switch (flash->flash_read) {
case M25P80_FAST:
case M25P80_DUAL:
case M25P80_QUAD:
return 1;
case M25P80_NORMAL:
return 0;
default:
dev_err(&flash->spi->dev, "No valid read type supported\n");
return -1;
}
}
static inline unsigned int m25p80_rx_nbits(const struct m25p *flash)
{
switch (flash->flash_read) {
case M25P80_DUAL:
return 2;
case M25P80_QUAD:
return 4;
default:
return 0;
}
}
/*
* Read an address range from the flash chip. The address range
* may be any size provided it is within the physical boundaries.
*/
static int m25p80_read(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, u_char *buf)
{
struct m25p *flash = mtd_to_m25p(mtd);
struct spi_transfer t[2];
struct spi_message m;
uint8_t opcode;
int dummy;
pr_debug("%s: %s from 0x%08x, len %zd\n", dev_name(&flash->spi->dev),
__func__, (u32)from, len);
spi_message_init(&m);
memset(t, 0, (sizeof t));
dummy = m25p80_dummy_cycles_read(flash);
if (dummy < 0) {
dev_err(&flash->spi->dev, "No valid read command supported\n");
return -EINVAL;
}
t[0].tx_buf = flash->command;
t[0].len = m25p_cmdsz(flash) + dummy;
spi_message_add_tail(&t[0], &m);
t[1].rx_buf = buf;
t[1].rx_nbits = m25p80_rx_nbits(flash);
t[1].len = len;
spi_message_add_tail(&t[1], &m);
mutex_lock(&flash->lock);
/* Wait till previous write/erase is done. */
if (wait_till_ready(flash)) {
/* REVISIT status return?? */
mutex_unlock(&flash->lock);
return 1;
}
/* Set up the write data buffer. */
mtd: m25p80: utilize dedicated 4-byte addressing commands Traditionally, the command set used by SPI flash only supported a 3-byte address. However, large SPI flash (>= 32MiB, or 256Mib) require 4 bytes to address the entire flash. Most manufacturers have supplied a mode switch (via a "bank register writer", or a "enable 4-byte mode" command), which tells the flash to expect 4 address cycles from now on, instead of 3. This mode remains until power is cut, the reset line is triggered (on packages where present), or a command is sent to reset the flash or to reset the 3-byte addressing mode. As an alternative, some flash manufacturers have developed a new command set that accept a full 4-byte address. They can be used orthogonally to any of the modes; that is, they can be used when the flash is in either 3-byte or 4-byte address mode. Now, there are a number of reasons why the "stateful" 4-byte address mode switch may not be acceptable. For instance, some SoC's perform a dumb boot sequence in which they only send 3-byte read commands to the flash. However, if an unexpected reset occurs, the flash chip cannot be guaranteed to return to its 3-byte mode. Thus, the SoC controller and flash will not understand each other. (One might consider hooking up the aforementioned reset pin to the system reset line so that any system reset will reset the flash to 3-byte mode, but some packages do not provide this pin. And in some other packages, one must choose between having a reset pin and having enough pins for 4-output QSPI support. It is an error prone process choosing a flash that will support a hardware reset pin!) This patch provides support for the new stateless command set, so that we can avoid the problems that come with a stateful addressing mode change. The flash can be left in "3-byte mode" while still accessing the entire flash. Note that Spansion supports this command set on all its large flash (e.g, S25FL512S), and Macronix has begun supporting this command set on some new flash (e.g., MX25L25635F). For the moment, I don't know how to differentiate the Macronix that don't support this command set (e.g., MX25L25635E) from those that do, so this patch only supports Spansion. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-04-11 02:34:57 -06:00
opcode = flash->read_opcode;
flash->command[0] = opcode;
m25p_addr2cmd(flash, from, flash->command);
spi_sync(flash->spi, &m);
*retlen = m.actual_length - m25p_cmdsz(flash) - dummy;
mutex_unlock(&flash->lock);
return 0;
}
/*
* Write an address range to the flash chip. Data must be written in
* FLASH_PAGESIZE chunks. The address range may be any size provided
* it is within the physical boundaries.
*/
static int m25p80_write(struct mtd_info *mtd, loff_t to, size_t len,
size_t *retlen, const u_char *buf)
{
struct m25p *flash = mtd_to_m25p(mtd);
u32 page_offset, page_size;
struct spi_transfer t[2];
struct spi_message m;
pr_debug("%s: %s to 0x%08x, len %zd\n", dev_name(&flash->spi->dev),
__func__, (u32)to, len);
spi_message_init(&m);
memset(t, 0, (sizeof t));
t[0].tx_buf = flash->command;
t[0].len = m25p_cmdsz(flash);
spi_message_add_tail(&t[0], &m);
t[1].tx_buf = buf;
spi_message_add_tail(&t[1], &m);
mutex_lock(&flash->lock);
/* Wait until finished previous write command. */
if (wait_till_ready(flash)) {
mutex_unlock(&flash->lock);
return 1;
}
write_enable(flash);
/* Set up the opcode in the write buffer. */
mtd: m25p80: utilize dedicated 4-byte addressing commands Traditionally, the command set used by SPI flash only supported a 3-byte address. However, large SPI flash (>= 32MiB, or 256Mib) require 4 bytes to address the entire flash. Most manufacturers have supplied a mode switch (via a "bank register writer", or a "enable 4-byte mode" command), which tells the flash to expect 4 address cycles from now on, instead of 3. This mode remains until power is cut, the reset line is triggered (on packages where present), or a command is sent to reset the flash or to reset the 3-byte addressing mode. As an alternative, some flash manufacturers have developed a new command set that accept a full 4-byte address. They can be used orthogonally to any of the modes; that is, they can be used when the flash is in either 3-byte or 4-byte address mode. Now, there are a number of reasons why the "stateful" 4-byte address mode switch may not be acceptable. For instance, some SoC's perform a dumb boot sequence in which they only send 3-byte read commands to the flash. However, if an unexpected reset occurs, the flash chip cannot be guaranteed to return to its 3-byte mode. Thus, the SoC controller and flash will not understand each other. (One might consider hooking up the aforementioned reset pin to the system reset line so that any system reset will reset the flash to 3-byte mode, but some packages do not provide this pin. And in some other packages, one must choose between having a reset pin and having enough pins for 4-output QSPI support. It is an error prone process choosing a flash that will support a hardware reset pin!) This patch provides support for the new stateless command set, so that we can avoid the problems that come with a stateful addressing mode change. The flash can be left in "3-byte mode" while still accessing the entire flash. Note that Spansion supports this command set on all its large flash (e.g, S25FL512S), and Macronix has begun supporting this command set on some new flash (e.g., MX25L25635F). For the moment, I don't know how to differentiate the Macronix that don't support this command set (e.g., MX25L25635E) from those that do, so this patch only supports Spansion. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-04-11 02:34:57 -06:00
flash->command[0] = flash->program_opcode;
m25p_addr2cmd(flash, to, flash->command);
page_offset = to & (flash->page_size - 1);
/* do all the bytes fit onto one page? */
if (page_offset + len <= flash->page_size) {
t[1].len = len;
spi_sync(flash->spi, &m);
*retlen = m.actual_length - m25p_cmdsz(flash);
} else {
u32 i;
/* the size of data remaining on the first page */
page_size = flash->page_size - page_offset;
t[1].len = page_size;
spi_sync(flash->spi, &m);
*retlen = m.actual_length - m25p_cmdsz(flash);
/* write everything in flash->page_size chunks */
for (i = page_size; i < len; i += page_size) {
page_size = len - i;
if (page_size > flash->page_size)
page_size = flash->page_size;
/* write the next page to flash */
m25p_addr2cmd(flash, to + i, flash->command);
t[1].tx_buf = buf + i;
t[1].len = page_size;
wait_till_ready(flash);
write_enable(flash);
spi_sync(flash->spi, &m);
*retlen += m.actual_length - m25p_cmdsz(flash);
}
}
mutex_unlock(&flash->lock);
return 0;
}
static int sst_write(struct mtd_info *mtd, loff_t to, size_t len,
size_t *retlen, const u_char *buf)
{
struct m25p *flash = mtd_to_m25p(mtd);
struct spi_transfer t[2];
struct spi_message m;
size_t actual;
int cmd_sz, ret;
pr_debug("%s: %s to 0x%08x, len %zd\n", dev_name(&flash->spi->dev),
__func__, (u32)to, len);
spi_message_init(&m);
memset(t, 0, (sizeof t));
t[0].tx_buf = flash->command;
t[0].len = m25p_cmdsz(flash);
spi_message_add_tail(&t[0], &m);
t[1].tx_buf = buf;
spi_message_add_tail(&t[1], &m);
mutex_lock(&flash->lock);
/* Wait until finished previous write command. */
ret = wait_till_ready(flash);
if (ret)
goto time_out;
write_enable(flash);
actual = to % 2;
/* Start write from odd address. */
if (actual) {
flash->command[0] = OPCODE_BP;
m25p_addr2cmd(flash, to, flash->command);
/* write one byte. */
t[1].len = 1;
spi_sync(flash->spi, &m);
ret = wait_till_ready(flash);
if (ret)
goto time_out;
*retlen += m.actual_length - m25p_cmdsz(flash);
}
to += actual;
flash->command[0] = OPCODE_AAI_WP;
m25p_addr2cmd(flash, to, flash->command);
/* Write out most of the data here. */
cmd_sz = m25p_cmdsz(flash);
for (; actual < len - 1; actual += 2) {
t[0].len = cmd_sz;
/* write two bytes. */
t[1].len = 2;
t[1].tx_buf = buf + actual;
spi_sync(flash->spi, &m);
ret = wait_till_ready(flash);
if (ret)
goto time_out;
*retlen += m.actual_length - cmd_sz;
cmd_sz = 1;
to += 2;
}
write_disable(flash);
ret = wait_till_ready(flash);
if (ret)
goto time_out;
/* Write out trailing byte if it exists. */
if (actual != len) {
write_enable(flash);
flash->command[0] = OPCODE_BP;
m25p_addr2cmd(flash, to, flash->command);
t[0].len = m25p_cmdsz(flash);
t[1].len = 1;
t[1].tx_buf = buf + actual;
spi_sync(flash->spi, &m);
ret = wait_till_ready(flash);
if (ret)
goto time_out;
*retlen += m.actual_length - m25p_cmdsz(flash);
write_disable(flash);
}
time_out:
mutex_unlock(&flash->lock);
return ret;
}
static int m25p80_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
{
struct m25p *flash = mtd_to_m25p(mtd);
uint32_t offset = ofs;
uint8_t status_old, status_new;
int res = 0;
mutex_lock(&flash->lock);
/* Wait until finished previous command */
if (wait_till_ready(flash)) {
res = 1;
goto err;
}
status_old = read_sr(flash);
if (offset < flash->mtd.size-(flash->mtd.size/2))
status_new = status_old | SR_BP2 | SR_BP1 | SR_BP0;
else if (offset < flash->mtd.size-(flash->mtd.size/4))
status_new = (status_old & ~SR_BP0) | SR_BP2 | SR_BP1;
else if (offset < flash->mtd.size-(flash->mtd.size/8))
status_new = (status_old & ~SR_BP1) | SR_BP2 | SR_BP0;
else if (offset < flash->mtd.size-(flash->mtd.size/16))
status_new = (status_old & ~(SR_BP0|SR_BP1)) | SR_BP2;
else if (offset < flash->mtd.size-(flash->mtd.size/32))
status_new = (status_old & ~SR_BP2) | SR_BP1 | SR_BP0;
else if (offset < flash->mtd.size-(flash->mtd.size/64))
status_new = (status_old & ~(SR_BP2|SR_BP0)) | SR_BP1;
else
status_new = (status_old & ~(SR_BP2|SR_BP1)) | SR_BP0;
/* Only modify protection if it will not unlock other areas */
if ((status_new&(SR_BP2|SR_BP1|SR_BP0)) >
(status_old&(SR_BP2|SR_BP1|SR_BP0))) {
write_enable(flash);
if (write_sr(flash, status_new) < 0) {
res = 1;
goto err;
}
}
err: mutex_unlock(&flash->lock);
return res;
}
static int m25p80_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
{
struct m25p *flash = mtd_to_m25p(mtd);
uint32_t offset = ofs;
uint8_t status_old, status_new;
int res = 0;
mutex_lock(&flash->lock);
/* Wait until finished previous command */
if (wait_till_ready(flash)) {
res = 1;
goto err;
}
status_old = read_sr(flash);
if (offset+len > flash->mtd.size-(flash->mtd.size/64))
status_new = status_old & ~(SR_BP2|SR_BP1|SR_BP0);
else if (offset+len > flash->mtd.size-(flash->mtd.size/32))
status_new = (status_old & ~(SR_BP2|SR_BP1)) | SR_BP0;
else if (offset+len > flash->mtd.size-(flash->mtd.size/16))
status_new = (status_old & ~(SR_BP2|SR_BP0)) | SR_BP1;
else if (offset+len > flash->mtd.size-(flash->mtd.size/8))
status_new = (status_old & ~SR_BP2) | SR_BP1 | SR_BP0;
else if (offset+len > flash->mtd.size-(flash->mtd.size/4))
status_new = (status_old & ~(SR_BP0|SR_BP1)) | SR_BP2;
else if (offset+len > flash->mtd.size-(flash->mtd.size/2))
status_new = (status_old & ~SR_BP1) | SR_BP2 | SR_BP0;
else
status_new = (status_old & ~SR_BP0) | SR_BP2 | SR_BP1;
/* Only modify protection if it will not lock other areas */
if ((status_new&(SR_BP2|SR_BP1|SR_BP0)) <
(status_old&(SR_BP2|SR_BP1|SR_BP0))) {
write_enable(flash);
if (write_sr(flash, status_new) < 0) {
res = 1;
goto err;
}
}
err: mutex_unlock(&flash->lock);
return res;
}
/****************************************************************************/
/*
* SPI device driver setup and teardown
*/
struct flash_info {
/* JEDEC id zero means "no ID" (most older chips); otherwise it has
* a high byte of zero plus three data bytes: the manufacturer id,
* then a two byte device id.
*/
u32 jedec_id;
u16 ext_id;
/* The size listed here is what works with OPCODE_SE, which isn't
* necessarily called a "sector" by the vendor.
*/
unsigned sector_size;
u16 n_sectors;
u16 page_size;
u16 addr_width;
u16 flags;
#define SECT_4K 0x01 /* OPCODE_BE_4K works uniformly */
#define M25P_NO_ERASE 0x02 /* No erase command needed */
#define SST_WRITE 0x04 /* use SST byte programming */
#define M25P_NO_FR 0x08 /* Can't do fastread */
mtd: chips: Add support for PMC SPI Flash chips in m25p80.c Add support for PMC (now Chingis, part of ISSI) Pm25LV512 (512 Kib), Pm25LV010 (1 Mib) and Pm25LQ032 (32 Mib) SPI Flash chips. This patch addresses two generations of PMC SPI Flash chips: - Pm25LV512 and Pm25LV010: these have 4KiB sectors and 32KiB blocks. The 4KiB sector erase uses a non-standard opcode (0xd7). They do not support JEDEC RDID (0x9f), and so they can only be detected by matching their name string with pre-configured platform data. Because of the cascaded acquisitions, the datasheet is no longer available on the current manufacturer's website, although it is still commonly used in some recent wireless routers (<https://forum.openwrt.org/viewtopic.php?pid=186360#p186360>). The only public datasheet available seems to be on GeoCities: <http://www.geocities.jp/scottle556/pdf/Pm25LV512-010.pdf> - Pm25LQ032: a newer generation flash, with 4KiB sectors and 64KiB blocks. It uses the standard erase and JEDEC read-ID opcodes. Manufacturer's datasheet is here: <http://www.chingistek.com/img/Product_Files/Pm25LQ032C%20datasheet%20v1.6.1.pdf> This patch is resent in order to take into account both Brian Norris remarks and this upstream patch: commit e534ee4f9ca29fdb38eea4b0c53f2154fbd8c1ee Author: Krzysztof Mazur <krzysiek@podlesie.net> Date: Fri Feb 22 15:51:05 2013 +0100 mtd: m25p80: introduce SST_WRITE flag for SST byte programming Not all SST devices implement the SST byte programming command. Some devices (like SST25VF064C) implement only standard m25p80 page write command. Now SPI flash devices that need sst_write() are explicitly marked with new SST_WRITE flag and the decision to use sst_write() is based on this flag instead of manufacturer id. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: Michel Stempin <michel.stempin@wanadoo.fr> [Brian: fixed conflict] Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-07-15 04:13:56 -06:00
#define SECT_4K_PMC 0x10 /* OPCODE_BE_4K_PMC works uniformly */
#define M25P80_DUAL_READ 0x20 /* Flash supports Dual Read */
#define M25P80_QUAD_READ 0x40 /* Flash supports Quad Read */
};
#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
((kernel_ulong_t)&(struct flash_info) { \
.jedec_id = (_jedec_id), \
.ext_id = (_ext_id), \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
.page_size = 256, \
.flags = (_flags), \
})
#define CAT25_INFO(_sector_size, _n_sectors, _page_size, _addr_width, _flags) \
((kernel_ulong_t)&(struct flash_info) { \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
.page_size = (_page_size), \
.addr_width = (_addr_width), \
.flags = (_flags), \
})
/* NOTE: double check command sets and memory organization when you add
* more flash chips. This current list focusses on newer chips, which
* have been converging on command sets which including JEDEC ID.
*/
static const struct spi_device_id m25p_ids[] = {
/* Atmel -- some are (confusingly) marketed as "DataFlash" */
{ "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
{ "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
{ "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K) },
{ "at25df321a", INFO(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
{ "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K) },
{ "at26f004", INFO(0x1f0400, 0, 64 * 1024, 8, SECT_4K) },
{ "at26df081a", INFO(0x1f4501, 0, 64 * 1024, 16, SECT_4K) },
{ "at26df161a", INFO(0x1f4601, 0, 64 * 1024, 32, SECT_4K) },
{ "at26df321", INFO(0x1f4700, 0, 64 * 1024, 64, SECT_4K) },
{ "at45db081d", INFO(0x1f2500, 0, 64 * 1024, 16, SECT_4K) },
/* EON -- en25xxx */
{ "en25f32", INFO(0x1c3116, 0, 64 * 1024, 64, SECT_4K) },
{ "en25p32", INFO(0x1c2016, 0, 64 * 1024, 64, 0) },
{ "en25q32b", INFO(0x1c3016, 0, 64 * 1024, 64, 0) },
{ "en25p64", INFO(0x1c2017, 0, 64 * 1024, 128, 0) },
{ "en25q64", INFO(0x1c3017, 0, 64 * 1024, 128, SECT_4K) },
{ "en25qh256", INFO(0x1c7019, 0, 64 * 1024, 512, 0) },
/* ESMT */
{ "f25l32pa", INFO(0x8c2016, 0, 64 * 1024, 64, SECT_4K) },
/* Everspin */
{ "mr25h256", CAT25_INFO( 32 * 1024, 1, 256, 2, M25P_NO_ERASE | M25P_NO_FR) },
{ "mr25h10", CAT25_INFO(128 * 1024, 1, 256, 3, M25P_NO_ERASE | M25P_NO_FR) },
/* GigaDevice */
{ "gd25q32", INFO(0xc84016, 0, 64 * 1024, 64, SECT_4K) },
{ "gd25q64", INFO(0xc84017, 0, 64 * 1024, 128, SECT_4K) },
/* Intel/Numonyx -- xxxs33b */
{ "160s33b", INFO(0x898911, 0, 64 * 1024, 32, 0) },
{ "320s33b", INFO(0x898912, 0, 64 * 1024, 64, 0) },
{ "640s33b", INFO(0x898913, 0, 64 * 1024, 128, 0) },
/* Macronix */
{ "mx25l2005a", INFO(0xc22012, 0, 64 * 1024, 4, SECT_4K) },
{ "mx25l4005a", INFO(0xc22013, 0, 64 * 1024, 8, SECT_4K) },
{ "mx25l8005", INFO(0xc22014, 0, 64 * 1024, 16, 0) },
{ "mx25l1606e", INFO(0xc22015, 0, 64 * 1024, 32, SECT_4K) },
{ "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, 0) },
{ "mx25l3255e", INFO(0xc29e16, 0, 64 * 1024, 64, SECT_4K) },
{ "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, 0) },
{ "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
{ "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 0) },
{ "mx25l25635e", INFO(0xc22019, 0, 64 * 1024, 512, 0) },
{ "mx25l25655e", INFO(0xc22619, 0, 64 * 1024, 512, 0) },
{ "mx66l51235l", INFO(0xc2201a, 0, 64 * 1024, 1024, M25P80_QUAD_READ) },
{ "mx66l1g55g", INFO(0xc2261b, 0, 64 * 1024, 2048, M25P80_QUAD_READ) },
/* Micron */
{ "n25q064", INFO(0x20ba17, 0, 64 * 1024, 128, 0) },
{ "n25q128a11", INFO(0x20bb18, 0, 64 * 1024, 256, 0) },
{ "n25q128a13", INFO(0x20ba18, 0, 64 * 1024, 256, 0) },
{ "n25q256a", INFO(0x20ba19, 0, 64 * 1024, 512, SECT_4K) },
{ "n25q512a", INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
mtd: chips: Add support for PMC SPI Flash chips in m25p80.c Add support for PMC (now Chingis, part of ISSI) Pm25LV512 (512 Kib), Pm25LV010 (1 Mib) and Pm25LQ032 (32 Mib) SPI Flash chips. This patch addresses two generations of PMC SPI Flash chips: - Pm25LV512 and Pm25LV010: these have 4KiB sectors and 32KiB blocks. The 4KiB sector erase uses a non-standard opcode (0xd7). They do not support JEDEC RDID (0x9f), and so they can only be detected by matching their name string with pre-configured platform data. Because of the cascaded acquisitions, the datasheet is no longer available on the current manufacturer's website, although it is still commonly used in some recent wireless routers (<https://forum.openwrt.org/viewtopic.php?pid=186360#p186360>). The only public datasheet available seems to be on GeoCities: <http://www.geocities.jp/scottle556/pdf/Pm25LV512-010.pdf> - Pm25LQ032: a newer generation flash, with 4KiB sectors and 64KiB blocks. It uses the standard erase and JEDEC read-ID opcodes. Manufacturer's datasheet is here: <http://www.chingistek.com/img/Product_Files/Pm25LQ032C%20datasheet%20v1.6.1.pdf> This patch is resent in order to take into account both Brian Norris remarks and this upstream patch: commit e534ee4f9ca29fdb38eea4b0c53f2154fbd8c1ee Author: Krzysztof Mazur <krzysiek@podlesie.net> Date: Fri Feb 22 15:51:05 2013 +0100 mtd: m25p80: introduce SST_WRITE flag for SST byte programming Not all SST devices implement the SST byte programming command. Some devices (like SST25VF064C) implement only standard m25p80 page write command. Now SPI flash devices that need sst_write() are explicitly marked with new SST_WRITE flag and the decision to use sst_write() is based on this flag instead of manufacturer id. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: Michel Stempin <michel.stempin@wanadoo.fr> [Brian: fixed conflict] Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-07-15 04:13:56 -06:00
/* PMC */
{ "pm25lv512", INFO(0, 0, 32 * 1024, 2, SECT_4K_PMC) },
{ "pm25lv010", INFO(0, 0, 32 * 1024, 4, SECT_4K_PMC) },
{ "pm25lq032", INFO(0x7f9d46, 0, 64 * 1024, 64, SECT_4K) },
mtd: chips: Add support for PMC SPI Flash chips in m25p80.c Add support for PMC (now Chingis, part of ISSI) Pm25LV512 (512 Kib), Pm25LV010 (1 Mib) and Pm25LQ032 (32 Mib) SPI Flash chips. This patch addresses two generations of PMC SPI Flash chips: - Pm25LV512 and Pm25LV010: these have 4KiB sectors and 32KiB blocks. The 4KiB sector erase uses a non-standard opcode (0xd7). They do not support JEDEC RDID (0x9f), and so they can only be detected by matching their name string with pre-configured platform data. Because of the cascaded acquisitions, the datasheet is no longer available on the current manufacturer's website, although it is still commonly used in some recent wireless routers (<https://forum.openwrt.org/viewtopic.php?pid=186360#p186360>). The only public datasheet available seems to be on GeoCities: <http://www.geocities.jp/scottle556/pdf/Pm25LV512-010.pdf> - Pm25LQ032: a newer generation flash, with 4KiB sectors and 64KiB blocks. It uses the standard erase and JEDEC read-ID opcodes. Manufacturer's datasheet is here: <http://www.chingistek.com/img/Product_Files/Pm25LQ032C%20datasheet%20v1.6.1.pdf> This patch is resent in order to take into account both Brian Norris remarks and this upstream patch: commit e534ee4f9ca29fdb38eea4b0c53f2154fbd8c1ee Author: Krzysztof Mazur <krzysiek@podlesie.net> Date: Fri Feb 22 15:51:05 2013 +0100 mtd: m25p80: introduce SST_WRITE flag for SST byte programming Not all SST devices implement the SST byte programming command. Some devices (like SST25VF064C) implement only standard m25p80 page write command. Now SPI flash devices that need sst_write() are explicitly marked with new SST_WRITE flag and the decision to use sst_write() is based on this flag instead of manufacturer id. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: Michel Stempin <michel.stempin@wanadoo.fr> [Brian: fixed conflict] Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-07-15 04:13:56 -06:00
/* Spansion -- single (large) sector size only, at least
* for the chips listed here (without boot sectors).
*/
{ "s25sl032p", INFO(0x010215, 0x4d00, 64 * 1024, 64, 0) },
{ "s25sl064p", INFO(0x010216, 0x4d00, 64 * 1024, 128, 0) },
{ "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
{ "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512, M25P80_DUAL_READ | M25P80_QUAD_READ) },
{ "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256, M25P80_DUAL_READ | M25P80_QUAD_READ) },
{ "s70fl01gs", INFO(0x010221, 0x4d00, 256 * 1024, 256, 0) },
{ "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024, 64, 0) },
{ "s25sl12801", INFO(0x012018, 0x0301, 64 * 1024, 256, 0) },
{ "s25fl129p0", INFO(0x012018, 0x4d00, 256 * 1024, 64, 0) },
{ "s25fl129p1", INFO(0x012018, 0x4d01, 64 * 1024, 256, 0) },
{ "s25sl004a", INFO(0x010212, 0, 64 * 1024, 8, 0) },
{ "s25sl008a", INFO(0x010213, 0, 64 * 1024, 16, 0) },
{ "s25sl016a", INFO(0x010214, 0, 64 * 1024, 32, 0) },
{ "s25sl032a", INFO(0x010215, 0, 64 * 1024, 64, 0) },
{ "s25sl064a", INFO(0x010216, 0, 64 * 1024, 128, 0) },
{ "s25fl008k", INFO(0xef4014, 0, 64 * 1024, 16, SECT_4K) },
{ "s25fl016k", INFO(0xef4015, 0, 64 * 1024, 32, SECT_4K) },
{ "s25fl064k", INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) },
/* SST -- large erase sizes are "overlays", "sectors" are 4K */
{ "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE) },
{ "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) },
{ "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE) },
{ "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) },
{ "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, SECT_4K) },
{ "sst25wf512", INFO(0xbf2501, 0, 64 * 1024, 1, SECT_4K | SST_WRITE) },
{ "sst25wf010", INFO(0xbf2502, 0, 64 * 1024, 2, SECT_4K | SST_WRITE) },
{ "sst25wf020", INFO(0xbf2503, 0, 64 * 1024, 4, SECT_4K | SST_WRITE) },
{ "sst25wf040", INFO(0xbf2504, 0, 64 * 1024, 8, SECT_4K | SST_WRITE) },
/* ST Microelectronics -- newer production may have feature updates */
{ "m25p05", INFO(0x202010, 0, 32 * 1024, 2, 0) },
{ "m25p10", INFO(0x202011, 0, 32 * 1024, 4, 0) },
{ "m25p20", INFO(0x202012, 0, 64 * 1024, 4, 0) },
{ "m25p40", INFO(0x202013, 0, 64 * 1024, 8, 0) },
{ "m25p80", INFO(0x202014, 0, 64 * 1024, 16, 0) },
{ "m25p16", INFO(0x202015, 0, 64 * 1024, 32, 0) },
{ "m25p32", INFO(0x202016, 0, 64 * 1024, 64, 0) },
{ "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
{ "m25p128", INFO(0x202018, 0, 256 * 1024, 64, 0) },
{ "n25q032", INFO(0x20ba16, 0, 64 * 1024, 64, 0) },
{ "m25p05-nonjedec", INFO(0, 0, 32 * 1024, 2, 0) },
{ "m25p10-nonjedec", INFO(0, 0, 32 * 1024, 4, 0) },
{ "m25p20-nonjedec", INFO(0, 0, 64 * 1024, 4, 0) },
{ "m25p40-nonjedec", INFO(0, 0, 64 * 1024, 8, 0) },
{ "m25p80-nonjedec", INFO(0, 0, 64 * 1024, 16, 0) },
{ "m25p16-nonjedec", INFO(0, 0, 64 * 1024, 32, 0) },
{ "m25p32-nonjedec", INFO(0, 0, 64 * 1024, 64, 0) },
{ "m25p64-nonjedec", INFO(0, 0, 64 * 1024, 128, 0) },
{ "m25p128-nonjedec", INFO(0, 0, 256 * 1024, 64, 0) },
{ "m45pe10", INFO(0x204011, 0, 64 * 1024, 2, 0) },
{ "m45pe80", INFO(0x204014, 0, 64 * 1024, 16, 0) },
{ "m45pe16", INFO(0x204015, 0, 64 * 1024, 32, 0) },
{ "m25pe20", INFO(0x208012, 0, 64 * 1024, 4, 0) },
{ "m25pe80", INFO(0x208014, 0, 64 * 1024, 16, 0) },
{ "m25pe16", INFO(0x208015, 0, 64 * 1024, 32, SECT_4K) },
{ "m25px16", INFO(0x207115, 0, 64 * 1024, 32, SECT_4K) },
{ "m25px32", INFO(0x207116, 0, 64 * 1024, 64, SECT_4K) },
{ "m25px32-s0", INFO(0x207316, 0, 64 * 1024, 64, SECT_4K) },
{ "m25px32-s1", INFO(0x206316, 0, 64 * 1024, 64, SECT_4K) },
{ "m25px64", INFO(0x207117, 0, 64 * 1024, 128, 0) },
/* Winbond -- w25x "blocks" are 64K, "sectors" are 4KiB */
{ "w25x10", INFO(0xef3011, 0, 64 * 1024, 2, SECT_4K) },
{ "w25x20", INFO(0xef3012, 0, 64 * 1024, 4, SECT_4K) },
{ "w25x40", INFO(0xef3013, 0, 64 * 1024, 8, SECT_4K) },
{ "w25x80", INFO(0xef3014, 0, 64 * 1024, 16, SECT_4K) },
{ "w25x16", INFO(0xef3015, 0, 64 * 1024, 32, SECT_4K) },
{ "w25x32", INFO(0xef3016, 0, 64 * 1024, 64, SECT_4K) },
{ "w25q32", INFO(0xef4016, 0, 64 * 1024, 64, SECT_4K) },
{ "w25q32dw", INFO(0xef6016, 0, 64 * 1024, 64, SECT_4K) },
{ "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) },
{ "w25q64", INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) },
{ "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K) },
{ "w25q80", INFO(0xef5014, 0, 64 * 1024, 16, SECT_4K) },
{ "w25q80bl", INFO(0xef4014, 0, 64 * 1024, 16, SECT_4K) },
{ "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K) },
{ "w25q256", INFO(0xef4019, 0, 64 * 1024, 512, SECT_4K) },
/* Catalyst / On Semiconductor -- non-JEDEC */
{ "cat25c11", CAT25_INFO( 16, 8, 16, 1, M25P_NO_ERASE | M25P_NO_FR) },
{ "cat25c03", CAT25_INFO( 32, 8, 16, 2, M25P_NO_ERASE | M25P_NO_FR) },
{ "cat25c09", CAT25_INFO( 128, 8, 32, 2, M25P_NO_ERASE | M25P_NO_FR) },
{ "cat25c17", CAT25_INFO( 256, 8, 32, 2, M25P_NO_ERASE | M25P_NO_FR) },
{ "cat25128", CAT25_INFO(2048, 8, 64, 2, M25P_NO_ERASE | M25P_NO_FR) },
{ },
};
MODULE_DEVICE_TABLE(spi, m25p_ids);
static const struct spi_device_id *jedec_probe(struct spi_device *spi)
{
int tmp;
u8 code = OPCODE_RDID;
u8 id[5];
u32 jedec;
u16 ext_jedec;
struct flash_info *info;
/* JEDEC also defines an optional "extended device information"
* string for after vendor-specific data, after the three bytes
* we use here. Supporting some chips might require using it.
*/
tmp = spi_write_then_read(spi, &code, 1, id, 5);
if (tmp < 0) {
pr_debug("%s: error %d reading JEDEC ID\n",
dev_name(&spi->dev), tmp);
return ERR_PTR(tmp);
}
jedec = id[0];
jedec = jedec << 8;
jedec |= id[1];
jedec = jedec << 8;
jedec |= id[2];
ext_jedec = id[3] << 8 | id[4];
for (tmp = 0; tmp < ARRAY_SIZE(m25p_ids) - 1; tmp++) {
info = (void *)m25p_ids[tmp].driver_data;
if (info->jedec_id == jedec) {
if (info->ext_id == 0 || info->ext_id == ext_jedec)
return &m25p_ids[tmp];
}
}
dev_err(&spi->dev, "unrecognized JEDEC id %06x\n", jedec);
return ERR_PTR(-ENODEV);
}
/*
* board specific setup should have ensured the SPI clock used here
* matches what the READ command supports, at least until this driver
* understands FAST_READ (for clocks over 25 MHz).
*/
static int m25p_probe(struct spi_device *spi)
{
const struct spi_device_id *id = spi_get_device_id(spi);
struct flash_platform_data *data;
struct m25p *flash;
struct flash_info *info;
unsigned i;
struct mtd_part_parser_data ppdata;
struct device_node *np = spi->dev.of_node;
int ret;
/* Platform data helps sort out which chip type we have, as
* well as how this board partitions it. If we don't have
* a chip ID, try the JEDEC id commands; they'll work for most
* newer chips, even if we don't recognize the particular chip.
*/
data = dev_get_platdata(&spi->dev);
if (data && data->type) {
const struct spi_device_id *plat_id;
for (i = 0; i < ARRAY_SIZE(m25p_ids) - 1; i++) {
plat_id = &m25p_ids[i];
if (strcmp(data->type, plat_id->name))
continue;
break;
}
if (i < ARRAY_SIZE(m25p_ids) - 1)
id = plat_id;
else
dev_warn(&spi->dev, "unrecognized id %s\n", data->type);
}
info = (void *)id->driver_data;
if (info->jedec_id) {
const struct spi_device_id *jid;
jid = jedec_probe(spi);
if (IS_ERR(jid)) {
return PTR_ERR(jid);
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
* can't trust partitions any longer, but we'll let
* mtd apply them anyway, since some partitions may be
* marked read-only, and we don't want to lose that
* information, even if it's not 100% accurate.
*/
dev_warn(&spi->dev, "found %s, expected %s\n",
jid->name, id->name);
id = jid;
info = (void *)jid->driver_data;
}
}
flash = devm_kzalloc(&spi->dev, sizeof(*flash), GFP_KERNEL);
if (!flash)
return -ENOMEM;
flash->command = devm_kzalloc(&spi->dev, MAX_CMD_SIZE, GFP_KERNEL);
if (!flash->command)
return -ENOMEM;
flash->spi = spi;
mutex_init(&flash->lock);
spi_set_drvdata(spi, flash);
/*
* Atmel, SST and Intel/Numonyx serial flash tend to power
* up with the software protection bits set
*/
if (JEDEC_MFR(info->jedec_id) == CFI_MFR_ATMEL ||
JEDEC_MFR(info->jedec_id) == CFI_MFR_INTEL ||
JEDEC_MFR(info->jedec_id) == CFI_MFR_SST) {
write_enable(flash);
write_sr(flash, 0);
}
if (data && data->name)
flash->mtd.name = data->name;
else
flash->mtd.name = dev_name(&spi->dev);
flash->mtd.type = MTD_NORFLASH;
flash->mtd.writesize = 1;
flash->mtd.flags = MTD_CAP_NORFLASH;
flash->mtd.size = info->sector_size * info->n_sectors;
flash->mtd._erase = m25p80_erase;
flash->mtd._read = m25p80_read;
/* flash protection support for STmicro chips */
if (JEDEC_MFR(info->jedec_id) == CFI_MFR_ST) {
flash->mtd._lock = m25p80_lock;
flash->mtd._unlock = m25p80_unlock;
}
/* sst flash chips use AAI word program */
if (info->flags & SST_WRITE)
flash->mtd._write = sst_write;
else
flash->mtd._write = m25p80_write;
/* prefer "small sector" erase if possible */
if (info->flags & SECT_4K) {
flash->erase_opcode = OPCODE_BE_4K;
flash->mtd.erasesize = 4096;
mtd: chips: Add support for PMC SPI Flash chips in m25p80.c Add support for PMC (now Chingis, part of ISSI) Pm25LV512 (512 Kib), Pm25LV010 (1 Mib) and Pm25LQ032 (32 Mib) SPI Flash chips. This patch addresses two generations of PMC SPI Flash chips: - Pm25LV512 and Pm25LV010: these have 4KiB sectors and 32KiB blocks. The 4KiB sector erase uses a non-standard opcode (0xd7). They do not support JEDEC RDID (0x9f), and so they can only be detected by matching their name string with pre-configured platform data. Because of the cascaded acquisitions, the datasheet is no longer available on the current manufacturer's website, although it is still commonly used in some recent wireless routers (<https://forum.openwrt.org/viewtopic.php?pid=186360#p186360>). The only public datasheet available seems to be on GeoCities: <http://www.geocities.jp/scottle556/pdf/Pm25LV512-010.pdf> - Pm25LQ032: a newer generation flash, with 4KiB sectors and 64KiB blocks. It uses the standard erase and JEDEC read-ID opcodes. Manufacturer's datasheet is here: <http://www.chingistek.com/img/Product_Files/Pm25LQ032C%20datasheet%20v1.6.1.pdf> This patch is resent in order to take into account both Brian Norris remarks and this upstream patch: commit e534ee4f9ca29fdb38eea4b0c53f2154fbd8c1ee Author: Krzysztof Mazur <krzysiek@podlesie.net> Date: Fri Feb 22 15:51:05 2013 +0100 mtd: m25p80: introduce SST_WRITE flag for SST byte programming Not all SST devices implement the SST byte programming command. Some devices (like SST25VF064C) implement only standard m25p80 page write command. Now SPI flash devices that need sst_write() are explicitly marked with new SST_WRITE flag and the decision to use sst_write() is based on this flag instead of manufacturer id. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: Michel Stempin <michel.stempin@wanadoo.fr> [Brian: fixed conflict] Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-07-15 04:13:56 -06:00
} else if (info->flags & SECT_4K_PMC) {
flash->erase_opcode = OPCODE_BE_4K_PMC;
flash->mtd.erasesize = 4096;
} else {
flash->erase_opcode = OPCODE_SE;
flash->mtd.erasesize = info->sector_size;
}
if (info->flags & M25P_NO_ERASE)
flash->mtd.flags |= MTD_NO_ERASE;
ppdata.of_node = spi->dev.of_node;
flash->mtd.dev.parent = &spi->dev;
flash->page_size = info->page_size;
flash->mtd.writebufsize = flash->page_size;
if (np) {
/* If we were instantiated by DT, use it */
if (of_property_read_bool(np, "m25p,fast-read"))
flash->flash_read = M25P80_FAST;
else
flash->flash_read = M25P80_NORMAL;
} else {
/* If we weren't instantiated by DT, default to fast-read */
flash->flash_read = M25P80_FAST;
}
/* Some devices cannot do fast-read, no matter what DT tells us */
if (info->flags & M25P_NO_FR)
flash->flash_read = M25P80_NORMAL;
/* Quad/Dual-read mode takes precedence over fast/normal */
if (spi->mode & SPI_RX_QUAD && info->flags & M25P80_QUAD_READ) {
ret = set_quad_mode(flash, info->jedec_id);
if (ret) {
dev_err(&flash->spi->dev, "quad mode not supported\n");
return ret;
}
flash->flash_read = M25P80_QUAD;
} else if (spi->mode & SPI_RX_DUAL && info->flags & M25P80_DUAL_READ) {
flash->flash_read = M25P80_DUAL;
}
mtd: m25p80: utilize dedicated 4-byte addressing commands Traditionally, the command set used by SPI flash only supported a 3-byte address. However, large SPI flash (>= 32MiB, or 256Mib) require 4 bytes to address the entire flash. Most manufacturers have supplied a mode switch (via a "bank register writer", or a "enable 4-byte mode" command), which tells the flash to expect 4 address cycles from now on, instead of 3. This mode remains until power is cut, the reset line is triggered (on packages where present), or a command is sent to reset the flash or to reset the 3-byte addressing mode. As an alternative, some flash manufacturers have developed a new command set that accept a full 4-byte address. They can be used orthogonally to any of the modes; that is, they can be used when the flash is in either 3-byte or 4-byte address mode. Now, there are a number of reasons why the "stateful" 4-byte address mode switch may not be acceptable. For instance, some SoC's perform a dumb boot sequence in which they only send 3-byte read commands to the flash. However, if an unexpected reset occurs, the flash chip cannot be guaranteed to return to its 3-byte mode. Thus, the SoC controller and flash will not understand each other. (One might consider hooking up the aforementioned reset pin to the system reset line so that any system reset will reset the flash to 3-byte mode, but some packages do not provide this pin. And in some other packages, one must choose between having a reset pin and having enough pins for 4-output QSPI support. It is an error prone process choosing a flash that will support a hardware reset pin!) This patch provides support for the new stateless command set, so that we can avoid the problems that come with a stateful addressing mode change. The flash can be left in "3-byte mode" while still accessing the entire flash. Note that Spansion supports this command set on all its large flash (e.g, S25FL512S), and Macronix has begun supporting this command set on some new flash (e.g., MX25L25635F). For the moment, I don't know how to differentiate the Macronix that don't support this command set (e.g., MX25L25635E) from those that do, so this patch only supports Spansion. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-04-11 02:34:57 -06:00
/* Default commands */
switch (flash->flash_read) {
case M25P80_QUAD:
flash->read_opcode = OPCODE_QUAD_READ;
break;
case M25P80_DUAL:
flash->read_opcode = OPCODE_DUAL_READ;
break;
case M25P80_FAST:
mtd: m25p80: utilize dedicated 4-byte addressing commands Traditionally, the command set used by SPI flash only supported a 3-byte address. However, large SPI flash (>= 32MiB, or 256Mib) require 4 bytes to address the entire flash. Most manufacturers have supplied a mode switch (via a "bank register writer", or a "enable 4-byte mode" command), which tells the flash to expect 4 address cycles from now on, instead of 3. This mode remains until power is cut, the reset line is triggered (on packages where present), or a command is sent to reset the flash or to reset the 3-byte addressing mode. As an alternative, some flash manufacturers have developed a new command set that accept a full 4-byte address. They can be used orthogonally to any of the modes; that is, they can be used when the flash is in either 3-byte or 4-byte address mode. Now, there are a number of reasons why the "stateful" 4-byte address mode switch may not be acceptable. For instance, some SoC's perform a dumb boot sequence in which they only send 3-byte read commands to the flash. However, if an unexpected reset occurs, the flash chip cannot be guaranteed to return to its 3-byte mode. Thus, the SoC controller and flash will not understand each other. (One might consider hooking up the aforementioned reset pin to the system reset line so that any system reset will reset the flash to 3-byte mode, but some packages do not provide this pin. And in some other packages, one must choose between having a reset pin and having enough pins for 4-output QSPI support. It is an error prone process choosing a flash that will support a hardware reset pin!) This patch provides support for the new stateless command set, so that we can avoid the problems that come with a stateful addressing mode change. The flash can be left in "3-byte mode" while still accessing the entire flash. Note that Spansion supports this command set on all its large flash (e.g, S25FL512S), and Macronix has begun supporting this command set on some new flash (e.g., MX25L25635F). For the moment, I don't know how to differentiate the Macronix that don't support this command set (e.g., MX25L25635E) from those that do, so this patch only supports Spansion. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-04-11 02:34:57 -06:00
flash->read_opcode = OPCODE_FAST_READ;
break;
case M25P80_NORMAL:
mtd: m25p80: utilize dedicated 4-byte addressing commands Traditionally, the command set used by SPI flash only supported a 3-byte address. However, large SPI flash (>= 32MiB, or 256Mib) require 4 bytes to address the entire flash. Most manufacturers have supplied a mode switch (via a "bank register writer", or a "enable 4-byte mode" command), which tells the flash to expect 4 address cycles from now on, instead of 3. This mode remains until power is cut, the reset line is triggered (on packages where present), or a command is sent to reset the flash or to reset the 3-byte addressing mode. As an alternative, some flash manufacturers have developed a new command set that accept a full 4-byte address. They can be used orthogonally to any of the modes; that is, they can be used when the flash is in either 3-byte or 4-byte address mode. Now, there are a number of reasons why the "stateful" 4-byte address mode switch may not be acceptable. For instance, some SoC's perform a dumb boot sequence in which they only send 3-byte read commands to the flash. However, if an unexpected reset occurs, the flash chip cannot be guaranteed to return to its 3-byte mode. Thus, the SoC controller and flash will not understand each other. (One might consider hooking up the aforementioned reset pin to the system reset line so that any system reset will reset the flash to 3-byte mode, but some packages do not provide this pin. And in some other packages, one must choose between having a reset pin and having enough pins for 4-output QSPI support. It is an error prone process choosing a flash that will support a hardware reset pin!) This patch provides support for the new stateless command set, so that we can avoid the problems that come with a stateful addressing mode change. The flash can be left in "3-byte mode" while still accessing the entire flash. Note that Spansion supports this command set on all its large flash (e.g, S25FL512S), and Macronix has begun supporting this command set on some new flash (e.g., MX25L25635F). For the moment, I don't know how to differentiate the Macronix that don't support this command set (e.g., MX25L25635E) from those that do, so this patch only supports Spansion. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-04-11 02:34:57 -06:00
flash->read_opcode = OPCODE_NORM_READ;
break;
default:
dev_err(&flash->spi->dev, "No Read opcode defined\n");
return -EINVAL;
}
mtd: m25p80: utilize dedicated 4-byte addressing commands Traditionally, the command set used by SPI flash only supported a 3-byte address. However, large SPI flash (>= 32MiB, or 256Mib) require 4 bytes to address the entire flash. Most manufacturers have supplied a mode switch (via a "bank register writer", or a "enable 4-byte mode" command), which tells the flash to expect 4 address cycles from now on, instead of 3. This mode remains until power is cut, the reset line is triggered (on packages where present), or a command is sent to reset the flash or to reset the 3-byte addressing mode. As an alternative, some flash manufacturers have developed a new command set that accept a full 4-byte address. They can be used orthogonally to any of the modes; that is, they can be used when the flash is in either 3-byte or 4-byte address mode. Now, there are a number of reasons why the "stateful" 4-byte address mode switch may not be acceptable. For instance, some SoC's perform a dumb boot sequence in which they only send 3-byte read commands to the flash. However, if an unexpected reset occurs, the flash chip cannot be guaranteed to return to its 3-byte mode. Thus, the SoC controller and flash will not understand each other. (One might consider hooking up the aforementioned reset pin to the system reset line so that any system reset will reset the flash to 3-byte mode, but some packages do not provide this pin. And in some other packages, one must choose between having a reset pin and having enough pins for 4-output QSPI support. It is an error prone process choosing a flash that will support a hardware reset pin!) This patch provides support for the new stateless command set, so that we can avoid the problems that come with a stateful addressing mode change. The flash can be left in "3-byte mode" while still accessing the entire flash. Note that Spansion supports this command set on all its large flash (e.g, S25FL512S), and Macronix has begun supporting this command set on some new flash (e.g., MX25L25635F). For the moment, I don't know how to differentiate the Macronix that don't support this command set (e.g., MX25L25635E) from those that do, so this patch only supports Spansion. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-04-11 02:34:57 -06:00
flash->program_opcode = OPCODE_PP;
if (info->addr_width)
flash->addr_width = info->addr_width;
mtd: m25p80: utilize dedicated 4-byte addressing commands Traditionally, the command set used by SPI flash only supported a 3-byte address. However, large SPI flash (>= 32MiB, or 256Mib) require 4 bytes to address the entire flash. Most manufacturers have supplied a mode switch (via a "bank register writer", or a "enable 4-byte mode" command), which tells the flash to expect 4 address cycles from now on, instead of 3. This mode remains until power is cut, the reset line is triggered (on packages where present), or a command is sent to reset the flash or to reset the 3-byte addressing mode. As an alternative, some flash manufacturers have developed a new command set that accept a full 4-byte address. They can be used orthogonally to any of the modes; that is, they can be used when the flash is in either 3-byte or 4-byte address mode. Now, there are a number of reasons why the "stateful" 4-byte address mode switch may not be acceptable. For instance, some SoC's perform a dumb boot sequence in which they only send 3-byte read commands to the flash. However, if an unexpected reset occurs, the flash chip cannot be guaranteed to return to its 3-byte mode. Thus, the SoC controller and flash will not understand each other. (One might consider hooking up the aforementioned reset pin to the system reset line so that any system reset will reset the flash to 3-byte mode, but some packages do not provide this pin. And in some other packages, one must choose between having a reset pin and having enough pins for 4-output QSPI support. It is an error prone process choosing a flash that will support a hardware reset pin!) This patch provides support for the new stateless command set, so that we can avoid the problems that come with a stateful addressing mode change. The flash can be left in "3-byte mode" while still accessing the entire flash. Note that Spansion supports this command set on all its large flash (e.g, S25FL512S), and Macronix has begun supporting this command set on some new flash (e.g., MX25L25635F). For the moment, I don't know how to differentiate the Macronix that don't support this command set (e.g., MX25L25635E) from those that do, so this patch only supports Spansion. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-04-11 02:34:57 -06:00
else if (flash->mtd.size > 0x1000000) {
/* enable 4-byte addressing if the device exceeds 16MiB */
mtd: m25p80: utilize dedicated 4-byte addressing commands Traditionally, the command set used by SPI flash only supported a 3-byte address. However, large SPI flash (>= 32MiB, or 256Mib) require 4 bytes to address the entire flash. Most manufacturers have supplied a mode switch (via a "bank register writer", or a "enable 4-byte mode" command), which tells the flash to expect 4 address cycles from now on, instead of 3. This mode remains until power is cut, the reset line is triggered (on packages where present), or a command is sent to reset the flash or to reset the 3-byte addressing mode. As an alternative, some flash manufacturers have developed a new command set that accept a full 4-byte address. They can be used orthogonally to any of the modes; that is, they can be used when the flash is in either 3-byte or 4-byte address mode. Now, there are a number of reasons why the "stateful" 4-byte address mode switch may not be acceptable. For instance, some SoC's perform a dumb boot sequence in which they only send 3-byte read commands to the flash. However, if an unexpected reset occurs, the flash chip cannot be guaranteed to return to its 3-byte mode. Thus, the SoC controller and flash will not understand each other. (One might consider hooking up the aforementioned reset pin to the system reset line so that any system reset will reset the flash to 3-byte mode, but some packages do not provide this pin. And in some other packages, one must choose between having a reset pin and having enough pins for 4-output QSPI support. It is an error prone process choosing a flash that will support a hardware reset pin!) This patch provides support for the new stateless command set, so that we can avoid the problems that come with a stateful addressing mode change. The flash can be left in "3-byte mode" while still accessing the entire flash. Note that Spansion supports this command set on all its large flash (e.g, S25FL512S), and Macronix has begun supporting this command set on some new flash (e.g., MX25L25635F). For the moment, I don't know how to differentiate the Macronix that don't support this command set (e.g., MX25L25635E) from those that do, so this patch only supports Spansion. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-04-11 02:34:57 -06:00
flash->addr_width = 4;
if (JEDEC_MFR(info->jedec_id) == CFI_MFR_AMD) {
/* Dedicated 4-byte command set */
switch (flash->flash_read) {
case M25P80_QUAD:
flash->read_opcode = OPCODE_QUAD_READ_4B;
break;
case M25P80_DUAL:
flash->read_opcode = OPCODE_DUAL_READ_4B;
break;
case M25P80_FAST:
flash->read_opcode = OPCODE_FAST_READ_4B;
break;
case M25P80_NORMAL:
flash->read_opcode = OPCODE_NORM_READ_4B;
break;
}
mtd: m25p80: utilize dedicated 4-byte addressing commands Traditionally, the command set used by SPI flash only supported a 3-byte address. However, large SPI flash (>= 32MiB, or 256Mib) require 4 bytes to address the entire flash. Most manufacturers have supplied a mode switch (via a "bank register writer", or a "enable 4-byte mode" command), which tells the flash to expect 4 address cycles from now on, instead of 3. This mode remains until power is cut, the reset line is triggered (on packages where present), or a command is sent to reset the flash or to reset the 3-byte addressing mode. As an alternative, some flash manufacturers have developed a new command set that accept a full 4-byte address. They can be used orthogonally to any of the modes; that is, they can be used when the flash is in either 3-byte or 4-byte address mode. Now, there are a number of reasons why the "stateful" 4-byte address mode switch may not be acceptable. For instance, some SoC's perform a dumb boot sequence in which they only send 3-byte read commands to the flash. However, if an unexpected reset occurs, the flash chip cannot be guaranteed to return to its 3-byte mode. Thus, the SoC controller and flash will not understand each other. (One might consider hooking up the aforementioned reset pin to the system reset line so that any system reset will reset the flash to 3-byte mode, but some packages do not provide this pin. And in some other packages, one must choose between having a reset pin and having enough pins for 4-output QSPI support. It is an error prone process choosing a flash that will support a hardware reset pin!) This patch provides support for the new stateless command set, so that we can avoid the problems that come with a stateful addressing mode change. The flash can be left in "3-byte mode" while still accessing the entire flash. Note that Spansion supports this command set on all its large flash (e.g, S25FL512S), and Macronix has begun supporting this command set on some new flash (e.g., MX25L25635F). For the moment, I don't know how to differentiate the Macronix that don't support this command set (e.g., MX25L25635E) from those that do, so this patch only supports Spansion. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-04-11 02:34:57 -06:00
flash->program_opcode = OPCODE_PP_4B;
/* No small sector erase for 4-byte command set */
flash->erase_opcode = OPCODE_SE_4B;
flash->mtd.erasesize = info->sector_size;
} else
mtd: m25p80: utilize dedicated 4-byte addressing commands Traditionally, the command set used by SPI flash only supported a 3-byte address. However, large SPI flash (>= 32MiB, or 256Mib) require 4 bytes to address the entire flash. Most manufacturers have supplied a mode switch (via a "bank register writer", or a "enable 4-byte mode" command), which tells the flash to expect 4 address cycles from now on, instead of 3. This mode remains until power is cut, the reset line is triggered (on packages where present), or a command is sent to reset the flash or to reset the 3-byte addressing mode. As an alternative, some flash manufacturers have developed a new command set that accept a full 4-byte address. They can be used orthogonally to any of the modes; that is, they can be used when the flash is in either 3-byte or 4-byte address mode. Now, there are a number of reasons why the "stateful" 4-byte address mode switch may not be acceptable. For instance, some SoC's perform a dumb boot sequence in which they only send 3-byte read commands to the flash. However, if an unexpected reset occurs, the flash chip cannot be guaranteed to return to its 3-byte mode. Thus, the SoC controller and flash will not understand each other. (One might consider hooking up the aforementioned reset pin to the system reset line so that any system reset will reset the flash to 3-byte mode, but some packages do not provide this pin. And in some other packages, one must choose between having a reset pin and having enough pins for 4-output QSPI support. It is an error prone process choosing a flash that will support a hardware reset pin!) This patch provides support for the new stateless command set, so that we can avoid the problems that come with a stateful addressing mode change. The flash can be left in "3-byte mode" while still accessing the entire flash. Note that Spansion supports this command set on all its large flash (e.g, S25FL512S), and Macronix has begun supporting this command set on some new flash (e.g., MX25L25635F). For the moment, I don't know how to differentiate the Macronix that don't support this command set (e.g., MX25L25635E) from those that do, so this patch only supports Spansion. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-04-11 02:34:57 -06:00
set_4byte(flash, info->jedec_id, 1);
} else {
flash->addr_width = 3;
}
dev_info(&spi->dev, "%s (%lld Kbytes)\n", id->name,
(long long)flash->mtd.size >> 10);
pr_debug("mtd .name = %s, .size = 0x%llx (%lldMiB) "
".erasesize = 0x%.8x (%uKiB) .numeraseregions = %d\n",
flash->mtd.name,
(long long)flash->mtd.size, (long long)(flash->mtd.size >> 20),
flash->mtd.erasesize, flash->mtd.erasesize / 1024,
flash->mtd.numeraseregions);
if (flash->mtd.numeraseregions)
for (i = 0; i < flash->mtd.numeraseregions; i++)
pr_debug("mtd.eraseregions[%d] = { .offset = 0x%llx, "
".erasesize = 0x%.8x (%uKiB), "
".numblocks = %d }\n",
i, (long long)flash->mtd.eraseregions[i].offset,
flash->mtd.eraseregions[i].erasesize,
flash->mtd.eraseregions[i].erasesize / 1024,
flash->mtd.eraseregions[i].numblocks);
/* partitions should match sector boundaries; and it may be good to
* use readonly partitions for writeprotected sectors (BP2..BP0).
*/
return mtd_device_parse_register(&flash->mtd, NULL, &ppdata,
data ? data->parts : NULL,
data ? data->nr_parts : 0);
}
static int m25p_remove(struct spi_device *spi)
{
struct m25p *flash = spi_get_drvdata(spi);
/* Clean up MTD stuff. */
return mtd_device_unregister(&flash->mtd);
}
static struct spi_driver m25p80_driver = {
.driver = {
.name = "m25p80",
.owner = THIS_MODULE,
},
.id_table = m25p_ids,
.probe = m25p_probe,
.remove = m25p_remove,
/* REVISIT: many of these chips have deep power-down modes, which
* should clearly be entered on suspend() to minimize power use.
* And also when they're otherwise idle...
*/
};
module_spi_driver(m25p80_driver);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Mike Lavender");
MODULE_DESCRIPTION("MTD SPI driver for ST M25Pxx flash chips");