Braindead newbie questions, DMA-backed PIO

Braindead newbie questions, DMA-backed PIO

[Matt Sealey]

Hi guys,

I have some probably quite simple questions which I am having a hard
time figuring out.

I am working on improving DMA support for the pata_imx driver. While
supporting normal MWDMA and UDMA modes is fairly easy (the SoC
DMA controller handles it almost transparently), for PIO mode I intend
to enhance it by replacing ata_sff_data_xfer with something that is
backed with a little more involved on DMA (basically using the DMA
unit to transfer data to the 16-bit drive data register).

However, I can't figure out (because there are no solid examples) if I
can act on the buffer data in the same way as I would in a DMA
function
by mapping sg's and doing a standard dmaengine slave transfer then
waiting for it to complete (thus relieving us of having to do
expensive
16-bit CPU I/O to a device register, and hopefully allowing the kernel
or userspace to do something else like play audio or whatever while we
wait for the slave transfer to complete). I assume it should all be
fine, but I just want to be super sure before I start scratching my
head over
something fundamentally impossible.

The other question semi-related is whether I really need to, as in the
current implementation, use the ata_sff_data_xfer_noirq (or a
derivative of
it) variant as this causes some incredible stuttering in the system
and impacts things like audio. What exactly are we protecting against
here,
an occurance of any system IRQ that might steal from the transfer, or
just the occurance of the ATA IRQ? With the drive interrupt enabled
(the manual just states that when it happens the drive is looking for
attention) is this going to cause some insanity with the transfer with
libata
servicing the interrupt behind my back and doing something odd? The
default interrupt handler in libata seems to be fairly safe and checks
if
the controller is busy or not, but since there are a lot of drivers
that use _noirq variant for PIO I am just curious what they are
looking to avoid
happening, perhaps if this is a legacy behavior nobody bothered to
change since libata got more advanced?

I also have another small question, is there any benefit to having
set_piomode, set_dmamode and set_mode all implemented? What's the
precise reason to implement set_mode, I assume just to handle any odd
tweaks like dma mask registers that are not ATA standard before
(or after?) the set_???mode functions are called? The pata_platform.c
driver which pata_imx.c was derived from implements it but does not
implement any other pio/dma mode setting. pata_imx sets up iordy
behavior for higher transfer rates (for some reason, it doesn't
actually have
any support for the timings) in this function. What is the recommended
way to do this these days? My current internal implementation removes
this and uses set_piomode and set_dmamode to implement drive timings
and set iordy, and I just want to check that this is correct.

Thanks for any answers..

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.

Re: Braindead newbie questions, DMA-backed PIO

[Robert Hancock]

On 02/09/2012 01:43 PM, Matt Sealey wrote:
> Hi guys,
>
> I have some probably quite simple questions which I am having a hard
> time figuring out.
>
> I am working on improving DMA support for the pata_imx driver. While
> supporting normal MWDMA and UDMA modes is fairly easy (the SoC
> DMA controller handles it almost transparently), for PIO mode I intend
> to enhance it by replacing ata_sff_data_xfer with something that is
> backed with a little more involved on DMA (basically using the DMA
> unit to transfer data to the 16-bit drive data register).
>
> However, I can't figure out (because there are no solid examples) if I
> can act on the buffer data in the same way as I would in a DMA
> function
> by mapping sg's and doing a standard dmaengine slave transfer then
> waiting for it to complete (thus relieving us of having to do
> expensive
> 16-bit CPU I/O to a device register, and hopefully allowing the kernel
> or userspace to do something else like play audio or whatever while we
> wait for the slave transfer to complete). I assume it should all be
> fine, but I just want to be super sure before I start scratching my
> head over
> something fundamentally impossible.

I don't see any reason why this wouldn't be possible offhand.

>
> The other question semi-related is whether I really need to, as in the
> current implementation, use the ata_sff_data_xfer_noirq (or a
> derivative of
> it) variant as this causes some incredible stuttering in the system
> and impacts things like audio. What exactly are we protecting against
> here,
> an occurance of any system IRQ that might steal from the transfer, or
> just the occurance of the ATA IRQ? With the drive interrupt enabled
> (the manual just states that when it happens the drive is looking for
> attention) is this going to cause some insanity with the transfer with
> libata
> servicing the interrupt behind my back and doing something odd? The
> default interrupt handler in libata seems to be fairly safe and checks
> if
> the controller is busy or not, but since there are a lot of drivers
> that use _noirq variant for PIO I am just curious what they are
> looking to avoid
> happening, perhaps if this is a legacy behavior nobody bothered to
> change since libata got more advanced?

I have a vague recollection of hearing that the main reason for this was 
that some flaky controllers would choke if you allow interrupts to be 
processed in the middle of data transfer (the CMD640 seems to be one 
infamous example where reading the status register during a transfer as 
a result of an interrupt will corrupt the data). The ones using _noirq 
in libata seem to be fairly old and crusty controllers in general.

>
> I also have another small question, is there any benefit to having
> set_piomode, set_dmamode and set_mode all implemented? What's the
> precise reason to implement set_mode, I assume just to handle any odd
> tweaks like dma mask registers that are not ATA standard before
> (or after?) the set_???mode functions are called? The pata_platform.c
> driver which pata_imx.c was derived from implements it but does not
> implement any other pio/dma mode setting. pata_imx sets up iordy
> behavior for higher transfer rates (for some reason, it doesn't
> actually have
> any support for the timings) in this function. What is the recommended
> way to do this these days? My current internal implementation removes
> this and uses set_piomode and set_dmamode to implement drive timings
> and set iordy, and I just want to check that this is correct.
>
> Thanks for any answers..
>

Re: Braindead newbie questions, DMA-backed PIO

[Matt Sealey]

On Fri, Feb 10, 2012 at 10:49 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> On 02/09/2012 01:43 PM, Matt Sealey wrote:
>>
>> Hi guys,
>>
>> The other question semi-related is whether I really need to, as in the
>> current implementation, use the ata_sff_data_xfer_noirq (or a
>> derivative of
>> it) variant as this causes some incredible stuttering in the system
>> and impacts things like audio. What exactly are we protecting against
>> here,
>> an occurance of any system IRQ that might steal from the transfer, or
>> just the occurance of the ATA IRQ? With the drive interrupt enabled
>> (the manual just states that when it happens the drive is looking for
>> attention) is this going to cause some insanity with the transfer with
>> libata
>> servicing the interrupt behind my back and doing something odd? The
>> default interrupt handler in libata seems to be fairly safe and checks
>> if
>> the controller is busy or not, but since there are a lot of drivers
>> that use _noirq variant for PIO I am just curious what they are
>> looking to avoid
>> happening, perhaps if this is a legacy behavior nobody bothered to
>> change since libata got more advanced?
>
>
> I have a vague recollection of hearing that the main reason for this was
> that some flaky controllers would choke if you allow interrupts to be
> processed in the middle of data transfer (the CMD640 seems to be one
> infamous example where reading the status register during a transfer as a
> result of an interrupt will corrupt the data). The ones using _noirq in
> libata seem to be fairly old and crusty controllers in general.

Okay, just a FYI I removed the _noirq variant from the driver in my
local copy and
did a bunch of PIO transfers (actually did some disk imaging, rsyncs, hashing)
while also playing an MP3 and compiling (on an SD card just to generate an
interrupt elsewhere) and re-read the docs; apparently reading a PIO
register will
pause a DMA transfer on the disk (yay) and in general I can't find any
bugs or errata
about this nor can I make any ATA activity other than the FIFO
handling cause any
disk weirdness - in about 4 hours of various disk activity, and
without so much as a
peep on audio besides the music (as opposed to fairly regular
stop-starts and pops),
everything came out fine and there was a somewhat noticable performance increase
(around 600kb/s in PIO4 according to iozone).

So, that's that then. Thanks for the advise.. I have a bunch of stuff
to push now on
pata_imx but want to get the DMA code sorted out before I make a series.

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.