public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: khilman@ti•com (Kevin Hilman)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
Date: Thu, 10 May 2012 14:39:39 -0700	[thread overview]
Message-ID: <8762c3ww9w.fsf@ti.com> (raw)
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EA1BF14@DBDE01.ent.ti.com> (Vaibhav Hiremath's message of "Wed, 9 May 2012 08:59:49 +0000")

"Hiremath, Vaibhav" <hvaibhav@ti•com> writes:

> On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
>> Vaibhav Hiremath <hvaibhav@ti•com> writes:
>> 
>> > The function __omap2_set_globals() can be common across all
>> > platforms/architectures, even in case of omap4, internally it
>> > calls same set of functions as in __omap2_set_globals() function
>> > (except for sdrc).
>> 
>> OK so far.
>> 
>> > This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
>> > so that we can reuse same function across omap2/3/4...
>> 
>> But what happens when a single kernel is built that has support for an
>> SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
>> 
>
> As such Nothing...I looking into this direction while implementing.
>
> In that case, sdrc.c file will be compiled in and execution will jump to
> omap2_set_globals_sdrc(). But inside this function, we are already checking 
> whether the omap2_globals->sdrc and omap2_globals->sms for NULL and then use 
> it.
>
> And function omap2_sdrc_init() is also depends on machine, so in case of
> Am33xx, it won't get into sdrc execution at all. And in case of omap4, it 
> will.

Then why bother with the #ifdef at all?

If it already safe to call on all SoCs, just get rid of the #ifdef all
together.

>> In that case this new SOC_HAS_OMAP2_SDRC will be set, and
>> set_globals_sdrc() will be called even for the SoCs without SDRC.
>> 
>> So, rather than add a new Kconfig option for this, I would rather see 
>> you using the existing runtime feature check for the SDRC: omap_has_sdrc()
>> 
>
> There is NO difference between runtime feature check Vs this patch, refer to the function implementation,
>
> void __init omap2_set_globals_sdrc(struct omap_globals *omap2_globals)
> {
> 	if (omap2_globals->sdrc)
> 		omap2_sdrc_base = omap2_globals->sdrc;
> 	if (omap2_globals->sms)
> 		omap2_sms_base = omap2_globals->sms;
> }
>
> The initialization happens after checking for NULL, so even if you execute it or not, the variable are set to NULL in case of am33xx.
>
> So I don't find any difference between runtime and this patch.

Except readability.

Kevin

  reply	other threads:[~2012-05-10 21:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-08 19:52 [PATCH-V2 0/4] ARM: OMAP2+: Cleanup series in order to remove ARCH_OMAPx dependency Vaibhav Hiremath
2012-05-08 19:52 ` [PATCH-V2 1/4] ARM: OMAP2+: CLEANUP: All OMAP2PLUS uses omap-device.o target so add one entry Vaibhav Hiremath
2012-05-08 19:52 ` [PATCH-V2 2/4] ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c Vaibhav Hiremath
2012-05-10 23:02   ` Paul Walmsley
2012-05-11  7:01     ` Hiremath, Vaibhav
2012-05-08 19:52 ` [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals Vaibhav Hiremath
2012-05-08 22:38   ` Kevin Hilman
2012-05-09  8:59     ` Hiremath, Vaibhav
2012-05-10 21:39       ` Kevin Hilman [this message]
2012-05-11  6:09         ` Hiremath, Vaibhav
2012-05-11  6:37           ` Sricharan R
2012-05-11  6:43             ` Hiremath, Vaibhav
2012-05-11 21:54           ` Kevin Hilman
2012-05-14  9:23             ` Hiremath, Vaibhav
2012-05-08 19:52 ` [PATCH-V2 4/4] ARM: OMAP2+: CLEANUP: Add new config option for different DPLL features Vaibhav Hiremath
2012-05-08 22:50   ` Kevin Hilman
2012-05-09  9:06     ` Hiremath, Vaibhav
2012-05-10 22:35       ` Paul Walmsley
2012-05-11  5:30         ` Hiremath, Vaibhav

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=8762c3ww9w.fsf@ti.com \
    --to=khilman@ti$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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