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

[Anthony Liguori]

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