On Mon, Jan 16, 2017 at 2:32 AM, Rafał Miłecki <zaj...@gmail.com> wrote: > On 21 November 2016 at 16:31, Mathias Nyman > <mathias.ny...@linux.intel.com> wrote: >> On 21.11.2016 09:57, Rafał Miłecki wrote: >>> >>> Hi Mathias, >>> >>> On 17 October 2016 at 22:30, Rafał Miłecki <zaj...@gmail.com> wrote: >>>> >>>> From: Rafał Miłecki <ra...@milecki.pl> >>>> >>>> Broadcom's Northstar XHCI controllers seem to need a special start >>>> procedure to work correctly. There isn't any official documentation of >>>> this, the problem is that controller doesn't detect any connected >>>> devices with default setup. Moreover connecting USB device to controller >>>> that doesn't run properly can cause SoC's watchdog issues. >>>> >>>> A workaround that was successfully tested on multiple devices is to >>>> perform a fake doorbell. This patch adds code for doing this and enables >>>> it on BCM4708 family. >>>> >>>> Signed-off-by: Rafał Miłecki <ra...@milecki.pl> >>>> --- >>>> V2: Enable quirk for brcm,bcm4708 machines instead of adding separated >>>> binding >>>> for it. Thanks Rob for your comment on this. >>> >>> >>> Do you think you can pick & push this one? V2 follows Rob's suggestion >>> and he has some DT knowledge for sure, so I guess it should be OK. >>> -- >> >> >> Is there some more background information on this? >> >> I don't have any contacts to Broadcom myself, adding the BMC Kernel Feedback >> list to CC. >> Maybe someone over there has an errata, documentation or just general >> feedback. >> >> How was this workaround even figured out? ringing the doorbell for the first >> device doesn't seem like something found by trial and error, especially >> when >> xhci specs state that: >> >> "Software shall not write the Doorbell of an endpoint until after it has >> issued a >> Configure Endpoint Command for the endpoint and received a successful >> Command >> Completion Event." >> >> The whole workaround is a bit intrusive, allocating a fake device, ring a >> doorbell for a >> fake device in the wrong state, clearing off HSE (host system error) which >> should only be set >> when things really go bad, some random usleeps, and possible calling >> xhci_start() twice. >> >> I can't take this as is without some more info. > > Hi (ping) Broadcom guys, could you help us with this USB workaround, please?
Investigating internally. I'll let you know if I can find anything. Thanks, Jon > > -- > Rafał