[Top] [All Lists]

Re: [PATCH] MIPS: DECstation HRT calibration bug fixes

To: Thomas Bogendoerfer <>
Subject: Re: [PATCH] MIPS: DECstation HRT calibration bug fixes
From: "Maciej W. Rozycki" <>
Date: Tue, 17 Sep 2013 16:10:54 +0100 (BST)
Cc: Ralf Baechle <>,
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <> <>
User-agent: Alpine 2.03 (LFD 1266 2009-07-14)
On Tue, 17 Sep 2013, Thomas Bogendoerfer wrote:

> >  Thomas, what was the rationale behind arranging things in this way?  Did 
> > you mean to make this code shared among platforms needing it?  I would 
> I really can't remember the reasoning any more, but I guess code sharing
> was a reason.

 That was my guess too, so I guess two guesses are enough to be sure. ;)

> > guess so, but then the copy in arch/mips/dec/prom/ would have to be 
> > removed and macros in <asm/dec/prom.h> adjusted according to the new API 
> > which you didn't do in your change.
> because I didn't have a running DECstation handy.

 Well, TBH, you could have made the same mechanical adjustments across the 
DEC files you made to your platform, or at the very least ping me (cc on 
your patch submission), especially if code sharing was your objective.

> > Also why the need for stack 
> > switching?  It looks like an unnecessary complication to me, any firmware 
> > callbacks exported have to maintain stack integrity or they would be 
> > unusable.  Is that to work around some SNI firmware quirk?
> a 64bit kernel with more than CKSEG0 addressable memory may end up having
> a stack outside of CKSEG0, which is something the 32bit SNI firmware
> doesn't like. I guess the same is true for DECstation, if there is a HW config
> with enough memory.

 Nope, 480MB is the maximum the most capable in this respect DECstation 
can ever take, so it never exceeds the KSEG0 space (the remaining 32MB of 
KSEG0-mapped space is taken for MMIO; some systems also take a further 
1.5GB for aliased TURBOchannel MMIO).  Thanks for confirming.

> >  [And does it work for the SNI in the first place? -- it looks to me like 
> > `o32_stk' has an alignment problem (8 is required for the stack pointer in 
> > the o32 ABI though 4 will often be enough to satisfy hardware); but 
> > perhaps it just happens to get correct alignment by virtue of merely 
> > always following a data object that enforces it, hmm...]
> it worked, but nevertheless fixing the aligment isn't a bad thing.

 OK, I think I've got a plan now.  I don't want to burden the DECstation 
with stack switching or the extra memory use it requires, so I'll reshape 
arch/mips/fw/lib/call_o32.S a bit to fit both platforms.  Will you be able 
and willing to test my code once it's ready with a SNI system?


<Prev in Thread] Current Thread [Next in Thread>