Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
To: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Add smem fallback allocation for dpt
Date: Fri, 18 Mar 2022 11:22:13 +0200	[thread overview]
Message-ID: <6cec7503-b7ab-8d7c-dff0-b83d65a9e3df@gmail.com> (raw)
In-Reply-To: <CAM0jSHMC76EyN-HeKFeON4ODeGPd2Ez=dF8eTNkA8Yp3eAu-JA@mail.gmail.com>

On 17.3.2022 13.55, Matthew Auld wrote:
> On Wed, 16 Mar 2022 at 22:23, Juha-Pekka Heikkila
> <juhapekka.heikkila@gmail.com> wrote:
>>
>> Add fallback smem allocation for dpt if stolen memory
>> allocation failed.
>>
>> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
>> ---
>>   drivers/gpu/drm/i915/display/intel_dpt.c | 18 ++++++++++++++----
>>   1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c b/drivers/gpu/drm/i915/display/intel_dpt.c
>> index fb0e7e79e0cd..c8b66433d4db 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
>> @@ -10,6 +10,7 @@
>>   #include "intel_display_types.h"
>>   #include "intel_dpt.h"
>>   #include "intel_fb.h"
>> +#include "gem/i915_gem_internal.h"
> 
> Nit: these should be kept sorted
> 
>>
>>   struct i915_dpt {
>>          struct i915_address_space vm;
>> @@ -128,6 +129,10 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space *vm)
>>          void __iomem *iomem;
>>          struct i915_gem_ww_ctx ww;
>>          int err;
>> +       u64 pin_flags = 0;
>> +
>> +       if (i915_gem_object_is_stolen(dpt->obj))
>> +               pin_flags |= PIN_MAPPABLE; /* for i915_vma_pin_iomap(stolen) */
>>
>>          wakeref = intel_runtime_pm_get(&i915->runtime_pm);
>>          atomic_inc(&i915->gpu_error.pending_fb_pin);
>> @@ -138,7 +143,7 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space *vm)
>>                          continue;
>>
>>                  vma = i915_gem_object_ggtt_pin_ww(dpt->obj, &ww, NULL, 0, 4096,
>> -                                                 HAS_LMEM(i915) ? 0 : PIN_MAPPABLE);
>> +                                                 pin_flags);
>>                  if (IS_ERR(vma)) {
>>                          err = PTR_ERR(vma);
>>                          continue;
>> @@ -248,10 +253,15 @@ intel_dpt_create(struct intel_framebuffer *fb)
>>
>>          size = round_up(size * sizeof(gen8_pte_t), I915_GTT_PAGE_SIZE);
>>
>> -       if (HAS_LMEM(i915))
>> -               dpt_obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_CONTIGUOUS);
>> -       else
>> +       dpt_obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_CONTIGUOUS);
>> +       if (IS_ERR(dpt_obj) && i915_ggtt_has_aperture(to_gt(i915)->ggtt))
>>                  dpt_obj = i915_gem_object_create_stolen(i915, size);
>> +       if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
>> +               drm_dbg_kms(&i915->drm, "fb: [FB:%d] Allocating dpt from smem\n",
>> +                           fb->base.base.id);
>> +
>> +               dpt_obj = i915_gem_object_create_internal(i915, size);
> 
> Looks like we are missing some prerequisite patch to be able to
> directly map such memory in vma_pin_iomap?

For these functions I'm more like a consumer, I was following 
suggestions from Chris on this. Is there something extra that should be 
considered in this regard when use it like this?

> 
>> +       }
>>          if (IS_ERR(dpt_obj))
>>                  return ERR_CAST(dpt_obj);
>>
>> --
>> 2.28.0
>>


  reply	other threads:[~2022-03-18  9:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-16 22:23 [Intel-gfx] [PATCH] drm/i915/display: Add smem fallback allocation for dpt Juha-Pekka Heikkila
2022-03-16 23:40 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2022-03-17  2:31 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-03-21  8:27   ` Juha-Pekka Heikkila
2022-03-21 16:44     ` Vudum, Lakshminarayana
2022-03-17 11:55 ` [Intel-gfx] [PATCH] " Matthew Auld
2022-03-18  9:22   ` Juha-Pekka Heikkila [this message]
2022-03-21 12:29     ` Matthew Auld
2022-03-21 18:36       ` Juha-Pekka Heikkila
2022-03-22 10:45         ` Matthew Auld
2022-03-22 12:06           ` Juha-Pekka Heikkila
2022-03-22 15:53             ` Matthew Auld
2022-03-23 15:09               ` Juha-Pekka Heikkila
2022-03-21 16:10 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork
2022-03-21 17:02 ` Patchwork

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=6cec7503-b7ab-8d7c-dff0-b83d65a9e3df@gmail.com \
    --to=juhapekka.heikkila@gmail.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.william.auld@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox