> > > >> Hello Fabio and Peter, > >> > >> I am suffering some strange behaviour in initializing the smtp reset > >> block of the USB1 (host) in iMX28 running kernel 3.12.1 (vanilla) on > >> my custom board based on iMX28EVK. > >> > >> With bootlets I DO NOT TOUCH any register to the USB PHY and family... > >> With bootloader (barebox 2013-03) I do not initialize the usbcore, > >> and the only stuff I set is the pinmux for USB_ID and USB_OC for both > >> ports, but none used. > >> > >> In the device tree there are both declarations for usb-device role > >> and usb-host role. > >> > >> Sometimes during cold-start or warm-start (due to a reset pressure, > >> and/or a reboot command issued) the USB1 (host) is not configured > >> because the function: > >> > >> stmp_reset_block() in the lib/stmp_device.c is exiting due to a TIMEOUT. > >> > >> The following code is executed correctly: > >> > >>> /* clear CLKGATE */ > >>> writel(STMP_MODULE_CLKGATE, reset_addr + > STMP_OFFSET_REG_CLR); > >>> > >>> /* set SFTRST to reset the block */ > >>> writel(STMP_MODULE_SFTRST, reset_addr + STMP_OFFSET_REG_SET); > >>> udelay(1); > >> > >> And now the problematic part: > >> > >>> /* poll CLKGATE becoming set */ > >>> while ((!(readl(reset_addr) & STMP_MODULE_CLKGATE)) && -- > timeout) > >>> /* nothing */; > >>> if (unlikely(!timeout > >> > >> it waits for 0x400 (timeout value counter) read access, then exit > >> with a timeout. It looks like the HW_USBPHY_CTRL for USBPHY1 > >> (0x8007E030) has the following value: 0x80020000 (so no CLKGATE > >> high...) > > > > It means the PHY works abnormal, would you please check the related > > PLL is configured successfully? > > > > I suppose yes, the PLL is configured in the right way (anyway I do not touch > any > known register neither in the linux kernel, neither in the barebox and/or > bootlets), because the subsequent boots are running fine (at least the 90% of > the times) >
I mean check PLL configuration runtime and see if it is the reason. Besides, if bootloader usb works ok with continual warm reset tests? Peter > Now as quick-and-dirty workaround I increased the timeout value to a > 0x4000 (16 times the original), and it seems to be ok for the 95% of the > times, > but I do not know if it is the correct way to face and correct the problem. > > There are some code to be inserted into bootloader and/or bootlets to ensure > a proper way to prepare the USB PHY clock PLL part so linux can initialize it > correctly? > >
