diff for duplicates of <1467868495.23055.1.camel@synopsys.com> diff --git a/a/1.txt b/N1/1.txt index 649fc11..fadf364 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,115 +1,115 @@ -Hi+AKA-Oleksij, +Hi?Oleksij, -On Wed, 2016-07-06 at 12:32 +-0200, fixed-term.Oleksij.Rempel wrote: -+AD4- -+AD4- On 06.07.2016 11:30, Alexey Brodkin wrote: -+AD4- +AD4- -+AD4- +AD4- Hi Oleksij, -+AD4- +AD4- -+AD4- +AD4- On Wed, 2016-07-06 at 11:09 +-0200, fixed-term.Oleksij.Rempel wrote: -+AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- On 06.07.2016 10:45, 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:38 +-0200, fixed-term.Oleksij.Rempel wrote: -+AD4- +AD4- +AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- +AD4- +AD4- -+AD4- +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- -+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Hi Oleksij, -+AD4- +AD4- +AD4- +AD4- +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- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AKA- -+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Hm... this Endpoint should be Interrupt, not Bulk. If you search for -+AD4- +AD4- +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- +AD4- +AD4- +AD4- +AD4- what did went wrong here? Is it not working in USB High Speed mode? -+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Unfortunately as of now on that board EHCI doesn't work. -+AD4- +AD4- +AD4- +AD4- +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- +AD4- +AD4- ECHI host controller or its integration. I do hope we will fix it sometime soon -+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- (this is a development board and USB controller is implemented in FPGA so -+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- there's a chance to fix stuff later on). -+AD4- +AD4- +AD4- +AD4- +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- +AD4- +AD4- with Wi-Fi USB dongle. -+AD4- +AD4- +AD4- +AD4- +AD4- I did some tests for 2 years on OHCI controller on x86. There was no -+AD4- +AD4- +AD4- +AD4- +AD4- noticable issues. It was even a bit faster then Intels EHCI. I don't -+AD4- +AD4- +AD4- +AD4- +AD4- think OHCI alone is the source of this problem. -+AD4- +AD4- +AD4- +AD4- Well I was also surprised how well that dongle works with that board in -+AD4- +AD4- +AD4- +AD4- OHCI mode. I saw quite consistent +AH4-4-5 Mbit/second rates when doing Speedtest -+AD4- +AD4- +AD4- +AD4- from my smartphone. So IMHO it's completely usable. Especially on that kind of -+AD4- +AD4- +AD4- +AD4- HW which has main CPU running at just 100MHz. -+AD4- +AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- +AD4- +AD4- -+AD4- +AD4- +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- +AD4- +AD4- speed support, (Not only high speed) and may use different usb -+AD4- +AD4- +AD4- +AD4- +AD4- descriptor for this. May be this is the problem. -+AD4- +AD4- +AD4- +AD4- So is there something we may do with all that? -+AD4- +AD4- +AD4- Sure... -+AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- This shows that EP4 is Bluk in full speed mode. And it is defined by a -+AD4- +AD4- +AD4- boot loader of this chip: -+AD4- +AD4- +AD4- grep -R USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE +ACo- -+AD4- +AD4- +AD4- sboot/magpie+AF8-1+AF8-1/sboot/hif/usb/src/usb+AF8-table.c: -+AD4- +AD4- +AD4- m2BYTE(USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE, USB+AF8-FS+AF8-EP4+AF8-MAX+AF8-PACKET+AF8-SIZE), -+AD4- +AD4- +AD4- sboot/magpie+AF8-1+AF8-1/sboot/hif/usb/src/usb+AF8-table.h:+ACM-define -+AD4- +AD4- +AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK -+AD4- +AD4- +AD4- sboot/magpie+AF8-1+AF8-1/inc/usb+AF8-table.h:+ACM-define USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE -+AD4- +AD4- +AD4- +AKA-bUSB+AF8-EP+AF8-TYPE+AF8-BULK -+AD4- +AD4- +AD4- target+AF8-firmware/magpie+AF8-fw+AF8-dev/target/inc/k2/usb+AF8-table.h:+ACM-define -+AD4- +AD4- +AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK -+AD4- +AD4- +AD4- target+AF8-firmware/magpie+AF8-fw+AF8-dev/target/inc/magpie/usb+AF8-table.h:+ACM-define -+AD4- +AD4- +AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK -+AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- So, there are fallowing variants to fix it: -+AD4- +AD4- +AD4- a) patch full speed usb descriptor in firmware and add usb reinit -+AD4- +AD4- +AD4- support to the driver. -+AD4- +AD4- +AD4- b) add support of different EP4 types. -+AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- In any case, some one need to implement it... right now i have time only -+AD4- +AD4- +AD4- for mentoring. -+AD4- +AD4- That's understood. -+AD4- +AD4- -+AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- It is hard to say, which solution is better. It will affect performance -+AD4- +AD4- +AD4- and stability. We will need lots of testing on different HW variants to -+AD4- +AD4- +AD4- know it. -+AD4- +AD4- +AD4- May be usb maeling list can give some input here? -+AD4- +AD4- Let's hope so :) -+AD4- +AD4- -+AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- Currently we have fallowing issues: -+AD4- +AD4- +AD4- - if EP4 and EP3 are Interrupt, it works slower on High Speed controller. -+AD4- +AD4- +AD4- - if EP4 and EP3 are Bulk, the work better on High Speed and brake on -+AD4- +AD4- +AD4- Super Speed controllers. This adapter support my 64B packets and if we -+AD4- +AD4- +AD4- have more, fifo of this adapter will overrun. -+AD4- +AD4- +AD4- - Full Speed is currently unknown field for me, and it looks like it was -+AD4- +AD4- +AD4- never actually working properly. -+AD4- +AD4- But given that dongle seem to work fine with muted warning do you think it's -+AD4- +AD4- fine to continue that way or not? -+AD4- +AD4- -+AD4- +AD4- I mean if there's a chance this +ACI-bogus usb xfer+ACI- might affect something during -+AD4- +AD4- execution? Otherwise if that's just not a crucial problem or not a problem at all -+AD4- +AD4- may be we may just think how to make this warning not so annoying (in my case -+AD4- +AD4- I saw never ending flood of those warnings so that basically stopped me from using -+AD4- +AD4- the board after that warning started to appear. -+AD4- -+AD4- I'll answer with an example: -+AD4- on USB3 hw this warning was ignore and caused hard reproducible bug -+AD4- which cost me some week to debug. The result was a FIFO overflow on -+AD4- adapter side. +On Wed, 2016-07-06@12:32 +0200, fixed-term.Oleksij.Rempel wrote: +> +> On 06.07.2016 11:30, Alexey Brodkin wrote: +> > +> > 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. +> +> I'll answer with an example: +> on USB3 hw this warning was ignore and caused hard reproducible bug +> which cost me some week to debug. The result was a FIFO overflow on +> adapter side. Yeah that makes a perfect sense then. Let's see if there're any other suggestions on the topic. diff --git a/a/content_digest b/N1/content_digest index 54a2c1f..ad4a00e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -10,128 +10,128 @@ "ref\0577CCAB8.90003@de.bosch.com\0" "ref\01467797356.3086.48.camel@synopsys.com\0" "ref\0577CDE24.2030600@de.bosch.com\0" - "From\0Alexey Brodkin <Alexey.Brodkin@synopsys.com>\0" - "Subject\0[ath9k-devel] ath9k-htc on OHCI -> bogus usb xfer\0" + "From\0Alexey.Brodkin@synopsys.com (Alexey Brodkin)\0" + "Subject\0ath9k-htc on OHCI -> bogus usb xfer\0" "Date\0Thu, 7 Jul 2016 05:16:08 +0000\0" - "To\0ath9k-devel@lists.ath9k.org\0" + "To\0linux-snps-arc@lists.infradead.org\0" "\00:1\0" "b\0" - "Hi+AKA-Oleksij,\n" + "Hi?Oleksij,\n" "\n" - "On Wed, 2016-07-06 at 12:32 +-0200, fixed-term.Oleksij.Rempel wrote:\n" - "+AD4- \n" - "+AD4- On 06.07.2016 11:30, Alexey Brodkin wrote:\n" - "+AD4- +AD4- \n" - "+AD4- +AD4- Hi Oleksij,\n" - "+AD4- +AD4- \n" - "+AD4- +AD4- On Wed, 2016-07-06 at 11:09 +-0200, fixed-term.Oleksij.Rempel wrote:\n" - "+AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- On 06.07.2016 10:45, Alexey Brodkin wrote:\n" - "+AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- Hi Oleksij,\n" - "+AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- On Wed, 2016-07-06 at 10:38 +-0200, fixed-term.Oleksij.Rempel wrote:\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- On 06.07.2016 10:32, Alexey Brodkin wrote:\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Hi Oleksij,\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- On Wed, 2016-07-06 at 10:24 +-0200, fixed-term.Oleksij.Rempel wrote:\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AKA-\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Hm... this Endpoint should be Interrupt, not Bulk. If you search for\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- what did went wrong here? Is it not working in USB High Speed mode?\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Unfortunately as of now on that board EHCI doesn't work.\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- That's not a problem of a particular USB device but something in either\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- ECHI host controller or its integration. I do hope we will fix it sometime soon\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- (this is a development board and USB controller is implemented in FPGA so\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- there's a chance to fix stuff later on).\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- So given only OHCI works on the board I went forward and attempted to use it\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- with Wi-Fi USB dongle.\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- I did some tests for 2 years on OHCI controller on x86. There was no\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- noticable issues. It was even a bit faster then Intels EHCI. I don't\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- think OHCI alone is the source of this problem.\n" - "+AD4- +AD4- +AD4- +AD4- Well I was also surprised how well that dongle works with that board in\n" - "+AD4- +AD4- +AD4- +AD4- OHCI mode. I saw quite consistent +AH4-4-5 Mbit/second rates when doing Speedtest\n" - "+AD4- +AD4- +AD4- +AD4- from my smartphone. So IMHO it's completely usable. Especially on that kind of\n" - "+AD4- +AD4- +AD4- +AD4- HW which has main CPU running at just 100MHz.\n" - "+AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- On other side, so far i know, this adapter claims to provide usb full\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- speed support, (Not only high speed) and may use different usb\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- descriptor for this. May be this is the problem.\n" - "+AD4- +AD4- +AD4- +AD4- So is there something we may do with all that?\n" - "+AD4- +AD4- +AD4- Sure...\n" - "+AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- This shows that EP4 is Bluk in full speed mode. And it is defined by a\n" - "+AD4- +AD4- +AD4- boot loader of this chip:\n" - "+AD4- +AD4- +AD4- grep -R USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE +ACo-\n" - "+AD4- +AD4- +AD4- sboot/magpie+AF8-1+AF8-1/sboot/hif/usb/src/usb+AF8-table.c:\n" - "+AD4- +AD4- +AD4- m2BYTE(USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE, USB+AF8-FS+AF8-EP4+AF8-MAX+AF8-PACKET+AF8-SIZE),\n" - "+AD4- +AD4- +AD4- sboot/magpie+AF8-1+AF8-1/sboot/hif/usb/src/usb+AF8-table.h:+ACM-define\n" - "+AD4- +AD4- +AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK\n" - "+AD4- +AD4- +AD4- sboot/magpie+AF8-1+AF8-1/inc/usb+AF8-table.h:+ACM-define USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE\n" - "+AD4- +AD4- +AD4- +AKA-bUSB+AF8-EP+AF8-TYPE+AF8-BULK\n" - "+AD4- +AD4- +AD4- target+AF8-firmware/magpie+AF8-fw+AF8-dev/target/inc/k2/usb+AF8-table.h:+ACM-define\n" - "+AD4- +AD4- +AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK\n" - "+AD4- +AD4- +AD4- target+AF8-firmware/magpie+AF8-fw+AF8-dev/target/inc/magpie/usb+AF8-table.h:+ACM-define\n" - "+AD4- +AD4- +AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK\n" - "+AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- So, there are fallowing variants to fix it:\n" - "+AD4- +AD4- +AD4- a) patch full speed usb descriptor in firmware and add usb reinit\n" - "+AD4- +AD4- +AD4- support to the driver.\n" - "+AD4- +AD4- +AD4- b) add support of different EP4 types.\n" - "+AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- In any case, some one need to implement it... right now i have time only\n" - "+AD4- +AD4- +AD4- for mentoring.\n" - "+AD4- +AD4- That's understood.\n" - "+AD4- +AD4- \n" - "+AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- It is hard to say, which solution is better. It will affect performance\n" - "+AD4- +AD4- +AD4- and stability. We will need lots of testing on different HW variants to\n" - "+AD4- +AD4- +AD4- know it.\n" - "+AD4- +AD4- +AD4- May be usb maeling list can give some input here?\n" - "+AD4- +AD4- Let's hope so :)\n" - "+AD4- +AD4- \n" - "+AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- Currently we have fallowing issues:\n" - "+AD4- +AD4- +AD4- - if EP4 and EP3 are Interrupt, it works slower on High Speed controller.\n" - "+AD4- +AD4- +AD4- - if EP4 and EP3 are Bulk, the work better on High Speed and brake on\n" - "+AD4- +AD4- +AD4- Super Speed controllers. This adapter support my 64B packets and if we\n" - "+AD4- +AD4- +AD4- have more, fifo of this adapter will overrun.\n" - "+AD4- +AD4- +AD4- - Full Speed is currently unknown field for me, and it looks like it was\n" - "+AD4- +AD4- +AD4- never actually working properly.\n" - "+AD4- +AD4- But given that dongle seem to work fine with muted warning do you think it's\n" - "+AD4- +AD4- fine to continue that way or not?\n" - "+AD4- +AD4- \n" - "+AD4- +AD4- I mean if there's a chance this +ACI-bogus usb xfer+ACI- might affect something during\n" - "+AD4- +AD4- execution? Otherwise if that's just not a crucial problem or not a problem at all\n" - "+AD4- +AD4- may be we may just think how to make this warning not so annoying (in my case\n" - "+AD4- +AD4- I saw never ending flood of those warnings so that basically stopped me from using\n" - "+AD4- +AD4- the board after that warning started to appear.\n" - "+AD4-\n" - "+AD4- I'll answer with an example:\n" - "+AD4- on USB3 hw this warning was ignore and caused hard reproducible bug\n" - "+AD4- which cost me some week to debug. The result was a FIFO overflow on\n" - "+AD4- adapter side.\n" + "On Wed, 2016-07-06@12:32 +0200, fixed-term.Oleksij.Rempel wrote:\n" + "> \n" + "> On 06.07.2016 11:30, Alexey Brodkin wrote:\n" + "> > \n" + "> > Hi Oleksij,\n" + "> > \n" + "> > On Wed, 2016-07-06@11:09 +0200, fixed-term.Oleksij.Rempel wrote:\n" + "> > > \n" + "> > > \n" + "> > > On 06.07.2016 10:45, Alexey Brodkin wrote:\n" + "> > > > \n" + "> > > > \n" + "> > > > Hi Oleksij,\n" + "> > > > \n" + "> > > > On Wed, 2016-07-06@10:38 +0200, fixed-term.Oleksij.Rempel wrote:\n" + "> > > > > \n" + "> > > > > \n" + "> > > > > \n" + "> > > > > On 06.07.2016 10:32, Alexey Brodkin wrote:\n" + "> > > > > > \n" + "> > > > > > \n" + "> > > > > > \n" + "> > > > > > Hi Oleksij,\n" + "> > > > > > \n" + "> > > > > > On Wed, 2016-07-06@10:24 +0200, fixed-term.Oleksij.Rempel wrote:\n" + "> > > > > > > \n" + "> > > > > > > \n" + "> > > > > > > \n" + "> > > > > > > ?\n" + "> > > > > > > Hm... this Endpoint should be Interrupt, not Bulk. If you search for\n" + "> > > > > > > lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.\n" + "> > > > > > > \n" + "> > > > > > > what did went wrong here? Is it not working in USB High Speed mode?\n" + "> > > > > > Unfortunately as of now on that board EHCI doesn't work.\n" + "> > > > > > \n" + "> > > > > > That's not a problem of a particular USB device but something in either\n" + "> > > > > > ECHI host controller or its integration. I do hope we will fix it sometime soon\n" + "> > > > > > (this is a development board and USB controller is implemented in FPGA so\n" + "> > > > > > there's a chance to fix stuff later on).\n" + "> > > > > > \n" + "> > > > > > So given only OHCI works on the board I went forward and attempted to use it\n" + "> > > > > > with Wi-Fi USB dongle.\n" + "> > > > > I did some tests for 2 years on OHCI controller on x86. There was no\n" + "> > > > > noticable issues. It was even a bit faster then Intels EHCI. I don't\n" + "> > > > > think OHCI alone is the source of this problem.\n" + "> > > > Well I was also surprised how well that dongle works with that board in\n" + "> > > > OHCI mode. I saw quite consistent ~4-5 Mbit/second rates when doing Speedtest\n" + "> > > > from my smartphone. So IMHO it's completely usable. Especially on that kind of\n" + "> > > > HW which has main CPU running at just 100MHz.\n" + "> > > > \n" + "> > > > > \n" + "> > > > > \n" + "> > > > > On other side, so far i know, this adapter claims to provide usb full\n" + "> > > > > speed support, (Not only high speed) and may use different usb\n" + "> > > > > descriptor for this. May be this is the problem.\n" + "> > > > So is there something we may do with all that?\n" + "> > > Sure...\n" + "> > > \n" + "> > > This shows that EP4 is Bluk in full speed mode. And it is defined by a\n" + "> > > boot loader of this chip:\n" + "> > > grep -R USB_FS_EP4_ATTRIBUTE *\n" + "> > > sboot/magpie_1_1/sboot/hif/usb/src/usb_table.c:\n" + "> > > m2BYTE(USB_FS_EP4_ATTRIBUTE, USB_FS_EP4_MAX_PACKET_SIZE),\n" + "> > > sboot/magpie_1_1/sboot/hif/usb/src/usb_table.h:#define\n" + "> > > USB_FS_EP4_ATTRIBUTE????????????bUSB_EP_TYPE_BULK\n" + "> > > sboot/magpie_1_1/inc/usb_table.h:#define USB_FS_EP4_ATTRIBUTE\n" + "> > > ?bUSB_EP_TYPE_BULK\n" + "> > > target_firmware/magpie_fw_dev/target/inc/k2/usb_table.h:#define\n" + "> > > USB_FS_EP4_ATTRIBUTE????????????bUSB_EP_TYPE_BULK\n" + "> > > target_firmware/magpie_fw_dev/target/inc/magpie/usb_table.h:#define\n" + "> > > USB_FS_EP4_ATTRIBUTE????????????bUSB_EP_TYPE_BULK\n" + "> > > \n" + "> > > \n" + "> > > So, there are fallowing variants to fix it:\n" + "> > > a) patch full speed usb descriptor in firmware and add usb reinit\n" + "> > > support to the driver.\n" + "> > > b) add support of different EP4 types.\n" + "> > > \n" + "> > > In any case, some one need to implement it... right now i have time only\n" + "> > > for mentoring.\n" + "> > That's understood.\n" + "> > \n" + "> > > \n" + "> > > It is hard to say, which solution is better. It will affect performance\n" + "> > > and stability. We will need lots of testing on different HW variants to\n" + "> > > know it.\n" + "> > > May be usb maeling list can give some input here?\n" + "> > Let's hope so :)\n" + "> > \n" + "> > > \n" + "> > > Currently we have fallowing issues:\n" + "> > > - if EP4 and EP3 are Interrupt, it works slower on High Speed controller.\n" + "> > > - if EP4 and EP3 are Bulk, the work better on High Speed and brake on\n" + "> > > Super Speed controllers. This adapter support my 64B packets and if we\n" + "> > > have more, fifo of this adapter will overrun.\n" + "> > > - Full Speed is currently unknown field for me, and it looks like it was\n" + "> > > never actually working properly.\n" + "> > But given that dongle seem to work fine with muted warning do you think it's\n" + "> > fine to continue that way or not?\n" + "> > \n" + "> > I mean if there's a chance this \"bogus usb xfer\" might affect something during\n" + "> > execution? Otherwise if that's just not a crucial problem or not a problem at all\n" + "> > may be we may just think how to make this warning not so annoying (in my case\n" + "> > I saw never ending flood of those warnings so that basically stopped me from using\n" + "> > the board after that warning started to appear.\n" + ">\n" + "> I'll answer with an example:\n" + "> on USB3 hw this warning was ignore and caused hard reproducible bug\n" + "> which cost me some week to debug. The result was a FIFO overflow on\n" + "> adapter side.\n" "\n" "Yeah that makes a perfect sense then.\n" "Let's see if there're any other suggestions on the topic.\n" "\n" -Alexey -de060e6086d5cd0021faf624729013bf220a073befb5a54e95e81a10cb7ad35c +a02c03337e43318a8100793f44b59f78f025208c587ba6cd6feec40662bae6b8
diff --git a/a/1.txt b/N2/1.txt index 649fc11..354d639 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,115 +1,115 @@ -Hi+AKA-Oleksij, +Hi Oleksij, -On Wed, 2016-07-06 at 12:32 +-0200, fixed-term.Oleksij.Rempel wrote: -+AD4- -+AD4- On 06.07.2016 11:30, Alexey Brodkin wrote: -+AD4- +AD4- -+AD4- +AD4- Hi Oleksij, -+AD4- +AD4- -+AD4- +AD4- On Wed, 2016-07-06 at 11:09 +-0200, fixed-term.Oleksij.Rempel wrote: -+AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- On 06.07.2016 10:45, 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:38 +-0200, fixed-term.Oleksij.Rempel wrote: -+AD4- +AD4- +AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- +AD4- +AD4- -+AD4- +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- -+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Hi Oleksij, -+AD4- +AD4- +AD4- +AD4- +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- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AKA- -+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Hm... this Endpoint should be Interrupt, not Bulk. If you search for -+AD4- +AD4- +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- +AD4- +AD4- +AD4- +AD4- what did went wrong here? Is it not working in USB High Speed mode? -+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Unfortunately as of now on that board EHCI doesn't work. -+AD4- +AD4- +AD4- +AD4- +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- +AD4- +AD4- ECHI host controller or its integration. I do hope we will fix it sometime soon -+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- (this is a development board and USB controller is implemented in FPGA so -+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- there's a chance to fix stuff later on). -+AD4- +AD4- +AD4- +AD4- +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- +AD4- +AD4- with Wi-Fi USB dongle. -+AD4- +AD4- +AD4- +AD4- +AD4- I did some tests for 2 years on OHCI controller on x86. There was no -+AD4- +AD4- +AD4- +AD4- +AD4- noticable issues. It was even a bit faster then Intels EHCI. I don't -+AD4- +AD4- +AD4- +AD4- +AD4- think OHCI alone is the source of this problem. -+AD4- +AD4- +AD4- +AD4- Well I was also surprised how well that dongle works with that board in -+AD4- +AD4- +AD4- +AD4- OHCI mode. I saw quite consistent +AH4-4-5 Mbit/second rates when doing Speedtest -+AD4- +AD4- +AD4- +AD4- from my smartphone. So IMHO it's completely usable. Especially on that kind of -+AD4- +AD4- +AD4- +AD4- HW which has main CPU running at just 100MHz. -+AD4- +AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- +AD4- +AD4- -+AD4- +AD4- +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- +AD4- +AD4- speed support, (Not only high speed) and may use different usb -+AD4- +AD4- +AD4- +AD4- +AD4- descriptor for this. May be this is the problem. -+AD4- +AD4- +AD4- +AD4- So is there something we may do with all that? -+AD4- +AD4- +AD4- Sure... -+AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- This shows that EP4 is Bluk in full speed mode. And it is defined by a -+AD4- +AD4- +AD4- boot loader of this chip: -+AD4- +AD4- +AD4- grep -R USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE +ACo- -+AD4- +AD4- +AD4- sboot/magpie+AF8-1+AF8-1/sboot/hif/usb/src/usb+AF8-table.c: -+AD4- +AD4- +AD4- m2BYTE(USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE, USB+AF8-FS+AF8-EP4+AF8-MAX+AF8-PACKET+AF8-SIZE), -+AD4- +AD4- +AD4- sboot/magpie+AF8-1+AF8-1/sboot/hif/usb/src/usb+AF8-table.h:+ACM-define -+AD4- +AD4- +AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK -+AD4- +AD4- +AD4- sboot/magpie+AF8-1+AF8-1/inc/usb+AF8-table.h:+ACM-define USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE -+AD4- +AD4- +AD4- +AKA-bUSB+AF8-EP+AF8-TYPE+AF8-BULK -+AD4- +AD4- +AD4- target+AF8-firmware/magpie+AF8-fw+AF8-dev/target/inc/k2/usb+AF8-table.h:+ACM-define -+AD4- +AD4- +AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK -+AD4- +AD4- +AD4- target+AF8-firmware/magpie+AF8-fw+AF8-dev/target/inc/magpie/usb+AF8-table.h:+ACM-define -+AD4- +AD4- +AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK -+AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- So, there are fallowing variants to fix it: -+AD4- +AD4- +AD4- a) patch full speed usb descriptor in firmware and add usb reinit -+AD4- +AD4- +AD4- support to the driver. -+AD4- +AD4- +AD4- b) add support of different EP4 types. -+AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- In any case, some one need to implement it... right now i have time only -+AD4- +AD4- +AD4- for mentoring. -+AD4- +AD4- That's understood. -+AD4- +AD4- -+AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- It is hard to say, which solution is better. It will affect performance -+AD4- +AD4- +AD4- and stability. We will need lots of testing on different HW variants to -+AD4- +AD4- +AD4- know it. -+AD4- +AD4- +AD4- May be usb maeling list can give some input here? -+AD4- +AD4- Let's hope so :) -+AD4- +AD4- -+AD4- +AD4- +AD4- -+AD4- +AD4- +AD4- Currently we have fallowing issues: -+AD4- +AD4- +AD4- - if EP4 and EP3 are Interrupt, it works slower on High Speed controller. -+AD4- +AD4- +AD4- - if EP4 and EP3 are Bulk, the work better on High Speed and brake on -+AD4- +AD4- +AD4- Super Speed controllers. This adapter support my 64B packets and if we -+AD4- +AD4- +AD4- have more, fifo of this adapter will overrun. -+AD4- +AD4- +AD4- - Full Speed is currently unknown field for me, and it looks like it was -+AD4- +AD4- +AD4- never actually working properly. -+AD4- +AD4- But given that dongle seem to work fine with muted warning do you think it's -+AD4- +AD4- fine to continue that way or not? -+AD4- +AD4- -+AD4- +AD4- I mean if there's a chance this +ACI-bogus usb xfer+ACI- might affect something during -+AD4- +AD4- execution? Otherwise if that's just not a crucial problem or not a problem at all -+AD4- +AD4- may be we may just think how to make this warning not so annoying (in my case -+AD4- +AD4- I saw never ending flood of those warnings so that basically stopped me from using -+AD4- +AD4- the board after that warning started to appear. -+AD4- -+AD4- I'll answer with an example: -+AD4- on USB3 hw this warning was ignore and caused hard reproducible bug -+AD4- which cost me some week to debug. The result was a FIFO overflow on -+AD4- adapter side. +On Wed, 2016-07-06 at 12:32 +0200, fixed-term.Oleksij.Rempel wrote: +> +> On 06.07.2016 11:30, Alexey Brodkin wrote: +> > +> > 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. +> +> I'll answer with an example: +> on USB3 hw this warning was ignore and caused hard reproducible bug +> which cost me some week to debug. The result was a FIFO overflow on +> adapter side. Yeah that makes a perfect sense then. Let's see if there're any other suggestions on the topic. diff --git a/a/content_digest b/N2/content_digest index 54a2c1f..a825fa1 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -11,127 +11,133 @@ "ref\01467797356.3086.48.camel@synopsys.com\0" "ref\0577CDE24.2030600@de.bosch.com\0" "From\0Alexey Brodkin <Alexey.Brodkin@synopsys.com>\0" - "Subject\0[ath9k-devel] ath9k-htc on OHCI -> bogus usb xfer\0" + "Subject\0Re: ath9k-htc on OHCI -> bogus usb xfer\0" "Date\0Thu, 7 Jul 2016 05:16:08 +0000\0" - "To\0ath9k-devel@lists.ath9k.org\0" + "To\0fixed-term.Oleksij.Rempel@de.bosch.com <fixed-term.Oleksij.Rempel@de.bosch.com>\0" + "Cc\0linux-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>\0" "\00:1\0" "b\0" - "Hi+AKA-Oleksij,\n" + "Hi\302\240Oleksij,\n" "\n" - "On Wed, 2016-07-06 at 12:32 +-0200, fixed-term.Oleksij.Rempel wrote:\n" - "+AD4- \n" - "+AD4- On 06.07.2016 11:30, Alexey Brodkin wrote:\n" - "+AD4- +AD4- \n" - "+AD4- +AD4- Hi Oleksij,\n" - "+AD4- +AD4- \n" - "+AD4- +AD4- On Wed, 2016-07-06 at 11:09 +-0200, fixed-term.Oleksij.Rempel wrote:\n" - "+AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- On 06.07.2016 10:45, Alexey Brodkin wrote:\n" - "+AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- Hi Oleksij,\n" - "+AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- On Wed, 2016-07-06 at 10:38 +-0200, fixed-term.Oleksij.Rempel wrote:\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- On 06.07.2016 10:32, Alexey Brodkin wrote:\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Hi Oleksij,\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- On Wed, 2016-07-06 at 10:24 +-0200, fixed-term.Oleksij.Rempel wrote:\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AKA-\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Hm... this Endpoint should be Interrupt, not Bulk. If you search for\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- what did went wrong here? Is it not working in USB High Speed mode?\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Unfortunately as of now on that board EHCI doesn't work.\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- That's not a problem of a particular USB device but something in either\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- ECHI host controller or its integration. I do hope we will fix it sometime soon\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- (this is a development board and USB controller is implemented in FPGA so\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- there's a chance to fix stuff later on).\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- So given only OHCI works on the board I went forward and attempted to use it\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- with Wi-Fi USB dongle.\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- I did some tests for 2 years on OHCI controller on x86. There was no\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- noticable issues. It was even a bit faster then Intels EHCI. I don't\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- think OHCI alone is the source of this problem.\n" - "+AD4- +AD4- +AD4- +AD4- Well I was also surprised how well that dongle works with that board in\n" - "+AD4- +AD4- +AD4- +AD4- OHCI mode. I saw quite consistent +AH4-4-5 Mbit/second rates when doing Speedtest\n" - "+AD4- +AD4- +AD4- +AD4- from my smartphone. So IMHO it's completely usable. Especially on that kind of\n" - "+AD4- +AD4- +AD4- +AD4- HW which has main CPU running at just 100MHz.\n" - "+AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- +AD4- +AD4- On other side, so far i know, this adapter claims to provide usb full\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- speed support, (Not only high speed) and may use different usb\n" - "+AD4- +AD4- +AD4- +AD4- +AD4- descriptor for this. May be this is the problem.\n" - "+AD4- +AD4- +AD4- +AD4- So is there something we may do with all that?\n" - "+AD4- +AD4- +AD4- Sure...\n" - "+AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- This shows that EP4 is Bluk in full speed mode. And it is defined by a\n" - "+AD4- +AD4- +AD4- boot loader of this chip:\n" - "+AD4- +AD4- +AD4- grep -R USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE +ACo-\n" - "+AD4- +AD4- +AD4- sboot/magpie+AF8-1+AF8-1/sboot/hif/usb/src/usb+AF8-table.c:\n" - "+AD4- +AD4- +AD4- m2BYTE(USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE, USB+AF8-FS+AF8-EP4+AF8-MAX+AF8-PACKET+AF8-SIZE),\n" - "+AD4- +AD4- +AD4- sboot/magpie+AF8-1+AF8-1/sboot/hif/usb/src/usb+AF8-table.h:+ACM-define\n" - "+AD4- +AD4- +AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK\n" - "+AD4- +AD4- +AD4- sboot/magpie+AF8-1+AF8-1/inc/usb+AF8-table.h:+ACM-define USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE\n" - "+AD4- +AD4- +AD4- +AKA-bUSB+AF8-EP+AF8-TYPE+AF8-BULK\n" - "+AD4- +AD4- +AD4- target+AF8-firmware/magpie+AF8-fw+AF8-dev/target/inc/k2/usb+AF8-table.h:+ACM-define\n" - "+AD4- +AD4- +AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK\n" - "+AD4- +AD4- +AD4- target+AF8-firmware/magpie+AF8-fw+AF8-dev/target/inc/magpie/usb+AF8-table.h:+ACM-define\n" - "+AD4- +AD4- +AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK\n" - "+AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- So, there are fallowing variants to fix it:\n" - "+AD4- +AD4- +AD4- a) patch full speed usb descriptor in firmware and add usb reinit\n" - "+AD4- +AD4- +AD4- support to the driver.\n" - "+AD4- +AD4- +AD4- b) add support of different EP4 types.\n" - "+AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- In any case, some one need to implement it... right now i have time only\n" - "+AD4- +AD4- +AD4- for mentoring.\n" - "+AD4- +AD4- That's understood.\n" - "+AD4- +AD4- \n" - "+AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- It is hard to say, which solution is better. It will affect performance\n" - "+AD4- +AD4- +AD4- and stability. We will need lots of testing on different HW variants to\n" - "+AD4- +AD4- +AD4- know it.\n" - "+AD4- +AD4- +AD4- May be usb maeling list can give some input here?\n" - "+AD4- +AD4- Let's hope so :)\n" - "+AD4- +AD4- \n" - "+AD4- +AD4- +AD4- \n" - "+AD4- +AD4- +AD4- Currently we have fallowing issues:\n" - "+AD4- +AD4- +AD4- - if EP4 and EP3 are Interrupt, it works slower on High Speed controller.\n" - "+AD4- +AD4- +AD4- - if EP4 and EP3 are Bulk, the work better on High Speed and brake on\n" - "+AD4- +AD4- +AD4- Super Speed controllers. This adapter support my 64B packets and if we\n" - "+AD4- +AD4- +AD4- have more, fifo of this adapter will overrun.\n" - "+AD4- +AD4- +AD4- - Full Speed is currently unknown field for me, and it looks like it was\n" - "+AD4- +AD4- +AD4- never actually working properly.\n" - "+AD4- +AD4- But given that dongle seem to work fine with muted warning do you think it's\n" - "+AD4- +AD4- fine to continue that way or not?\n" - "+AD4- +AD4- \n" - "+AD4- +AD4- I mean if there's a chance this +ACI-bogus usb xfer+ACI- might affect something during\n" - "+AD4- +AD4- execution? Otherwise if that's just not a crucial problem or not a problem at all\n" - "+AD4- +AD4- may be we may just think how to make this warning not so annoying (in my case\n" - "+AD4- +AD4- I saw never ending flood of those warnings so that basically stopped me from using\n" - "+AD4- +AD4- the board after that warning started to appear.\n" - "+AD4-\n" - "+AD4- I'll answer with an example:\n" - "+AD4- on USB3 hw this warning was ignore and caused hard reproducible bug\n" - "+AD4- which cost me some week to debug. The result was a FIFO overflow on\n" - "+AD4- adapter side.\n" + "On Wed, 2016-07-06 at 12:32 +0200, fixed-term.Oleksij.Rempel wrote:\n" + "> \n" + "> On 06.07.2016 11:30, Alexey Brodkin wrote:\n" + "> > \n" + "> > Hi Oleksij,\n" + "> > \n" + "> > On Wed, 2016-07-06 at 11:09 +0200, fixed-term.Oleksij.Rempel wrote:\n" + "> > > \n" + "> > > \n" + "> > > On 06.07.2016 10:45, Alexey Brodkin wrote:\n" + "> > > > \n" + "> > > > \n" + "> > > > Hi Oleksij,\n" + "> > > > \n" + "> > > > On Wed, 2016-07-06 at 10:38 +0200, fixed-term.Oleksij.Rempel wrote:\n" + "> > > > > \n" + "> > > > > \n" + "> > > > > \n" + "> > > > > On 06.07.2016 10:32, Alexey Brodkin wrote:\n" + "> > > > > > \n" + "> > > > > > \n" + "> > > > > > \n" + "> > > > > > Hi Oleksij,\n" + "> > > > > > \n" + "> > > > > > On Wed, 2016-07-06 at 10:24 +0200, fixed-term.Oleksij.Rempel wrote:\n" + "> > > > > > > \n" + "> > > > > > > \n" + "> > > > > > > \n" + "> > > > > > > \302\240\n" + "> > > > > > > Hm... this Endpoint should be Interrupt, not Bulk. If you search for\n" + "> > > > > > > lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.\n" + "> > > > > > > \n" + "> > > > > > > what did went wrong here? Is it not working in USB High Speed mode?\n" + "> > > > > > Unfortunately as of now on that board EHCI doesn't work.\n" + "> > > > > > \n" + "> > > > > > That's not a problem of a particular USB device but something in either\n" + "> > > > > > ECHI host controller or its integration. I do hope we will fix it sometime soon\n" + "> > > > > > (this is a development board and USB controller is implemented in FPGA so\n" + "> > > > > > there's a chance to fix stuff later on).\n" + "> > > > > > \n" + "> > > > > > So given only OHCI works on the board I went forward and attempted to use it\n" + "> > > > > > with Wi-Fi USB dongle.\n" + "> > > > > I did some tests for 2 years on OHCI controller on x86. There was no\n" + "> > > > > noticable issues. It was even a bit faster then Intels EHCI. I don't\n" + "> > > > > think OHCI alone is the source of this problem.\n" + "> > > > Well I was also surprised how well that dongle works with that board in\n" + "> > > > OHCI mode. I saw quite consistent ~4-5 Mbit/second rates when doing Speedtest\n" + "> > > > from my smartphone. So IMHO it's completely usable. Especially on that kind of\n" + "> > > > HW which has main CPU running at just 100MHz.\n" + "> > > > \n" + "> > > > > \n" + "> > > > > \n" + "> > > > > On other side, so far i know, this adapter claims to provide usb full\n" + "> > > > > speed support, (Not only high speed) and may use different usb\n" + "> > > > > descriptor for this. May be this is the problem.\n" + "> > > > So is there something we may do with all that?\n" + "> > > Sure...\n" + "> > > \n" + "> > > This shows that EP4 is Bluk in full speed mode. And it is defined by a\n" + "> > > boot loader of this chip:\n" + "> > > grep -R USB_FS_EP4_ATTRIBUTE *\n" + "> > > sboot/magpie_1_1/sboot/hif/usb/src/usb_table.c:\n" + "> > > m2BYTE(USB_FS_EP4_ATTRIBUTE, USB_FS_EP4_MAX_PACKET_SIZE),\n" + "> > > sboot/magpie_1_1/sboot/hif/usb/src/usb_table.h:#define\n" + "> > > USB_FS_EP4_ATTRIBUTE\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240bUSB_EP_TYPE_BULK\n" + "> > > sboot/magpie_1_1/inc/usb_table.h:#define USB_FS_EP4_ATTRIBUTE\n" + "> > > \302\240bUSB_EP_TYPE_BULK\n" + "> > > target_firmware/magpie_fw_dev/target/inc/k2/usb_table.h:#define\n" + "> > > USB_FS_EP4_ATTRIBUTE\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240bUSB_EP_TYPE_BULK\n" + "> > > target_firmware/magpie_fw_dev/target/inc/magpie/usb_table.h:#define\n" + "> > > USB_FS_EP4_ATTRIBUTE\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240bUSB_EP_TYPE_BULK\n" + "> > > \n" + "> > > \n" + "> > > So, there are fallowing variants to fix it:\n" + "> > > a) patch full speed usb descriptor in firmware and add usb reinit\n" + "> > > support to the driver.\n" + "> > > b) add support of different EP4 types.\n" + "> > > \n" + "> > > In any case, some one need to implement it... right now i have time only\n" + "> > > for mentoring.\n" + "> > That's understood.\n" + "> > \n" + "> > > \n" + "> > > It is hard to say, which solution is better. It will affect performance\n" + "> > > and stability. We will need lots of testing on different HW variants to\n" + "> > > know it.\n" + "> > > May be usb maeling list can give some input here?\n" + "> > Let's hope so :)\n" + "> > \n" + "> > > \n" + "> > > Currently we have fallowing issues:\n" + "> > > - if EP4 and EP3 are Interrupt, it works slower on High Speed controller.\n" + "> > > - if EP4 and EP3 are Bulk, the work better on High Speed and brake on\n" + "> > > Super Speed controllers. This adapter support my 64B packets and if we\n" + "> > > have more, fifo of this adapter will overrun.\n" + "> > > - Full Speed is currently unknown field for me, and it looks like it was\n" + "> > > never actually working properly.\n" + "> > But given that dongle seem to work fine with muted warning do you think it's\n" + "> > fine to continue that way or not?\n" + "> > \n" + "> > I mean if there's a chance this \"bogus usb xfer\" might affect something during\n" + "> > execution? Otherwise if that's just not a crucial problem or not a problem at all\n" + "> > may be we may just think how to make this warning not so annoying (in my case\n" + "> > I saw never ending flood of those warnings so that basically stopped me from using\n" + "> > the board after that warning started to appear.\n" + ">\n" + "> I'll answer with an example:\n" + "> on USB3 hw this warning was ignore and caused hard reproducible bug\n" + "> which cost me some week to debug. The result was a FIFO overflow on\n" + "> adapter side.\n" "\n" "Yeah that makes a perfect sense then.\n" "Let's see if there're any other suggestions on the topic.\n" "\n" -Alexey -de060e6086d5cd0021faf624729013bf220a073befb5a54e95e81a10cb7ad35c +17d996cc3a025066159129ebd4368a00da77b1683773d86e174160e65de86ae3
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.