[Top] [All Lists]

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

To: Chad Reese <>
Subject: Re: [PATCH 35/37] Set c0 status for ST0_KX on Cavium OCTEON.
From: "Maciej W. Rozycki" <>
Date: Sun, 26 Oct 2008 18:51:03 +0000 (GMT)
Cc: Ralf Baechle <>,,, Tomaso Paoletti <>, Paul Gortmaker <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <>
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.


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