Re: pci_mapreg_map(9) and prefetchable BARs

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

On Wed, Aug 10, 2011 at 08:04:16AM +0100, David Laight wrote:
> On Tue, Aug 09, 2011 at 06:11:29PM -0500, David Young wrote:
> > On Tue, Aug 09, 2011 at 05:38:43PM -0400, Michael wrote:
> > > Hello,
> > > 
> > > Why would it fail if the BAR is marked as prefetchable but someone
> > > requests a non-prefetchable mapping? The bit is just a hint.
> > 
> > My phrasing was probably awkward.  It wouldn't fail in that case.
> > 
> > Here's the proposal:
> > 
> > 1 Safety first: pci_mapreg_map() should map every BAR as
> >   if it is non-prefetchable (i.e., non-cached, non-write
> >   combining, order enforced) unless the caller passes the hint
> >   BUS_SPACE_MAP_PREFETCHABLE.
> > 
> > 2 pci_mapreg_map() should turn on caching, write-combining, et cetera,
> >   on a prefetchable BAR if the caller passes BUS_SPACE_MAP_PREFETCHABLE.
> > 
> > 3 pci_mapreg_map() should return 1 (indicating an error) before it
> >   violates #1.
> 
> Do we have any way for a driver to map different parts of a BAR
> with different options?

You can get the region's address & size using pci_mapreg_info(),
divide the region, and bus_space_map() each division with different
options.

I don't think that we can divide a region in any old way, though.  The
options may apply on the page level.

> Or even the same part of the a BAR with different options?

It seems like mapping different/same parts of a BAR with different
options could lead to behavior that is machine-dependent at best and
unpredictable at worst.  Sometimes I have wondered what happens on x86
when you have N virtual aliases for the same physical page, e.g., one
that is write-combining, one uncached, and one write-back---also, how
would those mappings ever happen except by mistake?

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 344-0444 x24