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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
