linux-mips
[Top] [All Lists]

Re: patch / rfc

To: Pete Popov <ppopov@embeddedalley.com>
Subject: Re: patch / rfc
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Fri, 26 Aug 2005 14:10:05 +0100 (BST)
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-reply-to: <1125006681.14435.1065.camel@localhost.localdomain>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1125006681.14435.1065.camel@localhost.localdomain>
Sender: linux-mips-bounce@linux-mips.org
On Thu, 25 Aug 2005, Pete Popov wrote:

> This is an experimental (though tested) patch for early ioremap support
> on mips, before mem_init runs. Something like this is only needed on
> certain SoCs that have all of their I/O on high addresses such that they
> can't me ioremapped through kseg1.

 Hmm, wouldn't a temporary large page and a wired TLB entry be an easier 
solution?  Somebody designing these SoCs must have taken such an approach 
into account when deciding to put I/O devices outside the space that's 
directly accessible through unmapped spaces, so I'd expect them all to be 
reachable in a single page of the largest size supported by a given 
implementation.  Especially as not all software is expected to implement 
fully-featured page management.  This entry would of course be no longer 
available after the final paging setup (TLBs tend to be too small for 
entries to be wasted).

> I think the CONFIG_64 stuff needs to removed since we don't need it. The
> patch was tested on a MIPS32 CPU only. Some of the significant changes:

 Well, MIPS64 has XPHYS, so there is no need for going through paging for 
ioremap() at all.

> - trap_init() became early_trap_init() since too much stuff happens
> there that is needed to support early ioremap. The old trap_init() is
> now empty.

 That just provides a strong suggestion considering an alternative 
approach, such as one proposed above is not a bad idea -- this changes the 
order subsystems are initialized for the MIPS platform, which makes it 
different from all the others and therefore problematic.

> - added plat_setup_late() call. All ports would need to add that call,
> or at least a placeholder. Early ioremap is possible only at that point.
> However, most of the code in each plat_setup() can be moved to
> plat_setup_late()

 Which means it should rather be a function pointer initialized somewhere 
earlier, possibly in plat_setup() and then:

static void __init null_plat_setup_late(void) { }
void (*plat_setup_late)(void) __initdata = null_plat_setup_late;
[...]
        plat_setup_late()

or:

void (*plat_setup_late)(void);
[...]
        if (plat_setup_late)
                plat_setup_late()

or something like that.

  Maciej

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