linux-toradex.git/drivers/usb/chipidea, branch v3.14.57

usb: chipidea: msm: Initialize PHY on reset event

2014-10-05T21:52:14+00:00

commit 233c7daf4eecd1e992dc42591182cd4a892e687c upstream.

Initialize USB PHY after every Link controller reset

Cc: Tim Bird 
Signed-off-by: Peter Chen 
Signed-off-by: Ivan T. Ivanov 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: msm: Use USB PHY API to control PHY state

2014-10-05T21:52:14+00:00

commit ea290056d7c46f7781ff13801048ed957b96d1a5 upstream.

PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.

Cc: Tim Bird 
Signed-off-by: Peter Chen 
Signed-off-by: Ivan T. Ivanov 
Acked-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: udc: Disable auto ZLP generation on ep0

2014-07-28T15:05:56+00:00

commit 953c66469735aed8d2ada639a72b150f01dae605 upstream.

There are 2 methods for ZLP (zero-length packet) generation:
1) In software
2) Automatic generation by device controller

1) is implemented in UDC driver and it attaches ZLP to IN packet if
   descriptor->size < wLength
2) can be enabled/disabled by setting ZLT bit in the QH

When gadget ffs is connected to ubuntu host, the host sends
get descriptor request and wLength in setup packet is 255 while the
size of descriptor which will be sent by gadget in IN packet is
64 byte. So the composite driver sets req->zero = 1.
In UDC driver following code will be executed then

        if (hwreq->req.zero && hwreq->req.length
            && (hwreq->req.length % hwep->ep.maxpacket == 0))
                add_td_to_list(hwep, hwreq, 0);

Case-A:
So in case of ubuntu host, UDC driver will attach a ZLP to the IN packet.
ubuntu host will request 255 byte in IN request, gadget will send 64 byte
with ZLP and host will come to know that there is no more data.
But hold on, by default ZLT=0 for endpoint 0 so hardware also tries to
automatically generate the ZLP which blocks enumeration for ~6 seconds due
to endpoint 0 STALL, NAKs are sent to host for any requests (OUT/PING)

Case-B:
In case when gadget ffs is connected to Apple device, Apple device sends
setup packet with wLength=64. So descriptor->size = 64 and wLength=64
therefore req->zero = 0 and UDC driver will not attach any ZLP to the
IN packet. Apple device requests 64 bytes, gets 64 bytes and doesn't
further request for IN data. But ZLT=0 by default for endpoint 0 so
hardware tries to automatically generate the ZLP which blocks enumeration
for ~6 seconds due to endpoint 0 STALL, NAKs are sent to host for any
requests (OUT/PING)

According to USB2.0 specs:

    8.5.3.2 Variable-length Data Stage
    A control pipe may have a variable-length data phase in which the
    host requests more data than is contained in the specified data
    structure. When all of the data structure is returned to the host,
    the function should indicate that the Data stage is ended by
    returning a packet that is shorter than the MaxPacketSize for the
    pipe. If the data structure is an exact multiple of wMaxPacketSize
    for the pipe, the function will return a zero-length packet to indicate
    the end of the Data stage.

In Case-A mentioned above:
If we disable software ZLP generation & ZLT=0 for endpoint 0 OR if software
ZLP generation is not disabled but we set ZLT=1 for endpoint 0 then
enumeration doesn't block for 6 seconds.

In Case-B mentioned above:
If we disable software ZLP generation & ZLT=0 for endpoint then enumeration
still blocks due to ZLP automatically generated by hardware and host not needing
it. But if we keep software ZLP generation enabled but we set ZLT=1 for
endpoint 0 then enumeration doesn't block for 6 seconds.

So the proper solution for this issue seems to disable automatic ZLP generation
by hardware (i.e by setting ZLT=1 for endpoint 0) and let software (UDC driver)
handle the ZLP generation based on req->zero field.

Signed-off-by: Abbas Raza 
Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: udc: delete td from req's td list at ep_dequeue

2014-07-09T18:18:24+00:00

commit e4adcff09ca39ecbcc4851d40d0f0a5458e7b77a upstream.

We need to delete un-finished td from current request's td list
at ep_dequeue API, otherwise, this non-user td will be remained
at td list before this request is freed. So if we do ep_queue->
ep_dequeue->ep_queue sequence, when the complete interrupt for
the second ep_queue comes, we search td list for this request,
the first td (added by the first ep_queue) will be handled, and
its status is still active, so we will consider the this transfer
still not be completed, but in fact, it has completed. It causes
the peripheral side considers it never receives current data for
this transfer.

We met this problem when do "Error Recovery Test - Device Configured"
test item for USBCV2 MSC test, the host has never received ACK for
the IN token for CSW due to peripheral considers it does not get this
CBW, the USBCV test log like belows:

--------------------------------------------------------------------------
INFO
Issuing BOT MSC Reset, reset should always succeed
INFO
Retrieving status on CBW endpoint
INFO
CBW endpoint status = 0x0
INFO
Retrieving status on CSW endpoint
INFO
CSW endpoint status = 0x0
INFO
Issuing required command (Test Unit Ready) to verify device has recovered
INFO
Issuing CBW (attempt #1):
INFO
|----- CBW LUN                  = 0x0
INFO
|----- CBW Flags                = 0x0
INFO
|----- CBW Data Transfer Length = 0x0
INFO
|----- CBW CDB Length           = 0x6
INFO
|----- CBW CDB-00 = 0x0
INFO
|----- CBW CDB-01 = 0x0
INFO
|----- CBW CDB-02 = 0x0
INFO
|----- CBW CDB-03 = 0x0
INFO
|----- CBW CDB-04 = 0x0
INFO
|----- CBW CDB-05 = 0x0
INFO
Issuing CSW : try 1
INFO
CSW Bulk Request timed out!
ERROR
Failed CSW phase : should have been success or stall
FAIL
(5.3.4) The CSW status value must be 0x00, 0x01, or 0x02.
ERROR
BOTCommonMSCRequest failed:  error=80004000

Cc: Andrzej Pietrasiewicz 
Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: need to mask when writting endptflush and endptprime

2014-02-21T20:34:45+00:00

ENDPTFLUSH and ENDPTPRIME registers are set by software and clear
by hardware. There is a bit for each endpoint. When we are setting
a bit for an endpoint we should make sure we do not touch other
endpoint bit. There is a race condition if the hardware clear the
bit between the read and the write in hw_write.

Cc: stable  # 3.11+
Signed-off-by: Peter Chen 
Signed-off-by: Matthieu CASTET 
Tested-by: Michael Grzeschik 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: udc: using MultO at TD as real mult value for ISO-TX

2014-01-13T23:55:19+00:00

We have met a bug that the high bandwidth ISO-TX transfer has failed
at the last packet if it is less than 1024, the TD status shows it
is "Transaction Error".

The root cause of this problem is: the mult value at qh is not correct
for current TD's transfer length. We use TD list to queue un-transfer
TDs, and change mult for new adding TDs. If new adding TDs transfer length
less than 1024, but the queued un-transfer TDs transfer length is larger
than 1024, the transfer error will occur, and vice versa.
Usually, this problem occurs at the last packet, and the first packet for
new frame.

We fixed this problem by setting Mult at QH as the largest value (3), and
set MultO (Multiplier Override) at TD according to every transfer length.
It can cover both hardware version less than 2.3 (the real mult is MultO
if it is not 0) and 2.3+ (the real mult is min(qh.mult, td.multo)).

Since the MultO bits are only existed at TX TD, we keep the ISO-RX behavior
unchanged.

For stable tree: 3.11+.

Cc: stable 
Cc: Michael Grzeschik 
Reported-by: Matthieu Vanin 
Tested-by: Matthieu Vanin 
Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: need to mask INT_STATUS when write otgsc

2014-01-13T23:55:19+00:00

For otgsc, both enable bits and status bits are in it. So we need
to make sure the status bits are not be cleared when write enable
bits. It can fix one bug that we plug in/out Micro AB cable fast,
and sometimes, the IDIS will be cleared wrongly when handle last
ID interrupt (ID 0->1), so the current interrupt will not occur.

For stable tree: 3.12+

Cc: stable@vger.kernel.org
Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: put hw_phymode_configure before ci_usb_phy_init

2014-01-13T23:55:19+00:00

hw_phymode_configure configures the PORTSC registers and allow the
following phy_inits to operate on the right parameters. This fix a problem
where the UPLI (ISP1504) could not be detected, because the Viewport was not
available and read the viewport return 0's only.

Signed-off-by: Chris Ruehl 
Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag

2014-01-13T23:55:19+00:00

* init the sts flag to 0 (missed)
* fix write the real bit not sts value
* Set PORTCS_STS and DEVLC_STS only if sts = 1

[Peter Chen: This one and the next patch fix the problem occurred imx27
and imx31, and imx27 and imx31 usb support are enabled until 3.14, so
these two patches isn't needed for -stable]

Signed-off-by: Chris Ruehl 
Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28

2014-01-13T23:55:19+00:00

Due to imx28 needs ARM swp instruction for writing, we set
CI_HDRC_IMX28_WRITE_FIX for imx28.

This patch is needed for stable tree 3.11+

Cc: stable@vger.kernel.org
Cc: robert.hodaszi@digi.com
Signed-off-by: Peter Chen 
Signed-off-by: Marc Kleine-Budde 
Tested-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman