[PARPORT] Re: Parport & DMA -- patch-2.2.7-tmw3


Tim Waugh (tim@cyberelk.demon.co.uk)
Tue, 11 May 1999 21:06:05 +0100 (GMT)


Hi Bert,

On Tue, 11 May 1999, Bert De Jonghe wrote:

> is it possible that something has changed in the buffer allocation for the
> parallel port ?

Yeah. What's happened is that the parport functions now all take a
pointer to kernel memory rather than user memory, so that they can be
called from any context (including interrupt handlers).

> Printing with DMA enabled gives me garbage and after a quick glance at
> the code I cannot find allocation of a buffer suitable for DMA any
> more. IIRC in parport_pc had such an allocation when I was working on
> the DMA, but that's already a long time ago. Is it correct that the
> buffer to be printed is now allocated in lp.c ?

Yes, and lp does the copying from user-space. The quick and dirty fix for
the current tmw tree is probably to make lp specify GFP_DMA when it
allocates the buffer.

> If so, should we
> allocate some other buffer with GFP_DMA encapsulated in parport_pc.c
> then, and do an extra copy of the data ? That way the user of the
> parport should not care about this DMA-alignment, and it seems to me
> that's the way it should be.

I think you've hit the nail on the head. The buffer that lp allocates
isn't allocated with GFP_DMA, because it doesn't even know that parport
can DMA from the buffer. But parport happily gives the pointer to the DMA
controller regardless.

For the 'correct' solution, how about this (for the 'ideal' API that I'm
documenting):

All of the block read/write functions have a 'flags' parameter, and the
client specifies 'PARPORT_CAN_DMA' if the memory they've provided is
available for use by DMA. Then the low-level driver may only use DMA if
PARPORT_CAN_DMA is in the flags.

SYNOPSIS

#include <linux/parport.h>

struct parport_operations {
        ...
        size_t (*ecp_write_data) (struct parport *port,
                                  const void *buf, size_t len, int flags);
        ...
};

DESCRIPTION

Writes a block of ECP data. The 'flags' parameter is one or more of
the following, bitwise-or'ed together:

PARPORT_CAN_DMA 'buf' is suitable for DMA transfers. The
                        low-level driver may be able to take advantage
                        of DMA, depending on the available hardware.

What do you think?

Tim.
*/

-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --



This archive was generated by hypermail 2.0b3 on Tue 11 May 1999 - 16:08:23 EDT