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

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

[Judith Baumgarten]

Hi,

I'm still working on the pxa_camera driver for PXA320. At the moment I  
can capture some frames (RAW mode), but then I get a DMA Bus Error.  
Has anyone an idea how to deal with that error or work out the  
specific cause?
The manual says, that if an error occures the channel is stopped until  
it's reprogrammed and the corresponding RUN bit is set, but there are  
no RUN bits in QCI DMA. So I don't see a chance to start it again...

Thanks,
Judith

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

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

[Guennadi Liakhovetski]

On Thu, 27 Aug 2009, Judith Baumgarten wrote:

> Hi,
> 
> I'm still working on the pxa_camera driver for PXA320.

Is this a new driver or an extension to pxa270?

> At the moment I can
> capture some frames (RAW mode), but then I get a DMA Bus Error. Has anyone an
> idea how to deal with that error or work out the specific cause?
> The manual says, that if an error occures the channel is stopped until it's
> reprogrammed and the corresponding RUN bit is set, but there are no RUN bits
> in QCI DMA. So I don't see a chance to start it again...

I think we also had some DMA issues on pxa270, but we fixed them latest 
with these patches:

"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.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

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

[Robert Jarzmik]

Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:

> On Thu, 27 Aug 2009, Judith Baumgarten wrote:
>
>> Hi,
>> 
>> I'm still working on the pxa_camera driver for PXA320.
>
> Is this a new driver or an extension to pxa270?
Good question :)

>> At the moment I can
>> capture some frames (RAW mode), but then I get a DMA Bus Error. Has anyone an
>> idea how to deal with that error or work out the specific cause?
>> The manual says, that if an error occures the channel is stopped until it's
>> reprogrammed and the corresponding RUN bit is set, but there are no RUN bits
>> in QCI DMA. So I don't see a chance to start it again...
>
> I think we also had some DMA issues on pxa270, but we fixed them latest 
> with these patches:
>
> "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.

You know, that little beast of PXA320 has a _dedicated_ 4-channel DMA controller
(with dedicated registers CIDADR, CIDSADR, ...). Maybe the rules we followed
for pxa270 are not all true anymore.

I would suggest to Judith to scan with care PXA3xx manual, volume III, chapter
3.4.5. To help debugging, you could add sysfs entries for CI* registers in
3.5.28.

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).

Cheers.

--
Robert

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

[Judith Baumgarten]

Zitat von Robert Jarzmik <robert.jarzmik@free.fr>:

> Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:
>
>> On Thu, 27 Aug 2009, Judith Baumgarten wrote:
>>
>>> Hi,
>>>
>>> I'm still working on the pxa_camera driver for PXA320.
>>
>> Is this a new driver or an extension to pxa270?
> Good question :)
It's an extension to the existing one (kernel 2.6.28.7).

>>> At the moment I can
>>> capture some frames (RAW mode), but then I get a DMA Bus Error.  
>>> Has anyone an
>>> idea how to deal with that error or work out the specific cause?
>>> The manual says, that if an error occures the channel is stopped until it's
>>> reprogrammed and the corresponding RUN bit is set, but there are  
>>> no RUN bits
>>> in QCI DMA. So I don't see a chance to start it again...
>>
>> I think we also had some DMA issues on pxa270, but we fixed them latest
>> with these patches:
>>
>> "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).

> You know, that little beast of PXA320 has a _dedicated_ 4-channel  
> DMA controller
> (with dedicated registers CIDADR, CIDSADR, ...). Maybe the rules we followed
> for pxa270 are not all true anymore.
Yes I know. The rules are almost the same, except that I can't say,  
stop DMA at the end of the sglist with that DDADR_STOP bit.
>
> I would suggest to Judith to scan with care PXA3xx manual, volume  
> III, chapter
> 3.4.5. To help debugging, you could add sysfs entries for CI* registers in
> 3.5.28.
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).

> 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...

Thanks
Judith

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

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

[Robert Jarzmik]

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

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

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

[Judith Baumgarten]

Zitat von Robert Jarzmik <robert.jarzmik@free.fr>:

>>> "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.
Ok, it still seems to be some kind of link_missed problem. I didn't  
find the culprit yet but the CICMD being 0 is an indicator I think. At  
the moment DMA and FIFOs are resetted and it works so far. But I could  
also load a new buffer.
The error occurs (mostly) when there are other hardware interrupts, so  
there is still some timing problem.

>> 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.
Due to the fact that this patch is for the system dma controller, that  
the pxa3xx doesn't use, I will have to integrate it to pxa_camera  
driver. Do you have an idea how to access the pcdev->lock out of such  
a function?

> 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 ...
I can only speak for pxa320, but at the moment it never minds. EOF and  
EOFX bits are always set at the same time so DMA can be prepared  
immediately after  the previous buffer was marked as done. But there  
seems to be still a bug in synchronisation of DMA and capturing,  
because the first (round about) 50 pixels are transferred to the last  
buffer, so that the image shifted left.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.