On Mon, Dec 29, 2014 at 01:37:04PM +0100, gianluca wrote:
> 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??
>
Yes, PLL1 is the dedicated PLL for USB1, you can get it from Reference
Manual.
>
> >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??
>
Define a global function to print PLL1, and call it at USB PHY
driver.
> 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.
You said you only met this problem during the warm reset, not cold boot,
right? I am just worried that the PLL is not locked at that time, maybe
a delay-retest loop can also work?
count = 0;
do {
rval = mxs_phy_hw_init(mxs_phy);
if (!rval) {
break;
} else {
count++;
is_pll_locked();
msleep(50);
}
} while (count < 10)
>
> 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! /
> ---------------
> ¯\_(".)_/¯
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
