From: Robert Jarzmik <robert.jarzmik@free.fr>
To: Marek Vasut <marek.vasut@gmail.com>
Cc: Jeff Garzik <jeff@garzik.org>,
linux-ide@vger.kernel.org, eric.y.miao@gmail.com,
haojian.zhuang@gmail.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] PXA DMA-capable PATA driver
Date: Mon, 17 May 2010 17:35:43 +0200 [thread overview]
Message-ID: <87hbm68rsg.fsf@free.fr> (raw)
In-Reply-To: <201005160300.02076.marek.vasut@gmail.com> (Marek Vasut's message of "Sun\, 16 May 2010 03\:00\:01 +0200")
Marek Vasut <marek.vasut@gmail.com> writes:
>> Once the transfer is over, you have to call dma_unmap_sg() to give back the
>> memory (ie. ensure cache consistency once the peripheral has finished
>> pushing data to the memory).
>
> This should be taken care of by the libata code, shouldn't it ?
Now I checked, it is in ata_sg_setup().
>> >> are you able to detect bus error?
>> >
>> > Sadly, no. Nor can I detect any other condition.
>>
>> Wouldn't the DCSR_BUSERR bit of DCSR report a bus error ?
>
> I have doubts, check the PXA270 TRM for example for description of that bit.
I have checked, and from my experience with PXA dma, when a DMA transfer is
aborted (peripheral error or wrong descriptor setup), the DMA chain is stopped
(thus your ENDIRQ never happens), and a DMA irq is raised, with DCSR having
DCSR_BUSERR raised.
This was at least verified for the DMA support in pxa_camera, and the previously
DMA api submitted for pxa.
Could you clarify your doubts, please ?
Cheers.
--
Robert
WARNING: multiple messages have this Message-ID (diff)
From: robert.jarzmik@free.fr (Robert Jarzmik)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] PXA DMA-capable PATA driver
Date: Mon, 17 May 2010 17:35:43 +0200 [thread overview]
Message-ID: <87hbm68rsg.fsf@free.fr> (raw)
In-Reply-To: <201005160300.02076.marek.vasut@gmail.com> (Marek Vasut's message of "Sun\, 16 May 2010 03\:00\:01 +0200")
Marek Vasut <marek.vasut@gmail.com> writes:
>> Once the transfer is over, you have to call dma_unmap_sg() to give back the
>> memory (ie. ensure cache consistency once the peripheral has finished
>> pushing data to the memory).
>
> This should be taken care of by the libata code, shouldn't it ?
Now I checked, it is in ata_sg_setup().
>> >> are you able to detect bus error?
>> >
>> > Sadly, no. Nor can I detect any other condition.
>>
>> Wouldn't the DCSR_BUSERR bit of DCSR report a bus error ?
>
> I have doubts, check the PXA270 TRM for example for description of that bit.
I have checked, and from my experience with PXA dma, when a DMA transfer is
aborted (peripheral error or wrong descriptor setup), the DMA chain is stopped
(thus your ENDIRQ never happens), and a DMA irq is raised, with DCSR having
DCSR_BUSERR raised.
This was at least verified for the DMA support in pxa_camera, and the previously
DMA api submitted for pxa.
Could you clarify your doubts, please ?
Cheers.
--
Robert
next prev parent reply other threads:[~2010-05-17 15:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-10 3:02 [PATCH] PXA DMA-capable PATA driver Marek Vasut
2010-05-10 3:02 ` Marek Vasut
2010-05-14 13:51 ` Marek Vasut
2010-05-14 13:51 ` Marek Vasut
2010-05-14 17:42 ` Jeff Garzik
2010-05-14 17:42 ` Jeff Garzik
2010-05-14 22:03 ` Jeff Garzik
2010-05-14 22:03 ` Jeff Garzik
2010-05-14 22:23 ` Marek Vasut
2010-05-14 22:23 ` Marek Vasut
2010-05-15 20:48 ` Robert Jarzmik
2010-05-15 20:48 ` Robert Jarzmik
2010-05-16 1:00 ` Marek Vasut
2010-05-16 1:00 ` Marek Vasut
2010-05-17 15:35 ` Robert Jarzmik [this message]
2010-05-17 15:35 ` Robert Jarzmik
2010-05-17 22:53 ` Marek Vasut
2010-05-17 22:53 ` Marek Vasut
2010-05-20 8:48 ` Tejun Heo
2010-05-20 8:48 ` Tejun Heo
2010-05-20 10:28 ` Marek Vasut
2010-05-20 10:28 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87hbm68rsg.fsf@free.fr \
--to=robert.jarzmik@free.fr \
--cc=eric.y.miao@gmail.com \
--cc=haojian.zhuang@gmail.com \
--cc=jeff@garzik.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ide@vger.kernel.org \
--cc=marek.vasut@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.