On Thu, Mar 3, 2022 at 12:47 PM Stephen Boyd wrote:
>
> Quoting Rob Clark (2022-03-03 11:46:47)
> > diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> > index fde9a29f884e..0ba1dbd4e50f 100644
> > --- a/drivers/gpu/drm/msm/msm_gpu.h
>
On Thu, Mar 3, 2022 at 12:42 PM Abhinav Kumar wrote:
>
> Hi Rob
>
> On 3/3/2022 11:46 AM, Rob Clark wrote:
> > From: Rob Clark
> >
> > Update headers from mesa commit:
> >
> >commit 7e63fa2bb13cf14b765ad06d046789ee1879b5ef
> >Author:
From: Rob Clark
Any app controlled perfcntr collection (GL_AMD_performance_monitor, etc)
does not require counters to maintain state across context switches. So
clear them if systemwide profiling is not active.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 29
From: Rob Clark
Add a SYSPROF param for system profiling tools like Mesa's pps-producer
(perfetto) to control behavior related to system-wide performance
counter collection. In particular, for profiling, one wants to ensure
that GPU context switches do not effect perfcounter state, and might
From: Rob Clark
It was always expected to have a use for this some day, so we left a
placeholder. Now we do. (And I expect another use in the not too
distant future when we start allowing userspace to allocate GPU iova.)
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx_gpu.c
From: Rob Clark
Some clever folks figured out a way to use performance counters as a
side-channel[1]. But, other than the special case of using the perf
counters for system profiling, we can reset the counters across context
switches to protect against this.
This series introduces a SYSPROF
Should be fixed by:
https://patchwork.freedesktop.org/patch/475238/?series=100448=1
t-b's welcome
On Wed, Mar 2, 2022 at 12:35 PM Naresh Kamboju
wrote:
>
> [Please ignore this email if it is already reported]
>
> Linux next-20220302 running on Qcom db410c the following kernel crash
> reported
m/dsi: Add dsi phy tuning configuration support
drm/msm/dsi: Add 10nm dsi phy tuning configuration support
Rob Clark (5):
drm/msm/rd: Add chip-id
drm/msm/dpu: Add SC8180x to hw catalog
drm/msm/gpu: Add ctx to get_param()
drm/msm/gpu: Track global faults per address-space
On Mon, Feb 28, 2022 at 10:49 PM David Laight wrote:
>
> From: Abhinav Kumar
> > Sent: 28 February 2022 21:38
> ...
> > We also did some profiling around how much increasing the block size
> > helps and here is the data:
> >
> > Block sizecost
> >
> > 4KB 229s
> > 8KB86s
On Mon, Feb 28, 2022 at 6:33 AM Tvrtko Ursulin
wrote:
>
>
> On 25/02/2022 22:14, Rob Clark wrote:
> > On Fri, Feb 25, 2022 at 12:25 PM Rob Clark wrote:
> >>
> >> From: Rob Clark
> >>
> >> Similar to AMD commit
> >> 874
On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:
>
> On Wed, 02 Feb 2022, Laurent Pinchart
> wrote:
> > Hi Jani,
> >
> > On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> >> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> >> > On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj
On Fri, Feb 25, 2022 at 12:25 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Similar to AMD commit
> 874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
> infrastructure added in previous patches, we add basic client info
> and GPU engine utilisat
On Fri, Feb 25, 2022 at 12:36 PM Ville Syrjälä
wrote:
>
> On Fri, Feb 25, 2022 at 12:26:12PM -0800, Rob Clark wrote:
> > From: Rob Clark
> >
> > Extend the helper macro so we don't have to throw it away if driver adds
> > support for optional fops, like show_fdinfo
From: Rob Clark
Noticed this was unused and never set.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h | 1 -
drivers/gpu/drm/msm/msm_gpu.h | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index
From: Rob Clark
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for msm.
Example output:
# cat /proc/`pgrep glmark2`/fdinfo/6
From: Rob Clark
Extend the helper macro so we don't have to throw it away if driver adds
support for optional fops, like show_fdinfo().
Signed-off-by: Rob Clark
---
include/drm/drm_gem.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_gem.h b/include/drm
From: Rob Clark
Add a way for userspace to specify the sequence number fence used to
track completion of the submit. As the seqno fence is simply an
incrementing counter which is local to the submitqueue, it is easy for
userspace to know the next value.
This is useful for native userspace
From: Rob Clark
Someone on IRC once asked an innocent enough sounding question: Why
with xf86-video-modesetting is es2gears limited at 120fps.
So I broke out the perfetto tracing mesa MR and took a look. It turns
out the problem was drm_atomic_helper_dirtyfb(), which would end up
waiting
On Wed, Feb 23, 2022 at 2:00 AM Dmitry Baryshkov
wrote:
>
> On 19/02/2022 22:39, Rob Clark wrote:
> > From: Rob Clark
> >
> > Someone on IRC once asked an innocent enough sounding question: Why
> > with xf86-video-modesetting is es2gears limited at 120fps.
>
On Tue, Feb 22, 2022 at 7:11 PM Dmitry Baryshkov
wrote:
>
> On 19/02/2022 21:33, Rob Clark wrote:
> > From: Rob Clark
> >
> > Avoid going down devfreq paths on devices where devfreq is not
> > initialized.
> >
> > Reported-by: Linux Kernel Function
On Mon, Feb 21, 2022 at 6:41 AM Akhil P Oommen wrote:
>
> This series supercedes [1]. Major change in this series is that it is now
> optional to include a gpu name in the gpu-list. This helps to avoid the
> confusion when we have different SKUs with different gpu names. And also
> I am pretty
On Mon, Feb 21, 2022 at 6:41 AM Akhil P Oommen wrote:
>
> Use a gpu name which is sprintf'ed from the chipid for 7c3 gpu instead of
> hardcoding one. This helps to avoid code churn in case of a gpu rename.
>
> Signed-off-by: Akhil P Oommen
> ---
>
> drivers/gpu/drm/msm/adreno/adreno_device.c |
On Mon, Feb 21, 2022 at 5:23 PM Konrad Dybcio
wrote:
>
> Add support for the Adreno 619 GPU, as found in Snapdragon 690 (SM6350),
> 480 (SM4350) and 750G (SM7225).
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 11 ++--
>
From: Rob Clark
Someone on IRC once asked an innocent enough sounding question: Why
with xf86-video-modesetting is es2gears limited at 120fps.
So I broke out the perfetto tracing mesa MR and took a look. It turns
out the problem was drm_atomic_helper_dirtyfb(), which would end up
waiting
On Sat, Feb 19, 2022 at 10:32 AM Rob Clark wrote:
>
> From: Rob Clark
>
> Avoid going down devfreq paths on devices where devfreq is not
> initialized.
>
> Reported-by: Linux Kernel Functional Testing
> Reported-by: Anders Roxell
forgot to add:
Fixes: 6aa89ae1fb04 (&
From: Rob Clark
Avoid going down devfreq paths on devices where devfreq is not
initialized.
Reported-by: Linux Kernel Functional Testing
Reported-by: Anders Roxell
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 31 +--
1 file changed, 25
From: Rob Clark
With native userspace drivers in guest, a lot of GEM objects need to be
neither shared nor mappable. And in fact making everything mappable
and/or sharable results in unreasonably high fd usage in host VMM.
Signed-off-by: Rob Clark
---
This is for a thing I'm working on, a new
On Fri, Feb 18, 2022 at 8:42 AM Chia-I Wu wrote:
>
> On Fri, Feb 18, 2022 at 7:57 AM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > With native userspace drivers in guest, a lot of GEM objects need to be
> > neither shared nor mappable. An
From: Rob Clark
With native userspace drivers in guest, a lot of GEM objects need to be
neither shared nor mappable. And in fact making everything mappable
and/or sharable results in unreasonably high fd usage in host VMM.
Signed-off-by: Rob Clark
---
This is for a thing I'm working on, a new
From: Rob Clark
The UABI was already defined for pointer to 64b value, and all the
userspace users of this ioctl that I could find are already using a
uint64_t (but zeroing it out to work around kernel only copying 32b).
Unfortunately this ioctl doesn't have a length field, so out of paranoia
I
From: Rob Clark
Other processes don't need to know about faults that they are isolated
from by virtue of address space isolation. They are only interested in
whether some of their state might have been corrupted.
But to be safe, also track unattributed faults. This case should really
never
From: Rob Clark
Prep work for next patch.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 ++-
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 ++-
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
drivers/gpu/drm/msm/msm_gpu.h | 3 ++-
drivers/gpu/drm/msm
From: Rob Clark
Currently, for GL_EXT_robustness userspace uses the global and per-
submitqueue fault counters to determine GUILTY_CONTEXT_RESET_EXT vs
INNOCENT_CONTEXT_RESET_EXT. But that is a bit overly paranoid, in
that a fault in a different process's context (when it has it's own
isolated
From: Rob Clark
Add a param so that userspace can query the fault count for faults that
might effect them (ie. any context sharing the same address space).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 +++
drivers/gpu/drm/msm/msm_drv.c | 1 +
drivers/gpu
From: Rob Clark
Prep work for next patch.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 ++-
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 ++-
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
drivers/gpu/drm/msm/msm_gpu.h | 3 ++-
drivers/gpu/drm/msm
From: Rob Clark
Currently, for GL_EXT_robustness userspace uses the global and per-
submitqueue fault counters to determine GUILTY_CONTEXT_RESET_EXT vs
INNOCENT_CONTEXT_RESET_EXT. But that is a bit overly paranoid, in
that a fault in a different process's context (when it has it's own
isolated
heck in dpu_setup_dspp_pcc
drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable
Miaoqian Lin (2):
drm/msm/dsi: Fix missing put_device() call in dsi_get_phy
drm/msm/hdmi: Fix missing put_device() call in msm_hdmi_get_phy
Rob Clark (3):
drm/msm/a6xx: Add missing suspend_c
On Wed, Jan 19, 2022 at 7:09 AM Daniel Vetter wrote:
>
> On Thu, Jan 06, 2022 at 04:55:35PM +, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Proposal to standardise the fdinfo text format as optionally output by DRM
> > drivers.
> >
> > Idea is that a simple but, well defined, spec
On Mon, Jan 17, 2022 at 6:38 AM Akhil P Oommen wrote:
>
> On 1/13/2022 12:43 PM, Dmitry Baryshkov wrote:
> > On Thu, 13 Jan 2022 at 00:19, Rob Clark wrote:
> >> On Tue, Jan 11, 2022 at 1:31 PM Akhil P Oommen
> >> wrote:
> >>> Expose speedbin t
From: Rob Clark
For newer devices which deprecate gpu-id and do matching based on
chip-id, we need this information in cmdstream dumps so that the
decoding tools know how to decode them.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_rd.c | 4
1 file changed, 4 insertions(+)
diff
From: Rob Clark
Reported-by: Danylo Piliaiev
Fixes: 3ab1c5cc3939 ("drm/msm: Add param for userspace to query suspend count")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6x
On Tue, Jan 11, 2022 at 1:31 PM Akhil P Oommen wrote:
>
> Expose speedbin through MSM_PARAM_CHIP_ID parameter to help userspace
> identify the sku.
>
> Signed-off-by: Akhil P Oommen
> ---
>
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 9 +
> 1 file changed, 5 insertions(+), 4
On Tue, Jan 11, 2022 at 1:31 PM Akhil P Oommen wrote:
>
> Add support for "Adreno 8c Gen 3" gpu along with the necessary speedbin
> support.
>
> Signed-off-by: Akhil P Oommen
> ---
>
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 21 +
>
From: Rob Clark
With system suspend using pm_runtime_force_suspend() we can't rely on
the pm_runtime_get_if_in_use() trick to deal with devfreq callbacks
after (or racing with) suspend. So flush any pending idle or boost
work in the suspend path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm
From: Rob Clark
System suspend uses pm_runtime_force_suspend(), which cheekily bypasses
the runpm reference counts. This doesn't actually work so well when the
GPU is active. So add a reasonable delay waiting for the GPU to become
idle.
Alternatively we could just return -EBUSY in this case
From: Rob Clark
Because system suspend uses pm_runtime_force_suspend() we can't rely
runpm refcnt's to protect us if the GPU is active, etc. Fortunately
*usually* the GPU is idle when system suspend is triggered. But that
isn't quite good enough.
The first patch attempts to block for a modest
From: Rob Clark
With system suspend using pm_runtime_force_suspend() we can't rely on
the pm_runtime_get_if_in_use() trick to deal with devfreq callbacks
after (or racing with) suspend. So flush any pending idle or boost
work in the suspend path.
v2: s/ret/remaining [sboyd], and switch
From: Rob Clark
System suspend uses pm_runtime_force_suspend(), which cheekily bypasses
the runpm reference counts. This doesn't actually work so well when the
GPU is active. So add a reasonable delay waiting for the GPU to become
idle.
Alternatively we could just return -EBUSY in this case
From: Rob Clark
Because system suspend uses pm_runtime_force_suspend() we can't rely
runpm refcnt's to protect us if the GPU is active, etc. Fortunately
*usually* the GPU is idle when system suspend is triggered. But that
isn't quite good enough.
The first patch attempts to block for a modest
On Fri, Jan 7, 2022 at 4:27 PM Stephen Boyd wrote:
>
> Quoting Rob Clark (2022-01-06 10:14:46)
> > From: Rob Clark
> >
> > System suspend uses pm_runtime_force_suspend(), which cheekily bypasses
> > the runpm reference counts. This doesn't actually work so well w
From: Rob Clark
With system suspend using pm_runtime_force_suspend() we can't rely on
the pm_runtime_get_if_in_use() trick to deal with devfreq callbacks
after (or racing with) suspend. So flush any pending idle or boost
work in the suspend path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm
From: Rob Clark
System suspend uses pm_runtime_force_suspend(), which cheekily bypasses
the runpm reference counts. This doesn't actually work so well when the
GPU is active. So add a reasonable delay waiting for the GPU to become
idle.
Alternatively we could just return -EBUSY in this case
From: Rob Clark
Because system suspend uses pm_runtime_force_suspend() we can't rely
runpm refcnt's to protect us if the GPU is active, etc. Fortunately
*usually* the GPU is idle when system suspend is triggered. But that
isn't quite good enough.
The first patch attempts to block for a modest
p_clockmatrix: repair non-kernel-doc comment
net: ethernet: lantiq_etop: fix build errors/warnings
mips: bcm63xx: add support for clk_get_parent()
mips: lantiq: add support for clk_get_parent()
gpio: rockchip: needs GENERIC_IRQ_CHIP to fix build errors
riscv: kvm: fix no
On Wed, Dec 15, 2021 at 8:45 AM Dmitry Baryshkov
wrote:
>
> Hi,
>
> On 09/12/2021 00:23, Rob Clark wrote:
> > On Wed, Dec 8, 2021 at 10:01 AM Dmitry Baryshkov
> > wrote:
> >>
> >> msm_ioremap() functions take additional argument dbgname used to outp
On Wed, Dec 15, 2021 at 11:17 AM Dmitry Baryshkov
wrote:
>
> On Wed, 15 Dec 2021 at 20:49, Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > Add UTS_RELEASE and show timestamp the same way for consistency.
> >
> > Signed-off-by: Ro
On Wed, Dec 15, 2021 at 11:10 AM Stephen Boyd wrote:
>
> Quoting Rob Clark (2021-12-15 09:59:02)
> > From: Rob Clark
> >
> > No functional change, as we only actually enable autosuspend for the GPU
> > device. But lets not encourage thinking that autosuspend i
From: Rob Clark
No functional change, as we only actually enable autosuspend for the GPU
device. But lets not encourage thinking that autosuspend is a good idea
for anything display related.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 8
drivers/gpu/drm/msm
From: Rob Clark
Signed-off-by: Rob Clark
---
v2: Drop unneeded msm_kms_show_priv [Dmitry B]
drivers/gpu/drm/msm/msm_debugfs.c | 75 +++
1 file changed, 75 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_debugfs.c
b/drivers/gpu/drm/msm/msm_debugfs.c
index
From: Rob Clark
We'll re-use this for debugfs.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/msm_disp_snapshot.c | 28 +++-
drivers/gpu/drm/msm/disp/msm_disp_snapshot.h | 10 +++
2 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm
From: Rob Clark
Add UTS_RELEASE and show timestamp the same way for consistency.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/msm_disp_snapshot.h | 4 ++--
drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c | 9 ++---
2 files changed, 8 insertions(+), 5 deletions(-)
diff
From: Rob Clark
This series adds a "kms" debugfs file to dump display register + atomic
state, which is useful for debugging issues that don't trigger a display
error irq (such as dsi phy misconfiguration).
Rob Clark (3):
drm/msm/disp: Tweak display snapshot to match gpu snapshot
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_debugfs.c | 90 +++
1 file changed, 90 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_debugfs.c
b/drivers/gpu/drm/msm/msm_debugfs.c
index 956b1efc3721..088f1160c892 100644
--- a/drivers/gpu
From: Rob Clark
We'll re-use this for debugfs.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/msm_disp_snapshot.c | 28 +++-
drivers/gpu/drm/msm/disp/msm_disp_snapshot.h | 10 +++
2 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm
From: Rob Clark
Add UTS_RELEASE and show timestamp the same way for consistency.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/msm_disp_snapshot.h | 4 ++--
drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c | 9 ++---
2 files changed, 8 insertions(+), 5 deletions(-)
diff
From: Rob Clark
This series adds a "kms" debugfs file to dump display register + atomic
state, which is useful for debugging issues that don't trigger a display
error irq (such as dsi phy misconfiguration).
Rob Clark (3):
drm/msm/disp: Tweak display snapshot to match gpu snapshot
From: Rob Clark
I am seeing some crash logs which imply that we are trying to use
crashdumper hw to read back GPU state when the GPU isn't initialized.
This doesn't go well (for example, GPU could be in 32b address mode
and ignoring the upper bits of buffer that it is trying to dump state
On Thu, Nov 4, 2021 at 8:05 PM Sean Paul wrote:
>
> From: Sean Paul
>
> This patch adds the register ranges required for HDCP key injection and
> HDCP TrustZone interaction as described in the dt-bindings for the
> sc7180 dp controller. Now that these are supported, change the
> compatible
On Wed, Dec 8, 2021 at 10:01 AM Dmitry Baryshkov
wrote:
>
> msm_ioremap() functions take additional argument dbgname used to output
> single debug line telling IO range. Drop that extra argument, use
> resource name instead.
For some history, the dbgname traces were used by an older tool that
On Thu, Nov 4, 2021 at 8:04 PM Sean Paul wrote:
>
> From: Sean Paul
>
> Just me with another revision of HDCP support for msm.
>
> This v4 patch series is mostly a retread of v3 with the following
> changes:
> - rebased on Bjorn's displayport-controller register refactor
> - another change to
From: Rob Clark
Otherwise we don't get another shot at it if the bridge probes before
the dsi host is registered. It seems like this is what *most* (but not
all) of the other bridges do.
It looks like this was missed in the conversion to attach dsi host at
probe time.
Fixes: c3b75d4734cb
From: Rob Clark
Otherwise we don't get another shot at it if the bridge probes before
the dsi host is registered. It seems like this is what *most* (but not
all) of the other bridges do.
It looks like this was missed in the conversion to attach dsi host at
probe time.
Fixes: c3b75d4734cb
From: Rob Clark
Otherwise we don't get another shot at it if the bridge probes before
the dsi host is registered. It seems like this is what *most* (but not
all) of the other bridges do.
It looks like this was missed in the conversion to attach dsi host at
probe time.
Fixes: c3b75d4734cb
On Mon, Nov 29, 2021 at 10:18 AM Rob Clark wrote:
>
> From: Rob Clark
>
> Elsewhere we treat zero as "no fence" and __msm_gem_submit_destroy()
> skips removal from fence_idr. We could alternately change this to use
> negative values for "no fence" but
From: Rob Clark
Elsewhere we treat zero as "no fence" and __msm_gem_submit_destroy()
skips removal from fence_idr. We could alternately change this to use
negative values for "no fence" but I think it is more clear to not allow
zero as a valid fence_id.
Signed-off-by: Rob
fers that caused crashes
Philip Chen (1):
drm/msm/dsi: set default num_data_lanes
Rob Clark (8):
drm/msm/devfreq: Fix OPP refcnt leak
drm/msm: Fix wait_fence submitqueue leak
drm/msm: Restore error return on invalid fence
drm/msm: Make a6xx_gpu_set_freq() static
drm
On Wed, Nov 24, 2021 at 11:36 PM Dmitry Baryshkov
wrote:
>
> On 28/04/2021 22:36, Rob Clark wrote:
> > 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) overwri
From: Rob Clark
If you don't realize is_a650_family() also encompasses a660 family,
you'd think that the debug buffer is double allocated. Add a comment
to make this more clear.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 3 +++
1 file changed, 3 insertions(+)
diff
From: Rob Clark
It appears to be a GMU fw build option whether it does anything with
debug and log buffers, but if they are all zeros it won't add anything
to the devcore size.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 12
1 file changed, 12
From: Rob Clark
This also includes a history of start index of the last 8 messages on
each queue, since parsing backwards to decode recently sent HFI messages
is hard(ish).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 48 -
drivers/gpu/drm/msm
From: Rob Clark
Turn it into a thing we can use to snapshot other GMU buffers.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 34 +
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
b
From: Rob Clark
We don't expect either of these conditions to ever be true, so let's get
shouty if they are.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm
From: Rob Clark
Re-work the boost and idle clamping to use PM QoS requests instead, so
they get aggreggated with other requests (such as cooling device).
This does have the minor side-effect that devfreq sysfs min_freq/
max_freq files now reflect the boost and idle clamping, as they show
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 71e52b2b2025..e1774ea342b1 100644
From: Rob Clark
Looks like 658f4c829688 ("drm/msm/devfreq: Add 1ms delay before
clamping freq") was badly rebased on top of efb8a170a367 ("drm/msm:
Fix devfreq NULL pointer dereference on a3xx") and ended up with
the NULL check in the wrong place.
Fixes: 658f4c829688 ("
From: Rob Clark
This was supposed to be a relative timer, not absolute.
Fixes: 658f4c829688 ("drm/msm/devfreq: Add 1ms delay before clamping freq")
Signed-off-by: Rob Clark
Reviewed-by: Douglas Anderson
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 +-
1 file changed, 1 inser
From: Akhil P Oommen
Capture gmu log in coredump to enhance debugging.
Signed-off-by: Akhil P Oommen
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 41 +
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno
From: Rob Clark
This adds additional snapshotting for interesting GMU buffers to the
devcore dumps, adds a couple WARN_ON()s, etc. (Plus a bonus comment)
Akhil P Oommen (1):
drm/msm/a6xx: Capture gmu log in devcoredump
Rob Clark (6):
drm/msm/gpu: Name GMU bos
drm/msm/gpu: Add some
On Mon, Nov 22, 2021 at 10:26 AM Rob Clark wrote:
>
> On Thu, Nov 18, 2021 at 2:21 AM Akhil P Oommen wrote:
> >
> > Capture gmu log in coredump to enhance debugging.
> >
> > Signed-off-by: Akhil P Oommen
> > ---
> >
> >
On Thu, Nov 18, 2021 at 2:21 AM Akhil P Oommen wrote:
>
> Capture gmu log in coredump to enhance debugging.
>
> Signed-off-by: Akhil P Oommen
> ---
>
> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 41
> +
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
>
From: Rob Clark
Re-work the boost and idle clamping to use PM QoS requests instead, so
they get aggreggated with other requests (such as cooling device).
This does have the minor side-effect that devfreq sysfs min_freq/
max_freq files now reflect the boost and idle clamping, as they show
From: Rob Clark
Looks like 658f4c829688 ("drm/msm/devfreq: Add 1ms delay before
clamping freq") was badly rebased on top of efb8a170a367 ("drm/msm:
Fix devfreq NULL pointer dereference on a3xx") and ended up with
the NULL check in the wrong place.
Fixes: 658f4c829688 ("
From: Rob Clark
This was supposed to be a relative timer, not absolute.
Fixes: 658f4c829688 ("drm/msm/devfreq: Add 1ms delay before clamping freq")
Signed-off-by: Rob Clark
Reviewed-by: Douglas Anderson
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 +-
1 file changed, 1 inser
On Fri, Nov 19, 2021 at 4:21 PM Doug Anderson wrote:
>
> Hi,
>
> On Fri, Nov 19, 2021 at 2:47 PM Rob Clark wrote:
> >
> > +void msm_devfreq_boost(struct msm_gpu *gpu, unsigned factor)
> > +{
> > + struct msm_gpu_devfreq *df = >devfreq;
> > +
On Fri, Nov 19, 2021 at 2:46 PM Rob Clark wrote:
>
> From: Rob Clark
>
> This was supposed to be a relative timer, not absolute.
>
Fixes: 658f4c829688 ("drm/msm/devfreq: Add 1ms delay before clamping freq")
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm
From: Rob Clark
This was supposed to be a relative timer, not absolute.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
index
From: Rob Clark
Re-work the boost and idle clamping to use PM QoS requests instead, so
they get aggreggated with other requests (such as cooling device).
This does have the minor side-effect that devfreq sysfs min_freq/
max_freq files now reflect the boost and idle clamping, as they show
On Thu, Nov 18, 2021 at 12:53 AM Daniel Vetter wrote:
>
> On Tue, Nov 16, 2021 at 06:31:10PM -0800, Gurchetan Singh wrote:
> > On Tue, Nov 16, 2021 at 7:43 AM Daniel Vetter wrote:
> >
> > > On Mon, Nov 15, 2021 at 07:26:14PM +, Kasireddy, Vivek wrote:
> > > > Hi Daniel, Greg,
> > > >
> > > >
On Fri, Nov 19, 2021 at 1:54 AM Pekka Paalanen wrote:
>
> On Thu, 18 Nov 2021 15:30:38 -0800
> Rob Clark wrote:
>
> > On Thu, Nov 18, 2021 at 2:39 AM Pekka Paalanen wrote:
> > >
> > > On Wed, 17 Nov 2021 14:48:40 -0800
> > > Brian Norris wrote:
On Thu, Nov 18, 2021 at 2:39 AM Pekka Paalanen wrote:
>
> On Wed, 17 Nov 2021 14:48:40 -0800
> Brian Norris wrote:
>
> > A variety of applications have found it useful to listen to
> > user-initiated input events to make decisions within a DRM driver, given
> > that input events are often the
1201 - 1300 of 5720 matches
Mail list logo
