SOC registers/immr determination from device tree (was Re: [PATCH 1/3] fsl_soc.c cleanup)
galak at kernel.crashing.org
Wed Sep 12 02:45:47 EST 2007
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
They could be in a sub node if there is a clear subnode for them to
More information about the Linuxppc-dev