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
next prev parent 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).