All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Walmsley <paul@pwsan.com>
To: Tony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	"Rajendra Nayak" <rnayak@ti.com>,
	"Benoît Cousson" <b-cousson@ti.com>,
	"Ranjith Lohithakshan" <ranjithl@ti.com>
Subject: Re: [PATCH v2 08/13] OMAP3/4 clock: split into per-chip family files
Date: Tue, 16 Feb 2010 14:54:54 -0700 (MST)	[thread overview]
Message-ID: <alpine.DEB.2.00.1002161453440.10478@utopia.booyaka.com> (raw)
In-Reply-To: <20100216192301.GQ21755@atomide.com>

On Tue, 16 Feb 2010, Tony Lindgren wrote:

> * Paul Walmsley <paul@pwsan.com> [100215 16:56]:
> > 
> > clock34xx_data.c now contains data for the OMAP34xx family, the
> > OMAP36xx family, and the OMAP3517 family, so rename it to
> > clock3xxx_data.c.  Rename clock34xx.c to clock3xxx.c, and move the
> > chip family-specific clock functions to clock34xx.c, clock36xx.c, or
> > clock3517.c, as appropriate.  So now "clock3xxx.*" refers to the OMAP3
> > superset.
> > 
> > The main goal here is to prepare to compile chip family-specific clock
> > functions only for kernel builds that target that chip family.  To get to
> > that point, we also need to add CONFIG_ARCH_* options for those other
> > chip families; that will be done in a future patch, planned for 2.6.35.
> 
> Just to comment on the naming, we should call additional cpu options
> CONFIG_CPU_OMAP3630 etc instead of CONFIG_ARCH_OMAP to avoid confusion.
> 
> I thought about renaming CONFIG_ARCH_OMAP2420 and CONFIG_ARCH_OMAP2430
> into CONFIG_CPU_OMAP2420 and CONFIG_CPU_OMAP2430, but as it covers
> a bunch of drivers too I've postponed that to 2.6.35.

Thanks, I've updated the patch description accordingly to reference
CONFIG_CPU_* rather than CONFIG_ARCH_*.


- Paul

WARNING: multiple messages have this Message-ID (diff)
From: paul@pwsan.com (Paul Walmsley)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 08/13] OMAP3/4 clock: split into per-chip family files
Date: Tue, 16 Feb 2010 14:54:54 -0700 (MST)	[thread overview]
Message-ID: <alpine.DEB.2.00.1002161453440.10478@utopia.booyaka.com> (raw)
In-Reply-To: <20100216192301.GQ21755@atomide.com>

On Tue, 16 Feb 2010, Tony Lindgren wrote:

> * Paul Walmsley <paul@pwsan.com> [100215 16:56]:
> > 
> > clock34xx_data.c now contains data for the OMAP34xx family, the
> > OMAP36xx family, and the OMAP3517 family, so rename it to
> > clock3xxx_data.c.  Rename clock34xx.c to clock3xxx.c, and move the
> > chip family-specific clock functions to clock34xx.c, clock36xx.c, or
> > clock3517.c, as appropriate.  So now "clock3xxx.*" refers to the OMAP3
> > superset.
> > 
> > The main goal here is to prepare to compile chip family-specific clock
> > functions only for kernel builds that target that chip family.  To get to
> > that point, we also need to add CONFIG_ARCH_* options for those other
> > chip families; that will be done in a future patch, planned for 2.6.35.
> 
> Just to comment on the naming, we should call additional cpu options
> CONFIG_CPU_OMAP3630 etc instead of CONFIG_ARCH_OMAP to avoid confusion.
> 
> I thought about renaming CONFIG_ARCH_OMAP2420 and CONFIG_ARCH_OMAP2430
> into CONFIG_CPU_OMAP2420 and CONFIG_CPU_OMAP2430, but as it covers
> a bunch of drivers too I've postponed that to 2.6.35.

Thanks, I've updated the patch description accordingly to reference
CONFIG_CPU_* rather than CONFIG_ARCH_*.


- Paul

  reply	other threads:[~2010-02-16 21:54 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-11 18:16 [PATCH 00/13] OMAP: clock: cleanup series for 2.6.34 Paul Walmsley
2010-02-11 18:16 ` Paul Walmsley
2010-02-11 18:16 ` [PATCH 01/13] OMAP2/3/4 clock: fix DPLL multiplier value errors; also copyrights, includes, documentation Paul Walmsley
2010-02-11 18:16   ` Paul Walmsley
2010-02-11 18:16 ` [PATCH 02/13] OMAP4 clock: drop the CLOCK_IN_OMAP4430 clock flag Paul Walmsley
2010-02-11 18:16   ` Paul Walmsley
2010-02-11 18:16 ` [PATCH 03/13] OMAP2xxx clock: GFX functional clock rates are not independently changeable Paul Walmsley
2010-02-11 18:16   ` Paul Walmsley
2010-02-11 18:16 ` [PATCH 04/13] OMAP2xxx clock: drop DELAYED_APP flag from non-clksel clocks Paul Walmsley
2010-02-11 18:16   ` Paul Walmsley
2010-02-11 18:17 ` [PATCH 05/13] OMAP2 clock: drop CONFIG_PARTICIPANT clock flag Paul Walmsley
2010-02-11 18:17   ` Paul Walmsley
2010-02-11 18:17 ` [PATCH 06/13] OMAP clock: compress clock flags down to a u8 Paul Walmsley
2010-02-11 18:17   ` Paul Walmsley
2010-02-11 18:17 ` [PATCH 07/13] OMAP clock: drop .id field; ensure each clock has a unique name Paul Walmsley
2010-02-11 18:17   ` Paul Walmsley
2010-02-11 18:17 ` [PATCH 08/13] OMAP3/4 clock: split into per-chip family files Paul Walmsley
2010-02-11 18:17   ` Paul Walmsley
2010-02-16  0:58   ` [PATCH v2 " Paul Walmsley
2010-02-16  0:58     ` Paul Walmsley
2010-02-16 19:23     ` Tony Lindgren
2010-02-16 19:23       ` Tony Lindgren
2010-02-16 21:54       ` Paul Walmsley [this message]
2010-02-16 21:54         ` Paul Walmsley
2010-02-16 23:11       ` Russell King - ARM Linux
2010-02-16 23:11         ` Russell King - ARM Linux
2010-02-16 23:47         ` Tony Lindgren
2010-02-16 23:47           ` Tony Lindgren
2010-02-16 23:48         ` Paul Walmsley
2010-02-16 23:48           ` Paul Walmsley
2010-02-11 18:17 ` [PATCH 09/13] OMAP2 clock: split OMAP2420, OMAP2430 clock data into their own files Paul Walmsley
2010-02-11 18:17   ` Paul Walmsley
2010-02-11 18:18 ` [PATCH 10/13] OMAP2430 clock: make func_96m_ck parent-selectable Paul Walmsley
2010-02-11 18:18   ` Paul Walmsley
2010-02-11 18:18 ` [PATCH 11/13] OMAP2 clock: drop DELAYED_APP clock flag Paul Walmsley
2010-02-11 18:18   ` Paul Walmsley
2010-02-11 18:18 ` [PATCH 12/13] OMAP clock: drop RATE_FIXED " Paul Walmsley
2010-02-11 18:18   ` Paul Walmsley
2010-02-16  1:02   ` [PATCH v2 " Paul Walmsley
2010-02-16  1:02     ` Paul Walmsley
2010-02-11 18:18 ` [PATCH 13/13] OMAP4 clock: drop the ALWAYS_ENABLED " Paul Walmsley
2010-02-11 18:18   ` Paul Walmsley
2010-02-16  0:55 ` [PATCH 00/13] OMAP: clock: cleanup series for 2.6.34 Paul Walmsley
2010-02-16  0:55   ` Paul Walmsley

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=alpine.DEB.2.00.1002161453440.10478@utopia.booyaka.com \
    --to=paul@pwsan.com \
    --cc=b-cousson@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=ranjithl@ti.com \
    --cc=rnayak@ti.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 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.