[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <643E69AA4436674C8F39DCC2C05F76386319985A02@HQMAIL03.nvidia.com>
Date: Wed, 5 Feb 2014 13:41:28 -0800
From: Andrew Chew <AChew@...dia.com>
To: Stephen Warren <swarren@...dotorg.org>,
"daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"thierry.reding@...il.com" <thierry.reding@...il.com>,
"rob@...dley.net" <rob@...dley.net>,
"grant.likely@...aro.org" <grant.likely@...aro.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"abrestic@...omium.org" <abrestic@...omium.org>,
"dgreid@...omium.org" <dgreid@...omium.org>,
"katierh@...omium.org" <katierh@...omium.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
"linux-watchdog@...r.kernel.org" <linux-watchdog@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: RE: [PATCH v2 2/3] clocksource: tegra: Define timer bases in header
file
> > +/* Tegra 20 timers */
> > +#define TEGRA20_TIMER1_BASE 0x0
> > +#define TEGRA20_TIMER2_BASE 0x8
> > +#define TEGRA20_TIMER3_BASE 0x50
> > +#define TEGRA20_TIMER4_BASE 0x58
> > +
> > +/* Tegra 30 timers */
> > +#define TEGRA30_TIMER1_BASE TEGRA20_TIMER1_BASE
> > +#define TEGRA30_TIMER2_BASE TEGRA20_TIMER2_BASE
> > +#define TEGRA30_TIMER3_BASE TEGRA20_TIMER3_BASE
> > +#define TEGRA30_TIMER4_BASE TEGRA20_TIMER4_BASE
> > +#define TEGRA30_TIMER5_BASE 0x60
> > +#define TEGRA30_TIMER6_BASE 0x68
> > +#define TEGRA30_TIMER7_BASE 0x70
> > +#define TEGRA30_TIMER8_BASE 0x78
> > +#define TEGRA30_TIMER9_BASE 0x80
> > +#define TEGRA30_TIMER0_BASE 0x88
>
> Why put the SoC name in the define names? Why not just have
> TIMER1_BASE..TIMER10_BASE (that should be 10 not 0 as in your patch,
> right?) and have the driver know that 1..4 are valid on Tegra20, and
> 1..10 are valid on later chips.
>
> I guess if the defines are moved into a header file, adding a TEGRA_ prefix
> does make sense.
>
> But I wonder if it wouldn't be simpler for the Tegra WDT driver to just call a
> function on the Tegra clocksource driver to find out which timer
> ID(s) to avoid using? Even simpler would be to just put a comment in the
> WDT driver saying that timer 5 was chosen arbitrarily, but if it's changed make
> sure not to conflict with the clocksource driver (and an equivalent change to
> the clocksource driver).
Alright, I think I'll just go with putting a comment in the WDT driver then, so that
We don't need to add this new header file.
--
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