qemu-devel
[Top][All Lists]
Advanced

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

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


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [RFC] Attaching EHCI to sysbus.
Date: Tue, 26 Jun 2012 11:28:32 +1000

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



reply via email to

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