[U-Boot] Potential issue with recent OMAP PRCM struct unification

[Sricharan R]

On Tuesday 02 April 2013 10:12 PM, Tom Rini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 04/02/2013 11:55 AM, Sricharan R wrote:
>> On Tuesday 02 April 2013 08:47 PM, Tom Rini wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> On 04/02/2013 11:06 AM, Sricharan R wrote:
>>>> On Tuesday 02 April 2013 05:59 PM, Michael Cashwell wrote:
>>>>> On Apr 2, 2013, at 5:32 AM, Sricharan R <r.sricharan at ti.com>
>>>>>  wrote:
>>> [snip]
>>>>>> Also why are you enabling the non-essential clocks ?
>>>>>
>>>>> Because I must be able to boot Linux kernels as far back as 
>>>>> 3.0.8 which predates this paradigm shift.
>>>>>
>>>>>> Now enabling non-essential clocks is deprecated and they
>>>>>> are **not** by enabled by default.
>>>>>
>>>>> As a point of clarification, are you asserting that 
>>>>> CONFIG_SYS_CLOCKS_ENABLE_ALL and CONFIG_SYS_ENABLE_PADS_ALL
>>>>> have been officially deprecated (e.g.: is planned for removal
>>>>> from u-boot)?
>>>>>
>>>>> There is no mention of this anywhere within the source tree,
>>>>>  including in any documentation or README and, IMO, it would
>>>>> be very premature given that at least 4 Linux kernel lines
>>>>> needing these inits are still within their longterm support
>>>>> window.
>>>>>
>>>>> But clearly until such removal happens dropping any that were
>>>>>  previously handled is a regression.
>>>>>
>>>>> Thanks for the assistance!
>>>>>
>>>> Yes, thats why we still have kept it for testing. But now,
>>>> there are already patches to fix this in the kernel being
>>>> posted, and probably all of them should be fixed shortly. Once
>>>> that is done, all of this can be removed.
>>>
>>> So, here's my 2 cents on this.  We can't up and drop these
>>> options from U-Boot until there's a complete / viable kernel
>>> tthhat doesn't need them.  I'm _not_ saying we need to test every
>>> patchset vs an old kernel or anything, but we shouldn't
>>> intentionally make life harder on folks, until we can just pull
>>> the option all together (and say use a new kernel, or an older
>>> u-boot).
>>>
>> Hmm, Agree this should not be broken unintentionally. But because
>> we purposefully deprecated this, kernel is now getting fixed.
>> Fixing any thing towards this deprecated one, will again introduce 
>> the luxury of not addressing in kernel, which is not good. If we
>> propose of removing this in U-BOOT after every thing is fixed in
>> kernel, we still will have of need of supporting for older
>> kernels..
> 
> Yes, I'm assuming the kernel folks to continue with adding clocks they
> need in the right places now that the main event has happened and we
> aren't enabling more things until / unless we need them.  And since I
> think that's going at reasonable speed, I don't think we need to draw
> a dated line in the sand, just one that says we shall remove the
> option, once a reasonable (read: most IO works) kernel tree is
> available that doesn't need this, we can remove it.  Maybe we can set
> a hope to remove date?  How about v2013.07?
> 
 Yes, sounds good. Hopefully kernel fixed by then

Regards,
 Sricharan