I'm seeing some strange behavior with linux-omap-pm branch and possibly with linux-omap master as well. I booted up a 3430 SDP with an image built using omap3_pm_defconfig. (I enabled EHCI in the menuconfig). The MUX framework reports that some padconfs are being changed: MUX: setup Y9_3430_USB1HS_PHY_STP (0xfa0025d8): 0x0218 -> 0x0003 MUX: setup Y8_3430_USB1HS_PHY_CLK (0xfa0025da): 0x0200 -> 0x0003 MUX: setup AA14_3430_USB1HS_PHY_DIR (0xfa0025ec): 0x1700 -> 0x010b MUX: setup AA11_3430_USB1HS_PHY_NXT (0xfa0025ee): 0x1700 -> 0x010b MUX: setup AA8_3430_USB2HS_PHY_CLK (0xfa0025f0): 0x1700 -> 0x0003 MUX: setup AA9_3430_USB2HS_PHY_DIR (0xfa0025f4): 0x1700 -> 0x010b MUX: setup T4_3430_USB2HS_PHY_D3 (0xfa0021de): 0x1708 -> 0x010b MUX: setup T3_3430_USB2HS_PHY_D4 (0xfa0021d8): 0x1700 -> 0x010b (some lines edited - this is just to illustrate that the MUX framework thinks the padconfs are changed) But, a dump of the registers after bootup shows many pads are being set to GPIO mode: EHCI Port 1 padconf 0x480025D8 = 0x00040004 0x480025DC = 0x00040004 0x480025E0 = 0x00040004 0x480025E4 = 0x00040004 0x480025E8 = 0x00040004 0x480025EC = 0x00040004 EHCI Port 2 padconf 0x480021D4 = 0x010B010B 0x480021D8 = 0x010B010B 0x480021DC = 0x010B010B 0x480025F0 = 0x00040004 0x480025F4 = 0x00040004 0x480025F8 = 0x00040004 I'll take a look in a while, but if someone already knows the reason for this, let me know. - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
