On Tue, 26 Dec 2017 21:57:58 +0000,
Troy Kisky wrote:
>
> On 12/26/2017 1:52 PM, Troy Kisky wrote:
> > On 12/25/2017 2:10 AM, Marc Zyngier wrote:
> >> On Sun, 24 Dec 2017 23:01:33 +0000,
> >> Troy Kisky wrote:
> >>>
> >>> commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7
> >>> Author: Marc Zyngier <marc.zyngier@xxxxxxx>
> >>> Date: Tue Aug 1 20:11:08 2017 -0500
> >>>
> >>> xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue
> >>> ...
> >>> ...
> >>> ...
> >>> --- a/drivers/usb/host/xhci-pci.c
> >>> +++ b/drivers/usb/host/xhci-pci.c
> >>> @@ -284,6 +284,13 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
> >>>
> >>> driver = (struct hc_driver *)id->driver_data;
> >>>
> >>> + /* For some HW implementation, a XHCI reset is just not enough... */
> >>> + if (usb_xhci_needs_pci_reset(dev)) {
> >>> + dev_info(&dev->dev, "Resetting\n");
> >>> + if (pci_reset_function_locked(dev))
> >>> + dev_warn(&dev->dev, "Reset failed");
> >>> + }
> >>> +
> >>> ________
> >>>
> >>>
> >>> This pci_reset_function_locked call, causes my i.mx6qp processor to
> >>> hang. It no longer responds to the MAGIC_SYSRQ key (break on serial
> >>> port).
> >>>
> >>>
> >>> If I comment it out, things return to normal when testing on
> >>> Linux-next (20171222).
> >>>
> >>> If you need more info, let me know.
> >>
> >> Well, for a start:
> >>
> >> - Does it fail with 4.13 or 4.14 too?
> >
> > v4.13-rc4 - good
> > v4.13-rc5 - fail
> > v4.13 - fail
> > v4.14 - fail
> >
> >
> >
> >> - Can you work out where it is locking up exactly (going slightly
> >> deeper than the pci_reset_function_locked() call)?
> >
> > With this patch
> > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > index 05104bd2b611..8782945a9f70 100644
> > --- a/drivers/usb/host/xhci.c
> > +++ b/drivers/usb/host/xhci.c
> > @@ -4808,8 +4808,10 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
> >
> > mutex_init(&xhci->mutex);
> > xhci->cap_regs = hcd->regs;
> > + pr_err("%s: 1\n", __func__);
> > xhci->op_regs = hcd->regs +
> > HC_LENGTH(readl(&xhci->cap_regs->hc_capbase));
> > + pr_err("%s: 2\n", __func__);
> > xhci->run_regs = hcd->regs +
> > (readl(&xhci->cap_regs->run_regs_off) & RTSOFF_MASK);
> > /* Cache read-only capability registers */
> > _____________________
> >
> > The last thing printed is
> > [ OK ] Reached target System Initialization.
> > [ OK ] Listening on D-Bus System Message Bus Socket.
> > [ OK ] Reached target Sockets.
> > [ OK ] Started Daily Cleanup of Temporary Directories.
> > [ 15.770319] xhci_gen_setup: 1
OK, so it looks like the CPU is blocked reading from the
device. Almost feels like the device is not clocked (that's about the
only reason why the CPU would be stuck on such a read).
> >
> >
> >> - Do you get the symptom at boot time?
> >
> > Boot
> >
> >> On resume? Is the USB driver
> >> compiled as a module or built-in?
> >
> > INSTALL drivers/usb/host/xhci-hcd.ko
> > INSTALL drivers/usb/host/xhci-pci.ko
> > INSTALL drivers/usb/host/xhci-renesas.ko
> >
> >> - What is your exact platform (something a bit more precise than just
> >> i.MX6...)?
> >
> > It is a custom board not in mainline. It does need to load firmware.
> >
> > I tried moving pci_reset_function_locked before renesas_check_if_fw_dl_is_needed
> > but that did not help.
> >
>
>
>
> Which I should say I also have this patch
>
>
> commit 01ac5cfd811088b5fe8c97f28f96086e30393c66
> Author: Christian Lamparter <chunkeey@xxxxxxxxx>
> Date: Wed Jun 8 00:14:57 2016 +0200
>
> usb: xhci: handle uPD720201 and uPD720202 w/o ROM
>
> This patch adds a firmware check for the uPD720201K8-711-BAC-A
> and uPD720202K8-711-BAA-A variant. Both of these chips are listed
> in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as
> devices which need a firmware in order to work as they do not have
> support to load the firmware from an external ROM.
>
> __________
>
> Sorry for not saying earlier.
That's a very interesting piece of information. Looking at that
patch[1], it doesn't provide any FW loader, and simply detects whether
the firmware is correctly present and running.
What is probably happening is that your bootloader loads the XHCI
firmware, the driver resets the XHCI device, and the firmware is
lost. Assuming my hunch is right, what would be required here is for
the firmware to be loaded after the reset, but that'd require writing
a firmware loader for xhci-pci (probably not a huge undertaking)
Could you please investigate whether my hunch is correct or not?
Thanks,
M.
[1]: https://patchwork.kernel.org/patch/9162693/
--
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
