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
>
>
>> - 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.
Troy
--
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
