All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joshua Kinard <kumba@gentoo.org>
To: Matt Turner <mattst88@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux MIPS List <linux-mips@linux-mips.org>
Subject: Re: [PATCH] MIPS: Add R16000 detection
Date: Tue, 20 Jan 2015 00:32:49 -0500	[thread overview]
Message-ID: <54BDE881.3090907@gentoo.org> (raw)
In-Reply-To: <CAEdQ38GHvbbSF0k0mQTAjMd8hn0D0Bg0hE2LHptxpkQV_gohGQ@mail.gmail.com>

On 01/20/2015 00:11, Matt Turner wrote:
> On Mon, Jan 19, 2015 at 8:13 PM, Joshua Kinard <kumba@gentoo.org> wrote:
>> On 01/19/2015 21:43, Matt Turner wrote:
>>> On Mon, Jan 19, 2015 at 4:56 PM, Joshua Kinard <kumba@gentoo.org> wrote:
>>>> On 01/19/2015 14:34, Matt Turner wrote:
>>>>> On Sun, Jan 18, 2015 at 5:30 PM, Joshua Kinard <kumba@gentoo.org> wrote:
>>>>>> diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
>>>>>> index 5342674..3f334a8 100644
>>>>>> --- a/arch/mips/kernel/cpu-probe.c
>>>>>> +++ b/arch/mips/kernel/cpu-probe.c
>>>>>> @@ -833,8 +833,13 @@ static inline void cpu_probe_legacy(struct cpuinfo_mips *c, unsigned int cpu)
>>>>>>                 c->tlbsize = 64;
>>>>>>                 break;
>>>>>>         case PRID_IMP_R14000:
>>>>>> -               c->cputype = CPU_R14000;
>>>>>> -               __cpu_name[cpu] = "R14000";
>>>>>> +               if (((c->processor_id >> 4) & 0x0f) > 2) {
>>>>>> +                       c->cputype = CPU_R16000;
>>>>>> +                       __cpu_name[cpu] = "R16000";
>>>>>> +               } else {
>>>>>> +                       c->cputype = CPU_R14000;
>>>>>> +                       __cpu_name[cpu] = "R14000";
>>>>>> +               }
>>>>>
>>>>> It looks like this is the only hunk that has a functional change, and
>>>>> that is simply setting __cpu_name[cpu] to "R16000"
>>>>>
>>>>> You can do that without adding CPU_R16000 to the enumeration. I don't
>>>>> see that adding it accomplishes anything.
>>>>>
>>>>
>>>> It mirrors what CPU_R14000 and CPU_R12000 do.  I won't rule out that, down the
>>>> road, something about the R16K might be different enough from the R14K to
>>>> require one of these other spots later on, so adding it now isn't going to
>>>> adversely affect things.
>>>
>>> That's justification for removing CPU_R14000 as well, not adding CPU_R16000.
>>>
>>> Otherwise it's just adding useless code.
>>
>> R14000 has a different CPU PRId than R12000 or R10000, so the code that sets
>> the icache/scache linesz wouldn't know to apply to R14K, including the writing
>> the the FrameMask register in CP0.  Octane and Origin2K/Onyx2 can both use
>> R14000 CPUs, so this is a bad suggestion, as removing R14000 detection would
>> render those systems inoperable with those CPUs.  I know, cause I'm the one
>> that actually sent the R14K patch in 9 years ago w/ commit 44d921b2 .
> 
> Sorry, you're not getting it.
> 
> git grep -B1 CPU_R14000
> 
> Notice how all of the instances of CPU_R14000 are preceded by
> CPU_R12000? That's because CPU_R14000 doesn't do anything differently.
> 
> All you should do to remove CPU_R14000 is to set c->cputype =
> CPU_R12000 in the PRID_IMP_R14000 case in cpu-probe.c.

I see what you're getting at, but I disagree with the reasoning.  The code
reads clearer when it's explicitly stated the way it is, rather than fudging
things and treating an R14K as an R12K for a minor gain of a few cycles.

And since I know there's something "weird" about the R14K right now, one of
those case statements might be needed down the road to do something a little
bit differently for R14K versus R12K and such (maybe in the TLB code, if I can
ever wrap my head around that).

In the end, it's Ralf's call on accepting it.

  reply	other threads:[~2015-01-20  5:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-19  1:30 [PATCH] MIPS: Add R16000 detection Joshua Kinard
2015-01-19 19:34 ` Matt Turner
2015-01-20  0:56   ` Joshua Kinard
2015-01-20  2:43     ` Matt Turner
2015-01-20  4:13       ` Joshua Kinard
2015-01-20  5:11         ` Matt Turner
2015-01-20  5:32           ` Joshua Kinard [this message]
2015-01-20 13:51             ` Ralf Baechle
2015-01-21 12:56 ` Joshua Kinard

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=54BDE881.3090907@gentoo.org \
    --to=kumba@gentoo.org \
    --cc=linux-mips@linux-mips.org \
    --cc=mattst88@gmail.com \
    --cc=ralf@linux-mips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.