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

[Matt Thomas <matt%3am-software.com@localhost>]

On Mar 11, 2010, at 11:40 AM, David Young wrote:

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

I don't see the point to this.

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

bus_dma_subregion can be used for that.  So bus_space_subregion.

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

Personally, I don't think it's needed at all.