[PATCH] mips: set ST0_MX flag for MDMX

[PATCH] mips: set ST0_MX flag for MDMX

[Matt Turner]

As the comment in commit 3301edcb says, DSP and MDMX share the same
config flag bit.

Without this set, MDMX instructions cause Illegal instruction errors.

Signed-off-by: Matt Turner <mattst88@gmail.com>
---
Is MDMX implemented by anything other than some Broadcom CPUs? Is it
totally replaced by DSP?

I had a terrible time finding any documentation on it (which is annoying
because Volume IV-b covering MDMX is referenced by all the MIPS64 documents.)
but finally found a copy here: www.enlight.ru/docs/cpu/risc/mips/MDMXspec.pdf

If it's dead, it's too bad because it's a pretty cool ISA.

 arch/mips/kernel/traps.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index cfdaaa4..89ead75 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -1548,7 +1548,7 @@ void __cpuinit per_cpu_trap_init(void)
 #endif
 	if (current_cpu_data.isa_level == MIPS_CPU_ISA_IV)
 		status_set |= ST0_XX;
-	if (cpu_has_dsp)
+	if (cpu_has_dsp || cpu_has_mdmx)
 		status_set |= ST0_MX;
 
 	change_c0_status(ST0_CU|ST0_MX|ST0_RE|ST0_FR|ST0_BEV|ST0_TS|ST0_KX|ST0_SX|ST0_UX,
-- 
1.7.3.4

Re: [PATCH] mips: set ST0_MX flag for MDMX

[Sergei Shtylyov]

Hello.

On 04-05-2012 2:40, Matt Turner wrote:

> As the comment in commit 3301edcb

    Please also specify that commit's summary in parens.

> says, DSP and MDMX share the same
> config flag bit.

> Without this set, MDMX instructions cause Illegal instruction errors.

> Signed-off-by: Matt Turner<mattst88@gmail.com>
> ---
> Is MDMX implemented by anything other than some Broadcom CPUs? Is it
> totally replaced by DSP?

> I had a terrible time finding any documentation on it (which is annoying
> because Volume IV-b covering MDMX is referenced by all the MIPS64 documents.)
> but finally found a copy here: www.enlight.ru/docs/cpu/risc/mips/MDMXspec.pdf

> If it's dead, it's too bad because it's a pretty cool ISA.

WBR, Sergei

Re: [PATCH] mips: set ST0_MX flag for MDMX

[Matt Turner]

On Fri, May 4, 2012 at 7:16 AM, Sergei Shtylyov <sshtylyov@mvista.com> wrote:
> Hello.
>
>
> On 04-05-2012 2:40, Matt Turner wrote:
>
>> As the comment in commit 3301edcb
>
>
>   Please also specify that commit's summary in parens.
>
>
>> says, DSP and MDMX share the same
>> config flag bit.

Everything in the first sentence after the comma *is* the summary of
that commit. "DSP and MDMX share the same config flag bit"

Matt

Re: [PATCH] mips: set ST0_MX flag for MDMX

[Maciej W. Rozycki]

Hi Matt,

> As the comment in commit 3301edcb says, DSP and MDMX share the same
> config flag bit.
> 
> Without this set, MDMX instructions cause Illegal instruction errors.

 NAK, it's all pretty and nice, but I am afraid you're missing the point 
with your change.  The bit has its purpose, the MDMX accumulator has to be 
saved and restored -- just as the DSP or the FPU context -- between task 
switches and the bit provides for doing that lazily (of course you can do 
that eagerly instead if you like).

> Is MDMX implemented by anything other than some Broadcom CPUs? Is it
> totally replaced by DSP?

 You can have both ASEs on a single processor and they serve different 
purposes as far as I can tell.  I think NEC had an implementation as well, 
but it could have been an older revision than Broadcom's.

> I had a terrible time finding any documentation on it (which is annoying
> because Volume IV-b covering MDMX is referenced by all the MIPS64 documents.)
> but finally found a copy here: www.enlight.ru/docs/cpu/risc/mips/MDMXspec.pdf

 That's the old spec, back from SGI days, using the COP2 opcode space.  
It may not have been implemented and is certainly obsolete.  COP2 is 
available for user-defined coprocessors in the current architecture 
definition and MDMX instructions use different encodings (peek at 
libopcodes for details).

> If it's dead, it's too bad because it's a pretty cool ISA.

 I don't think MaDMaX is dead, it's still referred to from the 
architecture spec as of revision 3.12 and I am fairly sure you'll be able 
to implement it in your processor if you get the right architecture 
licences.

  Maciej

Re: [PATCH] mips: set ST0_MX flag for MDMX

[Matt Turner]

On Wed, May 9, 2012 at 1:20 PM, Maciej W. Rozycki <macro@linux-mips.org> wrote:
>> As the comment in commit 3301edcb says, DSP and MDMX share the same
>> config flag bit.
>>
>> Without this set, MDMX instructions cause Illegal instruction errors.
>
>  NAK, it's all pretty and nice, but I am afraid you're missing the point
> with your change.  The bit has its purpose, the MDMX accumulator has to be
> saved and restored -- just as the DSP or the FPU context -- between task
> switches and the bit provides for doing that lazily (of course you can do
> that eagerly instead if you like).

Okay. It looks like I also need to add save/restoring of the MDMX
accumulator to arch/mips/power/cpu.c and
arch/mips/include/asm/switch_to.h:finish_arch_switch()?

Re: [PATCH] mips: set ST0_MX flag for MDMX

[Maciej W. Rozycki]

On Wed, 9 May 2012, Matt Turner wrote:

> >  NAK, it's all pretty and nice, but I am afraid you're missing the point
> > with your change.  The bit has its purpose, the MDMX accumulator has to be
> > saved and restored -- just as the DSP or the FPU context -- between task
> > switches and the bit provides for doing that lazily (of course you can do
> > that eagerly instead if you like).
> 
> Okay. It looks like I also need to add save/restoring of the MDMX
> accumulator to arch/mips/power/cpu.c and
> arch/mips/include/asm/switch_to.h:finish_arch_switch()?

 More or less, though I think you want to switch the MDMX state lazily as 
it's tied to the FPU -- MDMX instructions require CP0.Status.CU1 to be set 
to execute; it's implementation dependent whether you'll get a Coprocessor 
Unusable or an MDMX Unusable exception when CP0.Status.CU1 and 
CP0.Status.MX are both zero and an MDMX instruction is executed.  And 
moving the MDMX state every time will be wasting processor's time as 
nothing is going to use it (apart from the app you intend to write, I 
presume ;) ).

 Then there's stuff like ptrace(2), signal frames, perhaps more -- to say 
nothing of the userland side -- for full support.

  Maciej