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

[Scott Wood]

Kumar Gala wrote:
> On Sep 11, 2007, at 11:24 AM, Scott Wood wrote:
>> 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'm shocked. :-)

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

As opposed to overloading the meaning of 'reg'?

It's no different than how PCI ranges are treated -- we interpret, in a 
bus-specific way, that certain ranges mean certain things.  In the case 
of fsl immr/cssr buses, the first range would mean the immr/cssr space.

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

I'm unconvinced.

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

Does anything actually use /soc/reg as anything other than an input to
get_immrbase()?  If not, we can defer defining such nodes until there's
actually a need.

It'd probably be more efficient to discuss this in person; can you stop
by my cube sometime when you're around and not in a meeting?

-Scott