I've been having no luck getting low-speed USB devices (i.e.: keyboard and mouse) to work with the 4.4 96boards kernel on hikey. My ethernet dongle works fine though. Is there a known problem or do I maybe just have a config issue? The error messages are:
device descriptor read/64, error -71
and
device not accepting address 7, error -71
Thanks, -dl
On 06/05/16 17:52, David Long wrote:
I've been having no luck getting low-speed USB devices (i.e.: keyboard and mouse) to work with the 4.4 96boards kernel on hikey. My ethernet dongle works fine though. Is there a known problem or do I maybe just have a config issue? The error messages are:
device descriptor read/64, error -71
anddevice not accepting address 7, error -71
Did you leave the USB dongle plugged in? IIRC Hikey cannot support a mixture of high speed and low/full speed devices simultaneously.
Daniel.
On 05/06/2016 01:28 PM, Daniel Thompson wrote:
On 06/05/16 17:52, David Long wrote:
I've been having no luck getting low-speed USB devices (i.e.: keyboard and mouse) to work with the 4.4 96boards kernel on hikey. My ethernet dongle works fine though. Is there a known problem or do I maybe just have a config issue? The error messages are:
device descriptor read/64, error -71
anddevice not accepting address 7, error -71
Did you leave the USB dongle plugged in? IIRC Hikey cannot support a mixture of high speed and low/full speed devices simultaneously.
the following command should set the controller to full speed
$ echo 1 > /sys/kernel/debug/f72c0000.usb/config
On 05/06/2016 01:28 PM, Daniel Thompson wrote:
On 06/05/16 17:52, David Long wrote:
I've been having no luck getting low-speed USB devices (i.e.: keyboard and mouse) to work with the 4.4 96boards kernel on hikey. My ethernet dongle works fine though. Is there a known problem or do I maybe just have a config issue? The error messages are:
device descriptor read/64, error -71
anddevice not accepting address 7, error -71
Did you leave the USB dongle plugged in? IIRC Hikey cannot support a mixture of high speed and low/full speed devices simultaneously.
Daniel.
Um, but it did under 3.18.... Is this supposed to be a new problem?
I got rid of the ethernet dongle (and external hub) but I still have the same problem.
Thanks, -dl
On 05/06/2016 01:36 PM, Jorge Ramirez wrote:
On 05/06/2016 01:28 PM, Daniel Thompson wrote:
On 06/05/16 17:52, David Long wrote:
I've been having no luck getting low-speed USB devices (i.e.: keyboard and mouse) to work with the 4.4 96boards kernel on hikey. My ethernet dongle works fine though. Is there a known problem or do I maybe just have a config issue? The error messages are:
device descriptor read/64, error -71
anddevice not accepting address 7, error -71
Did you leave the USB dongle plugged in? IIRC Hikey cannot support a mixture of high speed and low/full speed devices simultaneously.
the following command should set the controller to full speed
$ echo 1 > /sys/kernel/debug/f72c0000.usb/config
That file does not exist in that directory.
-dl
On 05/06/2016 01:49 PM, David Long wrote:
$ echo 1 > /sys/kernel/debug/f72c0000.usb/config
That file does not exist in that directory.
-dl
um, maybe the functionality was removed in the reference platform kernel, would need to check
having said that you can force the controller to auto-negotiate with a simple "hack" - see this: https://github.com/96boards/linux/commit/66869c654a62c91104daf9e17c2d75c057c...
not ideal but if you are being blocked by this it might get you going... I'll try a recent release in a couple of days and can let you know what I find.
On 05/06/2016 01:28 PM, Daniel Thompson wrote:
On 06/05/16 17:52, David Long wrote:
I've been having no luck getting low-speed USB devices (i.e.: keyboard and mouse) to work with the 4.4 96boards kernel on hikey. My ethernet dongle works fine though. Is there a known problem or do I maybe just have a config issue? The error messages are:
device descriptor read/64, error -71
anddevice not accepting address 7, error -71
OK, so it's clear now that the problem is the inability to use full/low speed together with high speed devices, combined with the fact the 4.4 hikey kernel sets high speed when both speed classes are present. It also looks like other changes in the post 3.18 debugfs break the /home/linaro/bin/usb_speed tool (i.e.: the "config" file no longer exists).
Thanks, -dl
On Fri, May 6, 2016 at 10:55 AM, Jorge Ramirez jorge.ramirez-ortiz@linaro.org wrote:
On 05/06/2016 01:49 PM, David Long wrote:
$ echo 1 > /sys/kernel/debug/f72c0000.usb/config
That file does not exist in that directory.
-dl
um, maybe the functionality was removed in the reference platform kernel, would need to check
having said that you can force the controller to auto-negotiate with a simple "hack" - see this: https://github.com/96boards/linux/commit/66869c654a62c91104daf9e17c2d75c057c...
not ideal but if you are being blocked by this it might get you going... I'll try a recent release in a couple of days and can let you know what I find.
Ok. I've got this running against 4.4 now and it seems to be working ok. I'll be submitting it for review for AOSP, and will make sure Guodong is cc'ed so he can pick it up in his branches.
Thanks for the patch Jorge! -john
On 05/09/2016 06:56 PM, John Stultz wrote:
having said that you can force the controller to auto-negotiate with a simple "hack" - see this: https://github.com/96boards/linux/commit/66869c654a62c91104daf9e17c2d75c057c...
not ideal but if you are being blocked by this it might get you going... I'll try a recent release in a couple of days and can let you know what I find.
Ok. I've got this running against 4.4 now and it seems to be working ok. I'll be submitting it for review for AOSP, and will make sure Guodong is cc'ed so he can pick it up in his branches.
Thanks for the patch Jorge! -john
sure thing
On 10 May 2016 at 08:00, Jorge Ramirez jorge.ramirez-ortiz@linaro.org wrote:
On 05/09/2016 06:56 PM, John Stultz wrote:
having said that you can force the controller to auto-negotiate with a simple "hack" - see this:
https://github.com/96boards/linux/commit/66869c654a62c91104daf9e17c2d75c057c...
not ideal but if you are being blocked by this it might get you going... I'll try a recent release in a couple of days and can let you know what I find.
Ok. I've got this running against 4.4 now and it seems to be working ok. I'll be submitting it for review for AOSP, and will make sure Guodong is cc'ed so he can pick it up in his branches.
Thanks for the patch Jorge! -john
sure thing
Thanks, guys. So this feature is now part of hikey-mainline-rebase (v4.4).
You can fetch it from this branch: https://github.com/96boards-hikey/linux/commits/hikey-mainline-rebase (tag: hikey-mainline-rebase-v4.4-20160510)
== TAG: v4.4-20160510 - updated eas-v5.2 - add usb-speed auto-negociate == TAG: v4.4-20160504 - updated drm, adv7511 - added panel (LCD) support == TAG: v4.4-20160429 - added hdmi audio (i2s, k3dma), optee. == TAG: v4.4-20160317
-Guodong
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On Tue, May 10, 2016 at 7:54 AM, Guodong Xu guodong.xu@linaro.org wrote:
On 10 May 2016 at 08:00, Jorge Ramirez jorge.ramirez-ortiz@linaro.org wrote:
On 05/09/2016 06:56 PM, John Stultz wrote:
having said that you can force the controller to auto-negotiate with a simple "hack" - see this:
https://github.com/96boards/linux/commit/66869c654a62c91104daf9e17c2d75c057c...
not ideal but if you are being blocked by this it might get you going... I'll try a recent release in a couple of days and can let you know what I find.
Ok. I've got this running against 4.4 now and it seems to be working ok. I'll be submitting it for review for AOSP, and will make sure Guodong is cc'ed so he can pick it up in his branches.
Thanks for the patch Jorge! -john
sure thing
Thanks, guys. So this feature is now part of hikey-mainline-rebase (v4.4).
You can fetch it from this branch: https://github.com/96boards-hikey/linux/commits/hikey-mainline-rebase (tag: hikey-mainline-rebase-v4.4-20160510)
== TAG: v4.4-20160510
- updated eas-v5.2
- add usb-speed auto-negociate
== TAG: v4.4-20160504
- updated drm, adv7511
- added panel (LCD) support
== TAG: v4.4-20160429
- added hdmi audio (i2s, k3dma), optee.
== TAG: v4.4-20160317
Thanks for pushing it.
Amit, are you merging that into the RPK soon?
Thanks,
On Tue, May 10, 2016 at 4:24 PM, Guodong Xu guodong.xu@linaro.org wrote:
On 10 May 2016 at 08:00, Jorge Ramirez jorge.ramirez-ortiz@linaro.org wrote:
On 05/09/2016 06:56 PM, John Stultz wrote:
having said that you can force the controller to auto-negotiate with a simple "hack" - see this:
https://github.com/96boards/linux/commit/66869c654a62c91104daf9e17c2d75c057c...
not ideal but if you are being blocked by this it might get you going... I'll try a recent release in a couple of days and can let you know what I find.
Ok. I've got this running against 4.4 now and it seems to be working ok. I'll be submitting it for review for AOSP, and will make sure Guodong is cc'ed so he can pick it up in his branches.
Thanks for the patch Jorge! -john
sure thing
Thanks, guys. So this feature is now part of hikey-mainline-rebase (v4.4).
You can fetch it from this branch: https://github.com/96boards-hikey/linux/commits/hikey-mainline-rebase (tag: hikey-mainline-rebase-v4.4-20160510)
== TAG: v4.4-20160510
- updated eas-v5.2
- add usb-speed auto-negociate
I've merged the hikey-tracking-usb branch to get this fix. I won't be picking up the eas branch yet.
== TAG: v4.4-20160504
- updated drm, adv7511
adv7511 still conflicts with the QC LT tree. What is the ETA for preparing a non-conflicting branch that Xinliang was working on?
- added panel (LCD) support
== TAG: v4.4-20160429
- added hdmi audio (i2s, k3dma), optee.
== TAG: v4.4-20160317
These are all merged. Thanks.
On 05/11/2016 02:38 AM, Amit Kucheria wrote:
On Tue, May 10, 2016 at 4:24 PM, Guodong Xu guodong.xu@linaro.org wrote:
On 10 May 2016 at 08:00, Jorge Ramirez jorge.ramirez-ortiz@linaro.org wrote:
On 05/09/2016 06:56 PM, John Stultz wrote:
having said that you can force the controller to auto-negotiate with a simple "hack" - see this:
> https://github.com/96boards/linux/commit/66869c654a62c91104daf9e17c2d75c057c...
not ideal but if you are being blocked by this it might get you going... I'll try a recent release in a couple of days and can let you know what I find.
Ok. I've got this running against 4.4 now and it seems to be working ok. I'll be submitting it for review for AOSP, and will make sure Guodong is cc'ed so he can pick it up in his branches.
Thanks for the patch Jorge! -john
sure thing
Thanks, guys. So this feature is now part of hikey-mainline-rebase (v4.4).
You can fetch it from this branch: https://github.com/96boards-hikey/linux/commits/hikey-mainline-rebase (tag: hikey-mainline-rebase-v4.4-20160510)
== TAG: v4.4-20160510
- updated eas-v5.2
- add usb-speed auto-negociate
I've merged the hikey-tracking-usb branch to get this fix. I won't be picking up the eas branch yet.
== TAG: v4.4-20160504
- updated drm, adv7511
adv7511 still conflicts with the QC LT tree. What is the ETA for preparing a non-conflicting branch that Xinliang was working on?
- added panel (LCD) support
== TAG: v4.4-20160429
- added hdmi audio (i2s, k3dma), optee.
== TAG: v4.4-20160317
These are all merged. Thanks. _______________________________________________ Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
If hikey is to work with unmodified upstream code doesn't someone (KWG/Me?) have to make this "hack" (which is in the common USB driver) more palatable?
-dl
On 11 May 2016 at 21:38, David Long dave.long@linaro.org wrote:
On 05/11/2016 02:38 AM, Amit Kucheria wrote:
On Tue, May 10, 2016 at 4:24 PM, Guodong Xu guodong.xu@linaro.org wrote:
On 10 May 2016 at 08:00, Jorge Ramirez jorge.ramirez-ortiz@linaro.org wrote:
On 05/09/2016 06:56 PM, John Stultz wrote:
> having said that you can force the controller to auto-negotiate with > a > simple "hack" - see this:
>> >> https://github.com/96boards/linux/commit/66869c654a62c91104daf9e17c2d75c057c... > > > not ideal but if you are being blocked by this it might get you > going... > I'll try a recent release in a couple of days and can let you know > what > I > find.
Ok. I've got this running against 4.4 now and it seems to be working ok. I'll be submitting it for review for AOSP, and will make sure Guodong is cc'ed so he can pick it up in his branches.
Thanks for the patch Jorge! -john
sure thing
Thanks, guys. So this feature is now part of hikey-mainline-rebase (v4.4).
You can fetch it from this branch: https://github.com/96boards-hikey/linux/commits/hikey-mainline-rebase (tag: hikey-mainline-rebase-v4.4-20160510)
== TAG: v4.4-20160510
- updated eas-v5.2
- add usb-speed auto-negociate
I've merged the hikey-tracking-usb branch to get this fix. I won't be picking up the eas branch yet.
== TAG: v4.4-20160504
- updated drm, adv7511
adv7511 still conflicts with the QC LT tree. What is the ETA for preparing a non-conflicting branch that Xinliang was working on?
- added panel (LCD) support
== TAG: v4.4-20160429
- added hdmi audio (i2s, k3dma), optee.
== TAG: v4.4-20160317
These are all merged. Thanks. _______________________________________________ Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
If hikey is to work with unmodified upstream code doesn't someone (KWG/Me?) have to make this "hack" (which is in the common USB driver) more palatable?
HiKey is using the designware IP in a special way (silicon defined), which means it lacks functionality of handling simultaneously high-speed and low/full-speed devices when working at USB host mode.
Then the question becomes how can you tell the dwc2 hcd has this limitation (as hikey) or not (as majority SoCs out there)?
-Guodong
-dl
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On Wed, May 11, 2016 at 6:38 AM, David Long dave.long@linaro.org wrote:
On Tue, May 10, 2016 at 4:24 PM, Guodong Xu guodong.xu@linaro.org wrote:
On 05/09/2016 06:56 PM, John Stultz wrote:
Ok. I've got this running against 4.4 now and it seems to be working ok. I'll be submitting it for review for AOSP, and will make sure Guodong is cc'ed so he can pick it up in his branches.
Thanks, guys. So this feature is now part of hikey-mainline-rebase (v4.4).
If hikey is to work with unmodified upstream code doesn't someone (KWG/Me?) have to make this "hack" (which is in the common USB driver) more palatable?
Yea. There's still enough less controversial functionality to get upstream to keep folks busy, but eventually we will get down to the few hardware specific quirks like this that we need to solve in a generic fashion (hikey's restricted HDMI modes is another similar quirk). To some extent it will depend on the maintainers desire to accommodate such a quirk.
thanks -john
On 05/11/2016 01:32 PM, John Stultz wrote:
On Wed, May 11, 2016 at 6:38 AM, David Long dave.long@linaro.org wrote:
On Tue, May 10, 2016 at 4:24 PM, Guodong Xu guodong.xu@linaro.org wrote:
On 05/09/2016 06:56 PM, John Stultz wrote:
Ok. I've got this running against 4.4 now and it seems to be working ok. I'll be submitting it for review for AOSP, and will make sure Guodong is cc'ed so he can pick it up in his branches.
Thanks, guys. So this feature is now part of hikey-mainline-rebase (v4.4).
If hikey is to work with unmodified upstream code doesn't someone (KWG/Me?) have to make this "hack" (which is in the common USB driver) more palatable?
Yea. There's still enough less controversial functionality to get upstream to keep folks busy, but eventually we will get down to the few hardware specific quirks like this that we need to solve in a generic fashion (hikey's restricted HDMI modes is another similar quirk). To some extent it will depend on the maintainers desire to accommodate such a quirk.
having said that nothing should discourage you to improve the code David - this and some other fixes/workarounds were not planned activities if that is what you are asking, just some hours spent after work (I have the feeling that you are asking about having a proper process in place to deal with issues like this?)
On 05/11/2016 03:52 PM, Jorge Ramirez wrote:
On 05/11/2016 01:32 PM, John Stultz wrote:
On Wed, May 11, 2016 at 6:38 AM, David Long dave.long@linaro.org wrote:
On Tue, May 10, 2016 at 4:24 PM, Guodong Xu guodong.xu@linaro.org wrote:
On 05/09/2016 06:56 PM, John Stultz wrote: > Ok. I've got this running against 4.4 now and it seems to be working > ok. I'll be submitting it for review for AOSP, and will make sure > Guodong is cc'ed so he can pick it up in his branches. >
Thanks, guys. So this feature is now part of hikey-mainline-rebase (v4.4).
If hikey is to work with unmodified upstream code doesn't someone (KWG/Me?) have to make this "hack" (which is in the common USB driver) more palatable?
Yea. There's still enough less controversial functionality to get upstream to keep folks busy, but eventually we will get down to the few hardware specific quirks like this that we need to solve in a generic fashion (hikey's restricted HDMI modes is another similar quirk). To some extent it will depend on the maintainers desire to accommodate such a quirk.
having said that nothing should discourage you to improve the code David
- this and some other fixes/workarounds were not planned activities if
that is what you are asking, just some hours spent after work (I have the feeling that you are asking about having a proper process in place to deal with issues like this?)
I'm just looking to help convert local fixes to known problems into acceptable upstream patches (in core code). I don't want to be duplicating work someone else is already doing or necessarily starting with the lowest priority issues, but this is a documented limitation where we might be able to take an existing quick fix and turn it into something acceptable upstream. I'm only looking at it now because I personally ran into it as a regression. I'm not sure if the current USB items in the gantt chart cover this issue, and someone could certainly tell me different core changes need to be upstreamed first. Do feel free to point out any process I might be missing here.
-dl
On Thu, May 12, 2016 at 1:54 AM, David Long dave.long@linaro.org wrote:
On 05/11/2016 03:52 PM, Jorge Ramirez wrote:
On 05/11/2016 01:32 PM, John Stultz wrote:
On Wed, May 11, 2016 at 6:38 AM, David Long dave.long@linaro.org wrote:
On Tue, May 10, 2016 at 4:24 PM, Guodong Xu guodong.xu@linaro.org wrote:
> > On 05/09/2016 06:56 PM, John Stultz wrote: >> >> Ok. I've got this running against 4.4 now and it seems to be working >> ok. I'll be submitting it for review for AOSP, and will make sure >> Guodong is cc'ed so he can pick it up in his branches. >>
Thanks, guys. So this feature is now part of hikey-mainline-rebase (v4.4).
If hikey is to work with unmodified upstream code doesn't someone (KWG/Me?) have to make this "hack" (which is in the common USB driver) more palatable?
Yea. There's still enough less controversial functionality to get upstream to keep folks busy, but eventually we will get down to the few hardware specific quirks like this that we need to solve in a generic fashion (hikey's restricted HDMI modes is another similar quirk). To some extent it will depend on the maintainers desire to accommodate such a quirk.
having said that nothing should discourage you to improve the code David
- this and some other fixes/workarounds were not planned activities if
that is what you are asking, just some hours spent after work (I have the feeling that you are asking about having a proper process in place to deal with issues like this?)
I'm just looking to help convert local fixes to known problems into acceptable upstream patches (in core code). I don't want to be duplicating work someone else is already doing or necessarily starting with the lowest priority issues, but this is a documented limitation where we might be able to take an existing quick fix and turn it into something acceptable upstream. I'm only looking at it now because I personally ran into it as a regression. I'm not sure if the current USB items in the gantt chart cover this issue, and someone could certainly tell me different core changes need to be upstreamed first. Do feel free to point out any process I might be missing here.
IMHO getting this fixed properly upstream is desirable and someone should spend time on it. The are some other tasks around hdmi audio that need help. Just pick one and let Guodong know.
Regards, Amit
-
Amit Kucheria -
Daniel Thompson -
David Long -
Guodong Xu -
John Stultz -
Jorge Ramirez -
Ricardo Salveti