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

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

[Tom Rini]

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

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

[Michael Cashwell]

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

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

[Tom Rini]

-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRWyn5AAoJENk4IS6UOR1WrL8P/RSPNhBQtTxVTWoFnS+3asna
hbMW8A9UDC06Ak8YnmMiJvgCSGu6bxIQK+1s+Bw1v9rw9MmFdEMW9NPiYVOwB1E8
3TABs5oAKaLkMET337iObajcEl2QQyddWywc78VigIR8qAsw5ZKzx5odnnpwcX65
f3qlbqfsB0qJDMwnETvAAmTuQXfq2oFfXfRym8cgGTH9JPA2WwsHDJvgyKsvwn9J
s07P/H7wGAdGyXeAOmsKvPt/3P91ViivWz7sEsRvC/D9hyF+ZR7Kf3w+fnmmGeQd
ofT5ew8FJa0GeAZh1D2AdsrrWbiAtKV3MmP1Hsxbd291g3jHbGY7552yYB7bXaJ4
WZwjS56DypFDjlUFZASJUAIuQFRcyEAtOMSlltdEXWO20FiU0WxYa5iMl+/U11Hv
yJgLoQgDe+E6th4yupsuVPVSkV/CN1D46Ib7BUxdWEcUpOgybOgWb3qcxNnkflwF
lb/ZkxsPRuFc6jQzgqVLhGHP60807+Pe11zdsKxymZMfClfvGd8sve0Wemba8c7o
4GYbn0ujABJPPDMDIak+fVbQDOh2X0LE2xz6ScJfEbdlJzk3hdvrrwibEZgQSiQ/
nw7IdBqPgZtm5WJR9Aw/Dygwo/0vM1GGDwFEGG4/gpROao+rwCpXZz2zf7x+nq+u
o1rLQLE6+VjMaPXsci8K
=PqUF
-----END PGP SIGNATURE-----

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

[Michael Cashwell]

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

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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130408/cc935a8c/attachment.pgp>

[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@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] [PATCH] doc/feature-removal-schedule.txt: Add CONFIG_SYS_(CLOCKS|PADS)_ENABLE_ALL

[Tom Rini]

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

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

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130408/8e72b174/attachment.pgp>