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

Kumar Gala galak at kernel.crashing.org
Wed Sep 12 03:54:58 EST 2007


On Sep 11, 2007, at 12:03 PM, Scott Wood wrote:

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

In PCI its not order dependent.  Its just a PCI address.  If you want  
to propose a SOC address that encodes other information like the PCI  
address does feel free to.  However, order shouldn't be special.  Its  
too fragile.

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

I think that's the only user for it.  Let's separate the issues.

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

I suggest you propose a solution to determine IMMR base w/o having  
using a specific entry in the range property and w/o introducing a  
new property.  I believe it can be done via either a new device type/ 
sub-node or regs in the soc node.  However, I don't believe you'll be  
able to come up with a solution that works for all the FSL platforms.

- k



More information about the Linuxppc-dev mailing list