On 12/25/2014 03:55 AM, Peter Chen wrote:
On Wed, Dec 24, 2014 at 01:51:32PM +0100, gianluca wrote:
On 12/23/2014 01:12 AM, Peter Chen wrote:
Ok, then just try to get the working version, and find the difference.
>From my mind, it should be PLL related.
Here I am again ;-)
The following log is taken by an automatic-script during bootup (rc.local).
the smtp_device.c throw a time out, so the imx_ehci logs an error
during bootup: unable to init phy
=EE= HW_CLKCTRL_PLL1CTRL0: /dev/mem opened.
Memory mapped at address 0xb6f30000.
Value at address 0x80040020 (0xb6f30020): 0x60000
=EE= HW_CLKCTRL_PLL1CTRL1: /dev/mem opened.
Memory mapped at address 0xb6f34000.
Value at address 0x80040030 (0xb6f34030): 0x800004B1
First I would like to confirm, the "USB1" you said is the second
USB controller, and will use dedicated PLL1, is it correct?
Yes, it is correct. USB1 is the second USB controller.
Where can I find the PLL1 as dedicated PLL for USB1? Device-Tree stuff??
If it is, you may need to print PLL1 at the code once the timeout
occurs, since the PLL1 may be normal behavior after some times.
You have mentioned, if it is built as module, every thing works ok,
correct?
The problem I am arising is the MMU-side stuff of doing thing. The
kernel probe function is passing the MMUmapped address and not the
real-hardware address so I cannot access directly the registers. The
only thing I can do is asking kernel to a mmapped address for the right
registers and print their values out in the dev_err() stuff... Anything
quicker??
But anyway, this morning I tried both static (Chipidea and Host/Device
Kconfig) and dynamic modules and it fails in both cases 5/10% of the
times during cold start.
So, thinking about your hint (about PLLs) I rewrote the phy-mxs-usb in
that way:
--- a/drivers/usb/phy/phy-mxs-usb.c 2013-11-20 21:37:52.000000000 +0100
+++ b/drivers/usb/phy/phy-mxs-usb.c 2014-12-29 12:40:29.000000000 +0100
@@ -61,12 +61,35 @@
return 0;
}
+static void mxs_force_phy_reset(struct usb_phy *phy);
+
static int mxs_phy_init(struct usb_phy *phy)
{
+ int rval;
struct mxs_phy *mxs_phy = to_mxs_phy(phy);
+ int count = 1, retry_count = 5;
+
+ /* TODO:
+ * Sometime for some obscure reason, the PLLs of the smtp block of
+ * USBPHY USB1 is not working as expected so as a _quick_and_dirty_
+ * workaround we try to suspend and resume the phy and its related
+ * clock-tree gates and retry to init itself.
+ * If after retry_count times fails, the USB PHY will not usable
+ * at all. Maybe another SoC reset will do the job. It will called
+ * in a rc.local stuff...
+ */
+ do {
+ clk_prepare_enable(mxs_phy->clk);
+ rval = mxs_phy_hw_init(mxs_phy);
+ if (rval) {
+ dev_warn(phy->dev,
+ "device USBPHY is not responding, retry %d of %d\n",
+ count, retry_count);
+ mxs_force_phy_reset(phy);
+ }
+ } while (rval != 0 && count++ <= retry_count);
- clk_prepare_enable(mxs_phy->clk);
- return mxs_phy_hw_init(mxs_phy);
+ return rval;
}
static void mxs_phy_shutdown(struct usb_phy *phy)
@@ -98,6 +121,16 @@
return 0;
}
+static void mxs_force_phy_reset(struct usb_phy *phy)
+{
+ mxs_phy_suspend(phy, 1 /* Suspend */);
+ mdelay(2);
+ mxs_phy_suspend(phy, 0 /* Resume */);
+ mdelay(2);
+ mxs_phy_shutdown(phy); /* Shutdown */
+ mdelay(2);
+}
+
static int mxs_phy_on_connect(struct usb_phy *phy,
enum usb_device_speed speed)
{
In this case (both modular and static) I received 5/10% of the times
during cold-start the warning, but after issuing a mxs_force_phy_reset()
the problem went away and the USB1 is working when the kernel reach its
final state...
All SoC chips are iMX286 (MCIMX286CVM4B-M06Z) and some boards are
powered by 5V only (4000mAmps), and others are powered by a 24Vdc and a
step-down regulator to achieve the 5V (4000mAmps) for the SoC...
Ah, just for your review:
The board which is powered by ONLY the 5V is refusing to boot from SD
Card (from BootROM Code I suppose) if the SDCard is SDHC mode. No
problem for other SD and/or sizes... Is it a issue to worth of?
Best regards,
--
,,,
(o o)
======oOO==(_)==OOo======
Gianluca Renzi
R&D
phone: +39.0542.609120
fax: +39.0542.609212
.oooO Oooo.
======( )==( )=======
\ ( ) /
\_) (_/
===================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(".)_/¯
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
