[PATCH 6/9] usb: chipidea: add PTW and PTS handling

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

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?

Regards,
Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |