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

[Michael Cashwell]

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.

-Michael Cashwell