[Nouveau] [PATCH 1/3] fbmem: fix aperture overlapping check

[Marcin Slusarz]

On Tue, Apr 13, 2010 at 06:28:21AM +1000, Dave Airlie wrote:
> On Mon, 2010-04-12 at 13:34 +0200, Marcin Slusarz wrote:
> > On Mon, Apr 12, 2010 at 09:54:28AM +1000, Dave Airlie wrote:
> > > On Sat, 2010-04-10 at 21:55 +0200, marcin.slusarz at gmail.com wrote:
> > > > fb_do_apertures_overlap is returning wrong value when one aperture
> > > > is completely whithin the other. Add generic ranges_overlap macro
> > > > (probably kernel.h candidate) and use it here.
> > > > 
> > > 
> > > That doesn't seem right.
> > > 
> > > The rules are:
> > > 
> > > the generic aperture has to be equal or smaller than the hw aperture,
> > > otherwise the generic driver will be trashing random hw pieces on the
> > > machine.
> 
> > Why "it has to"? Why generic aperture can't start one byte before hw?
> 
> Think about how it works a bit more, the answer is obvious.
> 
> The hw aperture is defined by the actual hardware, not by the OS or my
> code. The PCI apertures are well defined. Now for a generic driver like
> vesa or offb to access the hardware it needs to access the hw apertures.
> 
> It can't go accessing one byte before the hw aperture, as that will
> crash the machine, or write to some other devices hw.

Ok, thanks for explanation. I'll drop this patch and rebase the others.

> > > So with that in mind, the check makes sure the generic aperture starts
> > > somewhere inside the hw aperture, which the test clearly gets right.
> > 
> > So your only objection is that it's impossible with the current code?
> > 
> > > Have you got a pointer to a machine where it fails?
> > 
> > No, it failed with an artifical test while I was working on vga16fb handoff
> > (unfinished).
> 
> You won't be able to make this work for vga16fb from what I can see
> since it access 0xa000 directly, not via any of the defined apertures
> that vesafb/offb use. vga16fb will need a different approach I suspect.

Yeah, there's an idea to claim 0xa0000 as an aperture of vga16fb and then
do the same in KMS driver but only if it's the primary card. 
(You hinted to use SHADOW resource bit to check whether card is primary)
I think I'll try this approach soon.

Marcin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/