Re: MI overrides of bus_dma(9), bus_space(9), pci(9)

[David Young <dyoung%pobox.com@localhost>]

On Fri, Mar 12, 2010 at 08:58:11PM +0100, Matthias Drochner wrote:
> 
> [pci bus space alloc]
> dyoung%pobox.com@localhost said:
> > > The new methods should be part of the pci(9) API. That kind of
> > > bus space management is inherently bus specific.
> > Do you think that bus_space_alloc(9) should go away, then?
> 
> It shouldn't go away, it it needed where the MI pci hierarchy meets
> MD semantics, at the host bridge.
> 
> For me, bus_space_* and the bus_addr_t types refer to a platforms
> native "main bus" which is basically what comes out of the MMU.
> MI buses should use fixed width types to describe their interfaces.

According to my understanding of bus_space(9), bus_addr_t alone
can unambiguously describe an address on the target bus, from the
perspective of all of the agents directly connected to that bus.

Only the tuple [bus_space_handle_t, bus_addr_t] unambiguously describes
the same address from the perspective of the CPU, however.

bus_space_tag_t tells us what the target bus is, and how to operate on
it.

Does that sound about right to you?

> > And what about bus_space_map(9)?
> 
> Here is the question whether we want to support PCI where it is not
> a "native" bus and mapped by a MD host bridge.

Let's say "maybe someday." :-) I'm interested in accessing a PCI bus
over IEEE 1394.

> > Certainly I could introduce pci_space_alloc(9) with a similar signature
> > as bus_space_alloc().
> 
> There is no guarantee anyway that eg. the PCI I/O space corresponds
> to an I/O space known to bus_space_alloc()...

I think that in that case we will have no bus_space_tag_t for PCI I/O
space.  How will problems arise for bus_space_alloc()?

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933