Numonyx NOR and chip->mutex bug?

Stefan Bigler stefan.bigler at
Fri Feb 4 06:04:40 EST 2011

Hi Jocke

The code does the same, but is much nicer :-)
My test is also working again.

Im on the way to find out why our old P30 (130nm) Flash worked
without the fix.

Regards Stefan

Am 02/04/2011 11:47 AM, schrieb Joakim Tjernlund:
> Stefan Bigler<stefan.bigler at>  wrote on 2011/02/04 00:18:44:
>> Hi
>> Now I have a patch that fix my problem. I did not yet do a lot of tests
>> and I did
>> not yet analyzed correctness in all cases.
>> I check in the inval_cache_and_wait_for_operation() of the status is
>> status_OK
>> the if the chip->state and the chip_state (the current chip state and
>> the chip state
>> when the function is called) are equal or not. If equal break and exit
>> (set the
>> chip->state= FL_STATUS) and if not equal add the thread in the wait queue.
>> I think we are not finished when not equal so we have do not have to
>> take the mutex.
>> Now why this code worked with the older Flash chips. I don't know, but
>> eventually
>> they are slower after the write buffer command 0xe8 and they are still
>> busy when
>> inval_cache_and_wait_for_operation() checks if status_OK.
>> Tomorrow I'll check if this is the case. Now I do not have access to the HW.
>> Regards Stefan
> I havn't looked into this but I think I would rather see something like:
> -        if (map_word_andequal(map, status, status_OK, status_OK))
> +        if (map_word_andequal(map, status, status_OK, status_OK)&&
> +           (chip->state == chip_state))
> Does this work for you too?
>   Jocke

More information about the linux-mtd mailing list