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