On 8/30/07, Paul Brook <[EMAIL PROTECTED]> wrote: > > If this is the case, it means we don't need anything complicated. Devices > > map themselves straight into the system address space at the appropriate > > slot address (no plug-n-play to worry about), and device "DMA" goes via the > > IOMMU. > > Further searching by google suggests I may be wrong. > > The alternative is that the controller maps the 32-bit VA onto a device > select+28-bit address, using some as-yet undiscovered mechanism. > There are then a couple of different options for how the CPU/memory bus is > accessed: > a) The IOMMU is one or more slave devices, than feed the 28-bit address > possibly plus a few other bits from the device ID into the translation table. > This effectively allows you to map a proportion of the SBus 32-bit master VA > space onto CPU address space via the IOMMU, and map the remainder onto > devices on the same bus. For a system with <=8 slots per bus a fixed mapping > using the first 2G as 256Mb for each slot and the top 2G for IOMMU is > entirely feasible. > b) The 32-bit SBus VA is looked up directly into the IOMMU. Each IOMMU entry > can refer to either a CPU address, or a device+28-bit address on the local
>From DMA2.txt, NCR89C100.txt, NCR89C105.txt and turbosparc.pdf I gather the following: - CPU and IOMMU always perform slave accesses - Slave accesses use the 28-bit address bus to select the device - Slave accesses are not translated by IOMMU - NCR master devices (Lance, ESP) use an internal DREQ-style signal to indicate their need for DMA to their DMA controller - Master accesses use the 32-bit SBus data signals for both address and data - DMA controller is the master for NCR89C100+NCR89C105 combination - Master accesses are translated and controlled by IOMMU - Slave devices may or may not support master access cycles (not supported in the NCR case) - IOMMU can give direct bus access for "intelligent masters" (no devices known) We could model this using two buses: A slave bus between the CPU and the devices, and a master bus between devices and IOMMU. The slave bus translates the 36-bit CPU/memory bus addresses to 28-bit SBus bus addresses. The master bus uses IOMMU to translate 32-bit DVMA addresses to 36-bit CPU/memory bus addresses. Slave devices are connected to the slave bus and DREQs. Master devices and DMA controllers take the DREQs and both buses. Devices register the address ranges they serve on each bus. On Sun4c (without IOMMU) there would be just one bus for both purposes (with the MMU quirk). For the Sparc64 PCI bus which has an IOMMU, a similar dual bus arrangement would be needed. On PC/PPC systems the two buses would be again one. Maybe even the IO port access and MMIO could be unified (one generic bus for both)? That could simplify the device registration. Alternatively, the generic bus could support several access modes, so there would be no need for many virtual buses. Comments?
