struct member has a short description which is marked with an [XXX] identifier.
The following chapters explain the meaning of those identifiers.
</para>
- <sect1>
+ <sect1 id="Function_identifiers_XXX">
<title>Function identifiers [XXX]</title>
<para>
The functions are marked with [XXX] identifiers in the short
for most of the implementations. These functions can be replaced by the
board driver if neccecary. Those functions are called via pointers in the
NAND chip description structure. The board driver can set the functions which
- should be replaced by board dependend functions before calling nand_scan().
+ should be replaced by board dependent functions before calling nand_scan().
If the function pointer is NULL on entry to nand_scan() then the pointer
is set to the default function which is suitable for the detected chip type.
</para></listitem>
</itemizedlist>
</sect1>
- <sect1>
+ <sect1 id="Struct_member_identifiers_XXX">
<title>Struct member identifiers [XXX]</title>
<para>
The struct members are marked with [XXX] identifiers in the
[REPLACEABLE]</para><para>
Replaceable members hold hardware related functions which can be
provided by the board driver. The board driver can set the functions which
- should be replaced by board dependend functions before calling nand_scan().
+ should be replaced by board dependent functions before calling nand_scan().
If the function pointer is NULL on entry to nand_scan() then the pointer
is set to the default function which is suitable for the detected chip type.
</para></listitem>
<title>Basic board driver</title>
<para>
For most boards it will be sufficient to provide just the
- basic functions and fill out some really board dependend
+ basic functions and fill out some really board dependent
members in the nand chip description structure.
- See drivers/mtd/nand/skeleton for reference.
</para>
- <sect1>
+ <sect1 id="Basic_defines">
<title>Basic defines</title>
<para>
At least you have to provide a mtd structure and
</para>
<programlisting>
static struct mtd_info *board_mtd;
-static unsigned long baseaddr;
+static void __iomem *baseaddr;
</programlisting>
<para>
Static example
<programlisting>
static struct mtd_info board_mtd;
static struct nand_chip board_chip;
-static unsigned long baseaddr;
+static void __iomem *baseaddr;
</programlisting>
</sect1>
- <sect1>
+ <sect1 id="Partition_defines">
<title>Partition defines</title>
<para>
- If you want to divide your device into parititions, then
- enable the configuration switch CONFIG_MTD_PARITIONS and define
- a paritioning scheme suitable to your board.
+ If you want to divide your device into partitions, then
+ enable the configuration switch CONFIG_MTD_PARTITIONS and define
+ a partitioning scheme suitable to your board.
</para>
<programlisting>
#define NUM_PARTITIONS 2
};
</programlisting>
</sect1>
- <sect1>
+ <sect1 id="Hardware_control_functions">
<title>Hardware control function</title>
<para>
The hardware control function provides access to the
}
</programlisting>
</sect1>
- <sect1>
+ <sect1 id="Device_ready_function">
<title>Device ready function</title>
<para>
If the hardware interface has the ready busy pin of the NAND chip connected to a
the function must not be defined and the function pointer this->dev_ready is set to NULL.
</para>
</sect1>
- <sect1>
+ <sect1 id="Init_function">
<title>Init function</title>
<para>
The init function allocates memory and sets up all the board
int err = 0;
/* Allocate memory for MTD device structure and private data */
- board_mtd = kmalloc (sizeof(struct mtd_info) + sizeof (struct nand_chip), GFP_KERNEL);
+ board_mtd = kzalloc(sizeof(struct mtd_info) + sizeof(struct nand_chip), GFP_KERNEL);
if (!board_mtd) {
printk ("Unable to allocate NAND MTD device structure.\n");
err = -ENOMEM;
goto out;
}
- /* Initialize structures */
- memset ((char *) board_mtd, 0, sizeof(struct mtd_info) + sizeof(struct nand_chip));
-
- /* map physical adress */
- baseaddr = (unsigned long)ioremap(CHIP_PHYSICAL_ADDRESS, 1024);
- if(!baseaddr){
+ /* map physical address */
+ baseaddr = ioremap(CHIP_PHYSICAL_ADDRESS, 1024);
+ if (!baseaddr) {
printk("Ioremap to access NAND chip failed\n");
err = -EIO;
goto out_mtd;
this->dev_ready = board_dev_ready;
this->eccmode = NAND_ECC_SOFT;
- /* Scan to find existance of the device */
+ /* Scan to find existence of the device */
if (nand_scan (board_mtd, 1)) {
err = -ENXIO;
goto out_ior;
goto out;
out_ior:
- iounmap((void *)baseaddr);
+ iounmap(baseaddr);
out_mtd:
kfree (board_mtd);
out:
module_init(board_init);
</programlisting>
</sect1>
- <sect1>
+ <sect1 id="Exit_function">
<title>Exit function</title>
<para>
The exit function is only neccecary if the driver is
/* Release resources, unregister device */
nand_release (board_mtd);
- /* unmap physical adress */
- iounmap((void *)baseaddr);
+ /* unmap physical address */
+ iounmap(baseaddr);
/* Free the MTD device structure */
kfree (board_mtd);
driver. For a list of functions which can be overridden by the board
driver see the documentation of the nand_chip structure.
</para>
- <sect1>
+ <sect1 id="Multiple_chip_control">
<title>Multiple chip control</title>
<para>
- The nand driver can control chip arrays. Therefor the
+ The nand driver can control chip arrays. Therefore the
board driver must provide an own select_chip function. This
function must (de)select the requested chip.
The function pointer in the nand_chip structure must
}
</programlisting>
</sect1>
- <sect1>
+ <sect1 id="Hardware_ECC_support">
<title>Hardware ECC support</title>
- <sect2>
+ <sect2 id="Functions_and_constants">
<title>Functions and constants</title>
<para>
The nand driver supports three different types of
</itemizedlist>
</para>
</sect2>
- <sect2>
+ <sect2 id="Hardware_ECC_with_syndrome_calculation">
<title>Hardware ECC with syndrome calculation</title>
<para>
Many hardware ECC implementations provide Reed-Solomon
The ECC bytes must be placed immidiately after the data
bytes in order to make the syndrome generator work. This
is contrary to the usual layout used by software ECC. The
- seperation of data and out of band area is not longer
+ separation of data and out of band area is not longer
possible. The nand driver code handles this layout and
the remaining free bytes in the oob area are managed by
the autoplacement code. Provide a matching oob-layout
</para>
</sect2>
</sect1>
- <sect1>
+ <sect1 id="Bad_Block_table_support">
<title>Bad block table support</title>
<para>
Most NAND chips mark the bad blocks at a defined
allows faster access than always checking the
bad block information on the flash chip itself.
</para>
- <sect2>
+ <sect2 id="Flash_based_tables">
<title>Flash based tables</title>
<para>
It may be desired or neccecary to keep a bad block table in FLASH.
bad blocks. They have factory marked good blocks. The marker pattern
is erased when the block is erased to be reused. So in case of
powerloss before writing the pattern back to the chip this block
- would be lost and added to the bad blocks. Therefor we scan the
+ would be lost and added to the bad blocks. Therefore we scan the
chip(s) when we detect them the first time for good blocks and
store this information in a bad block table before erasing any
of the blocks.
<para>
The blocks in which the tables are stored are procteted against
accidental access by marking them bad in the memory bad block
- table. The bad block table managment functions are allowed
+ table. The bad block table management functions are allowed
to circumvernt this protection.
</para>
<para>
</itemizedlist>
</para>
</sect2>
- <sect2>
+ <sect2 id="User_defined_tables">
<title>User defined tables</title>
<para>
User defined tables are created by filling out a
</para>
</sect2>
</sect1>
- <sect1>
+ <sect1 id="Spare_area_placement">
<title>Spare area (auto)placement</title>
<para>
The nand driver implements different possibilities for
</para></listitem>
</itemizedlist>
</para>
- <sect2>
+ <sect2 id="Placement_defined_by_fs_driver">
<title>Placement defined by fs driver</title>
<para>
The calling function provides a pointer to a nand_oobinfo
done according to the given scheme in the nand_oobinfo structure.
</para>
</sect2>
- <sect2>
+ <sect2 id="Automatic_placement">
<title>Automatic placement</title>
<para>
Automatic placement uses the built in defaults to place the
done according to the default builtin scheme.
</para>
</sect2>
- <sect2>
+ <sect2 id="User_space_placement_selection">
<title>User space placement selection</title>
<para>
All non ecc functions like mtd->read and mtd->write use an internal
</para>
</sect2>
</sect1>
- <sect1>
+ <sect1 id="Spare_area_autoplacement_default">
<title>Spare area autoplacement default schemes</title>
- <sect2>
+ <sect2 id="pagesize_256">
<title>256 byte pagesize</title>
<informaltable><tgroup cols="3"><tbody>
<row>
</row>
</tbody></tgroup></informaltable>
</sect2>
- <sect2>
+ <sect2 id="pagesize_512">
<title>512 byte pagesize</title>
<informaltable><tgroup cols="3"><tbody>
<row>
</row>
</tbody></tgroup></informaltable>
</sect2>
- <sect2>
+ <sect2 id="pagesize_2048">
<title>2048 byte pagesize</title>
<informaltable><tgroup cols="3"><tbody>
<row>
manufacturers specifications. This applies similar to the spare area.
</para>
<para>
- Therefor NAND aware filesystems must either write in page size chunks
+ Therefore NAND aware filesystems must either write in page size chunks
or hold a writebuffer to collect smaller writes until they sum up to
pagesize. Available NAND aware filesystems: JFFS2, YAFFS.
</para>
<para>
This chapter describes the constants which might be relevant for a driver developer.
</para>
- <sect1>
+ <sect1 id="Chip_option_constants">
<title>Chip option constants</title>
- <sect2>
+ <sect2 id="Constants_for_chip_id_table">
<title>Constants for chip id table</title>
<para>
These constants are defined in nand.h. They are ored together to describe
</programlisting>
</para>
</sect2>
- <sect2>
+ <sect2 id="Constants_for_runtime_options">
<title>Constants for runtime options</title>
<para>
These constants are defined in nand.h. They are ored together to describe
</sect2>
</sect1>
- <sect1>
+ <sect1 id="EEC_selection_constants">
<title>ECC selection constants</title>
<para>
Use these constants to select the ECC algorithm.
</para>
</sect1>
- <sect1>
+ <sect1 id="Hardware_control_related_constants">
<title>Hardware control related constants</title>
<para>
These constants describe the requested hardware access function when
</para>
</sect1>
- <sect1>
+ <sect1 id="Bad_block_table_constants">
<title>Bad block table related constants</title>
<para>
These constants describe the options used for bad block
git://ftp.safe.ca / safe / jmp / linux-2.6 / blobdiff