History log of /openbmc/linux/fs/jffs2/os-linux.h (Results 101 – 106 of 106)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 265489f0 06-Jul-2005 David Woodhouse <dwmw2@infradead.org>

[JFFS2] Remove compatibilty cruft for ancient kernels

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>


Revision tags: v2.6.13-rc2, v2.6.13-rc1, v2.6.12, v2.6.12-rc6, v2.6.12-rc5, v2.6.12-rc4
# 8cd79216 03-May-2005 Artem B. Bityuckiy <dedekind@infradead.org>

[JFFS2] Fix NOR only compile

Fix the bug that caouses problems when compiling for NOR.
We read a newly erased block so we don't need to check ECC.

Define jffs2_is_writebuffered

[JFFS2] Fix NOR only compile

Fix the bug that caouses problems when compiling for NOR.
We read a newly erased block so we don't need to check ECC.

Define jffs2_is_writebuffered as zero if there is no wbuf.

Signed-off-by: Artem B. Bityuckiy <dedekind@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

show more ...


Revision tags: v2.6.12-rc3, v2.6.12-rc2
# 2f82ce1e 09-Feb-2005 Andrew Victor <andrew@sanpeople.com>

[JFFS2] Use a single config option for write buffer support

This patch replaces the current CONFIG_JFFS2_FS_NAND, CONFIG_JFFS2_FS_NOR_ECC
and CONFIG_JFFS2_FS_DATAFLASH with a single conf

[JFFS2] Use a single config option for write buffer support

This patch replaces the current CONFIG_JFFS2_FS_NAND, CONFIG_JFFS2_FS_NOR_ECC
and CONFIG_JFFS2_FS_DATAFLASH with a single configuration option -
CONFIG_JFFS2_FS_WRITEBUFFER.

The only functional change of this patch is that the slower div/mod
calculations for SECTOR_ADDR(), PAGE_DIV() and PAGE_MOD() are now always
used when CONFIG_JFFS2_FS_WRITEBUFFER is enabled.

Signed-off-by: Andrew Victor <andrew@sanpeople.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

show more ...


# 8f15fd55 09-Feb-2005 Andrew Victor <andrew@sanpeople.com>

[JFFS2] Add support for JFFS2-on-Dataflash devices.

For Dataflash, can_mark_obsolete = false and the NAND write buffering
code (wbuf.c) is used.

Since the DataFlash chip will au

[JFFS2] Add support for JFFS2-on-Dataflash devices.

For Dataflash, can_mark_obsolete = false and the NAND write buffering
code (wbuf.c) is used.

Since the DataFlash chip will automatically erase pages when writing,
the cleanmarkers are not needed - so cleanmarker_oob = false and
cleanmarker_size = 0

DataFlash page-sizes are not a power of two (they're multiples of 528
bytes). The SECTOR_ADDR macro (added in the previous core patch) is
replaced with a (slower) div/mod version if CONFIG_JFFS2_FS_DATAFLASH is
selected.

Signed-off-by: Andrew Victor <andrew@sanpeople.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

show more ...


# 3be36675 09-Feb-2005 Andrew Victor <andrew@sanpeople.com>

[JFFS2] Core changes required to support JFFS2-on-Dataflash devices.

DataFlash page-sizes are not a power of two (they're multiples of 528
bytes). There are a few places in JFFS2 code w

[JFFS2] Core changes required to support JFFS2-on-Dataflash devices.

DataFlash page-sizes are not a power of two (they're multiples of 528
bytes). There are a few places in JFFS2 code where sector_size is used
as a bitmask. A new macro (SECTOR_ADDR) was defined to calculate these
sector addresses. For non-DataFlash devices, the original (faster)
bitmask operation is still used.

In scan.c, the EMPTY_SCAN_SIZE was a constant of 1024.
Since this could be larger than the sector size of the DataFlash, this
is now basically set to MIN(sector_size, 1024).

Addition of a jffs2_is_writebuffered() macro.

Signed-off-by: Andrew Victor <andrew@sanpeople.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

show more ...


# 1da177e4 16-Apr-2005 Linus Torvalds <torvalds@ppc970.osdl.org>

Linux-2.6.12-rc2

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

Linux-2.6.12-rc2

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!

show more ...


12345