[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Attaching EHCI to sysbus.

From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] Attaching EHCI to sysbus.
Date: Mon, 25 Jun 2012 20:46:44 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 06/25/2012 08:28 PM, Peter Crosthwaite wrote:
On Tue, Jun 26, 2012 at 12:25 AM, Anthony Liguori<address@hidden>  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

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


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.

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:


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.

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 :-)


Anthony Liguori


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


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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]