Re: [RFC 53/60] drm/i915: Create stolen memory region from local memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux