Re: [PATCH v5 0/4] mtd:nand:omap2: clean-up of supported ECC schemes
On Tue, 2013-08-20 at 13:20 +, Gupta, Pekon wrote: Hi Artem, Brian, I'll try to go through old e-mails now, and especially ubi/ubifs ones, including yours, and I'll let Brian handle your patches, if I can? :-) I checked them, and they looked good to me: Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mtd: nand: omap2: Fix compilation warning
On Wed, 2013-07-24 at 17:48 +, Gupta, Pekon wrote: Hi Olof, fb1585bc13b (mtd: nand: omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe) introduced a warning when the new option is disabled, i.e. with omap2plus_defconfig: drivers/mtd/nand/omap2.c:1075:13: warning: 'omap3_enable_hwecc_bch' defined but not used [-Wunused-function] Fix this by rescoping the ifdef. Also remove a redudant #endif/#ifdef pair. Signed-off-by: Olof Johansson o...@lixom.net --- Thanks much.. But just to remind, this commit fb1585b in linux-next needs to be reverted. This patch is leftover by mistake because other dependent patches of this series were dropped. This will not only break omap2-nand driver, but might also break the build. Just dropped it, thanks! -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 0/4] mtd: nand: omap: add support for BCH16_ECC
On Thu, 2013-07-18 at 01:22 +0530, Pekon Gupta wrote: This patch series add support of BCH16_ECC scheme. As BCH16_ECC scheme generates 26bytes of ECC syndrome per 512B data, hence this scheme is usable only for NAND devices having 4K or above page-size, as their OOB/spare area has enough space to accomodate ECC. This patch series is applicable over an above following series: [1] [Patch] mtd:nand:omap2: clean-up of supported ECC schemes http://lists.infradead.org/pipermail/linux-mtd/2013-July/047530.html [2] [Patch] optimize and clean-up of OMAP NAND and ELM driver http://lists.infradead.org/pipermail/linux-mtd/2013-July/047538.html Also this BCH16_ECC patch series is sparsely tested, due to limited availability of boards with 4K/224NAND, so request the users to test the mentioned series, and provide Tested-by. I wonder if anyone in the list could help reviewing this? -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/4] mtd:nand:omap2: clean-up of supported ECC schemes
On Wed, 2013-07-03 at 13:16 +, Gupta, Pekon wrote: [Pekon]: Yes, I'm not seeing these build issues, as I'm cleanly returning from probe with pr_err(), if the required libraries (/lib/bch.c) are not build-in the system. --- [Patch v4 1/4]: mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC.. @@static int omap_nand_probe(struct platform_device *pdev) + default: + pr_err(selected ECC scheme not supported or not enabled\n); + err = -EINVAL; + goto out_release_mem_region; + } --- However, if you are still seeing this, could you please send me your config? I compile tested your patches too, and did not see any issues with my omap2_defconfig. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] mtd: devices: elm: Low power transition support
On Tue, 2013-06-18 at 00:16 +0530, Pekon Gupta wrote: From: avinash philip avinashphi...@ti.com ELM is used for locating bit-flip errors in when using BCH ECC scheme. This patch adds suspend/resume support for leaf level ELM driver, And also provides ELM register context save restore support, so that configurations are preserved across hardware power-off/on transitions. Signed-off-by: Philip Avinash avinashphi...@ti.com Signed-off-by: Pekon Gupta pe...@ti.com Pushed to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe
Hi Pekon, On Sun, 2013-06-23 at 23:28 +0530, Pekon Gupta wrote: +---+---+---+ | ECC scheme |ECC calculation|Error detection| +---+---+---+ |OMAP_ECC_HAMMING_CODE_DEFAULT|S/W|S/W | |OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W| |OMAP_ECC_HAMMING_CODE_HW_ROMCODE |H/W (GPMC) |S/W| +---+---+---+ |(requires CONFIG_MTD_NAND_ECC_BCH) | | | |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W| +---+---+---+ |(requires CONFIG_MTD_NAND_OMAP_BCH) | | | |OMAP_ECC_BCH8_CODE_HW|H/W (GPMC) |H/W (ELM) | +---+---+---+ This is a nice table, and you are doing very good job clearly classifying what is going on. I'd suggest to also put stuff like this to comments in the code. This patch - separates the configurations for various ECC schemes. - fixes dependency issues based on Kconfig options. - cleans up redundant code Signed-off-by: Pekon Gupta pe...@ti.com This does not apply to l2-mtd.git, could you please re-base? -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/4] mtd:nand:omap2: clean-up of supported ECC schemes
On Mon, 2013-07-01 at 15:21 +0530, Pekon Gupta wrote: +---+---+---+ | ECC scheme |ECC calculation|Error detection| +---+---+---+ |OMAP_ECC_HAMMING_CODE_DEFAULT|S/W|S/W | |OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W| |OMAP_ECC_HAMMING_CODE_HW_ROMCODE |H/W (GPMC) |S/W| +---+---+---+ |OMAP_ECC_BCH4_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)| |OMAP_ECC_BCH4_CODE_HW|H/W (GPMC) |H/W (ELM) | +---+---+---+ |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)| |OMAP_ECC_BCH8_CODE_HW|H/W (GPMC) |H/W (ELM) | +---+---+---+ Pushed patches 1-3 to l2-mtd.git, thanks. I had to fix the table because you use tabs there, and git log makes the table look messy. Please, use spaces instead next time. Thanks! -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MTD : cannot reserve enough PEBs for bad PEB handling
On Mon, 2013-04-22 at 10:38 +0100, Mark Jackson wrote: I'm trying to work out how to generate a valid UBI image, but I keep getting a cannot get enough PEBs warning. I generate my image (destined for a 64MB NAND partition) using:- $ mkfs.ubifs -d output/target -e 0x1f000 -c 483 -m 0x800 -x none -F -o output/images/rootfs.ubifs $ ubinize -o output/images/rootfs.ubi -m 0x800 -p 0x2 -s 512 -O 2048 ubinize.cfg My .cfg file is:- [ubifs] mode=ubi vol_id=0 vol_type=dynamic vol_name=rootfs vol_alignment=1 vol_flags=autoresize vol_size=61MiB image=output/images/rootfs.ubifs And the resulting image is:- -rw-rw-r-- 1 mpfj mpfj 9437184 Apr 16 10:19 rootfs.ubi This is then written to a freshly erased 64MB NAND partition, and appears to mount correctly, apart from the warning about not enough reserved PEBs, as follows:- ... [0.792456] UBI: attaching mtd7 to ubi0 [1.540858] UBI: scanning is finished [1.557578] UBI warning: print_rsvd_warning: cannot reserve enough PEBs for bad PEB handling, reserved 4, need 40 [1.561346] UBI: attached mtd7 (name rootfs, size 64 MiB) to ubi0 [1.561404] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes [1.561434] UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512 [1.561464] UBI: VID header offset: 2048 (aligned 2048), data offset: 4096 [1.561493] UBI: good PEBs: 512, bad PEBs: 0, corrupted PEBs: 0 [1.561520] UBI: user volume: 1, internal volumes: 1, max. volumes count: 128 [1.561554] UBI: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 1434266085 [1.561591] UBI: available PEBs: 0, total reserved PEBs: 512, PEBs reserved for bad PEB handling: 4 [1.562374] UBI: background thread ubi_bgt0d started, PID 598 ... I think I've calculated the various option values correctly for mkfs.ubifs and ubinize. But since I'm getting the warning, can anyone explain where I've gone wrong ? This is because UBI is trying to reserve 40 PEBs for bad block handling. Why so much? See the explanations here: http://www.linux-mtd.infradead.org/doc/ubi.html#L_max_beb You may adjust this value, but the default for UBI is the most pessimistic scenario. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MTD : Kernel oops when remounting ubifs as read/write
On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
Sorry ... this just locks up the unit.
OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
below. The patch I proposed did not get the error path correctly, but it
does fix the issue.
I think what you treat as lockup is the fixup process. UBIFS basically
reads the entire UBI volume and writes it back. And it uses the atomic
change UBI service, which means it also calculates CRC of everything it
writes. And this all just takes a lot of time. This has to be done only
once on the first mount.
I've attached the following:
1. The patch which fixes the issue when I use nandsim. It is also
inlined in the end. Please, give it a try and be more patient -
wait longer. Please, do report your results back.
2. 'reproduce.sh' - a quick and dirty shell script which reproduces the
problem
3. ubinize.cfg - is needed for 'reproduce.sh'.
Thanks!
From a173f8e9296562e5ece3dd2936d799001897d6c6 Mon Sep 17 00:00:00 2001
From: Artem Bityutskiy artem.bityuts...@linux.intel.com
Date: Thu, 14 Mar 2013 10:49:23 +0200
Subject: [PATCH] UBIFS: make space fixup work in the remount case
The UBIFS space fixup is a useful feature which allows to fixup the broken
flash space at the time of the first mount. The broken space is usually the
result of using a dumb industrial flasher which is not able to skip empty
NAND pages and just writes all 0xFFs to the empty space, which has grave
side-effects for UBIFS when UBIFS trise to write useful data to those empty
pages.
The fix-up feature works roughly like this:
1. mkfs.ubifs sets the fixup flag in UBIFS superblock when creating the image
(see -F option)
2. when the file-system is mounted for the first time, UBIFS notices the fixup
flag and re-writes the entire media atomically, which may take really a lot
of time.
3. UBIFS clears the fixup flag in the superblock.
This works fine when the file system is mounted R/W for the very first time.
But it did not really work in the case when we first mount the file-system R/O,
and then re-mount R/W. The reason was that we started the fixup procedure too
late, which we cannot really do because we have to fixup the space before it
starts being used.
Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
Reported-by: Mark Jackson mpfj-l...@mimc.co.uk
Cc: sta...@vger.kernel.org # 3.0+
---
fs/ubifs/super.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index ac838b8..fa4aec6 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1568,10 +1568,17 @@ static int ubifs_remount_rw(struct ubifs_info *c)
c-remounting_rw = 1;
c-ro_mount = 0;
+ if (c-space_fixup) {
+ err = ubifs_fixup_free_space(c);
+ if (err)
+ return err;
+ }
+
err = check_free_space(c);
if (err)
goto out;
+
if (c-old_leb_cnt != c-leb_cnt) {
struct ubifs_sb_node *sup;
@@ -1684,12 +1691,6 @@ static int ubifs_remount_rw(struct ubifs_info *c)
err = dbg_check_space_info(c);
}
- if (c-space_fixup) {
- err = ubifs_fixup_free_space(c);
- if (err)
- goto out;
- }
-
mutex_unlock(c-umount_mutex);
return err;
--
1.7.7.6
--
Best Regards,
Artem Bityutskiy
From a173f8e9296562e5ece3dd2936d799001897d6c6 Mon Sep 17 00:00:00 2001
From: Artem Bityutskiy artem.bityuts...@linux.intel.com
Date: Thu, 14 Mar 2013 10:49:23 +0200
Subject: [PATCH] UBIFS: make space fixup work in the remount case
The UBIFS space fixup is a useful feature which allows to fixup the broken
flash space at the time of the first mount. The broken space is usually the
result of using a dumb industrial flasher which is not able to skip empty
NAND pages and just writes all 0xFFs to the empty space, which has grave
side-effects for UBIFS when UBIFS trise to write useful data to those empty
pages.
The fix-up feature works roughly like this:
1. mkfs.ubifs sets the fixup flag in UBIFS superblock when creating the image
(see -F option)
2. when the file-system is mounted for the first time, UBIFS notices the fixup
flag and re-writes the entire media atomically, which may take really a lot
of time.
3. UBIFS clears the fixup flag in the superblock.
This works fine when the file system is mounted R/W for the very first time.
But it did not really work in the case when we first mount the file-system R/O,
and then re-mount R/W. The reason was that we started the fixup procedure too
late, which we cannot really do because we have to fixup the space before it
starts being used.
Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
Cc: sta...@vger.kernel.org # 3.0+
---
fs/ubifs/super.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index
Re: MTD : Kernel oops when remounting ubifs as read/write
On Thu, 2013-03-14 at 09:54 +, Mark Jackson wrote: On 14/03/13 09:13, Artem Bityutskiy wrote: On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote: Sorry ... this just locks up the unit. OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details below. The patch I proposed did not get the error path correctly, but it does fix the issue. I think what you treat as lockup is the fixup process. UBIFS basically reads the entire UBI volume and writes it back. And it uses the atomic change UBI service, which means it also calculates CRC of everything it writes. And this all just takes a lot of time. This has to be done only once on the first mount. Okay ... I've retried, but how long is a lot of time ? I've waited 15 minutes and still nothing. And I can see that there's no activity on the NAND chip select !?! I'll put some debug info into the fixup routines to see if I can trace what's going on. Just to make sure - try this last patch I sent. I did test it with nandsim at least, and I am sure it works. I did not test at all the first one. And yes, debug messages would be useful, just do not forget to add the 'ignore_loglevel' kernel boot option, otherwise you won't see the messages on your console, since they are of KERN_DEBUG level. You may have other issues which cause lockup, e.g., in driver level. It makes sense to validate your flash with MTD test modules. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MTD : Kernel oops when remounting ubifs as read/write
On Thu, 2013-03-14 at 11:15 +, Mark Jackson wrote: [ 28.538525] [d08ea004] *pgd=8f045811, *pte=, *ppte= [ 28.545173] Internal error: Oops: 7 [#1] ARM [ 28.549685] CPU: 0Not tainted (3.8.0-next-20130225-2-g678576f-dirty #40) [ 28.557595] PC is at crc32_le+0x50/0x168 [ 28.561735] LR is at ubi_eba_atomic_leb_change+0x1b4/0x410 [ 28.567523] pc : [c01e7244]lr : [c026dd9c]psr: 2013 [ 28.567523] sp : cf385de0 ip : 180a985a fp : c054f840 [ 28.579632] r10: c054f040 r9 : c054fc40 r8 : 158a1232 [ 28.585141] r7 : 4d506705 r6 : 9324fd72 r5 : 4dc8a10b r4 : 4c162691 [ 28.592025] r3 : c054e040 r2 : c054f440 r1 : d08ea000 r0 : 4c8ee09f [ 28.598912] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 28.606439] Control: 10c5387d Table: 8f3b8019 DAC: 0015 [ 28.612501] Process mount (pid: 659, stack limit = 0xcf384238) [ 28.618652] Stack: (0xcf385de0 to 0xcf386000) [ 28.623254] 5de0: cf2f8554 d08e6e8c 180a9e88 5a257c4f 58399ee9 c8d98a08 bb0ee864 [ 28.631886] 5e00: eae10678 c054fc40 c054f040 c054f840 cf2f8000 d08caffc 3c00 [ 28.640517] 5e20: cf2f8000 cf357c00 000c cf2ec000 000c cf2f8554 [ 28.649148] 5e40: d08cb000 0001e000 d08cb000 8000 0001e000 [ 28.657779] 5e60: 000c d08cb000 0080 000c 000c 0020 [ 28.666409] 5e80: 8000 c026c41c 0001e000 cf33 cf33 d08cb000 0001e000 c0179b14 [ 28.675042] 5ea0: 000d c0177a68 0001e000 cf33 cf330b20 000d c0179698 [ 28.683672] 5ec0: cf33 cf330a9c cf385f48 c0175170 0001 6013 [ 28.692303] 5ee0: cf32c800 cf385f48 0020 c00c9e24 [ 28.700934] 5f00: 00100100 00200200 cf3a6c80 8000 cf384000 00208020 cf01a200 [ 28.709564] 5f20: cf32c800 c00e3d6c 000c cf32c840 c0013968 cf31fb80 [ 28.718195] 5f40: 000c cf01a210 ce828858 000c cf3ac000 000a18b4 [ 28.726827] 5f60: 00208020 c0013968 cf384000 0003 c00e3e40 c0071e24 [ 28.735459] 5f80: cf31fb80 cf31fbc0 a010 bed87b68 b6ff148c [ 28.744091] 5fa0: 0015 c00137c0 bed87b68 000a18b4 000a18c0 000a18c2 00208020 [ 28.752720] 5fc0: bed87b68 b6ff148c 0015 0003 [ 28.761350] 5fe0: b6fa3f48 bed87a64 00042994 b6fa3f58 a010 000a18b4 [ 28.769989] [c01e7244] (crc32_le+0x50/0x168) from [cf2f8000] (0xcf2f8000) [ 28.777522] Code: e58d8008 0a26 e1a0c005 e58d2004 (e5916004) [ 28.784029] ---[ end trace f50f53afffe647f1 ]--- OK, this is an independent problem which, as I think, has nothing to do with the first one. I do not know why crc32 oopses on your system. You need to investigate this. I believe this is not UBI/UBIFS's fault. One theory could be that UBI uses vmalloc'ed buffers for the atomic update operation, and submits the buffer to the MTD layer for the I/O. If your NAND driver is trying to DMA this memory, you may be in trouble, because vmalloced memory is often not DMA-able on many systems, especially ARM systems which do not have coherent cache support. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MTD : Kernel oops when remounting ubifs as read/write
On Thu, 2013-03-14 at 12:02 +, Mark Jackson wrote: But there's also a call to crc with a size of 122880 bytes, and that's when the oops occurs. This is when we do the atomic LEB change. Is this size larger than the allocated buffer ? I believe so. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MTD : Kernel oops when remounting ubifs as read/write
On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
- if (c-space_fixup) {
- err = ubifs_fixup_free_space(c);
- if (err)
- goto out;
- }
-
mutex_unlock(c-umount_mutex);
return err;
Sorry ... this just locks up the unit.
Am I right that to reproduce it I need any image with the 'fixup' flag
set, then I should put it on the flash, mount it R/O and then remount
R/W. Right?
--
Best Regards,
Artem Bityutskiy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MTD : Kernel oops when remounting ubifs as read/write
On Mon, 2013-03-04 at 16:42 +, Mark Jackson wrote:
I'm encountering an oops when remounting my ubifs volume as read/write.
# mount -o remount,rw /
[ 89.434974] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
[ 89.442122] [c001b124] (unwind_backtrace+0x0/0xf0) from [c01ad7d4]
(ubifs_write_node+0x180/0x1c4)
[ 89.451896] [c01ad7d4] (ubifs_write_node+0x180/0x1c4) from [c01b3878]
(ubifs_write_master+0x9c/0x134)
[ 89.462018] [c01b3878] (ubifs_write_master+0x9c/0x134) from [c01a79a4]
(ubifs_remount_fs+0x5d4/0x7f8)
[ 89.472133] [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8) from [c010dbf4]
(do_remount_sb+0x98/0x16c)
[ 89.481790] [c010dbf4] (do_remount_sb+0x98/0x16c) from [c0128268]
(do_mount+0x830/0x888)
[ 89.490708] [c0128268] (do_mount+0x830/0x888) from [c0128344]
(sys_mount+0x84/0xb8)
[ 89.499178] [c0128344] (sys_mount+0x84/0xb8) from [c0013800]
(ret_fast_syscall+0x0/0x3c)
[ 89.510997] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
[ 89.517884] [c001b124] (unwind_backtrace+0x0/0xf0) from [c01ad7d4]
(ubifs_write_node+0x180/0x1c4)
[ 89.527641] [c01ad7d4] (ubifs_write_node+0x180/0x1c4) from [c01b38b4]
(ubifs_write_master+0xd8/0x134)
[ 89.537760] [c01b38b4] (ubifs_write_master+0xd8/0x134) from [c01a79a4]
(ubifs_remount_fs+0x5d4/0x7f8)
[ 89.547869] [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8) from [c010dbf4]
(do_remount_sb+0x98/0x16c)
[ 89.557526] [c010dbf4] (do_remount_sb+0x98/0x16c) from [c0128268]
(do_mount+0x830/0x888)
[ 89.566435] [c0128268] (do_mount+0x830/0x888) from [c0128344]
(sys_mount+0x84/0xb8)
[ 89.574905] [c0128344] (sys_mount+0x84/0xb8) from [c0013800]
(ret_fast_syscall+0x0/0x3c)
[ 89.585939] UBIFS: start fixing up free space
[ 89.592237] UBIFS: background thread ubifs_bgt0_0 started, PID 629
[ 91.419951] UBIFS: free space fixup complete
#
If it's any help, if the remount is put into my inittab, I don't get any oops.
Would you please try this patch (also attached):
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index ac838b8..9791b3c 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1568,6 +1568,12 @@ static int ubifs_remount_rw(struct ubifs_info *c)
c-remounting_rw = 1;
c-ro_mount = 0;
+ if (c-space_fixup) {
+ err = ubifs_fixup_free_space(c);
+ if (err)
+ goto out;
+ }
+
err = check_free_space(c);
if (err)
goto out;
@@ -1684,12 +1690,6 @@ static int ubifs_remount_rw(struct ubifs_info *c)
err = dbg_check_space_info(c);
}
- if (c-space_fixup) {
- err = ubifs_fixup_free_space(c);
- if (err)
- goto out;
- }
-
mutex_unlock(c-umount_mutex);
return err;
--
Best Regards,
Artem Bityutskiy
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index ac838b8..9791b3c 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1568,6 +1568,12 @@ static int ubifs_remount_rw(struct ubifs_info *c)
c-remounting_rw = 1;
c-ro_mount = 0;
+ if (c-space_fixup) {
+ err = ubifs_fixup_free_space(c);
+ if (err)
+ goto out;
+ }
+
err = check_free_space(c);
if (err)
goto out;
@@ -1684,12 +1690,6 @@ static int ubifs_remount_rw(struct ubifs_info *c)
err = dbg_check_space_info(c);
}
- if (c-space_fixup) {
- err = ubifs_fixup_free_space(c);
- if (err)
- goto out;
- }
-
mutex_unlock(c-umount_mutex);
return err;
Re: [PATCH 1/3] mtd: omap-onenand: pass device_node in platform data
On Tue, 2013-01-15 at 19:48 -0300, Ezequiel Garcia wrote: I saw you have acked the gpmc patch on nand. Can I add your Acked-by on this one, when I send the rebased patch set? Yes, I saw this series which depends on Daniel Mack's work. It looks good. You can add Acked-by: Artem Bityutskiy artem.bityuts...@linux.intel.com -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v4 0/3] mtd: nand: OMAP: ELM error correction support for BCH ecc
On Wed, 2013-01-16 at 12:22 +, Philip, Avinash wrote: This series is based on linux 3.8-rc2 and tested with [1]. Also this patch series depend on [1] for NAND flash device tree data and gpmc nand device tree binding documentation updates. 1. [PATCH v7 0/5] OMAP GPMC DT bindings http://www.spinics.net/lists/linux-omap/msg83505.html Tested on am335x-evm for BCH 4 and 8 bit error correction. Can you apply this patch series on l2-mtd tree as it will help RBL compatibility ecc layout for NAND flash in am335x-platforms and hardware based BCH error correction. OK, I've applied them. I dropped the part that updates the documentation. Please, handle it separately when Daniel's patches are in. Pushed to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v8 2/5] mtd: omap-nand: pass device_node in platform data
On Tue, 2013-01-15 at 10:52 -0800, Tony Lindgren wrote: Artem, Looks like this patch related to making GPMC work with DT was never sent to linux-mtd or to you so adding to cc. Is this OK to apply along with the GPMC patches, or do you want to take this separately with the MTD patches? Please, go ahead! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v8 2/5] mtd: omap-nand: pass device_node in platform data
On Tue, 2013-01-15 at 11:26 -0800, Tony Lindgren wrote: * Artem Bityutskiy dedeki...@gmail.com [130115 11:12]: On Tue, 2013-01-15 at 10:52 -0800, Tony Lindgren wrote: Artem, Looks like this patch related to making GPMC work with DT was never sent to linux-mtd or to you so adding to cc. Is this OK to apply along with the GPMC patches, or do you want to take this separately with the MTD patches? Please, go ahead! OK thanks. Can I add your Acked-by too? Yes Tony, please, do: Acked-by: Artem Bityutskiy dedeki...@gmail.com -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
On Tue, 2012-11-06 at 11:51 +0100, Matthieu CASTET wrote: - NAND_CMD_READID want an address that it is not scaled on x16 device (it is always 0x20) - NAND_CMD_PARAM want 8 bits data Signed-off-by: Matthieu CASTET matthieu.cas...@parrot.com Pushed this one to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/3] mtd nand : add NAND_BUSWIDTH_AUTO to autodetect bus width
On Tue, 2012-11-06 at 11:51 +0100, Matthieu CASTET wrote: The driver call nand_scan_ident in 8 bit mode, then readid or onfi detection are done (and detect bus width). The driver should update its bus width before calling nand_scan_tail. This work because readid and onfi are read work 8 byte mode. Pushed this one alone to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 3/3] omap3 nand : use NAND_BUSWIDTH_AUTO
On Tue, 2012-11-06 at 10:40 -0800, Tony Lindgren wrote: Where such tree could be found ? You should be able to use omap-for-v3.8/cleanup-headers-gpmc branch as a base for your patches [1]. Is this a stable branch which I may pull into l2-mtd.git? Then I could merge Matthieu's patches. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v3] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND addresses
On Mon, 2012-10-29 at 15:51 -0400, Christopher Harvey wrote: In 16bit NAND mode the GPMC would send the address 0xNN as 0xFFNN instead of 0x00NN on the bus. The 0xFFs were actually uninitialized bits that were left unset in the GPMC command output register. The reason they weren't initialized in 16bit mode is that if the same code that writes to this register was used in 8bit mode then 2 commands would be output in 8bit mode. One for the low byte, and an extra 0x0 command for the high byte. This commit uses writew if we're using 16bit NAND. This commit also changes the high byte in the command output register, but they are ignored by NAND chips anyway. Most chips seem fine with the extra 0xFFs, but the ONFI spec says otherwise. Signed-off-by: Christopher Harvey char...@matrox.com Pushed to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v3] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND addresses
On Thu, 2012-11-15 at 09:48 -0500, Christopher Harvey wrote: On Thu, Nov 15, 2012 at 01:02:09PM +0200, Artem Bityutskiy wrote: On Mon, 2012-10-29 at 15:51 -0400, Christopher Harvey wrote: In 16bit NAND mode the GPMC would send the address 0xNN as 0xFFNN instead of 0x00NN on the bus. The 0xFFs were actually uninitialized bits that were left unset in the GPMC command output register. The reason they weren't initialized in 16bit mode is that if the same code that writes to this register was used in 8bit mode then 2 commands would be output in 8bit mode. One for the low byte, and an extra 0x0 command for the high byte. This commit uses writew if we're using 16bit NAND. This commit also changes the high byte in the command output register, but they are ignored by NAND chips anyway. Most chips seem fine with the extra 0xFFs, but the ONFI spec says otherwise. Signed-off-by: Christopher Harvey char...@matrox.com Pushed to l2-mtd.git, thanks! !!! Did anybody get around to testing this? I thought this patch had been abandoned. Will testing get done on an omap chip now that it is in a tree? I should have prefixed it with RFC. I assume _you_ tested it, and Ivan was happy. But if it is untested, I am dropping it. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH] mtd: omap2-nand: avoid unaligned DMA accesses, fall back on prefetch method
On Thu, 2012-09-20 at 17:44 +0200, Arnout Vandecappelle (Essensium/Mind) wrote: It's difficult to reproduce the error, because the buffers are aligned most of the time. Can you just take one of the mtd tests (e.g., mtd_speedtest), amend it a little and make sure it uses unaligned buffers? Perhaps a better method is to fetch the first few unaligned bytes with the prefetch method, and then continue with DMA. However, since it's hard to force an unaligned buffer, it's also hard to test that this method works. Yes, this would be a lot cleaner. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH] mtd: nand: omap2: Fix the nand-disk led trigger
On Mon, 2012-09-17 at 13:52 +0300, Grazvydas Ignotas wrote: On Thu, Sep 13, 2012 at 6:06 PM, Raphael Assenat r...@8d.com wrote: When the omap2 nand flash driver is used, the nand-disk led trigger does not work due to nand_wait_ready not being called. I think better solution is just to delete omap_wait() function, which is just a copy of nand_wait() without LED and oops handling. If waitfunc is not set by the driver, default nand_wait is used by the core. Or if it does really need own wait function, we can re-work the internal api similarly to what we did to MTD api. Instead of calling 'chip-waitfunc()' directly from everywhere, have a wrapper 'nand_wati()' function, which can do things common to all drivers, and then actually call the underlying '-waitfunc()'. So in this case, it can do the LED stuff. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/2] mtd/nand/omap2: fix omap_nand_remove segfault
On Fri, 2012-08-31 at 13:35 +0200, Andreas Bießmann wrote: Do not kfree() the mtd_info, it is handled in the mtd subsystem and already freed by nand_release(). Instead kfree() the struct omap_nand_info allocated in omap_nand_probe which was not kfree()ed before. This patch fixes following error when unloading the omap2 module: Added Cc: sta...@vger.kernel.org to both patches and pushed to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v3 10/10] mtd: nand: omap2: use gpmc provided irqs
On Tue, 2012-08-21 at 15:14 +0530, Afzal Mohammed wrote: GPMC platform initialization provides it's clients with interrupts that can be used through struct resource. Make use of it for irq mode functionality. Also now write protect disable is done by GPMC, hence remove it. Signed-off-by: Afzal Mohammed af...@ti.com Acked-by: Artem Bityutskiy artem.bityuts...@linux.intel.com -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
RE: [PATCH v2 08/10] ARM: OMAP2+: gpmc: Modify interrupt handling
On Wed, 2012-06-13 at 11:56 +, Mohammed, Afzal wrote: I guess XXX means Warning? Why not to use plain English? :-) It was made so that in editor (vim, maybe got biased towards it as I use it) it gets highlighted, do you want me to send an updated series ? No, thanks. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 00/10] Prepare for GPMC driver conversion (w.r.t MTD)
On Wed, 2012-06-13 at 17:02 +0530, Afzal Mohammed wrote: Hi, This series cleans up gpmc mtd interactions so that GPMC driver conversion which is going to happen shortly would happen smoothly by not creating much disturbance outside of arch/arm/*omap*/ Dunno if Tony picked this, but the MTD changes look good an the quick glance. Feel free to add Acked-by: Artem Bityutskiy artem.bityuts...@linux.intel.com Thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 00/10] Prepare for GPMC driver conversion (w.r.t MTD)
On Wed, 2012-06-13 at 17:02 +0530, Afzal Mohammed wrote: Hi, This series cleans up gpmc mtd interactions so that GPMC driver conversion which is going to happen shortly would happen smoothly by not creating much disturbance outside of arch/arm/*omap*/ BTW, be aware that Russel King patched the omap2.c file in patch series which switches to the DMA engine, so I expect conflicts. You can check his tree, I guess. The subjects were: [CFT 09/11] mtd: omap2: add DMA engine support [CFT 10/11] mtd: omap2: remove private DMA API implementation -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
RE: [PATCH 00/10] Prepare for GPMC driver conversion (w.r.t MTD)
On Thu, 2012-06-14 at 16:01 +, Mohammed, Afzal wrote: Hi Artem, On Wed, Jun 13, 2012 at 16:39:08, Tony Lindgren wrote: Looks good to me, made one comment to mtd: nand: omap2: handle nand on gpmc patch. Maybe after that is fixed Artem can take a look and maybe ack the two mtd related patches? After fixing as per Tony's comments, V2 [1] of the series has been posted, can you please take a look at it. I do not have any objections if Tony takes the entire series and merges via his tree. I do not have time to review your patches, but they look OK on the quick glance. Thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 08/10] ARM: OMAP2+: gpmc: Modify interrupt handling
On Wed, 2012-06-13 at 17:03 +0530, Afzal Mohammed wrote: +/* XXX: Only NAND irq has been considered,currently these are the only ones used + */ +#define GPMC_NR_IRQ 2 I guess XXX means Warning? Why not to use plain English? :-) -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [CFT 09/11] mtd: omap2: add DMA engine support
On Thu, 2012-06-07 at 12:09 +0100, Russell King wrote: Add DMA engine support to the OMAP2 NAND driver. This supplements the private DMA API implementation contained within this driver, and the driver can be independently switched at build time between using DMA engine and the private DMA API. Tested-by: Grazvydas Ignotas nota...@gmail.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk I guess it is makes sense to make this stuff to go in via the OMAP tree. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [CFT 09/11] mtd: omap2: add DMA engine support
On Thu, 2012-06-07 at 14:11 +0100, Russell King - ARM Linux wrote: No, it makes sense to get this stuff via a single tree all together, because, as you can see from the thread structure, it isn't purely an OMAP thing. The OMAP stuff depends on a core set, as does a bunch of PL08x and SA11x0 changes. We can't stuff all that through the OMAP tree, that wouldn't make any sense. What probably should happen is that the tip of the OMAP stuff gets pulled by Tony into his tree, and we share those commits between my tree and his - and then it doesn't matter what goes in when and by whom. Oh, sure, sorry, I actually wanted to say that these to patches should _not_ got via the MTD tree. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
RE: [PATCH 0/3] GPMC NAND isr using standard API
On Tue, 2012-05-22 at 04:26 +, Mohammed, Afzal wrote: Tony, Artem, how should the conflict between omap mtd trees be handled for patch series ? You merge the 2 trees and work on top of that? Or you wait for 3.5-r1 when everything is merged and work on top of that? -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Thu, 2012-05-10 at 19:45 +0200, Ivan Djelic wrote: On Thu, May 10, 2012 at 04:52:18PM +0100, Artem Bityutskiy wrote: On Thu, 2012-05-10 at 17:17 +0200, Ivan Djelic wrote: But in order to do so, I need the changes that Afzal has submitted (in particular [3]). Those changes (and as a consequence, my new patch) won't hit 3.5. So, when Afzal's patches are pushed, I'll submit a new, single MTD patch. But this is not going to happen this merge window as I understood, may be not even the next one. We need to make UBIFS happy sooner than that, I think. So may be we go forward with your original patch? I'm OK with this too, as the patches are ready and tested. The MTD patch is [2], it depends on [1] which has been pushed, then dropped by Tony. Do you need me to repost [2] ? Tony, sorry to backpedal on this: would you re-push patch [1], if indeed Afzal's patches are not going to be merged soon ? In the meantime, I can prepare a patch on top of Afzal's to have a smooth transition w.r.t BCH support. What do you think ? OK, since we now have Tony's ack - I have applied both patches to l2-mtd.git. Thanks. I have a question though - will send separately. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Wed, 2012-05-09 at 08:31 -0700, Tony Lindgren wrote: Note that I could prepare a new MTD patch with BCH ecc code included, allowing to drop the GPMC BCH ecc api. OK, let's do that then. I'll drop this patch and you can coordinate your patch with Afzal. Ivan, so are you going to send new patches early enough to make them hit 3.5? Can you please then re-send all the dependent patches again and again describe what depends on what, because I am getting lost :-) -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Thu, 2012-05-10 at 17:17 +0200, Ivan Djelic wrote: But in order to do so, I need the changes that Afzal has submitted (in particular [3]). Those changes (and as a consequence, my new patch) won't hit 3.5. So, when Afzal's patches are pushed, I'll submit a new, single MTD patch. But this is not going to happen this merge window as I understood, may be not even the next one. We need to make UBIFS happy sooner than that, I think. So may be we go forward with your original patch? -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH] ARM: OMAP1: fix compilation issue in board-sx1.c
On Tue, 2012-05-08 at 17:17 -0700, Tony Lindgren wrote: * Artem Bityutskiy dedeki...@gmail.com [120508 07:02]: From: Artem Bityutskiy artem.bityuts...@linux.intel.com SX1 board requirese i2c, so select it in Kconfig, otherwise I have the following build error: Thanks applying into fixes-non-critical as this seems to build with omap1_defconfig. Right, because omap1_defconfig has i2c enabled. The build fails if I disable it. But this is not critical to me at all. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 3.4-rc6] MTD: NAND: ams-delta: fix request_mem_region() failure
On Mon, 2012-05-07 at 22:51 +0200, Janusz Krzysztofik wrote: A call to request_mem_region() has been introduced in the omap-gpio driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40, gpio/omap: Use devm_ API and add request_mem_region). This change prevented the Amstrad Delta NAND driver, which was doing the same in order to take control over OMAP MPU I/O lines that the NAND device hangs off, from loading successfully. Aiaiai found out that your patch adds this gcc warning: Successfully built configuration l2_omap1_defconfig,arm,arm-unknown-linux-gnueabi-, results: --- before_patching.log +++ after_patching.log @@ @@ +drivers/mtd/nand/ams-delta.c: In function 'ams_delta_cleanup': +drivers/mtd/nand/ams-delta.c:285:19: warning: unused variable 'res' [-Wunused-variable] -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 3.4-rc6] MTD: NAND: ams-delta: fix request_mem_region() failure
On Tue, 2012-05-08 at 10:03 +0300, Artem Bityutskiy wrote: On Mon, 2012-05-07 at 22:51 +0200, Janusz Krzysztofik wrote: A call to request_mem_region() has been introduced in the omap-gpio driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40, gpio/omap: Use devm_ API and add request_mem_region). This change prevented the Amstrad Delta NAND driver, which was doing the same in order to take control over OMAP MPU I/O lines that the NAND device hangs off, from loading successfully. Aiaiai found out that your patch adds this gcc warning: Successfully built configuration l2_omap1_defconfig,arm,arm-unknown-linux-gnueabi-, results: --- before_patching.log +++ after_patching.log @@ @@ +drivers/mtd/nand/ams-delta.c: In function 'ams_delta_cleanup': +drivers/mtd/nand/ams-delta.c:285:19: warning: unused variable 'res' [-Wunused-variable] But I've fixed this up and pushed to l2-mtd.git. From the commit message I have an impression that you are not going to implement that longer term plan. Dunno if Tony has a plan to force someone to do this by blocking some changes which are not urgent fixes. Hmm? :-) -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
[PATCH] ARM: OMAP1: fix compilation issue in board-sx1.c
From: Artem Bityutskiy artem.bityuts...@linux.intel.com SX1 board requirese i2c, so select it in Kconfig, otherwise I have the following build error: arch/arm/mach-omap1/board-sx1.c: In function 'sx1_i2c_write_byte': arch/arm/mach-omap1/board-sx1.c:58:2: error: implicit declaration of function 'i2c_get_adapter' [-Werror=implicit-function-declaration] arch/arm/mach-omap1/board-sx1.c:58:7: warning: assignment makes pointer from integer without a cast [enabled by default] arch/arm/mach-omap1/board-sx1.c:67:2: error: implicit declaration of function 'i2c_transfer' [-Werror=implicit-function-declaration] arch/arm/mach-omap1/board-sx1.c:68:2: error: implicit declaration of function 'i2c_put_adapter' [-Werror=implicit-function-declaration] arch/arm/mach-omap1/board-sx1.c: In function 'sx1_i2c_read_byte': arch/arm/mach-omap1/board-sx1.c:82:7: warning: assignment makes pointer from integer without a cast [enabled by default] cc1: some warnings being treated as errors make[1]: *** [arch/arm/mach-omap1/board-sx1.o] Error 1 make: *** [arch/arm/mach-omap1] Error 2 make: *** Waiting for unfinished jobs Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com --- arch/arm/mach-omap1/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig index dfab466..cba3f71 100644 --- a/arch/arm/mach-omap1/Kconfig +++ b/arch/arm/mach-omap1/Kconfig @@ -132,6 +132,7 @@ config MACH_OMAP_PALMTT config MACH_SX1 bool Siemens SX1 + select I2C depends on ARCH_OMAP1 ARCH_OMAP15XX help Support for the Siemens SX1 phone. To boot the kernel, -- 1.7.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Tue, 2012-04-17 at 10:48 +0200, Ivan Djelic wrote: This patch adds a simple BCH ecc computation api, similar to the existing Hamming ecc api. It is intended to be used by the MTD layer. It implements the following features: - support 4-bit and 8-bit ecc computation - do not protect user bytes in spare area, only data area is protected - ecc for an erased NAND page (0xFFs) is also a sequence of 0xFFs This last feature is obtained by adding a constant polynomial to the hardware computed ecc. It allows to correct bitflips in blank pages and is extremely useful to support filesystems such as UBIFS, which expect erased pages to contain only 0xFFs. This api has been tested on an OMAP3630 board. Signed-off-by: Ivan Djelic ivan.dje...@parrot.com Hi Tony, what do you think about merging this patch? This is the enabler for making UBIFS actually usable on OMAP platforms which use BCH ECC. There are 2 other MTD patches which depend on this - so I wonder if it is easier to merge this one via the MTD tree, providing it has your/others' ack(s). Thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
On Tue, 2012-04-17 at 15:49 +0200, Janusz Krzysztofik wrote: A call to request_mem_region() has been introduced in the omap-gpio driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40, gpio/omap: Use devm_ API and add request_mem_region). This change prevented the Amstrad Delta NAND driver, which was doing the same in order to take control over OMAP MPU I/O lines that the NAND device hangs off, from loading successfully. There is another driver, omap-keypad, which also manipulates OMAP MPUIO registers, but has never been calling request_mem_region() on startup, so it's not affected by the change in the gpio-omap and works correctly. Drop request_mem_region() call and related bits from ams-delta NAND driver. Created and tested against linux-3.4-rc3. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl How about race conditions? Where is the guarantee that these 2 drivers won't affect each other when doing I/O at the same time to the same HW resources? -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Wed, 2012-04-25 at 08:23 -0700, Tony Lindgren wrote: Hi, * Artem Bityutskiy dedeki...@gmail.com [120425 07:52]: On Tue, 2012-04-17 at 10:48 +0200, Ivan Djelic wrote: This patch adds a simple BCH ecc computation api, similar to the existing Hamming ecc api. It is intended to be used by the MTD layer. It implements the following features: - support 4-bit and 8-bit ecc computation - do not protect user bytes in spare area, only data area is protected - ecc for an erased NAND page (0xFFs) is also a sequence of 0xFFs This last feature is obtained by adding a constant polynomial to the hardware computed ecc. It allows to correct bitflips in blank pages and is extremely useful to support filesystems such as UBIFS, which expect erased pages to contain only 0xFFs. This api has been tested on an OMAP3630 board. Signed-off-by: Ivan Djelic ivan.dje...@parrot.com Hi Tony, what do you think about merging this patch? This is the enabler for making UBIFS actually usable on OMAP platforms which use BCH ECC. There are 2 other MTD patches which depend on this - so I wonder if it is easier to merge this one via the MTD tree, providing it has your/others' ack(s). Looks OK to me, however there are other pending GPMC patches to convert it to a platform device device driver. Need to look those closer though. Anyways, it's best that I queue them to avoid merge conflicts. Sure. Do you these for other changes for UBIFS? Not in UBIFS, but in drivers/mtd/nand/omap2.c - Ivan sent another patch which adds BCH support to to omap2.c, was sent to linux-omap, subject [PATCH] mtd: nand: omap: add support for hardware BCH ecc If so, I can set up an immutable branch for GPMC that you can merge in as well. I guess this would be a good idea, but probably it is better to do this when you believe you merged most gpmc patches, so probably closer to the final -rc? -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
On Wed, 2012-04-25 at 19:01 +0200, Janusz Krzysztofik wrote: Both drivers use separate subsets of registers that belong to the OMAP1 MPU I/O device, but are used for controlling different sets of I/O pins. The NAND driver reads/writes the folowing registers: - OMAP_MPUIO_INPUT_LATCH, - OMAP_MPUIO_OUTPUT, - OMAP_MPUIO_IO_CNTL, while the keypad driver - the following: - OMAP_MPUIO_KBR_LATCH, - OMAP_MPUIO_KBC, - OMAP_MPUIO_KBD_MASKIT - OMAP_MPUIO_GPIO_DEBOUNCING. Both subsets are non-overlapping, and we rely on the drivers being free of bugs and doing their job correctly, not stepping on each others' feet, I guess. First of all, I think this information should be in the commit message. Also, some sort of comment in the driver code would be nice. If locking the memory region is too coarse approach, the should have a small separate omap-specific MPUIO subsystem which will be used by drivers to access MPUIO? Another question - should request_mem_region() be also removed from the omap-gpio driver then? I think it is more sensible to put a comment there that it is sharing MPIO with other drivers, instead of having an illusion of exclusive memory region ownership. But this is up to the OMAP community - I can take this patch to my l2-mtd tree if you get an ack from Tony or other OMAP guys. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH] mtd: omap2: fix resource leak in prefetch-busy path
On Wed, 2012-04-11 at 04:04 +0300, Grazvydas Ignotas wrote: If prefetch engine is busy, current code forgets to call dma_unmap_single(), which results in a deadlock later, so add it. Signed-off-by: Grazvydas Ignotas nota...@gmail.com Pushed to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/5] mtd: plat_nand: Add default partition parser and use it
On Wed, 2012-03-28 at 11:12 -0700, H Hartley Sweeten wrote: This patch series adds cmdlinepart as the default partition parser for the plat_nand driver and updates all the arch setup code to use it. Arch setup code that requires other partition parsers can still pass that information as chip.part_probe_types. Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com Pushed the series to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [GIT PULL] HSI framework
On Wed, 2012-03-07 at 11:49 +0100, Sebastian Reichel wrote: Hi Linus, I've noticed that you have not pulled this (yet). I would like to confirm that we at Intel are also very interested to have HSI upstream. I believe this code base is more than worth merging since it has many users and it has proven itself in real Nokia products. Would you please pull it? Hi, I think we never got a reply why the HSI framework has not been pulled into 3.3. So what needs to be done to get it pulled into 3.4? Hi, Because this question is for Linus, he should be in To: instead of Cc: - correcting. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 2/2] mtd : Make the mtd_suspend return 0 if the suspend is not implemented
On Mon, 2012-01-30 at 23:58 +0100, Rafael J. Wysocki wrote: Thanks, but is anyone actually going to push it to Linus any time soon? I agree, but I am not the maintainer so cannot answer. David Woodhouse is aware of this, but I do not know when he gonna send the pull request. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH RFC 2/2] mtd : Make the mtd_suspend return 0 if the suspend is not implemented
On Tue, 2012-01-24 at 09:06 +, Russell King - ARM Linux wrote:
However, the bug made it into the 3.3 merge window, so shouldn't this
bugfix be sent upstream immediately?
David is the MTD maintainer, and Artem just helps out. I believe Artem
is waiting for David to finish travelling before asking David (last seen
at Hong Kong airport) to pull these fixes. David in turn will pass them
onto Linus. Plus, Linus only started adding to -rc1 yesterday, so its a
little early to expect this to be fixed.
Hi,
here is the latest version of the fix.
http://git.infradead.org/users/dedekind/l2-mtd-2.6.git/commit/283d43b9ce2952535aa89c0195085e2a1b7e5fce
Also attached.
From 283d43b9ce2952535aa89c0195085e2a1b7e5fce Mon Sep 17 00:00:00 2001
From: Artem Bityutskiy artem.bityuts...@linux.intel.com
Date: Mon, 16 Jan 2012 11:07:16 +0200
Subject: [PATCH] mtd: fix MTD suspend
Commits 3fe4bae88460869a8e553397cd9057a4ee7ca341 and
079c985e7a6f4ce60f931cebfdd5ee3c3 broke MTD suspend in 2 ways:
1. When the '-suspend' method is not present, we return -EOPNOTSUPP,
but
the callers of 'mtd_suspend()' expects 0 instead.
2. Checking of the 'mtd' parameter against NULL has been incorrectly
removed
in 'mtd_cls_suspend()'.
This patch fixes the breakages. This has been found, analyzed, reported
and tested by Rafael J. Wysocki r...@sisk.pl.
Note, this patch is not needed in the stable tree because it causes a
regression introduced during the v3.3 merge window.
Reported-by: Rafael J. Wysocki r...@sisk.pl
Tested-by: Rafael J. Wysocki r...@sisk.pl
Tested-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
---
drivers/mtd/mtdcore.c |2 +-
include/linux/mtd/mtd.h |4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index b265188..de96865 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -119,7 +119,7 @@ static int mtd_cls_suspend(struct device *dev,
pm_message_t state)
{
struct mtd_info *mtd = dev_get_drvdata(dev);
- return mtd_suspend(mtd);
+ return mtd ? mtd_suspend(mtd) : 0;
}
static int mtd_cls_resume(struct device *dev)
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 1a81fde..d8c7aad 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -427,9 +427,7 @@ static inline int mtd_is_locked(struct mtd_info
*mtd, loff_t ofs, uint64_t len)
static inline int mtd_suspend(struct mtd_info *mtd)
{
- if (!mtd-suspend)
- return -EOPNOTSUPP;
- return mtd-suspend(mtd);
+ return mtd-suspend ? mtd-suspend(mtd) : 0;
}
static inline void mtd_resume(struct mtd_info *mtd)
--
1.7.7.6
--
Best Regards,
Artem Bityutskiy
From 283d43b9ce2952535aa89c0195085e2a1b7e5fce Mon Sep 17 00:00:00 2001
From: Artem Bityutskiy artem.bityuts...@linux.intel.com
Date: Mon, 16 Jan 2012 11:07:16 +0200
Subject: [PATCH] mtd: fix MTD suspend
Commits 3fe4bae88460869a8e553397cd9057a4ee7ca341 and
079c985e7a6f4ce60f931cebfdd5ee3c3 broke MTD suspend in 2 ways:
1. When the '-suspend' method is not present, we return -EOPNOTSUPP, but
the callers of 'mtd_suspend()' expects 0 instead.
2. Checking of the 'mtd' parameter against NULL has been incorrectly removed
in 'mtd_cls_suspend()'.
This patch fixes the breakages. This has been found, analyzed, reported
and tested by Rafael J. Wysocki r...@sisk.pl.
Note, this patch is not needed in the stable tree because it causes a
regression introduced during the v3.3 merge window.
Reported-by: Rafael J. Wysocki r...@sisk.pl
Tested-by: Rafael J. Wysocki r...@sisk.pl
Tested-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
---
drivers/mtd/mtdcore.c |2 +-
include/linux/mtd/mtd.h |4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index b265188..de96865 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -119,7 +119,7 @@ static int mtd_cls_suspend(struct device *dev, pm_message_t state)
{
struct mtd_info *mtd = dev_get_drvdata(dev);
- return mtd_suspend(mtd);
+ return mtd ? mtd_suspend(mtd) : 0;
}
static int mtd_cls_resume(struct device *dev)
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 1a81fde..d8c7aad 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -427,9 +427,7 @@ static inline int mtd_is_locked(struct mtd_info *mtd, loff_t ofs, uint64_t len)
static inline int mtd_suspend(struct mtd_info *mtd)
{
- if (!mtd-suspend)
- return -EOPNOTSUPP;
- return mtd-suspend(mtd);
+ return mtd-suspend ? mtd-suspend(mtd) : 0;
}
static inline void mtd_resume(struct mtd_info *mtd)
--
1.7.7.6
signature.asc
Description: This is a digitally signed message part
Re: Linux 3.3-1 out - merge window closed
On Tue, 2012-01-24 at 20:57 +0200, Carlos Chinea wrote: Several people have shown interest for this to be integrated in the kernel to help development.The framework is already in use in Nokia products like N9. We (ST-Ericsson) also use this framework and we have a driver for it in the works and submitted to the list at one time I think. I am sorry if I have not ACK:ed all patches but I have my ack on the big one. That said I suspect it mightn't have been pulled because Torvalds cannot verify who you are, and/or that there is no signed tag on it? GPG keys are getting mandatory, though it's sad if it's becoming a barrier to entry. There is a signed tag (hsi_for_3.3), but said it so is true that my key was signed only by one person. Today I've managed to meet Artem Bityutskiy and he has now also signed the key. However, It is my understanding that's not enough :( You may try to approach Pekka Enberg penb...@kernel.org -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: Linux 3.3-1 out - merge window closed
On Wed, 2012-01-25 at 13:47 +0200, Pekka Enberg wrote: On Wed, Jan 25, 2012 at 1:35 PM, Artem Bityutskiy artem.bityuts...@linux.intel.com wrote: There is a signed tag (hsi_for_3.3), but said it so is true that my key was signed only by one person. Today I've managed to meet Artem Bityutskiy and he has now also signed the key. However, It is my understanding that's not enough :( You may try to approach Pekka Enberg penb...@kernel.org I pretty much don't sign keys for people I don't know personally, sorry. I did not suggest that, of course. I meant that you are also in Helsinki and if Carlos knows you he could approach you. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [GIT PULL] HSI framework
On Fri, 2012-01-13 at 15:25 +0200, Carlos Chinea wrote: Hi Linus, I have been working in an HSI framework. The High Speed Synchronous Serial Interface (HSI) is a serial interface mainly used for connecting application engines (APE) with cellular modem engines (CMT) in cellular handsets. The framework is currently being used for some people and we would like to see it integrated into the kernel for 3.3. There is no HW controller drivers in this pull, but some people have already some of them pending which they would like to push as soon as this integrated. I am also working on the acceptance for an TI OMAP one, based on a compatible legacy version of the interface called SSI. Hi Linus, I've noticed that you have not pulled this (yet). I would like to confirm that we at Intel are also very interested to have HSI upstream. I believe this code base is more than worth merging since it has many users and it has proven itself in real Nokia products. Would you please pull it? -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 5/7] MTD: NAND: ams-delta: use GPIO instead of custom I/O
On Tue, 2011-12-20 at 00:08 +0100, Janusz Krzysztofik wrote: Don't use Amstrad Delta custom I/O functions for controlling the device, use GPIO API instead. While being at it, add missing gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB). Depends on patch 2/7 ARM: OMAP1: ams-delta: convert latches to basic_mmio_gpio Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Cc: David Woodhouse dw...@infradead.org Cc: Tony Lindgren t...@atomide.com Looks good, thanks! Reviewed-by: Artem Bityutskiy artem.bityuts...@linux.intel.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mdt nand: omap2+ use platform options
On Fri, 2011-12-02 at 09:28 -0800, Brian Norris wrote: On Fri, Dec 2, 2011 at 2:20 AM, Grazvydas Ignotas nota...@gmail.com wrote: On Thu, Dec 1, 2011 at 10:42 AM, Artem Bityutskiy dedeki...@gmail.com wrote: On Tue, 2011-11-29 at 10:00 +0100, Jan Weitzel wrote: Signed-off-by: Jan Weitzel j.weit...@phytec.de Pushed to l2-mtd-2.6.git, thank you! This breaks build here, did you really test it, Jan? drivers/mtd/nand/omap2.c: In function 'omap_nand_probe': drivers/mtd/nand/omap2.c:1078: error: 'struct omap_nand_platform_data' has no member named 'options' This is exactly what I was asking already. I don't see 'options' in 'struct omap_nand_platform_data' in 'arch/arm/plat-omap/include/plat/nand.h', even in linux-next. Yes, sorry, I've payed not enough attention to the patch. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH] mdt nand: omap2+ use platform options
On Fri, 2011-12-02 at 12:20 +0200, Grazvydas Ignotas wrote: On Thu, Dec 1, 2011 at 10:42 AM, Artem Bityutskiy dedeki...@gmail.com wrote: On Tue, 2011-11-29 at 10:00 +0100, Jan Weitzel wrote: Signed-off-by: Jan Weitzel j.weit...@phytec.de Pushed to l2-mtd-2.6.git, thank you! This breaks build here, did you really test it, Jan? drivers/mtd/nand/omap2.c: In function 'omap_nand_probe': drivers/mtd/nand/omap2.c:1078: error: 'struct omap_nand_platform_data' has no member named 'options' OK, dropping it for now. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH] mdt nand: omap2+ use platform options
On Tue, 2011-11-29 at 10:00 +0100, Jan Weitzel wrote: Options from struct omap_nand_platform_data are not used. Apply options after nand_scan_ident to avoid overwrite due to NAND_CHIPOPTIONS_MSK. So you can pass options from platformcode Signed-off-by: Jan Weitzel j.weit...@phytec.de Pushed to l2-mtd-2.6.git, thank you! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: nand: Making MTD_NAND_OMAP2 depend on ARCH_OMAP2PLUS
On Wed, 2011-11-16 at 10:48 +0530, Shubhrajyoti D wrote: Making MTD_NAND_OMAP2 depend on ARCH_OMAP2PLUS instead of oring with ARCH2/3/4. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com Pushed to l2-mtd-2.6, thanks! Artem. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HSI framework for linux-next
On Fri, 2011-10-28 at 12:27 +0300, Carlos Chinea wrote: Hi Stephen, I have been working in an HSI framework for linux: https://lkml.org/lkml/2011/6/10/280 The framework is in good shape and is currently being used for some people so we would like it to see it integrated, if possible, for 3.3 Latest discussion for integration: https://lkml.org/lkml/2011/10/20/177 Stephen, I confirm that this is useful and solid framework, works well, and we are also interested to see it upstream. Thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
RE: [PATCH] ti816x: add support for nand on ti8168 evm
On Mon, 2011-09-19 at 17:04 +0530, Saxena, Parth wrote: Artem, I will re-post this patch to linux-omap list and Tony. Can I add your name in the 'Acked-by' section? No, I did not review this patch. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ti816x: add support for nand on ti8168 evm
On Thu, 2011-09-08 at 18:33 +0530, Saxena, Parth wrote: Add partition table for NAND device on TI8168 EVM and initialise the NAND module. Signed-off-by: Saxena, Parth parth.sax...@ti.com Signed-off-by: Basheer, Mansoor Ahamed mansoor.aha...@ti.com --- This patch is tested on top of linux-omap/master and Hemant's patches submitted recently. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53457.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg54296.html arch/arm/mach-omap2/board-ti8168evm.c | 39 + 1 files changed, 39 insertions(+), 0 deletions(-) Please, send this patch to Tony, I think it should go in via the omap tree, not via the MTD tree. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] MTD: Nand: use MTD_NAND_OMAP2 for OMAP4
On Wed, 2011-07-20 at 09:28 +0200, Jan Weitzel wrote: use MTD_NAND_OMAP2 also for OMAP4 arch. testes wit omap4430 Signed-off-by: Jan Weitzel j.weit...@phytec.de --- v2: add menuconfig description Pushed to l2-mtd-2.6.git, thanks. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: Nand: use MTD_NAND_OMAP2 for OMAP4
On Fri, 2011-07-15 at 12:52 +0200, Jan Weitzel wrote: config MTD_NAND_OMAP2 tristate NAND Flash device on OMAP2 and OMAP3 I guess you need to add OMAP4 to the string above as well. - depends on ARM (ARCH_OMAP2 || ARCH_OMAP3) + depends on ARM (ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4) help - Support for NAND flash on Texas Instruments OMAP2 and OMAP3 platforms. + Support for NAND flash on Texas Instruments OMAP2, OMAP3 and OMAP4 + platforms. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] omap : nand : fix subpage ecc issue with prefetch
On Wed, 2011-05-11 at 21:17 +0530, Kishore Kadiyala wrote: When reading/writing a subpage (When HW ECC is not available/enabled) for number of bytes not aligned to 4, the mis-aligned bytes are handled first (by cpu copy method) before enabling the Prefetch engine to/from 'p'(start of buffer 'buf'). Then it reads/writes rest of the bytes with the help of Prefetch engine, if available, or again using cpu copy method. Currently, reading/writing of rest of bytes, is not done correctly since its trying to read/write again to/from begining of buffer 'buf', overwriting the mis-aligned bytes. Read write using prefetch engine got broken in commit '2c01946c'. We never hit a scenario of not getting 'gpmc_prefetch_enable' call success. So, problem did not get caught up. Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com Signed-off-by: Vimal Singh vimal.neww...@gmail.com Reported-by: Bryan DE FARIA bdefa...@adeneo-embedded.com Cc: sta...@kernel.org [2.6.35+] Pushed to l2-mtd-2.6.git, thanks. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap : nand : fix subpage ecc issue with prefetch
On Mon, 2011-05-02 at 16:40 +0530, Kishore Kadiyala wrote: For prefetch engine, read and write got broken in commit '2c01946c'. We never hit a scenario of not getting 'gpmc_prefetch_enable' call success. When reading/writing a subpage with a non divisible by 4 ecc number of bytes, the mis-aligned bytes gets handled first before enabling the Prefetch engine, then it reads/writes rest of the bytes. Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com Signed-off-by: Vimal Singh vimal.neww...@gmail.com Reported-by: Bryan DE FARIA bdefa...@adeneo-embedded.com This needs a better commit message with more explanation and analysis of the problem and how it was fixed.This commit message is not very understandable. And then it needs also: Cc: sta...@kernel.org [2.6.36+] Right? And then we could send it upstream. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mtd: nand: Fix bad block identification issue
On Thu, 2011-04-28 at 20:30 +0300, Artem Bityutskiy wrote: On Wed, 2011-04-27 at 17:39 +0530, Saxena, Parth wrote: This patch solves the above issue for omap by initialising badblockbits. We are working further on this to find a generic fix to the problem in nand_base.c. But it looks like the generic solution is to return the line which was accidentally removed, how about this patch From: Artem Bityutskiy artem.bityuts...@nokia.com Date: Thu, 28 Apr 2011 20:26:59 +0300 Subject: [PATCH] mtd: return badblockbits back In commit c7b28e25cb9beb943aead770ff14551b55fa8c79 the initialization of the backblockbits was accidentally removed. This patch returns it back, because otherwise some NAND drivers are broken. This problem was reported by Saxena, Parth parth.sax...@ti.com here: http://lists.infradead.org/pipermail/linux-mtd/2011-April/035221.html Reported-by: Saxena, Parth parth.sax...@ti.com Signed-off-by: Artem Bityutskiy artem.bityuts...@nokia.com Cc: sta...@kernel.org [2.6.36+] --- drivers/mtd/nand/nand_base.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Any ack/nack/tested-by? -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] mtd: nand: Fix bad block identification issue
On Fri, 2011-04-29 at 19:52 +0530, Saxena, Parth wrote: -Original Message- From: Artem Bityutskiy [mailto:dedeki...@gmail.com] Sent: Thursday, April 28, 2011 11:01 PM To: Saxena, Parth; Brian Norris Cc: linux-...@lists.infradead.org; Basheer, Mansoor Ahamed; linux- o...@vger.kernel.org Subject: Re: [RFC] mtd: nand: Fix bad block identification issue On Wed, 2011-04-27 at 17:39 +0530, Saxena, Parth wrote: This patch solves the above issue for omap by initialising badblockbits. We are working further on this to find a generic fix to the problem in nand_base.c. But it looks like the generic solution is to return the line which was accidentally removed, how about this patch From: Artem Bityutskiy artem.bityuts...@nokia.com Date: Thu, 28 Apr 2011 20:26:59 +0300 Subject: [PATCH] mtd: return badblockbits back In commit c7b28e25cb9beb943aead770ff14551b55fa8c79 the initialization of the backblockbits was accidentally removed. This patch returns it back, because otherwise some NAND drivers are broken. This problem was reported by Saxena, Parth parth.sax...@ti.com here: http://lists.infradead.org/pipermail/linux-mtd/2011-April/035221.html Reported-by: Saxena, Parth parth.sax...@ti.com Signed-off-by: Artem Bityutskiy artem.bityuts...@nokia.com Cc: sta...@kernel.org [2.6.36+] --- drivers/mtd/nand/nand_base.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 15510f2..5a7f817 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -3106,6 +3106,8 @@ ident_done: chip-chip_shift += 32 - 1; } + chip-badblockbits = 8; + /* Set the bad block position */ if (mtd-writesize 512 || (busw NAND_BUSWIDTH_16)) chip-badblockpos = NAND_LARGE_BADBLOCK_POS; [Saxena, Parth] Tested-By: Saxena, Parth parth.sax...@ti.com Acked By: Saxena, Parth parth.sax...@ti.com Thanks, pushing to the l2-mtd-2.6.git. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mtd: nand: Fix bad block identification issue
On Fri, 2011-04-29 at 11:03 -0700, Brian Norris wrote: As promised (but too late?): Acked-by: Brian Norris computersforpe...@gmail.com No, not late, I rebase my l2 tree with no shame :-) But once the patch hits the real mtd tree, then we never change it. So, I've added you tag, thanks. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mtd: nand: Fix bad block identification issue
On Wed, 2011-04-27 at 17:39 +0530, Saxena, Parth wrote: This patch solves the above issue for omap by initialising badblockbits. We are working further on this to find a generic fix to the problem in nand_base.c. But it looks like the generic solution is to return the line which was accidentally removed, how about this patch From: Artem Bityutskiy artem.bityuts...@nokia.com Date: Thu, 28 Apr 2011 20:26:59 +0300 Subject: [PATCH] mtd: return badblockbits back In commit c7b28e25cb9beb943aead770ff14551b55fa8c79 the initialization of the backblockbits was accidentally removed. This patch returns it back, because otherwise some NAND drivers are broken. This problem was reported by Saxena, Parth parth.sax...@ti.com here: http://lists.infradead.org/pipermail/linux-mtd/2011-April/035221.html Reported-by: Saxena, Parth parth.sax...@ti.com Signed-off-by: Artem Bityutskiy artem.bityuts...@nokia.com Cc: sta...@kernel.org [2.6.36+] --- drivers/mtd/nand/nand_base.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 15510f2..5a7f817 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -3106,6 +3106,8 @@ ident_done: chip-chip_shift += 32 - 1; } + chip-badblockbits = 8; + /* Set the bad block position */ if (mtd-writesize 512 || (busw NAND_BUSWIDTH_16)) chip-badblockpos = NAND_LARGE_BADBLOCK_POS; -- 1.7.2.3 -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: omap2: mtd split nand_scan in ident and tail
On Tue, 2011-04-19 at 16:15 +0200, Jan Weitzel wrote: nand_scan calls nand_scan_tail and here we got a ecc.layout and calculate oobavail for this layout. After calling nand_scan, we change the layout pointer if OMAP_ECC_HAMMING_CODE_HW_ROMCODE is set. This results in not calcluated oobavail. Mountig as jffs2 is not possible. To fix that nand_scan has to split up in nand_scan_ident and nand_scan_tail setting ecc.layout between these calls. So nand_scan_tail calculates oobvail for the used layout. This is also done in serveral other platforms. Signed-off-by: Jan Weitzel j.weit...@phytec.de Reviewed-by: Vimal Singh vimal.neww...@gmail.com Jan, thanks for the patch, pushed to l2-mtd-2.6.git. And apologies that I missed. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] MTD: s3c2410_nand: Add option to disable hw ECC at runtime
On Thu, 2011-04-14 at 16:48 +0200, Lars-Peter Clausen wrote: On 04/14/2011 02:08 PM, Artem Bityutskiy wrote: On Tue, 2011-04-12 at 21:47 +0200, Lars-Peter Clausen wrote: From: Holger Freyther ze...@openmoko.org This patch adds a flag to the s3c2410_nand platform data, which configures whether hardware ECC is used. Currently it is only possible to decide whether hw ECC should be used or not at compile time through a config option. But if you want to build a kernel which runs on multiple devices you might have a configuration where some devices require hw ECC and some devices which want software ECC. Signed-off-by: Lars-Peter Clausen l...@metafoo.de Extending platform data is kind of vetoed in arm tree, I do not think the MTD tree can take these changes. That is not my understanding of the situation. But what do you suggest as an alternative for fixing this issue? Well, I got this understanding by talking to the OMAP maintainer and by chatting with rmk. But I might be wrong. So the understanding is that board data extending is banned, at least for a while. And the arm world has to consolidate and probably switch to the DT tree approach. This would be painful, this would make some vendors to return to behind the curtains, so this would be a step back in the short run. But in a couple of years this would be resolved, may be under Linaro's aegis, and then the arm world would make 2 steps forward, so that previous step back would be compensated in the longer run. But! I'm just an small MTD guy, so I might be mistaken. Of course if you make your board file changes be merged via the corresponding arm sub-tree - go ahead send your MTD driver updates! This is I guess the answer to your what do you suggest question. CCing the arm lists so that people could correct me. Here is the beginning of the thread: http://lists.infradead.org/pipermail/linux-mtd/2011-April/034866.html -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap2: mtd split nand_scan in ident and tail
On Fri, 2011-04-15 at 15:34 +0200, Jan Weitzel wrote:
Am Donnerstag, den 14.04.2011, 11:15 +0200 schrieb Jan Weitzel:
nand_scan calls nand_scan_ident and nand_scan_tail, setting values like
oobvail
according to ecc.layout. If we change the layout afterwards values are
wrong.
Signed-off-by: Jan Weitzel j.weit...@phytec.de
---
drivers/mtd/nand/omap2.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index da9a351..288423f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1073,9 +1073,9 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
/* DIP switches on some boards change between 8 and 16 bit
* bus widths for flash. Try the other width if the first try fails.
*/
- if (nand_scan(info-mtd, 1)) {
+ if (nand_scan_ident(info-mtd, 1, NULL)) {
info-nand.options ^= NAND_BUSWIDTH_16;
- if (nand_scan(info-mtd, 1)) {
+ if (nand_scan_ident(info-mtd, 1, NULL)) {
err = -ENXIO;
goto out_release_mem_region;
}
@@ -1101,6 +1101,12 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-nand.ecc.layout = omap_oobinfo;
}
+ /* second phase scan */
+ if (nand_scan_tail(info-mtd)) {
+ err = -ENXIO;
+ goto out_release_mem_region;
+ }
+
#ifdef CONFIG_MTD_PARTITIONS
err = parse_mtd_partitions(info-mtd, part_probes, info-parts, 0);
if (err 0)
So no comments? Is any rework needed? Without this patch I am not able
to mount partions with OMAP_ECC_HAMMING_CODE_HW_ROMCODE.
Sorry, I missed this patch. Could you please update the commit message
and make it more verbose and state clearly:
1. which problem you solve
2. how you solve it
3. why is this the right solution
Thanks!
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Wed, 2011-03-30 at 23:10 +0200, Thomas Gleixner wrote: The only problem is to find a person, who is willing to do that, has enough experience, broad shoulders and a strong accepted voice. Not to talk about finding someone who is willing to pay a large enough compensation for pain and suffering. If I understand correctly, this is exactly what Linaro would need to do. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] omap3: nand: report corrected ecc errors
On Mon, 2011-02-28 at 13:12 +0100, John Ogness wrote: From: John Ogness john.ogn...@linutronix.de The number of corrected ECC errors should be reported since other MTD systems make use of this information (such as UBI data scrubbing). Signed-off-by: John Ogness john.ogn...@linutronix.de --- Patch v2: o Patch against linux-next-20110225. o Added comments explaining return codes. Pushed to l2-mtd-2.6.git, thanks. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mtd: OneNAND: OMAP2: increase multiblock erase verify timeout
Hi, On Thu, 2011-02-17 at 15:46 -0800, Tony Lindgren wrote: * Adrian Hunter adrian.hun...@nokia.com [110207 00:45]: From: Roman Tereshonkov roman.tereshon...@nokia.com The current multiblock erase verify read timeout 100us is the maximum for none-error case. If errors happen during multibock erase then the specification recommends to run multiblock erase verify command with maximum timeout 10ms (see specs. for KFM4G16Q2A and KFN8G16Q2A). For the most common non-error case we wait 100us in udelay polling loop. In case of timeout the interrupt mode is used to wait for the command end. Signed-off-by: Roman Tereshonkov roman.tereshon...@nokia.com I'll queue this series. Anybody from MTD list care to ack this patch? Acked-by: Artem Bityutskiy artem.bityuts...@nokia.com -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mtd: Add nand_base feature to align subpage read buffers
Hi,
would it please be possible improve comments and the commit message and
make them explain better which problem the patch solves, what is the
problem with the current code, how exactly you solve the problem, and
why your solution is the best among other alternative solutions?
I think the below commit messages is too short and does not explain
this.
On Thu, 2011-01-06 at 14:39 +1300, Charles Manning wrote:
Some nand controllers (eg. omap2) need to have their buffers u32 aligned
to use high speed transfer mechanisms.
This commit provides a way to plug in an alignment function and provides a
32-bit algnment function.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
drivers/mtd/nand/nand_base.c | 22 +-
include/linux/mtd/nand.h |5 +++--
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 1f75a1b..e8c2432 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1156,6 +1156,22 @@ static int nand_read_page_swecc(struct mtd_info *mtd,
struct nand_chip *chip,
}
/**
+ * nand_align_subpage32 - function to align subpage read to 32-bits
+ * @mtd: mtd info structure
+ * @buf: pointer to pointer of buffer that needs to be aligned
+ * @len: pointer to length that needs to be aligned.
+ */
+
Why blank line here?
+void nand_align_subpage32(uint8_t **buf, int *len)
+{
+ int diff = (int)(*buf) 3;
+ *buf = *buf - diff;
It is really not obvious that this buffer does not come from user-space,
but it is some internal chip-buffers-databuf, so you actually can step
back. Cold you please put some comment about this?
+ *len = *len + diff;
+ *len = (*len + 3) ~3;
+}
+EXPORT_SYMBOL(nand_align_subpage32);
In general, do you think it is a good thing that MTD NAND core always
reads to internal buffer first, then copies the data to the user buffer?
To me it looks like bad idea because we end up with unwanted overhead.
There is a benefit - if you read the same NAND page twice, you get the
data from the buffer the second time. But this does not work with
sub-pages, and I think this MTD core is wrong place for this. If someone
wants caching, he could use the Linux page cache as a layer on top of
MTD core, instead of this castrated one NAND page cache.
Anyway, what I want to say is that the current architecture is bad, IMO.
Namely, this always read to own buffer thing is bad. But your patch
relays on this, so if some one some day wants to improve MTD NAND core
in this respect, he'll end up with more job.
Is it possible to invent some solution which does not rely on the fact
that you deal with an internal buffer, but instead, assumes that you may
be dealing with a user buffer?
+
+/**
* nand_read_subpage - [REPLACABLE] software ecc based sub-page read function
* @mtd: mtd info structure
* @chip:nand chip info structure
@@ -1169,6 +1185,7 @@ static int nand_read_subpage(struct mtd_info *mtd,
struct nand_chip *chip,
int start_step, end_step, num_steps;
uint32_t *eccpos = chip-ecc.layout-eccpos;
uint8_t *p;
+ uint8_t *b;
The current style prefers
uint8_t *p, *b;
for some reasons.
int data_col_addr, i, gaps = 0;
int datafrag_len, eccfrag_len, aligned_len, aligned_pos;
int busw = (chip-options NAND_BUSWIDTH_16) ? 2 : 1;
@@ -1222,7 +1239,10 @@ static int nand_read_subpage(struct mtd_info *mtd,
struct nand_chip *chip,
chip-cmdfunc(mtd, NAND_CMD_RNDOUT,
mtd-writesize + aligned_pos, -1);
- chip-read_buf(mtd, chip-oob_poi[aligned_pos], aligned_len);
+ b = chip-oob_poi[aligned_pos];
+ if(chip-align_subpage)
+ chip-align_subpage(b, aligned_len);
+ chip-read_buf(mtd, b, aligned_len);
}
for (i = 0; i eccfrag_len; i++)
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 63e17d0..6ea6177 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -474,6 +474,7 @@ struct nand_buffers {
* additional error status checks (determine if errors are
* correctable).
* @write_page: [REPLACEABLE] High-level page write function
+ * @align_subpage: [OPTIONAL] Aligns subpage read buffer.
*/
Would it please be possible to add more comments to the code about this
align_subpage stuff, for people who try to read it in the future?
--
Best Regards,
Artem Bityutskiy (Битюцкий Артём)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Huge ubi or ubifs sync slowdown since 2.6.32
On Tue, 2010-12-21 at 11:36 +1300, Charles Manning wrote: Hi All I've been looking into a ubifs performance regression on linux-omap 2.6.37. My test is pretty simple, copy a 2Mbyte file and sync. # sync; date; cp 2Mbyte-file foo; sync; date On 2.6.32 and earler, the time between the two dates was around 3 seconds. On linux-omap master it is around 14 seconds. Ouch! At first I thought the problem was due to changes in the OMAP nand drivers, but raw randwrite speed is actually a bit faster. This suggest the finger should be pointed at ubi or ubifs. I then thought that perhaps the layout of my ubinized image might be a contributing factor so I erased the partition, ubiformatted and ubimkvoled. The problem persisted, Any suggestions as to what might be broken or how to debug this deeper? Can you try this on nandsim and see if there are still differences? You can make nandsim slower by injecting an udelay somewhere. Try this on your x86 host - this way you'll narrow this down to an OMAP-specific or platform-independent problem. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UBIFS not mounting on linux-omap 2.6.36
On Mon, 2010-12-20 at 11:18 +1300, Charles Manning wrote: Hi All I am trying to nail down an omap3 ubifs performance regression, but cannot get Steve Sakoman's 2.6.35 or 2.6.36 kernels http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git to mount ubifs although the same procedure works with older kernels and works with the linux-omap 2.6.37 master. Well, the only hint I can give is some kind of bisecting, but probably you do not need such hint :-) -- Best Regards, Artem Bityutskiy (Битюцкий Артём) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] MTD: NAND: ams-delta: convert to platform driver
On Tue, 2010-12-14 at 21:09 +0100, Janusz Krzysztofik wrote: In its current form, the driver may interfere with different hardware on different boards if built into the kernel, hence is not suitable for inclusion into a defconfig, inteded to be usable with multiple OMAP1 cpu and machine types. Convert it to a platform driver, that should be free from this issue. Created and tested against linux-2.6.37-rc5 on Amstrad Delta. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Pushed to l2-mtd-2.6.git, thanks! -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] omap: nand: remove hardware ECC as default
On Tue, 2010-11-30 at 10:05 -0800, Tony Lindgren wrote: * Sukumar Ghorai s-gho...@ti.com [101119 06:36]: CONFIG_MTD_NAND_OMAP_HWECC defined wrongly in patch submitted for 2.6.36. This flag enables hw ecc by default. Boards like beagle and pandora uses sw ecc for write (e.g. binary flushed from u-boot) and read from kernel. https://patchwork.kernel.org/patch/111036/ Signed-off-by: Sukumar Ghorai s-gho...@ti.com This should go in as a fix for the -rc via MTD list if possible. Acked-by: Tony Lindgren t...@atomide.com Tony, I think this is quite simple patch, and you can merge it yourself, MTD tree is slow. I hope dwmw2 will not beat me for this, but unless he quickly jumps in and confirms he takes care of this patch, just go ahead an merge it. I've put dwmw2 to To:, just in case. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mtd: OneNAND: fix bufferram management when chip has 2-planes.
On Sat, 2010-10-23 at 15:43 +0200, Enric Balletbo i Serra wrote: This patch adds code that I think was lost when it was applied the commit 5988af2319781bc8e0ce418affec4e09cfa77907 - mtd: Flex-OneNAND support Test case: 1. Stress a jffs2 filesystem using bonnie++ -u 0:0 -s 32 -m 16 -r 16 2. dmesg shows various 'Header CRC failed' errors like: Header CRC failed on REF_PRISTINE node at 0x1e81315c: Read 0x00e0, calculated 0x564fc9e8 Tested on IGEP v2 board with a Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58) with 2 planes from Numonyx and CONFIG_MTD_ONENAND_2X_PROGRAM set to y Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com Kyungmin, would be nice to have your ack/nack. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 09/10] OMAP2/3: Convert write/read functions to raw read/write
On Mon, 2010-10-25 at 01:01 +0100, David Woodhouse wrote:
On Thu, 2010-10-07 at 14:50 -0500, Nishanth Menon wrote:
my comment being that by moving {read,write}[wlb] to __raw versions dont
solve the real issue of namespace here. fix should be in
arch/arm/include/asm/io.h IMHO. so that there are no overlaps as this.
Indeed. This patch is complete nonsense.
Removing from my l2 tree.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP: NAND: Fix static declaration warning
On Wed, 2010-10-06 at 03:26 +0530, G, Manjunath Kondaiah wrote: This patch fixes sparse warning for static declaration of variable use_dma drivers/mtd/nand/omap2.c:114:11: warning: symbol 'use_dma' was not declared. Should it be static? Signed-off-by: G, Manjunath Kondaiah manj...@ti.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-...@lists.infradead.org Cc: Tony Lindgren t...@atomide.com Cc: Nishanth Menon n...@ti.com I've pushed this patch to my l2-mtd-2.6.git. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP2/3: NAND: Convert write/read functions to raw read/write
On Wed, 2010-10-06 at 03:26 +0530, G, Manjunath Kondaiah wrote: Following sparse warnings exists due to use of writel/w and readl/w functions. This patch fixes the sparse warnings by converting readl/w functions usage into __raw_readl/__raw_readw functions. drivers/mtd/nand/omap2.c:484:15: warning: symbol '__v' shadows an earlier one drivers/mtd/nand/omap2.c:484:15: originally declared here drivers/mtd/onenand/omap2.c:86:9: warning: symbol '__v' shadows an earlier one drivers/mtd/onenand/omap2.c:86:9: originally declared here Signed-off-by: G, Manjunath Kondaiah manj...@ti.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-...@lists.infradead.org I've pushed this patch to my l2-mtd-2.6.git. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nand: omap2: Missing arg to gpmc_prefetch_reset()
On Fri, 2010-09-24 at 23:45 +0200, Loïc Minier wrote: Fix missing cs arg to gpmc_prefetch_reset() when CONFIG_MTD_NAND_OMAP_PREFETCH_DMA=y which caused a build failure since 948d38e799f0ab87cf8ed9113fcdaaee61acf321: drivers/mtd/nand/omap2.c: In function 'omap_nand_dma_transfer': drivers/mtd/nand/omap2.c:416: error: too few arguments to function 'gpmc_prefetch_reset' Signed-off-by: Loïc Minier loic.min...@linaro.org --- drivers/mtd/nand/omap2.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) FYI, a similar patch is already in Linus' tree, so I'm dropping it from my tree: commit f12f662f29d5801e598c6bb4a71e54b2de218f72 Author: Daniel J Blueman daniel.blue...@gmail.com Date: Wed Sep 29 21:01:55 2010 +0100 fix OMAP2 MTD build failure Fix build failure from recent interface change and merge. Tested on OMAP3430. Signed-off-by: Daniel J Blueman daniel.blue...@gmail.com Signed-off-by: Linus Torvalds torva...@linux-foundation.org -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nand: omap2: Missing arg to gpmc_prefetch_reset()
On Mon, 2010-10-04 at 10:52 +0200, Loïc Minier wrote: On Mon, Oct 04, 2010, Artem Bityutskiy wrote: FYI, a similar patch is already in Linus' tree, so I'm dropping it from my tree Ok, thanks; is there something I should have done to get this patch into Linus tree? No, you did everything right. I guess that guy was just faster than you. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nand: omap2: Missing arg to gpmc_prefetch_reset()
On Fri, 2010-09-24 at 23:45 +0200, Loïc Minier wrote: Fix missing cs arg to gpmc_prefetch_reset() when CONFIG_MTD_NAND_OMAP_PREFETCH_DMA=y which caused a build failure since 948d38e799f0ab87cf8ed9113fcdaaee61acf321: drivers/mtd/nand/omap2.c: In function 'omap_nand_dma_transfer': drivers/mtd/nand/omap2.c:416: error: too few arguments to function 'gpmc_prefetch_reset' Signed-off-by: Loïc Minier loic.min...@linaro.org Looks like a regression which should be merged to 2.6.36. I've taken this patch to l2-mtd-2.6.git, will ping dwmw2 about the need to merge this to 2.6.36. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap3: sr: improve errors handling
On Fri, 2010-07-09 at 16:20 +0300, Artem Bityutskiy wrote: From: Artem Bityutskiy artem.bityuts...@nokia.com Do not forget to check the 'platform_device_add_data()' error code in 'omap_device_build_ss()'. Signed-off-by: Artem Bityutskiy artem.bityuts...@nokia.com Please, discard this patch, I'll send a new one with amended subject. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]omap:dmtimer:no null check for kzalloc
On Mon, 2010-07-12 at 03:39 +0530, Tarun Kanti DebBarma wrote:
+ if (!pdata) {
+ pr_err(%s: \
+ No memory for omap_dm_timer_plat_info\n,
+ __func__);
+ return -ENOMEM;
+ }
do not use concatenation ('\'), this is probably not what you want.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-SR] [PATCH 5/7] omap3: sr: device: add unlikely checks
On Fri, 2010-06-25 at 16:46 -0500, Nishanth Menon wrote: Add unlikely checks to better optimize the rare occurrance of erroneous conditions. Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Thara Gopinath th...@ti.com Signed-off-by: Nishanth Menon n...@ti.com unlikely and friends make sens only in realy hot path places. In other places like you touch, they are pointless - better let gcc make a choice of how to arrange code. And they only make the code less readable by adding extra braces and making ifs longer. Thus, NACK for this from my side. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] omap3: sr: fix memory leak and simplify the code
From: Artem Bityutskiy artem.bityuts...@nokia.com
This patch fixes the following problem indicated by kmemleak:
kmemleak: unreferenced object 0xdf93c280 (size 64):
kmemleak: backtrace:
kmemleak: [c00df6d4] create_object+0x104/0x200
kmemleak: [c00d7638] kmem_cache_alloc+0xe4/0xf4
kmemleak: [c000fc38] omap_devinit_smartreflex+0x44/0x244
kmemleak: [c003a33c] do_one_initcall+0x5c/0x1b8
kmemleak: [c00083fc] kernel_init+0x94/0x110
kmemleak: [c003ba04] kernel_thread_exit+0x0/0x8
The reason is that 'omap_devinit_smartreflex()' allocates 'sr_data',
then passes it to 'omap_device_build()', which 'kmemdup()'s it and
uses the copy. But 'omap_devinit_smartreflex()' never frees 'sr_data'.
This patch make 'sr_data' to be a stack variable, which eliminates
the memory leak and simplifies the code a bit.
Signed-off-by: Artem Bityutskiy artem.bityuts...@nokia.com
---
arch/arm/mach-omap2/sr_device.c | 27 +--
1 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 24630ef..d1bb495 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -129,7 +129,7 @@ static int __init omap_devinit_smartreflex(void)
char *name = smartreflex;
do {
- struct omap_smartreflex_data *sr_data;
+ struct omap_smartreflex_data sr_data;
struct omap_smartreflex_dev_data *sr_dev_data;
struct omap_device *od;
struct omap_hwmod *oh;
@@ -140,15 +140,7 @@ static int __init omap_devinit_smartreflex(void)
if (!oh)
break;
- sr_data = kzalloc(sizeof(struct omap_smartreflex_data),
- GFP_KERNEL);
sr_dev_data = (struct omap_smartreflex_dev_data *)oh-dev_attr;
- if (!sr_data) {
- pr_warning(%s: could not find hwmod data for %d\n,
- __func__, i + 1);
- kfree(sr_data);
- return -ENOMEM;
- }
/*
* OMAP3430 ES3.1 chips by default come with Efuse burnt
@@ -159,26 +151,25 @@ static int __init omap_devinit_smartreflex(void)
*/
if (cpu_is_omap343x()) {
if (omap_rev() == OMAP3430_REV_ES3_1)
- sr_data-enable_on_init = true;
+ sr_data.enable_on_init = true;
else
- sr_data-enable_on_init = false;
+ sr_data.enable_on_init = false;
} else {
- sr_data-enable_on_init = false;
+ sr_data.enable_on_init = false;
}
- sr_data-device_enable = omap_device_enable;
- sr_data-device_shutdown = omap_device_shutdown;
- sr_data-device_idle = omap_device_idle;
+ sr_data.device_enable = omap_device_enable;
+ sr_data.device_shutdown = omap_device_shutdown;
+ sr_data.device_idle = omap_device_idle;
omap_get_voltage_table(i, sr_dev_data-volt_data,
sr_dev_data-volts_supported);
- sr_set_nvalues(sr_dev_data, sr_data);
+ sr_set_nvalues(sr_dev_data, sr_data);
- od = omap_device_build(name, i, oh, sr_data, sizeof(*sr_data),
+ od = omap_device_build(name, i, oh, sr_data, sizeof(sr_data),
omap_sr_latency,
ARRAY_SIZE(omap_sr_latency), 0);
if (IS_ERR(od)) {
pr_warning(%s: Could not build omap_device %s:%s\n,
__func__, name, oh-name);
- kfree(sr_data);
}
i++;
} while (1);
--
1.7.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap3: sr: improve errors handling
From: Artem Bityutskiy artem.bityuts...@nokia.com Do not forget to check the 'platform_device_add_data()' error code in 'omap_device_build_ss()'. Signed-off-by: Artem Bityutskiy artem.bityuts...@nokia.com --- arch/arm/plat-omap/omap_device.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index f2bd2e2..e8da192 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -414,7 +414,9 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id, od-pdev.num_resources = res_count; od-pdev.resource = res; - platform_device_add_data(od-pdev, pdata, pdata_len); + ret = platform_device_add_data(od-pdev, pdata, pdata_len); + if (ret) + goto odbs_exit4; od-pm_lats = pm_lats; od-pm_lats_cnt = pm_lats_cnt; -- 1.7.1.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] omap3: sr: fix memory leak and simplify the code
On Fri, 2010-07-09 at 16:20 +0300, Artem Bityutskiy wrote: From: Artem Bityutskiy artem.bityuts...@nokia.com This patch fixes the following problem indicated by kmemleak: kmemleak: unreferenced object 0xdf93c280 (size 64): kmemleak: backtrace: kmemleak: [c00df6d4] create_object+0x104/0x200 kmemleak: [c00d7638] kmem_cache_alloc+0xe4/0xf4 kmemleak: [c000fc38] omap_devinit_smartreflex+0x44/0x244 kmemleak: [c003a33c] do_one_initcall+0x5c/0x1b8 kmemleak: [c00083fc] kernel_init+0x94/0x110 kmemleak: [c003ba04] kernel_thread_exit+0x0/0x8 The reason is that 'omap_devinit_smartreflex()' allocates 'sr_data', then passes it to 'omap_device_build()', which 'kmemdup()'s it and uses the copy. But 'omap_devinit_smartreflex()' never frees 'sr_data'. This patch make 'sr_data' to be a stack variable, which eliminates the memory leak and simplifies the code a bit. Signed-off-by: Artem Bityutskiy artem.bityuts...@nokia.com --- arch/arm/mach-omap2/sr_device.c | 27 +-- 1 files changed, 9 insertions(+), 18 deletions(-) Note, I only compile-tested both of the patches, so be careful. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-SR] [PATCH 5/7] omap3: sr: device: add unlikely checks
On Fri, 2010-07-09 at 08:40 -0500, Nishanth Menon wrote:
Artem Bityutskiy had written, on 07/09/2010 08:12 AM, the following:
On Fri, 2010-06-25 at 16:46 -0500, Nishanth Menon wrote:
Add unlikely checks to better optimize the rare occurrance of
erroneous conditions.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
unlikely and friends make sens only in realy hot path places. In other
places like you touch, they are pointless - better let gcc make a choice
@@ -43,8 +43,9 @@ static void __init sr_read_efuse(struct omap_sr_dev_data
*dev_data,
{
int i;
- if (!dev_data || !dev_data-volts_supported || !dev_data-volt_data ||
- !dev_data-efuse_nvalues_offs) {
+ if (unlikely(!dev_data || !dev_data-volts_supported ||
+ !dev_data-volt_data ||
+ !dev_data-efuse_nvalues_offs)) {
@@ -87,8 +88,8 @@ static void __init sr_set_testing_nvalues(struct
omap_sr_dev_data *dev_data,
{
int i;
- if (!dev_data || !dev_data-volts_supported ||
- !dev_data-volt_data || !dev_data-test_nvalues) {
+ if (unlikely(!dev_data || !dev_data-volts_supported ||
+ !dev_data-volt_data || !dev_data-test_nvalues)) {
and other places, why do you think that these are checks that should be
expected? - would be great if you can explain inline to the patch which
unlikely checks dont make sense.
static functions such as these are helpers for the maincode, unless
something horribly wrong occurs within the codepath calling these
helpers, they are not expected to be invalid parameters. hence the
rationale for adding unlikely.
Sorry, I do not really understand you. All I said is that
unlikely()/likely() are usually used in hot-paths / tight loops.
unlikely()/likely() are micro optimization. They make no difference when
you use them in initialization paths.
So what I said, that in your patch they will make no difference
performance wise. So no benefits.
But they make if () statements a bit more difficult to read, this is a
drawback.
So your patch introduces no benefits, just a drawback. Thus, it is not
good.
There were many flamewars about unlikely and likely in lkml in the past.
And the outcome was always - do not use them anywhere except of
performance-critical tight loops / hot paths.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] omap3: sr: improve errors handling
On Fri, 2010-07-09 at 20:35 +0530, Gopinath, Thara wrote: -Original Message- From: Artem Bityutskiy [mailto:dedeki...@gmail.com] Sent: Friday, July 09, 2010 6:50 PM To: linux-omap@vger.kernel.org Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara; Peter p2 De Schrijver Subject: [PATCH 2/2] omap3: sr: improve errors handling From: Artem Bityutskiy artem.bityuts...@nokia.com Do not forget to check the 'platform_device_add_data()' error code in 'omap_device_build_ss()'. Hello Artem, Can we have a better subject and description. The subject esp has got nothing to do with the fix. Hmm, I do not see why you think so. I think the subject is fine - the patch improves error handling in the SR code. Then description says how exactly it improves it - it makes the code to not forget to check the return code, and it tells in which function and which return code. So the logic is: 1. The subject line is a short description which gives the idea what the commit is about. So, my subject line says: 1.1. It is about omap3 (which is true) 1.2. It is about sr (which is true) 1.3. It improves error handling (which is also true) So the subject line is descriptive enough. It does not have to provide all glory details. Then the description provides the details. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap3: sr: improve errors handling
On Fri, 2010-07-09 at 10:51 -0500, Nishanth Menon wrote: So the logic is: 1. The subject line is a short description which gives the idea what the commit is about. So, my subject line says: 1.1. It is about omap3 (which is true) 1.2. It is about sr (which is true) I think Thara's contention is that this is omap_device related- yeah SR is one of the users of omap_device, but there are much more folks using omap_device in l-o today. I see. I'll try to come up with a better prefix, but if you suggest me a good subject line, I'll be grateful :-) -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] omap3: sr: improve errors handling
On Fri, 2010-07-09 at 11:00 -0500, Menon, Nishanth wrote: -Original Message- From: Artem Bityutskiy [mailto:dedeki...@gmail.com] Sent: Friday, July 09, 2010 10:51 AM On Fri, 2010-07-09 at 10:51 -0500, Nishanth Menon wrote: So the logic is: 1. The subject line is a short description which gives the idea what the commit is about. So, my subject line says: 1.1. It is about omap3 (which is true) 1.2. It is about sr (which is true) I think Thara's contention is that this is omap_device related- yeah SR is one of the users of omap_device, but there are much more folks using omap_device in l-o today. I see. I'll try to come up with a better prefix, but if you suggest me a good subject line, I'll be grateful :-) Subject: omap: device: improve errors handling Do not forget to check the 'platform_device_add_data()' error code in 'omap_device_build_ss()'. How does that sound? Good, thank you! I'll re-send the patch tomorrow unless you change the subject yourself :-) -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible bug in onenand_base ?
On Thu, 2010-07-08 at 12:11 +0200, Enric Balletbò i Serra wrote: Hello, 2010/7/8 Artem Bityutskiy dedeki...@gmail.com: On Thu, 2010-07-08 at 11:55 +0200, Enric Balletbò i Serra wrote: Hello, I made new tests regarding this issue. Looks like the problem is reading from the OneNAND device. Did you try older kernel and then bisecting who is responsible for the breakage? Yes, before commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd: Flex-OneNAND support) http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5988af2319781bc8e0ce418affec4e09cfa77907 my OneNAND is working, after the commit, the OneNAND support is broken. Ok, we could revert it, but it is better to fix it. CCing the author of the commit. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible bug in onenand_base ?
Probably Adrian could comment on this?
On Fri, 2010-04-30 at 12:05 +0200, Enric Balletbò i Serra wrote:
Hello all,
After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
Flex-OneNAND support) the onenand support for my device is broken.
Before this commit when I run the nandtest program all is ok
---
# nandtest /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
002c: checking...
Finished pass 1 successfully
--
Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
fails with:
---
# nandtest /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
: reading...
[ 299.092041] onenand_wait: ECC error = 0x8488
( ... lots of ECC errors ... )
[ 299.092041] onenand_wait: ECC error = 0x8488
ECC failed at
: checking...
compare failed. seed 1804289383
Byte 0x1 is 5a should be da
Byte 0x3 is 82 should be 92
Byte 0x4 is 10 should be 1a
( ... )
---
Investigating a little I see a significant difference introduced by
this patch. In line
347:page = (int) (addr - onenand_addr(this, block))
this-page_shift; (patch applied)
instead of
347:page = (int) (addr this-page_shift); (without patch)
I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
the line 347 and now works again. Fantastic, but I suspect this is not
the proper solution (probably this breaks other onenands devices, I
can't test).
I'm just introducing in OneNAND devices so anyone can help me to
understand and solve the problem ? Note that my device is a Numonyx
4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
page )
Thanks in advance,
///:~Enric
---
diff --git a/drivers/mtd/onenand/onenand_base.c
b/drivers/mtd/onenand/onenand_base.c
index 081f97d..b1d50a3 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
int cmd, loff_t addr, size_t le
default:
block = (int) onenand_block(this, addr);
- page = (int) (addr - onenand_addr(this, block))
this-page_shift;
+ page = (int) (addr this-page_shift);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
---
__
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
