Re: [RFC v3] Intel xhci: Support EHCI/xHCI port switching.

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

 



On Thu, May 26, 2011 at 10:45:10PM -0700, Sarah Sharp wrote:
> The Intel Panther Point chipsets contain an EHCI and xHCI host controller
> that shares some number of skew-dependent ports.  These ports can be
> switched from the EHCI to the xHCI host (and vice versa) by a hardware MUX
> that is controlled by registers in the xHCI PCI configuration space.  The
> USB 3.0 SuperSpeed terminations on the xHCI ports can be controlled
> separately from the USB 2.0 data wires.
> 
> This switchover mechanism is there to support users who do a custom
> install of certain non-Linux operating systems that don't have official
> USB 3.0 support.  By default, the ports are under EHCI, SuperSpeed
> terminations are off, and USB 3.0 devices will show up under the EHCI
> controller at reduced speeds.  (This was more palatable for the marketing
> folks than having completely dead USB 3.0 ports if no xHCI drivers are
> available.)  Users should be able to turn on xHCI by default through a
> BIOS option, but users are happiest when they don't have to change random
> BIOS settings.
> 
> This patch introduces a driver method to switchover the ports from EHCI to
> xHCI before the EHCI driver finishes PCI enumeration.  We want to switch
> the ports over before the USB core has the chance to enumerate devices
> under EHCI, or boot from USB mass storage will fail if the boot device
> connects under EHCI first, and then gets disconnected when the port
> switches over to xHCI.
> 
> Add code to the xHCI PCI quirk to switch the ports from EHCI to xHCI.  The
> PCI quirks code will run before any other PCI probe function is called, so
> this avoids the issue with boot devices.
> 
> Another issue is with BIOS behavior during system resume from hibernate.
> If the BIOS doesn't support xHCI, it may switch the devices under EHCI to
> allow use of the USB keyboard, mice, and mass storage devices.  It's
> supposed to remember the value of the port routing registers and switch
> them back when the OS attempts to take control of the xHCI host controller,
> but we all know not to trust BIOS writers.
> 
> Make both the xHCI driver and the EHCI driver attempt to switchover the
> ports in their PCI resume functions.  We can't guarantee which PCI device
> will be resumed first, so this avoids any race conditions.  Writing a '1'
> to an already set port switchover bit or a '0' to a cleared port switchover
> bit should have no effect.
> 
> The xHCI PCI configuration registers will be documented in the EDS-level
> chipset spec, which is not public yet.  I have permission from legal and
> the Intel chipset group to release this patch early to allow good Linux
> support at product launch.  I've tried to document the registers as much
> as possible, so please let me know if anything is unclear.

Thanks for taking the kernel boot parameter out, much nicer.

Just one tiny nit:

> +	if (!ports_available)
> +		dev_warn(&xhci_pdev->dev,
> +				"WARNING: BIOS reports no USB 3.0 ports? "
> +				"Email linux-usb@xxxxxxxxxxxxxxx\n");
> +

Do you really want to get emails about this?
We've been burned in the past, but I know we still have messages for
this for the usb-storage stuff, and it's useful there.

What would a user be able to do, or you be able to do, if someone does
email you based on this, and the other warning message like this?  How
are we going to be able to resolve it, by fixing the kernel code, or
their BIOS?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux