[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200708100933.46235.marc.pignat@hevs.ch>
Date: Fri, 10 Aug 2007 09:33:45 +0200
From: Marc Pignat <marc.pignat@...s.ch>
To: Hans-Jürgen Koch <hjk@...utronix.de>
Cc: linux-arm-kernel@...ts.arm.linux.org.uk,
"Ulf Samuelsson" <ulf@...el.com>, andrew@...people.com,
trivial@...nel.org, linux-kernel@...r.kernel.org,
Andy Herzig <andrew.herzig@....com>
Subject: Re: [PATCH] at91 pm: Compilation fix for at91sam926x
On Friday 10 August 2007 09:12, Hans-Jürgen Koch wrote:
> Am Freitag 10 August 2007 00:15 schrieb Ulf Samuelsson:
> >
> > > > +#if defined(CONFIG_ARCH_AT91RM9200)
> > > > at91_sys_write(AT91_SDRAMC_SRR, 1); /*
> > > > self-refresh mode */
> >
> > > Why don't use:
> > > if (cpu_is_at91rm9200())
> > > at91_sys_write(AT91_SDRAMC_SRR, 1);
> >
> > What is the benefit?
More readable. (see '#ifdefs are ugly' in Documentation/SubmittingPatches)
> > Will the optimizer remove the code if the CPU is not the at91rm9200?
Optimizer will remove that code if at91rm9200 support is not compiled and
choose at runtime if the cpu support is compiled in.
>
> No, it won't. cpu_is_something() is intended for runtime decisions.
> Remember that the purpose of this patch was to solve a compile time
> issue (see subject). AT91_SDRAMC_SRR isn't defined properly for
> non-9200 processors because they don't have that register. So we need
> something like #ifdef to include this line only on 9200.
Oops, I missed that problem, sorry...
and what about this:
#ifdef CONFIG_ARCH_AT91RM9200
#define sdram_lowpower_enable() at91_sys_write(AT91_SDRAMC_SRR, 1)
#define sdram_lowpower_disable() at91_sys_write(AT91_SDRAMC_SRR, 0)
#else
#define sdram_lowpower_enable()
#define sdram_lowpower_disable()
#endif
and using sdram_lowpower_{enable,disable}() when requiered?
Regards
Marc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists