From mboxrd@z Thu Jan 1 00:00:00 1970 From: robert.jarzmik@free.fr (Robert Jarzmik) Date: Tue, 01 Sep 2009 21:08:39 +0200 Subject: How to work out the cause of a DMA Bus Error (QCI PXA320)? In-Reply-To: <20090831183042.26357169rn4rl5ma@webmail.tu-cottbus.de> (Judith Baumgarten's message of "Mon, 31 Aug 2009 18:30:42 +0200") References: <20090827182308.19411cv37br99zvw@webmail.tu-cottbus.de> <87iqg7ixcp.fsf@free.fr> <20090831183042.26357169rn4rl5ma@webmail.tu-cottbus.de> Message-ID: <87r5uq7aa0.fsf@free.fr> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Judith Baumgarten writes: > Zitat von Robert Jarzmik : > >> Guennadi Liakhovetski writes: >> >>> On Thu, 27 Aug 2009, Judith Baumgarten wrote: >> "V4L/DVB (11322): pxa_camera: Fix overrun condition on last buffer" >> "V4L/DVB (11321): pxa_camera: Redesign DMA handling" >> >> if you're writing a new driver, have a look t pxa270 and at those patches >> specifically. >> > I implemented the most important things of that patches and it seems to solve > some of the errors (The error occurs later). Good. Guennadi won't be mad I broke the design :) May I suggest an old and dirty trick I used to debug the DMA on pxa27x. I tried the smallest size of picture, and multiple of 16 in bytes. I think it was 48x32 pixels of RGB565 (ie. 48 * 32 * 2 bytes). As you can see, that size fits in one transfer (assuming it begins on a page start). Now you try that transfer, and if a BUSERR occurs, you freeze the DMA, (comment out the DMA restarting). You check the DMA registers, find the culprit, and all is good. If you don't, you try several images, as those sport reporters shooting Formula One cars. If that doesn't trigger the bug either, you try prime numbers for width and height (small ones first, big ones next). If that doesn't trigger the bug, there is no bug :) > Could you explain how to create these entries in sysfs? They could be really > helpfull, because it seems, that it's a timing problem. If I insert two or > three printks it works for over 30 minutes (I stopped it then). I could provide you this : http://git.kernel.org/?p=linux/kernel/git/ycmiao/pxa-linux-2.6.git;a=commitdiff;h=f957c87757a2e2dcf825ed66d5489f9848cf8d75;hp=4ed0ec58fbcc76925d22854fa5050c2748ae3270 This is a bit egocentric, but I think that's the kind of stuff you're looking for. And if you work on in, I hope you'll expand that patch so add the specific pxa3xx registers. > >> Ah, and you're right, there is no "RUN" bit in CICMDx. I suspect, after a 30s >> reading of the specification, that reloading CIDADR with a correct value will >> trigger the DMA transfer (QCI DMA FIFO threshold -> DMA request line assert >> -> >> DMA transfer). > Yes you are right. It starts again, if I load a new Descriptor but I always get > fifo overruns then. I will try to implement the overflow handling of chapter > 3.4.5.3 exactly. At the moment I didn't use the CICR0_DIS... Seems a timing issue ... maybe the time the descriptor is loaded, the fifo is overrun. I seem to remember a discussion with Guennadi about DMA startup. Guennadi thought it would be better to prepare DMA before QCI interrupt signaling the end of frame (and the near to come beginning of the next one), I thought DMA should be dealt with after the interrupt. Maybe you'll prove me wrong, who knows ... Cheers. -- Robert