From: Deng-Cheng Zhu <dczhu@mips.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: John Crispin <john@phrozen.org>, <linux-mips@linux-mips.org>,
<kevink@paralogos.com>
Subject: Re: [PATCH v2 1/2] MIPS: fix/enrich 34K APRP (APSP) functionalities
Date: Tue, 22 May 2012 15:05:54 +0800 [thread overview]
Message-ID: <4FBB3AD2.1040802@mips.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1205212350070.3701@eddie.linux-mips.org>
On 05/22/2012 07:17 AM, Maciej W. Rozycki wrote:
> On Mon, 21 May 2012, Deng-Cheng Zhu wrote:
>
>>> What's so Malta-specific in the VPE loader anyway? It's a CPU feature,
>>> not a board-specific one.
>>
>> Well, first off, for VPE loader itself, when it comes to CPS we have
>> vpe_run() that derives from amon_cpu_start() in arch/mips/mti-malta/malta-
>> amon.c. There is no implementation of amon_cpu_start() on other platforms.
>
> Hmm, there's nothing platform-specific there, the file is pretty generic,
> it could be moved to arch/mips/kernel/ or thereabouts. That applies to
> <asm/mips-boards/launch.h> too, before you ask
Yeah, agree with you. I didn't do it simply because I'm not sure :)
> (you may want to use alloc_bootmem or suchlike instead of hardcoding the
> trampoline page, though it's probably pretty safe to assume the end of
> the exception handler page is available everywhere).
I'm not quite clear about this. Do you mean to bypass the arbitrary monitor
in vpe_run() (in other words, to directly bring up the vpe in vpe_run())?
Why do we need to worry about writing to the cpulaunch data?
>> Secondly, I suppose VPE loader works uniquely for APRP, and part of APRP
>> (such as IRQ related stuff) depends on platform code. So it makes sense
>> (IMO) to impose the dependency of APRP on the root (VPE loader).
>
> Hmm, does it really? It sounds wrong to me, it shouldn't use any
> hardware interrupts, and software interrupts again are available
> everywhere, at least on the MT processors now in existence.
>
> There's nothing platform-specific referred to from arch/mips/kernel/vpe.c
> AFAICT (and I trust in Beth having got this piece right). I reckon it
> used to work with CONFIG_MIPS_SIM too, though I could imagine the
> configuration got neglected a bit as it is somewhat unusual.
Oh, When I said IRQ related stuff I meant the interrupt specific changes in
rtlx.c (not vpe.c) which correspond to those in malta-int.c. They are
there to resolve some issues (Please refer to the code changes and added
comments in these 2 files in PATCH #1 and #2.).
Thanks for your review,
Deng-Cheng
WARNING: multiple messages have this Message-ID (diff)
From: Deng-Cheng Zhu <dczhu@mips.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: John Crispin <john@phrozen.org>,
linux-mips@linux-mips.org, kevink@paralogos.com
Subject: Re: [PATCH v2 1/2] MIPS: fix/enrich 34K APRP (APSP) functionalities
Date: Tue, 22 May 2012 15:05:54 +0800 [thread overview]
Message-ID: <4FBB3AD2.1040802@mips.com> (raw)
Message-ID: <20120522070554.rIqtXxZyt6PFNf8Z4Pj45sQESF-uxBUd-sHwa04PHn0@z> (raw)
In-Reply-To: <alpine.LFD.2.00.1205212350070.3701@eddie.linux-mips.org>
On 05/22/2012 07:17 AM, Maciej W. Rozycki wrote:
> On Mon, 21 May 2012, Deng-Cheng Zhu wrote:
>
>>> What's so Malta-specific in the VPE loader anyway? It's a CPU feature,
>>> not a board-specific one.
>>
>> Well, first off, for VPE loader itself, when it comes to CPS we have
>> vpe_run() that derives from amon_cpu_start() in arch/mips/mti-malta/malta-
>> amon.c. There is no implementation of amon_cpu_start() on other platforms.
>
> Hmm, there's nothing platform-specific there, the file is pretty generic,
> it could be moved to arch/mips/kernel/ or thereabouts. That applies to
> <asm/mips-boards/launch.h> too, before you ask
Yeah, agree with you. I didn't do it simply because I'm not sure :)
> (you may want to use alloc_bootmem or suchlike instead of hardcoding the
> trampoline page, though it's probably pretty safe to assume the end of
> the exception handler page is available everywhere).
I'm not quite clear about this. Do you mean to bypass the arbitrary monitor
in vpe_run() (in other words, to directly bring up the vpe in vpe_run())?
Why do we need to worry about writing to the cpulaunch data?
>> Secondly, I suppose VPE loader works uniquely for APRP, and part of APRP
>> (such as IRQ related stuff) depends on platform code. So it makes sense
>> (IMO) to impose the dependency of APRP on the root (VPE loader).
>
> Hmm, does it really? It sounds wrong to me, it shouldn't use any
> hardware interrupts, and software interrupts again are available
> everywhere, at least on the MT processors now in existence.
>
> There's nothing platform-specific referred to from arch/mips/kernel/vpe.c
> AFAICT (and I trust in Beth having got this piece right). I reckon it
> used to work with CONFIG_MIPS_SIM too, though I could imagine the
> configuration got neglected a bit as it is somewhat unusual.
Oh, When I said IRQ related stuff I meant the interrupt specific changes in
rtlx.c (not vpe.c) which correspond to those in malta-int.c. They are
there to resolve some issues (Please refer to the code changes and added
comments in these 2 files in PATCH #1 and #2.).
Thanks for your review,
Deng-Cheng
next prev parent reply other threads:[~2012-05-22 7:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-17 8:51 [PATCH v2 0/2] MIPS: enable APRP (APSP) and add features - v2 Deng-Cheng Zhu
2012-05-17 8:51 ` Deng-Cheng Zhu
2012-05-17 8:51 ` [PATCH v2 1/2] MIPS: fix/enrich 34K APRP (APSP) functionalities Deng-Cheng Zhu
2012-05-17 8:51 ` Deng-Cheng Zhu
2012-05-17 12:30 ` John Crispin
2012-05-18 8:10 ` Deng-Cheng Zhu
2012-05-18 8:10 ` Deng-Cheng Zhu
2012-05-18 18:06 ` John Crispin
2012-05-20 21:32 ` Maciej W. Rozycki
2012-05-21 3:23 ` Deng-Cheng Zhu
2012-05-21 3:23 ` Deng-Cheng Zhu
2012-05-21 23:17 ` Maciej W. Rozycki
2012-05-22 7:05 ` Deng-Cheng Zhu [this message]
2012-05-22 7:05 ` Deng-Cheng Zhu
2012-05-22 22:12 ` Maciej W. Rozycki
2012-05-23 9:07 ` Deng-Cheng Zhu
2012-05-23 9:07 ` Deng-Cheng Zhu
2012-05-17 8:51 ` [PATCH v2 2/2] MIPS: enable CPS multicore APRP (APSP) Deng-Cheng Zhu
2012-05-17 8:51 ` Deng-Cheng Zhu
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=4FBB3AD2.1040802@mips.com \
--to=dczhu@mips.com \
--cc=john@phrozen.org \
--cc=kevink@paralogos.com \
--cc=linux-mips@linux-mips.org \
--cc=macro@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox