[U-Boot] [PATCH] doc/feature-removal-schedule.txt: Add CONFIG_SYS_(CLOCKS|PADS)_ENABLE_ALL
We shall remove these OMAP4/5-specific options in v2013.07, barring insufficient progress on the kernel side.
Cc: Sricharan R r.sricharan@ti.com Signed-off-by: Tom Rini trini@ti.com --- doc/feature-removal-schedule.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
diff --git a/doc/feature-removal-schedule.txt b/doc/feature-removal-schedule.txt index d9a0cc2..58db440 100644 --- a/doc/feature-removal-schedule.txt +++ b/doc/feature-removal-schedule.txt @@ -24,6 +24,22 @@ Who: Wolfgang Denk wd@denx.de
---------------------------
+What: Remove CONFIG_SYS_ENABLE_PADS_ALL and CONFIG_SYS_CLOCKS_ENABLE_ALL +When: Release v2013.07 + +Why: When set these options enable "all" of the pads and clocks found + on OMAP4/5 platforms, so that the Linux Kernel does not have to. + It has been agreed that this goes against the U-Boot design + philosophy and since f3f98bb0 we have not enabled more than is + used in U-Boot. The kernel has been updating drivers to enable + rather than assume pads/clocks have been enabled already. Our + expectation is that by v2013.07 a suitable kernel shall exist that + does not need these options set for a reasonable I/O set to function. + +Who: Tom Rini trini@ti.com and Sricharan R r.sricharan@ti.com + +--------------------------- + What: Users of the legacy miiphy_* code When: undetermined
On Apr 2, 2013, at 1:39 PM, Tom Rini trini@ti.com wrote:
We shall remove these OMAP4/5-specific options in v2013.07, barring insufficient progress on the kernel side. ... +Our expectation is that by v2013.07 a suitable kernel shall exist that does not need these options set for a reasonable I/O set to function.
What, specifically, is meant by "a suitable kernel shall exist"? In practice, there's isn't a single such kernel version.
I'm currently using 3.0.8. That version most assuredly fails miserably without defining CONFIG_SYS_(CLOCKS|PADS)_ENABLE_ALL in u-boot. That kernel is part of the 3.0.x longterm lineage which as I write this is at 3.0.71.
Is there a belief that 3.0.71 would work without the legacy support? That upgrade wouldn't be too bad since kernel ABI changes are not generally done via patch level version changes. But forcing an update to 3.4.x, 3.8.x or even later just to keep current with u-boot is an entirely different thing.
I'm very worried if that's what's being proposed here as it would be very user unfriendly.
-Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/02/2013 02:41 PM, Michael Cashwell wrote:
On Apr 2, 2013, at 1:39 PM, Tom Rini trini@ti.com wrote:
We shall remove these OMAP4/5-specific options in v2013.07, barring insufficient progress on the kernel side. ... +Our expectation is that by v2013.07 a suitable kernel shall exist that does not need these options set for a reasonable I/O set to function.
What, specifically, is meant by "a suitable kernel shall exist"? In practice, there's isn't a single such kernel version.
I'm currently using 3.0.8. That version most assuredly fails miserably without defining CONFIG_SYS_(CLOCKS|PADS)_ENABLE_ALL in u-boot. That kernel is part of the 3.0.x longterm lineage which as I write this is at 3.0.71.
You're on a 3.0.8 from somewhere-within-TI, that's not getting regular updates (or it would be on 3.0.71 or close-to), yes?
Is there a belief that 3.0.71 would work without the legacy support? That upgrade wouldn't be too bad since kernel ABI changes are not generally done via patch level version changes. But forcing an update to 3.4.x, 3.8.x or even later just to keep current with u-boot is an entirely different thing.
I'm very worried if that's what's being proposed here as it would be very user unfriendly.
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.
While the former isn't as close as I would like for various reasons, there is progress on the latter. It's not a replacement today (which is why I didn't set the deadline any sooner, the patches to remove the options have existed since November? or so), but it really better be by v2013.07.
Not that, I'm pretty sure at least, TI is providing LTK-type support, but that window closes at 2 years, which for 3.0 would be right around v2013.07 anyhow.
- -- Tom
On Apr 2, 2013, at 2:56 PM, Tom Rini trini@ti.com wrote:
On 04/02/2013 02:41 PM, Michael Cashwell wrote:
I'm currently using 3.0.8. That version most assuredly fails miserably without defining CONFIG_SYS_(CLOCKS|PADS)_ENABLE_ALL in u-boot. That kernel is part of the 3.0.x longterm lineage which as I write this is at 3.0.71.
You're on a 3.0.8 from somewhere-within-TI, that's not getting regular updates (or it would be on 3.0.71 or close-to), yes?
It's an Android-related project and the kernel is what was current for Ice Cream Sandwich at the time the development started. Being Anddroid-related I expect you can appreciate why kernel updates are not trivial undertakings.
Would 3.0.71 not need the legacy support? I could likely update to 3.0.71 but going to 3.4.x or 3.8.x would have a large ripple effect to the rest of the system.
... forcing an update to 3.4.x, 3.8.x or even later just to keep current with u-boot is an entirely different thing.
I'm very worried if that's what's being proposed here as it would be very user unfriendly.
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.
IMO, that's overly dismissive of the collateral impact of making such a large kernel change. As noted, there are many cases where users can update to the latest patch level but more than that is too invasive.
One could argue that no one's being forced. If a user's kernel is stuck then having their boot loader also be stuck is OK. Perhaps, but it seems a bit artificial.
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.
-Mike
I thought I had replied to this, but I don't see it in my email right now.
On Tue, Apr 02, 2013 at 11:16:43PM -0400, Michael Cashwell wrote:
On Apr 2, 2013, at 2:56 PM, Tom Rini trini@ti.com wrote:
On 04/02/2013 02:41 PM, Michael Cashwell wrote:
I'm currently using 3.0.8. That version most assuredly fails miserably without defining CONFIG_SYS_(CLOCKS|PADS)_ENABLE_ALL in u-boot. That kernel is part of the 3.0.x longterm lineage which as I write this is at 3.0.71.
You're on a 3.0.8 from somewhere-within-TI, that's not getting regular updates (or it would be on 3.0.71 or close-to), yes?
It's an Android-related project and the kernel is what was current for Ice Cream Sandwich at the time the development started. Being Anddroid-related I expect you can appreciate why kernel updates are not trivial undertakings.
Would 3.0.71 not need the legacy support? I could likely update to 3.0.71 but going to 3.4.x or 3.8.x would have a large ripple effect to the rest of the system.
No, 3.0.x is 3.0.x, and quite old.
... forcing an update to 3.4.x, 3.8.x or even later just to keep current with u-boot is an entirely different thing.
I'm very worried if that's what's being proposed here as it would be very user unfriendly.
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.
IMO, that's overly dismissive of the collateral impact of making such a large kernel change. As noted, there are many cases where users can update to the latest patch level but more than that is too invasive.
One could argue that no one's being forced. If a user's kernel is stuck then having their boot loader also be stuck is OK. Perhaps, but it seems a bit artificial.
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.
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.
-Michael Cashwell
-----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
On Tue, Apr 02, 2013 at 07:39:43AM -0000, Tom Rini wrote:
We shall remove these OMAP4/5-specific options in v2013.07, barring insufficient progress on the kernel side.
Cc: Sricharan R r.sricharan@ti.com Signed-off-by: Tom Rini trini@ti.com
Applied to u-boot-ti/master, thanks!
participants (2)
-
Michael Cashwell -
Tom Rini