<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/include/linux/mtd/nand.h, branch v2014.07</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>mtd: nand: fix GET/SET_FEATURES address on 16-bit devices</title>
<updated>2014-06-06T21:46:05+00:00</updated>
<author>
<name>David Mosberger</name>
<email>davidm@egauge.net</email>
</author>
<published>2014-05-05T19:16:18+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=6e1899e633c2ac3f6da7101d4990361c6ff2a9d2'/>
<id>6e1899e633c2ac3f6da7101d4990361c6ff2a9d2</id>
<content type='text'>
As per following Sections in ONFI Spec, GET_FEATURES and SET_FEATURES also need
byte-addressing on 16-bit devices.

*Section: Target Initialization"
"The Read ID and Read Parameter Page commands only use the lower 8-bits of the
 data bus. The host shall not issue commands that use a word data width on x16
 devices until the host determines the device supports a 16-bit data bus width
 in the parameter page."

*Section: Bus Width Requirements*
"When the host supports a 16-bit bus width, only data is transferred at the
 16-bit width. All address and command line transfers shall use only the lower
 8-bits of the data bus. During command transfers, the host may place any value
 on the upper 8-bits of the data bus. During address transfers, the host shall
 set the upper 8-bits of the data bus to 00h."

So porting following commit from linux kernel
    commit e34fcb07a6d57411de6e15a47724fbe92c5caa42
    Author: David Mosberger &lt;davidm@egauge.net&gt;  (preserving authorship)
    mtd: nand: fix GET/SET_FEATURES address on 16-bit devices

Signed-off-by: Pekon Gupta &lt;pekon@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As per following Sections in ONFI Spec, GET_FEATURES and SET_FEATURES also need
byte-addressing on 16-bit devices.

*Section: Target Initialization"
"The Read ID and Read Parameter Page commands only use the lower 8-bits of the
 data bus. The host shall not issue commands that use a word data width on x16
 devices until the host determines the device supports a 16-bit data bus width
 in the parameter page."

*Section: Bus Width Requirements*
"When the host supports a 16-bit bus width, only data is transferred at the
 16-bit width. All address and command line transfers shall use only the lower
 8-bits of the data bus. During command transfers, the host may place any value
 on the upper 8-bits of the data bus. During address transfers, the host shall
 set the upper 8-bits of the data bus to 00h."

So porting following commit from linux kernel
    commit e34fcb07a6d57411de6e15a47724fbe92c5caa42
    Author: David Mosberger &lt;davidm@egauge.net&gt;  (preserving authorship)
    mtd: nand: fix GET/SET_FEATURES address on 16-bit devices

Signed-off-by: Pekon Gupta &lt;pekon@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: nand: force NAND_CMD_READID onto 8-bit bus</title>
<updated>2014-06-06T21:46:03+00:00</updated>
<author>
<name>Brian Norris</name>
<email>computersforpeace@gmail.com</email>
</author>
<published>2014-05-05T19:16:17+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=27ce9e4290b168a1241699d411678959aaf9649b'/>
<id>27ce9e4290b168a1241699d411678959aaf9649b</id>
<content type='text'>
As per following Sections in ONFI Spec, NAND_CMD_READID should use only
lower 8-bit for transfering command, address and data even on x16 NAND device.

*Section: Target Initialization"
"The Read ID and Read Parameter Page commands only use the lower 8-bits of the
 data bus. The host shall not issue commands that use a word data width on x16
 devices until the host determines the device supports a 16-bit data bus width
 in the parameter page."

*Section: Bus Width Requirements*
"When the host supports a 16-bit bus width, only data is transferred at the
 16-bit width. All address and command line transfers shall use only the lower
 8-bits of the data bus. During command transfers, the host may place any value
 on the upper 8-bits of the data bus. During address transfers, the host shall
 set the upper 8-bits of the data bus to 00h."

Thus porting  following commit from linux-kernel to ensure that column address
is not altered to align to x16 bus when issuing NAND_CMD_READID command.

    commit 3dad2344e92c6e1aeae42df1c4824f307c51bcc7
    mtd: nand: force NAND_CMD_READID onto 8-bit bus
    Author: Brian Norris &lt;computersforpeace@gmail.com&gt; (preserving authorship)

    The NAND command helpers tend to automatically shift the column address
    for x16 bus devices, since most commands expect a word address, not a
    byte address. The Read ID command, however, expects an 8-bit address
    (i.e., 0x00, 0x20, or 0x40 should not be translated to 0x00, 0x10, or
    0x20).

    This fixes the column address for a few drivers which imitate the
    nand_base defaults.

Signed-off-by: Pekon Gupta &lt;pekon@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As per following Sections in ONFI Spec, NAND_CMD_READID should use only
lower 8-bit for transfering command, address and data even on x16 NAND device.

*Section: Target Initialization"
"The Read ID and Read Parameter Page commands only use the lower 8-bits of the
 data bus. The host shall not issue commands that use a word data width on x16
 devices until the host determines the device supports a 16-bit data bus width
 in the parameter page."

*Section: Bus Width Requirements*
"When the host supports a 16-bit bus width, only data is transferred at the
 16-bit width. All address and command line transfers shall use only the lower
 8-bits of the data bus. During command transfers, the host may place any value
 on the upper 8-bits of the data bus. During address transfers, the host shall
 set the upper 8-bits of the data bus to 00h."

Thus porting  following commit from linux-kernel to ensure that column address
is not altered to align to x16 bus when issuing NAND_CMD_READID command.

    commit 3dad2344e92c6e1aeae42df1c4824f307c51bcc7
    mtd: nand: force NAND_CMD_READID onto 8-bit bus
    Author: Brian Norris &lt;computersforpeace@gmail.com&gt; (preserving authorship)

    The NAND command helpers tend to automatically shift the column address
    for x16 bus devices, since most commands expect a word address, not a
    byte address. The Read ID command, however, expects an 8-bit address
    (i.e., 0x00, 0x20, or 0x40 should not be translated to 0x00, 0x10, or
    0x20).

    This fixes the column address for a few drivers which imitate the
    nand_base defaults.

Signed-off-by: Pekon Gupta &lt;pekon@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: driver _read() returns max_bitflips; mtd_read() returns -EUCLEAN</title>
<updated>2013-10-09T17:52:04+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@imgtec.com</email>
</author>
<published>2013-09-04T14:16:56+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=40462e541d740e6af634fc793164e49317b38a11'/>
<id>40462e541d740e6af634fc793164e49317b38a11</id>
<content type='text'>
Linux modified the MTD driver interface in commit edbc4540 (with the
same name as this commit). The effect is that calls to mtd_read will
not return -EUCLEAN if the number of ECC-corrected bit errors is below
a certain threshold, which defaults to the strength of the ECC. This
allows -EUCLEAN to stop indicating "some bits were corrected" and begin
indicating "a large number of bits were corrected, the data held in
this region of flash may be lost soon". UBI makes use of this and when
-EUCLEAN is returned from mtd_read it will move data to another block
of flash. Without adopting this interface change UBI on U-boot attempts
to move data between blocks every time a single bit is corrected using
the ECC, which is a very common occurance on some devices.

For some devices where bit errors are common enough, UBI can get stuck
constantly moving data around because each block it attempts to use has
a single bit error. This condition is hit when wear_leveling_worker
attempts to move data from one PEB to another in response to an
-EUCLEAN/UBI_IO_BITFLIPS error. When this happens ubi_eba_copy_leb is
called to perform the data copy, and after the data is written it is
read back to check its validity. If that read returns UBI_IO_BITFLIPS
(in response to an MTD -EUCLEAN) then ubi_eba_copy_leb returns 1 to
wear_leveling worker, which then proceeds to schedule the destination
PEB for erasure. This leads to erase_worker running on the PEB, and
following a successful erase wear_leveling_worker is called which
begins this whole cycle all over again. The end result is that (without
UBI debug output enabled) the boot appears to simply hang whilst in
reality U-boot busily works away at destroying a block of the NAND
flash. Debug output from this situation:

  UBI DBG: ensure_wear_leveling: schedule scrubbing
  UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
  UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 1027
  UBI DBG: ubi_io_read: read 4096 bytes from PEB 1027:4096
  UBI DBG: ubi_eba_copy_leb: copy LEB 0:0, PEB 1027 to PEB 4083
  UBI DBG: ubi_eba_copy_leb: read 1040384 bytes of data
  UBI DBG: ubi_io_read: read 1040384 bytes from PEB 1027:8192
  UBI: fixable bit-flip detected at PEB 1027
  UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 4083
  UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:4096
  UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 4083
  UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:4096
  UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:8192
  UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:8192
  UBI: fixable bit-flip detected at PEB 4083
  UBI DBG: schedule_erase: schedule erasure of PEB 4083, EC 55, torture 0
  UBI DBG: erase_worker: erase PEB 4083 EC 55
  UBI DBG: sync_erase: erase PEB 4083, old EC 55
  UBI DBG: do_sync_erase: erase PEB 4083
  UBI DBG: sync_erase: erased PEB 4083, new EC 56
  UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 4083
  UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:0
  UBI DBG: ensure_wear_leveling: schedule scrubbing
  UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
  ...

This patch adopts the interface change as in Linux commit edbc4540 in
order to avoid such situations. Given that none of the drivers under
drivers/mtd return -EUCLEAN, this should only affect those using
software ECC. I have tested that it works on a board which is
currently out of tree, but which I hope to be able to begin
upstreaming soon.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
Acked-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Linux modified the MTD driver interface in commit edbc4540 (with the
same name as this commit). The effect is that calls to mtd_read will
not return -EUCLEAN if the number of ECC-corrected bit errors is below
a certain threshold, which defaults to the strength of the ECC. This
allows -EUCLEAN to stop indicating "some bits were corrected" and begin
indicating "a large number of bits were corrected, the data held in
this region of flash may be lost soon". UBI makes use of this and when
-EUCLEAN is returned from mtd_read it will move data to another block
of flash. Without adopting this interface change UBI on U-boot attempts
to move data between blocks every time a single bit is corrected using
the ECC, which is a very common occurance on some devices.

For some devices where bit errors are common enough, UBI can get stuck
constantly moving data around because each block it attempts to use has
a single bit error. This condition is hit when wear_leveling_worker
attempts to move data from one PEB to another in response to an
-EUCLEAN/UBI_IO_BITFLIPS error. When this happens ubi_eba_copy_leb is
called to perform the data copy, and after the data is written it is
read back to check its validity. If that read returns UBI_IO_BITFLIPS
(in response to an MTD -EUCLEAN) then ubi_eba_copy_leb returns 1 to
wear_leveling worker, which then proceeds to schedule the destination
PEB for erasure. This leads to erase_worker running on the PEB, and
following a successful erase wear_leveling_worker is called which
begins this whole cycle all over again. The end result is that (without
UBI debug output enabled) the boot appears to simply hang whilst in
reality U-boot busily works away at destroying a block of the NAND
flash. Debug output from this situation:

  UBI DBG: ensure_wear_leveling: schedule scrubbing
  UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
  UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 1027
  UBI DBG: ubi_io_read: read 4096 bytes from PEB 1027:4096
  UBI DBG: ubi_eba_copy_leb: copy LEB 0:0, PEB 1027 to PEB 4083
  UBI DBG: ubi_eba_copy_leb: read 1040384 bytes of data
  UBI DBG: ubi_io_read: read 1040384 bytes from PEB 1027:8192
  UBI: fixable bit-flip detected at PEB 1027
  UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 4083
  UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:4096
  UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 4083
  UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:4096
  UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:8192
  UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:8192
  UBI: fixable bit-flip detected at PEB 4083
  UBI DBG: schedule_erase: schedule erasure of PEB 4083, EC 55, torture 0
  UBI DBG: erase_worker: erase PEB 4083 EC 55
  UBI DBG: sync_erase: erase PEB 4083, old EC 55
  UBI DBG: do_sync_erase: erase PEB 4083
  UBI DBG: sync_erase: erased PEB 4083, new EC 56
  UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 4083
  UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:0
  UBI DBG: ensure_wear_leveling: schedule scrubbing
  UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
  ...

This patch adopts the interface change as in Linux commit edbc4540 in
order to avoid such situations. Given that none of the drivers under
drivers/mtd return -EUCLEAN, this should only affect those using
software ECC. I have tested that it works on a board which is
currently out of tree, but which I hope to be able to begin
upstreaming soon.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
Acked-by: Stefan Roese &lt;sr@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: resync with Linux-3.7.1</title>
<updated>2013-05-31T22:12:03+00:00</updated>
<author>
<name>Sergey Lapin</name>
<email>slapin@ossfans.org</email>
</author>
<published>2013-01-14T03:46:50+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=dfe64e2c89731a3f9950d7acd8681b68df2bae03'/>
<id>dfe64e2c89731a3f9950d7acd8681b68df2bae03</id>
<content type='text'>
This patch is essentially an update of u-boot MTD subsystem to
the state of Linux-3.7.1 with exclusion of some bits:

- the update is concentrated on NAND, no onenand or CFI/NOR/SPI
flashes interfaces are updated EXCEPT for API changes.

- new large NAND chips support is there, though some updates
have got in Linux-3.8.-rc1, (which will follow on top of this patch).

To produce this update I used tag v3.7.1 of linux-stable repository.

The update was made using application of relevant patches,
with changes relevant to U-Boot-only stuff sticked together
to keep bisectability. Then all changes were grouped together
to this patch.

Signed-off-by: Sergey Lapin &lt;slapin@ossfans.org&gt;
[scottwood@freescale.com: some eccstrength and build fixes]
Signed-off-by: Scott Wood &lt;scottwood@freescale.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch is essentially an update of u-boot MTD subsystem to
the state of Linux-3.7.1 with exclusion of some bits:

- the update is concentrated on NAND, no onenand or CFI/NOR/SPI
flashes interfaces are updated EXCEPT for API changes.

- new large NAND chips support is there, though some updates
have got in Linux-3.8.-rc1, (which will follow on top of this patch).

To produce this update I used tag v3.7.1 of linux-stable repository.

The update was made using application of relevant patches,
with changes relevant to U-Boot-only stuff sticked together
to keep bisectability. Then all changes were grouped together
to this patch.

Signed-off-by: Sergey Lapin &lt;slapin@ossfans.org&gt;
[scottwood@freescale.com: some eccstrength and build fixes]
Signed-off-by: Scott Wood &lt;scottwood@freescale.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Consolidate bool type</title>
<updated>2013-04-01T20:33:52+00:00</updated>
<author>
<name>York Sun</name>
<email>yorksun@freescale.com</email>
</author>
<published>2013-04-01T18:29:11+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=472d546054dadacca91530bad42ad06f6408124e'/>
<id>472d546054dadacca91530bad42ad06f6408124e</id>
<content type='text'>
'bool' is defined in random places. This patch consolidates them into a
single header file include/linux/types.h, using stdbool.h introduced in C99.

All other #define, typedef and enum are removed. They are all consistent with
true = 1, false = 0.

Replace FALSE, False with false. Replace TRUE, True with true.
Skip *.py, *.php, lib/* files.

Signed-off-by: York Sun &lt;yorksun@freescale.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
'bool' is defined in random places. This patch consolidates them into a
single header file include/linux/types.h, using stdbool.h introduced in C99.

All other #define, typedef and enum are removed. They are all consistent with
true = 1, false = 0.

Replace FALSE, False with false. Replace TRUE, True with true.
Skip *.py, *.php, lib/* files.

Signed-off-by: York Sun &lt;yorksun@freescale.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nand: Move the sub-page read support enable to a flag</title>
<updated>2012-11-26T21:41:28+00:00</updated>
<author>
<name>Joe Hershberger</name>
<email>joe.hershberger@ni.com</email>
</author>
<published>2012-11-05T06:46:31+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=c788ecfdc3eb577757ffc1bfb8416added07ef33'/>
<id>c788ecfdc3eb577757ffc1bfb8416added07ef33</id>
<content type='text'>
Use a flag instead of a hard-coded macro so that sub-page reads can be
enabled in other cases (such as on-die ecc).

This is the same as a5ff4f102937a3492bca4a9ff0c341d78813414c in Linux

Signed-off-by: Joe Hershberger &lt;joe.hershberger@ni.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use a flag instead of a hard-coded macro so that sub-page reads can be
enabled in other cases (such as on-die ecc).

This is the same as a5ff4f102937a3492bca4a9ff0c341d78813414c in Linux

Signed-off-by: Joe Hershberger &lt;joe.hershberger@ni.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'master' of git://git.denx.de/u-boot-arm</title>
<updated>2012-09-21T21:53:13+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@ti.com</email>
</author>
<published>2012-09-21T21:53:13+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=495dbd72dd1172de866ba323263a5b62cf454972'/>
<id>495dbd72dd1172de866ba323263a5b62cf454972</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver</title>
<updated>2012-09-17T23:54:43+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@denx.de</email>
</author>
<published>2012-08-30T13:39:38+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=9c790a748f6b61e36f7aaf0c8d5ed35c9b09f454'/>
<id>9c790a748f6b61e36f7aaf0c8d5ed35c9b09f454</id>
<content type='text'>
This is based on Linux kernel -next:

commit 14f44abf1dafc20ba42ce8616a8fc8fbd1b3712b
Author: Brian Norris &lt;computersforpeace@gmail.com&gt;
Date:   Fri Jul 13 09:28:24 2012 -0700

    mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver

    The NAND_CHIPOPTIONS_MSK has limited utility and is causing real bugs. It
    silently masks off at least one flag that might be set by the driver
    (NAND_NO_SUBPAGE_WRITE). This breaks the GPMI NAND driver and possibly
    others.

    Really, as long as driver writers exercise a small amount of care with
    NAND_* options, this mask is not necessary at all; it was only here to
    prevent certain options from accidentally being set by the driver. But the
    original thought turns out to be a bad idea occasionally. Thus, kill it.

    Note, this patch fixes some major gpmi-nand breakage.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Brian Norris &lt;computersforpeace@gmail.com&gt;
Cc: Eric Nelson &lt;eric.nelson@boundarydevices.com&gt;
Cc: Fabio Estevam &lt;festevam@gmail.com&gt;
Cc: Otavio Salvador &lt;otavio@ossystems.com.br&gt;
Cc: Scott Wood &lt;scottwood@freescale.com&gt;
Signed-off-by: Scott Wood &lt;scottwood@freescale.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is based on Linux kernel -next:

commit 14f44abf1dafc20ba42ce8616a8fc8fbd1b3712b
Author: Brian Norris &lt;computersforpeace@gmail.com&gt;
Date:   Fri Jul 13 09:28:24 2012 -0700

    mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver

    The NAND_CHIPOPTIONS_MSK has limited utility and is causing real bugs. It
    silently masks off at least one flag that might be set by the driver
    (NAND_NO_SUBPAGE_WRITE). This breaks the GPMI NAND driver and possibly
    others.

    Really, as long as driver writers exercise a small amount of care with
    NAND_* options, this mask is not necessary at all; it was only here to
    prevent certain options from accidentally being set by the driver. But the
    original thought turns out to be a bad idea occasionally. Thus, kill it.

    Note, this patch fixes some major gpmi-nand breakage.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Brian Norris &lt;computersforpeace@gmail.com&gt;
Cc: Eric Nelson &lt;eric.nelson@boundarydevices.com&gt;
Cc: Fabio Estevam &lt;festevam@gmail.com&gt;
Cc: Otavio Salvador &lt;otavio@ossystems.com.br&gt;
Cc: Scott Wood &lt;scottwood@freescale.com&gt;
Signed-off-by: Scott Wood &lt;scottwood@freescale.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nand: consolidate duplicated constants</title>
<updated>2012-09-17T22:33:42+00:00</updated>
<author>
<name>Joe Hershberger</name>
<email>joe.hershberger@ni.com</email>
</author>
<published>2012-08-22T21:49:44+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=33b1d5cae3defdbeb30333ffac41bcbff85c5019'/>
<id>33b1d5cae3defdbeb30333ffac41bcbff85c5019</id>
<content type='text'>
NAND_CMD_ constants for lock/unlock should be in the header

Signed-off-by: Joe Hershberger &lt;joe.hershberger@ni.com&gt;
Signed-off-by: Scott Wood &lt;scottwood@freescale.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
NAND_CMD_ constants for lock/unlock should be in the header

Signed-off-by: Joe Hershberger &lt;joe.hershberger@ni.com&gt;
Signed-off-by: Scott Wood &lt;scottwood@freescale.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nand: Try to align the default buffers</title>
<updated>2012-09-07T20:54:30+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2012-07-29T20:53:25+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=b572595ee95829ab62e354c55a8fbd0f4db23935'/>
<id>b572595ee95829ab62e354c55a8fbd0f4db23935</id>
<content type='text'>
The NAND layer needs to use cache-aligned buffers by default. Towards this
goal. align the default buffers and their members according to the minimum
DMA alignment defined for the architecture.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Tom Warren &lt;twarren@nvidia.com&gt;
Acked-by: Scott Wood &lt;scottwood@freescale.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The NAND layer needs to use cache-aligned buffers by default. Towards this
goal. align the default buffers and their members according to the minimum
DMA alignment defined for the architecture.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Tom Warren &lt;twarren@nvidia.com&gt;
Acked-by: Scott Wood &lt;scottwood@freescale.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
