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 dp
On Fri, Apr 23, 2021 at 4:58 AM Otavio Salvador
wrote:
>
> Hello all,
>
> We found this error when using Freedreno driver on an i.MX53 device
> with Wayland. Any idea how to fix this?
>
> [ 32.414110] [drm:msm_ioctl_gem_submit] *ERROR* invalid cmdstream size: 0
The invalid cmdstream size is som
From: Rob Clark
Our initial logic for excluding dma-bufs was not quite right. In
particular we want msm_gem_get/put_pages() path used for exported
dma-bufs to increment/decrement the pin-count.
Also, in case the importer is vmap'ing the dma-buf, we need to be
sure to update the object
From: Rob Clark
With some recent userspace work to allow more rendering to be merged
into a single SUBMIT ioctl, I realized we have some sharp edges around
running out of free ringbuffer space.
1) Currently we only flush once all the cmds (or rather IBs to the cmd
buffer) are written into
From: Rob Clark
Currently if userspace manages to fill up the ring faster than the GPU
can consume we (a) spin for up to 1sec, and then (b) overwrite the
ringbuffer contents from previous submits that the GPU is still busy
executing. Which predictably goes rather badly.
Instead, just skip
From: Rob Clark
On a5xx and a6xx devices that are using CP_WHERE_AM_I to update a
ringbuffer read-ptr shadow value, periodically emit a CP_WHERE_AM_I
every 32 commands, so that a later submit waiting for ringbuffer
space to become available sees partial progress, rather than not
seeing rptr
On Thu, Apr 8, 2021 at 6:20 AM Maxime Ripard wrote:
>
> Hi Stephen,
>
> On Tue, Mar 30, 2021 at 11:56:15AM -0700, Stephen Boyd wrote:
> > Quoting Maxime Ripard (2021-03-30 08:35:27)
> > > Hi Stephen,
> > >
> > > On Mon, Mar 29, 2021 at 06:52:01PM -0700, Stephen Boyd wrote:
> > > > Trimming Cc list
From: Rob Clark
dpu_crtc_atomic_flush() was directly poking it's attached planes in a
code path that ended up in dpu_plane_atomic_update(), even if the plane
was not involved in the current atomic update. While a bit dubious,
this worked before because plane->state would always
not skip to error paths after
> that. Other drivers do this the same for out-fence and similar things.
>
> Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler")
> Cc: Rob Clark
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Sumit Semwal
> Cc: "Christi
On Fri, Aug 6, 2021 at 9:42 AM Daniel Vetter wrote:
>
> On Fri, Aug 6, 2021 at 12:58 AM Rob Clark wrote:
> >
> > On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter wrote:
> > >
> > > Originally drm_sched_job_init was the point of no return, after which
> > &g
On Fri, Aug 6, 2021 at 11:41 AM Daniel Vetter wrote:
>
> On Fri, Aug 6, 2021 at 7:15 PM Rob Clark wrote:
> >
> > On Fri, Aug 6, 2021 at 9:42 AM Daniel Vetter wrote:
> > >
> > > On Fri, Aug 6, 2021 at 12:58 AM Rob Clark wrote:
> > > >
>
On Fri, Aug 6, 2021 at 12:11 PM Daniel Vetter wrote:
>
> On Fri, Aug 6, 2021 at 8:57 PM Rob Clark wrote:
> >
> > On Fri, Aug 6, 2021 at 11:41 AM Daniel Vetter
> > wrote:
> > >
> > > On Fri, Aug 6, 2021 at 7:15 PM Rob Clark wrote:
> > > >
From: Rob Clark
Combine adreno_is_a640() and adreno_is_a680().
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 5 ++---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 15 +++
drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 2 +-
drivers/gpu/drm/msm/adreno
From: Rob Clark
This check is really about which SQE firmware, rather than which GPU.
Rework to match minimum version based on firmware name, so it doesn't
need to be updated when adding additional GPUs using the same fw.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.
On Tue, Aug 3, 2021 at 2:37 AM Dmitry Baryshkov
wrote:
>
> On 03/08/2021 12:06, Thomas Zimmermann wrote:
> > Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
> > IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
> > don't benefit from using it.
> >
> > DRM IRQ call
On Tue, Jul 6, 2021 at 1:47 AM Thomas Zimmermann wrote:
>
> Moving the driver-specific mmap code into a GEM object function allows
> for using DRM helpers for various mmap callbacks.
>
> The respective msm functions are being removed. The file_operations
> structure fops is now being created by th
From: Rob Clark
Based on discussion from a previous series[1] to add a "boost" mechanism
when, for example, vblank deadlines are missed. Instead of a boost
callback, this approach adds a way to set a deadline on the fence, by
which the waiter would like to see the fence signalled.
I&
From: Rob Clark
Add a way to hint to the fence signaler of an upcoming deadline, such as
vblank, which the fence waiter would prefer not to miss. This is to aid
the fence signaler in making power management decisions, like boosting
frequency as the deadline approaches and awareness of missing
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_vblank.c | 31 +++
include/drm/drm_vblank.h | 1 +
2 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 3417e1ac7918..88c824c294dc
From: Rob Clark
For an atomic commit updating a single CRTC (ie. a pageflip) calculate
the next vblank time, and inform the fence(s) of that deadline.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_atomic_helper.c | 36 +
1 file changed, 36 insertions(+)
diff
From: Rob Clark
As the finished fence is the one that is exposed to userspace, and
therefore the one that other operations, like atomic update, would
block on, we need to propagate the deadline from from the finished
fence to the actual hw fence.
Signed-off-by: Rob Clark
---
drivers/gpu/drm
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_fence.c | 76 +++
drivers/gpu/drm/msm/msm_fence.h | 20 +++
drivers/gpu/drm/msm/msm_gpu.h | 1 +
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 20 +++
4 files changed, 117
On Sat, Aug 7, 2021 at 11:40 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 07.08.21 um 19:08 schrieb Rob Clark:
> > On Tue, Aug 3, 2021 at 2:37 AM Dmitry Baryshkov
> > wrote:
> >>
> >> On 03/08/2021 12:06, Thomas Zimmermann wrote:
> >>> Drop
On Sat, Aug 7, 2021 at 12:21 PM Caleb Connolly
wrote:
>
> Hi Rob, Akhil,
>
> On 29/07/2021 21:53, Rob Clark wrote:
> > On Thu, Jul 29, 2021 at 1:28 PM Caleb Connolly
> > wrote:
> >>
> >>
> >>
> >> On 29/07/2021 21:24, Rob Clark
On Sun, Aug 8, 2021 at 7:33 AM Caleb Connolly wrote:
>
>
>
> On 07/08/2021 21:04, Rob Clark wrote:
> > On Sat, Aug 7, 2021 at 12:21 PM Caleb Connolly
> > wrote:
> >>
> >> Hi Rob, Akhil,
> >>
> >> On 29/07/2021 21:53, Rob Clark
On Mon, Aug 9, 2021 at 7:52 AM Akhil P Oommen wrote:
>
> On 8/8/2021 10:22 PM, Rob Clark wrote:
> > On Sun, Aug 8, 2021 at 7:33 AM Caleb Connolly
> > wrote:
> >>
> >>
> >>
> >> On 07/08/2021 21:04, Rob Clark wrote:
> >&g
On Mon, Aug 9, 2021 at 7:56 AM Will Deacon wrote:
>
> On Mon, Aug 02, 2021 at 06:36:04PM -0700, Rob Clark wrote:
> > On Mon, Aug 2, 2021 at 8:14 AM Will Deacon wrote:
> > >
> > > On Mon, Aug 02, 2021 at 08:08:07AM -0700, Rob Clark wrote:
> > > > On Mon,
On Mon, Aug 9, 2021 at 10:05 AM Will Deacon wrote:
>
> On Mon, Aug 09, 2021 at 09:57:08AM -0700, Rob Clark wrote:
> > On Mon, Aug 9, 2021 at 7:56 AM Will Deacon wrote:
> > > On Mon, Aug 02, 2021 at 06:36:04PM -0700, Rob Clark wrote:
> > > > On Mon, Aug 2, 2
On Mon, Aug 9, 2021 at 10:28 AM Akhil P Oommen wrote:
>
> On 8/9/2021 9:48 PM, Caleb Connolly wrote:
> >
> >
> > On 09/08/2021 17:12, Rob Clark wrote:
> >> On Mon, Aug 9, 2021 at 7:52 AM Akhil P Oommen
> >> wrote:
> >>>
> >>> On 8
On Mon, Aug 9, 2021 at 10:47 AM Sai Prakash Ranjan
wrote:
>
> On 2021-08-09 23:10, Will Deacon wrote:
> > On Mon, Aug 09, 2021 at 10:18:21AM -0700, Rob Clark wrote:
> >> On Mon, Aug 9, 2021 at 10:05 AM Will Deacon wrote:
> >> >
> >> > On Mon, Aug
On Mon, Aug 9, 2021 at 11:11 AM Sai Prakash Ranjan
wrote:
>
> On 2021-08-09 23:37, Rob Clark wrote:
> > On Mon, Aug 9, 2021 at 10:47 AM Sai Prakash Ranjan
> > wrote:
> >>
> >> On 2021-08-09 23:10, Will Deacon wrote:
> >> > On Mon, Aug 09, 2021 at 1
On Mon, Aug 9, 2021 at 1:35 PM Caleb Connolly wrote:
>
>
>
> On 09/08/2021 18:58, Rob Clark wrote:
> > On Mon, Aug 9, 2021 at 10:28 AM Akhil P Oommen
> > wrote:
> >>
> >> On 8/9/2021 9:48 PM, Caleb Connolly wrote:
> >>>
> >>>
On Wed, Aug 11, 2021 at 5:15 AM Laurent Pinchart
wrote:
>
> Hi Stephen,
>
> On Tue, Aug 10, 2021 at 10:26:33PM -0700, Stephen Boyd wrote:
> > Quoting Laurent Pinchart (2021-06-23 17:03:02)
> > > To simplify interfacing with the panel, wrap it in a panel-bridge and
> > > let the DRM bridge helpers
On Wed, Aug 11, 2021 at 1:39 PM Stephen Boyd wrote:
>
> Quoting Rob Clark (2021-08-11 09:20:30)
> > On Wed, Aug 11, 2021 at 5:15 AM Laurent Pinchart
> > wrote:
> > >
> > > Hi Stephen,
> > >
> > > On Tue, Aug 10, 2021 at 10:26:33PM -0700, Step
From: Rob Clark
The first patch fixes breakage in drm-next for the ti eDP bridge (which
is used on nearly all the snapdragon windows laptops and chromebooks).
The second add drm/msm NO_CONNECTOR support, and the final two add
NO_CONNECTOR support to the ti eDP bridge.
Would be nice to get at
From: Rob Clark
If we created our own connector because the driver does not support the
NO_CONNECTOR flag, we don't want the downstream bridge to *also* create
a connector. And if this driver did pass the NO_CONNECTOR flag (and we
supported that mode) this would change nothing.
From: Rob Clark
For now, since we have a mix of bridges which support this flag, which
which do *not* support this flag, or work both ways, try it once with
NO_CONNECTOR and then fall back to the old way if that doesn't work.
Eventually we can drop the fallback path.
Signed-off-by: Rob
From: Rob Clark
For the brave new world of bridges not creating their own connectors, we
need to implement the max clock limitation via bridge->mode_valid()
instead of connector->mode_valid().
Signed-off-by: Rob Clark
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 24 +++--
From: Rob Clark
Slightly awkward to fish out the display_info when we aren't creating
own connector. But I don't see an obvious better way.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 34 +++
1 file changed, 29 insertions(+), 5
dsi phy
drm/msm/dsi: Add PHY configuration for SC7280
drm/msm/dsi: Add DSI support for SC7280
Rob Clark (3):
drm/msm: Periodically update RPTR shadow
drm/msm: Add adreno_is_a640_family()
drm/msm: Rework SQE version check
Souptick Joarder (1):
drm/msm/dp: Remove unus
On Thu, Aug 12, 2021 at 9:55 AM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Aug 11, 2021 at 4:51 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > If we created our own connector because the driver does not support the
> > NO_CONNECTOR flag, we don
On Thu, Aug 12, 2021 at 10:31 AM Sam Ravnborg wrote:
>
> Hi Rob,
>
> On Wed, Aug 11, 2021 at 04:52:48PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > For now, since we have a mix of bridges which support this flag, which
> > which do *not* support this
On Thu, Aug 12, 2021 at 11:44 AM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Wed, Aug 11, 2021 at 04:52:49PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > For the brave new world of bridges not creating their own connecto
On Mon, Aug 16, 2021 at 8:38 AM Daniel Vetter wrote:
>
> On Mon, Aug 16, 2021 at 12:14:35PM +0200, Christian König wrote:
> > Am 07.08.21 um 20:37 schrieb Rob Clark:
> > > From: Rob Clark
> > >
> > > As the finished fence is the one that is exposed to user
wrote:
>
> The general approach seems to make sense now I think.
>
> One minor thing which I'm missing is adding support for this to the
> dma_fence_array and dma_fence_chain containers.
>
> Regards,
> Christian.
>
> Am 07.08.21 um 20:37 schrieb Rob Clark:
&g
rm_sched_job doesn't escape anywhere at all.
>
> For robustness it's still better to align with other drivers here and
> not bail out after job_arm().
>
> v3: I misplaced drm_sched_job_arm by _one_ line! Thanks to Rob for
> testing and debug help.
>
> Cc: Rob Clark
> C
On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter wrote:
>
> drm_sched_job_init is already at the right place, so this boils down
> to deleting code.
>
> Signed-off-by: Daniel Vetter
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Sumit Semwal
> Cc: "Christian König"
t seem to care much,
> - and it probably makes sense to lift this into dma-resv.c code as a
> proper concept, so that drivers don't have to hack up their own
> solution each on their own.
>
> v2: Improve commit message per Lucas' suggestion.
>
> Cc: Lucas Stach
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 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 Mon, Mar 1, 2021 at 1:41 PM Dmitry Baryshkov
wrote:
>
> if GPU components have failed to bind, shutdown callback would fail with
> the following backtrace. Add safeguard check to stop that oops from
> happening and allow the board to reboot.
>
> [ 66.617046] Unable to handle kernel NULL point
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-o
ave used the "white lie" approach. One representative 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
> >
On Fri, Mar 19, 2021 at 5:09 AM Fabio Estevam wrote:
>
> Hi Dmitry,
>
> On Mon, Mar 1, 2021 at 6:41 PM Dmitry Baryshkov
> wrote:
>
> > diff --git a/drivers/gpu/drm/msm/msm_atomic.c
> > b/drivers/gpu/drm/msm/msm_atomic.c
> > index 6a326761dc4a..2fd0cf6421ad 100644
> > --- a/drivers/gpu/drm/msm/ms
On Fri, Mar 19, 2021 at 8:13 AM Fabio Estevam wrote:
>
> Hi Rob,
>
> On Fri, Mar 19, 2021 at 11:44 AM Rob Clark wrote:
>
> > I think that might not help if something fails to probe due to (for
> > example) a missing dependency, so !priv->kms is probably a better
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 change
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 for
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/gp
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
be
On Wed, Mar 24, 2021 at 6:49 PM Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2021-03-18 13:05:44)
> > if GPU components have failed to bind, shutdown callback would fail with
> > the following backtrace. Add safeguard check to stop that oops from
> > happening and allow the board to reboot.
>
On Wed, Mar 17, 2021 at 2:33 AM Sai Prakash Ranjan
wrote:
>
> Hi Rob,
>
> On 2021-03-16 22:46, Rob Clark wrote:
>
> ...
>
> >> > >
> >> > > When the GPU has a buffer mapped with IOMMU_LLC, is the buffer also
> >> > > mapped
>
drm/msm/disp/dpu1: icc path needs to be set before dpu runtime resume
Konrad Dybcio (1):
drm/msm/adreno: a5xx_power: Don't apply A540 lm_setup to other GPUs
Rob Clark (1):
drm/msm: Ratelimit invalid-fence message
Stephen Boyd (2):
drm/msm/kms: Use nested locking for crt
lyan Thota (1):
drm/msm/disp/dpu1: icc path needs to be set before dpu runtime resume
Konrad Dybcio (1):
drm/msm/adreno: a5xx_power: Don't apply A540 lm_setup to other GPUs
Rob Clark (1):
drm/msm: Ratelimit invalid-fence message
Stephen Boyd (2):
drm/msm/kms: U
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:
> >
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 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 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 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 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 s
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 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
fixing Jordan's email so he actually sees this
On Wed, Mar 31, 2021 at 7:02 AM Dmitry Baryshkov
wrote:
>
> I suppose the microcode version check for a650 is incorrect. It checks
> for the version 1.95, while the firmware released have major version of 0:
> 0.91 (vulnerable), 0.99 (fixing the issu
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
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
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
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
--- a
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 runti
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(&priv->mm_lock);
>
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 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
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
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
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
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
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-by
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(msm_ob
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 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:
> > >>
> > >>
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 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")
> Sig
v (1):
drm/msm: a6xx: fix version check for the A650 SQE microcode
John Stultz (1):
drm/msm: Fix removal of valid error case when checking speed_bin
Kalyan Thota (1):
drm/msm/disp/dpu1: program 3d_merge only if block is attached
Rob Clark (1):
drm/msm: Fix a5xx/a6xx timest
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
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
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 ++--
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 dele
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
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 p
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 inse
101 - 200 of 6553 matches
Mail list logo
