Re: [PATCH] MTD NAND: Fix ECC errors in au1550nd.c

[Vitaly Wool <vwool@ru.mvista.com>]

Vitaly Bordug wrote:

> Thomas Gleixner wrote:
>
>> On Tue, 2005-10-04 at 15:53 +0400, Vitaly Bordug wrote:
>>
>>> Actually, yes, a sort of. The issue was in some bytes lost during 
>>> read cycles (ECC errors reported) when PCMCIA (board AMD Alchemy 
>>> 1550) is active. This does not take place when 4 CS drives  happen - 
>>> as shown on the timing diagram - e.g.
>>> cs: \__/\__/\__/\__/\_<CS low>______ [works fine]
>>>                     ^
>>>         asserted by SoC controller
>>> unchanged code:
>>> cs:\______________/\_[PCMCIA driver steals bytes ]...
>>>                ^
>>>         asserted by SoC controller
>>
>>
>>
>> Right. Thats a known problem with those FLASH types. You have to hold CS
>> low until the busy pin goes high.
>>
>> Hmm, you have to protect against interrupts during this time I guess ?
>> If not you can use the existing controller lock implementation to
>> protect against concurrent access.
>>
> Yes. That's because making a global locking mechanism across 3 
> different divers looks more ugly than just local_irq_save() for a 
> short period in one callback.

Enabling interrupts in callback looks quite dangerous to me. I'm also 
afraid that real-time responsiveness of that system is not gonna be 
satisfactory.
So why not implement mutex-based bus_lock()/bus_unlock() routines 
somewhere in arch/mips/somewhere and call those from wherever they are 
needed to prevent concurrent access? It'a a question due to the fact 
that I haven't seen evidence that you really need to disable interrupts, 
if that's not the case, please elaborate :)

Vitaly