I made a first implementation of this concept. CPU->bus uses
"southbound" functions, device->CPU "northbound" ones.
The system is not symmetric, the device address range allocation could
well be separate.
What do you think?
Index: qemu/cpu-all.h
===
> > IIUC devices never register addresses on the master bus. The only thing
> > that responds on that bus is the IOMMU.
>
> Generally yes, but these "intelligent masters" and their targets would
> register on on both buses. The only case I can only think of is a
> video grabber, it's frame memory c
On 9/8/07, Paul Brook <[EMAIL PROTECTED]> wrote:
> > 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
>
> I thought device selection was s
> 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
I thought device selection was separate from the 28-bit SBus slave address
space. ie. each
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.
>
>
> 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 al
> This is a bit mysterious for me too. SBus address space is 28 bits
> (256MB). Usually each slot maps to a different area. So the CPU sees
> one slot for example at 0x3000 and other at 0x4000 .
>
> IOMMU can map max 2G of memory, usually a 32 or 64MB region. For the
> devices, this device
On 8/28/07, Paul Brook <[EMAIL PROTECTED]> wrote:
> > On second thought, there is a huge difference between a write access
> > originating from CPU destined for the device and the device writing to
> > main memory. The CPU address could be 0xf000 1000, which may translate
> > to a bus address of 0x
> On second thought, there is a huge difference between a write access
> originating from CPU destined for the device and the device writing to
> main memory. The CPU address could be 0xf000 1000, which may translate
> to a bus address of 0x1000, as an example. The device could write to
> main memo
On 8/26/07, Blue Swirl <[EMAIL PROTECTED]> wrote:
> On 8/26/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
> > Paul Brook wrote:
> > pci_gdma.diff: Convert PCI devices and targets
> >
> > Any comments? The patches are a bit intrusive and I can't test the
> > targets except that
On 8/26/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
> Paul Brook wrote:
> pci_gdma.diff: Convert PCI devices and targets
>
> Any comments? The patches are a bit intrusive and I can't test the
> targets except that they compile.
> >>> Shouldn't the PCI DMA object be a property
Paul Brook wrote:
pci_gdma.diff: Convert PCI devices and targets
Any comments? The patches are a bit intrusive and I can't test the
targets except that they compile.
Shouldn't the PCI DMA object be a property of the PCI bus?
ie. we don't want/need to pass it round as a separate parameter. It ca
> >> pci_gdma.diff: Convert PCI devices and targets
> >>
> >> Any comments? The patches are a bit intrusive and I can't test the
> >> targets except that they compile.
> >
> > Shouldn't the PCI DMA object be a property of the PCI bus?
> > ie. we don't want/need to pass it round as a separate parame
Paul Brook wrote:
On Friday 24 August 2007, Blue Swirl wrote:
I have now converted the ISA DMA devices (SB16, FDC), most PCI devices
and targets.
gdma.diff: Generic DMA
pc_ppc_dma_to_gdma.diff: Convert x86 and PPC to GDMA
pc_sb16_to_gdma.diff: Convert SB16 to GDMA
pc_fdc_to_gdma.diff: FDC
pc_dm
On Friday 24 August 2007, Blue Swirl wrote:
> I have now converted the ISA DMA devices (SB16, FDC), most PCI devices
> and targets.
>
> gdma.diff: Generic DMA
> pc_ppc_dma_to_gdma.diff: Convert x86 and PPC to GDMA
> pc_sb16_to_gdma.diff: Convert SB16 to GDMA
> pc_fdc_to_gdma.diff: FDC
> pc_dma_clea
In 8/16/07, malc <[EMAIL PROTECTED]> wrote:
> Very long time ago i changed the ISA DMA API to address some of the
> critique that Fabrice expressed, i can't remember offhand if that
> included removal of explicit position passing or not (the patch is on
> some off-line HDD so it's not easy to check
On Thu, 16 Aug 2007, Blue Swirl wrote:
On 8/14/07, Blue Swirl <[EMAIL PROTECTED]> wrote:
Would the framework need any changes to support other targets? Comments welcome.
Replying to myself: Yes, changes may be needed. Some of the DMA
controllers move the data outside CPU loop, but that does n
On 8/14/07, Blue Swirl <[EMAIL PROTECTED]> wrote:
> Would the framework need any changes to support other targets? Comments
> welcome.
Replying to myself: Yes, changes may be needed. Some of the DMA
controllers move the data outside CPU loop, but that does not make
much difference.
Background: I
18 matches
Mail list logo
