adev->rmmio is set to be NULL in amdgpu_device_unmap_mmio to prevent
access after pci_remove, however, in SRIOV case, amdgpu_virt_release_full_gpu
will still use adev->rmmio for access after amdgpu_device_unmap_mmio.
The patch is to move such SRIOV calling earlier to fini_early stage.
Fixes: 07775
[AMD Official Use Only]
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Saturday, September 18, 2021 12:16 AM
> To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: [PATCH 1/2] MAINTAINERS
> Can we remove drm_modeset_lock_all[_ctx] now? If so, let's queue that up as
> part
> of the set.
>
drm_modeset_lock_all() and drm_modeset_unlock_all() can be removed (I'll do that
on v2 of this patch series).
drm_modset_lock_all_ctx() is a different story and there are still two places
(one i
> > + struct drm_modeset_acquire_ctx ctx;
> > int r;
> > + int ret;
>
> Relocate ret with r please
Done!
> > - drm_modeset_unlock_all(dev);
> > + DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
>
> You should check ret here
Done!
> > int r;
> > + int ret;
>
> Relocate ret with r
> > int i;
> > + int ret;
>
> Please move up with i
Done!
> > + DRM_MODESET_LOCK_ALL_END((&dev_priv->drm), ctx, ret);
> >
> > return 0;
>
> Return ret here
Done!
> > + struct drm_modeset_acquire_ctx ctx;
> > int i;
> > + int ret;
>
> Please move up with i
Done!
> >
> > int i, out_width;
> > + int ret;
>
> Please put ret with i & out_width
Done!
> > - drm_modeset_unlock_all(crtc->dev);
> > + DRM_MODESET_LOCK_ALL_END(crtc->dev, ctx, ret);
> >
> > return 0;
>
> Return ret here
Done!
> > - drm_modeset_unlock_all(fb->dev);
> > + DRM_MODESET_LOCK_ALL_END(fb->dev, ctx, ret);
> >
> > return 0;
>
> Return ret here.
Done!
> > int err = 0;
> > + int ret;
>
> You can use err here instead.
Done!
> > + struct drm_modeset_acquire_ctx ctx;
> > int i, r;
> > + int ret;
>
> Could you please tuck this up with i & r?
Done!
> > - drm_modeset_unlock_all(dev);
> > + DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
>
> You should check ret here
Would it be save to return at this point if th
>
> Could you please fix the subject, changing dmr to drm?
>
Ups! Sure, I'll fix that. Thanks for noticing.
>
> I think you can just reuse 'ret' instead of creating a new variable. That
> ensures if the lock fails we return the error from the macros.
>
I didn't reuse "ret" because otherwise
On 21/09/17 05:24PM, Daniel Vetter wrote:
>
> Can we at least replace those with drm_modeset_lock_all_ctx and delete
> drm_modeset_lock_all? That would be really nice goal to make sure these
> don't spread further.
I just checked and turns out no one else is using "drm_modeset_lock_all()"
anymore.
Ping
Andrey
On 2021-09-17 7:30 a.m., Andrey Grodzovsky wrote:
Problem:
When device goes into suspend and unplugged during it
then all HW programming during resume fails leading
to a bad SW during pci remove handling which follows.
Because device is first resumed and only later removed
we cannot
Can you also add a Fixes: tag to make it easier to identify stable
branches for backports? I think it's this commit:
commit 1d5dbfe6c06a5269b535f8e6b13569f32c42ea60
Author: Alex Sierra
Date: Wed May 5 14:15:50 2021 -0500
drm/amdkfd: classify and map mixed svm range pages in GPU
[Why
On 2021-09-17 2:04 p.m., Philip Yang wrote:
For xnack off, restore work dma unmap previous system memory page, and
dma map the updated system memory page to update GPU mapping, this is
not dma mapping leaking, remove the WARN_ONCE for dma mapping leaking.
prange->dma_addr store the VRAM page pfn
From: "Liu, Zhan"
[Why]
DIG mapping change is causing a blocker
[How]
Revert the change for now. We will re-implement it later.
Reviewed-by: Jimmy Kizito
Acked-by: Rodrigo Siqueira
Signed-off-by: Zhan Liu
---
drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c | 6 --
1 file changed,
From: Hayden Goodfellow
[Why]
Currently, the 32bit kernel build fails due to an incorrect string
format specifier. ARRAY_SIZE() returns size_t type as it uses sizeof().
However, we specify it in a string as %ld. This causes a compiler error
and causes the 32bit build to fail.
[How]
Change the %l
From: Aric Cyr
This new DC version brings improvements in the following areas:
- New firmware version
- Fix HPD problems on DCN2
- Fix generic encoder problems and null deferences
- Adjust DCN301 watermark
- Rework dynamic bpp for DCN3x
- Improve link training fallback logic
Acked-by: Rodrigo Si
From: Anthony Koo
Acked-by: Rodrigo Siqueira
Signed-off-by: Anthony Koo
---
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
From: Jimmy Kizito
[Why]
Links which are dynamically assigned link encoders have their link
encoder set to NULL.
[How]
Check that a pointer to a link_encoder object is non-NULL before using
it.
Reviewed-by: Aric Cyr
Reviewed-by: Meenakshikumar Somasundaram
Acked-by: Rodrigo Siqueira
Signed-o
From: Nikola Cornij
[why]
If DCN30 watermark calc is used for DCN301, the calculated values are
wrong due to the data structure mismatch between DCN30 and DCN301.
However, using the original DCN301 watermark values causes underflow.
[how]
- Add DCN21-style watermark calculations
- Adjust DCN301
From: Meenakshikumar Somasundaram
[Why]
Need a bit for x86 driver to enable a FW boot option for an upcoming
feature.
[How]
Added a bit in dmub_fw_boot_options for an upcoming feature.
Reviewed-by: Jimmy Kizito
Reviewed-by: Jun Lei
Acked-by: Rodrigo Siqueira
Signed-off-by: Meenakshikumar Som
From: Michael Strauss
[WHY]
Currently causes visible flicker in some scenarios on OLED eDPs
Reviewed-by: Haonan Wang
Acked-by: Rodrigo Siqueira
Signed-off-by: Michael Strauss
---
drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
From: "Guo, Bing"
Why:
Screen sometimes would have artifacts or blink once at the time when bpp
is dynamically changed.
How:
1. Changed to update PPS infopacket in frame mode instead of immediate mode
since other updates for bpp change are double-buffered.
2. Changed double-buffering enableme
From: "Liu, Zhan"
[Why]
Starting from B0, along with RDPCSTX, RDPCSPIPE registers are also used.
[How]
Make sure RDPCSPIPE registers are programmed correctly.
Reviewed-by: Charlene Liu
Acked-by: Rodrigo Siqueira
Signed-off-by:Zhan Liu
---
.../amd/display/dc/dcn10/dcn10_link_encoder.h | 1 +
From: Jimmy Kizito
[Why]
Link training should fail if stream bandwidth exceeds link bandwidth.
[How]
Correct fallback logic and use named variables to make intention clear.
Reviewed-by: Meenakshikumar Somasundaram
Reviewed-by: Jun Lei
Acked-by: Rodrigo Siqueira
Signed-off-by: Jimmy Kizito
-
From: "Lai, Derek"
[Why]
The change of setting a timer callback on boot for 10 seconds is still
working, just lost power down on boot and power down for DCN3.
[How]
Added power down on boot and power down for DCN3.
Reviewed-by: Anthony Koo
Acked-by: Rodrigo Siqueira
Signed-off-by: Derek Lai
From: "Liu, Zhan"
[Why]
DCN3 B0 has a mux, which redirects PHYC and PHYD to PHYF and PHYG.
[How]
Fix DIG mapping.
Reviewed-by: Charlene Liu
Acked-by: Rodrigo Siqueira
Signed-off-by: Zhan Liu
---
drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c | 6 ++
1 file changed, 6 insertions(+
From: Jimmy Kizito
[Why]
Trying to enable multiple displays simultaneously exposed shortcomings
with the algorithm for dynamic link encoder assignment.
The main problems were:
- Assuming stream order remained constant across states would sometimes
lead to invalid DIG encoder assignment.
- Incorr
From: Jimmy Kizito
[Why]
Incorrect encoder assignments were being used while applying a new state
to hardware.
(1) When committing a new state to hardware requires resetting the
back-end, the encoder assignments of the current or old state should be
used when disabling the back-end; and the enco
From: Aric Cyr
Acked-by: Rodrigo Siqueira
Signed-off-by: Aric Cyr
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index 8897750bdaea..1306dedc1a98 100644
--- a
From: Qingqing Zhuo
[Why]
HPD disable and enable sequences are not mutually exclusive on Linux.
For HPDs that spans under 1s (i.e. HPD low = 1s), part of the disable
sequence (specifically, a request to SMU to lower refclk) could come
right before the call to PHY enablement, causing DMUB to acces
From: Anthony Koo
Acked-by: Rodrigo Siqueira
Signed-off-by: Anthony Koo
---
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
This DC patchset brings improvements in multiple areas. In summary, we
highlight:
- New firmware version
- Fix HPD problems on DCN2
- Fix generic encoder problems and null deferences
- Adjust DCN301 watermark
- Rework dynamic bpp for DCN3x
- Improve link training fallback logic
Best Regards
Sique
If svm migration init failed to create pages for device memory, set flag
to disable SVM capability, svm migrate fini skip release device pages
and mem region.
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 6 ++
1 file changed, 6 insert
Hi Lilian,
This change lgtm.
Reviewed-by: Rodrigo Siqueira
On 09/07, Qingqing Zhuo wrote:
> As part of the FPU isolation work documented in
> https://patchwork.freedesktop.org/series/93042/, isolate
> code that uses FPU in DSC to DML, where all FPU code
> should locate.
>
> This change does no
For xnack off, restore work dma unmap previous system memory page, and
dma map the updated system memory page to update GPU mapping, this is
not dma mapping leaking, remove the WARN_ONCE for dma mapping leaking.
prange->dma_addr store the VRAM page pfn after the range migrated to
VRAM, should not
From: Aric Cyr
Acked-by: Rodrigo Siqueira
Signed-off-by: Aric Cyr
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index 8897750bdaea..1306dedc1a98 100644
--- a
From: Anthony Koo
Acked-by: Rodrigo Siqueira
Signed-off-by: Anthony Koo
---
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
From: Qingqing Zhuo
[Why]
HPD disable and enable sequences are not mutually exclusive on Linux.
For HPDs that spans under 1s (i.e. HPD low = 1s), part of the disable
sequence (specifically, a request to SMU to lower refclk) could come
right before the call to PHY enablement, causing DMUB to acces
This DC patchset brings improvements in multiple areas. In summary, we
highlight:
- New firmware version
- Fix HPD problems on DCN2
- Fix generic encoder problems and null deferences
- Adjust DCN301 watermark
- Rework dynamic bpp for DCN3x
- Improve link training fallback logic
Best Regards
Sique
On Fri, Sep 17, 2021 at 6:15 PM Alex Deucher wrote:
>
> Now that the scheduler is being used by more and more
> drivers, we need someone to maintain it. Andrey has
> stepped up to maintain the scheduler.
>
> Cc: Andrey Grodzovsky
> Cc: airl...@gmail.com
> Cc: daniel.vet...@ffwll.ch
> Signed-off-
Now that the scheduler is being used by more and more
drivers, we need someone to maintain it. Andrey has
stepped up to maintain the scheduler.
Cc: Andrey Grodzovsky
Cc: airl...@gmail.com
Cc: daniel.vet...@ffwll.ch
Signed-off-by: Alex Deucher
---
MAINTAINERS | 8
1 file changed, 8 ins
Fix the path to cover both the older powerplay infrastructure
and the newer SwSMU infrastructure.
Signed-off-by: Alex Deucher
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 851255b71ccc..379092f34fff 100644
--- a/MAINTAINER
On Thu, Sep 16, 2021 at 11:15:52PM +0200, Fernando Ramos wrote:
> The previous commits do exactly what this entry in the TODO file asks
> for, thus we can remove it now as it is no longer applicable.
Thanks for doing this work!
Can we remove drm_modeset_lock_all[_ctx] now? If so, let's queue that
On Thu, Sep 16, 2021 at 11:15:51PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/amd/amdgpu/a
On Thu, Sep 16, 2021 at 11:15:50PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/gma500/psb_d
On Thu, Sep 16, 2021 at 11:15:49PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/i915/display
On Thu, Sep 16, 2021 at 11:15:48PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/msm/disp/dpu
On Thu, Sep 16, 2021 at 11:15:47PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/nouveau/disp
On Thu, Sep 16, 2021 at 11:15:46PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/omapdrm/omap
On Thu, Sep 16, 2021 at 11:15:46PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/omapdrm/omap
On Thu, Sep 16, 2021 at 11:15:45PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/radeon/radeo
On Thu, Sep 16, 2021 at 11:15:44PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
> ---
> dr
On Thu, Sep 16, 2021 at 11:15:43PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/tegra/dsi.c
On Thu, Sep 16, 2021 at 11:15:42PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
Reviewed-by: Sean Paul
> Signed-off-by: Fernando Ramos
> ---
> dr
On Thu, Sep 16, 2021 at 11:15:41PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace driver calls to
> drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
> DRM_MODESET_LOCK_ALL_END()
>
> Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
> ---
> dr
On Thu, Sep 16, 2021 at 11:15:39PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace the boilerplate code
> surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
> and DRM_MODESET_LOCK_ALL_END()
>
With the subject fixed (s/dmr/drm),
Reviewed-by
On Thu, Sep 16, 2021 at 11:15:40PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace the boilerplate code
> surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
> and DRM_MODESET_LOCK_ALL_END()
>
With the subject fixed (s/dmr/drm/),
Reviewed-b
On Thu, Sep 16, 2021 at 11:15:38PM +0200, Fernando Ramos wrote:
> As requested in Documentation/gpu/todo.rst, replace the boilerplate code
> surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
> and DRM_MODESET_LOCK_ALL_END()
>
Hi Fernando,
Thank you for your patch. Could you
On Thu, Sep 16, 2021 at 11:15:37PM +0200, Fernando Ramos wrote:
> Hi all,
>
> One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to
> "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's what this
> patch series is about.
>
> You will find two types of chang
Note that it already has this protection.
Andrey
On 2021-09-17 8:04 a.m., James Zhu wrote:
typo. vcn_v3_0_sw_init --> vcn_v3_0_sw_fini
On 2021-09-17 8:00 a.m., James Zhu wrote:
Hi Andrey
Can you apply this improvement on vcn_v3_0_sw_init also?
With this adding, This patch is Reviewed-by
On Thu, Sep 16, 2021 at 10:10:14AM -0300, Jason Gunthorpe wrote:
> On Thu, Sep 16, 2021 at 02:31:34PM +0200, Daniel Vetter wrote:
> > On Wed, Sep 15, 2021 at 10:45:36AM +0300, Oded Gabbay wrote:
> > > On Tue, Sep 14, 2021 at 7:12 PM Jason Gunthorpe wrote:
> > > >
> > > > On Tue, Sep 14, 2021 at 04
On Thu, Sep 16, 2021 at 03:44:25PM +0300, Oded Gabbay wrote:
> On Thu, Sep 16, 2021 at 3:31 PM Daniel Vetter wrote:
> >
> > On Wed, Sep 15, 2021 at 10:45:36AM +0300, Oded Gabbay wrote:
> > > On Tue, Sep 14, 2021 at 7:12 PM Jason Gunthorpe wrote:
> > > >
> > > > On Tue, Sep 14, 2021 at 04:18:31PM
typo. vcn_v3_0_sw_init --> vcn_v3_0_sw_fini
On 2021-09-17 8:00 a.m., James Zhu wrote:
Hi Andrey
Can you apply this improvement on vcn_v3_0_sw_init also?
With this adding, This patch is Reviewed-by: James Zhu
Thanks & Best Regards!
James
On 2021-09-17 7:30 a.m., Andrey Grodzovsky wrot
Hi Andrey
Can you apply this improvement on vcn_v3_0_sw_init also?
With this adding, This patch is Reviewed-by: James Zhu
Thanks & Best Regards!
James
On 2021-09-17 7:30 a.m., Andrey Grodzovsky wrote:
Add more guards to MMIO access post device
unbind/unplug
Bug:https://bugs.archlinux.org/
Problem:
When device goes into suspend and unplugged during it
then all HW programming during resume fails leading
to a bad SW during pci remove handling which follows.
Because device is first resumed and only later removed
we cannot rely on drm_dev_enter/exit here.
Fix:
Use a flag we use for PCIe
Add more guards to MMIO access post device
unbind/unplug
Bug:https://bugs.archlinux.org/task/72092?project=1&order=dateopened&sort=desc&pagenum=1
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 8 ++--
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 17 +++--
Exactly that, yes. The idea is that we want to create at least some
pressure on VRAM when VRAM|GTT is specified.
Essentially we would like to have that for CS as well, but it's just
hard to find the right balance between no pressure and the full pressure
of VRAM placement for VRAM|GTT BOs.
I
[AMD Official Use Only]
Why? just to evict some inactive vram BOs?
From: Koenig, Christian
Sent: Friday, September 17, 2021 3:06:16 PM
To: Pan, Xinhui ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH] drm/amdgpu: Let BO created in its
Am 17.09.21 um 09:04 schrieb xinhui pan:
For any user BO, it is allowed to alloc memory in both GTT and VRAM
domain. That means one VRAM BO could be eviced to GTT.
Now if device is already lack of VRAM, this BO could alloc memory from
GTT directly without evicting other VRAM BO. In this way we c
For any user BO, it is allowed to alloc memory in both GTT and VRAM
domain. That means one VRAM BO could be eviced to GTT.
Now if device is already lack of VRAM, this BO could alloc memory from
GTT directly without evicting other VRAM BO. In this way we can reduce
memory evictions.
Signed-off-by:
71 matches
Mail list logo
