On Fri, 2005-08-26 at 14:10 +0100, Maciej W. Rozycki wrote:

On Thu, 25 Aug 2005, Pete Popov wrote:

quoted

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?  

Yes, you can do that. It's just not as nice and the problem is that you
either have to remember these wired mappings, flush them later, and
properly ioremap them, or forever use up a few tlbs.

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.  

They may or may not be reachable with a single tlb. I've twice now seen
new SoCs with a huge I/O address range. There may or may not be a good
reason for this but we are not always hired early enough to change the
design.

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).

Right.

quoted

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.

Right. I can easily change that.

quoted

- 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.

Well, yes and no. On PowerPC, they do all this ahead of trap_init so
their trap_init is empty as well. Looking at the code, I just don't see
any reason why we can't do that init earlier.

quoted

- 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.

Sure, we can do that.

Thanks,

Pete