> >>> 1) Expose a dirty (or content_age property)
> >>> 2) Attach a clip-rect blob property.
> >>> 3) Fake a page-flip by ping-ponging two frame-buffers pointing to the
> >>> same
> >>> underlying buffer object.
> >>>
> >>> Are you saying that people are already using 3) and we should keep
> using
On Thu, Apr 5, 2018 at 9:30 AM, Thomas Hellstrom wrote:
> On 04/04/2018 11:56 AM, Daniel Vetter wrote:
>>
>> On Wed, Apr 04, 2018 at 11:10:08AM +0200, Thomas Hellstrom wrote:
>>>
>>> On 04/04/2018 10:43 AM, Daniel Vetter wrote:
On Wed, Apr 04, 2018 at 10:22:21AM +0200, Thomas Hellstrom w
On Thu, Apr 05, 2018 at 04:00:47PM -0600, Jordan Crouse wrote:
> The i915 DRM driver very cleverly used ascii85 encoding for their
> GPU state file. Move the encode functions to a general header file to
> support other drivers that might be interested in the same
> functionality.
In a previous ver
Convert the format of the 'show' debugfs file and the crash
dump to a format resembling YAML. This should be easier to
parse and be more flexible for future changes and expansions.
Signed-off-by: Jordan Crouse
---
Documentation/gpu/drm-msm-crash-dump.txt | 30 ++
dri
Convert the existing GPU show function to use the GPU state to
dump the information rather than reading it directly from the hardware.
This will require an additional step to capture the state before
dumping it for the existing nodes but it will greatly facilitate reusing
the same code for dumping
The i915 DRM driver very cleverly used ascii85 encoding for their
GPU state file. Move the encode functions to a general header file to
support other drivers that might be interested in the same
functionality.
Reviewed-by: Chris Wilson
Signed-off-by: Jordan Crouse
drivers/gpu/drm/i915/i915_gpu_
HLSQ, SP and TP registers are only accessible from a special
aperture and to make matters worse the aperture is blocked from
the CPU on targets that can support secure rendering. Luckily the
GPU hardware has its own purpose built register dumper that can
access the registers from the aperture. Add
Add the infrastructure to capture the state current state of the
GPU and store it in memory. This is useful for storing the state
of a hung GPU so it can be dumped later.
For now grab the same basic ringbuffer information and registers
that are provided by the debugfs 'gpu' node but obviously this
Do a bit of cleanup to prepare for upcoming changes to pass the
hanging task comm and cmdline to the crash dump function.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gpu.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm
This is revision 4 implementing a GPU crash state for drm/msm
(https://patchwork.freedesktop.org/series/36097/). I think its mature enough
to pull out of RFC status and think about merging.
The goal is to store and provide enough information to debug software
and hardware issues on the Adreno har
Add a drm printer suitable for use with the read callback for
devcoredump or any other file operation read() function that
isn't otherwise covered by seq_file.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_print.c | 54 +
include/drm/drm_print.h
Add the contents of each ringbuffer to the GPU state and dump the
data in the crash file encoded with ascii85. To save space only
the used portions of the ringbuffer are dumped.
Signed-off-by: Jordan Crouse
---
Documentation/gpu/drm-msm-crash-dump.txt | 5
drivers/gpu/drm/msm/adreno/adreno
On a hang copy out the contents of the buffer objects attached to the
guilty submission and print them in the crash dump report.
Signed-off-by: Jordan Crouse
---
Documentation/gpu/drm-msm-crash-dump.txt | 7 +
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 54 ++--
d
Capture the GPU state on a GPU hang and store it for later playback
via the devcoredump facility. Only one crash state is stored at a
time on the assumption that the first hang is usually the most
interesting. The existing crash state can be cleared after capturing
it and then a new one will be cap
On Thu, Apr 05, 2018 at 06:13:48PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to get rid of plane->fb/crtc on atomic drivers. Stop
> looking at them.
>
> v2: Catch the plane->crtc case too
>
> Cc: Rob Clark
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedreno@lists.freedeskto
On Thu, Apr 05, 2018 at 06:13:54PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
> them.
>
> v2: Catch a few more cases
>
> Cc: Rob Clark
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedreno@lists.freedesktop.org
> Sig
Again same justification as for drm_gem_fb_prepare_fb().
Definitely needs some testing because Rob doesn't remember why he did
this, and Google/git.fd.o or anything also doesn't shed some light on
it.
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedreno@lis
From: Ville Syrjälä
We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.
v2: Catch a few more cases
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst #v1
---
drivers/gpu/drm/m
From: Ville Syrjälä
We want to get rid of plane->fb/crtc on atomic drivers. Stop
looking at them.
v2: Catch the plane->crtc case too
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst #v1
---
driver
On Thu, Apr 5, 2018 at 3:30 PM, Thomas Hellstrom wrote:
> On 04/04/2018 11:56 AM, Daniel Vetter wrote:
>>
>> On Wed, Apr 04, 2018 at 11:10:08AM +0200, Thomas Hellstrom wrote:
>>>
>>> On 04/04/2018 10:43 AM, Daniel Vetter wrote:
On Wed, Apr 04, 2018 at 10:22:21AM +0200, Thomas Hellstrom w
On 04/04/2018 11:56 AM, Daniel Vetter wrote:
On Wed, Apr 04, 2018 at 11:10:08AM +0200, Thomas Hellstrom wrote:
On 04/04/2018 10:43 AM, Daniel Vetter wrote:
On Wed, Apr 04, 2018 at 10:22:21AM +0200, Thomas Hellstrom wrote:
Hi,
On 04/04/2018 08:58 AM, Daniel Vetter wrote:
On Wed, Apr 4, 2018 a
Hi Sharat,
On 3/23/2018 12:49 PM, Sharat Masetty wrote:
The last level system cache can be partitioned to 32
different slices of which GPU has two slices preallocated.
The "gpu" slice is used for caching GPU buffers and
the "gpuhtw" slice is used for caching the GPU SMMU
pagetables. This patch
22 matches
Mail list logo