All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.