SOC registers/immr determination from device tree (was Re: [PATCH 1/3] fsl_soc.c cleanup)
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
>>>>> 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
>> 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
> 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
> 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.
More information about the Linuxppc-dev