from:"Bin Liu"

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

2015-10-14 Thread Bin Liu


Hi,

On 10/13/2015 01:22 PM, Felipe Balbi wrote:

Yegor Yefremov  writes:

On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov
 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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2015-10-14 Thread Bin Liu


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, 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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2015-10-14 Thread Bin Liu




On 10/14/2015 12:19 PM, Felipe Balbi wrote:


Hi,

Bin Liu <b-...@ti.com> writes:

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, 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,

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

2015-10-14 Thread Bin Liu




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, 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 ep

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

2015-10-14 Thread Bin Liu


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, 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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] phy: Add a driver for dm816x USB PHY

2015-03-10 Thread Bin Liu

On Mon, Mar 9, 2015 at 4:41 PM, Tony Lindgren t...@atomide.com wrote:
* Bin Liu binml...@gmail.com [150309 14:35]:
On Mon, Mar 9, 2015 at 4:26 PM, Tony Lindgren t...@atomide.com wrote:
* Felipe Balbi ba...@ti.com [150309 14:21]:
On Mon, Mar 09, 2015 at 04:17:29PM -0500, Bin Liu wrote:
On Mon, Mar 9, 2015 at 4:13 PM, Felipe Balbi ba...@ti.com wrote:
On Mon, Mar 09, 2015 at 04:11:28PM -0500, Bin Liu wrote:
Hi,

On Mon, Mar 9, 2015 at 3:51 PM, Tony Lindgren t...@atomide.com
wrote:
Add a minimal driver for dm816x USB. Otherwise we can just use
the existing musb_am335x and musb_dsps on dm816x.

dm816x has the almost identical usbss as that in am335x, we should be
able to adopt musb_am335x and musb_dsps for dm816x, and dm814x too?

Tony's using the same musb glue layers, this is just a phy driver,
right ?

Can the current am335x phy driver be adopted too? I remember it is
under drivers/usb/phy/.

Tony will be best to answer, but according to our IRC discussions, it's
too different. Tony ?

Well we should check again between dm814x and am335x documentation
against the $subject driver as the dm816x docs were buggy and I may
have gotten a wrong idea initially.

Will it make our life a little easier by comparing the usb drivers for
dm81xx and am335x in previous TI kernel releases? I cam dig out the
source code if that helps.

Yeah that probably helps if you've dealt with dm814x earlier :)

Well, don't expect much from me about dm814x ;), I did not read its
trm nor errata, but only booted the board a few times trying to
compare the MUSB behaviours while debugging issues on am335x.

Ok, the previous TI released 3.2 kernel for am335x is at [1], and
2.6.37 kernel dm81xx is at [2].

Regards,
-Bin.

[1]
http://arago-project.org/git/projects/?p=linux-am33x.git;a=shortlog;h=refs/heads/v3.2-staging

[2]
http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/TI81XXPSP_04.04.00.01

Just don't look at the dm816x trm, only the errata pdf works for
dm816x phy.

Note that we still are missing basic support for dm814x in mainline,
I'm planning to tackle that at some point but I don't know when I'm
going to get to it..

Regards,

Tony
--
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

Re: [PATCH] phy: Add a driver for dm816x USB PHY

2015-03-09 Thread Bin Liu

Hi,

On Mon, Mar 9, 2015 at 3:51 PM, Tony Lindgren t...@atomide.com wrote:
 Add a minimal driver for dm816x USB. Otherwise we can just use
 the existing musb_am335x and musb_dsps on dm816x.

dm816x has the almost identical usbss as that in am335x, we should be
able to adopt musb_am335x and musb_dsps for dm816x, and dm814x too?

Regards,
-Bin.


 Cc: Brian Hutchinson b.hutch...@gmail.com
 Cc: Felipe Balbi ba...@ti.com
 Signed-off-by: Tony Lindgren t...@atomide.com

 --- /dev/null
 +++ b/Documentation/devicetree/bindings/phy/dm816x-phy.txt
 @@ -0,0 +1,24 @@
 +Device tree binding documentation for am816x USB PHY
 +=
 +
 +Required properties:
 +- compatible : should be ti,dm816x-usb-phy
 +- reg : offset and length of the PHY register set.
 +- reg-names : name for the phy registers
 +- clocks : phandle to the clock
 +- clock-names : name of the clock
 +- syscon: phandle for the syscon node to access misc registers
 +- #phy-cells : from the generic PHY bindings, must be 1
 +- syscon: phandle for the syscon node to access misc registers
 +
 +Example:
 +
 +usb_phy0: usb-phy@20 {
 +   compatible = ti,dm8168-usb-phy;
 +   reg = 0x20 0x8;
 +   reg-names = phy;
 +   clocks = main_fapll 6;
 +   clock-names = refclk;
 +   #phy-cells = 0;
 +   syscon = scm_conf;
 +};
 --- a/drivers/phy/Kconfig
 +++ b/drivers/phy/Kconfig
 @@ -35,6 +35,13 @@ config ARMADA375_USBCLUSTER_PHY
 depends on OF
 select GENERIC_PHY

 +config PHY_DM816X_USB
 +   tristate TI dm816x USB PHY driver
 +   depends on ARCH_OMAP2PLUS
 +   select GENERIC_PHY
 +   help
 + Enable this for dm81xx USB to work.
 +
  config PHY_EXYNOS_MIPI_VIDEO
 tristate S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver
 depends on HAS_IOMEM
 --- a/drivers/phy/Makefile
 +++ b/drivers/phy/Makefile
 @@ -5,6 +5,7 @@
  obj-$(CONFIG_GENERIC_PHY)  += phy-core.o
  obj-$(CONFIG_PHY_BERLIN_USB)   += phy-berlin-usb.o
  obj-$(CONFIG_PHY_BERLIN_SATA)  += phy-berlin-sata.o
 +obj-$(CONFIG_PHY_DM816X_USB)   += phy-dm816x-usb.o
  obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
  obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o
  obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)  += phy-exynos-dp-video.o
 --- /dev/null
 +++ b/drivers/phy/phy-dm816x-usb.c
 @@ -0,0 +1,295 @@
 +/*
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +
 +#include linux/module.h
 +#include linux/platform_device.h
 +#include linux/regmap.h
 +
 +#include linux/slab.h
 +#include linux/of.h
 +#include linux/io.h
 +#include linux/usb/phy_companion.h
 +#include linux/clk.h
 +#include linux/err.h
 +#include linux/pm_runtime.h
 +#include linux/delay.h
 +#include linux/phy/phy.h
 +#include linux/of_platform.h
 +
 +#include linux/mfd/syscon.h
 +
 +/*
 + * TRM has two sets of USB_CTRL registers.. The correct register bits
 + * are in TRM section 24.9.8.2 USB_CTRL Register.
 + */
 +#define DM816X_USB_CTRL_PHYCLKSRC  BIT(8)  /* 1 = PLL ref clock */
 +#define DM816X_USB_CTRL_PHYSLEEP1  BIT(1)
 +#define DM816X_USB_CTRL_PHYSLEEP0  BIT(0)
 +
 +#define DM816X_USBPHY_CTRL_TXRISETUNE  1
 +#define DM816X_USBPHY_CTRL_TXVREFTUNE  0xc
 +#define DM816X_USBPHY_CTRL_TXPREEMTUNE 0x2
 +
 +struct dm816x_usb_phy {
 +   struct regmap *syscon;
 +   struct device *dev;
 +   unsigned int instance;
 +   struct clk *refclk;
 +   struct usb_phy phy;
 +   unsigned int usb_ctrl;  /* Shared between phy0 and phy1 */
 +   unsigned int usbphy_ctrl;
 +};
 +
 +static int dm816x_usb_phy_set_host(struct usb_otg *otg, struct usb_bus *host)
 +{
 +   otg-host = host;
 +   if (!host)
 +   otg-state = OTG_STATE_UNDEFINED;
 +
 +   return 0;
 +}
 +
 +static int dm816x_usb_phy_set_peripheral(struct usb_otg *otg,
 +struct usb_gadget *gadget)
 +{
 +   otg-gadget = gadget;
 +   if (!gadget)
 +   otg-state = OTG_STATE_UNDEFINED;
 +
 +   return 0;
 +}
 +
 +static int dm816x_usb_phy_power_off(struct phy *x)
 +{
 +   struct dm816x_usb_phy *phy = phy_get_drvdata(x);
 +
 +   pm_runtime_put(phy-dev);
 +
 +   return 0;
 +}
 +
 +static int dm816x_usb_phy_power_on(struct phy *x)
 +{
 +   struct dm816x_usb_phy *phy = phy_get_drvdata(x);
 +
 +   return pm_runtime_get_sync(phy-dev);
 +}
 +
 +static int dm816x_usb_phy_init(struct phy *x)
 +{
 +   struct dm816x_usb_phy *phy = phy_get_drvdata(x);
 +

Re: [PATCH] phy: Add a driver for dm816x USB PHY

2015-03-09 Thread Bin Liu

On Mon, Mar 9, 2015 at 4:20 PM, Tony Lindgren t...@atomide.com wrote:
 * Bin Liu binml...@gmail.com [150309 14:17]:
 On Mon, Mar 9, 2015 at 4:13 PM, Felipe Balbi ba...@ti.com wrote:
  On Mon, Mar 09, 2015 at 04:11:28PM -0500, Bin Liu wrote:
  Hi,
 
  On Mon, Mar 9, 2015 at 3:51 PM, Tony Lindgren t...@atomide.com wrote:
   Add a minimal driver for dm816x USB. Otherwise we can just use
   the existing musb_am335x and musb_dsps on dm816x.
 
  dm816x has the almost identical usbss as that in am335x, we should be
  able to adopt musb_am335x and musb_dsps for dm816x, and dm814x too?
 
  Tony's using the same musb glue layers, this is just a phy driver,
  right ?

 Can the current am335x phy driver be adopted too? I remember it is
 under drivers/usb/phy/.

 Yes this is just the phy, other than that things work the same.

 I believe this is different from the am335x phy, and more similar to
 what we have in old drivers/usb/musb/davinci.c. Chances are dm814x
 is same as am335x phy.

Alright, I only played the dm814x board a few times, but never with
dm816x, and thought dm816x and dm814x usbss are the same and very
close to am335x - am335x came out later than dm81xx and has some
improvement in usbss.


 But yeah, we really should do a proper phy driver for am335x too
 along the same lines. Might even be be able to combine those drivers
 with just different compatible values to set the quirks and the
 enable/disable functions.

Ok, I agreed we can make dm816x working first, then gradually move
am335x aligned to the framework.

Regards,
-Bin.


 Regards,

 Tony
--
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

Re: [PATCH] phy: Add a driver for dm816x USB PHY

2015-03-09 Thread Bin Liu

On Mon, Mar 9, 2015 at 4:26 PM, Tony Lindgren t...@atomide.com wrote:
 * Felipe Balbi ba...@ti.com [150309 14:21]:
 On Mon, Mar 09, 2015 at 04:17:29PM -0500, Bin Liu wrote:
  On Mon, Mar 9, 2015 at 4:13 PM, Felipe Balbi ba...@ti.com wrote:
   On Mon, Mar 09, 2015 at 04:11:28PM -0500, Bin Liu wrote:
   Hi,
  
   On Mon, Mar 9, 2015 at 3:51 PM, Tony Lindgren t...@atomide.com wrote:
Add a minimal driver for dm816x USB. Otherwise we can just use
the existing musb_am335x and musb_dsps on dm816x.
  
   dm816x has the almost identical usbss as that in am335x, we should be
   able to adopt musb_am335x and musb_dsps for dm816x, and dm814x too?
  
   Tony's using the same musb glue layers, this is just a phy driver,
   right ?
 
  Can the current am335x phy driver be adopted too? I remember it is
  under drivers/usb/phy/.

 Tony will be best to answer, but according to our IRC discussions, it's
 too different. Tony ?

 Well we should check again between dm814x and am335x documentation
 against the $subject driver as the dm816x docs were buggy and I may
 have gotten a wrong idea initially.

Will it make our life a little easier by comparing the usb drivers for
dm81xx and am335x in previous TI kernel releases? I cam dig out the
source code if that helps.

Regards,
-Bin,


 Regards,

 Tony
--
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

Re: [PATCH] phy: Add a driver for dm816x USB PHY

2015-03-09 Thread Bin Liu

On Mon, Mar 9, 2015 at 4:13 PM, Felipe Balbi ba...@ti.com wrote:
 On Mon, Mar 09, 2015 at 04:11:28PM -0500, Bin Liu wrote:
 Hi,

 On Mon, Mar 9, 2015 at 3:51 PM, Tony Lindgren t...@atomide.com wrote:
  Add a minimal driver for dm816x USB. Otherwise we can just use
  the existing musb_am335x and musb_dsps on dm816x.

 dm816x has the almost identical usbss as that in am335x, we should be
 able to adopt musb_am335x and musb_dsps for dm816x, and dm814x too?

 Tony's using the same musb glue layers, this is just a phy driver,
 right ?

Can the current am335x phy driver be adopted too? I remember it is
under drivers/usb/phy/.

Regards,
-Bin.


 --
 balbi
--
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

Re: am335x: USB DMA IRQ issue

2015-03-03 Thread Bin Liu

On Sat, Feb 28, 2015 at 3:57 PM, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Sat, Feb 28, 2015 at 10:39:49PM +0100, Yegor Yefremov wrote:
 On Tue, Feb 24, 2015 at 5:36 PM, Felipe Balbi ba...@ti.com wrote:
  Hi,
 
  On Thu, Feb 05, 2015 at 12:19:23PM +0100, Yegor Yefremov wrote:
  I have a problem with my am335x based board and USB.
 
  Kernel: Linux version 3.18.1 (YegorYefremov@development1) (gcc version
  4.9.2 (Buildroot 2015.02-git-00797-gf1b07c0) ) #1 SMP Thu Jan 15
  15:31:27 CET 2015
 
  I took two devices and equipped them with USB WLAN cards: Bus 001
  Device 003: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless
  Adapter. One device as AP and another as client. Client makes
  permanent ping to AP. And from time to time I start nuttcp session.
  After 2-3 days I get following errors:
 
  2-3 days ? oh man... :-)
 
  Here's one thing to try. Can you do some variable size pingtest ?
  Something like below should do ?
 
  random()
  {
  size=$(dd if=/dev/urandom count=1 2/dev/null|cksum|
  cut -f1 -d |tr '-' '\0')
  size=$(expr $size % 6)
  }
 
  num=$1
 
  if [ -z $num ]
  then
  num=1
  fi
 
  while ! ifconfig usb0 /dev/null 21; do
  printf waiting for usb0\n
  sleep 1;
  done
 
  ifconfig usb0 192.168.2.14
 
  for i in $(seq 1 $num); do
  random
  printf %d: \t pinging with size %-27d $i $size
  if ! ping -c 6 192.168.2.15 -s $size -q -i 0 /dev/null 21; then
  printf FAILED\n
  break
  fi
  printf PASSED\n
  done

 Still haven't tried your test, but have seen this interesting
 patch/proposal http://e2e.ti.com/support/arm/sitara_arm/f/791/t/404743.
 Seems to be somehow related.

 patch makes sense. If you can make sure it really solves your problem
 then send it as a proper patch on top of my testing/next, I'd be glad.

FYI, the patch is posted here
http://marc.info/?l=linux-usbm=142526223500889w=2.


 At some point, I'll just split dma callback into dedicated rx and tx
 callbacks to avoid confusion in the future.

 --
 balbi
--
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

Re: [PATCH 2/2] usb: musb: Fix getting a generic phy for musb_dsps

2015-02-09 Thread Bin Liu

On Mon, Feb 9, 2015 at 12:39 PM, Tony Lindgren t...@atomide.com wrote:
 * Bin Liu binml...@gmail.com [150206 10:21]:
 Tony,

 On Fri, Feb 6, 2015 at 11:23 AM, Tony Lindgren t...@atomide.com wrote:
  * George Cherian george.cher...@ti.com [150206 05:05]:
  Hi Tony,
 
  You also need to add similar things in dsps_musb_reset();
 
  Otherwise you might not recover from a BABBLE condition.
 
  Thank I totally missed that, updated patch below.
 
  Do you have some testcase that easily triggers BABBLE
  on MUSB?

 I normally just shorten DP or DM to VBUS to trigger babble. No device
 is connected to the port, if I remembered correctly.

 Oh OK, that sounds a bit risky with 5V on the VBUS if a
 device is detected? I think I'll wait on that :)

Sorry, 'shorten' is not a good work for what I did. Just use a wire to
quickly touch DP or DM to VBUS, which pulls up DP/DM shortly, but long
enough to cross SOF to generate a babble.

Regards,
-Bin.


 Regards,

 Tony
--
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

Re: [PATCH 2/2] usb: musb: Fix getting a generic phy for musb_dsps

2015-02-06 Thread Bin Liu

Tony,

On Fri, Feb 6, 2015 at 11:23 AM, Tony Lindgren t...@atomide.com wrote:
 * George Cherian george.cher...@ti.com [150206 05:05]:
 Hi Tony,

 You also need to add similar things in dsps_musb_reset();

 Otherwise you might not recover from a BABBLE condition.

 Thank I totally missed that, updated patch below.

 Do you have some testcase that easily triggers BABBLE
 on MUSB?

I normally just shorten DP or DM to VBUS to trigger babble. No device
is connected to the port, if I remembered correctly.

Regards,
-Bin.


 Regards,

 Tony

 8 --
 From: Tony Lindgren t...@atomide.com
 Date: Wed, 4 Feb 2015 06:28:49 -0800
 Subject: [PATCH] usb: musb: Fix getting a generic phy for musb_dsps

 We still have a combination of legacy phys and generic phys in
 use so we need to support both types of phy for musb_dsps.c.

 Cc: Brian Hutchinson b.hutch...@gmail.com
 Signed-off-by: Tony Lindgren t...@atomide.com

 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -457,12 +457,27 @@ static int dsps_musb_init(struct musb *musb)
 if (IS_ERR(musb-xceiv))
 return PTR_ERR(musb-xceiv);

 +   musb-phy = devm_phy_get(dev-parent, usb2-phy);
 +
 /* Returns zero if e.g. not clocked */
 rev = dsps_readl(reg_base, wrp-revision);
 if (!rev)
 return -ENODEV;

 usb_phy_init(musb-xceiv);
 +   if (IS_ERR(musb-phy))  {
 +   musb-phy = NULL;
 +   } else {
 +   ret = phy_init(musb-phy);
 +   if (ret  0)
 +   return ret;
 +   ret = phy_power_on(musb-phy);
 +   if (ret) {
 +   phy_exit(musb-phy);
 +   return ret;
 +   }
 +   }
 +
 setup_timer(glue-timer, otg_timer, (unsigned long) musb);

 /* Reset the musb */
 @@ -502,6 +517,8 @@ static int dsps_musb_exit(struct musb *musb)

 del_timer_sync(glue-timer);
 usb_phy_shutdown(musb-xceiv);
 +   phy_power_off(musb-phy);
 +   phy_exit(musb-phy);
 debugfs_remove_recursive(glue-dbgfs_root);

 return 0;
 @@ -610,7 +627,7 @@ static int dsps_musb_reset(struct musb *musb)
 struct device *dev = musb-controller;
 struct dsps_glue *glue = dev_get_drvdata(dev-parent);
 const struct dsps_musb_wrapper *wrp = glue-wrp;
 -   int session_restart = 0;
 +   int session_restart = 0, error;

 if (glue-sw_babble_enabled)
 session_restart = sw_babble_control(musb);
 @@ -624,8 +641,14 @@ static int dsps_musb_reset(struct musb *musb)
 dsps_writel(musb-ctrl_base, wrp-control, (1  wrp-reset));
 usleep_range(100, 200);
 usb_phy_shutdown(musb-xceiv);
 +   error = phy_power_off(musb-phy);
 +   if (error)
 +   dev_err(dev, phy shutdown failed: %i\n, error);
 usleep_range(100, 200);
 usb_phy_init(musb-xceiv);
 +   error = phy_power_on(musb-phy);
 +   if (error)
 +   dev_err(dev, phy powerup failed: %i\n, error);
 session_restart = 1;
 }

 --
 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
--
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

Re: am335x: linux 3.16-rc3: USB DMA issue

2014-07-01 Thread Bin Liu

On Tue, Jul 1, 2014 at 10:37 AM, Ezequiel García
ezequ...@vanguardiasur.com.ar wrote:
 On 1 July 2014 12:07, Yegor Yefremov yegorsli...@googlemail.com wrote:
 [..]

 What can be done with these error messages:

 of_get_named_gpiod_flags: can't parse gpios property of node
 '/ocp/usb@4740/usb-phy@47401300[0]'
 47401300.usb-phy supply vcc not found, using dummy regulator
 musb-hdrc musb-hdrc.0.auto: Failed to request rx1.
 musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
 platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral
 of_get_named_gpiod_flags: can't parse gpios property of node
 '/ocp/usb@4740/usb-phy@47401b00[0]'
 47401b00.usb-phy supply vcc not found, using dummy regulator
 musb-hdrc musb-hdrc.1.auto: Failed to request rx1.
 musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517
 platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral
 couldn't find an available UDC


 The above are typical deferal messages. Have you tried building
 everything as a module or moving the DMA devicetree node so it's
 probed earlier?

 But I'm not sure it's related to the problem you are seeing.

It might be ZLP related. Daniel's patch dma: cppi41: handle 0-length
packets might solve it.

-Bin.

 --
 Ezequiel García, VanguardiaSur
 www.vanguardiasur.com.ar
 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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

Re: [PATCH v6 0/5] Add support for SW babble Control

2014-06-03 Thread Bin Liu

George,

On Mon, May 26, 2014 at 4:20 AM, George Cherian george.cher...@ti.com wrote:
 Series add support for SW babble control logic found in
 new silicon versions of AM335x. Runtime differentiation of
 silicon version is done by checking the BABBLE_CTL register.
 For newer silicon the register default value read is 0x4 and
 for older versions its 0x0.

Please add 'Tested-by: Bin Liu b-...@ti.com' to this series.

Thanks,
-Bin.


 Patch 1 - Handle Babble only if MUSB is in HOST mode
 Patch 2 - Convert recover work to delayed work.
 Patch 3 - usb_phy_vbus_(off/_on) are NOPs for am335x PHY
so use usb_phy(_shutdown/_init) in musb_platform_reset()
 Patch 4 - Add return value for musb_platform_reset() in prepration
to support SW babble_ctrl
 Patch 5 - Add and Enable sw babble control for newer silicon

 v5 - v6 : Squash patch 5 and 6 form v5 to avoid build warnings.

 v4 - v5 : Added a debug print before resetting MUSB.
changed a musb_readb to dsps_readb introduced in Patch#5 of v4.

 v3 - v4 : Fixes an issue in gagdet mode - BUS RESET should not
be handled as a BABBLE. Added a check for the same.(Patch #1)
Enable sw babble control properly (Patch #6)

 v2 - v3 : Modify musb_platform_reset() to return zero on success.



 George Cherian (5):
   usb: musb: core: Handle Babble condition only in HOST mode
   usb: musb: core: Convert babble recover work to delayed work
   usb: musb: dsps: Call usb_phy(_shutdown/_init) during
 musb_platform_reset()
   usb: musb: core: Convert the musb_platform_reset to have a return
 value.
   usb: musb: dsps: Add the sw_babble_control() and Enable for newer
 silicon

  drivers/usb/musb/musb_core.c | 27 --
  drivers/usb/musb/musb_core.h | 12 +++---
  drivers/usb/musb/musb_dsps.c | 88 
 ++--
  drivers/usb/musb/musb_regs.h |  7 
  4 files changed, 114 insertions(+), 20 deletions(-)

 --
 1.8.3.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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

Re: [PATCH v4 1/6] usb: musb: core: Handle Babble condition only in HOST mode

2014-05-22 Thread Bin Liu

Hi George,

On Mon, May 19, 2014 at 11:32 PM, George Cherian george.cher...@ti.com wrote:
 Hi Bin,

 On 5/19/2014 9:24 PM, Bin Liu wrote:

 Hi,

 On Mon, May 19, 2014 at 8:39 AM, George Cherian george.cher...@ti.com
 wrote:

 BABBLE and RESET share the same interrupt. The interrupt
 is considered to be RESET if MUSB is in peripheral mode and
 as a BABBLE if MUSB is in HOST mode.

 Handle babble condition iff MUSB is in HOST mode.

 Signed-off-by: George Cherian george.cher...@ti.com
 ---
   drivers/usb/musb/musb_core.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
 index 61da471..eff3c5c 100644
 --- a/drivers/usb/musb/musb_core.c
 +++ b/drivers/usb/musb/musb_core.c
 @@ -849,7 +849,7 @@ b_host:
  }

  /* handle babble condition */
 -   if (int_usb  MUSB_INTR_BABBLE)
 +   if (int_usb  MUSB_INTR_BABBLE  is_host_active(musb))
  schedule_work(musb-recover_work);

 I guess my following comments are for Daniel's patch as while which
 initially added the babble work.

 Should this if statement be merged into the previous 'if(int_usb 
 MUSB_INTR_RESET)' one, which handles the same interrupt and already
 handles host and device mode respectively.


 Initially I too had the babble handling as part of  'if(int_usb 
 MUSB_INTR_RESET)'
 one. But during my tests I hit a corner case where in we hit a BABBLE
 condition
 on disconnect. In such case the babble interrupt can be handled only if we
 have a seperate
 check, else its considered as a BUS RESET.

 When all devices are disconnected  MUSB_DEVCTL_HM = 0 and the code always
 enter the
 else path. In this path it treats the BABBLE as a BUS RESET.

The code flow is a bit confusing, two if() handle the same interrupt.
The second one implied using 'handled = IRQ_HANDLED;' from the first
one.
Also does the switch() in else{} in the first if() cause any side effect?

Since this babble handing is AM335x specific, how about handle it in
dsps_interrupt() in musb_dsps.c, which already has an entry for babble
interrupt? TI 3.2 kernel does this way.

Regards,
-Bin.



 Regards,
 -Bin.

   #if 0
 --
 1.8.3.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



 --
 -George

--
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

Re: [PATCH v3 0/5] Add support for SW babble Control

2014-05-19 Thread Bin Liu

Hi George,

On Mon, May 19, 2014 at 3:40 AM, George Cherian george.cher...@ti.com wrote:
 Hi Bin,


 On 5/15/2014 8:49 PM, Bin Liu wrote:

 George,

 On Thu, May 15, 2014 at 1:28 AM, George Cherian george.cher...@ti.com
 wrote:

 Hi Bin,


 On 5/14/2014 10:13 PM, Bin Liu wrote:

 George,

 On Wed, May 14, 2014 at 9:34 AM, Bin Liu binml...@gmail.com wrote:

 George,

 On Wed, May 14, 2014 at 12:37 AM, George Cherian
 george.cher...@ti.com
 wrote:

 On 5/14/2014 12:07 AM, Bin Liu wrote:

 Hi,

 On Tue, May 13, 2014 at 8:24 AM, George Cherian
 george.cher...@ti.com
 wrote:

 Hi Daniel,


 On 5/13/2014 6:44 PM, Daniel Mack wrote:

 Hi George,

 On 05/13/2014 02:57 PM, George Cherian wrote:

 I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the
 MUSB_BABBLE_CTL
 reg.
 can you try with the following patch.

 diff --git a/drivers/usb/musb/musb_dsps.c
 b/drivers/usb/musb/musb_dsps.c
 index 1ae6681..1160cd1 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
 * logic enabled.
 */
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
 -   if (val == MUSB_BABBLE_RCV_DISABLE)
 +   if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
 +   val |= MUSB_BABBLE_SW_SESSION_CTRL;
 +   dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
 +   }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)

 MUSB_BABBLE_STUCK_J still remains unset, so I get the same result
 as
 without the patch: a full glue reset is conducted. Do I get you
 right
 that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions
 when
 MUSB_BABBLE_SW_SESSION_CTRL is set?

 Basically, there are 2 types of babble conditions.
 1) Transient babble condition - which could be recovered from
 without
 an
 IP
 reset .
 2) Babble condition - which could be recovered from only by doing an
 IP
 reset.

 Looks like you are always hitting case 2 (Most times am also hitting
 the
 same).
 Case 1 is really hard to reproduce. I don't have a reliable method
 as
 of
 now
 to
 reproduce this case consistently.

 [   19.672373] CAUTION: musb: Babble Interrupt Occurred
 [   19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
 (a_wait_bcon)
 [   19.685815] usb 1-1: USB disconnect, device number 3
 [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL
 value
 44
 [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset


 I don't quite follow, especially as I lack documentation of the IP
 core.
 How do you test babble errors, is there any way to force them to
 happen
 reliably?


 There is no 100% reliable method to force it to happen. Following is

 I have a way to force babble happen reliably - shorting DP or DM to
 VBUS. I opened the far-end plug of the USB cable, so I can easily
 short DP or DM to VBUS.

 Good to know that you have a reliable way to test babble condition.
 Can you please do a quick test on 3.15.0-rc4 with the series applied?
 In case of any assistance please do let me know.

 Sure, but could you please re-send those patches to my corporate email
 so that I can apply them from Thunderbird?

 You don't have to resend the patches. Nishanth Menon showed me a way
 to extract the patch from Gmail - Thanks Nishanth.

 But which repo do you want to me test with? The first patch ([PATCH v2
 1/5] usb: musb: core: Convert babble recover work to delayed work)
 does not apply to v3.15-rc4 tag. the current musb_core.c does not have
 the recovery work for musb. Please let me know what I missed.

 Oops I missed to mention the same.
 Please try on
 git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master

 The test is done. The babble always causes STUCK_J is reset,
 MUSB_BABBLE_CTL is 0x44 or 0x4. MUSB reset happens.

 Thankyou Bin for the help.

 Can I get a Tested-by from you?

Yes, sure.


 Do you think when re-start happens the driver should print a message
 on console saying re-start due to babble? It would help debug the
 babble problems while the dynamic debug is off.


 It prints  out a message saying babble condition occured.

That is good, but I think we also want to know the babble type - the
controller is reset or not.

 More over, it re-enumerates all the devices connected  as part of Musb
 re-start.

Sometimes the custom board has hw or sw issue, for example USB
basically does not functional, maybe after babble there is no
re-enumeration, then we cannot tell if controller reset happened or
not from the log. I think a specific message telling that will
helpful.

Regards,
-Bin.

 Don't you think that is sufficient enough ?

 Thanks,
 -Bin.

 Thanks,
 -Bin.

 I read these linux-usb emails in Gmail, and  am not aware of any easy
 way to extract patches from Gmail.

 BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
 handling is similar to this patch set. With TI3.12.10, MISC is always
 0x64, so MUSB

Re: [PATCH v4 1/6] usb: musb: core: Handle Babble condition only in HOST mode

2014-05-19 Thread Bin Liu

Hi,

On Mon, May 19, 2014 at 8:39 AM, George Cherian george.cher...@ti.com wrote:
 BABBLE and RESET share the same interrupt. The interrupt
 is considered to be RESET if MUSB is in peripheral mode and
 as a BABBLE if MUSB is in HOST mode.

 Handle babble condition iff MUSB is in HOST mode.

 Signed-off-by: George Cherian george.cher...@ti.com
 ---
  drivers/usb/musb/musb_core.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
 index 61da471..eff3c5c 100644
 --- a/drivers/usb/musb/musb_core.c
 +++ b/drivers/usb/musb/musb_core.c
 @@ -849,7 +849,7 @@ b_host:
 }

 /* handle babble condition */
 -   if (int_usb  MUSB_INTR_BABBLE)
 +   if (int_usb  MUSB_INTR_BABBLE  is_host_active(musb))
 schedule_work(musb-recover_work);

I guess my following comments are for Daniel's patch as while which
initially added the babble work.

Should this if statement be merged into the previous 'if(int_usb 
MUSB_INTR_RESET)' one, which handles the same interrupt and already
handles host and device mode respectively.

Regards,
-Bin.


  #if 0
 --
 1.8.3.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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

Re: [PATCH v4 4/6] usb: musb: core: Convert the musb_platform_reset to have a return value.

2014-05-19 Thread Bin Liu

Hi,

On Mon, May 19, 2014 at 8:39 AM, George Cherian george.cher...@ti.com wrote:
 Currently musb_platform_reset() is only used by dsps.
 In case of BABBLE interrupt for other platforms the  musb_platform_reset()
 is a NOP. In such situations no need to re-initialize the endpoints.
 Also in the latest silicon revision of AM335x, we do have a babble recovery
 mechanism without resetting the IP block. In preperation to add that support
 its better to have a rest_done return for  musb_platform_reset().

 Signed-off-by: George Cherian george.cher...@ti.com
 ---
  drivers/usb/musb/musb_core.c | 38 +-
  drivers/usb/musb/musb_core.h | 10 ++
  drivers/usb/musb/musb_dsps.c |  3 ++-
  3 files changed, 29 insertions(+), 22 deletions(-)

 diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
 index 8920b80..1b0b85d 100644
 --- a/drivers/usb/musb/musb_core.c
 +++ b/drivers/usb/musb/musb_core.c
 @@ -1755,28 +1755,32 @@ static void musb_irq_work(struct work_struct *data)
  static void musb_recover_work(struct work_struct *data)
  {
 struct musb *musb = container_of(data, struct musb, 
 recover_work.work);
 -   int status;
 +   int status, ret;

 -   musb_platform_reset(musb);
 +   ret  = musb_platform_reset(musb);
 +   if (ret   0)

If change it to ' if (ret)' here, you don't have to indent the reset
of the code.

Regards,
-Bin.

 +   return;

 -   usb_phy_vbus_off(musb-xceiv);
 -   usleep_range(100, 200);
 +   if (!ret) {
 +   usb_phy_vbus_off(musb-xceiv);
 +   usleep_range(100, 200);

 -   usb_phy_vbus_on(musb-xceiv);
 -   usleep_range(100, 200);
 +   usb_phy_vbus_on(musb-xceiv);
 +   usleep_range(100, 200);

 -   /*
 -* When a babble condition occurs, the musb controller removes the
 -* session bit and the endpoint config is lost.
 -*/
 -   if (musb-dyn_fifo)
 -   status = ep_config_from_table(musb);
 -   else
 -   status = ep_config_from_hw(musb);
 +   /*
 +* When a babble condition occurs, the musb controller
 +* removes the session bit and the endpoint config is lost.
 +*/
 +   if (musb-dyn_fifo)
 +   status = ep_config_from_table(musb);
 +   else
 +   status = ep_config_from_hw(musb);

 -   /* start the session again */
 -   if (status == 0)
 -   musb_start(musb);
 +   /* start the session again */
 +   if (status == 0)
 +   musb_start(musb);
 +   }
  }

  /* --
 diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
 index 423cd00..3ccb428 100644
 --- a/drivers/usb/musb/musb_core.h
 +++ b/drivers/usb/musb/musb_core.h
 @@ -192,7 +192,7 @@ struct musb_platform_ops {

 int (*set_mode)(struct musb *musb, u8 mode);
 void(*try_idle)(struct musb *musb, unsigned long timeout);
 -   void(*reset)(struct musb *musb);
 +   int (*reset)(struct musb *musb);

 int (*vbus_status)(struct musb *musb);
 void(*set_vbus)(struct musb *musb, int on);
 @@ -554,10 +554,12 @@ static inline void musb_platform_try_idle(struct musb 
 *musb,
 musb-ops-try_idle(musb, timeout);
  }

 -static inline void musb_platform_reset(struct musb *musb)
 +static inline int  musb_platform_reset(struct musb *musb)
  {
 -   if (musb-ops-reset)
 -   musb-ops-reset(musb);
 +   if (!musb-ops-reset)
 +   return -EINVAL;
 +
 +   return musb-ops-reset(musb);
  }

  static inline int musb_platform_get_vbus_status(struct musb *musb)
 diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
 index 74c4193..f6f3087 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -536,7 +536,7 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
 return 0;
  }

 -static void dsps_musb_reset(struct musb *musb)
 +static int dsps_musb_reset(struct musb *musb)
  {
 struct device *dev = musb-controller;
 struct dsps_glue *glue = dev_get_drvdata(dev-parent);
 @@ -548,6 +548,7 @@ static void dsps_musb_reset(struct musb *musb)
 usleep_range(100, 200);
 usb_phy_init(musb-xceiv);

 +   return 0;
  }

  static struct musb_platform_ops dsps_ops = {
 --
 1.8.3.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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

Re: [PATCH v3 0/5] Add support for SW babble Control

2014-05-15 Thread Bin Liu

George,

On Thu, May 15, 2014 at 1:28 AM, George Cherian george.cher...@ti.com wrote:
 Hi Bin,


 On 5/14/2014 10:13 PM, Bin Liu wrote:

 George,

 On Wed, May 14, 2014 at 9:34 AM, Bin Liu binml...@gmail.com wrote:

 George,

 On Wed, May 14, 2014 at 12:37 AM, George Cherian george.cher...@ti.com
 wrote:

 On 5/14/2014 12:07 AM, Bin Liu wrote:

 Hi,

 On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com
 wrote:

 Hi Daniel,


 On 5/13/2014 6:44 PM, Daniel Mack wrote:

 Hi George,

 On 05/13/2014 02:57 PM, George Cherian wrote:

 I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the
 MUSB_BABBLE_CTL
 reg.
 can you try with the following patch.

 diff --git a/drivers/usb/musb/musb_dsps.c
 b/drivers/usb/musb/musb_dsps.c
 index 1ae6681..1160cd1 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
   val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
 -   if (val == MUSB_BABBLE_RCV_DISABLE)
 +   if (val == MUSB_BABBLE_RCV_DISABLE) {
   glue-sw_babble_enabled = true;
 +   val |= MUSB_BABBLE_SW_SESSION_CTRL;
 +   dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
 +   }
   ret = dsps_musb_dbg_init(musb, glue);
   if (ret)

 MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
 without the patch: a full glue reset is conducted. Do I get you right
 that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions
 when
 MUSB_BABBLE_SW_SESSION_CTRL is set?

 Basically, there are 2 types of babble conditions.
 1) Transient babble condition - which could be recovered from without
 an
 IP
 reset .
 2) Babble condition - which could be recovered from only by doing an
 IP
 reset.

 Looks like you are always hitting case 2 (Most times am also hitting
 the
 same).
 Case 1 is really hard to reproduce. I don't have a reliable method as
 of
 now
 to
 reproduce this case consistently.

 [   19.672373] CAUTION: musb: Babble Interrupt Occurred
 [   19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
 (a_wait_bcon)
 [   19.685815] usb 1-1: USB disconnect, device number 3
 [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL
 value
 44
 [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset


 I don't quite follow, especially as I lack documentation of the IP
 core.
 How do you test babble errors, is there any way to force them to
 happen
 reliably?


 There is no 100% reliable method to force it to happen. Following is

 I have a way to force babble happen reliably - shorting DP or DM to
 VBUS. I opened the far-end plug of the USB cable, so I can easily
 short DP or DM to VBUS.

 Good to know that you have a reliable way to test babble condition.
 Can you please do a quick test on 3.15.0-rc4 with the series applied?
 In case of any assistance please do let me know.

 Sure, but could you please re-send those patches to my corporate email
 so that I can apply them from Thunderbird?

 You don't have to resend the patches. Nishanth Menon showed me a way
 to extract the patch from Gmail - Thanks Nishanth.

 But which repo do you want to me test with? The first patch ([PATCH v2
 1/5] usb: musb: core: Convert babble recover work to delayed work)
 does not apply to v3.15-rc4 tag. the current musb_core.c does not have
 the recovery work for musb. Please let me know what I missed.

 Oops I missed to mention the same.
 Please try on
 git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master

The test is done. The babble always causes STUCK_J is reset,
MUSB_BABBLE_CTL is 0x44 or 0x4. MUSB reset happens.

Do you think when re-start happens the driver should print a message
on console saying re-start due to babble? It would help debug the
babble problems while the dynamic debug is off.

Thanks,
-Bin.


 Thanks,
 -Bin.

 I read these linux-usb emails in Gmail, and  am not aware of any easy
 way to extract patches from Gmail.

 BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
 handling is similar to this patch set. With TI3.12.10, MISC is always
 0x64, so MUSB never restarts.

 Thanks,
 -Bin.

 But the interesting thing is that with TI 3.2 kernel, shorting DP or
 DM to VBUS causes MISC register to be 0x4, but the result is
 completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.

 So in the 3.2 kernel, the babble handing resets the controller, but
 the 3.12.10 does not.

 Regards,
 -Bin.

 my setup ,
 I have a HUB with 4 devices connected , which gives me a Babble
 interrupt
 on both connects and disconnects ( Not always though).

 Anyway, the full glue layer solves this rare condition quite well for
 me. Is there any downside of this?


 Daniel

 --
 -George

 --
 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

Re: [PATCH v3 0/5] Add support for SW babble Control

2014-05-14 Thread Bin Liu

George,

On Wed, May 14, 2014 at 12:37 AM, George Cherian george.cher...@ti.com wrote:
 On 5/14/2014 12:07 AM, Bin Liu wrote:

 Hi,

 On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com
 wrote:

 Hi Daniel,


 On 5/13/2014 6:44 PM, Daniel Mack wrote:

 Hi George,

 On 05/13/2014 02:57 PM, George Cherian wrote:

 I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
 reg.
 can you try with the following patch.

 diff --git a/drivers/usb/musb/musb_dsps.c
 b/drivers/usb/musb/musb_dsps.c
 index 1ae6681..1160cd1 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
   * logic enabled.
   */
  val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
 -   if (val == MUSB_BABBLE_RCV_DISABLE)
 +   if (val == MUSB_BABBLE_RCV_DISABLE) {
  glue-sw_babble_enabled = true;
 +   val |= MUSB_BABBLE_SW_SESSION_CTRL;
 +   dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
 +   }
  ret = dsps_musb_dbg_init(musb, glue);
  if (ret)

 MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
 without the patch: a full glue reset is conducted. Do I get you right
 that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
 MUSB_BABBLE_SW_SESSION_CTRL is set?

 Basically, there are 2 types of babble conditions.
 1) Transient babble condition - which could be recovered from without an
 IP
 reset .
 2) Babble condition - which could be recovered from only by doing an IP
 reset.

 Looks like you are always hitting case 2 (Most times am also hitting the
 same).
 Case 1 is really hard to reproduce. I don't have a reliable method as of
 now
 to
 reproduce this case consistently.

 [   19.672373] CAUTION: musb: Babble Interrupt Occurred
 [   19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
 (a_wait_bcon)
 [   19.685815] usb 1-1: USB disconnect, device number 3
 [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
 44
 [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset


 I don't quite follow, especially as I lack documentation of the IP core.
 How do you test babble errors, is there any way to force them to happen
 reliably?


 There is no 100% reliable method to force it to happen. Following is

 I have a way to force babble happen reliably - shorting DP or DM to
 VBUS. I opened the far-end plug of the USB cable, so I can easily
 short DP or DM to VBUS.

 Good to know that you have a reliable way to test babble condition.
 Can you please do a quick test on 3.15.0-rc4 with the series applied?
 In case of any assistance please do let me know.

Sure, but could you please re-send those patches to my corporate email
so that I can apply them from Thunderbird?

I read these linux-usb emails in Gmail, and  am not aware of any easy
way to extract patches from Gmail.

BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
handling is similar to this patch set. With TI3.12.10, MISC is always
0x64, so MUSB never restarts.

Thanks,
-Bin.


 But the interesting thing is that with TI 3.2 kernel, shorting DP or
 DM to VBUS causes MISC register to be 0x4, but the result is
 completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.

 So in the 3.2 kernel, the babble handing resets the controller, but
 the 3.12.10 does not.

 Regards,
 -Bin.

 my setup ,
 I have a HUB with 4 devices connected , which gives me a Babble interrupt
 on both connects and disconnects ( Not always though).

 Anyway, the full glue layer solves this rare condition quite well for
 me. Is there any downside of this?


 Daniel


 --
 -George

 --
 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



 --
 -George

--
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

Re: [PATCH v3 0/5] Add support for SW babble Control

2014-05-14 Thread Bin Liu

George,

On Wed, May 14, 2014 at 9:34 AM, Bin Liu binml...@gmail.com wrote:
 George,

 On Wed, May 14, 2014 at 12:37 AM, George Cherian george.cher...@ti.com 
 wrote:
 On 5/14/2014 12:07 AM, Bin Liu wrote:

 Hi,

 On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com
 wrote:

 Hi Daniel,


 On 5/13/2014 6:44 PM, Daniel Mack wrote:

 Hi George,

 On 05/13/2014 02:57 PM, George Cherian wrote:

 I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
 reg.
 can you try with the following patch.

 diff --git a/drivers/usb/musb/musb_dsps.c
 b/drivers/usb/musb/musb_dsps.c
 index 1ae6681..1160cd1 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
   * logic enabled.
   */
  val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
 -   if (val == MUSB_BABBLE_RCV_DISABLE)
 +   if (val == MUSB_BABBLE_RCV_DISABLE) {
  glue-sw_babble_enabled = true;
 +   val |= MUSB_BABBLE_SW_SESSION_CTRL;
 +   dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
 +   }
  ret = dsps_musb_dbg_init(musb, glue);
  if (ret)

 MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
 without the patch: a full glue reset is conducted. Do I get you right
 that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
 MUSB_BABBLE_SW_SESSION_CTRL is set?

 Basically, there are 2 types of babble conditions.
 1) Transient babble condition - which could be recovered from without an
 IP
 reset .
 2) Babble condition - which could be recovered from only by doing an IP
 reset.

 Looks like you are always hitting case 2 (Most times am also hitting the
 same).
 Case 1 is really hard to reproduce. I don't have a reliable method as of
 now
 to
 reproduce this case consistently.

 [   19.672373] CAUTION: musb: Babble Interrupt Occurred
 [   19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
 (a_wait_bcon)
 [   19.685815] usb 1-1: USB disconnect, device number 3
 [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
 44
 [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset


 I don't quite follow, especially as I lack documentation of the IP core.
 How do you test babble errors, is there any way to force them to happen
 reliably?


 There is no 100% reliable method to force it to happen. Following is

 I have a way to force babble happen reliably - shorting DP or DM to
 VBUS. I opened the far-end plug of the USB cable, so I can easily
 short DP or DM to VBUS.

 Good to know that you have a reliable way to test babble condition.
 Can you please do a quick test on 3.15.0-rc4 with the series applied?
 In case of any assistance please do let me know.

 Sure, but could you please re-send those patches to my corporate email
 so that I can apply them from Thunderbird?

You don't have to resend the patches. Nishanth Menon showed me a way
to extract the patch from Gmail - Thanks Nishanth.

But which repo do you want to me test with? The first patch ([PATCH v2
1/5] usb: musb: core: Convert babble recover work to delayed work)
does not apply to v3.15-rc4 tag. the current musb_core.c does not have
the recovery work for musb. Please let me know what I missed.

Thanks,
-Bin.


 I read these linux-usb emails in Gmail, and  am not aware of any easy
 way to extract patches from Gmail.

 BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
 handling is similar to this patch set. With TI3.12.10, MISC is always
 0x64, so MUSB never restarts.

 Thanks,
 -Bin.


 But the interesting thing is that with TI 3.2 kernel, shorting DP or
 DM to VBUS causes MISC register to be 0x4, but the result is
 completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.

 So in the 3.2 kernel, the babble handing resets the controller, but
 the 3.12.10 does not.

 Regards,
 -Bin.

 my setup ,
 I have a HUB with 4 devices connected , which gives me a Babble interrupt
 on both connects and disconnects ( Not always though).

 Anyway, the full glue layer solves this rare condition quite well for
 me. Is there any downside of this?


 Daniel


 --
 -George

 --
 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



 --
 -George

--
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

Re: [PATCH v3 0/5] Add support for SW babble Control

2014-05-13 Thread Bin Liu

Hi,

On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com wrote:
 Hi Daniel,


 On 5/13/2014 6:44 PM, Daniel Mack wrote:

 Hi George,

 On 05/13/2014 02:57 PM, George Cherian wrote:

 I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
 reg.
 can you try with the following patch.

 diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
 index 1ae6681..1160cd1 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
  * logic enabled.
  */
 val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
 -   if (val == MUSB_BABBLE_RCV_DISABLE)
 +   if (val == MUSB_BABBLE_RCV_DISABLE) {
 glue-sw_babble_enabled = true;
 +   val |= MUSB_BABBLE_SW_SESSION_CTRL;
 +   dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
 +   }
 ret = dsps_musb_dbg_init(musb, glue);
 if (ret)

 MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
 without the patch: a full glue reset is conducted. Do I get you right
 that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
 MUSB_BABBLE_SW_SESSION_CTRL is set?

 Basically, there are 2 types of babble conditions.
 1) Transient babble condition - which could be recovered from without an IP
 reset .
 2) Babble condition - which could be recovered from only by doing an IP
 reset.

 Looks like you are always hitting case 2 (Most times am also hitting the
 same).
 Case 1 is really hard to reproduce. I don't have a reliable method as of now
 to
 reproduce this case consistently.

 [   19.672373] CAUTION: musb: Babble Interrupt Occurred
 [   19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
 (a_wait_bcon)
 [   19.685815] usb 1-1: USB disconnect, device number 3
 [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
 44
 [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset


 I don't quite follow, especially as I lack documentation of the IP core.
 How do you test babble errors, is there any way to force them to happen
 reliably?


 There is no 100% reliable method to force it to happen. Following is

I have a way to force babble happen reliably - shorting DP or DM to
VBUS. I opened the far-end plug of the USB cable, so I can easily
short DP or DM to VBUS.

But the interesting thing is that with TI 3.2 kernel, shorting DP or
DM to VBUS causes MISC register to be 0x4, but the result is
completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.

So in the 3.2 kernel, the babble handing resets the controller, but
the 3.12.10 does not.

Regards,
-Bin.

 my setup ,
 I have a HUB with 4 devices connected , which gives me a Babble interrupt
 on both connects and disconnects ( Not always though).

 Anyway, the full glue layer solves this rare condition quite well for
 me. Is there any downside of this?


 Daniel



 --
 -George

 --
 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
--
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

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

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

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

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

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

Re: [PATCH] phy: Add a driver for dm816x USB PHY

Re: [PATCH] phy: Add a driver for dm816x USB PHY

Re: [PATCH] phy: Add a driver for dm816x USB PHY

Re: [PATCH] phy: Add a driver for dm816x USB PHY

Re: [PATCH] phy: Add a driver for dm816x USB PHY

Re: am335x: USB DMA IRQ issue

Re: [PATCH 2/2] usb: musb: Fix getting a generic phy for musb_dsps

Re: [PATCH 2/2] usb: musb: Fix getting a generic phy for musb_dsps

Re: am335x: linux 3.16-rc3: USB DMA issue

Re: [PATCH v6 0/5] Add support for SW babble Control

Re: [PATCH v4 1/6] usb: musb: core: Handle Babble condition only in HOST mode

Re: [PATCH v3 0/5] Add support for SW babble Control

Re: [PATCH v4 1/6] usb: musb: core: Handle Babble condition only in HOST mode

Re: [PATCH v4 4/6] usb: musb: core: Convert the musb_platform_reset to have a return value.

Re: [PATCH v3 0/5] Add support for SW babble Control

Re: [PATCH v3 0/5] Add support for SW babble Control

Re: [PATCH v3 0/5] Add support for SW babble Control

Re: [PATCH v3 0/5] Add support for SW babble Control

23 matches

Site Navigation

Mail list logo

Footer information