**** BEGIN LOGGING AT Mon Dec 09 02:59:58 2013
Dec 09 10:37:08 <ant_work> lumag: I think I've identified the timeout issue, is in inval_cache_and_wait_for_operation()
Dec 09 10:37:26 <ant_work> unfortunately I'm lost with the mutex/spinlocks etc ;)
Dec 09 10:38:27 <ant_work> I think this patch should have fixed race but maybe not in our case...
Dec 09 10:38:30 <ant_work> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mtd/chips/cfi_cmdset_0001.c?id=ecf3fde07c8dcb92a1bf3fbdfe70905d85cd00e1
Dec 09 10:39:46 <ant_work> it is here where the status is read as '0' on first run
Dec 09 10:41:31 <lumag> Hmm. Interesting
Dec 09 10:43:43 <ant_work> strangely I 'd expect a read of 0xFFFF from a suspended chip, isn't?
Dec 09 10:48:06 <ant_work> I have plenty of debug logs, filled with printk outputing the function where we do map_read/write
Dec 09 10:52:09 <ant_work> the return value checked before "Chip not ready for buffer write." is ret = WAIT_TIMEOUT(map, chip, cmd_adr, 0, 0);
Dec 09 11:09:11 <ant_work> oh, and about the QRY...it is clearly written in the spec that "The query code is presented on the lower-byte data
Dec 09 11:09:11 <ant_work> outputs (DQ7-0)."
Dec 09 13:55:59 <ant_work> bluelightning: the  "files/device_table-minimal.txt" in meta-handheld is out of sync. 0 instead of root etc.
Dec 09 13:56:41 <bluelightning> ant_work: ok
Dec 09 13:56:42 <ant_work> the file is only there for machines using 2.6 so w/out devtmpfs
Dec 09 13:59:09 <ant_work> the one in oe-core still lacks /dev/input /dev/sd* /dev/mmcblck* so cannot be replaced
Dec 09 13:59:18 <ant_work> (wondering about that one in oe-core...)
Dec 09 15:33:10 <ant_work> lumag: about that same patch for races, here they had another solution
Dec 09 15:33:22 <ant_work> http://lists.infradead.org/pipermail/linux-mtd/2011-April/034870.html
Dec 09 15:34:26 <ant_work> see, also on Sharp chips latency is 500 us
Dec 09 15:34:30 <ant_work> 5. If the interval time from a Block Erase Resume command to a subsequent Block Erase Suspend command is shorter
Dec 09 15:34:30 <ant_work> than tERES and its sequence is repeated, the block erase operation may not be finished.
Dec 09 15:35:14 <ant_work> but really I think our issue is with the page buffer, not with erase but I can be wrong
Dec 09 15:37:23 <ant_work> seems more "(Page Buffer) Program Suspend
Dec 09 15:37:23 <ant_work> Latency Time to Read"
Dec 09 15:37:40 <ant_work> which is just 10 us (max)
Dec 09 16:53:16 <ant_home> lumag: boot + instant unlock (seems all ok)  http://pastebin.com/LyyPYA9K
Dec 09 16:55:09 <ant_home> lumag: here is flash_eraseall  http://pastebin.com/gwSQCx9H
Dec 09 16:55:25 <ant_home> ..and here it starts reading status = 0 (busy)
Dec 09 17:13:08 <ant_home> curiously flashcpy buffered get always status 80... http://pastebin.com/94kDfm07
Dec 09 17:20:27 <ant_home> so it seems it is Block Erase the operation failing
Dec 09 17:20:53 <ant_home> better, not ready on first access
Dec 09 17:21:29 * ant_home will read for fun the partitioning register
Dec 09 18:01:11 <ant_home> lumag: well, it seems we have another problem...
Dec 09 18:01:38 <ant_home> Partition Configuration Register:400
Dec 09 18:01:39 <ant_home> sa1100-0: Found 2 x16 devices at 0x0 in 32-bit bank. Manufacturer ID 0x0000b0 Chip ID 0x0000b0
Dec 09 18:01:53 <ant_home> 400 = 10000000000
Dec 09 18:02:22 <ant_home> so the PCR is 100 (as default after reset)
Dec 09 18:04:36 <ant_home> 100 = Plane 0-2 are merged into one partition.
Dec 09 18:04:36 <ant_home> (default in a top parameter device)
Dec 09 18:05:17 <ant_home> page 16 of the datasheet LH28F640BFHE-PTTL90(2.41)
Dec 09 18:07:07 <ant_home> "Status register reflects partition state, not WSM (Write State Machine) state - this allows a status register for each partition."
Dec 09 18:13:02 <ant_home> and finally the appendix datasheet at 4.7 shows
Dec 09 18:13:05 <ant_home> STATUS CHECK PROCEDURE
Dec 09 18:13:05 <ant_home> FOR ALL PARTITIONS
Dec 09 18:13:05 <ant_home> BEFORE BLOCK ERASE OPERATION
Dec 09 18:13:52 <ant_home> my question is why the he** did Sharp overcomplicate things on collie?
Dec 09 18:14:07 * ant_home heading to the kitchen 
**** ENDING LOGGING AT Tue Dec 10 02:59:58 2013