[U-Boot] [PATCH] doc/feature-removal-schedule.txt: Add CONFIG_SYS_(CLOCKS|PADS)_ENABLE_ALL
Tom Rini
trini at ti.com
Wed Apr 10 17:16:39 CEST 2013
-----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 at 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-----
More information about the U-Boot
mailing list