From: Kevin Hilman <khilman@deeprootsystems.com>
To: Olof Johansson <olof@lixom.net>
Cc: "Premi, Sanjeev" <premi@ti.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [RFC] Common mechanism to identify Si revision
Date: Thu, 10 Sep 2009 10:54:46 -0700 [thread overview]
Message-ID: <87bpliadnd.fsf@deeprootsystems.com> (raw)
In-Reply-To: <20090906124639.GA22239@lixom.net> (Olof Johansson's message of "Sun\, 6 Sep 2009 07\:46\:39 -0500")
Olof Johansson <olof@lixom.net> writes:
> On Thu, Sep 03, 2009 at 04:14:28PM +0530, Premi, Sanjeev wrote:
>> Hi,
>>
>> Currently there are multiple mechanisms for identifying the si revisions.
>>
>> Most places the comparison is against omap_rev() as a whole number. Example:
>>
>> arch/arm/mach-omap2/board-3430sdp.c:695: if (omap_rev() > OMAP3430_REV_ES1_0)
>> arch/arm/mach-omap2/board-3430sdp.c:728: if (omap_rev() > OMAP3430_REV_ES1_0)
>>
>> Then, there are custom macros. Example (cpu.h):
>>
>> #define CHIP_GE_OMAP3430ES3_1 (CHIP_IS_OMAP3430ES3_1)
>> #define CHIP_GE_OMAP3430ES3 (CHIP_IS_OMAP3430ES3_0 | \
>> CHIP_GE_OMAP3430ES3_1)
>> #define CHIP_GE_OMAP3430ES2 (CHIP_IS_OMAP3430ES2 | \
>> CHIP_GE_OMAP3430ES3)
>>
>> The problem with comparing against a whole number is that comparison is invalid
>> for another processor series. E.g. OMAP3430 and OMAP3517.
>>
>> Here, I am proposing a common mechanism to identify the si revision; that focuses
>> on the revision bits alone. (See code below)
>>
>> The usage would then be (example):
>>
>> if (omap_rev() > OMAP3430_REV_ES1_0)
>>
>> To
>>
>> if (cpu_is_omap34xx() && OMAP_REV_GT(OMAP_ES_1_0)
>
> What's the purpose of most of these checks in the first place? I can
> see two immediate needs:
>
> 1) To check for various errata and do appropriate workarounds
>
> 2) To check if the current chip has a certain feature
>
> Both of these could just as well be abstracted away such that you use
> tests on the form:
>
> if (OMAP_HAS_ERRATA_FOO) ...
>
> or:
> if (OMAP_FEATURE_FOO) ...
>
> And then move the actual checking of a feature into the header file
> where the errata/feature setups are defined.
>
>
> There's two major benefits to this:
>
> 1) Readability. No need to sit and look up in a manual why there's a
> check for version X here.
> (and/or no need to add a specific comment about it).
>
> 2) Keeping changes centralized. If there's a new revision or chip,
> there's just one header file to update, not 20 different source files.
>
> For example, a bunch of the checks in pm34xx.c would be nicer to have as:
>
> if (OMAP_HAS_USBHOST())
>
I tend to agree with Olaf here and am in favor of the new 'features'
patch that Sanjeev has already proposed.
That doesn't mean that I'm opposed to this change in principle, but
would rather see most of the omap_rev() and cpu_is_* checks disappear
in favor of more generic omap_has_feature() checks.
Kevin
next prev parent reply other threads:[~2009-09-10 17:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-03 10:44 [RFC] Common mechanism to identify Si revision Premi, Sanjeev
2009-09-03 10:49 ` Premi, Sanjeev
2009-09-06 12:46 ` Olof Johansson
2009-09-07 6:03 ` Premi, Sanjeev
2009-09-07 12:34 ` Olof Johansson
2009-09-07 13:02 ` Premi, Sanjeev
2009-09-07 14:09 ` Olof Johansson
2009-09-10 17:54 ` Kevin Hilman [this message]
2009-09-11 13:04 ` Cousson, Benoit
2009-09-11 15:33 ` Premi, Sanjeev
2009-09-10 9:29 ` Paul Walmsley
2009-09-11 11:24 ` Premi, Sanjeev
2009-09-19 14:41 ` Paul Walmsley
2009-09-23 4:20 ` Premi, Sanjeev
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=87bpliadnd.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=linux-omap@vger.kernel.org \
--cc=olof@lixom.net \
--cc=premi@ti.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