Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
On 22-09-2022 19:26, Lucas De Marchi wrote:
> On Wed, Sep 21, 2022 at 12:00:38PM +0530, Iddamsetty, Aravind wrote:
>> replying here for earlier comments too.
>>
>> On 21-09-2022 01:35, Lucas De Marchi wrote:
>>> On Tue, Sep 20, 2022 at 01:31:49AM -0700, Lucas De Marchi wrote:
On Tue, Sep 20, 2022 at 12:49:40PM +0530, Aravind Iddamsetty wrote:
> As an integrated GPU, MTL does not have local memory and
> HAS_LMEM() returns false. However the platform's stolen memory
> is presented via BAR2 (i.e., the BAR we traditionally consider
> to be the LMEM BAR) and should be managed by the driver the same
> way that local memory is on dgpu platforms (which includes
> setting the "lmem" bit on page table entries). We use the term
> "local stolen memory" to refer to this model.
>
> Cc: Matt Roper
> Cc: Lucas De Marchi
>
> Signed-off-by: CQ Tang
> Signed-off-by: Aravind Iddamsetty
> Original-author: CQ Tang
> ---
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 113 +
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 3 +
> 3 files changed, 100 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index acc561c0f0aa..bad5250fb764 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -77,6 +77,19 @@ void i915_gem_stolen_remove_node(struct
> drm_i915_private *i915,
> mutex_unlock(&i915->mm.stolen_lock);
> }
>
> +static bool is_dsm_invalid(struct drm_i915_private *i915, struct
> resource *dsm)
> +{
> + if (!HAS_BAR2_SMEM_STOLEN(i915)) {
I called a similar function as is_dsm_valid() in
https://patchwork.freedesktop.org/series/108620/
sounds weird with "invalid" and the double negation on return early
style.
>>
>> sure, will change it hope i can use that from your patch.
>
> that patch is now pushed, so now you can reuse it.
Thanks for the info and help.
Aravind.
>
> Lucas De Marchi
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
On Wed, Sep 21, 2022 at 12:00:38PM +0530, Iddamsetty, Aravind wrote:
replying here for earlier comments too.
On 21-09-2022 01:35, Lucas De Marchi wrote:
On Tue, Sep 20, 2022 at 01:31:49AM -0700, Lucas De Marchi wrote:
On Tue, Sep 20, 2022 at 12:49:40PM +0530, Aravind Iddamsetty wrote:
As an integrated GPU, MTL does not have local memory and
HAS_LMEM() returns false. However the platform's stolen memory
is presented via BAR2 (i.e., the BAR we traditionally consider
to be the LMEM BAR) and should be managed by the driver the same
way that local memory is on dgpu platforms (which includes
setting the "lmem" bit on page table entries). We use the term
"local stolen memory" to refer to this model.
Cc: Matt Roper
Cc: Lucas De Marchi
Signed-off-by: CQ Tang
Signed-off-by: Aravind Iddamsetty
Original-author: CQ Tang
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 113 +
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 3 +
3 files changed, 100 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index acc561c0f0aa..bad5250fb764 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -77,6 +77,19 @@ void i915_gem_stolen_remove_node(struct
drm_i915_private *i915,
mutex_unlock(&i915->mm.stolen_lock);
}
+static bool is_dsm_invalid(struct drm_i915_private *i915, struct
resource *dsm)
+{
+ if (!HAS_BAR2_SMEM_STOLEN(i915)) {
I called a similar function as is_dsm_valid() in
https://patchwork.freedesktop.org/series/108620/
sounds weird with "invalid" and the double negation on return early
style.
sure, will change it hope i can use that from your patch.
that patch is now pushed, so now you can reuse it.
Lucas De Marchi
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
replying here for earlier comments too.
On 21-09-2022 01:35, Lucas De Marchi wrote:
> On Tue, Sep 20, 2022 at 01:31:49AM -0700, Lucas De Marchi wrote:
>> On Tue, Sep 20, 2022 at 12:49:40PM +0530, Aravind Iddamsetty wrote:
>>> As an integrated GPU, MTL does not have local memory and
>>> HAS_LMEM() returns false. However the platform's stolen memory
>>> is presented via BAR2 (i.e., the BAR we traditionally consider
>>> to be the LMEM BAR) and should be managed by the driver the same
>>> way that local memory is on dgpu platforms (which includes
>>> setting the "lmem" bit on page table entries). We use the term
>>> "local stolen memory" to refer to this model.
>>>
>>> Cc: Matt Roper
>>> Cc: Lucas De Marchi
>>>
>>> Signed-off-by: CQ Tang
>>> Signed-off-by: Aravind Iddamsetty
>>> Original-author: CQ Tang
>>> ---
>>> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 113 +
>>> drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
>>> drivers/gpu/drm/i915/i915_drv.h | 3 +
>>> 3 files changed, 100 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>>> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>>> index acc561c0f0aa..bad5250fb764 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>>> @@ -77,6 +77,19 @@ void i915_gem_stolen_remove_node(struct
>>> drm_i915_private *i915,
>>> mutex_unlock(&i915->mm.stolen_lock);
>>> }
>>>
>>> +static bool is_dsm_invalid(struct drm_i915_private *i915, struct
>>> resource *dsm)
>>> +{
>>> + if (!HAS_BAR2_SMEM_STOLEN(i915)) {
>>
>> I called a similar function as is_dsm_valid() in
>> https://patchwork.freedesktop.org/series/108620/
>>
>> sounds weird with "invalid" and the double negation on return early
>> style.
sure, will change it hope i can use that from your patch.
>>
>>> + if (dsm->start == 0)
>>> + return true;
>>> + }
>>> +
>>> + if (dsm->end <= dsm->start)
>>> + return true;
>>> +
>>> + return false;
>>> +}
>>> +
>>> static int i915_adjust_stolen(struct drm_i915_private *i915,
>>> struct resource *dsm)
>>> {
>>> @@ -84,7 +97,7 @@ static int i915_adjust_stolen(struct
>>> drm_i915_private *i915,
>>> struct intel_uncore *uncore = ggtt->vm.gt->uncore;
>>> struct resource *r;
>>>
>>> - if (dsm->start == 0 || dsm->end <= dsm->start)
>>> + if (is_dsm_invalid(i915, dsm))
>>> return -EINVAL;
>>>
>>> /*
>>> @@ -136,7 +149,7 @@ static int i915_adjust_stolen(struct
>>> drm_i915_private *i915,
>>> * overlaps with the non-stolen system memory range, since lmem
>>> is local
>>> * to the gpu.
>>> */
>>> - if (HAS_LMEM(i915))
>>> + if (HAS_LMEM(i915) || HAS_BAR2_SMEM_STOLEN(i915))
>>
>> comment above makes no sense when you add this. For this specific case
>> it's still system memory, reserved by the BIOS and that we access by
>> mapping the lmembar
thanks for catching this.
>>
>>> return 0;
>>>
>>> /*
>>> @@ -371,8 +384,6 @@ static void icl_get_stolen_reserved(struct
>>> drm_i915_private *i915,
>>>
>>> drm_dbg(&i915->drm, "GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
>>>
>>> - *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
>>> -
>>> switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
>>> case GEN8_STOLEN_RESERVED_1M:
>>> *size = 1024 * 1024;
>>> @@ -390,6 +401,12 @@ static void icl_get_stolen_reserved(struct
>>> drm_i915_private *i915,
>>> *size = 8 * 1024 * 1024;
>>> MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
>>> }
>>> +
>>> + if ((GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) && !IS_DGFX(i915))
>>> + /* the base is initialized to stolen top so subtract size to
>>> get base */
>>> + *base -= *size;
>>
>> that doesn't necessarily holds true. According to the spec the wopcm
>> base is 1MB aligned so even if it is "at the top", it may not mean it
>> is at the
>> very very top that we can just subtract the size.
well here the reserved_base is not to the top of the BAR, we got the
stolen size from GGC register so base is initialized to end of that
stolen size. hence we subtract the reserved size from it.
>>
>>
>>> + else
>>> + *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
>>> }
>>>
>>> static int i915_gem_init_stolen(struct intel_memory_region *mem)
>>> @@ -423,8 +440,7 @@ static int i915_gem_init_stolen(struct
>>> intel_memory_region *mem)
>>> if (i915_adjust_stolen(i915, &i915->dsm))
>>> return 0;
>>>
>>> - GEM_BUG_ON(i915->dsm.start == 0);
>>> - GEM_BUG_ON(i915->dsm.end <= i915->dsm.start);
>>> + GEM_BUG_ON(is_dsm_invalid(i915, &i915->dsm));
>>>
>>> stolen_top = i915->dsm.end + 1;
>>> reserved_base = stolen_top;
>>> @@ -796,6 +812,46 @@ static const struct intel_memory_region_ops
>>> i915_region_stolen_lmem_ops = {
>>> .init_object = _i915_gem_object_stolen_init,
>>> };
>>>
>>> +static int get_mtl_gms_size(struct
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
Hi Matt, Lucas,
thanks for your feedback,
> > > + switch (gms) {
> > > + case 0x0 ... 0x10:
> > > + return gms * 32;
> > > + case 0x20:
> > > + return 1024;
> > > + case 0x30:
> > > + return 1536;
> > > + case 0x40:
> > > + return 2048;
> > > + case 0xf0 ... 0xfe:
> >
> > just a bit puzzled by the fact that case ranges are not standard
> > and are supported only by GCC, unless, of course, I miss
> > something. Do we still want to use them as they are widely used
> > around the kernel?
>
> i915 already has 17 other uses of this notation and the DRM subsystem in
> general has about 50 today. So it's not super common, but I think it
> should be okay to use. I believe clang supports this language extension
> as well and the coding style doc doesn't say anything one way or the
> other.
I thought clang supports it for C++ rather than C, but I'm not a
clang expert, so that I might be wrong.
The fact that it is widely used is never a convincing argument
and if gcc supports it, then it does it against the standard,
both C11 and C17 (this is what puzzles me everytime I see these C
tricks offered by gcc).
Anyway, I'm not against it (nor in favour) as the ellipsis is
becoming very commonly used. My comment, by the way, did not mean
to block the patch, I just wanted to check what other people
think about.
Thanks,
Andi
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
On Tue, Sep 20, 2022 at 06:57:46PM +0200, Andi Shyti wrote:
> Hi Aravind,
>
> > +static int get_mtl_gms_size(struct intel_uncore *uncore)
> > +{
> > + u16 ggc, gms;
> > +
> > + ggc = intel_uncore_read16(uncore, _MMIO(0x108040));
> > +
> > + /* check GGMS, should be fixed 0x3 (8MB) */
> > + if ((ggc & 0xc0) != 0xc0)
> > + return -EIO;
> > +
> > + /* return valid GMS value, -EIO if invalid */
> > + gms = ggc >> 8;
> > + switch (gms) {
> > + case 0x0 ... 0x10:
> > + return gms * 32;
> > + case 0x20:
> > + return 1024;
> > + case 0x30:
> > + return 1536;
> > + case 0x40:
> > + return 2048;
> > + case 0xf0 ... 0xfe:
>
> just a bit puzzled by the fact that case ranges are not standard
> and are supported only by GCC, unless, of course, I miss
> something. Do we still want to use them as they are widely used
> around the kernel?
i915 already has 17 other uses of this notation and the DRM subsystem in
general has about 50 today. So it's not super common, but I think it
should be okay to use. I believe clang supports this language extension
as well and the coding style doc doesn't say anything one way or the
other.
Matt
>
> Andi
>
> > + return (gms - 0xf0 + 1) * 4;
> > + default:
> > + return -EIO;
> > + }
> > +}
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
On Tue, Sep 20, 2022 at 01:31:49AM -0700, Lucas De Marchi wrote:
On Tue, Sep 20, 2022 at 12:49:40PM +0530, Aravind Iddamsetty wrote:
As an integrated GPU, MTL does not have local memory and
HAS_LMEM() returns false. However the platform's stolen memory
is presented via BAR2 (i.e., the BAR we traditionally consider
to be the LMEM BAR) and should be managed by the driver the same
way that local memory is on dgpu platforms (which includes
setting the "lmem" bit on page table entries). We use the term
"local stolen memory" to refer to this model.
Cc: Matt Roper
Cc: Lucas De Marchi
Signed-off-by: CQ Tang
Signed-off-by: Aravind Iddamsetty
Original-author: CQ Tang
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 113 +
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h| 3 +
3 files changed, 100 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index acc561c0f0aa..bad5250fb764 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -77,6 +77,19 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
*i915,
mutex_unlock(&i915->mm.stolen_lock);
}
+static bool is_dsm_invalid(struct drm_i915_private *i915, struct resource *dsm)
+{
+ if (!HAS_BAR2_SMEM_STOLEN(i915)) {
I called a similar function as is_dsm_valid() in
https://patchwork.freedesktop.org/series/108620/
sounds weird with "invalid" and the double negation on return early
style.
+ if (dsm->start == 0)
+ return true;
+ }
+
+ if (dsm->end <= dsm->start)
+ return true;
+
+ return false;
+}
+
static int i915_adjust_stolen(struct drm_i915_private *i915,
struct resource *dsm)
{
@@ -84,7 +97,7 @@ static int i915_adjust_stolen(struct drm_i915_private *i915,
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
struct resource *r;
- if (dsm->start == 0 || dsm->end <= dsm->start)
+ if (is_dsm_invalid(i915, dsm))
return -EINVAL;
/*
@@ -136,7 +149,7 @@ static int i915_adjust_stolen(struct drm_i915_private *i915,
* overlaps with the non-stolen system memory range, since lmem is local
* to the gpu.
*/
- if (HAS_LMEM(i915))
+ if (HAS_LMEM(i915) || HAS_BAR2_SMEM_STOLEN(i915))
comment above makes no sense when you add this. For this specific case
it's still system memory, reserved by the BIOS and that we access by
mapping the lmembar
return 0;
/*
@@ -371,8 +384,6 @@ static void icl_get_stolen_reserved(struct drm_i915_private
*i915,
drm_dbg(&i915->drm, "GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
- *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
-
switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
case GEN8_STOLEN_RESERVED_1M:
*size = 1024 * 1024;
@@ -390,6 +401,12 @@ static void icl_get_stolen_reserved(struct
drm_i915_private *i915,
*size = 8 * 1024 * 1024;
MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
}
+
+ if ((GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) && !IS_DGFX(i915))
+ /* the base is initialized to stolen top so subtract size to
get base */
+ *base -= *size;
that doesn't necessarily holds true. According to the spec the wopcm
base is 1MB aligned so even if it is "at the top", it may not mean it is at the
very very top that we can just subtract the size.
+ else
+ *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
}
static int i915_gem_init_stolen(struct intel_memory_region *mem)
@@ -423,8 +440,7 @@ static int i915_gem_init_stolen(struct intel_memory_region
*mem)
if (i915_adjust_stolen(i915, &i915->dsm))
return 0;
- GEM_BUG_ON(i915->dsm.start == 0);
- GEM_BUG_ON(i915->dsm.end <= i915->dsm.start);
+ GEM_BUG_ON(is_dsm_invalid(i915, &i915->dsm));
stolen_top = i915->dsm.end + 1;
reserved_base = stolen_top;
@@ -796,6 +812,46 @@ static const struct intel_memory_region_ops
i915_region_stolen_lmem_ops = {
.init_object = _i915_gem_object_stolen_init,
};
+static int get_mtl_gms_size(struct intel_uncore *uncore)
+{
+ u16 ggc, gms;
+
+ ggc = intel_uncore_read16(uncore, _MMIO(0x108040));
??
+
+ /* check GGMS, should be fixed 0x3 (8MB) */
+ if ((ggc & 0xc0) != 0xc0)
+ return -EIO;
+
+ /* return valid GMS value, -EIO if invalid */
+ gms = ggc >> 8;
+ switch (gms) {
+ case 0x0 ... 0x10:
+ return gms * 32;
+ case 0x20:
+ return 1024;
+ case 0x30:
+ return 1536;
+ case 0x40:
+ return 2048;
+ case 0xf0 ... 0xfe:
+ return (gms - 0xf0 + 1) * 4;
+
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
On Tue, Sep 20, 2022 at 06:57:46PM +0200, Andi Shyti wrote:
Hi Aravind,
+static int get_mtl_gms_size(struct intel_uncore *uncore)
+{
+ u16 ggc, gms;
+
+ ggc = intel_uncore_read16(uncore, _MMIO(0x108040));
+
+ /* check GGMS, should be fixed 0x3 (8MB) */
+ if ((ggc & 0xc0) != 0xc0)
+ return -EIO;
+
+ /* return valid GMS value, -EIO if invalid */
+ gms = ggc >> 8;
+ switch (gms) {
+ case 0x0 ... 0x10:
+ return gms * 32;
+ case 0x20:
+ return 1024;
+ case 0x30:
+ return 1536;
+ case 0x40:
+ return 2048;
+ case 0xf0 ... 0xfe:
just a bit puzzled by the fact that case ranges are not standard
and are supported only by GCC, unless, of course, I miss
clang also supports it and can build the kernel (or a great portion of
it).
Lucas De Marchi
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
Hi Aravind,
> +static int get_mtl_gms_size(struct intel_uncore *uncore)
> +{
> + u16 ggc, gms;
> +
> + ggc = intel_uncore_read16(uncore, _MMIO(0x108040));
> +
> + /* check GGMS, should be fixed 0x3 (8MB) */
> + if ((ggc & 0xc0) != 0xc0)
> + return -EIO;
> +
> + /* return valid GMS value, -EIO if invalid */
> + gms = ggc >> 8;
> + switch (gms) {
> + case 0x0 ... 0x10:
> + return gms * 32;
> + case 0x20:
> + return 1024;
> + case 0x30:
> + return 1536;
> + case 0x40:
> + return 2048;
> + case 0xf0 ... 0xfe:
just a bit puzzled by the fact that case ranges are not standard
and are supported only by GCC, unless, of course, I miss
something. Do we still want to use them as they are widely used
around the kernel?
Andi
> + return (gms - 0xf0 + 1) * 4;
> + default:
> + return -EIO;
> + }
> +}
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
On Tue, Sep 20, 2022 at 12:49:40PM +0530, Aravind Iddamsetty wrote:
As an integrated GPU, MTL does not have local memory and
HAS_LMEM() returns false. However the platform's stolen memory
is presented via BAR2 (i.e., the BAR we traditionally consider
to be the LMEM BAR) and should be managed by the driver the same
way that local memory is on dgpu platforms (which includes
setting the "lmem" bit on page table entries). We use the term
"local stolen memory" to refer to this model.
Cc: Matt Roper
Cc: Lucas De Marchi
Signed-off-by: CQ Tang
Signed-off-by: Aravind Iddamsetty
Original-author: CQ Tang
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 113 +
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h| 3 +
3 files changed, 100 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index acc561c0f0aa..bad5250fb764 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -77,6 +77,19 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
*i915,
mutex_unlock(&i915->mm.stolen_lock);
}
+static bool is_dsm_invalid(struct drm_i915_private *i915, struct resource *dsm)
+{
+ if (!HAS_BAR2_SMEM_STOLEN(i915)) {
I called a similar function as is_dsm_valid() in
https://patchwork.freedesktop.org/series/108620/
sounds weird with "invalid" and the double negation on return early
style.
+ if (dsm->start == 0)
+ return true;
+ }
+
+ if (dsm->end <= dsm->start)
+ return true;
+
+ return false;
+}
+
static int i915_adjust_stolen(struct drm_i915_private *i915,
struct resource *dsm)
{
@@ -84,7 +97,7 @@ static int i915_adjust_stolen(struct drm_i915_private *i915,
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
struct resource *r;
- if (dsm->start == 0 || dsm->end <= dsm->start)
+ if (is_dsm_invalid(i915, dsm))
return -EINVAL;
/*
@@ -136,7 +149,7 @@ static int i915_adjust_stolen(struct drm_i915_private *i915,
* overlaps with the non-stolen system memory range, since lmem is local
* to the gpu.
*/
- if (HAS_LMEM(i915))
+ if (HAS_LMEM(i915) || HAS_BAR2_SMEM_STOLEN(i915))
comment above makes no sense when you add this. For this specific case
it's still system memory, reserved by the BIOS and that we access by
mapping the lmembar
return 0;
/*
@@ -371,8 +384,6 @@ static void icl_get_stolen_reserved(struct drm_i915_private
*i915,
drm_dbg(&i915->drm, "GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
- *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
-
switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
case GEN8_STOLEN_RESERVED_1M:
*size = 1024 * 1024;
@@ -390,6 +401,12 @@ static void icl_get_stolen_reserved(struct
drm_i915_private *i915,
*size = 8 * 1024 * 1024;
MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
}
+
+ if ((GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) && !IS_DGFX(i915))
+ /* the base is initialized to stolen top so subtract size to
get base */
+ *base -= *size;
that doesn't necessarily holds true. According to the spec the wopcm
base is 1MB aligned so even if it is "at the top", it may not mean it is at the
very very top that we can just subtract the size.
+ else
+ *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
}
static int i915_gem_init_stolen(struct intel_memory_region *mem)
@@ -423,8 +440,7 @@ static int i915_gem_init_stolen(struct intel_memory_region
*mem)
if (i915_adjust_stolen(i915, &i915->dsm))
return 0;
- GEM_BUG_ON(i915->dsm.start == 0);
- GEM_BUG_ON(i915->dsm.end <= i915->dsm.start);
+ GEM_BUG_ON(is_dsm_invalid(i915, &i915->dsm));
stolen_top = i915->dsm.end + 1;
reserved_base = stolen_top;
@@ -796,6 +812,46 @@ static const struct intel_memory_region_ops
i915_region_stolen_lmem_ops = {
.init_object = _i915_gem_object_stolen_init,
};
+static int get_mtl_gms_size(struct intel_uncore *uncore)
+{
+ u16 ggc, gms;
+
+ ggc = intel_uncore_read16(uncore, _MMIO(0x108040));
??
+
+ /* check GGMS, should be fixed 0x3 (8MB) */
+ if ((ggc & 0xc0) != 0xc0)
+ return -EIO;
+
+ /* return valid GMS value, -EIO if invalid */
+ gms = ggc >> 8;
+ switch (gms) {
+ case 0x0 ... 0x10:
+ return gms * 32;
+ case 0x20:
+ return 1024;
+ case 0x30:
+ return 1536;
+ case 0x40:
+ return 2048;
+ case 0xf0 ... 0xfe:
+ return (gms - 0xf0 + 1) * 4;
+ default:
+ return -EIO;
+ }
+}
+
+static inli
