RE: [PATCH] usb: host: xhci-rcar: Avoid long wait in xhci_reset()

[Felipe Balbi <felipe.balbi@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]


Hi,

Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> writes:
>> > > And, kernel log is the following:
>> > >
>> > > [    1.565605] xhci-hcd ee000000.usb: xHCI Host Controller
>> > > [    1.570636] xhci-hcd ee000000.usb: new USB bus registered, assigned bus number 5
>> > > [   22.270160] xhci-hcd ee000000.usb: can't setup: -110
>> > > [   22.274931] xhci-hcd ee000000.usb: USB bus 5 deregistered
>> > > [   22.280158] xhci-hcd: probe of ee000000.usb failed with error -110
>> > >
>> > > The timestamp is strange to me. But, logs of R-Car H3 (ES1.0) and
>> > > R-Car H2 were the same.
>> >
>> > yeah, seems like your system timer is counting twice for each tick.
>> 
>> Yes, I will investigate this later.
>> 
>> > > Should I revise the commit log in detail?
>> >
>> > Sure, but let's first why this is the case. It's unclear, to me at
>> > least, why reset fails.
>> 
>> I understood it. I will investigate why reset fails first.
>
> According to the HW team of R-Car SoCs, the firmware of R-Car USB 3.0 host controller
> will control the reset. So, if the xhci-rcar driver doesn't do firmware downloading,
> the reset of USB3.0 host controller doesn't work correctly.
> The HW team intends to describe this specification on next datasheet revision.
> (In other words, the current datasheet doesn't mention exactly about this.)

that explains it, thanks :-)

> So, I will revise the commit log and submit such a patch later.

great, thanks

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]