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. -Michael Cashwell _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
