From: Rajendra Nayak <rnayak@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>,
Benoit Cousson <b-cousson@ti.com>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 00/18] OMAP4: PM data big spring cleanup and fixes
Date: Fri, 08 Jul 2011 09:56:29 -0700 [thread overview]
Message-ID: <4E1736BD.5070301@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1107080031440.24181@utopia.booyaka.com>
On 7/7/2011 11:39 PM, Paul Walmsley wrote:
> On Thu, 7 Jul 2011, Tony Lindgren wrote:
>
>> * Rajendra Nayak<rnayak@ti.com> [110706 22:26]:
>>> On 7/6/2011 12:19 AM, Paul Walmsley wrote:
>>>>
>>>> Patch 16, to me, belongs best with the 4460 support series and so I'll see
>>>> if it makes sense to fit it in there somewhere.
>>>
>>> Paul,
>>>
>>> Do you want me to base the 4460 support series on one of your branches
>>> and re-post including the above patch?
>>
>> Do we really need to do that patching right now to add base 4460 support?
>>
>> If we're just doing a bunch of renames all over the place to add support
>> for a new processor variant, something is wrong. This is exactly the kind
>> of "crazy churn" Linus was complaining about. In this case the crazy churn
>> is "let's rename 4430 to 44XX all over the place".
>>
>> To me it's sane to assume that we can have most of 4430 features on 4460
>> and don't need to rename 4430 to 44XX for that. Adding 4460 should be
>> just add few new 4460 defines, then do an arch_initcall to fixup things
>> between 4430 and 4460.
>>
>> It would be nice to get the base 4460 support merged as the patches look
>> ready to go otherwise. Rajendra, I suggest you take a quick look and see
>> if you can leave out the dependency to the 4430 to 44XX rename patch to
>> add minimal 4460 support. Then we can patch in the missing features later
>> on, most likely we don't even need the arch_initcall fixup initially either.
>>
>> This would also leave out the dependency between the various patch
>> series which will always lead into issues with merging code. Changes to
>> the infrastructure issues like this should have been patched away early.
>> The merge window is about to start and we're still waiting for the
>> dependencies to get sorted out.
>
> Rajendra's patch series doesn't require the 4430 -> 44XX changes in the
> PRM/CM macros (Benoît's patch 16). That patch can be put in a separate
> series, if you like.
Paul, I could not find any 4430 -> 44XX changes in any PRM/CM macros
in Benoit's patch 16. Instead, I see he is updating the CHIP_IS_* macros
similar to what I did in my series for Powerdomain/Clockdomain.
>
> It does require changing CHIP_IS_OMAP4430 to CHIP_IS_OMAP44XX in the
> powerdomains, clockdomains, etc.
And in hwmod, which is what Benoit's patch 16 does I guess.
If we drop all these, the only alternative is to change the way the
different SoC variant's are handled in these different frameworks
the way Tony suggested, by having SoC specific lists.
> To me, that seems reasonable since the
> 4460 isn't simply a die shrink, it has some other changes on it; but I
> guess you have a different view on that.
>
> I will add acks/reviewed-by:s on the 4460 patches, and maybe you can
> decide which ones you'd like to merge, if any.
>
>
> - Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-07-08 16:56 UTC|newest]
Thread overview: 44+ 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
2011-07-08 7:32 ` Tony Lindgren
2011-07-08 9:04 ` Peter De Schrijver
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 [this message]
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=4E1736BD.5070301@ti.com \
--to=rnayak@ti.com \
--cc=b-cousson@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=tony@atomide.com \
/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