On Sat, Apr 18, 2015 at 07:10:41AM -0400, Tom Rini wrote:
On Sat, Apr 18, 2015 at 12:31:54PM +0200, Hans de Goede wrote:
Hi,
On 18-04-15 11:19, Hans de Goede wrote:
Hi,
On 17-04-15 21:39, Hans de Goede wrote:
Hi,
On 17-04-15 21:28, Hans de Goede wrote:
Hi,
On 17-04-15 19:53, Tom Rini wrote:
<snip>
I haven't had a chance to bisect yet but I will in a few hours.
No need to, I've just completed a bisect, it points to:
5bca5a6303f3526ab2cf9c0a62cd26c16e0d5c2f is the first bad commit commit 5bca5a6303f3526ab2cf9c0a62cd26c16e0d5c2f Author: Simon Glass sjg@chromium.org Date: Wed Mar 25 12:22:27 2015 -0600
dm: usb: Drop the EHCI weak functions These are a pain with driver model because we might have different EHCI drivers which want to implement them differently. Now that they use consistent function signatures, we can in good conscience move them to a struct. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>I'm going to first spend some time with my family now, I may look into this later tonight, or otherwise this weekend. I'll be sure to check mail first to avoid double work, so feel free to fix the problem while I'm relaxing :)
Ok, so I could not help myself and took a quick look at the patch causing the issue, this fixes the reset on usb scan problem:
diff --git a/drivers/usb/host/ehci-sunxi.c b/drivers/usb/host/ehci-sunxi.c index eda9f69..a847ac5 100644 --- a/drivers/usb/host/ehci-sunxi.c +++ b/drivers/usb/host/ehci-sunxi.c @@ -34,6 +34,8 @@ int ehci_hcd_init(int index, enum usb_init_type init, struct ehci_hccr **hccr, (uint32_t)*hccr, (uint32_t)*hcor, (uint32_t)HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));
- ehci_set_controller_priv(index, NULL, NULL);
return 0;}
And should probably be squashed into the original patch to avoid bisect problems.
But with this in place, all is still not well wrt non devicetree usb, usb keyboard support does not work, "usb tree" says:
USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Hub (480 Mb/s, 100mA) | +-3 Hub (12 Mb/s, 100mA) | | -1 See Interface (12 Mb/s, 0mA) |
Note the -1 as device number for the "See Interface" device.
This particular usb setup used to work fine.
I guess this is another issue to git bisect, no idea when I'll get around to that.
Ok, so I've done a git bisect of this (using a branch with my patch for the usb-reset issue squashed into the original commit to keep things bisectable), and it points to:
commit 3f7af70db23fc1c6b8f9e1bd966cadf2eb139f93 Author: Simon Glass sjg@chromium.org Date: Wed Mar 25 12:22:07 2015 -0600
dm: usb: Complete the splitting up of usb_new_device() This function now calls usb_setup_device() to set up the device and usb_hub_probe() to check if it is a hub. The XHCI special case is now a parameter to usb_setup_device(). The latter will be used by the USB uclass when it is added, since it does not rely on any CONFIGs or legacy data structures. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>(the commit id may be of because as said I'm using a custom branch for this).
I'll see if I can figure out why that commit breaks things, but I thought I would share the bisect result ASAP to avoid double work.
Attached are 2 patches (to be squashed into the original for bisectability) which fix things. See the commit messages for details.
Note these do not apply on top of u-boot-dm/master, they apply on top of the offending commit.
What I've done to get these "integrated" into my dm-master branch is:
- checkout the offending commit
- git am the 2 patches
- note down the commit id of the 2 patches as just applied
- checkout u-boot-dm/master
- git rebase -i origin/master
And then add lines with "pick <commit-id>" directly after the line for the troublesome commit
And then when everything looks good, redo the rebase -i and change the pick into fixup.
Interesting, you bisected down to a slightly different commit for the problem I'm having also with a keyboard. I'll squash yours in, in my local testing branch, and see if that helps my issue as well, thanks!
Also fixes the issue I saw.
Tested-by: Tom Rini trini@konsulko.com