| Message ID | 1364924383-27101-1-git-send-email-trini@ti.com |
|---|---|
| State | Accepted |
| Delegated to: | Tom Rini |
| Headers | show |
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 -----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-----
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
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!
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 -----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-----
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
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(+)