From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [85.21.88.2] (helo=mail.dev.rtsoft.ru) by canuck.infradead.org with smtp (Exim 4.52 #1 (Red Hat Linux)) id 1ENEr2-0005j2-Bm for linux-mtd@lists.infradead.org; Wed, 05 Oct 2005 15:23:13 -0400 Message-ID: <43442813.8050700@ru.mvista.com> Date: Wed, 05 Oct 2005 23:22:59 +0400 From: Vitaly Wool MIME-Version: 1.0 To: Vitaly Bordug References: <434130A3.2090908@ru.mvista.com> <1128381010.13057.16.camel@tglx.tec.linutronix.de> <43426D4F.2000400@ru.mvista.com> <1128444102.13057.46.camel@tglx.tec.linutronix.de> <4343FCE3.8090307@ru.mvista.com> In-Reply-To: <4343FCE3.8090307@ru.mvista.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: tglx@linutronix.de, linux-mtd@lists.infradead.org Subject: Re: [PATCH] MTD NAND: Fix ECC errors in au1550nd.c List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: \__/\__/\__/\__/\_______ [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