All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Potential issue with recent OMAP PRCM struct unification
Date: Tue, 2 Apr 2013 12:42:36 -0400	[thread overview]
Message-ID: <515B0A7C.7080801@ti.com> (raw)
In-Reply-To: <515AFF5E.7020509@ti.com>

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

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRWwp8AAoJENk4IS6UOR1WTFwP/iqQsntG0x9Ubos4BjWm521T
yDp+548n72x2yNXuCBXVKj5IwyMtvjMOeuaHmu/TCish1riSpd96aKLtimfXaZum
Me7xfRGzEVGO4VUz8wbzHFZQyfZ6ON9zXjRswSrzj5Rt8Wuc8R7nn10FEsptTWK4
EiID/QjaIr6rl+175h4Qj6js/RrQ76q5iJVkFShSiih++MUISOa7H/msHVbr80G6
S/novDHSRdCGz8OB85tCi+b49qeOSmt3990aW3NXTvkdXDUmBC9BrR1t4n6IyMGi
tUwsJ+I0nyV3vQFb/OcxYNlDfsKELNSEtmqQ74OBBfINrmON+5IhouQ8smK43hFT
4yeeoj9Bcu36LcEYRLu29eBKXAhfnfUMQWHQFTRj5VPNlEUhWd+3dm1sgz2wCLro
srAAJ4R9Aev+fkhpC2JuzbRrAOyBUN3k05T4P3+XomFGbgkvYkNgOtuy4kb4qMus
v0oRT53Ygm0YihKF6wRtktbuYLOEkkSy5zhmEpov7ONQK6BiRtr+14igpFFwJ28x
xg+VhKRE4yvuCRccMUKP+afRhJln+53BW/XIJ7D/8Vs39dg2CsO5yg6cDLUyI/Ns
BM2BRRVE37A6WliDs5119JeKPou6fnN7H3OmsHFDheSkBztjJxI9nmfrNw9husFn
MmqpBh/7hBTDLNTDBELo
=qE1a
-----END PGP SIGNATURE-----

  reply	other threads:[~2013-04-02 16:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-01 15:42 [U-Boot] Potential issue with recent OMAP PRCM struct unification Michael Cashwell
2013-04-02  9:32 ` Sricharan R
2013-04-02 12:29   ` Michael Cashwell
2013-04-02 15:06     ` Sricharan R
2013-04-02 15:17       ` Tom Rini
2013-04-02 15:55         ` Sricharan R
2013-04-02 16:42           ` Tom Rini [this message]
2013-04-02 17:29             ` Sricharan R

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=515B0A7C.7080801@ti.com \
    --to=trini@ti.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.