**** BEGIN LOGGING AT Thu Jan 23 02:59:59 2014
Jan 23 12:33:00 <ant_work> lumag: I have maybe discovered why two 16 chips return status 80808080: some LH28* parts use SR.15 for the global partition status and this would be 0x8000
Jan 23 12:33:13 <ant_work> so if SR.7 is also set we get 8080
Jan 23 12:33:27 <lumag> ant_work, hello
Jan 23 12:33:40 <ant_work> hi
Jan 23 12:33:40 <lumag> So it is normal status, just unexpected by driver.
Jan 23 12:33:42 <lumag> Isn't it?
Jan 23 12:34:01 <ant_work> see, thius is on the docs for the bottom-block version of our flash
Jan 23 12:34:13 <ant_work> the -PBTL70A
Jan 23 12:34:21 <ant_work> 2004
Jan 23 12:34:33 <ant_work> our flash is 2001 and the docs don't mention it..
Jan 23 12:35:24 <ant_work> note that the logic is opposite to the one of Intel part (using PWS = SR.0)
Jan 23 12:35:40 <ant_work> SR.15  1 = Ready in All Partitions
Jan 23 12:35:50 <ant_work> while for Intel parts is the opposite: 1 =Program or erase operation in other partition.
Jan 23 12:36:37 <ant_work> so I *think* we should check for 8080 because 0080 means some partition is writing/erasing
Jan 23 12:37:39 <ant_work> now, it happens that 0x8080 & 0x80 = 0x80
Jan 23 12:37:56 <ant_work> so I'm under the impression we pass the checks...
Jan 23 12:38:41 <ant_work> see how it was introduced in 2004:
Jan 23 12:38:42 <ant_work> http://lists.infradead.org/pipermail/linux-mtd-cvs/2004-June/003741.html
Jan 23 12:39:19 <ant_work> (the previous patches are introducing the multi-partition chips)
Jan 23 12:41:16 <ant_work> lumag: how would you change
Jan 23 12:41:16 <ant_work> if (chip->priv && (status & status_PWS) == status_PWS)
Jan 23 12:41:21 <ant_work> ?
Jan 23 12:42:13 <lumag> I'd use status_PWS that depends on the used chip
Jan 23 12:42:24 <ant_work> PWS = CMD(0x8080) ?
Jan 23 12:42:44 <lumag> Yes.
Jan 23 12:42:46 <lumag> if LH28
Jan 23 12:43:30 <ant_work> btw, if you have a moment, check at the very end, the last table
Jan 23 12:43:32 <ant_work> http://www.sharpsma.com/webfm_send/819
Jan 23 12:44:44 <ant_work> I understand it, when SR.15 is 1 the 'pulse/like a laser for CD' is active
Jan 23 12:45:00 <ant_work> er.. when is 0
Jan 23 12:45:51 <ant_work> Figure A-3-1
Jan 23 12:49:40 <ant_work> this page is missing from our spec...still I get 8080 readings...
Jan 23 12:50:34 <lumag> what is pulsing?
Jan 23 12:51:03 <ant_work> the erase/write 'pulse'? higher voltage?
Jan 23 12:52:09 <ant_work> I've read about pulse in other docs about suspend/resume ...
Jan 23 12:55:28 <ant_work> so basically if we don't get 8080 the WSM is busy...and I'm pretty sure we received 00800080 after CM(0xe8) write to buffer
Jan 23 12:56:24 <ant_work> I'm a bit confused about the bit-test to do :p
Jan 23 12:57:14 <ant_work> bluelightning: in the meanwhile pls pull meta-hh
Jan 23 12:57:58 <ant_work> for devel we'll just do minor edits on the top of it
**** ENDING LOGGING AT Fri Jan 24 02:59:59 2014