[U-Boot] [PATCH] doc/feature-removal-schedule.txt: Add CONFIG_SYS_(CLOCKS|PADS)_ENABLE_ALL

[Tom Rini <trini@ti.com>]

-----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 <trini@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-----