From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sricharan R Date: Tue, 2 Apr 2013 22:59:18 +0530 Subject: [U-Boot] Potential issue with recent OMAP PRCM struct unification In-Reply-To: <515B0A7C.7080801@ti.com> References: <515AA5A5.7090607@ti.com> <11BF9239-335A-4D2A-9A4C-A2CEAA5F4349@prograde.net> <515AF3EF.9010802@ti.com> <515AF69E.6080504@ti.com> <515AFF5E.7020509@ti.com> <515B0A7C.7080801@ti.com> Message-ID: <515B156E.1060607@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>>>> 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