Re: musb: communication issue with more than 12 FTDI ports

[Bin Liu <b-liu-l0cyMroinI0@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