Hi Hans, On 24/02/16 14:42, Hans de Goede wrote: > Hi, > > On 24-02-16 15:30, Andre Przywara wrote: >> Hi Hans, >> >> On 24/02/16 14:07, Hans de Goede wrote: >>> Hi, >>> >>> On 24-02-16 14:59, Andre Przywara wrote: >>>> Hi, >>>> >>>> (dropping some lists and people) >>>> >>>> On 24/02/16 11:15, Hans de Goede wrote: >>>>> From: Reinder de Haan <patchesrdh@xxxxxxxxx> >>>>> >>>>> At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple >>>>> reset lines, the controller will not initialize while the reset for >>>>> its companion is still asserted, which means we need to de-assert >>>>> 2 resets for the controller to work. >>>> >>>> Interesting, is that documented somewhere or has this been found out by >>>> try-and-error? >>> >>> Found out by try-and-error. >> >> I was afraid so ;-) >> >>>> I was experimenting with USB on the Pine64 yesterday and stumbled upon >>>> the failing OHCI reset (because it now needs bits 16 _and_ 17 to be set >>>> for the OHCI PHY to reset), but couldn't get the EHCI controller to >>>> work >>>> properly also. >>> >>> Then it likely is something different, the problem on the H3 causes >>> the ohci / ehci driver to not load at all, since the registers read >>> all 00 (or was it FF ?), which causes the reset-control and wait for >>> ack code in the generic bits of the drivers to fail (IIRC). >> >> Too bad, I was hoping that this would fix it for me ;-) >> >>>> How would this behaviour manifest? I don't see failure messages with my >>>> new DT (the driver seems to happily initialize), but it doesn't show >>>> anything other than the root hub even when plugging in devices. >>> >>> This may be a phy init problem (specifically missing something >>> similar to >>> sun4i_usb_phy_passby() in drivers/phy/phy-sun4i-usb.c for the A64), >> >> Ah, that sounds more likely. I was wondering what "pmu" meant in this >> regard. >> Where was this "pmu1" address in the DT gathered from? I just subtracted >> the 4K offset that make the difference between the A64 and A33 (which >> seems to be the closest in terms of USB), but the memory map does not >> show where this magic register should be. There seems to be "nothing" at >> 0x01c18000 for the A33 (according to the manual), but the A64 has the >> OTG control registers in the respective region. >> >> A33: OTG HCI: 0x01c19000, EHCI0 HCI: 0x01c1a000, pmu1: 0x01c1a800 >> A64: OTG HCI: 0x01c1a000, EHCI0 HCI: 0x01c1b000, pmu??? >> >> Do you have any clue here about the pmu1 register whereabouts on the A64? > > With Allwinners BSP kernels for older boards you can typically find all > the right phy init magic in: > > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/usb/host/sunxi_hci.c > > > And for the passby / pmu stuff specifically in usb_passby(), in the above > version of the code that uses: > > reg_value = USBC_Readl(sunxi_hci->usb_vbase + SUNXI_USB_PMU_IRQ_ENABLE); > > Whereby vbase gets set in init_sunxi_hci() as: > > sunxi_hci->usb_vbase = (void __iomem *)usbc_base[sunxi_hci->usbc_no]; > > With usbc_base being: > > static u32 usbc_base[4] = {(u32 __force)SUNXI_USB_HCI0_VBASE, (u32 > __force)SUNXI_USB_HCI1_VBASE, (u32 __force)SUNXI_USB_HCI2_VBASE, (u32 > __force)SUNXI_USB_HCI3_VBASE}; > > For the H3 at-least, this is all wrapped in model specific #ifdef > blocks ... > > But it is all contained in that one file, for the SUNXI_USB_HCI0_VBASE > defines do a grep in the mach include dir. Wow, thanks a lot for the pointers, that should give me enough clues to tackle this later today. > So assuming you've some A64 BSP kernel sources, that is where I would > start looking / digging (this has not failed me yet to get the usb > hosts running). This file will typically also contain hints on which > clocks you need to enable. Yeah, I took a brief look in there yesterday, but was disguste^Wconfused quickly. Will take a deep breath before doing that again tonight. >>> maybe you've not enabled the 5V power to the host USB ports ? >>> >>> My first step would be to check the 5v plug something with a powerled >>> or some such into the usb port and if the led does not light up >>> you need to drive some gpio high (typically) or enable some regulator >>> somewhere. >> >> So the USB pendrive I insert lights up, that's why I suspect the >> regulator is working. > > Yeah, then it likely is not a 5v problem, although I've seen cases where > there was some semi-high value resistor shortening a FET to switch the 5V > on/off, so it would seem if there is 5V there, but it is not really usable > (cannot deliver much if any current) until you actually drive the FET. I was wondering about that possibility also. I can try to use some self powered USB device to rule this out. Thanks! Andre. > That is likely not the case here, but I've seen this on at least one > board ... > > Regards, > > Hans > -- 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
