Em Ter, 2017-11-14 às 20:19 +0000, Chris Wilson escreveu: > Quoting Paulo Zanoni (2017-11-14 20:12:41) > > Em Qui, 2017-11-02 às 17:17 +0200, Ville Syrjala escreveu: > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > Apparently there are some machines that put semi-sensible looking > > > values > > > into the stolen "reserved" base and size, except those values are > > > actually > > > outside the stolen memory. There is a bit in the register which > > > supposedly could tell us whether the reserved area is even > > > enabled or > > > not. Let's check for that before we go trusting the base and > > > size. > > > > If this is such a problem since g4x, why didn't we spot it earlier? > > It > > would be nice if you could explain in the commit message (or at > > least > > in this email) what are the consequences you're seeing that made > > you > > realize about this problem. Did something actually explode? I'm > > genuinely curious. > > The consequence is that we disable stolen; the machine keeps on > working > quite happily. Thanks! > Only fbc actually depends on stolen allocation to > function, and no one complains if fbc is disabled. (There's a sketch > out > there that we could use a contiguous allocation for fbc if we run out > of > stolen.) ILK_DPFC_CB_BASE (aka FBC_CFB_BASE these days) needs to be programmed as an offset of the base of stolen memory, so you'll need to allocate this memory in the region that comes right after stolen, or you'll run out of bits to write to the register. Also, things such as the "last 8mb bug" of BDW/SKL suggest that maybe this wouldn't work. Unless, of course, you have some plan to work around this. > Internal hw functions are oblivious to our qualms about the > location of stolen and whether some other device is using the same > physical address for its trampoline. > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
