Bert De Jonghe (bert@sophis.be)
Wed, 12 May 1999 11:18:10 +0200 (CEST)
On Tue, 11 May 1999, Tim Waugh wrote:
> On Tue, 11 May 1999, Philip Blundell wrote:
>
> > I think I'd prefer it backwards - the low-level driver provides a flag
> > that says its buffers need to be DMA-able (or even just a set of GFP
> > flags that you can OR into the argument to kmalloc). A high level
> > driver has no sensible way to decide on its own whether to allocate
> > buffers that are suitable for DMA or not.
>
> Okay. By what mechanism? Changing attach(), perhaps?
>
> void (*attach) (struct parport *port, int gfp)
If we take this track I think we need both : the user (e.g. lp) of the
parport needs to be informed that the parport can use DMA and therefor the
buffer needs to be correctly allocated. If this allocation fails and we
want to fallback on non-DMA transfer, we again need a way to tell the
low-level driver about it (e.g. with the PARPORT_CAN_DMA flag in
xxx_write_data).
On the other hand I think this DMA-problem is purely a PC architecture
problem and, in my opinion, thus only parport_pc should deal with it. I
also don't like the idea of all higher-level drivers having to ask the
low-level driver if DMA is possible, decide how to allocate their buffer
on that info and report back if this went OK or not.
Maybe parport_pc can have a private DMA-capable buffer (private_data ?)
allocated if DMA is configured ? The cost would be an extra copy of the
data into this buffer, but for me that's a price I'm willing to pay to
avoid making the high-level drivers more complex and putting PC artifacts
all over the place.
Or, just thinking aloud, maybe a special function in the low-level driver
could take care of the allocation, and the higher-level drivers use that
function instead of allocating a buffer themselves ? Hmmm... we'd probably
need to pass some (e.g. PARPORT_CAN_DMA) flag along as well, to allow for
different buffers when maybe GFP_DMA failed ? No more extra copy and the
"intelligence" for allocating a suitable buffer is again up to the
architecture-dependant part, only there and nicely encapsulated. Or am I
thinking too much in objects here ? ;-)
Bert.
.+. ------------------------------------.
+: :+. ,+ Ing. Bert DE JONGHE :
`+: :+' | System Engineer :
| `+' | ,+ : Disclaimer:
+. | ,+' Sophis Systems nv :
| `+' Vlamingstraat 19 : Any errors in fact, tact
+. | B-8560 Wevelgem : or spelling are due to
`+ _______ Tel: +32 (0) 56/43.26.26 _; transmission faults.
-- 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 Wed 12 May 1999 - 05:19:44 EDT