On 10/14/2015 12:05 PM, Felipe Balbi wrote:
Hi, Bin Liu <b-...@ti.com> writes:Felipe, On 10/14/2015 11:25 AM, Felipe Balbi wrote:Hi, Bin Liu <b-...@ti.com> writes:On 10/14/2015 10:56 AM, Felipe Balbi wrote:Hi, Bin Liu <b-...@ti.com> writes:Hi, On 10/13/2015 01:22 PM, Felipe Balbi wrote:Yegor Yefremov <yegorsli...@googlemail.com> writes:On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov <yegorsli...@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, 480MHow 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-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
