> On Mon, Jun 20, 2011 at 6:23 PM, Paul Brook wrote:
> >> > Yeah, that's why I said, "hard to do well". It makes it very hard to
> >> > add new socket types.
> >>
> >> PCI, USB, IDE, SCSI, SBus, what else? APICBus? I2C? 8 socket types
> >> ought to be enough for anybody.
> >
> > Off the top of
On 06/21/2011 12:32 AM, Blue Swirl wrote:
On Mon, Jun 20, 2011 at 6:23 PM, Paul Brook wrote:
>> > Yeah, that's why I said, "hard to do well". It makes it very hard to add
>> > new socket types.
>>
>> PCI, USB, IDE, SCSI, SBus, what else? APICBus? I2C? 8 socket types
>> ought to be enough
On Mon, Jun 20, 2011 at 6:23 PM, Paul Brook wrote:
>> > Yeah, that's why I said, "hard to do well". It makes it very hard to add
>> > new socket types.
>>
>> PCI, USB, IDE, SCSI, SBus, what else? APICBus? I2C? 8 socket types
>> ought to be enough for anybody.
>
> Off the top of my head: AClink (a
> > Yeah, that's why I said, "hard to do well". It makes it very hard to add
> > new socket types.
>
> PCI, USB, IDE, SCSI, SBus, what else? APICBus? I2C? 8 socket types
> ought to be enough for anybody.
Off the top of my head: AClink (audio), i2s (audio), SSI/SSP (synchonous
serial), Firewire,
On Wed, Jun 15, 2011 at 11:00 PM, Anthony Liguori wrote:
> On 06/15/2011 01:56 PM, Blue Swirl wrote:
>>
>> On Tue, Jun 14, 2011 at 4:21 PM, Anthony Liguori
>> wrote:
>>>
>>> Which suggests that we really need to move away from declarative device
>>> definitions. It makes it hard to have variable
On 06/15/2011 01:56 PM, Blue Swirl wrote:
On Tue, Jun 14, 2011 at 4:21 PM, Anthony Liguori wrote:
Which suggests that we really need to move away from declarative device
definitions. It makes it hard to have variable numbers of properties.
I'd suppose the number of slots could be fixed. The
On Tue, Jun 14, 2011 at 4:21 PM, Anthony Liguori wrote:
> On 06/13/2011 03:59 PM, Blue Swirl wrote:
>>
>> On Sun, Jun 12, 2011 at 10:21 PM, Anthony Liguori
>> wrote:
>>>
>>> On 06/12/2011 12:12 PM, Avi Kivity wrote:
On 06/10/2011 06:43 PM, Anthony Liguori wrote:
>
>> What exactl
On 06/13/2011 03:59 PM, Blue Swirl wrote:
On Sun, Jun 12, 2011 at 10:21 PM, Anthony Liguori wrote:
On 06/12/2011 12:12 PM, Avi Kivity wrote:
On 06/10/2011 06:43 PM, Anthony Liguori wrote:
What exactly is so very wrong about buses that they need to die?
They force a device tree. The devic
On Sun, Jun 12, 2011 at 10:21 PM, Anthony Liguori wrote:
> On 06/12/2011 12:12 PM, Avi Kivity wrote:
>>
>> On 06/10/2011 06:43 PM, Anthony Liguori wrote:
>>>
What exactly is so very wrong about buses that they need to die?
>>>
>>> They force a device tree. The device model shouldn't be a tree
On 06/13/2011 03:05 AM, Avi Kivity wrote:
On 06/12/2011 10:21 PM, Anthony Liguori wrote:
It's perfectly fine to have a type called PCIBus that I440FX extends,
but qdev shouldn't have explicit knowledge of something called a "bus"
IMHO. Doing this forces a limited mechanism of connecting device
On Fri, Jun 10, 2011 at 04:59:08PM +0200, Markus Armbruster wrote:
> Anthony Liguori writes:
>
> > On 06/10/2011 03:13 AM, Markus Armbruster wrote:
> >> Jan Kiszka writes:
> >>> Resource management, e.g. IRQs. That will be useful for other types of
> >>> buses as well.
> >>
> >> A device should
On 06/12/2011 10:21 PM, Anthony Liguori wrote:
It's perfectly fine to have a type called PCIBus that I440FX extends,
but qdev shouldn't have explicit knowledge of something called a "bus"
IMHO. Doing this forces a limited mechanism of connecting devices
because it creates an artificial tree (by
On 06/12/2011 12:12 PM, Avi Kivity wrote:
On 06/10/2011 06:43 PM, Anthony Liguori wrote:
What exactly is so very wrong about buses that they need to die?
They force a device tree. The device model shouldn't be a tree, but a
directed graph.
Right. As an example, you configure PCI interrupt
On 06/10/2011 06:43 PM, Anthony Liguori wrote:
What exactly is so very wrong about buses that they need to die?
They force a device tree. The device model shouldn't be a tree, but a
directed graph.
Right. As an example, you configure PCI interrupt routing and the
memory controller by w
Am 10.06.2011 um 14:51 schrieb Anthony Liguori:
The trouble is that I don't think we have a reasonable way to refer
to properties of other devices and we don't have names for all
devices. I think if we fix the later problem, the former problem
becomes easier.
For the former issue I sent
On 06/10/2011 09:59 AM, Markus Armbruster wrote:
Anthony Liguori writes:
On 06/10/2011 03:13 AM, Markus Armbruster wrote:
Jan Kiszka writes:
Resource management, e.g. IRQs. That will be useful for other types of
buses as well.
A device should be able to say "I need to be connected to an
Anthony Liguori writes:
> On 06/10/2011 03:13 AM, Markus Armbruster wrote:
>> Jan Kiszka writes:
>>> Resource management, e.g. IRQs. That will be useful for other types of
>>> buses as well.
>>
>> A device should be able to say "I need to be connected to an IRQ line".
>> Feels generic to me.
>
>
On 06/10/2011 09:22 AM, Markus Armbruster wrote:
Peter Maydell writes:
But I think that's a non-typical case compared to the usual one
of "these wires are just hardwired this way by the machine".
IIRC, the PCI bus also provides a number of IRQ lines for the device to
tickle (INTA#..INTD#).
On 06/10/2011 09:18 AM, Jan Kiszka wrote:
On 2011-06-10 16:12, Anthony Liguori wrote:
On 06/10/2011 08:43 AM, Jan Kiszka wrote:
-device piix3,id=piix3 -device
isa-serial,id=serial,irq[3]=piix3.irq[3],irq[4]=piix3.irq[4],...
But I don't think we benefit from modelling it this correctly. The
On 06/10/2011 08:50 AM, Peter Maydell wrote:
On 10 June 2011 14:43, Jan Kiszka wrote:
On 2011-06-10 15:10, Peter Maydell wrote:
This makes the wiring of this signal look like a property of the
isa-serial device, which is a bit odd, since it's just as much
a property of the piix3. Actually it's
Peter Maydell writes:
> On 10 June 2011 14:43, Jan Kiszka wrote:
>> On 2011-06-10 15:10, Peter Maydell wrote:
>>> This makes the wiring of this signal look like a property of the
>>> isa-serial device, which is a bit odd, since it's just as much
>>> a property of the piix3. Actually it's neither
On 2011-06-10 16:12, Anthony Liguori wrote:
> On 06/10/2011 08:43 AM, Jan Kiszka wrote:
>> On 2011-06-10 15:10, Peter Maydell wrote:
>>> On 10 June 2011 13:51, Anthony Liguori wrote:
On 06/10/2011 03:13 AM, Markus Armbruster wrote:
>
> Jan Kiszka writes:
>>
>> Resource manag
On 06/10/2011 08:43 AM, Jan Kiszka wrote:
On 2011-06-10 15:10, Peter Maydell wrote:
On 10 June 2011 13:51, Anthony Liguori wrote:
On 06/10/2011 03:13 AM, Markus Armbruster wrote:
Jan Kiszka writes:
Resource management, e.g. IRQs. That will be useful for other types of
buses as well.
A
On 06/10/2011 08:10 AM, Peter Maydell wrote:
On 10 June 2011 13:51, Anthony Liguori wrote:
On 06/10/2011 03:13 AM, Markus Armbruster wrote:
Jan Kiszkawrites:
Resource management, e.g. IRQs. That will be useful for other types of
buses as well.
A device should be able to say "I need to
On 2011-06-10 15:10, Peter Maydell wrote:
> On 10 June 2011 13:51, Anthony Liguori wrote:
>> On 06/10/2011 03:13 AM, Markus Armbruster wrote:
>>>
>>> Jan Kiszka writes:
Resource management, e.g. IRQs. That will be useful for other types of
buses as well.
>>>
>>> A device should be
On 10 June 2011 14:43, Jan Kiszka wrote:
> On 2011-06-10 15:10, Peter Maydell wrote:
>> This makes the wiring of this signal look like a property of the
>> isa-serial device, which is a bit odd, since it's just as much
>> a property of the piix3. Actually it's neither, it's a property
>> of the ma
On 10 June 2011 13:51, Anthony Liguori wrote:
> On 06/10/2011 03:13 AM, Markus Armbruster wrote:
>>
>> Jan Kiszka writes:
>>>
>>> Resource management, e.g. IRQs. That will be useful for other types of
>>> buses as well.
>>
>> A device should be able to say "I need to be connected to an IRQ line".
On 06/10/2011 03:13 AM, Markus Armbruster wrote:
Jan Kiszka writes:
Resource management, e.g. IRQs. That will be useful for other types of
buses as well.
A device should be able to say "I need to be connected to an IRQ line".
Feels generic to me.
More specifically, a device has input IRQs.
Jan Kiszka writes:
> On 2011-06-09 18:40, Markus Armbruster wrote:
>> Jan Kiszka writes:
>>
>>> On 2011-06-08 13:33, Peter Maydell wrote:
At the moment you can't really implement one sysbus device by saying
that it's composed of a set of other sysbus devices. This patch adds
new
On 2011-06-09 18:40, Markus Armbruster wrote:
> Jan Kiszka writes:
>
>> On 2011-06-08 13:33, Peter Maydell wrote:
>>> At the moment you can't really implement one sysbus device by saying
>>> that it's composed of a set of other sysbus devices. This patch adds
>>> new functions sysbus_pass_mmio()
Jan Kiszka writes:
> On 2011-06-08 13:33, Peter Maydell wrote:
>> At the moment you can't really implement one sysbus device by saying
>> that it's composed of a set of other sysbus devices. This patch adds
>> new functions sysbus_pass_mmio() and sysbus_pass_one_irq() which
>> allow a sysbus devi
On 2011-06-08 13:33, Peter Maydell wrote:
> At the moment you can't really implement one sysbus device by saying
> that it's composed of a set of other sysbus devices. This patch adds
> new functions sysbus_pass_mmio() and sysbus_pass_one_irq() which
> allow a sysbus device to delegate an MMIO or I
At the moment you can't really implement one sysbus device by saying
that it's composed of a set of other sysbus devices. This patch adds
new functions sysbus_pass_mmio() and sysbus_pass_one_irq() which
allow a sysbus device to delegate an MMIO or IRQ to another sysbus
device (The approach is inspi
33 matches
Mail list logo
