On Tue, 2012-06-12 at 09:58 +0200, Edgar E. Iglesias wrote:
> On Tue, Jun 12, 2012 at 10:33:51AM +1000, Peter Crosthwaite wrote:
> > >
> > > Hi,
> > >
> > > IIRC the word array thing is device specific, not really AXI stream.
> > > I think the whole connection to AXI is a bit unfortunate,
> >
> >
Am 12.06.2012 15:32, schrieb Peter Maydell:
> [...] I'm not sure if anybody's thought about
> how we expose memory regions in a QOM manner.)
Anthony had that in his i440fx RFC.
/-F
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörff
On 06/12/2012 04:32 PM, Peter Maydell wrote:
> On 12 June 2012 14:18, Avi Kivity wrote:
>> On 06/12/2012 03:58 PM, Peter Maydell wrote:
>>> On 11 June 2012 18:31, Avi Kivity wrote:
On 06/11/2012 06:01 PM, Anthony Liguori wrote:
> Perhaps we should just make MemoryRegion work in both dire
On 12 June 2012 14:18, Avi Kivity wrote:
> On 06/12/2012 03:58 PM, Peter Maydell wrote:
>> On 11 June 2012 18:31, Avi Kivity wrote:
>>> On 06/11/2012 06:01 PM, Anthony Liguori wrote:
Perhaps we should just make MemoryRegion work in both directions?
>>
>>> The other direction is currently cpu
On 06/12/2012 03:58 PM, Peter Maydell wrote:
> On 11 June 2012 18:31, Avi Kivity wrote:
>> On 06/11/2012 06:01 PM, Anthony Liguori wrote:
>>> Perhaps we should just make MemoryRegion work in both directions?
>
>> The other direction is currently cpu_physical_memory_rw(). We do need
>> to support
On 11 June 2012 18:31, Avi Kivity wrote:
> On 06/11/2012 06:01 PM, Anthony Liguori wrote:
>> Perhaps we should just make MemoryRegion work in both directions?
> The other direction is currently cpu_physical_memory_rw(). We do need
> to support issuing transactions from arbitrary points in the me
On 06/11/2012 09:36 PM, Anthony Liguori wrote:
>>
>> cpu_physical_memory_rw() would be implemented as
>> memory_region_rw(system_memory, ...) while pci_dma_rw() would be
>> implemented as memory_region_rw(pcibm, ...). This would allow different
>> address transformations for the two accesses.
>
>
On Tue, Jun 12, 2012 at 12:31:58PM +0300, Avi Kivity wrote:
> On 06/11/2012 09:35 PM, Anthony Liguori wrote:
> >>
> >> The other direction is currently cpu_physical_memory_rw().
> >
> > Right, and with benh's proposal, it's dma_memory_rw(). It also adds a
> > DMAContext parameter.
> >
> > I can'
On 06/11/2012 09:35 PM, Anthony Liguori wrote:
>>
>> The other direction is currently cpu_physical_memory_rw().
>
> Right, and with benh's proposal, it's dma_memory_rw(). It also adds a
> DMAContext parameter.
>
> I can't help think that the contents of DMAContext is awfully similar to
> MemoryR
On Tue, Jun 12, 2012 at 10:33:51AM +1000, Peter Crosthwaite wrote:
> >
> > Hi,
> >
> > IIRC the word array thing is device specific, not really AXI stream.
> > I think the whole connection to AXI is a bit unfortunate,
>
> Yes, so I think we can summaries the confusion here with AXI stream is
> com
>
> Hi,
>
> IIRC the word array thing is device specific, not really AXI stream.
> I think the whole connection to AXI is a bit unfortunate,
Yes, so I think we can summaries the confusion here with AXI stream is
completely unreleated to AXI. The connection between the two comes
with the way low le
On 06/11/2012 12:31 PM, Avi Kivity wrote:
On 06/11/2012 06:01 PM, Anthony Liguori wrote:
On 06/11/2012 08:39 AM, Peter Maydell wrote:
On 11 June 2012 14:15, Anthony Liguori wrote:
From what you said earlier, it's basically:
'write data to this address'
'read data from this address'
An i
On 06/11/2012 12:31 PM, Avi Kivity wrote:
On 06/11/2012 06:01 PM, Anthony Liguori wrote:
On 06/11/2012 08:39 AM, Peter Maydell wrote:
On 11 June 2012 14:15, Anthony Liguori wrote:
From what you said earlier, it's basically:
'write data to this address'
'read data from this address'
An i
On 06/11/2012 06:01 PM, Anthony Liguori wrote:
> On 06/11/2012 08:39 AM, Peter Maydell wrote:
>> On 11 June 2012 14:15, Anthony Liguori wrote:
>>> From what you said earlier, it's basically:
>>>
>>> 'write data to this address'
>>> 'read data from this address'
>>>
>>> An interface that implement
On Mon, Jun 11, 2012 at 10:03:56AM -0500, Anthony Liguori wrote:
> On 06/11/2012 09:53 AM, Peter Maydell wrote:
> >On 11 June 2012 15:38, Edgar E. Iglesias wrote:
> >>On Mon, Jun 11, 2012 at 02:39:56PM +0100, Peter Maydell wrote:
> >>>Ideally the interface used by DMA controllers should be identic
On 11 June 2012 16:03, Anthony Liguori wrote:
> On 06/11/2012 09:53 AM, Peter Maydell wrote:
>> In hardware (at least for AXI) they're the same thing. A DMA
>> controller is a bus master, just like a CPU. They don't care
>> whether the slave is RAM or a device, they're just issuing
>> memory trans
On 06/11/2012 09:53 AM, Peter Maydell wrote:
On 11 June 2012 15:38, Edgar E. Iglesias wrote:
On Mon, Jun 11, 2012 at 02:39:56PM +0100, Peter Maydell wrote:
Ideally the interface used by DMA controllers should be identical to
the interface used by CPUs to talk to the rest of the system: it's
ex
On 06/11/2012 08:39 AM, Peter Maydell wrote:
On 11 June 2012 14:15, Anthony Liguori wrote:
From what you said earlier, it's basically:
'write data to this address'
'read data from this address'
An interface that implements this is DMAContext. Forget about the fact that
'DMA' is in the name.
On Mon, Jun 11, 2012 at 03:53:23PM +0100, Peter Maydell wrote:
> On 11 June 2012 15:38, Edgar E. Iglesias wrote:
> > On Mon, Jun 11, 2012 at 02:39:56PM +0100, Peter Maydell wrote:
> >> Ideally the interface used by DMA controllers should be identical to
> >> the interface used by CPUs to talk to t
On 11 June 2012 15:38, Edgar E. Iglesias wrote:
> On Mon, Jun 11, 2012 at 02:39:56PM +0100, Peter Maydell wrote:
>> Ideally the interface used by DMA controllers should be identical to
>> the interface used by CPUs to talk to the rest of the system: it's
>> exactly the same bus interface in hardwa
On Mon, Jun 11, 2012 at 02:39:56PM +0100, Peter Maydell wrote:
> On 11 June 2012 14:15, Anthony Liguori wrote:
> > From what you said earlier, it's basically:
> >
> > 'write data to this address'
> > 'read data from this address'
> >
> > An interface that implements this is DMAContext. Forget abo
Il 11/06/2012 15:17, Anthony Liguori ha scritto:
>>
>> I think AXI counts as a point-to-point link, so no bus.
>>
>> In my prop-ptr branch you can find some code (untested beyond
>> compilation)
>> that tried to model AXI using interfaces
>> (git://github.com/pbonzini/qemu.git).
>
> s/pbonzin
On 11 June 2012 14:15, Anthony Liguori wrote:
> From what you said earlier, it's basically:
>
> 'write data to this address'
> 'read data from this address'
>
> An interface that implements this is DMAContext. Forget about the fact that
> 'DMA' is in the name. It's really the symmetric version o
On 06/11/2012 12:54 AM, Paolo Bonzini wrote:
Ive had a brief look at the refactorings on qom-next, I notice that
busses are now just children of the parent object TYPE_BUS.
Essentially for point-to-point links this means that link itself
has a QOM object. So for finer clarification, for new busse
On 06/08/2012 08:24 PM, Peter Crosthwaite wrote:
On Sat, Jun 9, 2012 at 12:15 AM, Anthony Liguori wrote:
On 06/08/2012 12:23 PM, Peter Crosthwaite wrote:
Hi all,
Im looking to QOMifying and refactoring the AXI stream interfaces
between the AXI ethernet and AXI DMA modules. I could use some
g
On 11 June 2012 06:54, Paolo Bonzini wrote:
> I think AXI counts as a point-to-point link, so no bus.
Depends what you mean by AXI. In general an AXI bus fabric
can have multiple masters and slaves connected via an
interconnect, but we probably don't actually want to model
the interconnect as a s
> > Ive had a brief look at the refactorings on qom-next, I notice that
> > busses are now just children of the parent object TYPE_BUS.
> > Essentially for point-to-point links this means that link itself
> > has a QOM object. So for finer clarification, for new busses should or
> > should I not ha
On Sat, Jun 9, 2012 at 12:12 PM, Andreas Färber wrote:
> Am 09.06.2012 03:53, schrieb Peter Crosthwaite:
>> On Fri, Jun 8, 2012 at 7:45 PM, Andreas Färber wrote:
>>> Am 08.06.2012 06:23, schrieb Peter Crosthwaite:
Each of the two core has three interfaces (+interrupt pins):
1: Sysb
Am 09.06.2012 03:53, schrieb Peter Crosthwaite:
> On Fri, Jun 8, 2012 at 7:45 PM, Andreas Färber wrote:
>> Am 08.06.2012 06:23, schrieb Peter Crosthwaite:
>>> Each of the two core has three interfaces (+interrupt pins):
>>>
>>> 1: Sysbus attachment for device control
>>> 2: AXI stream TX link
>>>
On Fri, Jun 8, 2012 at 7:45 PM, Andreas Färber wrote:
> Am 08.06.2012 06:23, schrieb Peter Crosthwaite:
>> Each of the two core has three interfaces (+interrupt pins):
>>
>> 1: Sysbus attachment for device control
>> 2: AXI stream TX link
>> 3: AXI stream RX link
> [...]
>> struct XilinxDMAConnect
On Sat, Jun 9, 2012 at 12:15 AM, Anthony Liguori wrote:
> On 06/08/2012 12:23 PM, Peter Crosthwaite wrote:
>>
>> Hi all,
>>
>> Im looking to QOMifying and refactoring the AXI stream interfaces
>> between the AXI ethernet and AXI DMA modules. I could use some
>> guidance on how to do this as I can
On 06/08/2012 09:59 PM, Paul Brook wrote:
Of course we then hit the usual problem with QOM that we can only link
to objects, and it's impossible to expose multiple interfaces of the
same type.
I'm pretty sure Anthony claimed this was entirely possible --
presumably that's how Pins are going to
On 06/08/2012 12:23 PM, Peter Crosthwaite wrote:
Hi all,
Im looking to QOMifying and refactoring the AXI stream interfaces
between the AXI ethernet and AXI DMA modules. I could use some
guidance on how to do this as I can think of about 6 different
solutions. Sources are hw/xilinx_axienet.c and
> >>> Of course we then hit the usual problem with QOM that we can only link
> >>> to objects, and it's impossible to expose multiple interfaces of the
> >>> same type.
> >>
> >> I'm pretty sure Anthony claimed this was entirely possible --
> >> presumably that's how Pins are going to work.
> >
>
On 8 June 2012 14:41, Anthony Liguori wrote:
> On 06/08/2012 05:13 PM, Paul Brook wrote:
>> Of course we then hit the usual problem with QOM that we can only link to
>> objects, and it's impossible to expose multiple interfaces of the same
>> type.
> No, QOM supports multiple inheritance of inter
> >> So what im proposing is AXI stream is implemented as a unidirectional
> >> point to point bus. The xilinx ethernet system would consist of two of
> >> these buses one for tx, one for rx.
> >
> > I thought the idea was that with QOM the bus/device model would go away.
> > The DMA controller im
On 06/08/2012 05:13 PM, Paul Brook wrote:
Im looking to QOMifying and refactoring the AXI stream interfaces
between the AXI ethernet and AXI DMA modules. I could use some
guidance on how to do this as I can think of about 6 different
solutions. Sources are hw/xilinx_axienet.c and hw/xilinx_axidma
On 06/08/2012 09:13 PM, Paul Brook wrote:
On 8 June 2012 10:13, Paul Brook wrote:
Of course we then hit the usual problem with QOM that we can only link to
objects, and it's impossible to expose multiple interfaces of the same
type.
I'm pretty sure Anthony claimed this was entirely possible -
> On 8 June 2012 10:13, Paul Brook wrote:
> > Of course we then hit the usual problem with QOM that we can only link to
> > objects, and it's impossible to expose multiple interfaces of the same
> > type.
>
> I'm pretty sure Anthony claimed this was entirely possible --
> presumably that's how Pi
Am 08.06.2012 06:23, schrieb Peter Crosthwaite:
> Each of the two core has three interfaces (+interrupt pins):
>
> 1: Sysbus attachment for device control
> 2: AXI stream TX link
> 3: AXI stream RX link
[...]
> struct XilinxDMAConnection {
> void *dma;
> void *client;
>
> DMAPushFn to
On 8 June 2012 10:13, Paul Brook wrote:
> Of course we then hit the usual problem with QOM that we can only link to
> objects, and it's impossible to expose multiple interfaces of the same type.
I'm pretty sure Anthony claimed this was entirely possible --
presumably that's how Pins are going to
> Im looking to QOMifying and refactoring the AXI stream interfaces
> between the AXI ethernet and AXI DMA modules. I could use some
> guidance on how to do this as I can think of about 6 different
> solutions. Sources are hw/xilinx_axienet.c and hw/xilinx_axidma.c.
>
>...
>
> So what im proposing
Hi all,
Im looking to QOMifying and refactoring the AXI stream interfaces
between the AXI ethernet and AXI DMA modules. I could use some
guidance on how to do this as I can think of about 6 different
solutions. Sources are hw/xilinx_axienet.c and hw/xilinx_axidma.c.
First ill start off by describ
43 matches
Mail list logo
