IMAP_ADDR on PPC 8xx

[Walter L. Wimer III]

Thanks, Dan!  This is exactly the kind of feedback I was seeking.

Based on your comments and Wolfgang's comments, I conclude that:

     1. The U-Boots on my MPC885ADS and MPC8272ADS boards are
        unequivocally broken and should be replaced with ones from the
        official U-Boot source repositories that use IMMR values
        matching the Linux kernel source.
     2. For now, there is no pressing need to fix the existing drivers;
        they may continue dereferencing IMAP_ADDR directly as they
        currently do.
     3. In the future, the drivers will ultimately migrate toward
        individually calling ioremap() and maintaining their own private
        pointers.


Thanks again,

Walt 



On Tue, 2006-05-09 at 17:51 -0400, Dan Malek wrote:
> On May 9, 2006, at 3:52 PM, Walter L. Wimer III wrote:
> 
> > Exactly.  I think this kind of "automatic adaption" to the particular
> > platform is what should be in the vanilla kernel.
> 
> This does not mean you can choose some arbitrary value.
> There is a small range of high memory addresses that will
> work successfully for IMMR.  You may not see any problems
> right away, but depending upon drivers selected and the
> software features used, some problems will crop up.
> There are also MMU performance enhancements that may
> be used with certain values, and guaranteed kernel crashes
> at some point in the future when abused.
> 
> With Linux, the IMMR should always have a value of
> 0xf0000000 or 0xff000000 for best results.
> 
> > This was the second major part of our 2.6.11.7-based patch.  It
> > performed a single ioremap(), stored the result in a global  
> > pointer, and
> > then used that pointer in all the drivers instead of using IMAP_ADDR
> > directly.
> 
> This is not an acceptable practice.  We are removing all
> global pointers like this, and any driver that needs access to
> some or all of the IMMR space should be individually mapping
> those regions it needs.  Under the covers of ioremap() we are
> performing various alignment and reuse of address spaces
> in order to support things like performance enhancements
> and cache coherent regions.
> 
> Thanks.
> 
> 	-- Dan
>