Some chips fails to identify properly when SYNC_WRITE mode is enabled
(the example is OneNAND on S5PC110 SoC). This patch adds a workaround
for such chips.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
This patch adds a new callback for the underlying drivers, which is
called instead of accessing the buffer ram directly. This callback will
be used by Samsung OneNAND driver to implement DMA transfers on S5PC110
SoC.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
This patch extends OneNAND core code with support for OneNAND verify
write check. This is done by allocating the buffer for verify read
directly from the core code.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
This patch adds support for OneNAND chips that have 4KiB page size.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
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>
mtd->writesize and len are unsigned so the test does not work.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Mika Korhonen <ext-mika.2.korhonen@nokia.com>
Reviewed-by: Adrian Hunter <adrian.hunter@nokia.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Add support for multiblock erase command. OneNANDs (excluding Flex-OneNAND)
are capable of simultaneous erase of up to 64 eraseblocks which is much faster.
This changes the erase requests for regions covering multiple eraseblocks
to be performed using multiblock erase.
Signed-off-by: Mika Korhonen <ext-mika.2.korhonen@nokia.com>
Reviewed-by: Adrian Hunter <adrian.hunter@nokia.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Separate the actual execution of erase to a new function:
onenand_block_by_block_erase(). This is done in preparation for
the multiblock erase support.
Signed-off-by: Mika Korhonen <ext-mika.2.korhonen@nokia.com>
Reviewed-by: Adrian Hunter <adrian.hunter@nokia.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
What is OTP in OneNAND?
The device includes,
1. one block-sized OTP (One Time Programmable) area and
2. user-controlled 1st block OTP(Block 0)
that can be used to increase system security or to provide
identification capabilities.
What is done?
In OneNAND, one block of the NAND Array is set aside as an OTP
memory area, and 1st Block (Block 0) can be used as OTP area.
This area, available to the user, can be configured and locked
with secured user information. The OTP block can be read,
programmed and locked using the same operations as any other NAND
Flash Array memory block. After issuing an OTP-Lock, OTP block
cannot be erased. OTP block is fully-guaranteed to be a good
block.
Why it is done?
Locking the 1st Block OTP has the effect of a 'Write-protect' to
guard against accidental re-programming of data stored in the 1st
block and OTP Block.
Which problem it solves?
OTP support is provided in the existing implementation of
OneNAND/Flex-OneNAND driver, but it is not working with OneNAND
devices. Have observed the following in current OTP OneNAND Implmentation,
1. DataSheet specific sequence to lock the OTP Area is not followed.
2. Certain functions are quiet generic to cope with OTP specific activity.
This patch re-implements OTP support for OneNAND device.
How it is done?
For all blocks, 8th word is available to the user.
However, in case of OTP Block, 8th word of sector 0, page 0 is reserved as
OTP Locking Bit area. Therefore, in case of OTP Block, user usage on this
area is prohibited. Condition specific values are entered in the 8th word,
sector0, page 0 of the OTP block during the process of issuing an OTP-Lock.
The possible conditions are:
1. Only 1st Block Lock
2. Only OTP Block Lock
3. Lock both the 1st Block and the OTP Block
What Other feature additions have been done in this patch?
This patch adds feature for:
1. Only 1st Block Lock
2. Lock both the 1st Block and the OTP Blocks
Re-implemented OTP support for OneNAND
Added following features to OneNAND
1. Lock only 1st Block in OneNAND
2. Lock BOTH 1st Block and OTP Block in OneNAND
[comments were slightly tweaked by Artem]
Signed-off-by: Amul Kumar Saha <amul.saha@samsung.com>
Reviewed-by: Adrian Hunter <adrian.hunter@nokia.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
This patch resolves all the prints present in onenand_base.c
Primarily, it replaces the hard-coded function names in the prints,
and makes use of __func__.
Signed-off-by: Amul Kumar Saha <amul.saha@samsung.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Mika Korhonen <mika.j.korhonen@gmail.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
This patch unifies the flex_bdry setting for module vs. built-in
configuration of OneNAND.
Signed-off-by: Amul Kumar Saha <amul.saha@samsung.com>
Signed-off-by: Vishak G <vishak.g@samsung.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Add bbt_wait & unlock_all as replaceable for some platform such as
s3c64xx s3c64xx has its own OneNAND controller and another interface
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Add support for Samsung Flex-OneNAND devices.
Flex-OneNAND combines SLC and MLC technologies into a single device.
SLC area provides increased reliability and speed, suitable for storing
code such as bootloader, kernel and root file system. MLC area
provides high density and is suitable for storing user data.
SLC and MLC regions can be configured through kernel parameter.
[akpm@linux-foundation.org: export flexoand_region and onenand_addr]
Signed-off-by: Rohit Hagargundgi <h.rohit@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Vishak G <vishak.g@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
In addition to adding the Numonyx manufacturer code, this patch
also ensures 'sync. write' is disabled when reading identification
data - something that the Numonyx chip objects to, but the
Samsung chip seems to ignore.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
OneNAND write-while-program method of writing improves performance,
compared with ordinary writes, by transferring data to OneNAND's
RAM buffers atthe same time as programming the NAND core.
When writing several NAND pages at a time, an improvement of
12% to 25% is seen.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
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>
To get the correct information in case of power off recovery,
it should read ECC status first
Also remove previous workaround method.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
A power loss while writing can result in a page becoming unreadable.
When the device is mounted again, reading that page gives controller
errors. Upper level software like JFFS2 treat -EIO as fatal, refusing to
mount at all. That means it is necessary to treat the error as an ECC
error to allow recovery. Note that typically in this case, the
eraseblock can still be erased and rewritten i.e. it has not become a
bad block.
Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Implement the panic_write function for the onenand driver. This waits
for any active command to complete/timeout, performs the write, waits
for it to complete and then returns.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
In function onenand_verify_oob, local variable oobbuf shall be unsigned char.
In the case of a value is >= 0x80, it's unequal in comparing the value in an unsigned char and signed char.
Signed-off-by: Sheng Yongjie (Sam) <samsheng@trident.com.cn>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Consolidate OneNAND operation order as OneNAND Spec.
It also doesn't break previous operation order.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
When an ECC error occurs, the read should be completed
anyway before returning -EBADMSG. Returning -EBADMSG
straight away is incorrect.
Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
When the erase callback performs some other action on the flash, it's
highly likely to deadlock unless we actually release the chip lock
before calling it.
This patch mirrors that same change already done for NAND.
Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
The OneNAND driver was confusing JFFS2 by returning positive error
codes.
Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Ensure OneNAND's block locking operations are synchronized
like all other operations.
Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
This patch make the OneNAND driver much less racy. It fixes
our "onenand_wait: read timeout!" heisenbugs. The reason of
these bugs was that the driver did not lock the chip when
accessing OTP, and it screwed up OneNAND state when the OTP
was read while JFFS2 was doing FS checking.
This patch also fixes other races I spotted:
1. BBT was not protected
2. Access to ecc_stats was not protected
Now the chip is locked when BBT is accessed.
To fix all of these I basically split all interface functions
on 'function()' and 'function_nolock()' parts.
I tested this patch on N800 hardware - it fixes our problems.
But I tested a little different version because our OneNAND
codebase is slightly out-of-date. But it should be OK.
This patch also includes the prin fixes I posted before.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
To enable the main read/write at oob ops
Next time we will commit the main read/write support for yaffs2
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
The 2X Program is an extension of Program Operation.
Since the device is equipped with two DataRAMs, and two-plane NAND Flash
memory array, these two component enables simultaneous program of 4KiB.
Plane1 has only even blocks such as block0, block2, block4 while Plane2
has only odd blocks such as block1, block3, block5.
So MTD regards it as 4KiB page size and 256KiB block size
Now the following chips support it. (KFXXX16Q2M)
Demux: KFG2G16Q2M, KFH4G16Q2M, KFW8G16Q2M,
Mux: KFM2G16Q2M, KFN4G16Q2M,
And more recent chips
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
The JFFS2 requests OOB function from column 0.
But the oobtest in nand-tests doesn't.
So we only exit loop only when column start with 0.
Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Here it's not the case: all the entries are occupied by
OOB chunks. Therefore, once we get into a loop like
for (free = this->ecclayout->oobfree; free->length; ++free) {
}
we might end up scanning past the real oobfree array.
Probably the best way out, as the same thing might happen for common NAND
as well, is to check index against MTD_MAX_OOBFREE_ENTRIES.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Classify the page data and oob buffer
and it prevents the memory fragementation (writesize + oobsize)
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
When transferring/filling of the oob is finished in OOB_AUTO, we exit the loop
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
add Nokia Copyright and a credit
Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
In oob functions, it is used main buffer instead of oob one. So fix it.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Kyungmin Park