linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: rnayak@ti.com (Rajendra Nayak)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 00/18] OMAP4: PM data big spring cleanup and fixes
Date: Fri, 08 Jul 2011 00:22:04 -0700	[thread overview]
Message-ID: <4E16B01C.2080604@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1107080053100.24181@utopia.booyaka.com>

On 7/8/2011 12:11 AM, Paul Walmsley wrote:
> On Thu, 7 Jul 2011, Martin Fouts wrote:
>
>> From: Tony Lindgren [tony at atomide.com]
>>
>>> The second problem we have here is "why does adding 4460 support depend
>>> on a cosmetic clean-up patch". That dependency should not exist at all
>>> as it seems the 4460 patches should work even without this patch.
>>
>> I agree. Had the original submitter had the foresight to realize that
>> the code should work for all 44xx family processors, we would have no
>> issue at all.
>
> Uhhh...
>
> The original 4430 data, which is mostly what we're talking about here, was
> added in 2009.  Maybe a few people inside TI knew what was going to change
> and what was going to be the same for future OMAP4 parts.  But even if
> someone did know, the decision of what to call a chip often isn't up to
> engineers, it's up to marketing, which picks whatever name they like.
> You know, like Linux 2.6.40^H^H^H^H^H^H3.0.
>
> So back in 2009, the submitter and maintainers were faced with a choice:
>
> Option 1. Submit patches with facts.  "OMAP4430".  Don't speculate what
> future, as-yet-nonexistent products will be numbered, and what their
> feature set will be.  Plan to generalize later once it is known exactly
> what needs to be generalized.
>
> Option 2. Try to predict what marketing will call the next chip, and what
> features will still be present, then put that into the codebase.
> "OMAP44XX".  Hope you guess right so you don't have to change them all if
> marketing or engineering comes up with something different.
>
> So, what's the right answer?
>
> I probably can't tell you that, but I can tell you that in 2009, option 1
> seemed more technically conservative.  So that's what we did.  Maybe that
> isn't the right answer, though.

I completely agree with Paul. What if the 4460 of today was called
4640 for some reason. (Well we do have a 3630, don't we)
Would the OMAP44XX work then, no. We would need a OMAP4XXX instead.

>
>
> - Paul

  reply	other threads:[~2011-07-08  7:22 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-01 20:41 [PATCH v2 00/18] OMAP4: PM data big spring cleanup and fixes Benoit Cousson
2011-07-01 20:41 ` [PATCH v2 01/18] OMAP4: cm: Remove RESTORE macros to avoid access from SW Benoit Cousson
2011-07-01 20:41 ` [PATCH v2 02/18] OMAP4: prcm_mpu: Fix indent in few macros Benoit Cousson
2011-07-01 20:41 ` [PATCH v2 03/18] OMAP4: clockdomain data: Fix data order and wrong name Benoit Cousson
2011-07-01 20:41 ` [PATCH v2 04/18] OMAP4: clock data: Add sddiv to USB DPLL Benoit Cousson
2011-07-01 20:41 ` [PATCH v2 05/18] OMAP4: clock data: Remove usb_host_fs clkdev with NULL dev Benoit Cousson
2011-07-01 20:41 ` [PATCH v2 06/18] OMAP4: clock data: Re-order some clock nodes and structure fields Benoit Cousson
2011-07-01 20:41 ` [PATCH v2 07/18] OMAP4: clock data: Fix max mult and div for USB DPLL Benoit Cousson
2011-07-01 20:41 ` [PATCH v2 08/18] OMAP4: clock data: Rename clock flags from 443X to 44XX Benoit Cousson
2011-07-10  2:03   ` Paul Walmsley
2011-07-01 20:41 ` [PATCH v2 09/18] OMAP4: clock data: Remove McASP2, McASP3 and MMC6 clocks Benoit Cousson
2011-07-06  6:59   ` Paul Walmsley
2011-07-01 20:41 ` [PATCH v2 10/18] OMAP4: clock data: Remove UNIPRO clock nodes Benoit Cousson
2011-07-06  7:00   ` Paul Walmsley
2011-07-01 20:41 ` [PATCH v2 11/18] OMAP4: clock data: Add missing divider selection for auxclks Benoit Cousson
2011-07-01 20:41 ` [PATCH v2 12/18] OMAP4: prcm: Remove references to non-existant peripherals Benoit Cousson
2011-07-01 20:41 ` [PATCH v2 13/18] OMAP4: hwmod data: Fix L3 interconnect data order and alignement Benoit Cousson
2011-07-01 20:41 ` [PATCH v2 14/18] OMAP4: hwmod data: Remove un-needed parens Benoit Cousson
2011-07-01 20:41 ` [PATCH v2 15/18] OMAP4: hwmod data: Fix bad alignement Benoit Cousson
2011-07-01 20:41 ` [PATCH v2 16/18] OMAP4: hwmod data: Replace CHIP_IS_OMAP4430 by OMAP44XX Benoit Cousson
2011-07-01 20:41 ` [PATCH v2 17/18] OMAP4: hwmod data: Modify DSS opt clocks Benoit Cousson
2011-07-02  9:13   ` Tomi Valkeinen
2011-07-02  9:36     ` Tomi Valkeinen
2011-07-09  8:26       ` Paul Walmsley
2011-07-09  8:24     ` Paul Walmsley
2011-07-01 20:41 ` [PATCH v2 18/18] OMAP4: hwmod data: Change DSS main_clk scheme Benoit Cousson
2011-07-06  7:19 ` [PATCH v2 00/18] OMAP4: PM data big spring cleanup and fixes Paul Walmsley
2011-07-06 19:31   ` Rajendra Nayak
2011-07-07  6:01     ` Tony Lindgren
2011-07-07  7:24       ` Martin Fouts
2011-07-07 12:10         ` Tony Lindgren
2011-07-07 14:30           ` Martin Fouts
2011-07-07 15:48             ` Tony Lindgren
2011-07-08  7:33               ` Paul Walmsley
2011-07-08  7:11             ` Paul Walmsley
2011-07-08  7:22               ` Rajendra Nayak [this message]
2011-07-08  7:32                 ` Tony Lindgren
2011-07-28 17:08           ` Cousson, Benoit
2011-07-08  6:39       ` Paul Walmsley
2011-07-08 13:16         ` Tony Lindgren
2011-07-08 16:56         ` Rajendra Nayak
2011-07-06 22:41   ` Paul Walmsley
2011-07-28 17:11   ` Cousson, Benoit

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=4E16B01C.2080604@ti.com \
    --to=rnayak@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).