On Fri, 2005-08-26 at 14:10 +0100, Maciej W. Rozycki wrote:
> 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?
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.
> > 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.
> > - 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.
> > - 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
