linux-mips
[Top] [All Lists]

Re: [PATCH 35/37] Set c0 status for ST0_KX on Cavium OCTEON.

To: Chad Reese <kreese@caviumnetworks.com>
Subject: Re: [PATCH 35/37] Set c0 status for ST0_KX on Cavium OCTEON.
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Sun, 26 Oct 2008 18:51:03 +0000 (GMT)
Cc: Ralf Baechle <ralf@linux-mips.org>, ddaney@caviumnetworks.com, linux-mips@linux-mips.org, Tomaso Paoletti <tpaoletti@caviumnetworks.com>, Paul Gortmaker <Paul.Gortmaker@windriver.com>
In-reply-to: <49051A78.8080601@caviumnetworks.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1224809821-5532-1-git-send-email-ddaney@caviumnetworks.com> <1224809821-5532-36-git-send-email-ddaney@caviumnetworks.com> <20081026124821.GN25297@linux-mips.org> <49051A78.8080601@caviumnetworks.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Alpine 1.10 (LFD 962 2008-03-14)
On Sun, 26 Oct 2008, Chad Reese wrote:

> The Octeon IO space regions are significantly larger than a 32bit kernel
> could tlb map easily. The entire range takes 49 bits to address. As a

 Do you need them all at once?  If not, you may be able to get away with 
ioremap() called on demand.

> not particularly clean, but working alternative, we enable 64bit
> addressing in the kernel and used XKPHYS to access IO. Every access was
> surrounded by a local_irq_save/local_irq_restore. Since this is ugly to
> the extreme, maybe we should drop being able to boot a 32bit kernel on
> Octeon until something better is worked out.

 Good idea anyway I would say.  With 64-bit processors support for a 
32-bit kernel may be a nice feature, but really only if it works straight 
away with no strange hacks.  Otherwise a 64-bit kernel is the obvious 
choice providing a superset of the functionality, including but not 
limited to support for the same plain 32-bit (o32) userland if need be.  
And with the GCC/GAS changes to support -msym32 that happened a while ago 
the overhead from using a 64-bit kernel has become quite negligible.

  Maciej

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