Req review: OF_decode_addr()
t.moestl at tu-bs.de
Tue Sep 2 08:40:37 PDT 2003
On Mon, 2003/09/01 at 19:18:13 -0700, Marcel Moolenaar wrote:
> 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
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
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
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 Moestl <t.moestl at tu-bs.de> http://www.tu-bs.de/~y0015675/
<tmm at FreeBSD.org> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
More information about the freebsd-sparc64