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

Robert Jarzmik robert.jarzmik at free.fr
Fri Aug 28 14:53:26 EDT 2009


Guennadi Liakhovetski <g.liakhovetski at 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



More information about the linux-arm-kernel mailing list