Date: Tue, 2 Sep 2003 17:40:55 +0200 From: Thomas Moestl <t.moestl@tu-bs.de> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: sparc64@freebsd.org Subject: Re: Req review: OF_decode_addr() Message-ID: <20030902154054.GA691@timesink.dyndns.org> In-Reply-To: <20030902021813.GA2300@dhcp01.pn.xcllnt.net> References: <20030902021813.GA2300@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2003/09/01 at 19:18:13 -0700, Marcel Moolenaar wrote: > Gang, > > Attached a patch to add function OF_decode_addr(). The function > takes a package handle (phandle_t) and returns the physical > (decoded) address at which it resides as well as it space. > This function is needed by uart(4) to for low-level console > access. It would probably be good to have another parameter specifying the number of the register bank to map, for devices which have more than one (i.e. have multiple register structures in their "reg" property). > There's one thing I'm not happy about and that's the call to > ofw_isa_map_iorange(). It makes it impossible to create a kernel > without isa. It makes sense to move the bulk of the code in > OF_decode_addr() to the respective bus drivers and have some > linker set to tie bus name to function pointer. It would actually be quite easy to implement this in a general and almost bus-neutral way. Each bus node has (or should have :) an "#address-cells" and a "#size-cells" property. A "reg" property of a child node is just an array of structures of an address comprised of #address-cells 32-bit words and a region size comprised of #size-cells words. The "ranges" property of a bus in turn is an array of structures of child addresses of #address-cells words, and a mapped address and region size (of the size specified by the #address-cells or the #size-cells property of the parent, respectively). All the address spaces etc. are encoded in the addresses, so they alone are enough to find out the physical address for a node; this is done simply by mapping upward in the device tree on each "ranges" property there is, using the properties described above to dynamically size the comparisons and property structures. In a final step, we need to look at the last node we mapped at to determine the bus space we need to use to create a bus tag (really, the only required information is whether we need little-endian or big-endian accesses). This should the only bus-specific code required. There are apparently cases where the #foo-cells properties are missing; a sane default should be 2. Of course, there might also be problems with the usual firmware quirks. > I'm not sure it's important to have that right away or if we can > commit this and deal with that later? Just commit it. I can take a stab at implementing a more general version later if you'd like (but it could take a month or so before I will get to do it). - Thomas -- Thomas Moestl <t.moestl@tu-bs.de> http://www.tu-bs.de/~y0015675/ <tmm@FreeBSD.org> http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030902154054.GA691>