Re: [Qemu-devel] [RFC] Attaching EHCI to sysbus.
Hi, Does it make sense to have an EHCI bus type that inherits from USBBus? That way we could change USBPortOps into methods of the USBBus that the subclass overrides. I don't think this is useful. USBPortOps should be identical for both cases. That would strongly decouple the EHCI code from the PCI device. Then the ehci-pci device just needs to setup the EHCI bus and forward MMIO requests appropriately. I think what we need to do is: (1) Create EHCIPCIState, which holds just PCIDevice and EHCIState. (2) Setup dma context in pci init function, then switch over all memory access from pci_* to dma_* (simliar to ohci). Generic ehci code should not have any pci references any more then. Now: (3) create EHCISysbusState, hook up sysbus init function which does mmio registration, dma context setup and irq windup the sysbus way. cheers, Gerd
[Qemu-devel] [RFC] Attaching EHCI to sysbus.
Hi All,
I have a platform (Xilinx Zynq) that has a USB EHCI controller that
attaches directly to the system bus and not through PCI. We are
looking for a way to disentangle EHCI from PCI - currently it inherits
from TYPE_PCI_DEVICE:
static TypeInfo ehci_info = {
.name = usb-ehci,
.parent= TYPE_PCI_DEVICE,
.instance_size = sizeof(EHCIState),
.class_init= ehci_class_init,
};
How would we go about edit EHCI to inherit from TYPE_SYSBUS_DEVICE as well?
Regards,
Peter
Re: [Qemu-devel] [RFC] Attaching EHCI to sysbus.
Hi Peter,
Am 25.06.2012 11:34, schrieb Peter Crosthwaite:
I have a platform (Xilinx Zynq) that has a USB EHCI controller that
attaches directly to the system bus and not through PCI. We are
looking for a way to disentangle EHCI from PCI - currently it inherits
from TYPE_PCI_DEVICE:
static TypeInfo ehci_info = {
.name = usb-ehci,
.parent= TYPE_PCI_DEVICE,
.instance_size = sizeof(EHCIState),
.class_init= ehci_class_init,
};
How would we go about edit EHCI to inherit from TYPE_SYSBUS_DEVICE as well?
As mentioned recently, I need that for the Tegra platform as well,
please keep me in the loop.
Basically it means adding a second TypeInfo with its own class_init.
We'd need to have PCIEHCIState with PCIDevice as parent and a
SysBusEHCIState with SysBusDevice as parent, sharing a common EHCIState.
The m48t59 comes to mind as example with both ISADevice and
SysBusDevice. Maintaining VMState compatibility is likely going to be
tricky.
Following David's DMA refactoring this also means that the PCI DMA
helpers used in EHCI need to be replaced by the generic ones now
suggested by Ben, as done for OHCI.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [RFC] Attaching EHCI to sysbus.
On 06/25/2012 05:02 AM, Andreas Färber wrote:
Hi Peter,
Am 25.06.2012 11:34, schrieb Peter Crosthwaite:
I have a platform (Xilinx Zynq) that has a USB EHCI controller that
attaches directly to the system bus and not through PCI. We are
looking for a way to disentangle EHCI from PCI - currently it inherits
from TYPE_PCI_DEVICE:
static TypeInfo ehci_info = {
.name = usb-ehci,
.parent= TYPE_PCI_DEVICE,
.instance_size = sizeof(EHCIState),
.class_init= ehci_class_init,
};
How would we go about edit EHCI to inherit from TYPE_SYSBUS_DEVICE as well?
Gerd,
Does it make sense to have an EHCI bus type that inherits from USBBus?
That way we could change USBPortOps into methods of the USBBus that the subclass
overrides.
That would strongly decouple the EHCI code from the PCI device. Then the
ehci-pci device just needs to setup the EHCI bus and forward MMIO requests
appropriately.
Regards,
Anthony Liguori
As mentioned recently, I need that for the Tegra platform as well,
please keep me in the loop.
Basically it means adding a second TypeInfo with its own class_init.
We'd need to have PCIEHCIState with PCIDevice as parent and a
SysBusEHCIState with SysBusDevice as parent, sharing a common EHCIState.
The m48t59 comes to mind as example with both ISADevice and
SysBusDevice. Maintaining VMState compatibility is likely going to be
tricky.
Following David's DMA refactoring this also means that the PCI DMA
helpers used in EHCI need to be replaced by the generic ones now
suggested by Ben, as done for OHCI.
Regards,
Andreas
Re: [Qemu-devel] [RFC] Attaching EHCI to sysbus.
On Tue, Jun 26, 2012 at 12:25 AM, Anthony Liguori anth...@codemonkey.ws wrote:
On 06/25/2012 05:02 AM, Andreas Färber wrote:
Hi Peter,
Am 25.06.2012 11:34, schrieb Peter Crosthwaite:
I have a platform (Xilinx Zynq) that has a USB EHCI controller that
attaches directly to the system bus and not through PCI. We are
looking for a way to disentangle EHCI from PCI - currently it inherits
from TYPE_PCI_DEVICE:
static TypeInfo ehci_info = {
.name = usb-ehci,
.parent = TYPE_PCI_DEVICE,
.instance_size = sizeof(EHCIState),
.class_init = ehci_class_init,
};
How would we go about edit EHCI to inherit from TYPE_SYSBUS_DEVICE as
well?
Gerd,
Does it make sense to have an EHCI bus type that inherits from USBBus?
Hi Anthony,
Is this a more general problem than USB though? I was thinking of yet
a different approach. With devices like m48t59 already having
ISA+SYSBUS, and now EHCI along with Vincents Palatins SDHCI (out of
tree) having both PCI+SYSBUS, there are multiple precedents for
wanting to cast PCI/ISA to SYSBUS. Is this problem solvable is the
generic sense using some sort of QOM arrangement? Can TYPE_PCI_DEVICE
be setup such that is a inherited type from TYPE_SYSBUS_DEVICE, such
that all PCI devices are SYSBUS devices? Then its just a trivial cast
on the machine model level.
Regards,
Peter
That way we could change USBPortOps into methods of the USBBus that the
subclass overrides.
That would strongly decouple the EHCI code from the PCI device. Then the
ehci-pci device just needs to setup the EHCI bus and forward MMIO requests
appropriately.
Regards,
Anthony Liguori
As mentioned recently, I need that for the Tegra platform as well,
please keep me in the loop.
Basically it means adding a second TypeInfo with its own class_init.
We'd need to have PCIEHCIState with PCIDevice as parent and a
SysBusEHCIState with SysBusDevice as parent, sharing a common EHCIState.
The m48t59 comes to mind as example with both ISADevice and
SysBusDevice. Maintaining VMState compatibility is likely going to be
tricky.
Following David's DMA refactoring this also means that the PCI DMA
helpers used in EHCI need to be replaced by the generic ones now
suggested by Ben, as done for OHCI.
Regards,
Andreas
Re: [Qemu-devel] [RFC] Attaching EHCI to sysbus.
On 06/25/2012 08:28 PM, Peter Crosthwaite wrote:
On Tue, Jun 26, 2012 at 12:25 AM, Anthony Liguorianth...@codemonkey.ws wrote:
On 06/25/2012 05:02 AM, Andreas Färber wrote:
Hi Peter,
Am 25.06.2012 11:34, schrieb Peter Crosthwaite:
I have a platform (Xilinx Zynq) that has a USB EHCI controller that
attaches directly to the system bus and not through PCI. We are
looking for a way to disentangle EHCI from PCI - currently it inherits
from TYPE_PCI_DEVICE:
static TypeInfo ehci_info = {
.name = usb-ehci,
.parent= TYPE_PCI_DEVICE,
.instance_size = sizeof(EHCIState),
.class_init= ehci_class_init,
};
How would we go about edit EHCI to inherit from TYPE_SYSBUS_DEVICE as
well?
Gerd,
Does it make sense to have an EHCI bus type that inherits from USBBus?
Hi Anthony,
Is this a more general problem than USB though?
Yup.
I was thinking of yet
a different approach. With devices like m48t59 already having
ISA+SYSBUS, and now EHCI along with Vincents Palatins SDHCI (out of
tree) having both PCI+SYSBUS, there are multiple precedents for
wanting to cast PCI/ISA to SYSBUS.
That's a bad idea I think.
Is this problem solvable is the
generic sense using some sort of QOM arrangement?
Yeah. Unfortunately, sysbus means different things in different contexts.
QOM doesn't require devices to be on any particular bus. Sometimes you just
have a device with a well known interface (like a UART) and you want the ability
to expose it over a set of well known transports. A UART's a great example and
here's my latest refactoring of it:
https://github.com/aliguori/qemu/blob/qom-pin.4/hw/serial.c
https://github.com/aliguori/qemu/blob/qom-pin.4/hw/isa-serial.c
You can see isa-serial is trivialized and you can also instantiate serial
directly without having to make it a sysbus device.
But in the case of EHCI, it's really a bus type. Since QOM models busses as
proper objects, we can use inheritance to extend busses which we weren't able to
do before.
That let's us modify the way the ehci controller is implemented to largely be
implemented as part of the BusState such that the binding to either PCI or
sysbus (no real need to use sysbus btw) can be absolutely trivial.
Can TYPE_PCI_DEVICE
be setup such that is a inherited type from TYPE_SYSBUS_DEVICE, such
that all PCI devices are SYSBUS devices? Then its just a trivial cast
on the machine model level.
This won't work in general but also because there are various places in qdev
that assume that only one type of device can sit on a bus. It's also a pretty
ugly thing.
Most things that are sysbus devices today really don't need to be any more.
It's better to just think about sysbus not existing :-)
Regards,
Anthony Liguori
Regards,
Peter
That way we could change USBPortOps into methods of the USBBus that the
subclass overrides.
That would strongly decouple the EHCI code from the PCI device. Then the
ehci-pci device just needs to setup the EHCI bus and forward MMIO requests
appropriately.
Regards,
Anthony Liguori
As mentioned recently, I need that for the Tegra platform as well,
please keep me in the loop.
Basically it means adding a second TypeInfo with its own class_init.
We'd need to have PCIEHCIState with PCIDevice as parent and a
SysBusEHCIState with SysBusDevice as parent, sharing a common EHCIState.
The m48t59 comes to mind as example with both ISADevice and
SysBusDevice. Maintaining VMState compatibility is likely going to be
tricky.
Following David's DMA refactoring this also means that the PCI DMA
helpers used in EHCI need to be replaced by the generic ones now
suggested by Ben, as done for OHCI.
Regards,
Andreas
