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.