On Sat, Apr 17, 2021 at 9:21 AM Caleb Connolly wrote:
>
> The WARN_ON in dpu_runtime_resume() fires constantly on non-SC7180
> platforms. As SDM845 now has interconnects hooked up we should always
> try and parse them.
>
> Fixes: 627dc55c273d ("drm/msm/disp/dpu1: icc path needs to be set before
On Thu, Apr 15, 2021 at 9:33 PM Dan Carpenter wrote:
>
> On Thu, Apr 15, 2021 at 04:21:01PM -0700, Rob Clark wrote:
> > > > 5785dd7a8ef0de Akhil P Oommen 2020-10-28 571 icc_path =
> > > > devm_of_icc_get(>dev, "gfx-mem");
> > > > 57
) error: passing
> > non negative 1 to ERR_PTR
> >
> > vim +600 drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> >
> > 7198e6b03155f6 Rob Clark 2013-07-19 515 struct msm_gpu
> > *a3xx_gpu_init(struct drm_device *dev)
> > 7198e6b03155f6 Rob Clark 2013-07-19
On Mon, Apr 12, 2021 at 7:28 AM Daniel Vetter wrote:
>
> On Thu, Apr 08, 2021 at 08:23:42AM -0700, Rob Clark wrote:
> > On Thu, Apr 8, 2021 at 4:15 AM Daniel Vetter wrote:
> > >
> > > On Mon, Apr 05, 2021 at 10:45:23AM -0700, Rob Clark wrote:
> > > >
On Thu, Apr 8, 2021 at 4:16 PM AngeloGioacchino Del Regno
wrote:
>
>
> Il gio 8 apr 2021, 21:05 Rob Clark ha scritto:
>>
>> On Wed, Apr 7, 2021 at 12:11 PM AngeloGioacchino Del Regno
>> wrote:
>> >
>> > Il 07/04/21 20:19, abhin..
On Wed, Apr 7, 2021 at 12:11 PM AngeloGioacchino Del Regno
wrote:
>
> Il 07/04/21 20:19, abhin...@codeaurora.org ha scritto:
> > Hi Marijn
> >
> > On 2021-04-06 14:47, Marijn Suijten wrote:
> >> Leaving this at a close-to-maximum register value 0xFFF0 means it takes
> >> very long for the MDSS to
On Thu, Apr 8, 2021 at 4:15 AM Daniel Vetter wrote:
>
> On Mon, Apr 05, 2021 at 10:45:23AM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > One would normally hope not to be under enough memory pressure to need
> > to swap GEM objects to disk backed swap
From: Rob Clark
The previous patch fixes the user visible spelling. This one fixes the
code. Oops.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 12 ++--
drivers/gpu/drm/msm/msm_gem.h | 16
drivers/gpu/drm/msm/msm_gem_shrinker.c | 2
On Tue, Apr 6, 2021 at 6:39 AM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in debugfs gem stats. Fix it. Also
> re-align output to cater for the extra 1 character.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/msm/msm_gem.c | 8
> 1 file
From: Rob Clark
Now that tracking is wired up for potentially evictable GEM objects,
wire up shrinker and the remaining GEM bits for unpinning backing pages
of inactive objects.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 23
drivers/gpu/drm/msm
From: Rob Clark
Shoot down any mmap's *first* before put_pages(). Also add a WARN_ON
that the object is locked (to make it clear that this doesn't race with
msm_gem_fault()) and remove a redundant WARN_ON (since is_purgable()
already covers that case).
Fixes: 68209390f116 ("drm/msm: shr
From: Rob Clark
Objects that are potential for swapping out are (1) willneed (ie. if
they are purgable/MADV_WONTNEED we can just free the pages without them
having to land in swap), (2) not on an active list, (3) not dma-buf
imported or exported, and (4) not vmap'd. This repurposes the purged
From: Rob Clark
Currently nearly everything, other than newly allocated objects which
are not yet backed by pages, is pinned and resident in RAM. But it will
be nice to have some stats on what is unpinned once that is supported.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 7
From: Rob Clark
Currently these always go together, either when we purge MADV_WONTNEED
objects or when the object is freed. But for unpin, we want to be able
to purge (unmap from iommu) the vma, while keeping the iova range
allocated (so we can remap back to the same GPU virtual address when
From: Rob Clark
Currently this doesn't matter since we keep the pages pinned until the
object is destroyed. But when we start unpinning pages to allow objects
to be evicted to swap, it will.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 1 +
1 file changed, 1 insertion
From: Rob Clark
So we don't have to duplicate the boilerplate for eviction.
This also lets us re-use the main scan loop for vmap shrinker.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_shrinker.c | 94 +-
1 file changed, 46 insertions(+), 48 deletions
From: Rob Clark
If you mess something up, you don't really need to see the same warn on
splat 4000 times pumped out a slow debug UART port..
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 66 +--
drivers/gpu/drm/msm/msm_gem.h | 19 ++
2
From: Rob Clark
One would normally hope not to be under enough memory pressure to need
to swap GEM objects to disk backed swap. But memory backed zram swap
(as enabled on chromebooks, for example) can actually be quite fast
and useful on devices with less RAM. On a 4GB device, opening up ~4
From: Rob Clark
lock_stat + mmm_donut[1] say that this reduces contention on mm_lock
significantly (~350x lower waittime-max, and ~100x lower waittime-avg)
[1]
https://chromium.googlesource.com/chromiumos/platform/microbenchmarks/+/refs/heads/main/mmm_donut.py
Signed-off-by: Rob Clark
On Fri, Apr 2, 2021 at 4:55 AM Kalyan Thota wrote:
>
> Update the 3d merge as active in the data path only if
> the hw block is selected in the configuration.
>
> Reported-by: Stephen Boyd
Thanks, I've added:
Fixes: 73bfb790ac78 ("msm:disp:dpu1: setup display datapath for SC7180 target")
>
On Thu, Apr 1, 2021 at 2:03 PM Dmitry Baryshkov
wrote:
>
> On Thu, 1 Apr 2021 at 23:09, Rob Clark wrote:
> >
> > On Mon, Feb 22, 2021 at 8:06 AM Rob Clark wrote:
> > >
> > > On Mon, Feb 22, 2021 at 7:45 AM Akhil P Oommen
> > > wrote:
> >
On Mon, Feb 22, 2021 at 8:06 AM Rob Clark wrote:
>
> On Mon, Feb 22, 2021 at 7:45 AM Akhil P Oommen wrote:
> >
> > On 2/19/2021 9:30 PM, Rob Clark wrote:
> > > On Fri, Feb 19, 2021 at 2:44 AM Akhil P Oommen
> > > wrote:
> > >>
> > >>
From: Rob Clark
lock_stat + mmm_donut[1] say that this reduces contention on mm_lock
significantly (~350x lower waittime-max, and ~100x lower waittime-avg)
[1]
https://chromium.googlesource.com/chromiumos/platform/microbenchmarks/+/refs/heads/main/mmm_donut.py
Signed-off-by: Rob Clark
On Thu, Apr 1, 2021 at 8:34 AM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Mar 31, 2021 at 6:24 PM Rob Clark wrote:
> >
> > @@ -45,6 +30,9 @@ msm_gem_shrinker_scan(struct shrinker *shrinker, struct
> > shrink_control *sc)
> > list_for_each_entry(
From: Rob Clark
The last patch lost the breakdown of active vs inactive GEM objects in
$debugfs/gem. But we can add some better stats to summarize not just
active vs inactive, but also purgable/purged to make up for that.
Signed-off-by: Rob Clark
Tested-by: Douglas Anderson
Reviewed
From: Rob Clark
When the system is under heavy memory pressure, we can end up with lots
of concurrent calls into the shrinker. Keeping a running tab on what we
can shrink avoids grabbing a lock in shrinker->count(), and avoids
shrinker->scan() getting called when not profitable.
Also,
From: Rob Clark
Unused since commit c951a9b284b9 ("drm/msm: Remove msm_gem_free_work")
Signed-off-by: Rob Clark
Tested-by: Douglas Anderson
---
drivers/gpu/drm/msm/msm_gem.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm
From: Rob Clark
In normal cases the gem obj lock is acquired first before mm_lock. The
exception is iterating the various object lists. In the shrinker path,
deadlock is avoided by using msm_gem_trylock() and skipping over objects
that cannot be locked. But for debugfs the straightforward
From: Rob Clark
I've been spending some time looking into how things behave under high
memory pressure. The first patch is a random cleanup I noticed along
the way. The second improves the situation significantly when we are
getting shrinker called from many threads in parallel. And the last
On Wed, Mar 31, 2021 at 4:39 PM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Mar 31, 2021 at 4:23 PM Rob Clark wrote:
> >
> > On Wed, Mar 31, 2021 at 3:44 PM Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Mar 31, 2021 at
On Wed, Mar 31, 2021 at 4:13 PM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Mar 31, 2021 at 3:14 PM Rob Clark wrote:
> >
> > @@ -111,23 +111,15 @@ static const struct file_operations msm_gpu_fops = {
> > static int msm_gem_show(struct drm_device *dev, struct seq_file
On Wed, Mar 31, 2021 at 3:44 PM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Mar 31, 2021 at 3:14 PM Rob Clark wrote:
> >
> > @@ -818,11 +820,19 @@ static void update_inactive(struct msm_gem_object
> > *msm_obj)
> > mutex_lock(>mm_lock);
> &g
On Wed, Mar 31, 2021 at 9:03 AM Dmitry Baryshkov
wrote:
>
> On 31/03/2021 14:27, Kalyan Thota wrote:
> > WARN_ON was introduced by the below commit to catch runtime resumes
> > that are getting triggered before icc path was set.
> >
> > "drm/msm/disp/dpu1: icc path needs to be set before dpu
On Thu, Mar 25, 2021 at 7:37 AM Jordan Crouse wrote:
>
> jcrouse at codeaurora.org ha started bouncing. Redirect to a
nit: s/ha/has/
> more permanent address.
>
> Signed-off-by: Jordan Crouse
Acked-by: Rob Clark
> ---
>
> .mailmap | 1 +
> 1 file changed, 1
From: Rob Clark
The last patch lost the breakdown of active vs inactive GEM objects in
$debugfs/gem. But we can add some better stats to summarize not just
active vs inactive, but also purgable/purged to make up for that.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_fb.c | 3
From: Rob Clark
In normal cases the gem obj lock is acquired first before mm_lock. The
exception is iterating the various object lists. In the shrinker path,
deadlock is avoided by using msm_gem_trylock() and skipping over objects
that cannot be locked. But for debugfs the straightforward
From: Rob Clark
When the system is under heavy memory pressure, we can end up with lots
of concurrent calls into the shrinker. Keeping a running tab on what we
can shrink avoids grabbing a lock in shrinker->count(), and avoids
shrinker->scan() getting called when not profitable.
Also,
From: Rob Clark
Unused since c951a9b284b907604759628d273901064c60d09f
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index b3a0a880cbab..7a9107cf1818 100644
From: Rob Clark
I've been spending some time looking into how things behave under high
memory pressure. The first patch is a random cleanup I noticed along
the way. The second improves the situation significantly when we are
getting shrinker called from many threads in parallel. And the last
On Tue, Mar 30, 2021 at 8:31 AM Will Deacon wrote:
>
> On Tue, Mar 30, 2021 at 08:03:36AM -0700, Rob Clark wrote:
> > On Tue, Mar 30, 2021 at 2:34 AM Will Deacon wrote:
> > >
> > > On Mon, Mar 29, 2021 at 09:02:50PM -0700, Rob Clark wrote:
> > > > O
On Tue, Mar 30, 2021 at 2:34 AM Will Deacon wrote:
>
> On Mon, Mar 29, 2021 at 09:02:50PM -0700, Rob Clark wrote:
> > On Mon, Mar 29, 2021 at 7:47 AM Will Deacon wrote:
> > >
> > > On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
> > > > db8
On Mon, Mar 29, 2021 at 7:47 AM Will Deacon wrote:
>
> On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
> > db820c wants to use the qcom smmu path to get HUPCF set (which keeps
> > the GPU from wedging and then sometimes wedging the kernel after a
> > page fault), but it doesn't have
On Fri, Mar 26, 2021 at 5:33 PM Rob Clark wrote:
>
> On Fri, Mar 26, 2021 at 4:48 PM Rob Herring wrote:
> >
> > On Fri, Mar 26, 2021 at 4:13 PM Rob Clark wrote:
> > >
> > > On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote:
> > > >
> >
On Fri, Mar 26, 2021 at 4:48 PM Rob Herring wrote:
>
> On Fri, Mar 26, 2021 at 4:13 PM Rob Clark wrote:
> >
> > On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote:
> > >
> > > On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote:
> > > >
> >
On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote:
>
> On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote:
> >
> > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote:
> > >
> > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding
> > > wrote:
> > &
On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote:
>
> On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding
> wrote:
> >
> > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote:
> > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke
> > > wrote:
> &
On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding wrote:
>
> On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote:
> > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke wrote:
> > >
> > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote:
> >
From: Rob Clark
A couple kernel side things I realized I needed in the process of
implementing performance-counter and render-stage support for perfetto,
the first patch fixes the MSM_PARAM_TIMESTAMP query which was just
wrong on a5xx/a6xx (ALWAYS_COUNT vs ALWAYS_ON). The second adds a
way
From: Rob Clark
Performance counts, and ALWAYS_ON counters used for capturing GPU
timestamps, lose their state across suspend/resume cycles. Userspace
tooling for performance monitoring needs to be aware of this. For
example, after a suspend userspace needs to recalibrate it's offset
between
From: Rob Clark
They were reading a counter that was configured to ALWAYS_COUNT (ie.
cycles that the GPU is doing something) rather than ALWAYS_ON. This
isn't the thing that userspace is looking for.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 ++--
drivers/gpu/drm
On Mon, Mar 22, 2021 at 5:44 PM Matthias Kaehlcke wrote:
>
> On Mon, Mar 22, 2021 at 02:17:12AM -0700, Kalyan Thota wrote:
> > From: Kalyan Thota
> >
> > DPU runtime resume will request for a min vote on the AXI bus as
> > it is a necessary step before turning ON the AXI clock.
> >
> > The
epresentative panel was
> > listed in the device tree. The power sequencings of this
> > representative panel were OK to use across all panels that might be
> > attached and other differences were handled by EDID. This patch
> > attempts to set a new precedent and avoid the ne
From: Rob Clark
We have seen a couple cases where low memory situations cause something
bad to happen, followed by a flood of these messages obscuring the root
cause. Lets ratelimit the dmesg spam so that next time it happens we
don't loose the kernel traces leading up to this.
Signed-off
On Tue, Mar 16, 2021 at 10:04 AM Rob Clark wrote:
>
> On Wed, Feb 3, 2021 at 2:14 PM Rob Clark wrote:
> >
> > 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:
> > &g
On Wed, Feb 3, 2021 at 2:14 PM Rob Clark wrote:
>
> 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, 20
On Fri, Feb 26, 2021 at 9:24 AM Bjorn Andersson
wrote:
>
> On Fri 26 Feb 03:55 CST 2021, Sai Prakash Ranjan wrote:
>
> > Adreno(GPU) SMMU and APSS(Application Processor SubSystem) SMMU
> > both implement "arm,mmu-500" in some QTI SoCs and to run through
> > adreno smmu specific implementation
ch also brings in changes to support vblank_disable_immediate
> requirement in dpu driver.
>
> Changes in v1:
> - Specify reason to add vblank timestamp support. (Rob).
> - Add changes to provide vblank counter from dpu driver.
>
> Changes in v2:
> - Fix warn stack reported by Rob Clark with v2
On Mon, Feb 22, 2021 at 7:45 AM Akhil P Oommen wrote:
>
> On 2/19/2021 9:30 PM, Rob Clark wrote:
> > On Fri, Feb 19, 2021 at 2:44 AM Akhil P Oommen
> > wrote:
> >>
> >> On 2/18/2021 9:41 PM, Rob Clark wrote:
> >>> On Thu, Feb 18, 2021 at 4:28 AM
On Fri, Feb 19, 2021 at 2:44 AM Akhil P Oommen wrote:
>
> On 2/18/2021 9:41 PM, Rob Clark wrote:
> > On Thu, Feb 18, 2021 at 4:28 AM Akhil P Oommen
> > wrote:
> >>
> >> On 2/18/2021 2:05 AM, Jonathan Marek wrote:
> >>> On 2/17/21 3:18 PM, Rob Clar
On Thu, Feb 18, 2021 at 4:28 AM Akhil P Oommen wrote:
>
> On 2/18/2021 2:05 AM, Jonathan Marek wrote:
> > On 2/17/21 3:18 PM, Rob Clark wrote:
> >> On Wed, Feb 17, 2021 at 11:08 AM Jordan Crouse
> >> wrote:
> >>>
> >>> On Wed, Feb 17, 2021
On Wed, Feb 17, 2021 at 11:08 AM Jordan Crouse wrote:
>
> On Wed, Feb 17, 2021 at 07:14:16PM +0530, Akhil P Oommen wrote:
> > On 2/17/2021 8:36 AM, Rob Clark wrote:
> > >On Tue, Feb 16, 2021 at 12:10 PM Jonathan Marek wrote:
> > >>
> > >>Ignore nvme
On Tue, Feb 16, 2021 at 12:10 PM Jonathan Marek wrote:
>
> Ignore nvmem_cell_get() EOPNOTSUPP error in the same way as a ENOENT error,
> to fix the case where the kernel was compiled without CONFIG_NVMEM.
>
> Fixes: fe7952c629da ("drm/msm: Add speed-bin support to a618 gpu")
> Signed-off-by:
On Tue, Feb 16, 2021 at 10:06 AM Jonathan Marek wrote:
>
> On 2/16/21 11:54 AM, Dmitry Baryshkov wrote:
> > On Mon, 15 Feb 2021 at 19:25, Jonathan Marek wrote:
> >>
> >> The driver already has support for sm8150/sm8250, but the compatibles were
> >> never added.
> >>
> >> Also inverse the
On Tue, Feb 16, 2021 at 7:21 AM wrote:
>
> On 2021-02-12 23:19, Rob Clark wrote:
> > On Thu, Feb 11, 2021 at 7:31 AM wrote:
> >>
> >> On 2021-02-11 01:56, Rob Clark wrote:
> >> > On Wed, Feb 10, 2021 at 3:41 AM wrote:
> >> >>
> >&
On Fri, Feb 12, 2021 at 3:45 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.
>
>
On Thu, Feb 11, 2021 at 7:31 AM wrote:
>
> On 2021-02-11 01:56, Rob Clark wrote:
> > On Wed, Feb 10, 2021 at 3:41 AM wrote:
> >>
> >> On 2021-02-01 00:46, Rob Clark wrote:
> >> > On Fri, Dec 18, 2020 at 2:27 AM Kalyan Thota
> >> > wrote:
On Wed, Feb 10, 2021 at 3:41 AM wrote:
>
> On 2021-02-01 00:46, Rob Clark wrote:
> > On Fri, Dec 18, 2020 at 2:27 AM Kalyan Thota
> > wrote:
> >>
> >> Set the flag vblank_disable_immediate = true to turn off vblank irqs
> >> immediat
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
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
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 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 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 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 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 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
> >
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 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 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 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
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 overloo
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.
>
>
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
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
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
>
>
On Tue, Jan 26, 2021 at 3:41 AM Robin Murphy wrote:
>
> On 2021-01-25 21:51, Jordan Crouse wrote:
> > On Fri, Jan 22, 2021 at 12:53:17PM +, Robin Murphy wrote:
> >> On 2021-01-22 12:41, Will Deacon wrote:
> >>> On Tue, Nov 24, 2020 at 12:15:58PM -0700, Jordan Crouse wrote:
> Call
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
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
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
> 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("Rob
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!
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 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
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:
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
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, 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
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 parameter or
member
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
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 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
1 - 100 of 1414 matches
Mail list logo
