* musb: communication issue with more than 12 FTDI ports
@ 2015-10-12 9:34 Yegor Yefremov
[not found] ` <CAGm1_ku3d4q3jQ6ZZYaLktd182O_WY5Hvu-Z877N31e5wN2_NA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 13+ messages in thread
From: Yegor Yefremov @ 2015-10-12 9:34 UTC (permalink / raw)
To: linux-usb
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Felipe Balbi
We have a problem, when using more than 12 FTDI ports. Kernels tried:
3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz
Below the USB topology:
# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
|__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
|__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
|__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M
|__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M
When using 12 ports and performing serial test (a pair of ports is
connected via null-modem cable and a rather short string ca. 90
characters will be sent alternating at 1200 and 115200b/s, testing
scripts are written in Python and running as own processes per a pair
of ports) there are no timeouts, i.e. all sent characters will be
received. As soon as I open ports 13 and 14 I start to get arbitrary
timeouts (from test software point of view) on all ports.
In order to check, if ftdi_sio has primary to do with this issue, I've
performed the same test on a PC and PandaBoard Rev. A2 (EHCI port) and
there were no issues with 16 ports. So it seems to have something to
do with am335x + musb + number of end points.
Any idea? Let me know, if you need our test script.
Yegor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread[parent not found: <CAGm1_ku3d4q3jQ6ZZYaLktd182O_WY5Hvu-Z877N31e5wN2_NA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: musb: communication issue with more than 12 FTDI ports [not found] ` <CAGm1_ku3d4q3jQ6ZZYaLktd182O_WY5Hvu-Z877N31e5wN2_NA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2015-10-12 10:34 ` Yegor Yefremov [not found] ` <CAGm1_kvwLu=4R1G8+bXEhmU4298B-+XGKQRaOjZOz15eU1StFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Yegor Yefremov @ 2015-10-12 10:34 UTC (permalink / raw) To: linux-usb Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Felipe Balbi On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: > We have a problem, when using more than 12 FTDI ports. Kernels tried: > 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz > > Below the USB topology: > > # lsusb -t > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M > |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M > |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M > |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M > |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M > |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M > |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M > |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M > |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M > |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M > |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M > |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M > |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M > |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M > |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M > |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M > |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M > |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M > |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M > |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M > > When using 12 ports and performing serial test (a pair of ports is > connected via null-modem cable and a rather short string ca. 90 > characters will be sent alternating at 1200 and 115200b/s, testing > scripts are written in Python and running as own processes per a pair > of ports) there are no timeouts, i.e. all sent characters will be > received. As soon as I open ports 13 and 14 I start to get arbitrary > timeouts (from test software point of view) on all ports. > > In order to check, if ftdi_sio has primary to do with this issue, I've > performed the same test on a PC and PandaBoard Rev. A2 (EHCI port) and > there were no issues with 16 ports. So it seems to have something to > do with am335x + musb + number of end points. > > Any idea? Let me know, if you need our test script. >From time to time I get following warnings (4.3.0-rc5): musb_host_rx 1915: RX1 dma busy, csr 2020 musb_host_rx 1915: RX4 dma busy, csr 2020 musb_host_rx 1915: RX7 dma busy, csr 2220 musb_host_rx 1915: RX1 dma busy, csr 2020 Though they are not timely related to serial test timeouts. Yegor -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <CAGm1_kvwLu=4R1G8+bXEhmU4298B-+XGKQRaOjZOz15eU1StFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* RE: musb: communication issue with more than 12 FTDI ports [not found] ` <CAGm1_kvwLu=4R1G8+bXEhmU4298B-+XGKQRaOjZOz15eU1StFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2015-10-12 13:33 ` Konstantin Shkolnyy 2015-10-13 18:22 ` Felipe Balbi 1 sibling, 0 replies; 13+ messages in thread From: Konstantin Shkolnyy @ 2015-10-12 13:33 UTC (permalink / raw) To: Yegor Yefremov, linux-usb Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Felipe Balbi [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3561 bytes --] Some host controllers just can't support so many pipes opened at once. Check what the SoC spec says about that. -----Original Message----- From: linux-usb-owner@vger.kernel.org [mailto:linux-usb-owner@vger.kernel.org] On Behalf Of Yegor Yefremov Sent: Monday, October 12, 2015 05:35 To: linux-usb Cc: linux-omap@vger.kernel.org; Felipe Balbi Subject: Re: musb: communication issue with more than 12 FTDI ports On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov <yegorslists@googlemail.com> wrote: > We have a problem, when using more than 12 FTDI ports. Kernels tried: > 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz > > Below the USB topology: > > # lsusb -t > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M > |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M > |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M > |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M > |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M > |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M > |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M > |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M > |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M > |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M > |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M > |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M > |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M > |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M > |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M > |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M > |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M > |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M > |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M > |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M > > When using 12 ports and performing serial test (a pair of ports is > connected via null-modem cable and a rather short string ca. 90 > characters will be sent alternating at 1200 and 115200b/s, testing > scripts are written in Python and running as own processes per a pair > of ports) there are no timeouts, i.e. all sent characters will be > received. As soon as I open ports 13 and 14 I start to get arbitrary > timeouts (from test software point of view) on all ports. > > In order to check, if ftdi_sio has primary to do with this issue, I've > performed the same test on a PC and PandaBoard Rev. A2 (EHCI port) and > there were no issues with 16 ports. So it seems to have something to > do with am335x + musb + number of end points. > > Any idea? Let me know, if you need our test script. From time to time I get following warnings (4.3.0-rc5): musb_host_rx 1915: RX1 dma busy, csr 2020 musb_host_rx 1915: RX4 dma busy, csr 2020 musb_host_rx 1915: RX7 dma busy, csr 2220 musb_host_rx 1915: RX1 dma busy, csr 2020 Though they are not timely related to serial test timeouts. Yegor -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±ºÆâžØ^n‡r¡ö¦zË\x1aëh™¨èÚ&¢îý»\x05ËÛÔØï¦v¬Îf\x1dp)¹¹br šê+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹\x1e®w¥¢¸?™¨èÚ&¢)ߢ^[f ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: musb: communication issue with more than 12 FTDI ports [not found] ` <CAGm1_kvwLu=4R1G8+bXEhmU4298B-+XGKQRaOjZOz15eU1StFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-10-12 13:33 ` Konstantin Shkolnyy @ 2015-10-13 18:22 ` Felipe Balbi [not found] ` <87r3kyd3xw.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org> 1 sibling, 1 reply; 13+ messages in thread From: Felipe Balbi @ 2015-10-13 18:22 UTC (permalink / raw) To: Yegor Yefremov, linux-usb Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, b-liu-l0cyMroinI0 [-- Attachment #1: Type: text/plain, Size: 3252 bytes --] Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes: > On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov > <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >> We have a problem, when using more than 12 FTDI ports. Kernels tried: >> 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz >> >> Below the USB topology: >> >> # lsusb -t >> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M >> |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M >> |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M >> |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M >> |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M >> |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M >> |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M >> |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M >> |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M >> |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M >> |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M >> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M >> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M >> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M >> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M >> |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M >> |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M >> |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M >> |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M >> >> When using 12 ports and performing serial test (a pair of ports is >> connected via null-modem cable and a rather short string ca. 90 >> characters will be sent alternating at 1200 and 115200b/s, testing >> scripts are written in Python and running as own processes per a pair >> of ports) there are no timeouts, i.e. all sent characters will be >> received. As soon as I open ports 13 and 14 I start to get arbitrary >> timeouts (from test software point of view) on all ports. >> >> In order to check, if ftdi_sio has primary to do with this issue, I've >> performed the same test on a PC and PandaBoard Rev. A2 (EHCI port) and >> there were no issues with 16 ports. So it seems to have something to >> do with am335x + musb + number of end points. >> >> Any idea? Let me know, if you need our test script. > > From time to time I get following warnings (4.3.0-rc5): > > musb_host_rx 1915: RX1 dma busy, csr 2020 > musb_host_rx 1915: RX4 dma busy, csr 2020 > musb_host_rx 1915: RX7 dma busy, csr 2220 > musb_host_rx 1915: RX1 dma busy, csr 2020 > > Though they are not timely related to serial test timeouts. yeah, I don't think MUSB can easily handle that. IIRC, endpoint scheduling in MUSB is rather bad. While we have enough endpoints to handle this case, you might be running into some IP (or driver) issues. Bin, have you ever tested this many serial devices on AM335x ? -- balbi [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <87r3kyd3xw.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org>]
* Re: musb: communication issue with more than 12 FTDI ports [not found] ` <87r3kyd3xw.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org> @ 2015-10-14 15:35 ` Bin Liu [not found] ` <561E7639.40506-l0cyMroinI0@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Bin Liu @ 2015-10-14 15:35 UTC (permalink / raw) To: Felipe Balbi, Yegor Yefremov, linux-usb Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Hi, On 10/13/2015 01:22 PM, Felipe Balbi wrote: > Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes: >> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov >> <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >>> We have a problem, when using more than 12 FTDI ports. Kernels tried: >>> 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz >>> >>> Below the USB topology: >>> >>> # lsusb -t >>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M >>> |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M >>> |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M >>> |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M >>> |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M >>> |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M >>> |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M >>> |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M >>> |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M >>> |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M >>> |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M >>> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M >>> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M >>> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M >>> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M >>> |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M >>> |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M >>> |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M >>> |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M How many EPs does each FTDI device require? at least one INT EP, right? If I read it right, the topology above has 2 hubs, and 16 high-speed FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP configuration used by default. I am wondering how those devices got enumerated properly. >>> >>> When using 12 ports and performing serial test (a pair of ports is >>> connected via null-modem cable and a rather short string ca. 90 >>> characters will be sent alternating at 1200 and 115200b/s, testing >>> scripts are written in Python and running as own processes per a pair >>> of ports) there are no timeouts, i.e. all sent characters will be >>> received. As soon as I open ports 13 and 14 I start to get arbitrary >>> timeouts (from test software point of view) on all ports. >>> >>> In order to check, if ftdi_sio has primary to do with this issue, I've >>> performed the same test on a PC and PandaBoard Rev. A2 (EHCI port) and >>> there were no issues with 16 ports. So it seems to have something to >>> do with am335x + musb + number of end points. >>> >>> Any idea? Let me know, if you need our test script. >> >> From time to time I get following warnings (4.3.0-rc5): >> >> musb_host_rx 1915: RX1 dma busy, csr 2020 >> musb_host_rx 1915: RX4 dma busy, csr 2020 >> musb_host_rx 1915: RX7 dma busy, csr 2220 >> musb_host_rx 1915: RX1 dma busy, csr 2020 >> >> Though they are not timely related to serial test timeouts. > > yeah, I don't think MUSB can easily handle that. IIRC, endpoint > scheduling in MUSB is rather bad. While we have enough endpoints to > handle this case, you might be running into some IP (or driver) issues. > > Bin, have you ever tested this many serial devices on AM335x ? No, I never tested this many devices. It could be resource limitation, but the log above is about CPPI, so I recommend to test with CPPI disabled to isolate if this is MUSB issue or CPPI. Regards, -Bin. > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <561E7639.40506-l0cyMroinI0@public.gmane.org>]
* Re: musb: communication issue with more than 12 FTDI ports [not found] ` <561E7639.40506-l0cyMroinI0@public.gmane.org> @ 2015-10-14 15:56 ` Felipe Balbi [not found] ` <87h9ltbg0i.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Felipe Balbi @ 2015-10-14 15:56 UTC (permalink / raw) To: Bin Liu, Yegor Yefremov, linux-usb Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [-- Attachment #1: Type: text/plain, Size: 2492 bytes --] Hi, Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: > Hi, > > On 10/13/2015 01:22 PM, Felipe Balbi wrote: >> Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes: >>> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov >>> <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >>>> We have a problem, when using more than 12 FTDI ports. Kernels tried: >>>> 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz >>>> >>>> Below the USB topology: >>>> >>>> # lsusb -t >>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>>> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M >>>> |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M >>>> |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M >>>> |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M >>>> |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M >>>> |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M >>>> |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M >>>> |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M >>>> |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M >>>> |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M >>>> |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M >>>> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M >>>> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M >>>> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M >>>> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M >>>> |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M >>>> |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M >>>> |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M >>>> |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M > > How many EPs does each FTDI device require? at least one INT EP, right? > If I read it right, the topology above has 2 hubs, and 16 high-speed > FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT > EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP > configuration used by default. I am wondering how those devices got > enumerated properly. dynamic EP allocation, but that has its own limitations. -- balbi [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <87h9ltbg0i.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org>]
* Re: musb: communication issue with more than 12 FTDI ports [not found] ` <87h9ltbg0i.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org> @ 2015-10-14 15:57 ` Bin Liu [not found] ` <561E7B6D.80605-l0cyMroinI0@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Bin Liu @ 2015-10-14 15:57 UTC (permalink / raw) To: Felipe Balbi, Yegor Yefremov, linux-usb Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On 10/14/2015 10:56 AM, Felipe Balbi wrote: > > Hi, > > Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: >> Hi, >> >> On 10/13/2015 01:22 PM, Felipe Balbi wrote: >>> Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes: >>>> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov >>>> <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >>>>> We have a problem, when using more than 12 FTDI ports. Kernels tried: >>>>> 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz >>>>> >>>>> Below the USB topology: >>>>> >>>>> # lsusb -t >>>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>>>> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M >>>>> |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M >>>>> |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M >>>>> |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M >>>>> |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M >>>>> |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M >>>>> |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M >>>>> |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M >>>>> |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M >>>>> |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M >>>>> |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M >>>>> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M >>>>> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M >>>>> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M >>>>> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M >>>>> |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M >>>>> |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M >>>>> |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M >>>>> |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M >> >> How many EPs does each FTDI device require? at least one INT EP, right? >> If I read it right, the topology above has 2 hubs, and 16 high-speed >> FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT >> EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP >> configuration used by default. I am wondering how those devices got >> enumerated properly. > > dynamic EP allocation, but that has its own limitations. > MUSB does not support dynamic EP allocation for INT/ISOCH. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <561E7B6D.80605-l0cyMroinI0@public.gmane.org>]
* Re: musb: communication issue with more than 12 FTDI ports [not found] ` <561E7B6D.80605-l0cyMroinI0@public.gmane.org> @ 2015-10-14 16:25 ` Felipe Balbi [not found] ` <87eggxbeou.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Felipe Balbi @ 2015-10-14 16:25 UTC (permalink / raw) To: Bin Liu, Yegor Yefremov, linux-usb Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [-- Attachment #1: Type: text/plain, Size: 2900 bytes --] Hi, Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: > On 10/14/2015 10:56 AM, Felipe Balbi wrote: >> >> Hi, >> >> Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: >>> Hi, >>> >>> On 10/13/2015 01:22 PM, Felipe Balbi wrote: >>>> Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes: >>>>> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov >>>>> <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >>>>>> We have a problem, when using more than 12 FTDI ports. Kernels tried: >>>>>> 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz >>>>>> >>>>>> Below the USB topology: >>>>>> >>>>>> # lsusb -t >>>>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>>>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>>>>> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M >>>>>> |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M >>>>>> |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M >>>>>> |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M >>>>>> |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M >>>>>> |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M >>>>>> |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M >>>>>> |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M >>>>>> |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M >>>>>> |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M >>>>>> |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M >>>>>> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M >>>>>> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M >>>>>> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M >>>>>> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M >>>>>> |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M >>>>>> |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M >>>>>> |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M >>>>>> |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M >>> >>> How many EPs does each FTDI device require? at least one INT EP, right? >>> If I read it right, the topology above has 2 hubs, and 16 high-speed >>> FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT >>> EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP >>> configuration used by default. I am wondering how those devices got >>> enumerated properly. >> >> dynamic EP allocation, but that has its own limitations. >> > MUSB does not support dynamic EP allocation for INT/ISOCH. I remember isoc doesn't, not sure about int. Do you remember where that part of the code is off the top of your head ? -- balbi [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <87eggxbeou.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org>]
* Re: musb: communication issue with more than 12 FTDI ports [not found] ` <87eggxbeou.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org> @ 2015-10-14 16:41 ` Bin Liu [not found] ` <561E85D4.4040208-l0cyMroinI0@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Bin Liu @ 2015-10-14 16:41 UTC (permalink / raw) To: Felipe Balbi, Yegor Yefremov, linux-usb Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Felipe, On 10/14/2015 11:25 AM, Felipe Balbi wrote: > > Hi, > > Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: >> On 10/14/2015 10:56 AM, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: >>>> Hi, >>>> >>>> On 10/13/2015 01:22 PM, Felipe Balbi wrote: >>>>> Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes: >>>>>> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov >>>>>> <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >>>>>>> We have a problem, when using more than 12 FTDI ports. Kernels tried: >>>>>>> 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz >>>>>>> >>>>>>> Below the USB topology: >>>>>>> >>>>>>> # lsusb -t >>>>>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>>>>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>>>>>> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M >>>>>>> |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M >>>>>>> |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M >>>>>>> |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>> |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>> |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>> |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>> |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>> |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>> |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>> |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>> |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>> |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>> |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>> |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M >>>> >>>> How many EPs does each FTDI device require? at least one INT EP, right? >>>> If I read it right, the topology above has 2 hubs, and 16 high-speed >>>> FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT >>>> EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP >>>> configuration used by default. I am wondering how those devices got >>>> enumerated properly. >>> >>> dynamic EP allocation, but that has its own limitations. >>> >> MUSB does not support dynamic EP allocation for INT/ISOCH. > > I remember isoc doesn't, not sure about int. Do you remember where that > part of the code is off the top of your head ? > The MUSB EP allocation is in musb_schedule() in musb_host.c. It does not have specific policy for INT/ISOCH, but the issue is that for periodic EP, it got allocated during device enumeration but freed only when the device is disconnected. So practically there is no dynamic EP allocation for INT/ISOCH. Regards, -Bin. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <561E85D4.4040208-l0cyMroinI0@public.gmane.org>]
* Re: musb: communication issue with more than 12 FTDI ports [not found] ` <561E85D4.4040208-l0cyMroinI0@public.gmane.org> @ 2015-10-14 17:05 ` Felipe Balbi [not found] ` <87bnc1bcu1.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Felipe Balbi @ 2015-10-14 17:05 UTC (permalink / raw) To: Bin Liu, Yegor Yefremov, linux-usb Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [-- Attachment #1: Type: text/plain, Size: 6896 bytes --] Hi, Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: > Felipe, > > On 10/14/2015 11:25 AM, Felipe Balbi wrote: >> >> Hi, >> >> Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: >>> On 10/14/2015 10:56 AM, Felipe Balbi wrote: >>>> >>>> Hi, >>>> >>>> Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: >>>>> Hi, >>>>> >>>>> On 10/13/2015 01:22 PM, Felipe Balbi wrote: >>>>>> Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes: >>>>>>> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov >>>>>>> <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >>>>>>>> We have a problem, when using more than 12 FTDI ports. Kernels tried: >>>>>>>> 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz >>>>>>>> >>>>>>>> Below the USB topology: >>>>>>>> >>>>>>>> # lsusb -t >>>>>>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>>>>>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>>>>>>> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M >>>>>>>> |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M >>>>>>>> |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M >>>>>>>> |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>>> |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>>> |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>>> |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>>> |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>>> |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>>> |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>>> |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>>> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>>> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>>> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>>> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>>> |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>>> |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>>> |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>>> |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M >>>>> >>>>> How many EPs does each FTDI device require? at least one INT EP, right? >>>>> If I read it right, the topology above has 2 hubs, and 16 high-speed >>>>> FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT >>>>> EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP >>>>> configuration used by default. I am wondering how those devices got >>>>> enumerated properly. >>>> >>>> dynamic EP allocation, but that has its own limitations. >>>> >>> MUSB does not support dynamic EP allocation for INT/ISOCH. >> >> I remember isoc doesn't, not sure about int. Do you remember where that >> part of the code is off the top of your head ? >> > > The MUSB EP allocation is in musb_schedule() in musb_host.c. > > It does not have specific policy for INT/ISOCH, but the issue is that > for periodic EP, it got allocated during device enumeration but freed > only when the device is disconnected. So practically there is no dynamic > EP allocation for INT/ISOCH. This is not exactly what I can see when trying things out: minicom.cap:56:[ 90.909917] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 minicom.cap:66:[ 91.175860] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 minicom.cap:100:[ 91.697827] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 minicom.cap:106:[ 91.818066] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 minicom.cap:149:[ 92.475792] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 minicom.cap:162:[ 92.736808] musb-hdrc musb-hdrc.1.auto: qh dc07d5c0 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 minicom.cap:207:[ 93.703046] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 minicom.cap:215:[ 93.977574] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 minicom.cap:240:[ 94.388472] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 minicom.cap:289:[ 95.422325] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 minicom.cap:305:[ 95.688207] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 minicom.cap:335:[ 96.291453] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 minicom.cap:410:[ 97.696976] musb-hdrc musb-hdrc.1.auto: qh df6b70c0 urb dc011f40 dev11 ep1in-intr, hw_ep 2, dd842080/8 minicom.cap:56:[ 90.909917] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 minicom.cap:66:[ 91.175860] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 minicom.cap:100:[ 91.697827] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 minicom.cap:106:[ 91.818066] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 minicom.cap:149:[ 92.475792] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 minicom.cap:162:[ 92.736808] musb-hdrc musb-hdrc.1.auto: qh dc07d5c0 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 minicom.cap:207:[ 93.703046] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 minicom.cap:215:[ 93.977574] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 minicom.cap:240:[ 94.388472] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 minicom.cap:289:[ 95.422325] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 minicom.cap:305:[ 95.688207] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 minicom.cap:335:[ 96.291453] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 minicom.cap:410:[ 97.696976] musb-hdrc musb-hdrc.1.auto: qh df6b70c0 urb dc011f40 dev11 ep1in-intr, hw_ep 2, dd842080/8 Note how the same ep1in-intr was used with different devices and different hw_eps. OTOH, within the same device, hw_ep was constant. Hmmm... -- balbi [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <87bnc1bcu1.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org>]
* Re: musb: communication issue with more than 12 FTDI ports [not found] ` <87bnc1bcu1.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org> @ 2015-10-14 17:09 ` Bin Liu [not found] ` <561E8C4E.1020602-l0cyMroinI0@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Bin Liu @ 2015-10-14 17:09 UTC (permalink / raw) To: Felipe Balbi, Yegor Yefremov, linux-usb Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On 10/14/2015 12:05 PM, Felipe Balbi wrote: > > Hi, > > Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: >> Felipe, >> >> On 10/14/2015 11:25 AM, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: >>>> On 10/14/2015 10:56 AM, Felipe Balbi wrote: >>>>> >>>>> Hi, >>>>> >>>>> Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: >>>>>> Hi, >>>>>> >>>>>> On 10/13/2015 01:22 PM, Felipe Balbi wrote: >>>>>>> Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes: >>>>>>>> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov >>>>>>>> <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >>>>>>>>> We have a problem, when using more than 12 FTDI ports. Kernels tried: >>>>>>>>> 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz >>>>>>>>> >>>>>>>>> Below the USB topology: >>>>>>>>> >>>>>>>>> # lsusb -t >>>>>>>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>>>>>>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>>>>>>>> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M >>>>>>>>> |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M >>>>>>>>> |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M >>>>>>>>> |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>>>> |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>>>> |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>>>> |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>>>> |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>>>> |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>>>> |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>>>> |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>>>> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>>>> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>>>> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>>>> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>>>> |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>>>> |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>>>> |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>>>> |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M >>>>>> >>>>>> How many EPs does each FTDI device require? at least one INT EP, right? >>>>>> If I read it right, the topology above has 2 hubs, and 16 high-speed >>>>>> FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT >>>>>> EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP >>>>>> configuration used by default. I am wondering how those devices got >>>>>> enumerated properly. >>>>> >>>>> dynamic EP allocation, but that has its own limitations. >>>>> >>>> MUSB does not support dynamic EP allocation for INT/ISOCH. >>> >>> I remember isoc doesn't, not sure about int. Do you remember where that >>> part of the code is off the top of your head ? >>> >> >> The MUSB EP allocation is in musb_schedule() in musb_host.c. >> >> It does not have specific policy for INT/ISOCH, but the issue is that >> for periodic EP, it got allocated during device enumeration but freed >> only when the device is disconnected. So practically there is no dynamic >> EP allocation for INT/ISOCH. > > This is not exactly what I can see when trying things out: > > minicom.cap:56:[ 90.909917] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 > minicom.cap:66:[ 91.175860] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 > minicom.cap:100:[ 91.697827] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 > minicom.cap:106:[ 91.818066] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 > minicom.cap:149:[ 92.475792] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 > minicom.cap:162:[ 92.736808] musb-hdrc musb-hdrc.1.auto: qh dc07d5c0 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 > minicom.cap:207:[ 93.703046] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 > minicom.cap:215:[ 93.977574] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 > minicom.cap:240:[ 94.388472] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 > minicom.cap:289:[ 95.422325] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 > minicom.cap:305:[ 95.688207] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 > minicom.cap:335:[ 96.291453] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 > minicom.cap:410:[ 97.696976] musb-hdrc musb-hdrc.1.auto: qh df6b70c0 urb dc011f40 dev11 ep1in-intr, hw_ep 2, dd842080/8 > minicom.cap:56:[ 90.909917] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 > minicom.cap:66:[ 91.175860] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 > minicom.cap:100:[ 91.697827] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 > minicom.cap:106:[ 91.818066] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 > minicom.cap:149:[ 92.475792] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 > minicom.cap:162:[ 92.736808] musb-hdrc musb-hdrc.1.auto: qh dc07d5c0 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 > minicom.cap:207:[ 93.703046] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 > minicom.cap:215:[ 93.977574] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 > minicom.cap:240:[ 94.388472] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 > minicom.cap:289:[ 95.422325] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 > minicom.cap:305:[ 95.688207] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 > minicom.cap:335:[ 96.291453] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 > minicom.cap:410:[ 97.696976] musb-hdrc musb-hdrc.1.auto: qh df6b70c0 urb dc011f40 dev11 ep1in-intr, hw_ep 2, dd842080/8 > > Note how the same ep1in-intr was used with different devices and > different hw_eps. OTOH, within the same device, hw_ep was Maybe I am wrong, but ep1in-intr is the EP reference to the device EP, while hw_ep is the reference to MUSB host EP. > constant. Hmmm... My understanding here is that a dedicated MUSB EP is allocated permanently for each device. > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <561E8C4E.1020602-l0cyMroinI0@public.gmane.org>]
* Re: musb: communication issue with more than 12 FTDI ports [not found] ` <561E8C4E.1020602-l0cyMroinI0@public.gmane.org> @ 2015-10-14 17:19 ` Felipe Balbi [not found] ` <874mhtbc63.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Felipe Balbi @ 2015-10-14 17:19 UTC (permalink / raw) To: Bin Liu, Yegor Yefremov, linux-usb Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [-- Attachment #1: Type: text/plain, Size: 7820 bytes --] Hi, Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: > On 10/14/2015 12:05 PM, Felipe Balbi wrote: >> >> Hi, >> >> Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: >>> Felipe, >>> >>> On 10/14/2015 11:25 AM, Felipe Balbi wrote: >>>> >>>> Hi, >>>> >>>> Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: >>>>> On 10/14/2015 10:56 AM, Felipe Balbi wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: >>>>>>> Hi, >>>>>>> >>>>>>> On 10/13/2015 01:22 PM, Felipe Balbi wrote: >>>>>>>> Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes: >>>>>>>>> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov >>>>>>>>> <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >>>>>>>>>> We have a problem, when using more than 12 FTDI ports. Kernels tried: >>>>>>>>>> 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz >>>>>>>>>> >>>>>>>>>> Below the USB topology: >>>>>>>>>> >>>>>>>>>> # lsusb -t >>>>>>>>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>>>>>>>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>>>>>>>>> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M >>>>>>>>>> |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M >>>>>>>>>> |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M >>>>>>>>>> |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>>>>> |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>>>>> |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>>>>> |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>>>>> |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>>>>> |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>>>>> |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>>>>> |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>>>>> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>>>>> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>>>>> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>>>>> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>>>>> |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>>>>> |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>>>>> |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>>>>> |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>> >>>>>>> How many EPs does each FTDI device require? at least one INT EP, right? >>>>>>> If I read it right, the topology above has 2 hubs, and 16 high-speed >>>>>>> FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT >>>>>>> EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP >>>>>>> configuration used by default. I am wondering how those devices got >>>>>>> enumerated properly. >>>>>> >>>>>> dynamic EP allocation, but that has its own limitations. >>>>>> >>>>> MUSB does not support dynamic EP allocation for INT/ISOCH. >>>> >>>> I remember isoc doesn't, not sure about int. Do you remember where that >>>> part of the code is off the top of your head ? >>>> >>> >>> The MUSB EP allocation is in musb_schedule() in musb_host.c. >>> >>> It does not have specific policy for INT/ISOCH, but the issue is that >>> for periodic EP, it got allocated during device enumeration but freed >>> only when the device is disconnected. So practically there is no dynamic >>> EP allocation for INT/ISOCH. >> >> This is not exactly what I can see when trying things out: >> >> minicom.cap:56:[ 90.909917] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >> minicom.cap:66:[ 91.175860] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >> minicom.cap:100:[ 91.697827] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >> minicom.cap:106:[ 91.818066] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 >> minicom.cap:149:[ 92.475792] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >> minicom.cap:162:[ 92.736808] musb-hdrc musb-hdrc.1.auto: qh dc07d5c0 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >> minicom.cap:207:[ 93.703046] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 >> minicom.cap:215:[ 93.977574] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 >> minicom.cap:240:[ 94.388472] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 >> minicom.cap:289:[ 95.422325] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 >> minicom.cap:305:[ 95.688207] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 >> minicom.cap:335:[ 96.291453] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 >> minicom.cap:410:[ 97.696976] musb-hdrc musb-hdrc.1.auto: qh df6b70c0 urb dc011f40 dev11 ep1in-intr, hw_ep 2, dd842080/8 >> minicom.cap:56:[ 90.909917] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >> minicom.cap:66:[ 91.175860] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >> minicom.cap:100:[ 91.697827] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >> minicom.cap:106:[ 91.818066] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 >> minicom.cap:149:[ 92.475792] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >> minicom.cap:162:[ 92.736808] musb-hdrc musb-hdrc.1.auto: qh dc07d5c0 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >> minicom.cap:207:[ 93.703046] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 >> minicom.cap:215:[ 93.977574] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 >> minicom.cap:240:[ 94.388472] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 >> minicom.cap:289:[ 95.422325] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 >> minicom.cap:305:[ 95.688207] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 >> minicom.cap:335:[ 96.291453] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 >> minicom.cap:410:[ 97.696976] musb-hdrc musb-hdrc.1.auto: qh df6b70c0 urb dc011f40 dev11 ep1in-intr, hw_ep 2, dd842080/8 >> >> Note how the same ep1in-intr was used with different devices and >> different hw_eps. OTOH, within the same device, hw_ep was > > Maybe I am wrong, but ep1in-intr is the EP reference to the device EP, > while hw_ep is the reference to MUSB host EP. We can't really know which EP the device side is using, right ? :-) The device sides gives us an address in the EP descriptor, but that's just a USB view, we don't know which hw endpoint the device is using; we only know its USB address. >> constant. Hmmm... > > My understanding here is that a dedicated MUSB EP is allocated > permanently for each device. Could be, it has been quite a long time since I messed around that part of MUSB. -- balbi [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <874mhtbc63.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org>]
* Re: musb: communication issue with more than 12 FTDI ports [not found] ` <874mhtbc63.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org> @ 2015-10-14 18:11 ` Bin Liu 0 siblings, 0 replies; 13+ messages in thread From: Bin Liu @ 2015-10-14 18:11 UTC (permalink / raw) To: Felipe Balbi, Yegor Yefremov, linux-usb Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On 10/14/2015 12:19 PM, Felipe Balbi wrote: > > Hi, > > Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: >> On 10/14/2015 12:05 PM, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: >>>> Felipe, >>>> >>>> On 10/14/2015 11:25 AM, Felipe Balbi wrote: >>>>> >>>>> Hi, >>>>> >>>>> Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: >>>>>> On 10/14/2015 10:56 AM, Felipe Balbi wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> writes: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 10/13/2015 01:22 PM, Felipe Balbi wrote: >>>>>>>>> Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes: >>>>>>>>>> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov >>>>>>>>>> <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >>>>>>>>>>> We have a problem, when using more than 12 FTDI ports. Kernels tried: >>>>>>>>>>> 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz >>>>>>>>>>> >>>>>>>>>>> Below the USB topology: >>>>>>>>>>> >>>>>>>>>>> # lsusb -t >>>>>>>>>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>>>>>>>>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >>>>>>>>>>> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M >>>>>>>>>>> |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M >>>>>>>>>>> |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M >>>>>>>>>>> |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>>>>>> |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>>>>>> |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>>>>>> |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>>>>>> |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>>>>>> |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>>>>>> |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>>>>>> |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>>>>>> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>>>>>> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>>>>>> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>>>>>> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>>>>>> |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M >>>>>>>>>>> |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M >>>>>>>>>>> |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M >>>>>>>>>>> |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M >>>>>>>> >>>>>>>> How many EPs does each FTDI device require? at least one INT EP, right? >>>>>>>> If I read it right, the topology above has 2 hubs, and 16 high-speed >>>>>>>> FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT >>>>>>>> EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP >>>>>>>> configuration used by default. I am wondering how those devices got >>>>>>>> enumerated properly. >>>>>>> >>>>>>> dynamic EP allocation, but that has its own limitations. >>>>>>> >>>>>> MUSB does not support dynamic EP allocation for INT/ISOCH. >>>>> >>>>> I remember isoc doesn't, not sure about int. Do you remember where that >>>>> part of the code is off the top of your head ? >>>>> >>>> >>>> The MUSB EP allocation is in musb_schedule() in musb_host.c. >>>> >>>> It does not have specific policy for INT/ISOCH, but the issue is that >>>> for periodic EP, it got allocated during device enumeration but freed >>>> only when the device is disconnected. So practically there is no dynamic >>>> EP allocation for INT/ISOCH. >>> >>> This is not exactly what I can see when trying things out: >>> >>> minicom.cap:56:[ 90.909917] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >>> minicom.cap:66:[ 91.175860] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >>> minicom.cap:100:[ 91.697827] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >>> minicom.cap:106:[ 91.818066] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 >>> minicom.cap:149:[ 92.475792] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >>> minicom.cap:162:[ 92.736808] musb-hdrc musb-hdrc.1.auto: qh dc07d5c0 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >>> minicom.cap:207:[ 93.703046] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 >>> minicom.cap:215:[ 93.977574] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 >>> minicom.cap:240:[ 94.388472] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 >>> minicom.cap:289:[ 95.422325] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 >>> minicom.cap:305:[ 95.688207] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 >>> minicom.cap:335:[ 96.291453] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 >>> minicom.cap:410:[ 97.696976] musb-hdrc musb-hdrc.1.auto: qh df6b70c0 urb dc011f40 dev11 ep1in-intr, hw_ep 2, dd842080/8 >>> minicom.cap:56:[ 90.909917] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >>> minicom.cap:66:[ 91.175860] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >>> minicom.cap:100:[ 91.697827] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >>> minicom.cap:106:[ 91.818066] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 >>> minicom.cap:149:[ 92.475792] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >>> minicom.cap:162:[ 92.736808] musb-hdrc musb-hdrc.1.auto: qh dc07d5c0 urb dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1 >>> minicom.cap:207:[ 93.703046] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 >>> minicom.cap:215:[ 93.977574] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 >>> minicom.cap:240:[ 94.388472] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 >>> minicom.cap:289:[ 95.422325] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 >>> minicom.cap:305:[ 95.688207] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1 >>> minicom.cap:335:[ 96.291453] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1 >>> minicom.cap:410:[ 97.696976] musb-hdrc musb-hdrc.1.auto: qh df6b70c0 urb dc011f40 dev11 ep1in-intr, hw_ep 2, dd842080/8 >>> >>> Note how the same ep1in-intr was used with different devices and >>> different hw_eps. OTOH, within the same device, hw_ep was >> >> Maybe I am wrong, but ep1in-intr is the EP reference to the device EP, >> while hw_ep is the reference to MUSB host EP. > > We can't really know which EP the device side is using, right ? :-) The Right, ep1in-intr is the EP# from the descriptor. > device sides gives us an address in the EP descriptor, but that's just a > USB view, we don't know which hw endpoint the device is using; we only The host does not have to know the hw EP on the device side. > know its USB address. The host know the device address and each EP reported from the descriptors. That is all for communication. > >>> constant. Hmmm... >> >> My understanding here is that a dedicated MUSB EP is allocated >> permanently for each device. > > Could be, it has been quite a long time since I messed around that part > of MUSB. > Hope you can pick it up, I have a list of issues with MUSB. I did not send them out just because I know you have other high priority things to do. ;) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-10-14 18:11 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-12 9:34 musb: communication issue with more than 12 FTDI ports Yegor Yefremov
[not found] ` <CAGm1_ku3d4q3jQ6ZZYaLktd182O_WY5Hvu-Z877N31e5wN2_NA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-12 10:34 ` Yegor Yefremov
[not found] ` <CAGm1_kvwLu=4R1G8+bXEhmU4298B-+XGKQRaOjZOz15eU1StFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-12 13:33 ` Konstantin Shkolnyy
2015-10-13 18:22 ` Felipe Balbi
[not found] ` <87r3kyd3xw.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org>
2015-10-14 15:35 ` Bin Liu
[not found] ` <561E7639.40506-l0cyMroinI0@public.gmane.org>
2015-10-14 15:56 ` Felipe Balbi
[not found] ` <87h9ltbg0i.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org>
2015-10-14 15:57 ` Bin Liu
[not found] ` <561E7B6D.80605-l0cyMroinI0@public.gmane.org>
2015-10-14 16:25 ` Felipe Balbi
[not found] ` <87eggxbeou.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org>
2015-10-14 16:41 ` Bin Liu
[not found] ` <561E85D4.4040208-l0cyMroinI0@public.gmane.org>
2015-10-14 17:05 ` Felipe Balbi
[not found] ` <87bnc1bcu1.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org>
2015-10-14 17:09 ` Bin Liu
[not found] ` <561E8C4E.1020602-l0cyMroinI0@public.gmane.org>
2015-10-14 17:19 ` Felipe Balbi
[not found] ` <874mhtbc63.fsf-HgARHv6XitJaoMGHk7MhZQC/G2K4zDHf@public.gmane.org>
2015-10-14 18:11 ` Bin Liu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).