Req review: OF_decode_addr()

[Marcel Moolenaar]

On Mon, Sep 01, 2003 at 11:49:56PM -0700, John-Mark Gurney wrote:
> Marcel Moolenaar wrote this message on Mon, Sep 01, 2003 at 19:18 -0700:
> > 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.
> 
> You mean physical address as viewed by the CPU, correct?

Yes.

> > This function is needed by uart(4) to for low-level console
> > access.
> > 
> > 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. I'm not sure
> > it's important to have that right away or if we can commit this
> > and deal with that later?
> 
> Why don't you wrap the ebus/isa part around an #if defined(NISA) ||
> defined(NEBUS) to prevent the inclusion of isa when not necessary?

That would work. The sbus part is sufficiently seperated from the
ebus part. 

> I would like to see this code in a more general format instead of in
> a MD file.  OpenFirmware is quite specific on how each bus lists it's
> registers and ranges.  We should leverage this so that other platforms
> don't have to have lots of special code to implement the same thing.

Good point. PowerPC immediately comes to mind. However, there's
a pitfall: The prototype uses both phandle_t and bus_addr_t.
A lot of files include OFW headers, but most do not have both
types visible. A more generic implementation will have a cost:
We need to do a more extensive shuffling/cleaning to get something
that builds. That definitely is beyond my scope.

> I don't have an OFW dump handy, so I can't verify correctness of code.

The code has been tested on an U2 (sbus) and an U5 (ebus/pci).

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net