On Tue, Oct 20, 2020 at 11:14 AM Daniel Vetter wrote:
>
> On Tue, Oct 20, 2020 at 7:23 PM Rob Clark wrote:
> >
> > On Tue, Oct 20, 2020 at 10:02 AM Daniel Vetter wrote:
> > >
> > > On Tue, Oct 20, 2020 at 5:08 PM Rob Clark wrote:
> > > >
>
From: Rob Clark
lockdep dislikes seeing locks unwound in a non-nested fashion.
Fixes: 37c2016e3608 ("drm/msm: Fix race condition in msm driver with async
layer updates")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_atomic.c | 2 +-
drivers/gpu/drm/msm/msm_kms.h| 4 +++
On Wed, Oct 21, 2020 at 12:24 AM Viresh Kumar wrote:
>
> On 05-10-20, 11:56, Viresh Kumar wrote:
> > On 28-08-20, 11:37, 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
> >
On Fri, Oct 23, 2020 at 1:55 AM Kristian Høgsberg wrote:
>
> On Mon, Oct 19, 2020 at 10:45 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > Move grabbing the bo lock into shrinker, with a msm_gem_trylock() to
> > skip over bo's that are already lock
From: Rob Clark
Signed-off-by: Rob Clark
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 1 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 1 +
drivers/gpu/drm/msm/dsi/dsi_host.c| 1 +
drivers/gpu/drm/msm/msm_drv.h | 54
From: Rob Clark
We'll need to introduce a _locked() version of msm_gem_get_iova(), so we
need to make that name available.
Signed-off-by: Rob Clark
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --
From: Rob Clark
This doesn't remove *all* the struct_mutex, but it covers the worst
of it, ie. shrinker/madvise/free/retire. The submit path still uses
struct_mutex, but it still needs *something* serialize a portion of
the submit path, and lock_stat mostly just shows the lock contention
From: Rob Clark
This will make it easier to transition over to obj->resv locking for
everything that is per-bo locking.
Signed-off-by: Rob Clark
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gem.c | 99 ---
drivers/gpu/drm/msm/msm_gem.h |
From: Rob Clark
Rather than relying on the big dev->struct_mutex hammer, introduce a
more specific lock for protecting the bo lists.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_debugfs.c | 7 +++
drivers/
From: Rob Clark
When we cut-over to using dma_resv_lock/etc instead of msm_obj->lock,
we'll need these for the submit path (where resv->lock is already held).
Signed-off-by: Rob Clark
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm
From: Rob Clark
Now that we are not relying on dev->struct_mutex to protect the
ring->submits lists, drop the struct_mutex lock.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gpu.c | 8 +---
1 file chan
From: Rob Clark
Move grabbing the bo lock into shrinker, with a msm_gem_trylock() to
skip over bo's that are already locked. This gets rid of the nested
lock classes.
Signed-off-by: Rob Clark
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gem.c
From: Rob Clark
Before we remove dev->struct_mutex from the retire path, we have to deal
with the situation of a submit retiring before the submit ioctl returns.
To deal with this, ring->submits will hold a reference to the submit,
which is dropped when the submit is retired. And the
From: Rob Clark
Now that active_list/inactive_list is protected by mm_lock, we no longer
need dev->struct_mutex in the free_object() path.
Signed-off-by: Rob Clark
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gem.c | 8
1 file changed, 8 deletions(-)
diff --gi
From: Rob Clark
The microcode bo's should never be madvise(WONTNEED), so these should
not be using msm_gem_get_vaddr_active().
Signed-off-by: Rob Clark
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
2
From: Rob Clark
Before adding another lock, give ring->lock a more descriptive name.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 ++--
drivers/gpu/drm/msm/adreno/a5xx_preempt.c |
From: Rob Clark
We only want to use the _unlocked() variant in the unlocked case.
Signed-off-by: Rob Clark
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gem.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers
From: Rob Clark
This also converts the special msm_gem_get_vaddr_active() to expect the
lock to already be held. There are two call-sites for this, one already
has the lock held, so it is more straightforward to just open-code the
locking for the other caller.
Signed-off-by: Rob Clark
From: Rob Clark
It cannot be atomically updated with obj->active_count, and the only
purpose is a useless WARN_ON() (which becomes a buggy WARN_ON() once
retire_submits() is not serialized with incoming submits via
struct_mutex)
Signed-off-by: Rob Clark
Reviewed-by: Kristian H. Kristen
From: Rob Clark
The obj->lock is sufficient for what we need.
This *does* have the implication that userspace can try to shoot
themselves in the foot by racing madvise(DONTNEED) with submit. But
the result will be about the same if they did madvise(DONTNEED) before
the submit ioctl, ie. t
From: Rob Clark
Now that we don't need struct_mutex in the free path, we can get rid of
the asynchronous free altogether.
Signed-off-by: Rob Clark
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_drv.c | 3 ---
drivers/gpu/drm/msm/msm_drv.h | 5 -
drivers/gpu/dr
From: Rob Clark
Small cleanup, update_fences() is used in the hangcheck path, but also
in the normal retire path.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gpu.c | 28 ++--
1 file changed, 14
From: Rob Clark
It is somewhat redundant with the gpu tracepoints, and anyways not too
useful to justify spamming the log when debug traces are enabled.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gpu.c | 1 -
1 file
From: Rob Clark
We cannot switch to using obj->resv for locking without first moving all
the copy_from_user() ahead of submit_lock_objects(). Otherwise in the
mm fault path we aquire mm->mmap_sem before obj lock, but in the submit
path the order is reversed.
Signed-off-by: Rob Clark
Re
From: Rob Clark
Unfortunately, due to an dev_pm_opp locking interaction with
mm->mmap_sem, we need to do pm get before aquiring obj locks,
otherwise we can have anger lockdep with the chain:
opp_table_lock --> &mm->mmap_sem --> reservation_ww_class_mutex
For an explicit f
From: Rob Clark
If there is only a single ring (no-preemption), everything is FIFO order
and there is no need to implicit-sync.
Mesa should probably just always use MSM_SUBMIT_NO_IMPLICIT, as behavior
is undefined when fences are not used to synchronize buffer usage across
contexts (which is
From: Rob Clark
One less place to rely on dev->struct_mutex.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gem_submit.c | 2 ++
drivers/gpu/drm/msm/msm_gpu.c| 37 ++--
drivers/gpu/drm/
From: Rob Clark
Now that the inactive_list is protected by mm_lock, and everything
else on per-obj basis is protected by obj->lock, we no longer depend
on struct_mutex.
Signed-off-by: Rob Clark
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gem.c | 1 -
drivers/
On Fri, Oct 23, 2020 at 11:20 AM Lucas Stach wrote:
>
> On Fr, 2020-10-23 at 09:51 -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > If there is only a single ring (no-preemption), everything is FIFO order
> > and there is no need to implicit-sync.
> >
>
On Thu, Oct 22, 2020 at 1:06 AM Viresh Kumar wrote:
>
> On 20-10-20, 07:13, Rob Clark wrote:
> > On Tue, Oct 20, 2020 at 4:24 AM Viresh Kumar
> > wrote:
> > >
> > > On 20-10-20, 12:56, Daniel Vetter wrote:
> > > > Yeah that's bad practice.
On Mon, Oct 26, 2020 at 5:48 AM Robin Murphy wrote:
>
> DRM_MSM fails to build with DRM_MSM_DP=n; add the missing stub.
>
> Signed-off-by: Robin Murphy
Thanks..
Reviewed-by: Rob Clark
and looks like,
Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on
Sn
On Thu, Oct 29, 2020 at 9:14 AM Daniel Vetter wrote:
>
> On Mon, Oct 26, 2020 at 10:34 AM Daniel Vetter wrote:
> >
> > On Fri, Oct 23, 2020 at 08:49:14PM -0700, Rob Clark wrote:
> > > On Fri, Oct 23, 2020 at 11:20 AM Lucas Stach
> > > wrote:
> > &g
On Mon, Sep 28, 2020 at 1:47 PM wrote:
>
> From: AngeloGioacchino Del Regno
>
> The Adreno 508/509/512 GPUs are stripped versions of the Adreno
> 5xx found in the mid-end SoCs such as SDM630, SDM636, SDM660 and
> SDA variants; these SoCs are usually provided with ZAP firmwares,
> but they have no
On Mon, Nov 2, 2020 at 11:29 AM Stephen Boyd wrote:
>
> Subject has a typo in "training".
>
> Quoting Kuogee Hsieh (2020-10-30 16:23:24)
> > Some dongles, such as Apple, required link training done at irq_hpd
>
> s/required/require/
>
> > request instead of plugin request. This patch promote irq_h
On Mon, Nov 2, 2020 at 9:47 PM Viresh Kumar wrote:
>
> On 27-10-20, 17:05, Viresh Kumar wrote:
> > It isn't that straight forward unfortunately, we need to make sure the
> > table doesn't get allocated for the same device twice, so
> > find+allocate needs to happen within a locked region.
> >
> >
Should be fixed by:
https://patchwork.freedesktop.org/patch/397039/?series=83038&rev=1
On Mon, Nov 2, 2020 at 7:44 PM dev god wrote:
>
> Hi
>
> fix implicit declaration of function error.
>
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:1229:7: error: implicit
> >> declaration of function 'ms
On Thu, Oct 29, 2020 at 6:01 PM Abhinav Kumar wrote:
>
> Register the base address of various dpu sub-modules with the
> dpu_dbg module so that it can be dumped out during error scenarios.
>
> changes in v2:
> - Fix an issue where the same dsi client was getting registered
>multiple times to
On Wed, Nov 4, 2020 at 12:03 PM Rob Herring wrote:
>
> On Fri, 30 Oct 2020 16:17:12 +0530, Akhil P Oommen wrote:
> > Add cooling device support to gpu. A cooling device is bound to a
> > thermal zone to allow thermal mitigation.
> >
> > Signed-off-by: Akhil P Oommen
> > Reviewed-by: Matthias Kaeh
On Tue, Nov 3, 2020 at 7:04 PM Viresh Kumar wrote:
>
> On 03-11-20, 08:50, Rob Clark wrote:
> > sorry, it didn't apply cleanly (which I guess is due to some other
> > dependencies that need to be picked back to v5.4 product kernel), and
> > due to some other things
On Mon, Nov 9, 2020 at 2:23 PM Jordan Crouse wrote:
>
> Use the new adreno-smmu-priv fault info function to get more SMMU
> debug registers and print the current TTBR0 to debug per-instance
> pagetables and figure out which GPU block generated the request.
>
> Signed-off-by: Jordan Crouse
> ---
>
From: Rob Clark
Similar to the previous patch, clear shadow on suspend to avoid timeouts
waiting for ringbuffer space.
Fixes: 8907afb476ac ("drm/msm: Allow a5xx to mark the RPTR shadow as
privileged")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 12 +
From: Rob Clark
Clear the shadow rptr on suspend. Otherwise, when we resume, we can
have a stale value until CP_WHERE_AM_I executes. If we suspend near
the ringbuffer wraparound point, this can lead to a chicken/egg
situation where we are waiting for ringbuffer space to write the
CP_WHERE_AM_I
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 speed-bin support to a6x family.
>
> Si
On Sat, Nov 14, 2020 at 8:24 AM Christoph Hellwig wrote:
>
> On Sat, Nov 14, 2020 at 10:17:12AM -0500, Jonathan Marek wrote:
> > +void msm_gem_sync_cache(struct drm_gem_object *obj, uint32_t flags,
> > + size_t range_start, size_t range_end)
> > +{
> > + struct msm_gem_object *msm_
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 shr
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 a/drivers/gpu/drm/msm
From: Rob Clark
Previously we only held obj lock in the _active_get() path, and relied
on atomic_dec_return() to not be racy in the _active_put() path where
obj lock was not held.
But this is a false sense of security. Unlike obj lifetime refcnt,
where you do not expect to *increase* the
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
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 wrote:
> >>> +void msm
On Sat, Nov 14, 2020 at 12:10 PM Jonathan Marek wrote:
>
> On 11/14/20 2:39 PM, 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 He
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
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
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
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 shr
From: Rob Clark
Previously we only held obj lock in the _active_get() path, and relied
on atomic_dec_return() to not be racy in the _active_put() path where
obj lock was not held.
But this is a false sense of security. Unlike obj lifetime refcnt,
where you do not expect to *increase* the
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 a/drivers/gpu/drm/msm
On Mon, Nov 16, 2020 at 9:33 AM Christoph Hellwig wrote:
>
> 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
On Thu, Nov 5, 2020 at 11:16 PM Viresh Kumar wrote:
>
> On 05-11-20, 11:24, Rob Clark wrote:
> > On Tue, Nov 3, 2020 at 7:04 PM Viresh Kumar wrote:
> > >
> > > On 03-11-20, 08:50, Rob Clark wrote:
> > > > sorry, it didn't apply cleanly (which I
ers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or
> member 'flush_mask' not described in 'mdp5_ctl_commit'
> drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or
> member 'start' not described in 'mdp5_ctl
On Tue, Nov 17, 2020 at 2:53 PM Stephen Boyd wrote:
>
> Quoting abhin...@codeaurora.org (2020-11-17 12:34:56)
> > On 2020-11-17 09:26, Stephen Boyd wrote:
> > > I don't know what this debug print is for but it is super chatty,
> > > throwing 8 lines of debug prints in the logs every time we update
On Tue, Nov 17, 2020 at 9:28 PM Viresh Kumar wrote:
>
> On 17-11-20, 09:02, Rob Clark wrote:
> > With that on top of the previous patch,
>
> Don't you still have this ? Which fixed the lockdep in the remove path.
>
> https://lore.kernel.org/lkml/20201022080644.2ck4ok
On Mon, Nov 23, 2020 at 9:01 AM Sai Prakash Ranjan
wrote:
>
> On 2020-11-23 20:51, Will Deacon wrote:
> > On Tue, Nov 17, 2020 at 08:00:39PM +0530, Sai Prakash Ranjan wrote:
> >> Some hardware variants contain a system cache or the last level
> >> cache(llc). This cache is typically a large block
On Thu, Nov 19, 2020 at 1:41 PM Abhinav Kumar wrote:
>
> Update the qos remap only if the client type changes for the plane.
> This will avoid unnecessary register programming and also avoid log
> spam from the dpu_vbif_set_qos_remap() function.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/g
On Mon, Nov 23, 2020 at 4:38 PM wrote:
>
> Hi Rob
>
> On 2020-11-23 15:18, Rob Clark wrote:
> > On Thu, Nov 19, 2020 at 1:41 PM Abhinav Kumar
> > wrote:
> >>
> >> Update the qos remap only if the client type changes for the plane.
> >> This w
On Tue, Nov 24, 2020 at 3:10 AM Will Deacon wrote:
>
> On Tue, Nov 24, 2020 at 09:32:54AM +0530, Sai Prakash Ranjan wrote:
> > On 2020-11-24 00:52, Rob Clark wrote:
> > > On Mon, Nov 23, 2020 at 9:01 AM Sai Prakash Ranjan
> > > wrote:
> > > >
>
On Tue, Nov 24, 2020 at 1:43 PM Will Deacon wrote:
>
> On Tue, Nov 24, 2020 at 11:05:39AM -0800, Rob Clark wrote:
> > On Tue, Nov 24, 2020 at 3:10 AM Will Deacon wrote:
> > > On Tue, Nov 24, 2020 at 09:32:54AM +0530, Sai Prakash Ranjan wrote:
> > > > On
From: Rob Clark
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: warning: Function
On Mon, Nov 16, 2020 at 9:55 AM Jonathan Marek wrote:
>
> On 11/16/20 12:50 PM, Rob Clark wrote:
> > On Mon, Nov 16, 2020 at 9:33 AM Christoph Hellwig wrote:
> >>
> >> On Sat, Nov 14, 2020 at 03:07:20PM -0500, Jonathan Marek wrote:
> >>> qcom's
to the heap
drm/msm/disp/dpu1/dpu_hw_interrupts: Demote kernel-doc formatting misuse
Marijn Suijten (1):
drm/msm: a5xx: Make preemption reset case reentrant
Rikard Falkeborn (1):
drm/msm: dsi: Constify dsi_host_ops
Rob Clark (33):
drm/msm/atomic: Drop per-CRTC locks in reverse
From: Rob Clark
[ 192.062000] [ cut here ]
[ 192.062498] WARNING: CPU: 3 PID: 2039 at drivers/gpu/drm/msm/msm_gem.c:381
put_iova_vmas+0x94/0xa0 [msm]
[ 192.062870] Modules linked in: snd_hrtimer snd_seq snd_seq_device rfcomm
algif_hash algif_skcipher af_alg bnep
On Mon, Dec 14, 2020 at 3:41 AM Kalyan Thota wrote:
>
> Turn off vblank irqs immediately as soon as drm_vblank_put is
> requested so that there are no irqs triggered during idle state.
>
> This will reduce cpu wakeups and help in power saving. The change
> also enable driver timestamp for vblanks.
On Sat, Jan 2, 2021 at 12:26 PM Iskren Chernev wrote:
>
> The msm_gem_get_iova should be guarded with gpu != NULL and not aspace
> != NULL, because aspace is NULL when using vram carveout.
>
> Fixes: 933415e24bd0d ("drm/msm: Add support for private address space
> instances")
>
> Signed-off-by: I
On Wed, Jan 6, 2021 at 8:50 PM Sai Prakash Ranjan
wrote:
>
> On 2021-01-05 01:00, Konrad Dybcio wrote:
> > Using this code on A5xx (and probably older too) causes a
> > smmu bug.
> >
> > Fixes: 474dadb8b0d5 ("drm/msm/a6xx: Add support for using system
> > cache(LLC)")
> > Signed-off-by: Konrad Dyb
connection pending state
Rob Clark (1):
drm/msm: Fix WARN_ON() splat in _free_object()
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 6 --
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 6 --
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 6 --
drivers/gpu/drm/msm/adreno/adreno_device.c
On Thu, Jan 7, 2021 at 9:20 AM Rob Clark wrote:
>
> On Sat, Jan 2, 2021 at 12:26 PM Iskren Chernev
> wrote:
> >
> > The msm_gem_get_iova should be guarded with gpu != NULL and not aspace
> > != NULL, because aspace is NULL when using vram carveout.
> >
> &
On Fri, Jan 8, 2021 at 6:05 AM Sai Prakash Ranjan
wrote:
>
> On 2021-01-08 19:09, Konrad Dybcio wrote:
> >> Konrad, can you please test this below change without your change?
> >
> > This brings no difference, a BUG still happens. We're still calling
> > to_a6xx_gpu on ANY device that's probed! To
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 535a026..8be3506 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -1369,3 +1369,4 @@ module_exit(msm_drm_unregister);
> MODULE_AUTHOR(&quo
it sounds like earlier kernels worked, did you
> attempt bisecting? Also for regressions put regressions into the
> subject, it's the magic work that gets much more attention.
the root issue is how are we doing KMS stuff on imx (where drm/msm is
only used for gpu).. which I think is thi
forgot to CC Krishna
On Tue, Jan 19, 2021 at 8:34 AM Rob Clark wrote:
>
> On Mon, Jan 18, 2021 at 11:00 PM Daniel Vetter wrote:
> >
> > On Mon, Jan 18, 2021 at 11:00 PM Fabio Estevam wrote:
> > >
> > > On Mon, Jan 18, 2021 at 6:44 PM Fabio Estevam wrote:
&g
On Mon, Jan 18, 2021 at 1:39 PM Will Deacon wrote:
>
> On Mon, Jan 18, 2021 at 01:16:03PM -0800, Rob Clark wrote:
> > On Mon, Dec 21, 2020 at 4:44 PM Isaac J. Manjarres
> > wrote:
> > >
> > > The MSM DRM driver depends on the availability of the ARM LPAE
On Mon, Jan 11, 2021 at 4:04 AM Sai Prakash Ranjan
wrote:
>
> A6XX GPUs have support for last level cache(LLC) also known
> as system cache and need to set the bus attributes to
> use it. Currently we use a generic adreno iommu address space
> implementation which are also used by older GPU genera
On Wed, Jan 20, 2021 at 3:04 AM AngeloGioacchino Del Regno
wrote:
>
> Il 11/01/21 13:04, Sai Prakash Ranjan ha scritto:
> > A6XX GPUs have support for last level cache(LLC) also known
> > as system cache and need to set the bus attributes to
> > use it. Currently we use a generic adreno iommu addr
On Mon, Jan 25, 2021 at 3:49 PM Stephen Boyd wrote:
>
> Lockdep complains about an AA deadlock when rebooting the device.
>
>
> WARNING: possible recursive locking detected
> 5.4.91 #1 Not tainted
>
> reboot/
On Wed, Jan 27, 2021 at 3:39 PM Eric Anholt wrote:
>
> Now that we're not racing with GPU setup, also fix races of timestamps
> against other timestamps. In CI, we were seeing this path trigger
> timeouts on setting the GMU bit, especially on the first set of tests
> right after boot (it's probab
On Fri, Dec 18, 2020 at 2:27 AM Kalyan Thota wrote:
>
> Set the flag vblank_disable_immediate = true to turn off vblank irqs
> immediately as soon as drm_vblank_put is requested so that there are
> no irqs triggered during idle state. This will reduce cpu wakeups
> and help in power saving.
>
> To
On Sat, Jan 9, 2021 at 5:51 AM AngeloGioacchino Del Regno
wrote:
>
> The VCO rate was being miscalculated due to a big overlook during
> the process of porting this driver from downstream to upstream:
> here we are really recalculating the rate of the VCO by reading
> the appropriate registers and
On Mon, Feb 1, 2021 at 2:11 AM AngeloGioacchino Del Regno
wrote:
>
> Il 31/01/21 20:50, Rob Clark ha scritto:
> > On Sat, Jan 9, 2021 at 5:51 AM AngeloGioacchino Del Regno
> > wrote:
> >>
> >> The VCO rate was being miscalculated due to a big overlook dur
On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote:
>
> On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash Ranjan wrote:
> > On 2021-01-29 14:35, Will Deacon wrote:
> > > On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash Ranjan wrote:
> > > > Add a new page protection flag IOMMU_LLC which can
On Mon, Feb 1, 2021 at 7:47 AM Rob Clark wrote:
>
> On Mon, Feb 1, 2021 at 2:11 AM AngeloGioacchino Del Regno
> wrote:
> >
> > Il 31/01/21 20:50, Rob Clark ha scritto:
> > > On Sat, Jan 9, 2021 at 5:51 AM AngeloGioacchino Del Regno
> > > wrote:
> > &
On Mon, Feb 1, 2021 at 9:05 AM Rob Clark wrote:
>
> On Mon, Feb 1, 2021 at 7:47 AM Rob Clark wrote:
> >
> > On Mon, Feb 1, 2021 at 2:11 AM AngeloGioacchino Del Regno
> > wrote:
> > >
> > > Il 31/01/21 20:50, Rob Clark ha scritto:
> > > > On
On Mon, Feb 1, 2021 at 9:18 AM Rob Clark wrote:
>
> On Mon, Feb 1, 2021 at 9:05 AM Rob Clark wrote:
> >
> > On Mon, Feb 1, 2021 at 7:47 AM Rob Clark wrote:
> > >
> > > On Mon, Feb 1, 2021 at 2:11 AM AngeloGioacchino Del Regno
> > > wrote:
> >
On Tue, Feb 2, 2021 at 7:46 AM Daniel Vetter wrote:
>
> On Mon, Jan 25, 2021 at 03:49:01PM -0800, Stephen Boyd wrote:
> > Lockdep complains about an AA deadlock when rebooting the device.
> >
> >
> > WARNING: possible recursive locking detected
> > 5.4.
On Tue, Feb 2, 2021 at 6:32 AM AngeloGioacchino Del Regno
wrote:
>
> Il 01/02/21 18:31, Rob Clark ha scritto:
> > On Mon, Feb 1, 2021 at 9:18 AM Rob Clark wrote:
> >>
> >> On Mon, Feb 1, 2021 at 9:05 AM Rob Clark wrote:
> >>>
> >&g
On Tue, Feb 2, 2021 at 10:46 AM AngeloGioacchino Del Regno
wrote:
>
> Il 02/02/21 19:45, Rob Clark ha scritto:
> > On Tue, Feb 2, 2021 at 6:32 AM AngeloGioacchino Del Regno
> > wrote:
> >>
> >> Il 01/02/21 18:31, Rob Clark ha scritto:
> >>>
On Tue, Feb 2, 2021 at 11:08 AM Rob Clark wrote:
>
> On Tue, Feb 2, 2021 at 10:46 AM AngeloGioacchino Del Regno
> wrote:
> >
> > Il 02/02/21 19:45, Rob Clark ha scritto:
> > > On Tue, Feb 2, 2021 at 6:32 AM AngeloGioacchino Del Regno
> > > wrote:
> &
On Wed, Feb 3, 2021 at 2:10 AM Daniel Vetter wrote:
>
> On Tue, Feb 02, 2021 at 08:51:25AM -0800, Rob Clark wrote:
> > On Tue, Feb 2, 2021 at 7:46 AM Daniel Vetter wrote:
> > >
> > > On Mon, Jan 25, 2021 at 03:49:01PM -0800, Stephen Boyd wrote:
> > > > L
On Wed, Feb 3, 2021 at 1:58 PM Stephen Boyd wrote:
>
> Quoting Rob Clark (2021-02-03 09:29:09)
> > On Wed, Feb 3, 2021 at 2:10 AM Daniel Vetter wrote:
> > >
> > > On Tue, Feb 02, 2021 at 08:51:25AM -0800, Rob Clark wrote:
> > > > On Tue, F
On Wed, Feb 3, 2021 at 1:46 PM Will Deacon wrote:
>
> On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote:
> > On 2021-02-01 23:50, Jordan Crouse wrote:
> > > On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote:
> > > > On Mon, Feb 1, 2
From: Rob Clark
In moving code around, we ended up using the same pointer to
copy_from_user() the relocs tables as we used for the cmd table
entry, which is clearly not right. This went unnoticed because
modern mesa on non-ancent kernels does not actually use relocs.
But this broke ancient mesa
er irq_hpd handler
drm/msm/dp: reset dp controller only at boot up and pm_resume
Rob Clark (1):
drm/msm: Fix legacy relocs path
Sai Prakash Ranjan (2):
drm/msm: Add proper checks for GPU LLCC support
drm/msm/a6xx: Create an A6XX GPU specific address space
Stephen Boyd (2):
1 - 100 of 2689 matches
Mail list logo
