[Intel-gfx] [PATCH 12/19] drm/i915/lmem: Bypass aperture when lmem is available

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Mon Apr 19 14:16:48 UTC 2021


On 16/04/2021 15:25, Matthew Auld wrote:
> On 14/04/2021 16:33, Tvrtko Ursulin wrote:
>>
>> On 12/04/2021 10:05, Matthew Auld wrote:
>>> From: Anusha Srivatsa <anusha.srivatsa at intel.com>
>>>
>>> In the scenario where local memory is available, we have
>>> rely on CPU access via lmem directly instead of aperture.
>>>
>>> v2:
>>> gmch is only relevant for much older hw, therefore we can drop the
>>> has_aperture check since it should always be present on such platforms.
>>> (Chris)
>>>
>>> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
>>> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan at intel.com>
>>> Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
>>> Cc: Chris P Wilson <chris.p.wilson at intel.com>
>>> Cc: Daniel Vetter <daniel.vetter at intel.com>
>>> Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
>>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
>>> Cc: CQ Tang <cq.tang at intel.com>
>>> Signed-off-by: Anusha Srivatsa <anusha.srivatsa at intel.com>
>>> ---
>>>   drivers/gpu/drm/i915/display/intel_fbdev.c | 22 +++++++++++++++-------
>>>   drivers/gpu/drm/i915/gem/i915_gem_lmem.c   | 15 +++++++++++++++
>>>   drivers/gpu/drm/i915/gem/i915_gem_lmem.h   |  5 +++++
>>>   drivers/gpu/drm/i915/i915_vma.c            | 19 +++++++++++++------
>>>   4 files changed, 48 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
>>> b/drivers/gpu/drm/i915/display/intel_fbdev.c
>>> index 2b37959da747..4af40229f5ec 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
>>> @@ -139,14 +139,22 @@ static int intelfb_alloc(struct drm_fb_helper 
>>> *helper,
>>>       size = mode_cmd.pitches[0] * mode_cmd.height;
>>>       size = PAGE_ALIGN(size);
>>> -    /* If the FB is too big, just don't use it since fbdev is not very
>>> -     * important and we should probably use that space with FBC or 
>>> other
>>> -     * features. */
>>>       obj = ERR_PTR(-ENODEV);
>>> -    if (size * 2 < dev_priv->stolen_usable_size)
>>> -        obj = i915_gem_object_create_stolen(dev_priv, size);
>>> -    if (IS_ERR(obj))
>>> -        obj = i915_gem_object_create_shmem(dev_priv, size);
>>> +    if (HAS_LMEM(dev_priv)) {
>>> +        obj = i915_gem_object_create_lmem(dev_priv, size,
>>> +                          I915_BO_ALLOC_CONTIGUOUS);
>>
>> Has to be contiguous? Question for display experts I guess.
>>
>> [Comes back later.] Ah for iomap? Put a comment to that effect perhaps?
> 
> I don't think it has to be, since we could in theory just use pin_map() 
> underneath, which can already deal with non-contiguous chunks of lmem, 
> although that might bring in ww locking. I think for now just add a 
> comment and mark this as XXX, and potentially revisit as follow up?

Sure.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>

Regards,

Tvrtko


More information about the Intel-gfx mailing list