Skip jiffy delay after each block lock/unlock for Intel CFI flash
with the "Instant Individual Block Locking" feature bit set.
Signed-off-by: Todd Poynor <tpoynor@mvista.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
oldstate has to be reset to FL_READY after sync completion.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The change makes the code endianess aware and replaces the bogus
nested loop to or the status flags together.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The change to the generic probe to look for the
smallest width of chip first is causing some problems
on boards with a single 16bit device.
The problem seems to be the jedec_match() is truncating
the device-id read from the table to match against the
one read from the hardware, causing a match against the
partial id of some chips with 16bit IDs (such as the
SST39LF160)
This fixes things for my own board, but something may
need to be done if the same problem is exhibited for
chips with an 8bit ID
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This enables support for reading, writing and locking so called
"Protection Registers" present on some flash chips.
A subset of them are pre-programmed at the factory with a
unique set of values. The rest is user-programmable.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* Removed table entry for AM29BDS643D, since device ID clashes with AM29DL640G
and both chips support CFI.
Signed-off-by: Jonas Holmberg <jonas.holmberg@axis.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Try larger numbers of chips before smaller
numbers of chips across the bus width.
This means we'll avoid misdetecting a 2 x16 array as 1 x32 if the
high 16-bits happen to read as zeros in the QRY area.
Signed-off-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
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!
