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