Numonyx NOR and chip->mutex bug?

[Michael Cashwell]

On Feb 7, 2011, at 10:01 AM, Joakim Tjernlund wrote:

> Stefan Bigler <stefan.bigler at keymile.com> wrote on 2011/02/07 15:47:00:
>> 
> 
>> I run the test on my side with the patches proposed with and without barrier().
>> Both worked without problems.
> 
> Thanks for testing.

So that means moving the chip state while loop first solves the problem for both of you. That's good news and makes it more likely that you are seeing the same issue. I'm OK that it doesn't fix my issue. It's seemed different from the beginning.

>> My workspace has now the following patches:
>> 
>> 1) clear status before suspend

No, before erase resume.

>> ------------------------------
>> +    /* numonyx data sheet clearly says to always reset the status bits
>> +       before resuming a suspended erase. not doing so results in
>> +       an ambiguous mixture of status bits once the command ends. */
>> +    debug_map_write(map, CMD(0x50), adr);
>> +    debug_map_write(map, CMD(0xd0), adr);
> 
> The 0xd0 seems should not be there, its already in place?

I think he meant the 0xd0 line to be context, not added. So maybe the + was wrong?

My current workaround from my problem is to do a throw-away status read "(void) map_read(map, addr);" after that 0x50, 0xd0, 0x70 sequence.

Since no one else is seeing my problem I expect it's some issue with my specific batch of chips. Ugh.

> it does seem like a good idea to add a Clear Status to be sure you won't end up with error bits set just before resume.
> This is a separate patch though. Does your test case work without this patch and only my patch applied?
> 
>> 2) compare chip>state and chip_state before touching the chip
>> ------------------------------------------------------------
> 
> I plan to submit this one shortly, if you and Michael could Ack. it when I do, that would be great.

Happy to test and ack when it arrives.

-Mike