All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Matthew Auld <matthew.auld@intel.com>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	Chris P Wilson <chris.p.wilson@intel.com>,
	Neel Desai <neel.desai@intel.com>
Subject: Re: [Intel-gfx] [RFC 53/60] drm/i915: Create stolen memory region from local memory
Date: Tue, 14 Jul 2020 20:39:12 +0300	[thread overview]
Message-ID: <20200714173912.GN6112@intel.com> (raw)
In-Reply-To: <84ff0146-0a35-c66e-2c33-2ce22aae4c6c@intel.com>

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@intel.com> wrote:
> >>
> >> From: CQ Tang <cq.tang@intel.com>
> >>
> >> 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2020-07-14 17:39 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-10 11:56 [Intel-gfx] [RFC 00/60] DG1 LMEM enabling Matthew Auld
2020-07-10 11:56 ` [Intel-gfx] [RFC 01/60] drm/i915: Add has_master_unit_irq flag Matthew Auld
2020-07-10 11:56 ` [Intel-gfx] [RFC 02/60] drm/i915/dg1: add initial DG-1 definitions Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 03/60] drm/i915/dg1: Add DG1 PCI IDs Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 04/60] drm/i915/dg1: add support for the master unit interrupt Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 05/60] drm/i915/dg1: Remove SHPD_FILTER_CNT register programming Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 06/60] drm/i915/dg1: Add fake PCH Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 07/60] drm/i915/dg1: Initialize RAWCLK properly Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 08/60] drm/i915/dg1: Define MOCS table for DG1 Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 09/60] drm/i915/dg1: Add DG1 power wells Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 10/60] drm/i915/dg1: Increase mmio size to 4MB Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 11/60] drm/i915/dg1: Wait for pcode/uncore handshake at startup Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 12/60] drm/i915/dg1: Add DPLL macros for DG1 Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 13/60] drm/i915/dg1: Add and setup DPLLs " Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 14/60] drm/i915/dg1: Enable DPLL " Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 15/60] drm/i915/dg1: add hpd interrupt handling Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 16/60] drm/i915/dg1: invert HPD pins Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 17/60] drm/i915/dg1: gmbus pin mapping Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 18/60] drm/i915/dg1: Enable first 2 ports for DG1 Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 19/60] drm/i915/dg1: Don't program PHY_MISC for PHY-C and PHY-D Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 20/60] drm/i915/dg1: Update comp master/slave relationships for PHYs Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 21/60] drm/i915/dg1: Update voltage swing tables for DP Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 22/60] drm/i915/dg1: provide port/phy mapping for vbt Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 23/60] drm/i915/dg1: map/unmap pll clocks Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 24/60] drm/i915/dg1: enable PORT C/D aka D/E Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 25/60] drm/i915/dg1: Load DMC Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 26/60] drm/i915/rkl: Add initial workarounds Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 27/60] drm/i915/dg1: Add initial DG1 workarounds Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 28/60] drm/i915/dg1: DG1 does not support DC6 Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 29/60] drm/i915/lmem: Limit block size to 4G Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 30/60] drm/i915/lmem: Do not check r->sgt.pfn for NULL Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 31/60] drm/i915/dgfx: define llc and snooping behaviour Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 32/60] drm/i915/lmem: support pread Matthew Auld
2020-07-10 12:39   ` Tvrtko Ursulin
2020-07-10 13:04     ` Chris Wilson
2020-07-10 11:57 ` [Intel-gfx] [RFC 33/60] drm/i915/lmem: support pwrite Matthew Auld
2020-07-13  5:09   ` Dave Airlie
2020-07-14 14:35     ` Matthew Auld
2020-07-16  0:43       ` Dave Airlie
2020-07-16 10:11         ` Matthew Auld
2020-07-19 21:52           ` Dave Airlie
2020-08-07  9:32             ` Joonas Lahtinen
2020-08-07  9:46     ` Joonas Lahtinen
2020-08-09 21:06       ` Dave Airlie
2020-07-10 11:57 ` [Intel-gfx] [RFC 34/60] drm/i915: introduce kernel blitter_context Matthew Auld
2020-08-03 19:59   ` Lucas De Marchi
2020-08-03 20:17     ` Lucas De Marchi
2020-07-10 11:57 ` [Intel-gfx] [RFC 35/60] drm/i915/query: Expose memory regions through the query uAPI Matthew Auld
2020-07-10 16:20   ` Tvrtko Ursulin
2020-07-10 11:57 ` [Intel-gfx] [RFC 36/60] drm/i915/uapi: introduce drm_i915_gem_create_ext Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 37/60] drm/i915/lmem: allocate cmd ring in lmem Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 38/60] drm/i915/dg1: Introduce dmabuf mmap to LMEM Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 39/60] drm/i915: setup the LMEM region Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 40/60] drm/i915: drop fake LMEM Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 41/60] drm/i915: Distinction of memory regions Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 42/60] drm/i915: PPGTT support Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 43/60] drm/i915: support GGTT LMEM entries Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 44/60] drm/i915: allocate context from LMEM Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 45/60] drm/i915: move engine scratch to LMEM Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 46/60] drm/i915: Provide a way to disable PCIe relaxed write ordering Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 47/60] drm/i915: setup GPU device lmem region Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 48/60] drm/i915: Fix object page offset within a region Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 49/60] drm/i915: add i915_gem_object_is_devmem() function Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 50/60] drm/i915: finish memory region support for stolen objects Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 51/60] drm/i915/lmem: support optional CPU clearing for special internal use Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 52/60] drm/i915/guc: put all guc objects in lmem when available Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 53/60] drm/i915: Create stolen memory region from local memory Matthew Auld
2020-07-13  4:48   ` Dave Airlie
2020-07-14 15:01     ` Matthew Auld
2020-07-14 16:57       ` Tang, CQ
2020-07-14 19:26         ` Dave Airlie
2020-08-07  9:38           ` Joonas Lahtinen
2020-08-07 16:24             ` Tang, CQ
2020-07-14 17:39       ` Ville Syrjälä [this message]
2020-07-10 11:57 ` [Intel-gfx] [RFC 54/60] drm/i915/lmem: Bypass aperture when lmem is available Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 55/60] drm/i915/lmem: reset the lmem buffer created by fbdev Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 56/60] drm/i915/dsb: Enable lmem for dsb Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 57/60] drm/i915: Reintroduce mem->reserved Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 58/60] drm/i915/dg1: Reserve first 1MB of local memory Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 59/60] drm/i915: defer pd lmem block put to worker Matthew Auld
2020-07-10 11:57 ` [Intel-gfx] [RFC 60/60] drm/i915/lmem: allocate HWSP in lmem Matthew Auld
2020-07-10 12:51 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for DG1 LMEM enabling Patchwork
2020-07-10 12:52 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-07-10 13:12 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-07-10 14:50 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-08-11  3:23 ` [Intel-gfx] [RFC 00/60] " Dave Airlie
2020-08-11 10:48   ` Matthew Auld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200714173912.GN6112@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=abdiel.janulgue@linux.intel.com \
    --cc=chris.p.wilson@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.auld@intel.com \
    --cc=neel.desai@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.