qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 1/1] hw/arm/sbsa-ref: use XHCI to replace EHCI


From: Leif Lindholm
Subject: Re: [PATCH 1/1] hw/arm/sbsa-ref: use XHCI to replace EHCI
Date: Thu, 1 Jun 2023 18:59:56 +0100

+Ard

On Thu, Jun 01, 2023 at 16:01:43 +0100, Peter Maydell wrote:
> > >> Also has EHCI never worked, or has it worked in some modes and so this
> > >> change should be versioned?
> > >
> > > AIUI, EHCI has never worked and can never have worked, because
> > > this board's RAM is all above 4G and the QEMU EHCI controller
> > > implementation only allows DMA descriptors with 32-bit addresses.
> > >
> > > Looking back at the archives, it seems we discussed XHCI vs
> > > EHCI when the sbsa-ref board went in, and the conclusion was
> > > that XHCI would be better. But there wasn't a sysbus XHCI device
> > > at that point, so we ended up committing the sbsa-ref board
> > > with EHCI and a plan to switch to XHCI when the sysbus-xhci
> > > device was done, which we then forgot about:
> > > https://mail.gnu.org/archive/html/qemu-arm/2018-11/msg00638.html
> >
> > Ah, thanks! That explains why we did the thing that made no sense :)
> >
> > To skip the migration hazard, my prefernece is we just leave the EHCI
> > device in for now, and add a separate XHCI on PCIe. We can drop the
> > EHCI device at some point in the future.
> 
> Why PCIe for the XHCI and not sysbus? At the time the board
> was originally added the argument was in favour of using
> a sysbus USB controller (you can see Ard making that point
> in the linked archive thread).

The original argument was that having the device on the sysbus
1) enabled codepaths we wanted to exercise and
2) more closely resembled the development systems available at the
time.

1 still applies, but I'm not sure 2 does. Ard?

/
    Leif



reply via email to

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