On Tue, Jul 14, 2020 at 04:01:31PM +0100, Matthew Auld wrote: > On 13/07/2020 05:48, Dave Airlie wrote: > > On Fri, 10 Jul 2020 at 22:01, Matthew Auld <matthew.auld@xxxxxxxxx> wrote: > >> > >> From: CQ Tang <cq.tang@xxxxxxxxx> > >> > >> Add "REGION_STOLEN" device info to dg1, create stolen memory > >> region from upper portion of local device memory, starting > >> from DSMBASE. > >> > >> The memory region is marked with "is_devmem=true". > > > > So is stolen fake on LMEM devices? The concept of stolen doesn't seem > > to make much sense with VRAM, so please enlighten me. > > CQ, do we actually need an explicit stolen LMEM region? The idea of > having a DSM like stolen region for LMEM does sound strange(outside of > the usual reserved portions which are for HW use etc), since the driver > has complete control over LMEM. Is it just a convenience thing to keep > things working as-is for fbc, initial fb, etc. or is there more to it? > There is buddy_alloc_range() for LMEM which we could potentially use to > wrap an object around for things like the initial fb or similar. For some reason the FBC hardware itself will treat the CFB base as an offset into stolen memory. So assuming they didn't change how the FBC hardware works we do still need the stolen base set up in some fashion. Also the CFB base register is 32bits wide so without the stolen base it wouldn't be able to address more than 4GiB or memory. Hmm, actually the docs say the register only accepts 28bit offsets so only 256MiB in fact. I'll have to double check if that's true and whether we are currently at risk of going past that limit... I think there are some other magic things in the hardware that also use the stolen base for something. I do agree that having stolen inside lmem is a bit odd. That's not how i810 worked IIRC. Back then you either had lmem or you had stolen. But I guess all the i810 people retired by now so there was no one to tell the new guys how to design this stuff :P -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx