From: Rob Clark
Just because a obj is active, if the vmap_count is zero, we can still
tear down the vmap.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_shrinker.c | 47 +++---
1 file changed, 35 insertions(+), 12 deletions(-)
diff --git
From: Rob Clark
The last patch is the main thing, motivated by some cases where we would
spend a lot of time in msm_gem_shrinker_count(). First two are fixes I
noticed along the way.
Rob Clark (3):
drm/msm: Protect obj->active_count under obj lock
drm/msm/shrinker: We can vmap shrink
From: Rob Clark
In situations where the GPU is mostly idle, all or nearly all buffer
objects will be in the inactive list. But if the system is under memory
pressure (from something other than GPU), we could still get a lot of
shrinker calls. Which results in traversing a list of thousands of
Very little attempt has been made to document these functions.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or
member 'ctl' not described in 'mdp5_ctl_set_encoder_state'
drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c:299:5: warning: no previous prototype
for ‘mdp5_disable’ [-Wmissing-prototypes]
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c:319:5: warning: no previous prototype
for ‘mdp5_enable’ [-Wmissing-prototypes]
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/adreno/a6xx_gpu.c:33:6: warning: no previous prototype for
‘a6xx_idle’ [-Wmissing-prototypes]
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: linux-arm-...@vger.kernel.org
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c:581:5: warning: no previous
prototype for ‘mdp5_crtc_setup_pipeline’ [-Wmissing-prototypes]
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c: In function
‘dpu_encoder_virt_mode_set’:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:981:31: warning: variable
‘num_dspp’ set but not used [-Wunused-but-set-variable]
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c: In function
‘_dpu_core_perf_calc_crtc’:
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:113:25: warning: variable
‘dpu_cstate’ set but not used [-Wunused-but-set-variable]
Cc: Rob Clark
Cc: Sean
On Sat, Nov 14, 2020 at 03:07:20PM -0500, Jonathan Marek wrote:
> qcom's vulkan driver has nonCoherentAtomSize=1, and it looks like
> dma_sync_single_for_cpu() does deal in some way with the partial cache line
> case, although I'm not sure that means we can have a nonCoherentAtomSize=1.
No, it
This set contains fixes for some "wouldn't it be nice if" issues,
however most of the patches seen here have been on the MLs, but
were left unreviewed.
Lee Jones (42):
drm/amd/amdgpu/atombios_encoders: Remove set but unused variable
'backlight_level'
drm/armada/armada_overlay: Staticify
On Mon, Nov 16, 2020 at 9:20 AM Jordan Crouse wrote:
>
> On Sat, Nov 14, 2020 at 11:30:10AM -0800, Rob Clark wrote:
> > From: Rob Clark
> >
> > In situations where the GPU is mostly idle, all or nearly all buffer
> > objects will be in the inactive list. But if the system is under memory
> >
On Sat, Nov 14, 2020 at 11:39:45AM -0800, Rob Clark wrote:
> On Sat, Nov 14, 2020 at 10:58 AM Jonathan Marek wrote:
> >
> > On 11/14/20 1:46 PM, Rob Clark wrote:
> > > On Sat, Nov 14, 2020 at 8:24 AM Christoph Hellwig wrote:
> > >>
> > >> On Sat, Nov 14, 2020 at 10:17:12AM -0500, Jonathan Marek
On Sat, Nov 14, 2020 at 10:17:12AM -0500, Jonathan Marek wrote:
> This makes it possible to use the non-coherent cached MSM_BO_CACHED mode,
> which otherwise doesn't provide any method for cleaning/invalidating the
> cache to sync with the device.
>
> Signed-off-by: Jonathan Marek
> ---
>
On Sat, Nov 14, 2020 at 11:30:10AM -0800, Rob Clark wrote:
> From: Rob Clark
>
> In situations where the GPU is mostly idle, all or nearly all buffer
> objects will be in the inactive list. But if the system is under memory
> pressure (from something other than GPU), we could still get a lot of
On Mon, Nov 16, 2020 at 07:40:03PM +0530, Akhil P Oommen wrote:
> On 11/12/2020 10:05 PM, Jordan Crouse wrote:
> >On Thu, Nov 12, 2020 at 09:19:04PM +0530, Akhil P Oommen wrote:
> >>So far a530v2 gpu has support for detecting its supported opps
> >>based on a fuse value called speed-bin. This
On Mon, Nov 16, 2020 at 6:34 AM Akhil P Oommen wrote:
>
> On 11/12/2020 10:07 PM, Rob Clark wrote:
> > On Thu, Nov 12, 2020 at 7:49 AM Akhil P Oommen
> > wrote:
> >>
> >> So far a530v2 gpu has support for detecting its supported opps
> >> based on a fuse value called speed-bin. This patch makes
Applied to drm-misc-next.
On Wed, Oct 28, 2020 at 2:44 PM Viresh Kumar wrote:
>
> dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
> find the OPP table with error -ENODEV (i.e. OPP table not present for
> the device). And we can call dev_pm_opp_of_remove_table()
>
On 11/12/2020 10:07 PM, Rob Clark wrote:
On Thu, Nov 12, 2020 at 7:49 AM Akhil P Oommen wrote:
So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes this
support generic across gpu families. This is in preparation to
extend
On 11/12/2020 10:05 PM, Jordan Crouse wrote:
On Thu, Nov 12, 2020 at 09:19:04PM +0530, Akhil P Oommen wrote:
So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes this
support generic across gpu families. This is in preparation
20 matches
Mail list logo
