How to work out the cause of a DMA Bus Error (QCI PXA320)?

[Robert Jarzmik]

Judith Baumgarten <judith.baumgarten at tu-cottbus.de> writes:

> Zitat von Robert Jarzmik <robert.jarzmik at free.fr>:
>
>> Guennadi Liakhovetski <g.liakhovetski at gmx.de> 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