Re: [PATCH 2/2] usb: host: xhci-plat: add wakeup entry at /sys

[Peter Chen <peter.chen@nxp.com>]

On 20-07-07 12:11:53, Alan Stern wrote:
> On Tue, Jul 07, 2020 at 02:01:28AM +0000, Peter Chen wrote:
> > On 20-07-06 12:22:37, Alan Stern wrote:
> > > On Mon, Jul 06, 2020 at 04:03:08AM +0000, Peter Chen wrote:
> > > > So, you suggest:
> > > > At hcd-pci.c, ohci-platform.c, ehci-platform.c, and xhci-plat.c:
> > > > change device_wakeup_enable to device_init_wakeup(dev, true).
> > > 
> > > I don't think it's necessary to do that.
> > > 
> > > device_init_wakeup(dev, true) just calls device_set_wakeup_capable() and 
> > > device_wakeup_enable().  The kernel already does the 
> > > device_set_wakeup_capable() part for these devices in the code that 
> > > registers them.  For instance, the PCI core calls 
> > > device_set_wakeup_capable() when a new device is discovered and 
> > > registered, so there's no need for hcd-pci.c to repeat this action.
> > 
> > But, that's not all the use cases. There are still two other use cases:
> > (Taking xhci-plat.c as an example):
> > - It is a platform bus device created by platform bus driver
> > - It is a platform bus device created by glue layer parents
> > (eg, dwc3/cdns3), usually, it is dual-role controller.
> 
> In these cases there would be a choice: xhci-plat.c could call 
> device_init_wakeup, or the platform-bus/glue-layer driver could call 
> device_set_wakeup_capable and xhci-plat.c could continue to call 
> device_enable_wakeup.

You said "the PCI core calls device_set_wakeup_capable() when a new device is
discovered and register", why PCI core does this, is every device on
PCI bus wakeup capable?

The reason I ask this is not every device on platform-bus is wakeup
capable, to let the controller device have defaulted "enabled" value,
we need to use device_init_wakeup at xhci-plat.c

> 
> 
> > > > I think if controller's wakeup setting is only used for ehci or xhci common code, that's ok. If
> > > > it is also used for glue layer's power control and wakeup setting; it may need to set "disabled"
> > > > for default value.
> > > 
> > > What sort of wakeup events can the glue layer generate?  It seems to me 
> > > that if there is no controller driver bound to the controller device 
> > > then the controller shouldn't be able to wake the system up in any case.
> > 
> > It should be the similar with PCI device you mentioned below. The
> > glue layer device is a platform device which is the parent of controller
> > device,
> 
> I don't understand.  Let's consider EHCI as an example.  The controller 
> device is something like 0000:00:1d.7, which is on the PCI bus and is a 
> PCI device.  Its child is usb1, which is a root-hub device on the USB 
> bus.
> 
> But you're saying that the glue layer device would be the parent of the 
> controller device, right?  This means it would be analogous to the 
> parent of 0000:00:1d.7.  In the PCI world, that parent would be a PCI 
> bridge or something similar.  It would have no understanding of 
> ID/VBUS/DP/DM/RX changes, since those are all USB concepts and have 
> nothing to do with PCI.

Sorry, my words were not precise.

From hardware level:
Controller includes core part and non-core part, core part is usually
designed by IP vendor, non-core part is usually designed by each SoC
vendors. Wakeup handling is part of non-core. The USB PHY gets
ID/VBUS/DP/DM/RX change events, the related signal ties to non-core part,
and non-core part knows the wakeup occurs.

From software level:
Taking single role controller as example:
Glue layer is a platform device, and handles non-core part events,
including wakeup events, it is the parent of common layer which handles
core part events (eg, xhci-plat.c)

So, one controller includes two platform devices, one for glue layer,
one for common layer.

> 
> > it could detect ID/VBUS/DP/DM/RX changes and generate wakeup
> > events, these wakeup events will trigger interrupt, this interrupt
> > number could be the same with controller interrupt number or not.
> 
> This really sounds like you are talking about the controller, not the 
> controller's parent.  Or maybe a PHY, which is sort of next to the 
> controller without being its parent or child.
> 
> I like to think of it this way: A controller or device is something that 
> sits at an endpoint of a bus or communication channel, or at the meeting 
> place of two buses or communication channels.  Thus, an EHCI controller 
> sits at the meeting place of a PCI bus and a USB bus.  As a result, it 
> has interfaces to two buses: an upward-facing PCI bus interface and a 
> downward-facing USB bus interface.  The controller and root-hub devices 
> are abstractions used by the kernel to represent these two interfaces.
> That's why the ehci-pci controller driver registers itself with a 
> struct pci_driver and why root hubs are bound to the usb_generic_driver, 
> even though the actual hardware is all part of a single EHCI controller 
> chip.
> 
> So now, in the situations you're talking about, what exactly are the 
> buses, the interfaces, and the controllers/devices?

roothub is the child of the core part, core part is the child of non-core part.

> 
> > When the system is in suspend (D3), when the wakeup events occurs,
> > the system interrupt controller could trigger wakeup request, and
> > wake system up. When the system is in full-power state (D0), this
> > interrupt just wakes up glue layer, and glue layer wakes up common
> > USB stack (EHCI/XHCI).
> 
> When a device or controller relays information from one bus or another, 
> the wakeup setting indicates whether or not it should relay wakeup 
> requests.  ID/VBUS/DP/DM/RX events are all things that take place on the 
> USB bus.  As a result, the corresponding wakeup requests are 
> theoretically generated by the root-hub device -- not by the controller 
> device, since the controller device is attached to the upward-facing bus 
> and not to the USB bus.  The controller's wakeup setting thus indicates 
> whether the controller should forward these wakeup requests from the 
> root hub to the upward-facing bus.  Once a request reaches the 
> upward-facing bus, it could take the form of an ordinary IRQ signal or a 
> system-level wakeup signal.

You are right, ID/VBUS/DP/DM/RX signal changing occurs at the USB bus,
and detected by USB PHY physically.
   
The controller device (core part) or glue layer device
(non-core part)'s wakeup setting is only used to enable/disable platform
related powers (regulators) for USB (PHY) which are used to detect
ID/VBUS/DP/DM/RX signal. If the platform doesn't need USB wakeup capabilities
for system suspend, it could turn off related powers. Besides, it could tell
the system if USB interrupt can be the wakeup interrupt.

> 
> > > > I am curious how PCI USB at PC determine whether it responds USB wakeup events or not?
> > > > At Linux kernel or BIOS? It has two places for enabling USB wakeup, one for USB devices
> > > > (including roothub), another is for PCI device?
> > > 
> > > PCI devices send wakeup requests via a special PCI power management 
> > > signal called PME -- you can see its state in the output from "lspci 
> > > -vv" in the Power Management Capability section.  In legacy systems this 
> > > signal was handled by the BIOS, but nowadays the PCI and ACPI subsystems 
> > > in the Linux kernel handle it.
> > > 
> > > If a PCI host controller is in the D3 low-power state when a wakeup 
> > > event occurs, it uses the PME# signal to request a wakeup.  If it is in 
> > > the D0 full-power state when a wakeup event occurs, it uses its normal 
> > > IRQ signal to tell the system about the event.
> > > 
> > 
> > If the USBCMD.RS is cleared, does the interrupt could still occur when
> > the system is at D0, or this interrupt is not USB interrupt, it is a
> > PCI interrupt?
> 
> I don't remember the details offhand.  I think pretty much the same 
> events are generated regardless of whether USBCMD.RS is set or clear.  
> 
> Anyway, when one of these events occurs, it causes an interrupt flag to 
> be set in the hardware.  If the controller is in D0 then it will raise a 
> PCI IRQ whenever the interrupt flag is set (and not masked).  If the 
> controller is in D3 then it is not allowed to raise a PCI IRQ, so it 
> asserts the PCI PME signal instead.
> 
> I'm not sure what you mean by "USB interrupt".  The USB protocol doesn't 
> have interrupts.  (It has interrupt URBs, but those are completely 
> different things as you know.)  The closest thing USB has to an 
> interrupt is a wakeup request.
> 

The "USB interrupt" I mean here is the interrupt event triggered by core
part of the USB controller, for example the interrupt at usbsts for EHCI.

-- 

Thanks,
Peter Chen