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