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