[PATCH 1/3] fsl_soc.c cleanup

Kumar Gala galak at kernel.crashing.org
Wed Sep 12 02:22:34 EST 2007


On Sep 11, 2007, at 10:51 AM, Scott Wood wrote:

> Kumar Gala wrote:
>> Yep.  However, after some discussion with Segher on this for 83xx/ 
>> 85xx/86xx I think we want to keep the reg prop and have it cover  
>> the initial soc registers [size on 83xx is 0x100, size on 85xx/ 
>> 86xx would be 0x1000].
>> What we need is a saner way to determine immr on 82xx & 8xx.   
>> Segher's rule is that a given "reg" prop shouldn't overlap w/any  
>> other reg.  We currently violate that on 8xx.  Not as clear on  
>> 82xx if we do that.
>> I'm thinking on 8xx we should move to grabbing a top level compat  
>> value (mpc8xx) and use the SPRN_IMMR to set immrbase.
>
> Any particular reason to special-case it, when we already need code  
> to do it the other way for every other fsl soc?

If you suggest a sane way of getting the value let me know.  The  
mpc8xx doesn't appear to have what I would call 'soc' level registers  
like 83xx/85xx/86xx does.  How do you propose we determine the immrbase?

>> On mpc82xx-pq2 we could add a immr "device" to search for.
>
> Enh.  The soc node *is* the immr "device".  I'd rather add a node  
> for the "initial" registers (they generally don't involve  
> configuring the immr "bus" itself, but rather the chipselect bus  
> and other miscellaneous things) if needed, get rid of /soc/reg, and  
> have ranges cover the whole immr.

> And why is 82xx-pq2 special?  Wouldn't you need this on 83xx, 85xx,  
> and 86xx as well?

The range will cover the whole immr space on 83xx/85xx/86xx.

82xx-pq2 is special in that its soc regs are in the middle of the  
immr address map.

- k



More information about the Linuxppc-dev mailing list