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

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

On Wed, Mar 10, 2010 at 11:35:42PM +0900, Izumi Tsutsui wrote:
> > MI overrides of bus_space(9) and bus_dma(9) will work analogously to the
> > above.
> 
> - Are those overrides mandatory or optional?

They're mandatory on platforms where there is a PCI bus.

> - Could you show specific examples of exceptions, resouce management
>   for bus_space(9) and bus_dma(9) too?

Exceptions: we can trap PCI exceptions, isolate the device that produced
    the exception, log the exception and/or resolve it.  For example, we
    can provide bus_space_{peek,poke}_{1,2,4,8}(9), or we can ascribe an
    exception to a particular device, notify or deactivate its driver.

    Likewise, we can ascribe memory-access violations (such as an IOMMU
    may trap) to a particular bus master, and notify or deactivate the
    bus master's driver.

Resource management:

    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).

> - How much performance impact is expected for bus_space(9) changes
>   on ports that use macro for access functions?

I have surveyed bus_space_{read,write}_{1,2,4}(9) implementations.  Here
are the the architectures where I think performance may get worse---I
put archs without PCI in [brackets]:

        arc, sh3, sparc64, [x68k]: an inline function accesses the space
            directly.

        cobalt, [luna68k], [mvme68k], [news68k], [newsmips], [next68k],
            [pmax][**], [vax], [sun68k], ia64: a macro accesses the
            space directly.

Performance may or may not get worse:

        [hp300]: a macro tests for a function pointer and either makes
            an indirect function call or accesses the space directly.

Performance will probably NOT get worse:

        algor, alpha, [amiga], [amigappc], arm, atari, dreamcast,
            ews4800mips, hp700, hpcmips, [hpcsh], [mac68k], powerpc,
            landisk, mips: a macro makes an indirect function call

        amd64, i386, sgimips: a function call.

        sparc[*]: an inline subroutine makes an indirect function call

Let me know if I missed any architecture.

I think that we should switch to MI bus_space_tag on all architectures
that have PCI, and see how it affects performance on arc, sh3, sparc64,
and cobalt.

Dave

*  An inline function accesses the space directly if
   __SLIM_SPARC_BUS_SPACE is #defined, however, it looks to me like that
   #define is never used.

** bus_space_write_{1,2,4} call wbflush()

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