Tim Waugh (tim@cyberelk.demon.co.uk)
Thu, 13 May 1999 08:51:32 +0100 (GMT)
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?
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?
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:
PARPORT_MODE_PCSPP IBM PC-style port registers, i.e.
parport_read_status isn't faked
PARPORT_MODE_EPP Can do epp_write_data etc. with hardware
assistance
PARPORT_MODE_ECP Can do ecp_write_data etc. with hardware
assistance
PARPORT_MODE_COMPAT compat_write_block may be hardware-assisted
PARPORT_MODE_DMA The hardware can DMA, and we'll probably use it:
allocate your buffers with GFP_DMA
Of course, these are all advisory. On the PC for instance, if we're not
allowed to use interrupts we can't sensibly use an ECP-capable chip.
Comments?
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 Thu 13 May 1999 - 03:55:39 EDT