11 Aug
2009
11 Aug
'09
12:56 a.m.
On Sat, 08 Aug 2009 13:19:30 +0200
Philipp Hachtmann <hachti at hachti.de> wrote:
[real DMA vs. DMA bounce buffers]
"It
isn't done until it is done proper."
I have seen far to much bad engineering. Especially in the PeeCee area.
I don't wane spend my time with PeeCee crap.
Without bus master support the
bus bridge will be almost useless.
As explained in an other post even an interrupt is a bus master
transaction. Most storage devices use bus master DMA. You can't do
without DMA.
[...]
This is ugly.
All data needs to be touched twice from the CPU.
Na und? *g*
From a performance point of view, this may be a bit (not too much) ugly.
But from the usability point of view, I don't see any great problems.
Usability means to be able to hook the real Unibus to a PC style machine. It would be easy to install a bus mapper between the
Unibus and the PCI
master interface. Just some more work.
Then please do it.
On the other side: The glue logic will be implemented in a FPGA. So it
is software. Software is easy to change. I sugest that you first get
the hardware going. Get some PCI-FPGA card, build an add on card with
UniBus drivers, connect it to a real UniBus that contains only some
memory and try to access this. If you got that far we can continue to
fight about a proper IOMMU / UniBus map. The later is just a matter of
software that is loaded into the FPGA. The real hard part is the
hardware.
Therefore: If
you design a PCI-UniBus bridge _*PLEASE*_ implement a
proper IOMMU / UniBus map. Everything else will be a ugly kludge.
Just copy the VAX UniBus map and you are done. It does exactely what
is needed.
For whom? Who will actually *use* that? The BSD drivers on the PC? If
yes, it would be worth a thought. Otherwise: No way. I'll be glad to
have a stable interface to the Unibus. Bus master access Unibus->PCI is
simply not planned for the first version. I have to define achievable
milestones. And this feature is simply far beyond my needs. I want to
access the Unibus. And I don't have a VAX that should be able to program
my PC. Only 18 bit CPUs and peripheral controllers. Worst case example:
Assume the most stupid access method on PCI: 8 bit single transaction
read access. That costs 4 cycles per byte. Let's add another cycle for
the sake of a bad implementation on the card. Makes 5.
Then we come to a read transfer rate of approx. 6.3 MByte/s on the bus.
This would allow for roughly 25 complete Unibus memory dumps per second.
The
problem here is that the whole system is staled at UniBus PIO
accesses. The CPU is utilized 100% just to move data around. If you use
DMA the UniBus device handles the data transfer at its own. No CPU
intervention is required and the CPU can do other things (like
servicing user tasks). When DMA is ready the CPU gets an interrupt and
that is all.
But it will be
a
nightmare to the OS programmer that has to fight with it writing a
device driver for it.
As you read above, I see no reason to avoid copying data in
the driver.
The driver has to fight something like Perhaps I have a too much simplified view on the
topic. In that case,
I'm grateful for enlightenment!
The problem here is that the driver becomes
dependent on your
particular implementation of the UniBus bridge. E.g. NetBSD is save
from this as it abstracts all bus access through
bus_space(9) anyway.
So the DMA bounce buffers have to be implemented in the
bus_space(9)
backend. But then you still have the problem that the whole system is
staled at UniBus transactions. The CPU needs to do PIO read / writes
and spends lots of wait states. You can't even shedule an other user
process. The whole machine hangs inside the kernel as the CPU is
spinning wait states.
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/