Re: xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/27/2017 2:37 AM, Marc Zyngier wrote:
> 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/
> 

Hi Marc


It already had a firmware downloader, and I tried reset both before and after that. No change.


So, now I've tried the same thing with 0 patches to linux-next. A nitrogen6_max board
with a Renesas USB3.0 PCIe card that has a firmware ROM, and so does not need the extra patch.

01:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)

It behaves identically to the other board. So, the firmware issue is a red herring.

[  OK  ] Found device /dev/ttymxc0.
[  OK  ] Found device /dev/ttymxc1.
[   11.916718] xhci_gen_setup: 1


BR
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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux