aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
diff options
context:
space:
mode:
authorArtem Bityutskiy <artem.bityutskiy@linux.intel.com>2012-05-14 12:49:35 -0400
committerArtem Bityutskiy <artem.bityutskiy@linux.intel.com>2012-05-20 13:25:59 -0400
commit4415626732defb5a4567a0a757c7c5baae7ca846 (patch)
tree31b02e4a1882d243f5fbc8599dae8fac66d917fb /drivers
parenta65a0eb6d198e058687a9214683bd1c418f20d39 (diff)
UBI: amend commentaries WRT dtype
Richard removed the "dtype" hint, but few commentaries were left and this patch removes them. I've also added a better description about the "dtype" field in the ubi-user.h for people who may ever wonder what was that dtype thing about. This patch also adds an important note that it is better to use value "3" for the "dtype" field. Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Diffstat (limited to 'drivers')
-rw-r--r--drivers/mtd/ubi/wl.c9
1 files changed, 1 insertions, 8 deletions
diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index f0bc10743bc0..64ce9930dacb 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -41,12 +41,6 @@
41 * physical eraseblocks with low erase counter to free physical eraseblocks 41 * physical eraseblocks with low erase counter to free physical eraseblocks
42 * with high erase counter. 42 * with high erase counter.
43 * 43 *
44 * The 'ubi_wl_get_peb()' function accepts data type hints which help to pick
45 * an "optimal" physical eraseblock. For example, when it is known that the
46 * physical eraseblock will be "put" soon because it contains short-term data,
47 * the WL sub-system may pick a free physical eraseblock with low erase
48 * counter, and so forth.
49 *
50 * If the WL sub-system fails to erase a physical eraseblock, it marks it as 44 * If the WL sub-system fails to erase a physical eraseblock, it marks it as
51 * bad. 45 * bad.
52 * 46 *
@@ -70,8 +64,7 @@
70 * to the user; instead, we first want to let users fill them up with data; 64 * to the user; instead, we first want to let users fill them up with data;
71 * 65 *
72 * o there is a chance that the user will put the physical eraseblock very 66 * o there is a chance that the user will put the physical eraseblock very
73 * soon, so it makes sense not to move it for some time, but wait; this is 67 * soon, so it makes sense not to move it for some time, but wait.
74 * especially important in case of "short term" physical eraseblocks.
75 * 68 *
76 * Physical eraseblocks stay protected only for limited time. But the "time" is 69 * Physical eraseblocks stay protected only for limited time. But the "time" is
77 * measured in erase cycles in this case. This is implemented with help of the 70 * measured in erase cycles in this case. This is implemented with help of the