mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mikael Pettersson <mikpe@csd.uu.se>
To: trini@kernel.crashing.org
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: PATCH][4/7] perfctr-2.7.2 for 2.6.6-mm2: PowerPC
Date: Sat, 15 May 2004 16:37:55 +0200 (MEST)	[thread overview]
Message-ID: <200405151437.i4FEbtWM001341@harpo.it.uu.se> (raw)

On Fri, 14 May 2004 11:07:06 -0700, Tom Rini wrote:
>> perfctr-2.7.2 for 2.6.6-mm2, part 4/7:
>[snip]
>> --- linux-2.6.6-mm2/drivers/perfctr/ppc.c	1970-01-01 01:00:00.000000000 +0100
>[snip]
>> +#define SPRN_MMCR0	0x3B8	/* 604 and up */
>[snip]
>> +#define MMCR2_RESERVED		(MMCR2_SMCNTEN | MMCR2_SMINTEN | MMCR2__RESERVED)
>
>All of these belong in <asm-ppc/reg.h>.

Will do. The _RESERVED masks are sometimes more related to the driver
than the hardware, so I think I'll keep those in the driver. But all
the hardware-related defines can be moved.

>[snip]
> +static int __init generic_init(void)
>> +{
>> +	static char generic_name[] __initdata = "PowerPC 60x/7xx/74xx";
>> +	unsigned int features;
>> +	enum pll_type pll_type;
>> +	unsigned int pvr;
>> +
>> +	features = PERFCTR_FEATURE_RDTSC | PERFCTR_FEATURE_RDPMC;
>> +	pvr = mfspr(SPRN_PVR);
>> +	switch( PVR_VER(pvr) ) {
>> +	case 0x0004: /* 604 */
>> +		pm_type = PM_604;
>> +		pll_type = PLL_NONE;
>> +		features = PERFCTR_FEATURE_RDTSC;
>> +		break;
>
>This should all be done with cputable bits I would think.
>arch/ppc/kernel/cputable.c and include/asm-ppc/cputable.h
>(CPU_FTR_PERFCTR_PLL_{NONE,604e,...) and then
>if (cur_cpu_spec[i]->cpu_features & CPU_FTR_PERFCTL_PLL_NONE)
>  pll_type = PLL_NONE
>
>Or might that be bigger, code wise, in the end?

For the cputable framework I would need at least 11 feature bits
(5 for pm_type, 6 for pll_type), with more later if/when G5 docs
ever become public. <asm-ppc/cputable.h> currently has 14 free
feature bits.

Encoding these as enumeration subfields in the high end of
cpu_features instead would require 3+3 bits (preferably 4+4
for future expansion).

So I can:
1. steal a big chunk of the remaining cpu_features bits, or
2. add pm_type and pll_type fields to struct cpu_spec, or
3. continue to keep this in the driver

Which would you prefer?

/Mikael

         reply	other threads:[~2004-05-15 14:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-14 14:11 Mikael Pettersson
2004-05-14 18:07 ` Tom Rini
2004-05-15 14:37   ` Mikael Pettersson [this message]
2004-05-17 17:23     ` Tom Rini

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=200405151437.i4FEbtWM001341@harpo.it.uu.se \
    --to=mikpe@csd.uu.se \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=trini@kernel.crashing.org \
    /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

all inboxes | Powered by JetHome®