-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/10/2013 10:58 AM, Michael Cashwell wrote: > On Apr 8, 2013, at 1:57 PM, Tom Rini <tr...@ti.com> wrote: > >>>> What I'm saying is that once either mainline, or another >>>> TI-provided tree exists and doesn't need these options set, >>>> they can go away. >>> >>> I want several new u-boot features (DFU, USB host Ethernet, GPT >>> support, etc.) but cannot casually update my Linux kernel. >>> These feature sets are clearly orthogonal and I would lament >>> an all-or- nothing binding that wasn't technically necessary. >> >> Right. By v2012.07 you ought to be able to find an Android tree >> based on a newer kernel rev, that works without all of these >> being enabled in U-Boot. Or you start paying more of the costs >> of needing to stay with legacy software, either backporting >> further changes, or holding a local undo of the removal of the >> pads/conf bits. > > OK, thanks for the clarification. That should be manageable, > especially with the advance notice. > > On a related issue, given the move to have u-boot only init the > hardware it needs we're running into an architecture conflict. > Consider the multitude of, let's say, OMAP4 boards. U-boot > supports different boards having different needs. > > In arch/arm/cpu/armv7/omap-common/hwinit-common.c there are calls > to set_muxconf_regs_essential() and > set_muxconf_regs_non_essential() that are in > board/<vendor>/<board>.c. > > That conceptually makes sense given that some boards might need > busses (like I2C3) that others do not. By making the pin function > and muxing board-level that's cleanly supported. > > But the same doesn't seem to be true for clocks. I don't see a > board- level way to express what clocks are needed. That seems to > be CPU-level (arch/arm/cpu/armv7/omap4/hw_data.c). > > Am I missing something? Shouldn't there be core call outs to a > board- level function like do_clocks_essential() like there is for > muxconf? > > Thanks for any guidance.
Sounds like it's an area that needs more clean-up. Frankly, am33xx took a while to get kinda-sorta generically broken up enough once there were not just a few TI-supported platforms but some custom platforms and then similar-family parts added. OMAP4/5 are on the cusp of making that second step and I imagine there will be some places where assumptions were wrong, or not made fully flexible enough. - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRZYJXAAoJENk4IS6UOR1W2mEQALLoGhPUgXpikohOgt/m/AtI MD6NcvCXEO9I94byjOBCHwwMON2DhL22Iq/RNciNn7EAwgl9eToQlg/QSAJXRQGM PTmPepP9iidRp5KwPqI6UOCUxDxotyGNu9PrL2c/sD1+a1eA60Sbab37tv4krpGW 8OXQUvmxlY/lJjubExvtEDVh4ym+Vw68bF3Mp7+dtozCJoWHiEUzWhZB5vVkjt22 qAJQpozP6cX/XQvJg9Pyy1mgrfIXeLSA5ZxESgyxt03CKTHHv9ZPWMLyvZQO+4Tm oBRhD1of3rsZ1rdpQAzleG3qS8G7hqTXdFz85G+Qj0m1hvOQsRwAkg/E2jYUJpnv mk+S7XLlXbbtLan/SeTnwP5eYj9AHPiRLmQqvijpOvuQKBpTg67wpcb2idH6Uxzx g+19pRfqYjf8y0clLcfcNYq+XdkXkOdEDvro6/n99xN/EgfNBGlUIHB77bYEW8+q akJtOt8+yB/oh1K852nJFr2pXznUPxAEG01zNszF4LRUtzk5NjD8HksWjO/ewfFO CI4fuSbOcPaFzR0sYg24+RoZWe4IRhmud0NOfSbF9a90fF2D1vmTu5vhAF6vry9H BbjI8sCNLcImUbM22OcC7X0MAPp9cEh62UB6JmhhwX50iW61O1/3osyGhp5gaAeX An5eYlDKLQrN4J4cp3Ys =Ufc3 -----END PGP SIGNATURE----- _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
