SOC registers/immr determination from device tree (was Re: [PATCH 1/3] fsl_soc.c cleanup)
scottwood at freescale.com
Wed Sep 12 03:03:31 EST 2007
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.
>>> 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
> 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?
More information about the Linuxppc-dev