From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] ath9k-htc on OHCI -> bogus usb xfer
Date: Wed, 6 Jul 2016 09:30:28 +0000 [thread overview]
Message-ID: <1467797356.3086.48.camel@synopsys.com> (raw)
In-Reply-To: <577CCAB8.90003@de.bosch.com>
Hi+AKA-Oleksij,
On Wed, 2016-07-06 at 11:09 +-0200, fixed-term.Oleksij.Rempel wrote:
+AD4-
+AD4- On 06.07.2016 10:45, Alexey Brodkin wrote:
+AD4- +AD4-
+AD4- +AD4- Hi Oleksij,
+AD4- +AD4-
+AD4- +AD4- On Wed, 2016-07-06 at 10:38 +-0200, fixed-term.Oleksij.Rempel wrote:
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- On 06.07.2016 10:32, Alexey Brodkin wrote:
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- Hi Oleksij,
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- On Wed, 2016-07-06 at 10:24 +-0200, fixed-term.Oleksij.Rempel wrote:
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AKA-
+AD4- +AD4- +AD4- +AD4- +AD4- Hm... this Endpoint should be Interrupt, not Bulk. If you search for
+AD4- +AD4- +AD4- +AD4- +AD4- lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- what did went wrong here? Is it not working in USB High Speed mode?
+AD4- +AD4- +AD4- +AD4- Unfortunately as of now on that board EHCI doesn't work.
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- That's not a problem of a particular USB device but something in either
+AD4- +AD4- +AD4- +AD4- ECHI host controller or its integration. I do hope we will fix it sometime soon
+AD4- +AD4- +AD4- +AD4- (this is a development board and USB controller is implemented in FPGA so
+AD4- +AD4- +AD4- +AD4- there's a chance to fix stuff later on).
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- So given only OHCI works on the board I went forward and attempted to use it
+AD4- +AD4- +AD4- +AD4- with Wi-Fi USB dongle.
+AD4- +AD4- +AD4- I did some tests for 2 years on OHCI controller on x86. There was no
+AD4- +AD4- +AD4- noticable issues. It was even a bit faster then Intels EHCI. I don't
+AD4- +AD4- +AD4- think OHCI alone is the source of this problem.
+AD4- +AD4- Well I was also surprised how well that dongle works with that board in
+AD4- +AD4- OHCI mode. I saw quite consistent +AH4-4-5 Mbit/second rates when doing Speedtest
+AD4- +AD4- from my smartphone. So IMHO it's completely usable. Especially on that kind of
+AD4- +AD4- HW which has main CPU running at just 100MHz.
+AD4- +AD4-
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- On other side, so far i know, this adapter claims to provide usb full
+AD4- +AD4- +AD4- speed support, (Not only high speed) and may use different usb
+AD4- +AD4- +AD4- descriptor for this. May be this is the problem.
+AD4- +AD4- So is there something we may do with all that?
+AD4- Sure...
+AD4-
+AD4- This shows that EP4 is Bluk in full speed mode. And it is defined by a
+AD4- boot loader of this chip:
+AD4- grep -R USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE +ACo-
+AD4- sboot/magpie+AF8-1+AF8-1/sboot/hif/usb/src/usb+AF8-table.c:
+AD4- m2BYTE(USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE, USB+AF8-FS+AF8-EP4+AF8-MAX+AF8-PACKET+AF8-SIZE),
+AD4- sboot/magpie+AF8-1+AF8-1/sboot/hif/usb/src/usb+AF8-table.h:+ACM-define
+AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK
+AD4- sboot/magpie+AF8-1+AF8-1/inc/usb+AF8-table.h:+ACM-define USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE
+AD4- +AKA-bUSB+AF8-EP+AF8-TYPE+AF8-BULK
+AD4- target+AF8-firmware/magpie+AF8-fw+AF8-dev/target/inc/k2/usb+AF8-table.h:+ACM-define
+AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK
+AD4- target+AF8-firmware/magpie+AF8-fw+AF8-dev/target/inc/magpie/usb+AF8-table.h:+ACM-define
+AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK
+AD4-
+AD4-
+AD4- So, there are fallowing variants to fix it:
+AD4- a) patch full speed usb descriptor in firmware and add usb reinit
+AD4- support to the driver.
+AD4- b) add support of different EP4 types.
+AD4-
+AD4- In any case, some one need to implement it... right now i have time only
+AD4- for mentoring.
That's understood.
+AD4- It is hard to say, which solution is better. It will affect performance
+AD4- and stability. We will need lots of testing on different HW variants to
+AD4- know it.
+AD4- May be usb maeling list can give some input here?
Let's hope so :)
+AD4- Currently we have fallowing issues:
+AD4- - if EP4 and EP3 are Interrupt, it works slower on High Speed controller.
+AD4- - if EP4 and EP3 are Bulk, the work better on High Speed and brake on
+AD4- Super Speed controllers. This adapter support my 64B packets and if we
+AD4- have more, fifo of this adapter will overrun.
+AD4- - Full Speed is currently unknown field for me, and it looks like it was
+AD4- never actually working properly.
But given that dongle seem to work fine with muted warning do you think it's
fine to continue that way or not?
I mean if there's a chance this +ACI-bogus usb xfer+ACI- might affect something during
execution? Otherwise if that's just not a crucial problem or not a problem at all
may be we may just think how to make this warning not so annoying (in my case
I saw never ending flood of those warnings so that basically stopped me from using
the board after that warning started to appear.
-Alexey
WARNING: multiple messages have this Message-ID (diff)
From: Alexey.Brodkin@synopsys.com (Alexey Brodkin)
To: linux-snps-arc@lists.infradead.org
Subject: ath9k-htc on OHCI -> bogus usb xfer
Date: Wed, 6 Jul 2016 09:30:28 +0000 [thread overview]
Message-ID: <1467797356.3086.48.camel@synopsys.com> (raw)
In-Reply-To: <577CCAB8.90003@de.bosch.com>
Hi?Oleksij,
On Wed, 2016-07-06@11:09 +0200, fixed-term.Oleksij.Rempel wrote:
>
> On 06.07.2016 10:45, Alexey Brodkin wrote:
> >
> > Hi Oleksij,
> >
> > On Wed, 2016-07-06@10:38 +0200, fixed-term.Oleksij.Rempel wrote:
> > >
> > >
> > > On 06.07.2016 10:32, Alexey Brodkin wrote:
> > > >
> > > >
> > > > Hi Oleksij,
> > > >
> > > > On Wed, 2016-07-06@10:24 +0200, fixed-term.Oleksij.Rempel wrote:
> > > > >
> > > > >
> > > > > ?
> > > > > Hm... this Endpoint should be Interrupt, not Bulk. If you search for
> > > > > lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
> > > > >
> > > > > what did went wrong here? Is it not working in USB High Speed mode?
> > > > Unfortunately as of now on that board EHCI doesn't work.
> > > >
> > > > That's not a problem of a particular USB device but something in either
> > > > ECHI host controller or its integration. I do hope we will fix it sometime soon
> > > > (this is a development board and USB controller is implemented in FPGA so
> > > > there's a chance to fix stuff later on).
> > > >
> > > > So given only OHCI works on the board I went forward and attempted to use it
> > > > with Wi-Fi USB dongle.
> > > I did some tests for 2 years on OHCI controller on x86. There was no
> > > noticable issues. It was even a bit faster then Intels EHCI. I don't
> > > think OHCI alone is the source of this problem.
> > Well I was also surprised how well that dongle works with that board in
> > OHCI mode. I saw quite consistent ~4-5 Mbit/second rates when doing Speedtest
> > from my smartphone. So IMHO it's completely usable. Especially on that kind of
> > HW which has main CPU running at just 100MHz.
> >
> > >
> > > On other side, so far i know, this adapter claims to provide usb full
> > > speed support, (Not only high speed) and may use different usb
> > > descriptor for this. May be this is the problem.
> > So is there something we may do with all that?
> Sure...
>
> This shows that EP4 is Bluk in full speed mode. And it is defined by a
> boot loader of this chip:
> grep -R USB_FS_EP4_ATTRIBUTE *
> sboot/magpie_1_1/sboot/hif/usb/src/usb_table.c:
> m2BYTE(USB_FS_EP4_ATTRIBUTE, USB_FS_EP4_MAX_PACKET_SIZE),
> sboot/magpie_1_1/sboot/hif/usb/src/usb_table.h:#define
> USB_FS_EP4_ATTRIBUTE????????????bUSB_EP_TYPE_BULK
> sboot/magpie_1_1/inc/usb_table.h:#define USB_FS_EP4_ATTRIBUTE
> ?bUSB_EP_TYPE_BULK
> target_firmware/magpie_fw_dev/target/inc/k2/usb_table.h:#define
> USB_FS_EP4_ATTRIBUTE????????????bUSB_EP_TYPE_BULK
> target_firmware/magpie_fw_dev/target/inc/magpie/usb_table.h:#define
> USB_FS_EP4_ATTRIBUTE????????????bUSB_EP_TYPE_BULK
>
>
> So, there are fallowing variants to fix it:
> a) patch full speed usb descriptor in firmware and add usb reinit
> support to the driver.
> b) add support of different EP4 types.
>
> In any case, some one need to implement it... right now i have time only
> for mentoring.
That's understood.
> It is hard to say, which solution is better. It will affect performance
> and stability. We will need lots of testing on different HW variants to
> know it.
> May be usb maeling list can give some input here?
Let's hope so :)
> Currently we have fallowing issues:
> - if EP4 and EP3 are Interrupt, it works slower on High Speed controller.
> - if EP4 and EP3 are Bulk, the work better on High Speed and brake on
> Super Speed controllers. This adapter support my 64B packets and if we
> have more, fifo of this adapter will overrun.
> - Full Speed is currently unknown field for me, and it looks like it was
> never actually working properly.
But given that dongle seem to work fine with muted warning do you think it's
fine to continue that way or not?
I mean if there's a chance this "bogus usb xfer" might affect something during
execution? Otherwise if that's just not a crucial problem or not a problem at all
may be we may just think how to make this warning not so annoying (in my case
I saw never ending flood of those warnings so that basically stopped me from using
the board after that warning started to appear.
-Alexey
WARNING: multiple messages have this Message-ID (diff)
From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: "fixed-term.Oleksij.Rempel@de.bosch.com"
<fixed-term.Oleksij.Rempel@de.bosch.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"anders.darander@gmail.com" <anders.darander@gmail.com>,
"ath9k-devel@lists.ath9k.org" <ath9k-devel@lists.ath9k.org>,
"linux@rempel-privat.de" <linux@rempel-privat.de>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: ath9k-htc on OHCI -> bogus usb xfer
Date: Wed, 6 Jul 2016 09:30:28 +0000 [thread overview]
Message-ID: <1467797356.3086.48.camel@synopsys.com> (raw)
In-Reply-To: <577CCAB8.90003@de.bosch.com>
Hi Oleksij,
On Wed, 2016-07-06 at 11:09 +0200, fixed-term.Oleksij.Rempel wrote:
>
> On 06.07.2016 10:45, Alexey Brodkin wrote:
> >
> > Hi Oleksij,
> >
> > On Wed, 2016-07-06 at 10:38 +0200, fixed-term.Oleksij.Rempel wrote:
> > >
> > >
> > > On 06.07.2016 10:32, Alexey Brodkin wrote:
> > > >
> > > >
> > > > Hi Oleksij,
> > > >
> > > > On Wed, 2016-07-06 at 10:24 +0200, fixed-term.Oleksij.Rempel wrote:
> > > > >
> > > > >
> > > > >
> > > > > Hm... this Endpoint should be Interrupt, not Bulk. If you search for
> > > > > lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
> > > > >
> > > > > what did went wrong here? Is it not working in USB High Speed mode?
> > > > Unfortunately as of now on that board EHCI doesn't work.
> > > >
> > > > That's not a problem of a particular USB device but something in either
> > > > ECHI host controller or its integration. I do hope we will fix it sometime soon
> > > > (this is a development board and USB controller is implemented in FPGA so
> > > > there's a chance to fix stuff later on).
> > > >
> > > > So given only OHCI works on the board I went forward and attempted to use it
> > > > with Wi-Fi USB dongle.
> > > I did some tests for 2 years on OHCI controller on x86. There was no
> > > noticable issues. It was even a bit faster then Intels EHCI. I don't
> > > think OHCI alone is the source of this problem.
> > Well I was also surprised how well that dongle works with that board in
> > OHCI mode. I saw quite consistent ~4-5 Mbit/second rates when doing Speedtest
> > from my smartphone. So IMHO it's completely usable. Especially on that kind of
> > HW which has main CPU running at just 100MHz.
> >
> > >
> > > On other side, so far i know, this adapter claims to provide usb full
> > > speed support, (Not only high speed) and may use different usb
> > > descriptor for this. May be this is the problem.
> > So is there something we may do with all that?
> Sure...
>
> This shows that EP4 is Bluk in full speed mode. And it is defined by a
> boot loader of this chip:
> grep -R USB_FS_EP4_ATTRIBUTE *
> sboot/magpie_1_1/sboot/hif/usb/src/usb_table.c:
> m2BYTE(USB_FS_EP4_ATTRIBUTE, USB_FS_EP4_MAX_PACKET_SIZE),
> sboot/magpie_1_1/sboot/hif/usb/src/usb_table.h:#define
> USB_FS_EP4_ATTRIBUTE bUSB_EP_TYPE_BULK
> sboot/magpie_1_1/inc/usb_table.h:#define USB_FS_EP4_ATTRIBUTE
> bUSB_EP_TYPE_BULK
> target_firmware/magpie_fw_dev/target/inc/k2/usb_table.h:#define
> USB_FS_EP4_ATTRIBUTE bUSB_EP_TYPE_BULK
> target_firmware/magpie_fw_dev/target/inc/magpie/usb_table.h:#define
> USB_FS_EP4_ATTRIBUTE bUSB_EP_TYPE_BULK
>
>
> So, there are fallowing variants to fix it:
> a) patch full speed usb descriptor in firmware and add usb reinit
> support to the driver.
> b) add support of different EP4 types.
>
> In any case, some one need to implement it... right now i have time only
> for mentoring.
That's understood.
> It is hard to say, which solution is better. It will affect performance
> and stability. We will need lots of testing on different HW variants to
> know it.
> May be usb maeling list can give some input here?
Let's hope so :)
> Currently we have fallowing issues:
> - if EP4 and EP3 are Interrupt, it works slower on High Speed controller.
> - if EP4 and EP3 are Bulk, the work better on High Speed and brake on
> Super Speed controllers. This adapter support my 64B packets and if we
> have more, fifo of this adapter will overrun.
> - Full Speed is currently unknown field for me, and it looks like it was
> never actually working properly.
But given that dongle seem to work fine with muted warning do you think it's
fine to continue that way or not?
I mean if there's a chance this "bogus usb xfer" might affect something during
execution? Otherwise if that's just not a crucial problem or not a problem at all
may be we may just think how to make this warning not so annoying (in my case
I saw never ending flood of those warnings so that basically stopped me from using
the board after that warning started to appear.
-Alexey
next prev parent reply other threads:[~2016-07-06 9:30 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-05 12:20 [ath9k-devel] ath9k-htc on OHCI -> bogus usb xfer Alexey Brodkin
2016-07-05 12:20 ` Alexey Brodkin
2016-07-05 12:20 ` Alexey Brodkin
2016-07-05 17:23 ` [ath9k-devel] " Oleksij Rempel
2016-07-05 17:23 ` Oleksij Rempel
2016-07-05 17:23 ` Oleksij Rempel
2016-07-05 17:31 ` [ath9k-devel] " Alexey Brodkin
2016-07-05 17:31 ` Alexey Brodkin
2016-07-05 17:31 ` Alexey Brodkin
2016-07-05 19:01 ` [ath9k-devel] " Oleksij Rempel
2016-07-05 19:01 ` Oleksij Rempel
2016-07-05 19:01 ` Oleksij Rempel
2016-07-06 7:44 ` [ath9k-devel] " Alexey Brodkin
2016-07-06 7:44 ` Alexey Brodkin
2016-07-06 7:44 ` Alexey Brodkin
2016-07-06 8:24 ` fixed-term.Oleksij.Rempel
2016-07-06 8:30 ` [ath9k-devel] " fixed-term.Oleksij.Rempel
2016-07-06 8:32 ` Alexey Brodkin
2016-07-06 8:32 ` Alexey Brodkin
2016-07-06 8:32 ` Alexey Brodkin
2016-07-06 8:38 ` fixed-term.Oleksij.Rempel
2016-07-06 8:39 ` [ath9k-devel] " fixed-term.Oleksij.Rempel
2016-07-06 8:45 ` Alexey Brodkin
2016-07-06 8:45 ` Alexey Brodkin
2016-07-06 8:45 ` Alexey Brodkin
2016-07-06 9:09 ` fixed-term.Oleksij.Rempel
2016-07-06 9:09 ` [ath9k-devel] " fixed-term.Oleksij.Rempel
2016-07-06 9:30 ` Alexey Brodkin [this message]
2016-07-06 9:30 ` Alexey Brodkin
2016-07-06 9:30 ` Alexey Brodkin
2016-07-06 10:32 ` fixed-term.Oleksij.Rempel
2016-07-06 10:32 ` [ath9k-devel] " fixed-term.Oleksij.Rempel
2016-07-07 5:16 ` Alexey Brodkin
2016-07-07 5:16 ` Alexey Brodkin
2016-07-07 5:16 ` Alexey Brodkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1467797356.3086.48.camel@synopsys.com \
--to=alexey.brodkin@synopsys.com \
--cc=ath9k-devel@lists.ath9k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.