linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: linux-usb@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Mathias Nyman <mathias.nyman@intel.com>,
	linux-pci@vger.kernel.org
Subject: Re: `quirk_usb_handoff_xhci` takes 60 ms with ASM1042
Date: Wed, 5 May 2021 14:31:56 +0200	[thread overview]
Message-ID: <YJKQPJU/KhRx8vuy@kroah.com> (raw)
In-Reply-To: <3a5d53db-040a-6806-1d6d-d85ef4ecba54@molgen.mpg.de>

On Wed, May 05, 2021 at 02:15:26PM +0200, Paul Menzel wrote:
> Dear Greg,
> 
> 
> Am 05.05.21 um 10:33 schrieb Greg Kroah-Hartman:
> > On Wed, May 05, 2021 at 10:27:52AM +0200, Paul Menzel wrote:
> 
> > > Am 05.05.21 um 10:11 schrieb Greg Kroah-Hartman:
> > > > On Wed, May 05, 2021 at 09:57:44AM +0200, Paul Menzel wrote:
> > > 
> > > > > On an Asus F2A85-M PRO, BIOS 6601 11/25/2014, with an ASM1042 SuperSpeed USB
> > > > > Host Controller [1b21:1042], and the xHCI drivers built as modules
> > > > > 
> > > > >       CONFIG_USB_XHCI_PCI=m
> > > > >       CONFIG_USB_XHCI_HCD=m
> > > > > 
> > > > > `quirk_usb_handoff_xhci` takes 60 ms, which is 15 % of the time to reaching
> > > > > `run_init_process()`. I addded some prints, showing the f
> > > > > 
> > > > >       [    0.308841] pci 0000:03:00.0: PCI->APIC IRQ transform: INT A -> IRQ 17
> > > > >       [    0.369858] pci 0000:03:00.0: handshake done with timeout = 0
> > > > >       [    0.369862] pci 0000:03:00.0: hc_init reached
> > > > >       [    0.369865] pci 0000:03:00.0: second handshake done
> > > > >       [    0.369869] pci 0000:03:00.0: third handshake done
> > > > >       [    0.369909] pci 0000:03:00.0: quirk_usb_early_handoff+0x0/0x670 took 59661 usecs
> > > > >       […]
> > > > >       [    0.415223] Run /lib/systemd/systemd as init process
> > > > > 
> > > > > Is there a way to optimize this, or move it out “the hot path”?
> > > > 
> > > > That's the hardware taking so long, all that function does is make some
> > > > PCI calls to the device.
> > > 
> > > In your experience, do most devices take that long?
> > 
> > No idea, it all depends on the device.  And is 60ms really that long to
> > initialize the USB controller?
> 
> For the goal of “instant” startup, I’d say yes.
> 
> I also guess, this is all the ASMedia ASM1042 firmware taking so long,
> right?

Probably, yes.  And you proved that below....

> > That's a complex beast.
> 
> I miss the PS/2 controller, which seemed to be simpler for *input* devices
> like keyboard and mouse. (No idea regarding power usage even.)

The PS/2 controller was horrible, even for keyboard and mice.  Many
motherboards and devices were blown up by hot-plugging them.

There's a reason we all came up with USB back in the day, please don't
make us go back to that mess...

> > > > If the driver is built as a module, there should not be any "hot
> > > > path" here as the module is loaded async when the device is
> > > > discovered, right?
> > >      obj-$(CONFIG_USB_PCI)   += pci-quirks.o
> > > 
> > > So all quirks are run independently of the USB “variant” (UHCI, OHCI, EHCI,
> > > xHCI).
> > > 
> > > Indeed, this driver is built into the Linux kernel.
> > > 
> > >      $ grep USB_PCI .config
> > >      CONFIG_USB_PCI=y
> > > 
> > > So, should `pci-quirks.c` be split up to have more fine grained control?
> > 
> > What control do you need here?
> 
> Good question, as I do not know the USB spec. I’d say, disabling certain
> quirks, or just run them, when the actual driver is loaded.

This is not a "quirk", it is part of how USB works.

> > And yeah, I see, but this code has to be run at early-startup to match
> > the USB spec requirements for handing off the USB control from the
> > BIOS/firmware/whatever, to the kernel.
> 
> That makes the second option above a moot point.
> 
> > Try changing your BIOS settings to not have "legacy" USB support in it,
> > that could cause this transition to go faster, at the expense of not
> > being able to use a USB device before Linux boots.
> 
> The firmware of the Asus F2A85-M PRO allows to disable *legacy* USB support
> for only the ASMedia ASM1042. And, thank you for the suggestion, it helped.
> `quirk_usb_early_handoff()` does not show up in the logs now, meaning it’s
> below 50 ms. And it is well below: less than one millisecond.
> 
>     [    0.308343] pci 0000:00:15.1: PCI->APIC IRQ transform: INT A -> IRQ
> 16
>     [    0.308359] pci 0000:03:00.0: PCI->APIC IRQ transform: INT A -> IRQ
> 17
>     [    0.308376] pci 0000:03:00.0: hc_init reached
>     [    0.308380] pci 0000:03:00.0: second handshake done
>     [    0.308384] pci 0000:03:00.0: third handshake done
>     [    0.308395] PCI: CLS 64 bytes, default 64
>     […]
>     [    0.401722] Run /lib/systemd/systemd as init process

Nice!

Go blame your bios vendor now :)

But realize just what is happening here, the hand-off of the USB
hardware from one "owner" to another is not a trivial operation.

Gotta love solutions that don't touch the kernel, thanks for following
up and letting us know.

greg k-h

  reply	other threads:[~2021-05-05 12:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-05  7:57 `quirk_usb_handoff_xhci` takes 60 ms with ASM1042 Paul Menzel
2021-05-05  8:11 ` Greg Kroah-Hartman
2021-05-05  8:27   ` Paul Menzel
2021-05-05  8:33     ` Greg Kroah-Hartman
2021-05-05 12:15       ` Paul Menzel
2021-05-05 12:31         ` Greg Kroah-Hartman [this message]
2021-05-05 15:47           ` Bjorn Helgaas
2021-05-05 15:53             ` Greg Kroah-Hartman
2021-05-06 15:23               ` Bjorn Helgaas
2021-05-06 15:59                 ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YJKQPJU/KhRx8vuy@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=pmenzel@molgen.mpg.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).