Michael Grzeschik a ?crit :

On Fri, Nov 16, 2012 at 05:39:42PM +0200, Alexander Shishkin wrote:

quoted

Matthieu CASTET [off-list ref] writes:

quoted

Alexander Shishkin a ?crit :

quoted

Michael Grzeschik [off-list ref] writes:

quoted

On Fri, Nov 16, 2012 at 03:34:23PM +0200, Alexander Shishkin wrote:

quoted

Michael Grzeschik [off-list ref] writes:

quoted

On Fri, Nov 16, 2012 at 02:45:39PM +0200, Alexander Shishkin wrote:

quoted

Michael Grzeschik [off-list ref] writes:

quoted

This patch makes it possible to configure the PTW and PTS bits inside
the portsc register for host and device mode before the driver starts
and the phy can be addressed as hardware implementation is designed.

Signed-off-by: Michael Grzeschik <redacted>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
 drivers/usb/chipidea/bits.h        |    3 +++
 drivers/usb/chipidea/ci.h          |    2 ++
 drivers/usb/chipidea/ci13xxx_imx.c |    1 +
 drivers/usb/chipidea/core.c        |   47 ++++++++++++++++++++++++++++++++++++
 drivers/usb/chipidea/host.c        |    4 +++
 include/linux/usb/chipidea.h       |    9 +++++++
 6 files changed, 66 insertions(+)

diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index 4b6ae3e..3cded5f 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h

@@ -48,6 +48,9 @@
 #define PORTSC_SUSP           BIT(7)
 #define PORTSC_HSP            BIT(9)
 #define PORTSC_PTC            (0x0FUL << 16)
+#define PORTSC_PTS            (BIT(31) | BIT(30))
+#define PORTSC_PTW            BIT(28)
+#define PORTSC_STS            BIT(29)

Hm, my spec says these are actually in DEVLC register and only have this
meaning in device mode. And in portsc these bits fall in device address
bitfield. Can you refer me to your spec?

You can find it here:
http://cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf?fpsp=1
Page 4947

Oh, but see, the offset is 0x184, which in chipidea spec (the version
that I have) corresponds to DEVLC and not PORTSC. So in this driver's
terminology it's DEVLC too, at least currently.

So have you tested this code and did it make any difference?

Yes, i have tested this code with MX25, MX28, MX35 and MX53. In every
SoCs Datasheet the PORTSC register is defined on PORTBASE+0x184. Without
this proper configuration its not possible to communicate with the PHY.

No, I mean, you're writing DEVLC (using present driver's terminology)
bits to PORTSC register. It *shouldn't* work. I suppose, it does
something, but not exactly what you intended.

I confirm in our datasheet we have PTW, PTS, STS in this register  PORTSCx with
this mapping.

In later design that support lpm, these bits have to move in another register
because ehci 1.1 use them [1].

Ahh, I didn't realize imxes were nolpm. Now it makes more sense. This
means that, as you suggested in the other mail, these portsc/devlc
accesses should be done conditionally based on ci->hw_bank.lpm.

To handle lpm devices in this patch, we need some register layout of the
lpm core. Probably only te DEVLC register. Is there some documentation
available?

In include/linux/usb/langwell_udc.h before it was removed, you could find the
mapping :

    u32 devlc;      /* control LPM and each USB port behavior */
/* bits 31:29, parallel transceiver select */
#define LPM_PTS(d)  (((d)>>29)&7)
#define LPM_STS     BIT(28) /* serial transceiver select */
#define LPM_PTW     BIT(27) /* parallel transceiver width */
#define LPM_PSPD(d) (((d)>>25)&3)   /* bits 26:25, port speed */
#define LPM_PSPD_MASK   (BIT(26) | BIT(25))
#define LPM_SPEED_FULL  0
#define LPM_SPEED_LOW   1
#define LPM_SPEED_HIGH  2
#define LPM_SRT     BIT(24) /* shorten reset time */
#define LPM_PFSC    BIT(23) /* port force full speed connect */
#define LPM_PHCD    BIT(22) /* PHY low power suspend clock disable */
#define LPM_STL     BIT(16) /* STALL reply to LPM token */
#define LPM_BA(d)   \
    (((d)>>1)&0x7ff)    /* bits 11:1, BmAttributes */
#define LPM_NYT_ACK BIT(0)  /* NYET/ACK reply to LPM token */