aboutsummaryrefslogtreecommitdiff
path: root/drivers/mtd/chips/cfi_cmdset_0002.c
AgeCommit message (Collapse)Author
2009-01-09[MTD] CFI: remove major/minor version check for command set 0x0002Wolfgang Grandegger
The NOR Flash memory K8P2815UQB from Samsung uses the major version number '0'. Add a quirk to cope with it. Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-12-10[MTD] update internal API to support 64-bit device sizeAdrian Hunter
MTD internal API presently uses 32-bit values to represent device size. This patch updates them to 64-bits but leaves the external API unchanged. Extending the external API is a separate issue for several reasons. First, no one needs it at the moment. Secondly, whether the implementation is done with IOCTLs, sysfs or both is still debated. Thirdly external API changes require the internal API to be accepted first. Note that although the MTD API will be able to support 64-bit device sizes, existing drivers do not and are not required to do so, although NAND base has been updated. In general, changing from 32-bit to 64-bit values cause little or no changes to the majority of the code with the following exceptions: - printk message formats - division and modulus of 64-bit values - NAND base support - 32-bit local variables used by mtdpart and mtdconcat - naughtily assuming one structure maps to another in MEMERASE ioctl Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-11-05[MTD] [NOR] Fix cfi_send_gen_cmd handling of x16 devices in x8 mode (v4)Eric W. Biederman
For "unlock" cycles to 16bit devices in 8bit compatibility mode we need to use the byte addresses 0xaaa and 0x555. These effectively match the word address 0x555 and 0x2aa, except the latter has its low bit set. Most chips don't care about the value of the 'A-1' pin in x8 mode, but some -- like the ST M29W320D -- do. So we need to be careful to set it where appropriate. cfi_send_gen_cmd is only ever passed addresses where the low byte is 0x00, 0x55 or 0xaa. Of those, only addresses ending 0xaa are affected by this patch, by masking in the extra low bit when the device is known to be in compatibility mode. [dwmw2: Do it only when (cmd_ofs & 0xff) == 0xaa] v4: Fix stupid typo in cfi_build_cmd_addr that failed to compile I'm writing this patch way to late at night. v3: Bring all of the work back into cfi_build_cmd_addr including calling of map_bankwidth(map) and cfi_interleave(cfi) So every caller doesn't need to. v2: Only modified the address if we our device_type is larger than our bus width. Cc: stable@kernel.org Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-10-18[MTD] [NOR] AT49BV6416 has swapped erase regionsHaavard Skinnemoen
The CFI information read from AT49BV6416 lists the erase regions in the wrong order, causing problems when trying to erase or update the first or last 64KiB block. Work around this by inverting the "top boot" flag, which will effectively reverse the order of the erase regions. This chip is obsolete, but it's used in some existing designs. Signed-off-by: Håvard Skinnemoen <haavard.skinnemoen@atmel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-10-18[MTD] cfi_cmdset_0002.c: Add Macronix CFI V1.0 TopBottom detectionChristopher Moore
This patch adds TopBottom detection for most Macronix chips with CFI V1.0. The main purpose of this patch is to add detection of the MX29LV400C B used on the LaCie Ethernet Disk mini V2 NAS. It detects the following parts correctly:- MX28F640C3B T MX29LV002C B MX29LV002NC B MX29LV004C T MX29LV400C T/B MX29LV800C T/B MX29LV160C T/B MX29SL800C T/B MX29SL802C T/B It detects the following uniform part as bottom but it should work correctly:- MX29LV040C For T parts it causes the erase block table to be reversed correctly. For other parts it avoids the bogus "Assuming top" message. It does not detect the following correctly:- MX28F640C3B B MX29LV002C T MX29LV002NC T MX29LV004C B MX29SL400C T/B MX29SL402C T/B If desired I could supply a more complicated patch to handle these as well. Only the MX29LV400C B has been physically tested; others were checked against their data sheets. Signed-off-by: Christopher Moore <moore@free.fr> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-06-04MTD/JFFS2: remove CVS keywordsAdrian Bunk
Once upon a time, the MTD repository was using CVS. This patch therefore removes all usages of the no longer updated CVS keywords from the MTD code. This also includes code that printed them to the user. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-04-22[MTD] [NOR] Fixup for incorrect CFI data in Spansion S29GL064/32N flash chipsTrent Piepho
This is a known erratum confirmed by Spansion. I have an errata document, but I can't find a link to it anywhere on their site to include here. Some of the S29GL064N chips report 64 sectors when they should report 128, and some of S29GL032N chips report 127 sectors when they should report 63. Note that when the chip dies are fixed by Spansion, they will still have the same id. The fix is done in such a way that it won't affect corrected chips. The fixups use the extended id made available by a previous patch. Without that, virtually all newer AMD/Spansion chips will have the same ID (0x227e) and it's not possible to apply the fixup to the correct chips. Signed-off-by: Trent Piepho <tpiepho@freescale.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-04-22[MTD] XIP: Use generic xip_iprefetch() instead of asm volatile (...)Paulius Zaleckas
Untested, but shouldn't break anything... Makes MTD_XIP arch independent. I guess this is why xip_iprefetch() was made for. Signed-off-by: Paulius Zaleckas <paulius.zaleckas@teltonika.lt> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-04-08mtd/chips: add missing set_current_state() to cfi_{amdstd,staa}_sync()Dmitry Adamushko
cfi_amdstd_sync() and cfi_staa_sync() call schedule() without changing task's state appropriately. In case of e.g. chip->state == FL_ERASING, cfi_*_sync() will be busy-looping either redundantly for a fixed interval of time (for SCHED_NORMAL tasks) or possibly endlessly (for RT tasks and UP). Signed-off-by: Dmitry Adamushko <dmitry.adamushko@gmail.com> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-03[MTD] Unlocking all Intel flash that is locked on power up.Justin Treon
Patch for unlocking all Intel flash that has instant locking on power up. The patch has been tested on Intel M18, P30 and J3D Strata Flash. 1. The automatic unlocking can be disabled for a particular partition in the map or the command line. a. For the bit mask in the map it should look like: .mask_flags = MTD_POWERUP_LOCK, b. For the command line parsing it should look like: mtdparts=0x80000(bootloader)lk 2. This will only unlock parts with instant individual block locking. Intel parts with legacy unlocking will not be unlocked. Signed-off-by: Justin Treon <justin_treon@yahoo.com> Signed-off-by: Jared Hulbert <jaredeh@gmail.com> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-01-10[MTD] [NOR] Fix incorrect interface code for x16/x32 chipsBartlomiej Sieka
According to "Common Flash Memory Interface Publication 100" dated December 1, 2001, the interface code for x16/x32 chips is 0x0005, and not 0x0004 used so far. Signed-off-by: Bartlomiej Sieka <tur@semihalf.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-10-30[MTD] [NOR] More CFI fixups for Atmel chipsHans-Christian Egtvedt
Convert CFI tables from Atmel cmdset_0001 chips to Intel format and set BufWrite timeouts to 0 for Atmel cmdset_0001 and cmdset_0002 chips. Some chips may indicate support for buffered writes even though they only support dual-word writes. The CFI fixup must run before fixup_use_write_buffers for this to work. Signed-off-by: Håvard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-06-28[MTD] [NOR] cfi_cmdset_0002.c: fix 'cfi_amdstd_erase_varsize' to be staticBen Dooks
Make cfi_amdstd_erase_varsize static, as declared at the top of the file to ensure sparse does not print a warning for an undeclared function, as so: drivers/mtd/chips/cfi_cmdset_0002.c:1612:5: warning: symbol 'cfi_amdstd_erase_varsize' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-03-08[MTD] [NOR] Fix oops in cfi_amdstd_syncVijay Sampath
The files cfi_cmdset_0002.c and cfi_cmdset_0020.c do not initialize their wait queues like is done in cfi_cmdset_0001.c. This causes an oops when the wait queue is accessed. I have copied the code from cfi_cmdset_0001.c that is pertinent to initialization of the wait queue. Signed-off-by: Vijay Sampath <vsampath@gmail.com> Acked-by: Joern Engel <joern@lazybastard.org> Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-11-28[MTD] replace kmalloc+memset with kzallocBurman Yan
Signed-off-by: Yan Burman <yan_952@hotmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-10-21[MTD] CHIPS: Support for SST 49LF040B flash chipRyan Jackson
Add chip driver and JEDEC probe support for the SST 49LF040B flash chip. Signed-off-by: Ryan Jackson <rjackson@lnxi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-22[MTD] Unlock NOR flash automatically where necessaryHåvard Skinnemoen
Introduce the MTD_STUPID_LOCK flag which indicates that the flash chip is always locked after power-up, so all sectors need to be unlocked before it is usable. If this flag is set, and the chip provides an unlock() operation, mtd_add_device will unlock the whole MTD device if it's writeable. This means that non-writeable partitions will stay locked. Set MTD_STUPID_LOCK in fixup_use_atmel_lock() so that these chips will work as expected. Signed-off-by: Håvard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-16MTD: Fix bug in fixup_convert_atmel_priHåvard Skinnemoen
The memset() in fixup_convert_atmel_pri is supposed to zero out everything except the first 5 bytes in *extp, but it ends up zeroing out something way outside the struct instead. Fix this potentially dangerous code by casting the pointer to char * before doing arithmetic. Signed-off-by: Håvard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-08-16MTD: Add lock/unlock operations for Atmel AT49BV6416Haavard Skinnemoen
The AT49BV6416 is locked by default, so we really need to provide at least the unlock() operation for write and erase to work. This patch implements both ->lock() and ->unlock() and provides a fixup to install them when an AT49BV6416 chip is detected. These functions are probably valid on more Atmel chips, but I believe it's mostly obsolete ones. The AT49BV6416 is in fact obsolete, but it's used on all current AT32STK1000 development boards. Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: Josh Boyer <jwboyer@gmail.com>
2006-08-16MTD: Convert Atmel PRI information to AMD formatHaavard Skinnemoen
Atmel flash chips don't have PRI information in the same format as AMD flash chips. This patch installs a fixup for all Atmel chips that converts the relevant PRI fields into AMD format. Only the fields that are actually used by the command set is actually converted. The rest are initialized to zero (which should be safe) Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: Josh Boyer <jwboyer@gmail.com>
2006-06-30Remove obsolete #include <linux/config.h>Jörn Engel
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-06-14[MTD] assume mtd->writesize is 1 for NOR flashesArtem B. Bityutskiy
Signed-off-by: Artem B. Bityitskiy
2006-05-08Export cfi_cmdset_0020 and cfi_cmdset_0002 with EXPORT_SYMBOL_GPLDavid Woodhouse
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-08Remove use of inter_module_crap in NOR flash chip drivers.David Woodhouse
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2005-11-07Merge master.kernel.org:/pub/scm/linux/kernel/git/tglx/mtd-2.6Linus Torvalds
Some manual fixups for clashing kfree() cleanups etc.
2005-11-07[PATCH] kfree cleanup: drivers/mtdJesper Juhl
This is the drivers/mtd part of the big kfree cleanup patch. Remove pointless checks for NULL prior to calling kfree() in drivers/mtd/. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Cc: David Woodhouse <dwmw2@infradead.org> Acked-by: Joern Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07[MTD] chips: Clean up trailing white spacesThomas Gleixner
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07[MTD] chips cfi_cmdset_0002: Prevent timeout raceKonstantin Baidarov
We've noticed that sometimes "MTD do_write_buffer(): software timeout" message was printed out when writing to a Fujitsu NOR flash. It turned out that this was because of a race in the timeout handling do_write_buffer(). A small timeout of (HZ / 1000) + 1 is used there, and sometimes if the timer interrupt handling takes more than one or even two jiffies (which is 1-2 ms with HZ == 1000) and that interrupt happens just after chip_ready() call, the driver bails out from a ready polling loop despite the chip has actually become ready while all those interrupts were handled. To deal with this issue, extra check for chip ready is neccessary on timeout expiration (and the checks should better be reordered). As do_write_oneword() uses the same approach, it needs to also be changed. Signed-off-by: Konstantin Baidarov <kbaidarov@ru.mvista.com> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-08-04[MTD] CHIPS: Recognize Spansion CFI 1.4 chipsTodd Poynor
Modify Amd/Fujitsu CFI NOR flash primary vendor extension table revision check to recognize version 1.4. Verified the existing driver can handle version 1.4 chips without additional info from 1.4 extended table. Move the primary vendor extension table revision check from common file to the 3 CFI chip driver files, since the data structures and revisions handled by those data structures are specific to the chip driver. Modify the error message printed when the revision is unknown to be a KERN_ERR instead of WARNING since this will cause mtd to ignore the chip. Signed-off-by: Todd Poynor <tpoynor@mvista.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-07-07[MTD] XIP cleanupThomas Gleixner
Move the architecture dependend code into include/asm/mtd-xip.h Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-07-05[MTD] cfi_cmdset_0002: Remove bogus includeThomas Gleixner
Including asm/hardware.h has to be done in linux/mtd/xip.h. Otherwise it breaks allyes compiles. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-06-29[MTD] XIP for AMD CFI flash.Todd Poynor
Author: Vitaly Wool <vwool@ru.mvista.com> Signed-off-by: Todd Poynor <tpoynor@mvista.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-05-24[MTD] cfi_cmdset_0002: Fix broken status checkThomas Gleixner
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-05-23[MTD] CFI-0002 - Improve error checkingEric W. Biedermann
Check for errors besides infinite loops when writing and erasing. Signed-off-by: Eric W. Biederman <ebiederman@lnxi.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!