[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: MI overrides of bus_dma(9), bus_space(9), pci(9)
On Thu, Mar 11, 2010 at 10:09:25PM +0100, Matthias Drochner wrote:
> dyoung%pobox.com@localhost said:
> > PCI-* bridges can override bus_space_alloc(9)/bus_space_free(9)
> > in order to (1) allocate space from the upstream bus, (2)
> > widen/narrow its I/O- or memory-space window. Then we can
> > provide a reliable rbus-like facility to detachable buses
> > through bus_space(9).
> This should be a separate set of methods, for two reasons:
> -It is unneeded if no device hotplug is intended. NetBSD used to be
> useful for small/embedded systems, so it should be possible to
> leave unneeded code out.
I have a couple of comments/questions about that:
(1) If a bus-bridge driver is not configured in the kernel, or if its
module is unloaded, then the code is left out.
(2) Do you intend for the new methods to belong to a new API, or to
bus_space(9)? What would the methods' names and contracts be?
> -The bus_space_* functions assume a platform dependent bus_addr_t
> width. This doesn't make sense for buses behind some bridge.
> Examples like 1394 and SCI come to mind which are wider than
> any practical processor bus (sparsely populated of course).
> Use of bus_addr_t et al. should be limited to md code.
I think that you are trying to tell me about some existing limitation to
This is what bus_space(9) has to say about bus_addr_t:
The bus_addr_t type is used to describe bus addresses. It must be an
unsigned integral type capable of holding the largest bus address usable
by the architecture. This type is primarily used when mapping and unmap-
ping bus space.
I take that to mean that in order to access a 1394 bus via bus_space(9)
on i386, where bus_addr_t was until very recently 32 bits wide, we will
need to extend bus_addr_t to 64 bits.
David Young OJC Technologies
dyoung%ojctech.com@localhost Urbana, IL * (217) 278-3933
Main Index |
Thread Index |