* Mehresh Ramneek-B31383 | 2011-06-21 14:46:14 [+0000]: >Mehresh Ramneek-B31383 wrote: >> >> [Ramneek]: No I cannot as different SoCs of BOOK-E family have >> different IP block versions > >There is no .dts file for P5020/P3041/P101x in upstream tree. Why this not noted it the device tree there are different IP blocks? This worked well for the network driver and crypto driver. > >[Ramneek]: Yes, the code still needs to be moved upstream. That's why I sent USB code as RFC for review. > I couldn't get your second point. Please explain it again ... > >The 83xx phy settings are in arch/powerpc/platforms/83xx/usb.c. What is wrong with that approach? > >[Ramneek]: 83xx family had several sub-families whose usb controllers needed a lot of initialization (differing among various socs like clock settings, pin muxing, etc) > For BOOK-E socs, phy initialization is very easy with same usb clock settings across all socs. Also muxing now is moved to board files. > Hence phy initialization was moved to the fsl/usb driver. > Only because some bits are changed for UTMI phy initialization for BOOK-E socs (having internal UTMI phy), I > have to introduce the code here only. There is no point ifdefing these things. I've been looking at the ehci register spec of mpc8379, mpc8536 and p1022 and it looks like mpc8379 + mpc8536 have a subset of what p1022 has to offer and it looks like they don't support UTMI at all. So why don't specify phy_type to UTMI at set the proper register then? The same goes PHY_CLK_VALID which is not availe on the former two. Add something sane to dts that this is later core revision and then check for PHY_CLK_VALID. Don't ifdef things. The ehci code already sets the USB_EN so might want to sync things there. Sebastian -- 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
