[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pci_mapreg_map(9) and prefetchable BARs
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
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?
David Young OJC Technologies
dyoung%ojctech.com@localhost Urbana, IL * (217) 344-0444 x24
Main Index |
Thread Index |