SOC registers/immr determination from device tree (was Re: [PATCH 1/3] fsl_soc.c cleanup)

[Kumar Gala]

On Sep 11, 2007, at 11:24 AM, Scott Wood wrote:

> Kumar Gala wrote:
>> On Sep 11, 2007, at 10:51 AM, Scott Wood wrote:
>>> 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?
>
> What exactly do you mean by "soc"-level registers?

registers that effect the soc-processor core interaction/bus (things  
like LAWs, CCSRBAR, etc).

> I propose we do it by defining the first (and ideally only, but  
> that's another argument) entry in ranges as the immr, and getting  
> rid of /soc/reg.

I disagree.  I don't think we want to start overloading the meaning  
of something like 'ranges' in that way.

>>> 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.
>
> And why can't it do that on 82xx?

we can cover the whole range, thats fine.  We just need a different  
mechanism to determine immr base.

>> 82xx-pq2 is special in that its soc regs are in the middle of the  
>> immr address map.
>
> The /soc node is misnamed; it should really be /immr.  Why do we  
> need these particular registers to be in /soc/reg rather than a  
> subnode?

They could be in a sub node if there is a clear subnode for them to  
be in.

- k