Philip Blundell (pb@nexus.co.uk)
Thu, 13 May 1999 09:45:52 +0100
In message <Pine.LNX.4.05.9905130841460.10745-100000@cyberelk.elk.co.uk>, Tim W
augh writes:
>On Wed, 12 May 1999, Philip Blundell wrote:
>
>> Actually, this is quite a good suggestion. The low-level driver can
>> inspect the address of the buffer it's handed, see if it's suitable
>> for DMA as it stands (ie on an ISA machine, make sure it is entirely
>> below the 16MB limit) and either use it directly or copy it to a
>> bounce buffer as necessary. So yes, you will get an extra copy some
>> of the time, but it might be worth it to save on software complexity.
>> The time to copy probably isn't that big a deal.
>
>But how does the high-level driver know to allocate DMA-capable memory?
My thinking was that it wouldn't need to care. If it just allocates memory
any old way, there's a chance you may end up with DMA-able space (in which
case so much the better) and there's a chance you may not, in which case the
low level driver can use the bounce buffer as necessary.
Incidentally, quite a few modern chipsets can do ISA DMA to anywhere in
memory, not just the low 16MB. But I'm not sure how to probe for this
facility so that we could safely use it.
>I think the low-level driver should say so via port->modes. The idea
>behind modes is to advertise what things the hardware can do for us, isn't
>it?
Kind of. Jörg Dorchain had an idea to separate it out into true modes (ie
things that are sensible to pass to the change_mode function) and other
hardware capabilities. That would probably be a good thing to do.
>Currently, the valid bits for modes are things like PARPORT_MODE_PCSPP and
>PARPORT_MODE_PCEPP, and so on. I wonder if we shouldn't change the
>EPP/ECP ones from being PC-specific, so that we have:
Yes, I think this is a good plan.
p.
-- 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 Thu 13 May 1999 - 05:01:40 EDT