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