This is revision 8 implementing a GPU crash state for drm/msm
(https://patchwork.freedesktop.org/series/36097/). This patchset adds better
documentation and reflects comments from the mailing lists. I know we will
miss 4.19 at this point, but I think this is ready to soak in msm-next for
a while.
Add drm_puts() for a much faster path to print constant strings
into a drm_printer object with memcpy and friends. This can
have seconds off of really large outputs such as GPU dumps.
If the drm_printer object supports a custom puts function then
use that otherwise fall back to the slower legacy p
Add a drm printer suitable for use with the read callback for
devcoredump or other suitable buffer based output format that
isn't otherwise covered by seq_file.
v2: Add improved documentation per Daniel Vetter
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_print.c | 74 +++
Add a puts() function to use seq_puts() to help speed up
up print time for constant strings.
Reviewed-by: Daniel Vetter
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_print.c | 6 ++
include/drm/drm_print.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm
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
For hangs, dump 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/msm-crash-dump.rst| 14 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 58 -
dri
Do a bit of cleanup to prepare for upcoming changes to pass the
hanging task comm and cmdline to the crash dump function.
v2: Use GFP_ATOMIC while holding the rcu lock per Chris Wilson
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gpu.c | 20 +++-
1 file changed, 11 i
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
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.
v2: Use a standard .rst for the msm crashdump documentation
Signed-off-by: Jordan Crouse
---
Documentation/gpu/ms
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.
v4: Make the return value const char * as suggested by Chris Wilson
v3: Fix error_puts -
Add the infrastructure to capture the current state of the GPU and
store it in memory so that 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 should
be extended to capture a much larger set of G
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 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/msm-crash-dump.rst| 7 +
drivers/gpu/drm/msm/adreno/adreno
Add a puts function for the coredump printer to bypass printf()
for constant strings for a speed boost. Reorganize the
coredump printf callback to share as much code as possible.
v2: Try to reuse code between print and puts as suggested by
Chris Wilson
Signed-off-by: Jordan Crouse
---
drive
On Friday, July 13, 2018 05:55:55 PM Dan Carpenter wrote:
> The omapfb_register_client[] array has OMAPFB_PLANE_NUM elements so the
> > should be >= or we are one element beyond the end of the array.
>
> Fixes: 8b08cf2b64f5 ("OMAP: add TI OMAP framebuffer driver")
> Signed-off-by: Dan Carpenter
On Monday, July 16, 2018 02:44:58 PM Colin King wrote:
> From: Colin Ian King
>
> The value of tmp being used in the switch statement has the range of
> just 0..3 hence the case 4 statement can never be reached and is
> deadcode and can be removed.
>
> Detected by CoverityScan, CID#744384 ("Logi
On Friday, July 20, 2018 07:52:13 PM Colin King wrote:
> From: Colin Ian King
>
> Pointer 'in' is being assigned but is never used hence it is
> redundant and can be removed.
>
> Cleans up clang warning:
> warning: variable 'in' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Co
On Saturday, July 21, 2018 08:16:09 PM Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix indentation warning (from gcc 8.1.0) in omap2/omapfb:
>
> ../drivers/video/fbdev/omap2/omapfb/dss/dispc.c: In function 'pixinc':
> ../drivers/video/fbdev/omap2/omapfb/dss/dispc.c:1859:2: warning: this 'else'
On Monday, July 16, 2018 03:45:43 PM Hans de Goede wrote:
> On x86 some firmwares use a low non native resolution for the display when
> they have shown some text messages. While keeping the bgrt filled with info
> for the native resolution. If the bgrt image intended for the native
> resolution st
https://bugs.freedesktop.org/show_bug.cgi?id=107309
--- Comment #2 from Vasilis LIaskovitis ---
Cool, thanks!
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://l
Hi,
On Tuesday 17 July 2018 04:33 AM, Carsten Behling wrote:
modesetting X11 driver may provide negative x/y cordinates in
mdp5_crtc_cursor_move call when rotation is enabled.
Cursor buffer can overlap down to its negative width/height.
ROI has to be recalculated for negative x/y indicating us
https://bugzilla.kernel.org/show_bug.cgi?id=200633
--- Comment #2 from sybo...@gmail.com ---
dmesg: https://ghostbin.com/paste/7pyty
Xorg: https://ghostbin.com/paste/38zyy
amdgpu.dc=0 does indeed make the issue go away, so I'm guessing DC was turned
on by default for Tonga in this kernel.
--
Yo
Hi Jordan,
I might be a bit late for the party, so consider the following jfyi.
On 24 July 2018 at 17:33, Jordan Crouse wrote:
> +void drm_puts(struct drm_printer *p, const char *str)
One could easily use the compiler to detect if drm_printf or drm_puts
should be used. See the trace_printk defi
On 2018-07-23 15:14, Tanmay Shah wrote:
file derived from msm-next kernel uapi header.
Change-Id: Idcaa1ad6fc13e0c1d2d0a2e619121d2c5450f7da
---
Makefile.sources | 1 +
include/drm/msm_drm.h | 308
++
2 files changed, 309 insertions(+)
cr
file derived from msm-next kernel uapi header.
Signed-off-by: Tanmay Shah
---
Makefile.sources | 1 +
include/drm/msm_drm.h | 308 ++
2 files changed, 309 insertions(+)
create mode 100644 include/drm/msm_drm.h
diff --git a/Makefile.sources
https://bugs.freedesktop.org/show_bug.cgi?id=107367
Bug ID: 107367
Summary: [regression, bisected] Games freeze the PC with newest
AMD Staging DRM Next Kernel
Product: Mesa
Version: git
Hardware: Other
OS: A
Boris Brezillon writes:
> This is needed to ensure ->is_unity is correct when the plane was
> previously configured to output a multi-planar format with scaling
> enabled, and is then being reconfigured to output a uniplanar format.
>
> Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
Tanmay Shah writes:
> file derived from msm-next kernel uapi header.
Unless there's an exception from Dave, I believe uapi headers in libdrm
and Mesa should be direct copies from "make headers_install" on the
drm-next branch. How does this compare to that?
signature.asc
Description: PGP signa
This caused a kernel oops since %pdH interpreted the pointer
as a struct file.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/drm_dp_cec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
index 87b67cc1ea58..a6cac47f
https://bugzilla.kernel.org/show_bug.cgi?id=199425
--- Comment #13 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
(In reply to Harry Wentland from comment #11)
> Should be fixed by https://patchwork.freedesktop.org/patch/230831/ which is
> merged into amd-staging-drm-next
Just tested with
On Tue, 24 Jul 2018 16:17:47 +0200 Michal Hocko wrote:
> On Fri 20-07-18 17:09:02, Andrew Morton wrote:
> [...]
> > - Undocumented return value.
> >
> > - comment "failed to reap part..." is misleading - sounds like it's
> > referring to something which happened in the past, is in fact
> > r
https://bugs.freedesktop.org/show_bug.cgi?id=106228
--- Comment #5 from Daniel Drake ---
Created attachment 140809
--> https://bugs.freedesktop.org/attachment.cgi?id=140809&action=edit
additional patch
this patch may also be required
--
You are receiving this mail because:
You are the assign
On Mon, Jul 23, 2018 at 10:29 AM, Jia-Ju Bai wrote:
> cik_pcie_gen3_enable() is only called by cik_common_hw_init(), which is
> never called in atomic context.
> cik_pcie_gen3_enable() calls mdelay() to busily wait, which is not
> necessary.
> mdelay() can be replaced with msleep().
>
> This is fo
On Mon, Jul 23, 2018 at 12:32 PM, Gustavo A. R. Silva
wrote:
> idx can be indirectly controlled by user-space, hence leading to a
> potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:408 amd
On Tue, 24 Jul 2018, Michal Hocko wrote:
> oom_reap_task_mm should return false when __oom_reap_task_mm return
> false. This is what my patch did but it seems this changed by
> http://www.ozlabs.org/~akpm/mmotm/broken-out/mm-oom-remove-oom_lock-from-oom_reaper.patch
> so that one should be fixed.
On 2018-07-24 12:19, Eric Anholt wrote:
Tanmay Shah writes:
file derived from msm-next kernel uapi header.
Unless there's an exception from Dave, I believe uapi headers in libdrm
and Mesa should be direct copies from "make headers_install" on the
drm-next branch. How does this compare to th
Tanmay Shah writes:
> On 2018-07-24 12:19, Eric Anholt wrote:
>> Tanmay Shah writes:
>>
>>> file derived from msm-next kernel uapi header.
>>
>> Unless there's an exception from Dave, I believe uapi headers in libdrm
>> and Mesa should be direct copies from "make headers_install" on the
>> drm
https://bugs.freedesktop.org/show_bug.cgi?id=106658
--- Comment #5 from Tim Carr ---
Have you tried booting with the 'idle=nomwait' kernel option? This worked for
the submitter of similar bug #106670, and so far seems to have worked for me as
well.
--
You are receiving this mail because:
You ar
This adds just enough performance counter support to measure the
clock. We don't have linux kernel drivers for the clock driving the
HW, and this was useful for determining that the V3D HW is running on
a slow clock, not that the driver was slow.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v
Once we push the job, the scheduler could run it and free it. So, if
we want to reference their fences, we need to grab them before then.
I haven't seen this happen in many days of conformance test runtime,
but let's still close the race.
Signed-off-by: Eric Anholt
Fixes: 57692c94dcbe ("drm/v3d:
On Fri, Jul 20, 2018 at 04:43:09PM -0400, Sean Paul wrote:
> From: Jeykumar Sankaran
>
> Adds bindings for Snapdragon 845 display processing unit
>
> Changes in v2:
> - Use SoC specific compatibles for mdss and dpu (Rob Herring)
> - Use assigned-clocks to set initial clock frequency (Rob Herring
Hi,
On Tue, Jul 24, 2018 at 12:12 AM, Daniel Thompson
wrote:
> Currently, if the DT does not define num-interpolated-steps then
> num_steps is undefined and the interpolation code will deploy randomly.
> Fix with a simple initialize to zero.
>
> Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear int
Hi, Stu:
It looks like the series is a bug fix of [1]. In [1], you create third
crtc but it does not work unless apply this series. So for all the
patches in this series, you should refer to [2] to add 'Fixes:' and
'Cc:' in commit message.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next
Hi, Stu:
On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote:
> This patch add memory mode for RDMA
>
> If use RDMA to read data from memory, it should set memory mode to RDMA
>
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 16 +++-
> 1 file changed,
Hi, Stu:
On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote:
> This patch add layer number condition for RDMA to control plane
>
> When plane init in crtc create,
> it use the number of OVL layer to init plane.
> That's OVL can read 4 memory address.
>
> For mt2712 third ddp, it use RDMA to read
Hi Takashi lwai,
Sorry, I have to use outlook again, since my mail client had some problems that
did not receive these series patches.
See the commands in line.
Thanks
JimQu
å件人: amd-gfx 代表 Takashi Iwai
åéæ¶é´: 2018å¹´7æ23æ¥ 22:50
https://bugs.freedesktop.org/show_bug.cgi?id=105532
--- Comment #10 from Timothy Arceri ---
(In reply to Christian Lanig from comment #7)
> (In reply to Alexander Tsoy from comment #5)
> > (In reply to Christian Lanig from comment #4)
> > There are native linux binaries in the linux subfolder.
>
Hi, Stu:
On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote:
> This patch fixed the error value for add DSI1 in mutex
>
English is not my mother language, but should it be 'fix' rather than
'fixed'?
Regards,
CK
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 2 +-
On Tue, 24 Jul 2018, Daniel Thompson wrote:
> Currently, if the DT does not define num-interpolated-steps then
> num_steps is undefined and the interpolation code will deploy randomly.
> Fix with a simple initialize to zero.
>
> Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear interpolation betwee
On Wed, 25 Jul 2018 05:32:52 +0200,
Qu, Jim wrote:
> @@ -269,6 +271,10 @@ static void radeon_audio_enable(struct radeon_device
> *rdev,
>
> if (rdev->audio.funcs->enable)
> rdev->audio.funcs->enable(rdev, pin, enable_mask);
> +
> + if (acomp && acomp->audio_ops && ac
See comments in line.
Thanks
JimQu
å件人: amd-gfx 代表 Takashi Iwai
åéæ¶é´: 2018å¹´7æ23æ¥ 22:50
æ¶ä»¶äºº: alsa-de...@alsa-project.org
æé: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
主é¢: [PATCH 4/4] drm/amdgpu:
On 2018å¹´07æ25æ¥ 13:28, Takashi Iwai wrote:
On Wed, 25 Jul 2018 05:32:52 +0200,
Qu, Jim wrote:
@@ -269,6 +271,10 @@ static void radeon_audio_enable(struct radeon_device *rdev,
if (rdev->audio.funcs->enable)
rdev->audio.funcs->enable(rdev, pin, enable_mask);
+
+
Hi, Stu:
On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote:
> This patch add dummy buffer for RDMA memory mode
>
> When display power on, the drm frame work would modeset and
> set up the display HW.
>
> In this time, the RDMA would start wroking and read the data from memory.
> But, user space
On Wed, 25 Jul 2018 07:38:37 +0200,
Qu, Jim wrote:
>
> Jim: Just like Alex said, we want driver can get eld info when hotplug in new
> device. amdgpu driver is a bit difference from radeon driver, it is not a
> suitable place to call notify() function in *_audio_enable() , since they are
> not
https://bugzilla.kernel.org/show_bug.cgi?id=200645
Bug ID: 200645
Summary: 4.18-rc regression bisected to e03fd3f30: amdgpu
polaris11/rx460 only activates on one output/monitor
of two
Product: Drivers
Version: 2.5
https://bugzilla.kernel.org/show_bug.cgi?id=200645
--- Comment #1 from Duncan (1i5t5.dun...@cox.net) ---
Created attachment 277489
--> https://bugzilla.kernel.org/attachment.cgi?id=277489&action=edit
gunziped /proc/config.gz
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=200645
--- Comment #2 from Duncan (1i5t5.dun...@cox.net) ---
Created attachment 277491
--> https://bugzilla.kernel.org/attachment.cgi?id=277491&action=edit
xrandr output (working)
--
You are receiving this mail because:
You are watching the assignee
On Tue 24-07-18 14:07:49, David Rientjes wrote:
[...]
> mm/oom_kill.c: clean up oom_reap_task_mm() fix
>
> indicate reaping has been partially skipped so we can expect future skips
> or another start before finish.
But we are not skipping. This is essentially the same case as mmap_sem
trylock fa
On Tue 24-07-18 12:53:07, Andrew Morton wrote:
[...]
> > On top of that the proposed cleanup looks as follows:
> >
>
> Looks good to me. Seems a bit strange that we omit the pr_info()
> output if the mm was partially reaped - people would still want to know
> this? Not very important though.
101 - 159 of 159 matches
Mail list logo
