[Bug 108194] Civilization VI - Animated leader characters small black squares artifacts
https://bugs.freedesktop.org/show_bug.cgi?id=108194 --- Comment #3 from Timothy Arceri --- It's also possible this is another example of bug #104602 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega
https://bugs.freedesktop.org/show_bug.cgi?id=104602 --- Comment #17 from Timothy Arceri --- After talking this over with Marek here is a summary of the problem. LLVM's VGPR indexing code on gfx9+ is broken for immediate arrays. Usually this is not a problem as GLSL IR in mesa will lower these to Uniforms via lower_const_arrays_to_uniforms(). However this does not work for the shaders in Civ6 because these arrays are not actually defined as constant arrays for example the original shader looks like this: vec4 x0[3]; vec4 x1[6]; vec4 x2[6]; vec4 x3[6]; x0[0].xy = vec2(0.031250, 0.50); x0[1].xy = vec2(0.968750, 0.031250); x0[2].xy = vec2(0.968750, 0.968750); x1[0].xy = vec2(1.00, 1.00); x1[1].xy = vec2(0.00, 1.00); x1[2].xy = vec2(-1.00, 0.00); x1[3].xy = vec2(-1.00, -1.00); x1[4].xy = vec2(0.00, -1.00); x1[5].xy = vec2(1.00, 0.00); x2[0].xy = vec2(1.00, -1.00); x2[1].xy = vec2(2.00, 1.00); x2[2].xy = vec2(1.00, 2.00); x2[3].xy = vec2(-1.00, 1.00); x2[4].xy = vec2(-2.00, -1.00); x2[5].xy = vec2(-1.00, -2.00); Without SSA I don't see any way for GLSL IR to easily recognise this as a constant array. Unfortunately by the time LLVM is done it is recognised and is exposed to the buggy indexing support. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Outreachy kernel] [PATCH] drm: Rename crtc_idr as object_idr to KMS cleanups
On Wed, 31 Oct 2018, Shayenne Moura wrote: > On 10/31, Julia Lawall wrote: > > > > > > On Wed, 31 Oct 2018, Shayenne Moura wrote: > > > > > On 10/31, Julia Lawall wrote: > > > > > > > > > > > > On Wed, 31 Oct 2018, Shayenne da Luz Moura wrote: > > > > > > > > > Rename 'drm_mode_config.crtc_idr' as 'drm_mode_config.object_idr', > > > > > as proposed in the task description in TODO list for KMS cleanups. > > > > > > > > Is object_idr a field that already exists? If so, "Rename" is not the > > > > best choice of words. It should be something like "use the object_idr > > > > field instead of the crtc_idr field" and then explain why. "task > > > > description in TODO list for KMS cleanups" isn't very helpful to > > > > understand why the change should be made. > > > > > > > > julia > > > > > > Hi Julia, > > > > > > Thank you for your review! > > > > > > This patch is to solve this TODO task: > > > drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. > > > Should be renamed to drm_mode_config.object_idr. > > > > > > Do you think I need to use this description in my commit message? > > > > That seems more helpful. > > > > But it seems that the name should actually be changed. Which means that > > the structure definition should be changed too. Was that done? > > > > julia > > Yes, you are right. I did not add the header file. Compilation should have given an error message. If you thought you compiled, then you don't have the right configuration to actually compile the code that you changed. julia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108086] mesa 18.2.x line is crashing and disabling kwin_x11 and effects thereof, no problem with 18.1.x
https://bugs.freedesktop.org/show_bug.cgi?id=108086 --- Comment #6 from jeckfer...@gmail.com --- Created attachment 142317 --> https://bugs.freedesktop.org/attachment.cgi?id=142317&action=edit It occurred again with 18.2.3 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108585] *ERROR* hw_init of IP block failed -22
https://bugs.freedesktop.org/show_bug.cgi?id=108585 --- Comment #15 from Alex Deucher --- Created attachment 142316 --> https://bugs.freedesktop.org/attachment.cgi?id=142316&action=edit more involved fix These patches attempt to reset the GPU on init if the GPU was already running from a previous load of the driver. Compile tested only at the moment. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108606] Raven Ridge: constant lockups since latest pull from Linus
https://bugs.freedesktop.org/show_bug.cgi?id=108606 --- Comment #12 from Alex Deucher --- (In reply to Samantha McVey from comment #11) > I am testing with amdgpu.ppfeaturemask=0xfffdbfff right now. I still have > that commit reverted, is this test still valid? What I mean is I have > amdgpu.ppfeaturemask=0xfffdbfff in my cmdline at the same time as commit > a06c3ee083b5c622bb9f4a687d7ab5265ee73dbf is reverted. yes, that is fine. That commit just changes the default value of the parameter. If you specify it directly, you override the default. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Add RGBA64 texture cpp for vc4 driver.
This patch is needed to help implement half-float texturing and
rendering for the vc4 driver in mesa. This small patch introduces the
cpp value for the RGBA64 texture. A future patch will include updates to
vc4_render_cl.c to handle HDR color stores.
---
drivers/gpu/drm/vc4/vc4_validate.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_validate.c
b/drivers/gpu/drm/vc4/vc4_validate.c
index 2db485abb186..29a4a21b5864 100644
--- a/drivers/gpu/drm/vc4/vc4_validate.c
+++ b/drivers/gpu/drm/vc4/vc4_validate.c
@@ -646,6 +646,9 @@ reloc_tex(struct vc4_exec_info *exec,
case VC4_TEXTURE_TYPE_S8:
cpp = 1;
break;
+ case VC4_TEXTURE_TYPE_RGBA64:
+ cpp = 8;
+ break;
case VC4_TEXTURE_TYPE_ETC1:
/* ETC1 is arranged as 64-bit blocks, where each block is 4x4
* pixels.
@@ -657,7 +660,6 @@ reloc_tex(struct vc4_exec_info *exec,
case VC4_TEXTURE_TYPE_BW1:
case VC4_TEXTURE_TYPE_A4:
case VC4_TEXTURE_TYPE_A1:
- case VC4_TEXTURE_TYPE_RGBA64:
case VC4_TEXTURE_TYPE_YUV422R:
default:
DRM_DEBUG("Texture format %d unsupported\n", type);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108272] [polaris10] opencl-mesa: Anything using OpenCL segfaults, XFX Radeon RX 580
https://bugs.freedesktop.org/show_bug.cgi?id=108272 --- Comment #11 from jamespharve...@gmail.com --- When I originally filed this, I assumed it was 1 bug since I tried 2 things with OpenCL, and both failed with opencl-mesa but worked with opencl-amd. Jan Vesely was correct that there were two separate problems. I'm hoping Jan Vesely can give guidance on whether to leave this bug open for any of the reasons below, or if I should close it and potentially open up 1-2 new bugs. The original luxmark bug (segfault) is solved, but that exposes 2 new opencl-mesa bugs when running luxmark. The original IndigoBenchmark bug (segfault) isn't solved, but as explained below, I understand if we have to consider that unsolvable for now. I don't think this affects any of these bugs, but I'll mention a few weeks ago, I switched back to my Asus Radeon R9 390. The same behaviors discussed in this entire bug report occur. (i.e. 18.2.3 and before crash luxmark.) If someone really wants me to do so, I can switch back to the RX 580 to test 18.2.4, but I'm betting since it works properly with the R9 390 that the problem is fixed. ORIGINAL LUXMARK BUG #1 - Using mesa 18.2.4, the luxmark segfault is solved. NEW - LUXMARK BUG #2 Jan Vesely's comment on 2018-10-09 mentions: "bumping MAX_GLOBAL_BUFFERS to 32 allows luxmark to run, albeit still with many incorrect pixels -- libclc rounding conversions are incorrect." That's what I'm seeing out of 18.2.4. Using LuxBall HDR (Simple Benchmark): MESA 18.2.4: 40626 (Image validation OK (65739 different pixels, 10.27%) AMDGPU-PRO: 15739 (Image validation OK (5736 different pixels, 0.90%) There's no typos there. opencl-mesa scores almost unbelievably higher than opencl-amd, but the different pixels percentage increases by a factor of 11.4. As Jan's other comment on 2018-10-09 mentions, the image looks garbled and the results are incorrect. Not sure if this bug should be left open for this issue, or if I should create a new bug. (Or, if there is a bug already open for it.) Or, if mesa will say it's purely libclc's problem, and to go to them about it. NEW - LUXMARK BUG #3 Although luxmark can now benchmark, when doing so, all input becomes unusably awful. It reminds me of when Windows has too many things open, suddenly decided it can't cope, and you're waiting to see if it's going to recover or crash. Keystrokes take too long to be printed, and the mouse becomes slow and jumpy. Top shows cpu and memory usage are fine, which was my first thought. BTW, running xf86-video-amdgpu 18.1.0, and when I upgraded mesa, it was both mesa and opencl-mesa. In comparison, if I use opencl-amd, input is not affected. I wouldn't even know the GPU is being slammed. Using the program radeontop, I can see when using mesa, "Graphics pipe", "Texture Addresser", and "Shader Interpolator" are between 95-100%, usually 98-100%. When using opencl-amd, radeontop shows the same. (Granted, Vertex Grouper + Tesselator / Shader Export/Scan Converter/Depth Block/Color Block bounce between 5-20% vs on opencl-mesa, they bounce between 1-5%.) INDIGO BUG -- I edited 18.2.4's si_get.c to be very short: snprintf(sscreen->renderer_string, sizeof(sscreen->renderer_string), "%s", chip_name); And compiled/installed it, but it didn't affect the crash. IndigoBenchmark said they're statically linking with LLVM 3.4, which is quite old. But, it runs fine with opencl-amd, and only crashes on opencl-mesa. I just posted a followup "where do we go from here"-ish comment there which has to be moderator approved so isn't showing yet. https://www.indigorenderer.com/forum/viewtopic.php?f=37&t=14986 Part of me thinks it needs to be given up on, being a closed-source precompiled binary statically linked against LLVM 3.4. Part of me thinks since it only crashes with opencl-mesa, and runs perfectly fine with opencl-amd, there's probably (but not definitely) a bug in opencl-mesa. But, I understand since they don't seem to be paying this any attention, we may have to give up on the Indigo Bug as being unable to be realistically investigated further. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108606] Raven Ridge: constant lockups since latest pull from Linus
https://bugs.freedesktop.org/show_bug.cgi?id=108606 --- Comment #11 from Samantha McVey --- I am testing with amdgpu.ppfeaturemask=0xfffdbfff right now. I still have that commit reverted, is this test still valid? What I mean is I have amdgpu.ppfeaturemask=0xfffdbfff in my cmdline at the same time as commit a06c3ee083b5c622bb9f4a687d7ab5265ee73dbf is reverted. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108608] Blank screen after KMS with Linux 4.19.0 on Hawaii (R9 290)
https://bugs.freedesktop.org/show_bug.cgi?id=108608 --- Comment #4 from Alex Deucher --- I think this patch should fix at least some of the issues: https://patchwork.freedesktop.org/patch/259364/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108606] Raven Ridge: constant lockups since latest pull from Linus
https://bugs.freedesktop.org/show_bug.cgi?id=108606 --- Comment #10 from Alex Deucher --- Can you determine whether it's stutter or gfxoff that causes the problem? Please try booting with amdgpu.ppfeaturemask=0xfffdbfff or amdgpu.ppfeaturemask=0x3fff on the kernel command line in grub and see which one fixes the issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108606] Raven Ridge: constant lockups since latest pull from Linus
https://bugs.freedesktop.org/show_bug.cgi?id=108606 --- Comment #9 from Alex Deucher --- Created attachment 142315 --> https://bugs.freedesktop.org/attachment.cgi?id=142315&action=edit possible fix Does this patch fix the issue? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108609] vegam_smumgr.c: accessing mvdd_voltage_table.entries[] array out of bounds in function vegam_populate_smc_mvdd_table
https://bugs.freedesktop.org/show_bug.cgi?id=108609 --- Comment #3 from Alex Deucher --- Ideally against one of these branches: https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.21-wip -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108096] [amd-staging-drm-next] SDDM screen corruption (not usable) with RX580, amdgpu, dc=1 (of course), regression - [bisected]
https://bugs.freedesktop.org/show_bug.cgi?id=108096 Dieter Nützel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] amdgpu/test: Add illegal register and memory access test.
On Wed, Oct 31, 2018 at 4:05 PM Grodzovsky, Andrey
wrote:
>
>
>
> On 10/31/2018 03:49 PM, Alex Deucher wrote:
> > On Wed, Oct 31, 2018 at 2:33 PM Andrey Grodzovsky
> > wrote:
> >> Illegal access will cause CP hang followed by job timeout and
> >> recovery kicking in.
> >> Also, disable the suite for all APU ASICs until GPU
> >> reset issues for them will be resolved and GPU reset recovery
> >> will be enabled by default.
> >>
> >> Signed-off-by: Andrey Grodzovsky
> >> ---
> >> tests/amdgpu/deadlock_tests.c | 118
> >> +-
> >> 1 file changed, 117 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
> >> index 292ec4e..c565f7a 100644
> >> --- a/tests/amdgpu/deadlock_tests.c
> >> +++ b/tests/amdgpu/deadlock_tests.c
> >> @@ -73,6 +73,29 @@
> >> * 1 - pfp
> >> */
> >>
> >> +#definePACKET3_WRITE_DATA 0x37
> >> +#defineWRITE_DATA_DST_SEL(x) ((x) << 8)
> >> + /* 0 - register
> >> +* 1 - memory (sync - via GRBM)
> >> +* 2 - gl2
> >> +* 3 - gds
> >> +* 4 - reserved
> >> +* 5 - memory (async - direct)
> >> +*/
> >> +#defineWR_ONE_ADDR (1 << 16)
> >> +#defineWR_CONFIRM (1 << 20)
> >> +#defineWRITE_DATA_CACHE_POLICY(x) ((x) << 25)
> >> + /* 0 - LRU
> >> +* 1 - Stream
> >> +*/
> >> +#defineWRITE_DATA_ENGINE_SEL(x)((x) << 30)
> >> + /* 0 - me
> >> +* 1 - pfp
> >> +* 2 - ce
> >> +*/
> >> +
> >> +#define mmVM_CONTEXT0_PAGE_TABLE_BASE_ADDR
> >> 0x54f
> >> +
> >> static amdgpu_device_handle device_handle;
> >> static uint32_t major_version;
> >> static uint32_t minor_version;
> >> @@ -85,6 +108,8 @@ int use_uc_mtype = 0;
> >> static void amdgpu_deadlock_helper(unsigned ip_type);
> >> static void amdgpu_deadlock_gfx(void);
> >> static void amdgpu_deadlock_compute(void);
> >> +static void amdgpu_illegal_reg_access();
> >> +static void amdgpu_illegal_mem_access();
> >>
> >> CU_BOOL suite_deadlock_tests_enable(void)
> >> {
> >> @@ -94,7 +119,9 @@ CU_BOOL suite_deadlock_tests_enable(void)
> >> &minor_version,
> >> &device_handle))
> >> return CU_FALSE;
> >>
> >> - if (device_handle->info.family_id == AMDGPU_FAMILY_SI) {
> >> + if (device_handle->info.family_id == AMDGPU_FAMILY_SI ||
> > Add AMDGPU_FAMILY_KV for CI based APUs as well.
> >
> >
> >> + device_handle->info.family_id == AMDGPU_FAMILY_CZ
> >> ||
> >> + device_handle->info.family_id == AMDGPU_FAMILY_RV)
> >> {
> >> printf("\n\nCurrently hangs the CP on this ASIC, deadlock
> >> suite disabled\n");
> >> enable = CU_FALSE;
> >> }
> >> @@ -140,6 +167,8 @@ int suite_deadlock_tests_clean(void)
> >> CU_TestInfo deadlock_tests[] = {
> >> { "gfx ring block test", amdgpu_deadlock_gfx },
> >> { "compute ring block test", amdgpu_deadlock_compute },
> >> + { "illegal reg access test", amdgpu_illegal_reg_access },
> >> + { "illegal mem access test", amdgpu_illegal_mem_access },
> > Won't this illegal mem access just result in a page fault? Is the
> > idea to set vm_debug to force an MC halt to test reset?
> >
> > Alex
>
> For this test to hang the CP amdgpu.vm_fault_stop=2 needs to be set.
With the KV added above and a comment about vm_fault_stop added, this patch is:
Reviewed-by: Alex Deucher
>
> Andrey
>
> >
> >> CU_TEST_INFO_NULL,
> >> };
> >>
> >> @@ -257,3 +286,90 @@ static void amdgpu_deadlock_helper(unsigned ip_type)
> >> r = amdgpu_cs_ctx_free(context_handle);
> >> CU_ASSERT_EQUAL(r, 0);
> >> }
> >> +
> >> +static void bad_access_helper(int reg_access)
> >> +{
> >> + amdgpu_context_handle context_handle;
> >> + amdgpu_bo_handle ib_result_handle;
> >> + void *ib_result_cpu;
> >> + uint64_t ib_result_mc_address;
> >> + struct amdgpu_cs_request ibs_request;
> >> + struct amdgpu_cs_ib_info ib_info;
> >> + struct amdgpu_cs_fence fence_status;
> >> + uint32_t expired;
> >> + int i, r;
> >> + amdgpu_bo_list_handle bo_list;
> >> + amdgpu_va_handle va_handle;
> >> +
> >> + r = amdgpu_cs_ctx_create(device_handle, &context_handle);
> >> + CU_ASSERT_EQUAL(r, 0);
> >> +
> >> + r = amdgpu_bo_alloc_and_map_raw(device_handle, 4096, 4096,
> >> + AMDGPU_GEM_DOMAIN_GTT, 0, 0,
> >> +
[Bug 108096] [amd-staging-drm-next] SDDM screen corruption (not usable) with RX580, amdgpu, dc=1 (of course), regression - [bisected]
https://bugs.freedesktop.org/show_bug.cgi?id=108096 --- Comment #24 from Dieter Nützel --- (In reply to Andrey Grodzovsky from comment #22) > (In reply to Andrey Grodzovsky from comment #21) > > Please load the driver in debug mode so I can see the error code value in > > dmesg - > > when loading the kernel add drm.debug=0xff > > > > Also to trace where exactly the error originated from please install > > trace-cmd and beore starting X (assuming you get the failure and the dmesg > > error right on start) > > sudo trace-cmd start -p function_graph -l amdgpu_cs_ioctl > > and get the output from /sys/kernel/debug/tracing/trace > > My bad, the correct command is > sudo trace-cmd start -p function_graph -g amdgpu_cs_ioctl Andrey, do you need these logs even after my commit #23? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108096] [amd-staging-drm-next] SDDM screen corruption (not usable) with RX580, amdgpu, dc=1 (of course), regression - [bisected]
https://bugs.freedesktop.org/show_bug.cgi?id=108096 --- Comment #23 from Dieter Nützel --- (In reply to Samuel Pitoiset from comment #20) > Make sure to load the right version of libdrm (ie. 2.4.93 or more recent). I > had this problem today because I was loading and old version of libdrm. > Something was installed in the wrong place. Doh! Sorry! Ugh. Development systems... My latest AMDGPU-PRO OpenCL (amdgpu-pro-18.30-635379-sle-12.tar.xz) installation broad me /opt/amdgpu/lib64/ insgesamt 268 drwxr-xr-x 2 root root 4096 18. Aug 06:31 . drwxr-xr-x 4 root root 4096 18. Aug 06:31 .. lrwxrwxrwx 1 root root22 8. Aug 18:33 libdrm_amdgpu.so.1 -> libdrm_amdgpu.so.1.0.0 -rwxr-xr-x 1 root root 69192 8. Aug 18:33 libdrm_amdgpu.so.1.0.0 lrwxrwxrwx 1 root root22 8. Aug 18:33 libdrm_radeon.so.1 -> libdrm_radeon.so.1.0.1 -rwxr-xr-x 1 root root 68968 8. Aug 18:33 libdrm_radeon.so.1.0.1 lrwxrwxrwx 1 root root15 8. Aug 18:33 libdrm.so.2 -> libdrm.so.2.4.0 -rwxr-xr-x 1 root root 99600 8. Aug 18:33 libdrm.so.2.4.0 lrwxrwxrwx 1 root root15 8. Aug 18:33 libkms.so.1 -> libkms.so.1.0.0 -rwxr-xr-x 1 root root 22096 8. Aug 18:33 libkms.so.1.0.0 but the screen corruption appeared first around Aug 22, 2018. So it worked 'halfway' with upstream _and_ AMDGPU-PRO libdrm. Maybe the AMD developers could include a 'tag' or something like that to differentiate both version?! CONCLUSION After deleting /opt/amdgpu/lib64/ ALL is fine, again. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108194] Civilization VI - Animated leader characters small black squares artifacts
https://bugs.freedesktop.org/show_bug.cgi?id=108194 Timothy Arceri changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Timothy Arceri --- I couldn't reproduce. Do you think you could get an apitrace [1] of the problem? Also if you were able to test 18.3 that would be great too. [1] https://github.com/apitrace/apitrace/wiki/Steam -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega
https://bugs.freedesktop.org/show_bug.cgi?id=104602 --- Comment #16 from Timothy Arceri --- Created attachment 142314 --> https://bugs.freedesktop.org/attachment.cgi?id=142314&action=edit Renderdoc capture Also attaching a renderdoc capture of the issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega
https://bugs.freedesktop.org/show_bug.cgi?id=104602 --- Comment #15 from Timothy Arceri --- Created attachment 142313 --> https://bugs.freedesktop.org/attachment.cgi?id=142313&action=edit Hack around issue I've found the source of the problem. It seems that the tgsi indirect indexing optimisation is causing issues on Vega for some reason. I've attached a hack which disables it resulting in correct rendering. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/msm: subclass work object for vblank events
msm maintains a separate structure to define vblank
work definitions and a list to track events submitted
to the display worker thread. We can avoid these
redundant list and its protection mechanism, if we
subclass the work object to encapsulate vblank
event parameters.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/msm_drv.c | 70 ---
drivers/gpu/drm/msm/msm_drv.h | 7 -
2 files changed, 19 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 1f384b3..67a96ee 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -203,61 +203,44 @@ u32 msm_readl(const void __iomem *addr)
return val;
}
-struct vblank_event {
- struct list_head node;
+struct msm_vblank_work {
+ struct kthread_work work;
int crtc_id;
bool enable;
+ struct msm_drm_private *priv;
};
static void vblank_ctrl_worker(struct kthread_work *work)
{
- struct msm_vblank_ctrl *vbl_ctrl = container_of(work,
- struct msm_vblank_ctrl, work);
- struct msm_drm_private *priv = container_of(vbl_ctrl,
- struct msm_drm_private, vblank_ctrl);
+ struct msm_vblank_work *vbl_work = container_of(work,
+ struct msm_vblank_work, work);
+ struct msm_drm_private *priv = vbl_work->priv;
struct msm_kms *kms = priv->kms;
- struct vblank_event *vbl_ev, *tmp;
- unsigned long flags;
-
- spin_lock_irqsave(&vbl_ctrl->lock, flags);
- list_for_each_entry_safe(vbl_ev, tmp, &vbl_ctrl->event_list, node) {
- list_del(&vbl_ev->node);
- spin_unlock_irqrestore(&vbl_ctrl->lock, flags);
-
- if (vbl_ev->enable)
- kms->funcs->enable_vblank(kms,
- priv->crtcs[vbl_ev->crtc_id]);
- else
- kms->funcs->disable_vblank(kms,
- priv->crtcs[vbl_ev->crtc_id]);
- kfree(vbl_ev);
-
- spin_lock_irqsave(&vbl_ctrl->lock, flags);
- }
+ if (vbl_work->enable)
+ kms->funcs->enable_vblank(kms, priv->crtcs[vbl_work->crtc_id]);
+ else
+ kms->funcs->disable_vblank(kms, priv->crtcs[vbl_work->crtc_id]);
- spin_unlock_irqrestore(&vbl_ctrl->lock, flags);
+ kfree(vbl_work);
}
static int vblank_ctrl_queue_work(struct msm_drm_private *priv,
int crtc_id, bool enable)
{
- struct msm_vblank_ctrl *vbl_ctrl = &priv->vblank_ctrl;
- struct vblank_event *vbl_ev;
- unsigned long flags;
+ struct msm_vblank_work *vbl_work;
- vbl_ev = kzalloc(sizeof(*vbl_ev), GFP_ATOMIC);
- if (!vbl_ev)
+ vbl_work = kzalloc(sizeof(*vbl_work), GFP_ATOMIC);
+ if (!vbl_work)
return -ENOMEM;
- vbl_ev->crtc_id = crtc_id;
- vbl_ev->enable = enable;
+ kthread_init_work(&vbl_work->work, vblank_ctrl_worker);
- spin_lock_irqsave(&vbl_ctrl->lock, flags);
- list_add_tail(&vbl_ev->node, &vbl_ctrl->event_list);
- spin_unlock_irqrestore(&vbl_ctrl->lock, flags);
+ vbl_work->crtc_id = crtc_id;
+ vbl_work->enable = enable;
+ vbl_work->priv = priv;
- kthread_queue_work(&priv->disp_thread.worker, &vbl_ctrl->work);
+ kthread_queue_work(&priv->disp_thread.worker, &vbl_work->work);
return 0;
}
@@ -269,20 +252,8 @@ static int msm_drm_uninit(struct device *dev)
struct msm_drm_private *priv = ddev->dev_private;
struct msm_kms *kms = priv->kms;
struct msm_mdss *mdss = priv->mdss;
- struct msm_vblank_ctrl *vbl_ctrl = &priv->vblank_ctrl;
- struct vblank_event *vbl_ev, *tmp;
int i;
- /* We must cancel and cleanup any pending vblank enable/disable
-* work before drm_irq_uninstall() to avoid work re-enabling an
-* irq after uninstall has disabled it.
-*/
- kthread_flush_work(&vbl_ctrl->work);
- list_for_each_entry_safe(vbl_ev, tmp, &vbl_ctrl->event_list, node) {
- list_del(&vbl_ev->node);
- kfree(vbl_ev);
- }
-
kthread_flush_worker(&priv->disp_thread.worker);
kthread_stop(priv->disp_thread.thread);
priv->disp_thread.thread = NULL;
@@ -474,9 +445,6 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
priv->wq = alloc_ordered_workqueue("msm", 0);
INIT_LIST_HEAD(&priv->inactive_list);
- INIT_LIST_HEAD(&priv->vblank_ctrl.event_list);
- kthread_init_work(&priv->vblank_ctrl.work, vblank_ctrl_worker);
- spin_lock_init(&priv->vblank_ctrl.lock);
drm_mode_config_init(ddev);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_d
[PATCH 1/2] drm/msm: use common display thread for dispatching vblank events
DPU was using one thread per display to dispatch async
commits and vblank requests. Since clean up already happened
in msm to use the common thread for all the display commits,
display threads are only used to cater vblank requests. Single
thread is sufficient to do the job without any performance hits.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 +---
drivers/gpu/drm/msm/msm_drv.c | 50 -
drivers/gpu/drm/msm/msm_drv.h | 2 +-
3 files changed, 23 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 82c55ef..aff20f5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -753,11 +753,7 @@ static int dpu_encoder_resource_control(struct drm_encoder
*drm_enc,
is_vid_mode = dpu_enc->disp_info.capabilities &
MSM_DISPLAY_CAP_VID_MODE;
- if (drm_enc->crtc->index >= ARRAY_SIZE(priv->disp_thread)) {
- DPU_ERROR("invalid crtc index\n");
- return -EINVAL;
- }
- disp_thread = &priv->disp_thread[drm_enc->crtc->index];
+ disp_thread = &priv->disp_thread;
/*
* when idle_pc is not supported, process only KICKOFF, STOP and MODESET
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9c9f7ff..1f384b3 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -257,8 +257,7 @@ static int vblank_ctrl_queue_work(struct msm_drm_private
*priv,
list_add_tail(&vbl_ev->node, &vbl_ctrl->event_list);
spin_unlock_irqrestore(&vbl_ctrl->lock, flags);
- kthread_queue_work(&priv->disp_thread[crtc_id].worker,
- &vbl_ctrl->work);
+ kthread_queue_work(&priv->disp_thread.worker, &vbl_ctrl->work);
return 0;
}
@@ -284,14 +283,12 @@ static int msm_drm_uninit(struct device *dev)
kfree(vbl_ev);
}
+ kthread_flush_worker(&priv->disp_thread.worker);
+ kthread_stop(priv->disp_thread.thread);
+ priv->disp_thread.thread = NULL;
+
/* clean up display commit/event worker threads */
for (i = 0; i < priv->num_crtcs; i++) {
- if (priv->disp_thread[i].thread) {
- kthread_flush_worker(&priv->disp_thread[i].worker);
- kthread_stop(priv->disp_thread[i].thread);
- priv->disp_thread[i].thread = NULL;
- }
-
if (priv->event_thread[i].thread) {
kthread_flush_worker(&priv->event_thread[i].worker);
kthread_stop(priv->event_thread[i].thread);
@@ -537,6 +534,22 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
ddev->mode_config.funcs = &mode_config_funcs;
ddev->mode_config.helper_private = &mode_config_helper_funcs;
+ /* initialize display thread */
+ kthread_init_worker(&priv->disp_thread.worker);
+ priv->disp_thread.dev = ddev;
+ priv->disp_thread.thread = kthread_run(kthread_worker_fn,
+ &priv->disp_thread.worker,
+ "disp_thread");
+ if (IS_ERR(priv->disp_thread.thread)) {
+ DRM_DEV_ERROR(dev, "failed to create crtc_commit kthread\n");
+ priv->disp_thread.thread = NULL;
+ goto err_msm_uninit;
+ }
+
+ ret = sched_setscheduler(priv->disp_thread.thread, SCHED_FIFO, ¶m);
+ if (ret)
+ pr_warn("display thread priority update failed: %d\n", ret);
+
/**
* this priority was found during empiric testing to have appropriate
* realtime scheduling to process display updates and interact with
@@ -544,27 +557,6 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
*/
param.sched_priority = 16;
for (i = 0; i < priv->num_crtcs; i++) {
-
- /* initialize display thread */
- priv->disp_thread[i].crtc_id = priv->crtcs[i]->base.id;
- kthread_init_worker(&priv->disp_thread[i].worker);
- priv->disp_thread[i].dev = ddev;
- priv->disp_thread[i].thread =
- kthread_run(kthread_worker_fn,
- &priv->disp_thread[i].worker,
- "crtc_commit:%d", priv->disp_thread[i].crtc_id);
- if (IS_ERR(priv->disp_thread[i].thread)) {
- DRM_DEV_ERROR(dev, "failed to create crtc_commit
kthread\n");
- priv->disp_thread[i].thread = NULL;
- goto err_msm_uninit;
- }
-
- ret = sched_setscheduler(priv->disp_thread[i].thread,
-SCHED_FIFO, ¶
Re: [PATCH v5 3/5] drm/gem: Add drm_gem_object_funcs
Den 17.10.2018 15.04, skrev Noralf Trønnes:
This adds an optional function table on GEM objects.
The main benefit is for drivers that support more than one type of
memory (shmem,vram,cma) for their buffers depending on the hardware it
runs on. With the callbacks attached to the GEM object itself, it is
easier to have core helpers for the the various buffer types. The driver
only has to make the decision about buffer type on GEM object creation
and all other callbacks can be handled by the chosen helper.
drm_driver->gem_prime_res_obj has not been added since there's a todo to
put a reservation_object into drm_gem_object.
v2: Drop drm_gem_object_funcs->prime_mmap in favour of
drm_gem_prime_mmap() (Daniel Vetter)
v1:
- drm_gem_object_funcs.map -> .prime_map let it only do PRIME mmap like
the function it superseeds (Daniel Vetter)
- Flip around the if ladders and make obj->funcs the first choice
highlighting the fact that this the new default way of doing it
(Daniel Vetter)
Signed-off-by: Noralf Trønnes
Acked-by: Daniel Vetter
---
Now that the shmem helper has now been postponed to the future I'm
thinking about doing some prep work in tinydrm to loosen the coupling to
the cma helper (longterm goal is try and get rid of tinydrm.ko altogether).
First step could be to add a drm_driver->gem_create_object function for
the cma helper that gives the default gem functions:
static const struct drm_gem_object_funcs drm_cma_gem_funcs = {
.free = drm_gem_cma_free_object,
.print_info = drm_gem_cma_print_info,
.get_sg_table = drm_gem_cma_prime_get_sg_table,
.vmap = drm_gem_cma_prime_vmap,
.vm_ops = &drm_gem_cma_vm_ops,
};
struct drm_gem_object *
drm_cma_gem_create_object_default_funcs(struct drm_device *dev, size_t size)
{
struct drm_gem_cma_object *cma_obj;
cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
if (!cma_obj)
return NULL;
cma_obj->base.funcs = &drm_cma_gem_funcs;
return cma_obj;
}
tinydrm drivers relies on the buffer always having a virtual address, so
for imported buffers there's currently a custom .gem_prime_import_sg_table
that vmaps the buffer. In order to use the default cma helper gem
functions I plan to do the vmapping on framebuffer creation instead.
I could create a pair of functions (fb_create/destroy) in the cma helper
to achieve that:
struct drm_framebuffer *
drm_cma_fb_create_vmap_with_funcs(struct drm_device *dev, struct
drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd,
const struct drm_framebuffer_funcs *funcs)
{
struct drm_gem_cma_object *cma;
struct drm_framebuffer *fb;
struct drm_gem_object *gem;
fb = drm_gem_fb_create_with_funcs(dev, file, mode_cmd, funcs);
if (IS_ERR(fb))
return fb;
gem = drm_gem_fb_get_obj(fb, 0);
cma = to_drm_gem_cma_obj(gem);
if (gem->import_attach)
cma->vaddr = dma_buf_vmap(gem->import_attach->dmabuf);
if (!cma->vaddr) {
DRM_DEV_DEBUG(dev->dev, "Failed to vmap buffer\n");
drm_gem_fb_destroy(fb);
return ERR_PTR(-ENOMEM);
}
return fb;
}
void drm_cma_fb_destroy_vunmap(struct drm_framebuffer *fb)
{
struct drm_gem_object *gem = drm_gem_fb_get_obj(fb, 0);
struct drm_gem_cma_object *cma = to_drm_gem_cma_obj(gem);
if (gem->import_attach) {
dma_buf_vmap(gem->import_attach->dmabuf, cma->vaddr);
cma->vaddr = NULL;
}
drm_gem_fb_destroy(fb);
}
This approach means that I would have to do the same for the future shmem
helper as well. If I add a vaddr to the gem object, I could create a
common pair of functions in the gem fb helper that can be used regardless
of the underlying buffer:
struct drm_gem_object {
void *vaddr;
};
struct drm_framebuffer *
drm_gem_fb_create_vmap_with_funcs(struct drm_device *dev, struct
drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd,
const struct drm_framebuffer_funcs *funcs)
{
struct drm_framebuffer *fb;
struct drm_gem_object *obj;
void *vaddr;
fb = drm_gem_fb_create_with_funcs(dev, file, mode_cmd, funcs);
if (IS_ERR(fb))
return fb;
if (obj->import_attach)
vaddr = dma_buf_vmap(obj->import_attach->dmabuf);
else
vaddr = drm_gem_vmap(obj);
if (!vaddr || IS_ERR(vaddr)) {
DRM_DEV_DEBUG(dev->dev, "Failed to vmap buffer\n");
drm_gem_fb_destroy(fb);
return ERR_PTR(-ENOMEM);
}
obj->vaddr = vaddr;
return fb;
}
void drm_gem_fb_destroy_vunmap(struct drm_framebuffer *fb)
{
struct drm_gem_object *obj = drm_gem_fb_get_obj(fb, 0);
if (obj->import_attach) {
dma_buf_vmap(obj->import_attach->dmabuf, obj->vaddr);
obj->vaddr = NULL;
} else {
drm_gem_vunmap(obj, obj->vaddr);
}
drm_gem_fb_destroy(fb);
}
It is also possible to take this a bit further and move the dma_buf_vmap()
call into drm_gem_vmap() and let it provide an address for imported
Re: [PATCH v6 00/28] Display Stream Compression enabling on eDP/DP
Pushed first 7 patches of this series, thanks for the reviews. Manasi On Wed, Oct 24, 2018 at 03:28:12PM -0700, Manasi Navare wrote: > VESA has developed an industry standard Display Stream Compression(DSC) > for interoperable, visually lossless compression over display links to > address the needs for higher resolution displays. > > This patch series enables DSC on Gen 10 eDP and Gen 11 eDP/DP panels. > This implementation is based on VESA DP 1.4 and DSC specifications. > > These patches have been validated on 1080p eDP 1.4 panel with DSC support > and FPGA based DP 1.4 sink device for following configurations: > > - DSC with both VDSC engines enabled > - DSC with only Left VDSC engine enabled > - DSC for Input = 24bpp, Output = 8bpp > - DSC for Input = 24bpp, Output = 10bpp > - DSC for Input = 24bpp, output = 12bpp > > This revision addresses the review feedback on previous version of the patch > set: > https://patchwork.freedesktop.org/series/47514/ > > Anusha Srivatsa (1): > drm/i915/dsc: Add slice_row_per_frame in DSC PPS programming > > Gaurav K Singh (4): > drm/dsc: Define VESA Display Stream Compression Capabilities > drm/i915/dsc: Define & Compute VESA DSC params > drm/i915/dsc: Compute Rate Control parameters for DSC > drm/i915/dp: Enable/Disable DSC in DP Sink > > Manasi Navare (21): > drm/dp: Add DP DSC DPCD receiver capability size define and missing > SHIFT > drm/i915/dp: Cache the DP/eDP DSC DPCD register set on Hotplug/eDP > Init > drm/dp: DRM DP helper/macros to get DP sink DSC parameters > drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC > drm/i915/dp: Validate modes using max Output BPP and slice count when > DSC supported > drm/dp: Define payload size for DP SDP PPS packet > drm/dsc: Define Display Stream Compression PPS infoframe > drm/dsc: Add helpers for DSC picture parameter set infoframes > drm/i915/dp: Add DSC params and DSC config to intel_crtc_state > drm/i915/dp: Compute DSC pipe config in atomic check > drm/i915/dp: Do not enable PSR2 if DSC is enabled > drm/dsc: Define the DSC 1.1 and 1.2 Line Buffer depth constants > drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI > drm/i915/dp: Configure i915 Picture parameter Set registers during DSC > enabling > drm/i915/dp: Use the existing write_infoframe() for DSC PPS SDPs > drm/i915/dp: Populate DSC PPS SDP and send PPS infoframes > drm/i915/dp: Configure Display stream splitter registers during DSC > enable > drm/i915/dp: Disable DSC in source by disabling DSS CTL bits > drm/i915/dsc: Enable and disable appropriate power wells for VDSC > drm/i915/dsc: Add Per connector debugfs node for DSC support/enable > drm/i915/dsc: Force DSC enable if requested by IGT/userspace > > Srivatsa, Anusha (2): > drm/dsc: Define Rate Control values that do not change over > configurations > drm/i915/icl: Add Display Stream Splitter control registers > > Documentation/gpu/drm-kms-helpers.rst | 12 + > drivers/gpu/drm/Makefile|2 +- > drivers/gpu/drm/drm_dp_helper.c | 90 ++ > drivers/gpu/drm/drm_dsc.c | 223 + > drivers/gpu/drm/i915/Makefile |3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 71 +- > drivers/gpu/drm/i915/i915_drv.h |5 + > drivers/gpu/drm/i915/i915_reg.h | 35 + > drivers/gpu/drm/i915/intel_ddi.c|5 + > drivers/gpu/drm/i915/intel_display.c| 39 +- > drivers/gpu/drm/i915/intel_display.h|4 +- > drivers/gpu/drm/i915/intel_dp.c | 361 +++- > drivers/gpu/drm/i915/intel_dp_mst.c |2 +- > drivers/gpu/drm/i915/intel_drv.h| 24 + > drivers/gpu/drm/i915/intel_hdmi.c | 23 +- > drivers/gpu/drm/i915/intel_psr.c| 16 +- > drivers/gpu/drm/i915/intel_runtime_pm.c |4 +- > drivers/gpu/drm/i915/intel_vdsc.c | 1103 +++ > include/drm/drm_dp_helper.h | 40 + > include/drm/drm_dsc.h | 491 ++ > 20 files changed, 2503 insertions(+), 50 deletions(-) > create mode 100644 drivers/gpu/drm/drm_dsc.c > create mode 100644 drivers/gpu/drm/i915/intel_vdsc.c > create mode 100644 include/drm/drm_dsc.h > > -- > 2.18.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Rename crtc_idr as object_idr to KMS cleanups
Hi Shayenne, Welcome to DRM. As far as I can see you're a newcomer to kernel development, so I'd recommend watch a recent talk from Marc [1] He provides a very good introduction, both for newbies and for people willing the know the deeper reasons behind. That said, here's some suggestions: On Wed, 31 Oct 2018 at 20:58, Shayenne da Luz Moura wrote: > I'd rename the title to "drm: rename drm_mode_config::crtc_idr to object_idr" The "... as ... to KMS cleanups" translation is very strange in English. It confused me and I've read the TODO over a dozen times ;-) > Rename 'drm_mode_config.crtc_idr' as 'drm_mode_config.object_idr', > as proposed in the task description in TODO list for KMS cleanups. > Similarly here. > Signed-off-by: Shayenne da Luz Moura > --- > drivers/gpu/drm/drm_lease.c | 6 +++--- > drivers/gpu/drm/drm_mode_config.c | 4 ++-- > drivers/gpu/drm/drm_mode_object.c | 8 > 3 files changed, 9 insertions(+), 9 deletions(-) > As pointed out in the talk - always self review and ensure patches don't break things. Here, DRM doesn't build which is obviously not correct and breaks things. HTH Emil [1] https://www.youtube.com/watch?v=LIdznotOxvg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Outreachy kernel] [PATCH] drm: Rename crtc_idr as object_idr to KMS cleanups
On 10/31, Julia Lawall wrote: > > > On Wed, 31 Oct 2018, Shayenne Moura wrote: > > > On 10/31, Julia Lawall wrote: > > > > > > > > > On Wed, 31 Oct 2018, Shayenne da Luz Moura wrote: > > > > > > > Rename 'drm_mode_config.crtc_idr' as 'drm_mode_config.object_idr', > > > > as proposed in the task description in TODO list for KMS cleanups. > > > > > > Is object_idr a field that already exists? If so, "Rename" is not the > > > best choice of words. It should be something like "use the object_idr > > > field instead of the crtc_idr field" and then explain why. "task > > > description in TODO list for KMS cleanups" isn't very helpful to > > > understand why the change should be made. > > > > > > julia > > > > Hi Julia, > > > > Thank you for your review! > > > > This patch is to solve this TODO task: > > drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. > > Should be renamed to drm_mode_config.object_idr. > > > > Do you think I need to use this description in my commit message? > > That seems more helpful. > > But it seems that the name should actually be changed. Which means that > the structure definition should be changed too. Was that done? > > julia Yes, you are right. I did not add the header file. Thanks again! Shayenne ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #30 from bmil...@gmail.com --- https://github.com/yshui/compton/issues/25 - related to this issue Some tests me and others did in compton shows there is some relation with vsync issues and the HW cursor. When I turn swcursor on in xorg config both kwin compositor and compton get significantly smoother. Similar behavior is noticeable in some games for me, game stays smooth when playing with keyboard or gamepad then you move the mouse and it starts stuttering hard. With swcursor I get a bit of input lag but smoother performance overall. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #38 from bmil...@gmail.com --- (In reply to Alex Deucher from comment #36) > *** Bug 105300 has been marked as a duplicate of this bug. *** https://bugs.freedesktop.org/show_bug.cgi?id=108322 - Also related. When I tested 4.18 kernel the bug used to trigger only @>73hz after sleep/wakeup. In latest drm-next-4.21-wip triggers as soon as I switch to 75hz. If I switch back from 75hz to 60hz it keeps flickering until I manually turn my monitor off/on. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108609] vegam_smumgr.c: accessing mvdd_voltage_table.entries[] array out of bounds in function vegam_populate_smc_mvdd_table
https://bugs.freedesktop.org/show_bug.cgi?id=108609 --- Comment #2 from Robert Strube --- What repo and branch do you want the patch made against? Does AMD have it's own repo for the linux kernel, or should I go against: git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master branch? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108608] Blank screen after KMS with Linux 4.19.0 on Hawaii (R9 290)
https://bugs.freedesktop.org/show_bug.cgi?id=108608 --- Comment #3 from abortretryf...@gmail.com --- Created attachment 142312 --> https://bugs.freedesktop.org/attachment.cgi?id=142312&action=edit Full dmesg output after crash -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #37 from bmil...@gmail.com --- (In reply to Alex Deucher from comment #35) > (In reply to bmilreu from comment #34) > > The flickering issues I have with 75hz are gone after forcing profile to > > high. > > The disables mclk switching by forcing the clocks to high. What modes and > refresh rates exhibit the problem? Any resolution at 75hz. My FullHD modelines are: [ 802.898] (II) AMDGPU(0): Modeline "1920x1080"x0.0 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP) [ 802.898] (II) AMDGPU(0): Modeline "1920x1080"x0.0 170.00 1920 1928 1960 2026 1080 1105 1113 1119 +hsync +vsync (83.9 kHz e) First one is 1080p@60hz (good), second is 1080p@75hz (flickers) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108608] Blank screen after KMS with Linux 4.19.0 on Hawaii (R9 290)
https://bugs.freedesktop.org/show_bug.cgi?id=108608 --- Comment #2 from abortretryf...@gmail.com --- Sure. I'll see if I can turn off all this 'audit' nonsense that's filling dmesg with the names of files and users on my PC that I don't want all over the internet. Haven't built a kernel from source in ages and never done a git bisect on one. I'll give it a try though. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Outreachy kernel] [PATCH] drm: Rename crtc_idr as object_idr to KMS cleanups
On Wed, 31 Oct 2018, Shayenne Moura wrote: > On 10/31, Julia Lawall wrote: > > > > > > On Wed, 31 Oct 2018, Shayenne da Luz Moura wrote: > > > > > Rename 'drm_mode_config.crtc_idr' as 'drm_mode_config.object_idr', > > > as proposed in the task description in TODO list for KMS cleanups. > > > > Is object_idr a field that already exists? If so, "Rename" is not the > > best choice of words. It should be something like "use the object_idr > > field instead of the crtc_idr field" and then explain why. "task > > description in TODO list for KMS cleanups" isn't very helpful to > > understand why the change should be made. > > > > julia > > Hi Julia, > > Thank you for your review! > > This patch is to solve this TODO task: > drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. > Should be renamed to drm_mode_config.object_idr. > > Do you think I need to use this description in my commit message? That seems more helpful. But it seems that the name should actually be changed. Which means that the structure definition should be changed too. Was that done? julia > > Best, > Shayenne > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To post to this group, send email to outreachy-ker...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/20181031211935.p2pxr7fh26m5dc7v%40smtp.gmail.com. > For more options, visit https://groups.google.com/d/optout. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Outreachy kernel] [PATCH] drm: Rename crtc_idr as object_idr to KMS cleanups
On 10/31, Julia Lawall wrote: > > > On Wed, 31 Oct 2018, Shayenne da Luz Moura wrote: > > > Rename 'drm_mode_config.crtc_idr' as 'drm_mode_config.object_idr', > > as proposed in the task description in TODO list for KMS cleanups. > > Is object_idr a field that already exists? If so, "Rename" is not the > best choice of words. It should be something like "use the object_idr > field instead of the crtc_idr field" and then explain why. "task > description in TODO list for KMS cleanups" isn't very helpful to > understand why the change should be made. > > julia Hi Julia, Thank you for your review! This patch is to solve this TODO task: drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. Should be renamed to drm_mode_config.object_idr. Do you think I need to use this description in my commit message? Best, Shayenne ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Outreachy kernel] [PATCH] drm: Rename crtc_idr as object_idr to KMS cleanups
On Wed, 31 Oct 2018, Shayenne da Luz Moura wrote:
> Rename 'drm_mode_config.crtc_idr' as 'drm_mode_config.object_idr',
> as proposed in the task description in TODO list for KMS cleanups.
Is object_idr a field that already exists? If so, "Rename" is not the
best choice of words. It should be something like "use the object_idr
field instead of the crtc_idr field" and then explain why. "task
description in TODO list for KMS cleanups" isn't very helpful to
understand why the change should be made.
julia
>
> Signed-off-by: Shayenne da Luz Moura
> ---
> drivers/gpu/drm/drm_lease.c | 6 +++---
> drivers/gpu/drm/drm_mode_config.c | 4 ++--
> drivers/gpu/drm/drm_mode_object.c | 8
> 3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
> index f4702f23c11d..4f8de2217049 100644
> --- a/drivers/gpu/drm/drm_lease.c
> +++ b/drivers/gpu/drm/drm_lease.c
> @@ -222,7 +222,7 @@ static struct drm_master *drm_lease_create(struct
> drm_master *lessor, struct idr
>
> idr_for_each_entry(leases, entry, object) {
> error = 0;
> - if (!idr_find(&dev->mode_config.crtc_idr, object))
> + if (!idr_find(&dev->mode_config.object_idr, object))
> error = -ENOENT;
> else if (!_drm_lease_held_master(lessor, object))
> error = -EACCES;
> @@ -438,7 +438,7 @@ static int fill_object_idr(struct drm_device *dev,
> /*
>* We're using an IDR to hold the set of leased
>* objects, but we don't need to point at the object's
> - * data structure from the lease as the main crtc_idr
> + * data structure from the lease as the main object_idr
>* will be used to actually find that. Instead, all we
>* really want is a 'leased/not-leased' result, for
>* which any non-NULL pointer will work fine.
> @@ -679,7 +679,7 @@ int drm_mode_get_lease_ioctl(struct drm_device *dev,
>
> if (lessee->lessor == NULL)
> /* owner can use all objects */
> - object_idr = &lessee->dev->mode_config.crtc_idr;
> + object_idr = &lessee->dev->mode_config.object_idr;
> else
> /* lessee can only use allowed object */
> object_idr = &lessee->leases;
> diff --git a/drivers/gpu/drm/drm_mode_config.c
> b/drivers/gpu/drm/drm_mode_config.c
> index ee80788f2c40..ab553b6465e2 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -381,7 +381,7 @@ void drm_mode_config_init(struct drm_device *dev)
> INIT_LIST_HEAD(&dev->mode_config.property_list);
> INIT_LIST_HEAD(&dev->mode_config.property_blob_list);
> INIT_LIST_HEAD(&dev->mode_config.plane_list);
> - idr_init(&dev->mode_config.crtc_idr);
> + idr_init(&dev->mode_config.object_idr);
> idr_init(&dev->mode_config.tile_idr);
> ida_init(&dev->mode_config.connector_ida);
> spin_lock_init(&dev->mode_config.connector_list_lock);
> @@ -484,7 +484,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>
> ida_destroy(&dev->mode_config.connector_ida);
> idr_destroy(&dev->mode_config.tile_idr);
> - idr_destroy(&dev->mode_config.crtc_idr);
> + idr_destroy(&dev->mode_config.object_idr);
> drm_modeset_lock_fini(&dev->mode_config.connection_mutex);
> }
> EXPORT_SYMBOL(drm_mode_config_cleanup);
> diff --git a/drivers/gpu/drm/drm_mode_object.c
> b/drivers/gpu/drm/drm_mode_object.c
> index cd9bc0ce9be0..bb1dd46496cd 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -38,7 +38,7 @@ int __drm_mode_object_add(struct drm_device *dev, struct
> drm_mode_object *obj,
> int ret;
>
> mutex_lock(&dev->mode_config.idr_mutex);
> - ret = idr_alloc(&dev->mode_config.crtc_idr, register_obj ? obj : NULL,
> + ret = idr_alloc(&dev->mode_config.object_idr, register_obj ? obj : NULL,
> 1, 0, GFP_KERNEL);
> if (ret >= 0) {
> /*
> @@ -79,7 +79,7 @@ void drm_mode_object_register(struct drm_device *dev,
> struct drm_mode_object *obj)
> {
> mutex_lock(&dev->mode_config.idr_mutex);
> - idr_replace(&dev->mode_config.crtc_idr, obj, obj->id);
> + idr_replace(&dev->mode_config.object_idr, obj, obj->id);
> mutex_unlock(&dev->mode_config.idr_mutex);
> }
>
> @@ -99,7 +99,7 @@ void drm_mode_object_unregister(struct drm_device *dev,
> {
> mutex_lock(&dev->mode_config.idr_mutex);
> if (object->id) {
> - idr_remove(&dev->mode_config.crtc_idr, object->id);
> + idr_remove(&dev->mode_config.object_idr, object->id);
> object->id = 0;
> }
> mutex_unlock(&dev->mode_config.idr_mutex);
> @@ -131,7 +131,7 @@ struct drm_mode_object *__drm_mode_object_find(struct
> drm_device *dev,
>
[PATCH] drm: Rename crtc_idr as object_idr to KMS cleanups
Rename 'drm_mode_config.crtc_idr' as 'drm_mode_config.object_idr',
as proposed in the task description in TODO list for KMS cleanups.
Signed-off-by: Shayenne da Luz Moura
---
drivers/gpu/drm/drm_lease.c | 6 +++---
drivers/gpu/drm/drm_mode_config.c | 4 ++--
drivers/gpu/drm/drm_mode_object.c | 8
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index f4702f23c11d..4f8de2217049 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -222,7 +222,7 @@ static struct drm_master *drm_lease_create(struct
drm_master *lessor, struct idr
idr_for_each_entry(leases, entry, object) {
error = 0;
- if (!idr_find(&dev->mode_config.crtc_idr, object))
+ if (!idr_find(&dev->mode_config.object_idr, object))
error = -ENOENT;
else if (!_drm_lease_held_master(lessor, object))
error = -EACCES;
@@ -438,7 +438,7 @@ static int fill_object_idr(struct drm_device *dev,
/*
* We're using an IDR to hold the set of leased
* objects, but we don't need to point at the object's
-* data structure from the lease as the main crtc_idr
+* data structure from the lease as the main object_idr
* will be used to actually find that. Instead, all we
* really want is a 'leased/not-leased' result, for
* which any non-NULL pointer will work fine.
@@ -679,7 +679,7 @@ int drm_mode_get_lease_ioctl(struct drm_device *dev,
if (lessee->lessor == NULL)
/* owner can use all objects */
- object_idr = &lessee->dev->mode_config.crtc_idr;
+ object_idr = &lessee->dev->mode_config.object_idr;
else
/* lessee can only use allowed object */
object_idr = &lessee->leases;
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index ee80788f2c40..ab553b6465e2 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -381,7 +381,7 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(&dev->mode_config.property_list);
INIT_LIST_HEAD(&dev->mode_config.property_blob_list);
INIT_LIST_HEAD(&dev->mode_config.plane_list);
- idr_init(&dev->mode_config.crtc_idr);
+ idr_init(&dev->mode_config.object_idr);
idr_init(&dev->mode_config.tile_idr);
ida_init(&dev->mode_config.connector_ida);
spin_lock_init(&dev->mode_config.connector_list_lock);
@@ -484,7 +484,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
ida_destroy(&dev->mode_config.connector_ida);
idr_destroy(&dev->mode_config.tile_idr);
- idr_destroy(&dev->mode_config.crtc_idr);
+ idr_destroy(&dev->mode_config.object_idr);
drm_modeset_lock_fini(&dev->mode_config.connection_mutex);
}
EXPORT_SYMBOL(drm_mode_config_cleanup);
diff --git a/drivers/gpu/drm/drm_mode_object.c
b/drivers/gpu/drm/drm_mode_object.c
index cd9bc0ce9be0..bb1dd46496cd 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -38,7 +38,7 @@ int __drm_mode_object_add(struct drm_device *dev, struct
drm_mode_object *obj,
int ret;
mutex_lock(&dev->mode_config.idr_mutex);
- ret = idr_alloc(&dev->mode_config.crtc_idr, register_obj ? obj : NULL,
+ ret = idr_alloc(&dev->mode_config.object_idr, register_obj ? obj : NULL,
1, 0, GFP_KERNEL);
if (ret >= 0) {
/*
@@ -79,7 +79,7 @@ void drm_mode_object_register(struct drm_device *dev,
struct drm_mode_object *obj)
{
mutex_lock(&dev->mode_config.idr_mutex);
- idr_replace(&dev->mode_config.crtc_idr, obj, obj->id);
+ idr_replace(&dev->mode_config.object_idr, obj, obj->id);
mutex_unlock(&dev->mode_config.idr_mutex);
}
@@ -99,7 +99,7 @@ void drm_mode_object_unregister(struct drm_device *dev,
{
mutex_lock(&dev->mode_config.idr_mutex);
if (object->id) {
- idr_remove(&dev->mode_config.crtc_idr, object->id);
+ idr_remove(&dev->mode_config.object_idr, object->id);
object->id = 0;
}
mutex_unlock(&dev->mode_config.idr_mutex);
@@ -131,7 +131,7 @@ struct drm_mode_object *__drm_mode_object_find(struct
drm_device *dev,
struct drm_mode_object *obj = NULL;
mutex_lock(&dev->mode_config.idr_mutex);
- obj = idr_find(&dev->mode_config.crtc_idr, id);
+ obj = idr_find(&dev->mode_config.object_idr, id);
if (obj && type != DRM_MODE_OBJECT_ANY && obj->type != type)
obj = NULL;
if (obj && obj->id != id)
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://l
[PULL] drm-misc-next-fixes
Hi Dave,
A few patches to round out the merge window. 6/7 are from one series fixing up
things around bridge/panel.
drm-misc-next-fixes-2018-10-31:
- Properly label Innolux TV123WAM as P120ZDG-BF1 (Doug)
- Add optional delay for panels without hpd hooked up (which solves the
mystery delay for TI SN65DSI86 bridge) (Doug)
- Another 6bpc quirk for BOE panel 0x0771 (Shawn)
Cc: Doug Anderson
Cc: Lee, Shawn C
Cheers, Sean
The following changes since commit f2bfc71aee75feff33ca659322b72ffeed5a243d:
Merge tag 'drm-intel-next-fixes-2018-10-18' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-10-19 14:28:11
+1000)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-10-31
for you to fetch changes up to 8f054b6f53ff34fb787bde4c5940f86a9c175177:
drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1 (2018-10-29
11:53:28 -0400)
- Properly label Innolux TV123WAM as P120ZDG-BF1 (Doug)
- Add optional delay for panels without hpd hooked up (which solves the
mystery delay for TI SN65DSI86 bridge) (Doug)
- Another 6bpc quirk for BOE panel 0x0771 (Shawn)
Cc: Doug Anderson
Cc: Lee, Shawn C
Douglas Anderson (6):
dt-bindings: drm/panel: simple: Add no-hpd property
drm/panel: simple: Support panels with HPD where HPD isn't connected
drm/panel: simple: Add "no-hpd" delay for Innolux TV123WAM
drm/bridge: ti-sn65dsi86: Remove the mystery delay
dt-bindings: drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1
drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1
Lee, Shawn C (1):
drm/edid: Add 6 bpc quirk for BOE panel.
...nnolux,tv123wam.txt => innolux,p120zdg-bf1.txt} | 8 +++---
.../bindings/display/panel/simple-panel.txt| 3 +++
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 29 --
drivers/gpu/drm/drm_edid.c | 3 +++
drivers/gpu/drm/panel/panel-simple.c | 29 +++---
5 files changed, 47 insertions(+), 25 deletions(-)
rename Documentation/devicetree/bindings/display/panel/{innolux,tv123wam.txt
=> innolux,p120zdg-bf1.txt} (70%)
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108323] RX580 starts doing a constant noise after setting fans to a fixed value, then back to auto
https://bugs.freedesktop.org/show_bug.cgi?id=108323 --- Comment #4 from bmil...@gmail.com --- Bug also triggers using the new sysfs API's fan1_target+fan1_enable on latest drm-next-4.21-wip -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] amdgpu/test: Add illegal register and memory access test.
On 10/31/2018 03:49 PM, Alex Deucher wrote:
> On Wed, Oct 31, 2018 at 2:33 PM Andrey Grodzovsky
> wrote:
>> Illegal access will cause CP hang followed by job timeout and
>> recovery kicking in.
>> Also, disable the suite for all APU ASICs until GPU
>> reset issues for them will be resolved and GPU reset recovery
>> will be enabled by default.
>>
>> Signed-off-by: Andrey Grodzovsky
>> ---
>> tests/amdgpu/deadlock_tests.c | 118
>> +-
>> 1 file changed, 117 insertions(+), 1 deletion(-)
>>
>> diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
>> index 292ec4e..c565f7a 100644
>> --- a/tests/amdgpu/deadlock_tests.c
>> +++ b/tests/amdgpu/deadlock_tests.c
>> @@ -73,6 +73,29 @@
>> * 1 - pfp
>> */
>>
>> +#definePACKET3_WRITE_DATA 0x37
>> +#defineWRITE_DATA_DST_SEL(x) ((x) << 8)
>> + /* 0 - register
>> +* 1 - memory (sync - via GRBM)
>> +* 2 - gl2
>> +* 3 - gds
>> +* 4 - reserved
>> +* 5 - memory (async - direct)
>> +*/
>> +#defineWR_ONE_ADDR (1 << 16)
>> +#defineWR_CONFIRM (1 << 20)
>> +#defineWRITE_DATA_CACHE_POLICY(x) ((x) << 25)
>> + /* 0 - LRU
>> +* 1 - Stream
>> +*/
>> +#defineWRITE_DATA_ENGINE_SEL(x)((x) << 30)
>> + /* 0 - me
>> +* 1 - pfp
>> +* 2 - ce
>> +*/
>> +
>> +#define mmVM_CONTEXT0_PAGE_TABLE_BASE_ADDR
>> 0x54f
>> +
>> static amdgpu_device_handle device_handle;
>> static uint32_t major_version;
>> static uint32_t minor_version;
>> @@ -85,6 +108,8 @@ int use_uc_mtype = 0;
>> static void amdgpu_deadlock_helper(unsigned ip_type);
>> static void amdgpu_deadlock_gfx(void);
>> static void amdgpu_deadlock_compute(void);
>> +static void amdgpu_illegal_reg_access();
>> +static void amdgpu_illegal_mem_access();
>>
>> CU_BOOL suite_deadlock_tests_enable(void)
>> {
>> @@ -94,7 +119,9 @@ CU_BOOL suite_deadlock_tests_enable(void)
>> &minor_version,
>> &device_handle))
>> return CU_FALSE;
>>
>> - if (device_handle->info.family_id == AMDGPU_FAMILY_SI) {
>> + if (device_handle->info.family_id == AMDGPU_FAMILY_SI ||
> Add AMDGPU_FAMILY_KV for CI based APUs as well.
>
>
>> + device_handle->info.family_id == AMDGPU_FAMILY_CZ ||
>> + device_handle->info.family_id == AMDGPU_FAMILY_RV) {
>> printf("\n\nCurrently hangs the CP on this ASIC, deadlock
>> suite disabled\n");
>> enable = CU_FALSE;
>> }
>> @@ -140,6 +167,8 @@ int suite_deadlock_tests_clean(void)
>> CU_TestInfo deadlock_tests[] = {
>> { "gfx ring block test", amdgpu_deadlock_gfx },
>> { "compute ring block test", amdgpu_deadlock_compute },
>> + { "illegal reg access test", amdgpu_illegal_reg_access },
>> + { "illegal mem access test", amdgpu_illegal_mem_access },
> Won't this illegal mem access just result in a page fault? Is the
> idea to set vm_debug to force an MC halt to test reset?
>
> Alex
For this test to hang the CP amdgpu.vm_fault_stop=2 needs to be set.
Andrey
>
>> CU_TEST_INFO_NULL,
>> };
>>
>> @@ -257,3 +286,90 @@ static void amdgpu_deadlock_helper(unsigned ip_type)
>> r = amdgpu_cs_ctx_free(context_handle);
>> CU_ASSERT_EQUAL(r, 0);
>> }
>> +
>> +static void bad_access_helper(int reg_access)
>> +{
>> + amdgpu_context_handle context_handle;
>> + amdgpu_bo_handle ib_result_handle;
>> + void *ib_result_cpu;
>> + uint64_t ib_result_mc_address;
>> + struct amdgpu_cs_request ibs_request;
>> + struct amdgpu_cs_ib_info ib_info;
>> + struct amdgpu_cs_fence fence_status;
>> + uint32_t expired;
>> + int i, r;
>> + amdgpu_bo_list_handle bo_list;
>> + amdgpu_va_handle va_handle;
>> +
>> + r = amdgpu_cs_ctx_create(device_handle, &context_handle);
>> + CU_ASSERT_EQUAL(r, 0);
>> +
>> + r = amdgpu_bo_alloc_and_map_raw(device_handle, 4096, 4096,
>> + AMDGPU_GEM_DOMAIN_GTT, 0, 0,
>> + &ib_result_handle,
>> &ib_result_cpu,
>> +
>> &ib_result_mc_address, &va_handle);
>> + CU_ASSERT_EQUAL(r, 0);
>> +
>> + r = amdgpu_get_bo_list(device_handle, ib_result_handle, NULL,
>> + &bo_list);
>> + CU_ASSERT_EQUAL(r, 0);
>> +
>> + ptr = ib_result_cpu;
>> + i = 0;
>> +
>> + ptr[i++]
Re: [PATCH libdrm] amdgpu/test: Add illegal register and memory access test.
On 10/31/2018 03:49 PM, Alex Deucher wrote:
> On Wed, Oct 31, 2018 at 2:33 PM Andrey Grodzovsky
> wrote:
>> Illegal access will cause CP hang followed by job timeout and
>> recovery kicking in.
>> Also, disable the suite for all APU ASICs until GPU
>> reset issues for them will be resolved and GPU reset recovery
>> will be enabled by default.
>>
>> Signed-off-by: Andrey Grodzovsky
>> ---
>> tests/amdgpu/deadlock_tests.c | 118
>> +-
>> 1 file changed, 117 insertions(+), 1 deletion(-)
>>
>> diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
>> index 292ec4e..c565f7a 100644
>> --- a/tests/amdgpu/deadlock_tests.c
>> +++ b/tests/amdgpu/deadlock_tests.c
>> @@ -73,6 +73,29 @@
>> * 1 - pfp
>> */
>>
>> +#definePACKET3_WRITE_DATA 0x37
>> +#defineWRITE_DATA_DST_SEL(x) ((x) << 8)
>> + /* 0 - register
>> +* 1 - memory (sync - via GRBM)
>> +* 2 - gl2
>> +* 3 - gds
>> +* 4 - reserved
>> +* 5 - memory (async - direct)
>> +*/
>> +#defineWR_ONE_ADDR (1 << 16)
>> +#defineWR_CONFIRM (1 << 20)
>> +#defineWRITE_DATA_CACHE_POLICY(x) ((x) << 25)
>> + /* 0 - LRU
>> +* 1 - Stream
>> +*/
>> +#defineWRITE_DATA_ENGINE_SEL(x)((x) << 30)
>> + /* 0 - me
>> +* 1 - pfp
>> +* 2 - ce
>> +*/
>> +
>> +#define mmVM_CONTEXT0_PAGE_TABLE_BASE_ADDR
>> 0x54f
>> +
>> static amdgpu_device_handle device_handle;
>> static uint32_t major_version;
>> static uint32_t minor_version;
>> @@ -85,6 +108,8 @@ int use_uc_mtype = 0;
>> static void amdgpu_deadlock_helper(unsigned ip_type);
>> static void amdgpu_deadlock_gfx(void);
>> static void amdgpu_deadlock_compute(void);
>> +static void amdgpu_illegal_reg_access();
>> +static void amdgpu_illegal_mem_access();
>>
>> CU_BOOL suite_deadlock_tests_enable(void)
>> {
>> @@ -94,7 +119,9 @@ CU_BOOL suite_deadlock_tests_enable(void)
>> &minor_version,
>> &device_handle))
>> return CU_FALSE;
>>
>> - if (device_handle->info.family_id == AMDGPU_FAMILY_SI) {
>> + if (device_handle->info.family_id == AMDGPU_FAMILY_SI ||
> Add AMDGPU_FAMILY_KV for CI based APUs as well.
>
>
>> + device_handle->info.family_id == AMDGPU_FAMILY_CZ ||
>> + device_handle->info.family_id == AMDGPU_FAMILY_RV) {
>> printf("\n\nCurrently hangs the CP on this ASIC, deadlock
>> suite disabled\n");
>> enable = CU_FALSE;
>> }
>> @@ -140,6 +167,8 @@ int suite_deadlock_tests_clean(void)
>> CU_TestInfo deadlock_tests[] = {
>> { "gfx ring block test", amdgpu_deadlock_gfx },
>> { "compute ring block test", amdgpu_deadlock_compute },
>> + { "illegal reg access test", amdgpu_illegal_reg_access },
>> + { "illegal mem access test", amdgpu_illegal_mem_access },
> Won't this illegal mem access just result in a page fault? Is the
> idea to set vm_debug to force an MC halt to test reset?
>
> Alex
For this once to hang to CP amdgpu.vm_fault_stop=2 needs to be set.
Andrey
>
>> CU_TEST_INFO_NULL,
>> };
>>
>> @@ -257,3 +286,90 @@ static void amdgpu_deadlock_helper(unsigned ip_type)
>> r = amdgpu_cs_ctx_free(context_handle);
>> CU_ASSERT_EQUAL(r, 0);
>> }
>> +
>> +static void bad_access_helper(int reg_access)
>> +{
>> + amdgpu_context_handle context_handle;
>> + amdgpu_bo_handle ib_result_handle;
>> + void *ib_result_cpu;
>> + uint64_t ib_result_mc_address;
>> + struct amdgpu_cs_request ibs_request;
>> + struct amdgpu_cs_ib_info ib_info;
>> + struct amdgpu_cs_fence fence_status;
>> + uint32_t expired;
>> + int i, r;
>> + amdgpu_bo_list_handle bo_list;
>> + amdgpu_va_handle va_handle;
>> +
>> + r = amdgpu_cs_ctx_create(device_handle, &context_handle);
>> + CU_ASSERT_EQUAL(r, 0);
>> +
>> + r = amdgpu_bo_alloc_and_map_raw(device_handle, 4096, 4096,
>> + AMDGPU_GEM_DOMAIN_GTT, 0, 0,
>> + &ib_result_handle,
>> &ib_result_cpu,
>> +
>> &ib_result_mc_address, &va_handle);
>> + CU_ASSERT_EQUAL(r, 0);
>> +
>> + r = amdgpu_get_bo_list(device_handle, ib_result_handle, NULL,
>> + &bo_list);
>> + CU_ASSERT_EQUAL(r, 0);
>> +
>> + ptr = ib_result_cpu;
>> + i = 0;
>> +
>> + ptr[i++]
[Bug 108613] amdgpu.dc=1 + xf86-video-amdgpu: changing to a GPU upscaling resolution resets pp_dpm_mclk
https://bugs.freedesktop.org/show_bug.cgi?id=108613 Bug ID: 108613 Summary: amdgpu.dc=1 + xf86-video-amdgpu: changing to a GPU upscaling resolution resets pp_dpm_mclk Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: tempel.jul...@gmail.com My display doesn't offer upscaling resolutions. However, amdgpu.dc=1 + xf86-video-amdgpu does. When I change the resolution from native (2560x1440) to one of those automatically offered upscaling resolutions (e.g. 1920x1080), the value in "/sys/class/drm/card0/device/pp_dpm_mclk" gets set to default. I changed it before like this (to prevent flickering with 75Hz with my display): echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk The VRAM runs with its maximum clock as long as I don't change resolution. When I change the resolution like described above, the VRAM clock again gets dynamically changed according to load, which introduces nasty flickering in my case. The desired behavior would be that the change done to pp_dpm_mclk remains untouched when changing to a GPU upscaling resolution. I haven't checked if pp_dpm_sclk is affected as well. Other powerplay/overdrive/fan settings remain untouched by resolution change. Using latest linux-amd-staging-drm-next-wip-git kernel. Xorg session -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108606] Raven Ridge: constant lockups since latest pull from Linus
https://bugs.freedesktop.org/show_bug.cgi?id=108606 --- Comment #8 from Samantha McVey --- On the newest firmware, the issue is present, yes. Output of /sys/kernel/debug/dri/0/amdgpu_firmware_info VCE feature version: 0, firmware version: 0x UVD feature version: 0, firmware version: 0x MC feature version: 0, firmware version: 0x ME feature version: 42, firmware version: 0x009c PFP feature version: 42, firmware version: 0x00b1 CE feature version: 42, firmware version: 0x004d RLC feature version: 1, firmware version: 0x0213 RLC SRLC feature version: 1, firmware version: 0x0001 RLC SRLG feature version: 1, firmware version: 0x0001 RLC SRLS feature version: 1, firmware version: 0x0001 MEC feature version: 42, firmware version: 0x0192 MEC2 feature version: 42, firmware version: 0x0192 SOS feature version: 0, firmware version: 0x ASD feature version: 0, firmware version: 0x0017ba78 SMC feature version: 0, firmware version: 0x1e44 SDMA0 feature version: 41, firmware version: 0x00a8 VCN feature version: 0, firmware version: 0x01004912 DMCU feature version: 0, firmware version: 0x0001 VBIOS version: 113-RAVEN-110 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108606] Raven Ridge: constant lockups since latest pull from Linus
https://bugs.freedesktop.org/show_bug.cgi?id=108606 --- Comment #7 from Alex Deucher --- (In reply to Samantha McVey from comment #6) > Yeah I have the latest linux-firmware installed. I also have raven_dmcu.bin > which just was added so I'm certain I have the latest, since I installed the > git version 3 days ago (when I read that Raven Ridge had its firmware > updated). So to confirm, the newest firmware did not help? Please provide the output of /sys/kernel/debug/dri/0/amdgpu_firmware_info -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] amdgpu/test: Add illegal register and memory access test.
On Wed, Oct 31, 2018 at 2:33 PM Andrey Grodzovsky
wrote:
>
> Illegal access will cause CP hang followed by job timeout and
> recovery kicking in.
> Also, disable the suite for all APU ASICs until GPU
> reset issues for them will be resolved and GPU reset recovery
> will be enabled by default.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> tests/amdgpu/deadlock_tests.c | 118
> +-
> 1 file changed, 117 insertions(+), 1 deletion(-)
>
> diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
> index 292ec4e..c565f7a 100644
> --- a/tests/amdgpu/deadlock_tests.c
> +++ b/tests/amdgpu/deadlock_tests.c
> @@ -73,6 +73,29 @@
> * 1 - pfp
> */
>
> +#definePACKET3_WRITE_DATA 0x37
> +#defineWRITE_DATA_DST_SEL(x) ((x) << 8)
> + /* 0 - register
> +* 1 - memory (sync - via GRBM)
> +* 2 - gl2
> +* 3 - gds
> +* 4 - reserved
> +* 5 - memory (async - direct)
> +*/
> +#defineWR_ONE_ADDR (1 << 16)
> +#defineWR_CONFIRM (1 << 20)
> +#defineWRITE_DATA_CACHE_POLICY(x) ((x) << 25)
> + /* 0 - LRU
> +* 1 - Stream
> +*/
> +#defineWRITE_DATA_ENGINE_SEL(x)((x) << 30)
> + /* 0 - me
> +* 1 - pfp
> +* 2 - ce
> +*/
> +
> +#define mmVM_CONTEXT0_PAGE_TABLE_BASE_ADDR
>0x54f
> +
> static amdgpu_device_handle device_handle;
> static uint32_t major_version;
> static uint32_t minor_version;
> @@ -85,6 +108,8 @@ int use_uc_mtype = 0;
> static void amdgpu_deadlock_helper(unsigned ip_type);
> static void amdgpu_deadlock_gfx(void);
> static void amdgpu_deadlock_compute(void);
> +static void amdgpu_illegal_reg_access();
> +static void amdgpu_illegal_mem_access();
>
> CU_BOOL suite_deadlock_tests_enable(void)
> {
> @@ -94,7 +119,9 @@ CU_BOOL suite_deadlock_tests_enable(void)
> &minor_version, &device_handle))
> return CU_FALSE;
>
> - if (device_handle->info.family_id == AMDGPU_FAMILY_SI) {
> + if (device_handle->info.family_id == AMDGPU_FAMILY_SI ||
Add AMDGPU_FAMILY_KV for CI based APUs as well.
> + device_handle->info.family_id == AMDGPU_FAMILY_CZ ||
> + device_handle->info.family_id == AMDGPU_FAMILY_RV) {
> printf("\n\nCurrently hangs the CP on this ASIC, deadlock
> suite disabled\n");
> enable = CU_FALSE;
> }
> @@ -140,6 +167,8 @@ int suite_deadlock_tests_clean(void)
> CU_TestInfo deadlock_tests[] = {
> { "gfx ring block test", amdgpu_deadlock_gfx },
> { "compute ring block test", amdgpu_deadlock_compute },
> + { "illegal reg access test", amdgpu_illegal_reg_access },
> + { "illegal mem access test", amdgpu_illegal_mem_access },
Won't this illegal mem access just result in a page fault? Is the
idea to set vm_debug to force an MC halt to test reset?
Alex
> CU_TEST_INFO_NULL,
> };
>
> @@ -257,3 +286,90 @@ static void amdgpu_deadlock_helper(unsigned ip_type)
> r = amdgpu_cs_ctx_free(context_handle);
> CU_ASSERT_EQUAL(r, 0);
> }
> +
> +static void bad_access_helper(int reg_access)
> +{
> + amdgpu_context_handle context_handle;
> + amdgpu_bo_handle ib_result_handle;
> + void *ib_result_cpu;
> + uint64_t ib_result_mc_address;
> + struct amdgpu_cs_request ibs_request;
> + struct amdgpu_cs_ib_info ib_info;
> + struct amdgpu_cs_fence fence_status;
> + uint32_t expired;
> + int i, r;
> + amdgpu_bo_list_handle bo_list;
> + amdgpu_va_handle va_handle;
> +
> + r = amdgpu_cs_ctx_create(device_handle, &context_handle);
> + CU_ASSERT_EQUAL(r, 0);
> +
> + r = amdgpu_bo_alloc_and_map_raw(device_handle, 4096, 4096,
> + AMDGPU_GEM_DOMAIN_GTT, 0, 0,
> + &ib_result_handle,
> &ib_result_cpu,
> +
> &ib_result_mc_address, &va_handle);
> + CU_ASSERT_EQUAL(r, 0);
> +
> + r = amdgpu_get_bo_list(device_handle, ib_result_handle, NULL,
> + &bo_list);
> + CU_ASSERT_EQUAL(r, 0);
> +
> + ptr = ib_result_cpu;
> + i = 0;
> +
> + ptr[i++] = PACKET3(PACKET3_WRITE_DATA, 3);
> + ptr[i++] = (reg_access ? WRITE_DATA_DST_SEL(0) :
> WRITE_DATA_DST_SEL(5))| WR_CONFIRM;
> + ptr[i++] = reg_access ? mmVM_CONTEXT0_PAGE_TABLE_BASE_ADDR :
> 0xdeadbee0;
> + ptr[i++] = 0;
> + ptr[i++] = 0xdeadbeef;
> +
>
[Bug 108606] Raven Ridge: constant lockups since latest pull from Linus
https://bugs.freedesktop.org/show_bug.cgi?id=108606 --- Comment #6 from Samantha McVey --- Yeah I have the latest linux-firmware installed. I also have raven_dmcu.bin which just was added so I'm certain I have the latest, since I installed the git version 3 days ago (when I read that Raven Ridge had its firmware updated). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock
https://bugs.freedesktop.org/show_bug.cgi?id=105300 Alex Deucher changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #16 from Alex Deucher --- *** This bug has been marked as a duplicate of bug 102646 *** -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 Alex Deucher changed: What|Removed |Added CC||tempel.jul...@gmail.com --- Comment #36 from Alex Deucher --- *** Bug 105300 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108606] Raven Ridge: constant lockups since latest pull from Linus
https://bugs.freedesktop.org/show_bug.cgi?id=108606 --- Comment #5 from Alex Deucher --- Does the latest firmware from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git fix the issue as well? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108272] [polaris10] opencl-mesa: Anything using OpenCL segfaults, XFX Radeon RX 580
https://bugs.freedesktop.org/show_bug.cgi?id=108272 --- Comment #10 from Juan A. Suarez --- Mesa 18.2.4 has been released. Could you check if that version fixes this bug? If so, please, close it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock
https://bugs.freedesktop.org/show_bug.cgi?id=105300 --- Comment #15 from tempel.jul...@gmail.com --- Issue still exists with current 4.21-wip kernel. As a workaround, it's enough to force the highest VRAM clock state (Forcing higher clocks on the GPU itself is not necessary.): echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk Odd side note: It doesn't help to overclock the lower VRAM pstates to the same clocks and voltages as the highest one. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2] MAINTAINERS: Add entry for VKMS
On 2018-10-21 9:27 p.m., Rodrigo Siqueira wrote: > Add maintainers and reviewers for VKMS driver > > Signed-off-by: Rodrigo Siqueira Acked-by: Harry Wentland Harry > --- > Changes in v2: > - Insert the section in alphabetical order > > MAINTAINERS | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 39c3f6682ace..56572f0968ce 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4733,6 +4733,16 @@ S: Odd Fixes > F: drivers/gpu/drm/udl/ > T: git git://anongit.freedesktop.org/drm/drm-misc > > +DRM DRIVER FOR VIRTUAL KERNEL MODESETTING (VKMS) > +M: Rodrigo Siqueira > +R: Haneen Mohammed > +R: Daniel Vetter > +T: git git://anongit.freedesktop.org/drm/drm-misc > +S: Maintained > +L: dri-devel@lists.freedesktop.org > +F: drivers/gpu/drm/vkms/ > +F: Documentation/gpu/vkms.rst > + > DRM DRIVER FOR VMWARE VIRTUAL GPU > M: "VMware Graphics" > M: Sinclair Yeh > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] fbdev changes for v4.20
On Wed, Oct 31, 2018 at 7:31 AM Bartlomiej Zolnierkiewicz wrote: > > Please pull fbdev changes for v4.20. No major changes to the subsystem > itself, mainly fb drivers fixes & cleanups (atyfb & udlfb updates stand > out from the rest) + removal of no longer needed old clps711xfb driver. Pulled, Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v5 5/5] drm/tinydrm: Switch from CMA to shmem buffers
Den 29.10.2018 10.07, skrev Daniel Vetter: On Sun, Oct 28, 2018 at 09:46:43PM +0100, Noralf Trønnes wrote: Den 28.10.2018 21.21, skrev David Lechner: On 10/26/2018 05:38 PM, Noralf Trønnes wrote: Den 17.10.2018 15.04, skrev Noralf Trønnes: This move makes tinydrm useful for more drivers. tinydrm doesn't need continuous memory, but at the time it was convenient to use the CMA library. The spi core can do dma on is_vmalloc() addresses making this possible. Cc: David Lechner Signed-off-by: Noralf Trønnes Acked-by: David Lechner Tested-by: David Lechner --- David, FYI This series is scratched. See the shmem helper patch thread for details. Yes, I saw that. Thank you. I don't suppose there is a way to configure the DMA controller to do the byte swapping? Not that I know of. "Proper" SPI hw can do 16-bit transfers and for them there's no problem. The DMA capable SPI block on the Pi can only do 8-bit, hence the swapping. But that wasn't the problem, the byteswapping actually papered over the problem. I'm no -mm expert so I don't know why the problem onyl showed up when using the virtual address of the buffer used by fbcon and not on mmap'ed fbdev as Daniel suggested would happen. Hm, I missed that detail. This sounds like one of the mappings ended up being write-combining (which avoids all the issues with dirty cpu cache lines), while the broken one was not. Or we ended up with a flush somewhere by accident. Either way shmem not being coherent is a problem on the Pi, even though I expected the DMA streaming API called by the spi core to flush "things". It should do that for you. At least if it's using dma_map/unmap_sg and friends. I just watched a talk by the i2c maintainer about his challenges with supporting DMA buffers and DMA only host controllers: DMA Safety in Buffers for Linux Kernel Device Drivers - Wolfram Sang https://www.youtube.com/watch?v=JDwaMClvV-s In passing he mentions this from Documentation/spi/spi-summary: - I/O buffers use the usual Linux rules, and must be DMA-safe. You'd normally allocate them from the heap or free page pool. So how can the SPI core ensure DMA safety for its DMA mapping of the underlying pages of virtual addresses? This is what I relied on when doing the shmem helper. Doing further digging I came across these: Vignesh R says: https://www.spinics.net/lists/kernel/msg2687381.html SPI core does try to DMA into underlying physical pages of vmalloc'd buffer. But this has two problems: 1. Does not work well with VIVT caches[1]. 2. On ARM LPAE systems, vmalloc'd buffers can be from highmem region that are not addressable using 32 bit addresses and is backed by LPAE. So, a 32 bit DMA cannot access these buffers. Both these issues lead to random crashes and errors with UBIFS and JFFS2 flash file systems which this patch series tries to address using bounce buffer [1] https://patchwork.kernel.org/patch/9579553/ Russel King provides some more info: https://patchwork.kernel.org/patch/9579553/#20139929 SPI is rather another special case - rather than SPI following the established mechanism of passing data references via scatterlists or similar, it also passes them via virtual addresses, which means SPI can directly access the vmalloc area when performing PIO. This really makes the problem more complex, because it means that if you do have a SPI driver that does that, it's going to be reading/writing direct from vmalloc space. That's not a problem as long as the data is only accessed via vmalloc space, but it will definitely go totally wrong if the data is subsequently mapped into userspace. So even if I could make the shmem helper work on the Raspberry Pi with tinydrm and SPI, it probably wouldn't work on all systems. I also learned that using devm_kmalloc, which tinydrm does for a tx buffer, is not DMA safe because it prepends a devres struct to the buffer making the buffer itself not cache line aligned. [Question] devm_kmalloc() for DMA ? https://linux-arm-kernel.infradead.narkive.com/vyJqy0RQ/question-devm-kmalloc-for-dma I'll turn this into a plain kmalloc when I return to my work on supporting device unplug which will deal with device resource lifetime issues. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] amdgpu/test: Add illegal register and memory access test.
Illegal access will cause CP hang followed by job timeout and
recovery kicking in.
Also, disable the suite for all APU ASICs until GPU
reset issues for them will be resolved and GPU reset recovery
will be enabled by default.
Signed-off-by: Andrey Grodzovsky
---
tests/amdgpu/deadlock_tests.c | 118 +-
1 file changed, 117 insertions(+), 1 deletion(-)
diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
index 292ec4e..c565f7a 100644
--- a/tests/amdgpu/deadlock_tests.c
+++ b/tests/amdgpu/deadlock_tests.c
@@ -73,6 +73,29 @@
* 1 - pfp
*/
+#definePACKET3_WRITE_DATA 0x37
+#defineWRITE_DATA_DST_SEL(x) ((x) << 8)
+ /* 0 - register
+* 1 - memory (sync - via GRBM)
+* 2 - gl2
+* 3 - gds
+* 4 - reserved
+* 5 - memory (async - direct)
+*/
+#defineWR_ONE_ADDR (1 << 16)
+#defineWR_CONFIRM (1 << 20)
+#defineWRITE_DATA_CACHE_POLICY(x) ((x) << 25)
+ /* 0 - LRU
+* 1 - Stream
+*/
+#defineWRITE_DATA_ENGINE_SEL(x)((x) << 30)
+ /* 0 - me
+* 1 - pfp
+* 2 - ce
+*/
+
+#define mmVM_CONTEXT0_PAGE_TABLE_BASE_ADDR
0x54f
+
static amdgpu_device_handle device_handle;
static uint32_t major_version;
static uint32_t minor_version;
@@ -85,6 +108,8 @@ int use_uc_mtype = 0;
static void amdgpu_deadlock_helper(unsigned ip_type);
static void amdgpu_deadlock_gfx(void);
static void amdgpu_deadlock_compute(void);
+static void amdgpu_illegal_reg_access();
+static void amdgpu_illegal_mem_access();
CU_BOOL suite_deadlock_tests_enable(void)
{
@@ -94,7 +119,9 @@ CU_BOOL suite_deadlock_tests_enable(void)
&minor_version, &device_handle))
return CU_FALSE;
- if (device_handle->info.family_id == AMDGPU_FAMILY_SI) {
+ if (device_handle->info.family_id == AMDGPU_FAMILY_SI ||
+ device_handle->info.family_id == AMDGPU_FAMILY_CZ ||
+ device_handle->info.family_id == AMDGPU_FAMILY_RV) {
printf("\n\nCurrently hangs the CP on this ASIC, deadlock suite
disabled\n");
enable = CU_FALSE;
}
@@ -140,6 +167,8 @@ int suite_deadlock_tests_clean(void)
CU_TestInfo deadlock_tests[] = {
{ "gfx ring block test", amdgpu_deadlock_gfx },
{ "compute ring block test", amdgpu_deadlock_compute },
+ { "illegal reg access test", amdgpu_illegal_reg_access },
+ { "illegal mem access test", amdgpu_illegal_mem_access },
CU_TEST_INFO_NULL,
};
@@ -257,3 +286,90 @@ static void amdgpu_deadlock_helper(unsigned ip_type)
r = amdgpu_cs_ctx_free(context_handle);
CU_ASSERT_EQUAL(r, 0);
}
+
+static void bad_access_helper(int reg_access)
+{
+ amdgpu_context_handle context_handle;
+ amdgpu_bo_handle ib_result_handle;
+ void *ib_result_cpu;
+ uint64_t ib_result_mc_address;
+ struct amdgpu_cs_request ibs_request;
+ struct amdgpu_cs_ib_info ib_info;
+ struct amdgpu_cs_fence fence_status;
+ uint32_t expired;
+ int i, r;
+ amdgpu_bo_list_handle bo_list;
+ amdgpu_va_handle va_handle;
+
+ r = amdgpu_cs_ctx_create(device_handle, &context_handle);
+ CU_ASSERT_EQUAL(r, 0);
+
+ r = amdgpu_bo_alloc_and_map_raw(device_handle, 4096, 4096,
+ AMDGPU_GEM_DOMAIN_GTT, 0, 0,
+ &ib_result_handle,
&ib_result_cpu,
+ &ib_result_mc_address,
&va_handle);
+ CU_ASSERT_EQUAL(r, 0);
+
+ r = amdgpu_get_bo_list(device_handle, ib_result_handle, NULL,
+ &bo_list);
+ CU_ASSERT_EQUAL(r, 0);
+
+ ptr = ib_result_cpu;
+ i = 0;
+
+ ptr[i++] = PACKET3(PACKET3_WRITE_DATA, 3);
+ ptr[i++] = (reg_access ? WRITE_DATA_DST_SEL(0) :
WRITE_DATA_DST_SEL(5))| WR_CONFIRM;
+ ptr[i++] = reg_access ? mmVM_CONTEXT0_PAGE_TABLE_BASE_ADDR : 0xdeadbee0;
+ ptr[i++] = 0;
+ ptr[i++] = 0xdeadbeef;
+
+ for (; i < 16; ++i)
+ ptr[i] = 0x1000;
+
+ memset(&ib_info, 0, sizeof(struct amdgpu_cs_ib_info));
+ ib_info.ib_mc_address = ib_result_mc_address;
+ ib_info.size = 16;
+
+ memset(&ibs_request, 0, sizeof(struct amdgpu_cs_request));
+ ibs_request.ip_type = AMDGPU_HW_IP_GFX;
+ ibs_request.ring = 0;
+ ibs_request.number_of_ibs = 1;
+ ibs_request.ibs = &ib_info;
+ ibs_request.resources = bo_list;
+
Re: [PATCH v4 3/4] drm: Document variable refresh properties
On 10/31/18 12:20 PM, Michel Dänzer wrote: > On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote: >> On 10/31/18 10:12 AM, Michel Dänzer wrote: >>> On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote: On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote: > > I understand the issue you're describing now. The timestamp is supposed > to signify the end of the current vblank. The call to get scanout > position is supposed to return the number of lines until scanout (a > negative value) or the number of lines since the next scanout began (a > positive value). > > The amdgpu driver calculates the number of lines based on a hardware > register status position which returns an increasing value from 0 that > indicates the current vpos/hpos for the display. > > For any vpos below vbl_start we know the value is correct since the next > vblank hasn't begun yet. But for anythign about vbl_start it's probably > wrong since it applies a corrective offset based on the fixed value of > crtc_vtotal. It's even worse when the value is above crtc_vtotal since > it'll be calculating the number of lines since the last scanout since > it'll be a positive value. > > So the issue becomes determining when the vfront porch will end. > > When the flip address gets written the vfront porch will end at the > start of the next line leaving only the back porch plus part of the > line. But we don't know when the flip will occur, if at all. It hasn't > occurred yet in this case. > > Waiting for the wrap around to 0 might be the best choice here since > there's no guarantee the flip will occur. I put some more thought into this and I don't think this is as bad as I had originally thought. I think the vblank timestamp is supposed to be for the first active pixel of the next scanout. The usage of which is for clients to time their content/animation/etc. The client likely doesn't care when they issue their flip, just that their content is matched for that vblank timestamp. The fixed refresh model works really well for that kind of application. Utilizing variable refresh rate would be a mistake in that case since the client would then have to time based on when they flip which is a lot harder to "predict" precisely. >>> >>> It's only a "mistake" as long as the timestamps are misleading. :) As >>> discussed before, accurate presentation timestamps are one requirement >>> for achieving perfectly smooth animation. >> >> For most 3D games the game world/rendering can advance by an arbitrary >> timestep - and faster will be smoother, which is what the native mode >> would give you. >> >> For fixed interval content/animation where you can't do that variable >> refresh rate could vastly improve the output. But like discussed before >> that would need a way to specify the interval/presentation timestamp to >> control that front porch duration. The timestamp will be misleading in >> any other case. > > I don't agree that an accurate timestamp can ever be more "misleading" > than an inaccurate one. But yeah, accurate timestamps and time-based > presentation are two sides of the same coin which can buy the holy grail > of perfectly smooth animation. :) > > I did some more investigation into when amdgpu gets the scanout position and what values we get back out of it. The timestamp is updated shortly after the crtc irq vblank which is typically within a few lines of vbl_start. This makes sense, since we can provide the prediction timestamp early. Waiting for the vblank to wrap around to 0 doesn't really make sense here since that would mean we already hit timeout or the flip occurred >>> >>> Sounds like you're mixing up the two cases of "actual" vblank events >>> (triggered by the "vblank" interrupt => drm_(crtc_)handle_vblank) and >>> flip completion events (triggered by the PFLIP interrupt with our >>> hardware => drm_crtc_send_vblank_event). >>> >>> Actual vblank events need to be delivered to userspace at the start of >>> vblank, so we indeed can't wait until the timestamp is accurate for >>> them. We just need to document the exact semantics of their timestamp >>> with VRR. >>> >>> For page flip completion events though, the timestamp needs to be >>> accurate and correspond to when the flipped frame starts being scanned >>> out, otherwise we'll surely break at least some userspace relying on >>> this information. >>> >> Yeah, I was. I guess what's sent is the estimated vblank timestamp >> calculated at the start of the interrupt. > > s/interrupt/vblank/, yeah. > > >> And since that's just a guess rather than what's actually going to >> happen it's going to be wrong in a lot of cases. >> >> I could see the wrap-around method working if the vblank timestamp was >> somehow updated in amdgpu or in drm_crtc_send_vblank_event. > > DC alr
[radeon-alex:drm-next-4.21-wip 113/125] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_abm.c:86 calculate_16_bit_backlight_from_pwm() warn: should 'bl_pwm << (1 + bl_int_count)' be a 64 bit type?
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.21-wip
head: 6830ffcb15a5bae3f031734b75b11a5f489a52bf
commit: 6459eb8ee95150ffbdfcd0c9325945be80f98cf8 [113/125] drm/amd/display:
Expand dc to use 16.16 bit backlight
smatch warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_abm.c:86
calculate_16_bit_backlight_from_pwm() warn: should 'bl_pwm << (1 +
bl_int_count)' be a 64 bit type?
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git remote update radeon-alex
git checkout 6459eb8ee95150ffbdfcd0c9325945be80f98cf8
vim +86 drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_abm.c
aa7397df Amy Zhang 2017-05-12 55
5e7773a2 Anthony Koo2017-01-23 56
6459eb8e Anthony Koo2018-10-12 57 static unsigned int
calculate_16_bit_backlight_from_pwm(struct dce_abm *abm_dce)
5e7773a2 Anthony Koo2017-01-23 58 {
5e7773a2 Anthony Koo2017-01-23 59 uint64_t current_backlight;
5e7773a2 Anthony Koo2017-01-23 60 uint32_t round_result;
5e7773a2 Anthony Koo2017-01-23 61 uint32_t pwm_period_cntl,
bl_period, bl_int_count;
5e7773a2 Anthony Koo2017-01-23 62 uint32_t bl_pwm_cntl, bl_pwm,
fractional_duty_cycle_en;
5e7773a2 Anthony Koo2017-01-23 63 uint32_t bl_period_mask,
bl_pwm_mask;
5e7773a2 Anthony Koo2017-01-23 64
5e7773a2 Anthony Koo2017-01-23 65 pwm_period_cntl =
REG_READ(BL_PWM_PERIOD_CNTL);
5e7773a2 Anthony Koo2017-01-23 66 REG_GET(BL_PWM_PERIOD_CNTL,
BL_PWM_PERIOD, &bl_period);
5e7773a2 Anthony Koo2017-01-23 67 REG_GET(BL_PWM_PERIOD_CNTL,
BL_PWM_PERIOD_BITCNT, &bl_int_count);
5e7773a2 Anthony Koo2017-01-23 68
5e7773a2 Anthony Koo2017-01-23 69 bl_pwm_cntl =
REG_READ(BL_PWM_CNTL);
5e7773a2 Anthony Koo2017-01-23 70 REG_GET(BL_PWM_CNTL,
BL_ACTIVE_INT_FRAC_CNT, (uint32_t *)(&bl_pwm));
5e7773a2 Anthony Koo2017-01-23 71 REG_GET(BL_PWM_CNTL,
BL_PWM_FRACTIONAL_EN, &fractional_duty_cycle_en);
5e7773a2 Anthony Koo2017-01-23 72
5e7773a2 Anthony Koo2017-01-23 73 if (bl_int_count == 0)
5e7773a2 Anthony Koo2017-01-23 74 bl_int_count = 16;
5e7773a2 Anthony Koo2017-01-23 75
5e7773a2 Anthony Koo2017-01-23 76 bl_period_mask = (1 <<
bl_int_count) - 1;
5e7773a2 Anthony Koo2017-01-23 77 bl_period &= bl_period_mask;
5e7773a2 Anthony Koo2017-01-23 78
5e7773a2 Anthony Koo2017-01-23 79 bl_pwm_mask = bl_period_mask <<
(16 - bl_int_count);
5e7773a2 Anthony Koo2017-01-23 80
5e7773a2 Anthony Koo2017-01-23 81 if (fractional_duty_cycle_en ==
0)
5e7773a2 Anthony Koo2017-01-23 82 bl_pwm &= bl_pwm_mask;
5e7773a2 Anthony Koo2017-01-23 83 else
5e7773a2 Anthony Koo2017-01-23 84 bl_pwm &= 0x;
5e7773a2 Anthony Koo2017-01-23 85
5e7773a2 Anthony Koo2017-01-23 @86 current_backlight = bl_pwm <<
(1 + bl_int_count);
Smatch is not clever enough to know that this doesn't wrap and
current_backlight is a u64 so it generates a warning.
5e7773a2 Anthony Koo2017-01-23 87
5e7773a2 Anthony Koo2017-01-23 88 if (bl_period == 0)
5e7773a2 Anthony Koo2017-01-23 89 bl_period = 0x;
5e7773a2 Anthony Koo2017-01-23 90
ca709397 Harry Wentland 2017-02-06 91 current_backlight =
div_u64(current_backlight, bl_period);
5e7773a2 Anthony Koo2017-01-23 92 current_backlight =
(current_backlight + 1) >> 1;
5e7773a2 Anthony Koo2017-01-23 93
5e7773a2 Anthony Koo2017-01-23 94 current_backlight =
(uint64_t)(current_backlight) * bl_period;
5e7773a2 Anthony Koo2017-01-23 95
5e7773a2 Anthony Koo2017-01-23 96 round_result =
(uint32_t)(current_backlight & 0x);
5e7773a2 Anthony Koo2017-01-23 97
5e7773a2 Anthony Koo2017-01-23 98 round_result = (round_result >>
(bl_int_count-1)) & 1;
5e7773a2 Anthony Koo2017-01-23 99
5e7773a2 Anthony Koo2017-01-23 100 current_backlight >>=
bl_int_count;
5e7773a2 Anthony Koo2017-01-23 101 current_backlight +=
round_result;
5e7773a2 Anthony Koo2017-01-23 102
5e7773a2 Anthony Koo2017-01-23 103 return
(uint32_t)(current_backlight);
5e7773a2 Anthony Koo2017-01-23 104 }
5e7773a2 Anthony Koo2017-01-23 105
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: Remove 80-column line in drm_mode_object.c
Break line after NULL to decrease the line size.
Signed-off-by: Shayenne da Luz Moura
---
Changes in v2:
- Remove aditional variable added in v1 and add a line break
drivers/gpu/drm/drm_mode_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mode_object.c
b/drivers/gpu/drm/drm_mode_object.c
index be8b754eaf60..cd9bc0ce9be0 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -38,7 +38,8 @@ int __drm_mode_object_add(struct drm_device *dev, struct
drm_mode_object *obj,
int ret;
mutex_lock(&dev->mode_config.idr_mutex);
- ret = idr_alloc(&dev->mode_config.crtc_idr, register_obj ? obj : NULL,
1, 0, GFP_KERNEL);
+ ret = idr_alloc(&dev->mode_config.crtc_idr, register_obj ? obj : NULL,
+ 1, 0, GFP_KERNEL);
if (ret >= 0) {
/*
* Set up the object linking under the protection of the idr
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Outreachy kernel] Re: [PATCH] drm: Remove 80-column line in drm_mode_object.c
On 10/31, Daniel Vetter wrote:
> On Wed, Oct 31, 2018 at 4:13 PM Jani Nikula
> wrote:
> >
> > On Wed, 31 Oct 2018, Shayenne da Luz Moura
> > wrote:
> > > Add a new variable to make the drm_mode_object comparison before
> > > idr_alloc and decrease line size.
> > >
> > > Signed-off-by: Shayenne da Luz Moura
> > > ---
> > > drivers/gpu/drm/drm_mode_object.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_mode_object.c
> > > b/drivers/gpu/drm/drm_mode_object.c
> > > index be8b754eaf60..4b9eafddb409 100644
> > > --- a/drivers/gpu/drm/drm_mode_object.c
> > > +++ b/drivers/gpu/drm/drm_mode_object.c
> > > @@ -36,9 +36,10 @@ int __drm_mode_object_add(struct drm_device *dev,
> > > struct drm_mode_object *obj,
> > > void (*obj_free_cb)(struct kref *kref))
> > > {
> > > int ret;
> > > + struct drm_mode_object *obj_tmp = register_obj ? obj : NULL;
> > >
> > > mutex_lock(&dev->mode_config.idr_mutex);
> > > - ret = idr_alloc(&dev->mode_config.crtc_idr, register_obj ? obj :
> > > NULL, 1, 0, GFP_KERNEL);
> > > + ret = idr_alloc(&dev->mode_config.crtc_idr, obj_tmp, 1, 0,
> > > GFP_KERNEL);
> >
> > Please don't send checkpatch "fixes" to adhere to the 80-column rule. Or
> > at least use --max-line-length=100 or something to look for worse
> > offenders than this.
> >
> > And if you insist, please just add a newline and proper indentation
> > after "NULL," instead of adding a temporary variable.
>
> Breaking the line after NULL, seems reasonable, I'd be happy to merge that.
> -Daniel
Okay, I will send a new version.
Thank you!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/msm: Split msm_gem_get_iova into two steps
Split the operation of msm_gem_get_iova into two operations:
1) allocate an iova and 2) map (pin) the backing memory int the
iommu. This is the first step toward allowing memory pinning
to occur independently of the iova management.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.h | 2 +
drivers/gpu/drm/msm/msm_gem.c | 80 ---
drivers/gpu/drm/msm/msm_gem.h | 1 +
drivers/gpu/drm/msm/msm_gem_vma.c | 44 -
4 files changed, 86 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 3a0f2119127b..63b28b69b2ab 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -241,6 +241,8 @@ struct drm_atomic_state *msm_atomic_state_alloc(struct
drm_device *dev);
void msm_atomic_state_clear(struct drm_atomic_state *state);
void msm_atomic_state_free(struct drm_atomic_state *state);
+int msm_gem_init_vma(struct msm_gem_address_space *aspace,
+ struct msm_gem_vma *vma, int npages);
void msm_gem_unmap_vma(struct msm_gem_address_space *aspace,
struct msm_gem_vma *vma);
int msm_gem_map_vma(struct msm_gem_address_space *aspace,
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index ff75e557b708..189d7f0f1aad 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -357,52 +357,76 @@ put_iova(struct drm_gem_object *obj)
}
}
-/* get iova, taking a reference. Should have a matching put */
-int msm_gem_get_iova(struct drm_gem_object *obj,
+static int msm_gem_get_iova_locked(struct drm_gem_object *obj,
struct msm_gem_address_space *aspace, uint64_t *iova)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
struct msm_gem_vma *vma;
int ret = 0;
- mutex_lock(&msm_obj->lock);
-
- if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
- mutex_unlock(&msm_obj->lock);
- return -EBUSY;
- }
+ WARN_ON(!mutex_is_locked(&msm_obj->lock));
vma = lookup_vma(obj, aspace);
if (!vma) {
- struct page **pages;
-
vma = add_vma(obj, aspace);
- if (IS_ERR(vma)) {
- ret = PTR_ERR(vma);
- goto unlock;
- }
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
- pages = get_pages(obj);
- if (IS_ERR(pages)) {
- ret = PTR_ERR(pages);
- goto fail;
+ ret = msm_gem_init_vma(aspace, vma, obj->size >> PAGE_SHIFT);
+ if (ret) {
+ del_vma(vma);
+ return ret;
}
-
- ret = msm_gem_map_vma(aspace, vma, msm_obj->sgt,
- obj->size >> PAGE_SHIFT);
- if (ret)
- goto fail;
}
*iova = vma->iova;
-
- mutex_unlock(&msm_obj->lock);
return 0;
+}
+
+static int msm_gem_pin_iova(struct drm_gem_object *obj,
+ struct msm_gem_address_space *aspace)
+{
+ struct msm_gem_object *msm_obj = to_msm_bo(obj);
+ struct msm_gem_vma *vma;
+ struct page **pages;
+
+ WARN_ON(!mutex_is_locked(&msm_obj->lock));
+
+ if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED))
+ return -EBUSY;
+
+ vma = lookup_vma(obj, aspace);
+ if (WARN_ON(!vma))
+ return -EINVAL;
+
+ pages = get_pages(obj);
+ if (IS_ERR(pages))
+ return PTR_ERR(pages);
+
+ return msm_gem_map_vma(aspace, vma, msm_obj->sgt,
+ obj->size >> PAGE_SHIFT);
+}
+
+
+/* get iova, taking a reference. Should have a matching put */
+int msm_gem_get_iova(struct drm_gem_object *obj,
+ struct msm_gem_address_space *aspace, uint64_t *iova)
+{
+ struct msm_gem_object *msm_obj = to_msm_bo(obj);
+ u64 local;
+ int ret;
+
+ mutex_lock(&msm_obj->lock);
+
+ ret = msm_gem_get_iova_locked(obj, aspace, &local);
+
+ if (!ret)
+ ret = msm_gem_pin_iova(obj, aspace);
+
+ if (!ret)
+ *iova = local;
-fail:
- del_vma(vma);
-unlock:
mutex_unlock(&msm_obj->lock);
return ret;
}
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index c5d9bd3e47a8..32c13e6559b5 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -41,6 +41,7 @@ struct msm_gem_vma {
uint64_t iova;
struct msm_gem_address_space *aspace;
struct list_head list;/* node in msm_gem_object::vmas */
+ bool mapped;
};
struct msm_gem_object {
diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c
b/drivers/gpu/drm/msm/msm_gem_vma.c
index 704ae7e69500..c4c42bf0db0e 100644
--- a/drivers/gpu/drm/msm/msm_gem_vma.c
+++ b/drivers/gpu/drm/msm/msm_gem_vma.c
[PATCH 5/6] drm/msm: Add msm_gem_get_and_pin_iova()
Add a new function to get and pin the iova memory in one
step (basically renaming the old msm_gem_get_iova function)
and switch msm_gem_get_iova() to only allocate an iova but
not map it in the IOMMU. This is only currently used by
msm_ioctl_gem_info() since all other users of of the iova
expect that the memory be immediately available.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 ++-
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 4 ++--
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 2 +-
drivers/gpu/drm/msm/dsi/dsi_host.c| 2 +-
drivers/gpu/drm/msm/msm_drv.c | 4
drivers/gpu/drm/msm/msm_drv.h | 2 ++
drivers/gpu/drm/msm/msm_fb.c | 2 +-
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
drivers/gpu/drm/msm/msm_gem.c | 24 ++-
drivers/gpu/drm/msm/msm_gem_submit.c | 2 +-
drivers/gpu/drm/msm/msm_gpu.c | 2 +-
12 files changed, 36 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 141062fbb4c8..3c2988514fc5 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -209,7 +209,8 @@ int adreno_hw_init(struct msm_gpu *gpu)
if (!ring)
continue;
- ret = msm_gem_get_iova(ring->bo, gpu->aspace, &ring->iova);
+ ret = msm_gem_get_and_pin_iova(ring->bo, gpu->aspace,
+ &ring->iova);
if (ret) {
ring->iova = 0;
DRM_DEV_ERROR(gpu->dev->dev,
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
index b91706cee2b8..ef6884f1fc34 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
@@ -384,7 +384,7 @@ static void update_cursor(struct drm_crtc *crtc)
if (next_bo) {
/* take a obj ref + iova ref when we start scanning
out: */
drm_gem_object_get(next_bo);
- msm_gem_get_iova(next_bo, kms->aspace, &iova);
+ msm_gem_get_and_pin_iova(next_bo, kms->aspace, &iova);
/* enable cursor: */
mdp4_write(mdp4_kms, REG_MDP4_DMA_CURSOR_SIZE(dma),
@@ -442,7 +442,7 @@ static int mdp4_crtc_cursor_set(struct drm_crtc *crtc,
}
if (cursor_bo) {
- ret = msm_gem_get_iova(cursor_bo, kms->aspace, &iova);
+ ret = msm_gem_get_and_pin_iova(cursor_bo, kms->aspace, &iova);
if (ret)
goto fail;
} else {
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 481c0d231149..9fd6b9b2dbcb 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -538,7 +538,7 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
goto fail;
}
- ret = msm_gem_get_iova(mdp4_kms->blank_cursor_bo, kms->aspace,
+ ret = msm_gem_get_and_pin_iova(mdp4_kms->blank_cursor_bo, kms->aspace,
&mdp4_kms->blank_cursor_iova);
if (ret) {
DRM_DEV_ERROR(dev->dev, "could not pin blank-cursor bo: %d\n",
ret);
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 413b52211017..c7cc276575fb 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -903,7 +903,7 @@ static int mdp5_crtc_cursor_set(struct drm_crtc *crtc,
if (!cursor_bo)
return -ENOENT;
- ret = msm_gem_get_iova(cursor_bo, kms->aspace,
+ ret = msm_gem_get_and_pin_iova(cursor_bo, kms->aspace,
&mdp5_crtc->cursor.iova);
if (ret)
return -EINVAL;
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index eba901584035..99122767abf4 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1248,7 +1248,7 @@ int dsi_dma_base_get_6g(struct msm_dsi_host *msm_host,
uint64_t *dma_base)
if (!dma_base)
return -EINVAL;
- return msm_gem_get_iova(msm_host->tx_gem_obj,
+ return msm_gem_get_and_pin_iova(msm_host->tx_gem_obj,
priv->kms->aspace, dma_base);
}
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9c9f7ff6960b..f2ebfb9ba0e4 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -849,6 +849,10 @@ static int msm_ioctl_gem_info_iova(struct drm_device *dev,
if (!priv->gpu)
return -EINVAL;
+ /*
+* Don't pin the memory here - just get an address so that us
[PATCH 6/6] drm/msm: Count how many times iova memory is pinned
Add a reference count to track how many times a particular
chunk of iova memory is pinned (mapped) in the iomu and
add msm_gem_unpin_iova to give up references.
It is important to note that msm_gem_unpin_iova replaces
msm_gem_put_iova because the new implicit behavior
that an assigned iova in a given vma is now valid for the
life of the buffer and what we are really focusing on is
the use of that iova.
For now the unmappings are lazy; once the reference counts
go to zero they *COULD* be unmapped dynamically but that
will require an outside force such as a shrinker or
mm_notifiers. For now, we're just focusing on getting
the counting right and setting ourselves up to be ready
for the future.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 6 +--
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 9 ++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 +-
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 2 +-
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 2 +-
drivers/gpu/drm/msm/dsi/dsi_host.c| 2 +-
drivers/gpu/drm/msm/msm_drv.h | 8 +++-
drivers/gpu/drm/msm/msm_fb.c | 2 +-
drivers/gpu/drm/msm/msm_gem.c | 43 ---
drivers/gpu/drm/msm/msm_gem.h | 1 +
drivers/gpu/drm/msm/msm_gem_submit.c | 2 +-
drivers/gpu/drm/msm/msm_gem_vma.c | 51 +--
drivers/gpu/drm/msm/msm_gpu.c | 2 +-
14 files changed, 87 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
index 6983cd9102bd..d9af3aff690f 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
@@ -130,15 +130,13 @@ reset_set(void *data, u64 val)
adreno_gpu->fw[ADRENO_FW_PFP] = NULL;
if (a5xx_gpu->pm4_bo) {
- if (a5xx_gpu->pm4_iova)
- msm_gem_put_iova(a5xx_gpu->pm4_bo, gpu->aspace);
+ msm_gem_unpin_iova(a5xx_gpu->pm4_bo, gpu->aspace);
drm_gem_object_put(a5xx_gpu->pm4_bo);
a5xx_gpu->pm4_bo = NULL;
}
if (a5xx_gpu->pfp_bo) {
- if (a5xx_gpu->pfp_iova)
- msm_gem_put_iova(a5xx_gpu->pfp_bo, gpu->aspace);
+ msm_gem_unpin_iova(a5xx_gpu->pfp_bo, gpu->aspace);
drm_gem_object_put(a5xx_gpu->pfp_bo);
a5xx_gpu->pfp_bo = NULL;
}
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index d6f8dedc028a..135496393cf3 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -841,20 +841,17 @@ static void a5xx_destroy(struct msm_gpu *gpu)
a5xx_preempt_fini(gpu);
if (a5xx_gpu->pm4_bo) {
- if (a5xx_gpu->pm4_iova)
- msm_gem_put_iova(a5xx_gpu->pm4_bo, gpu->aspace);
+ msm_gem_unpin_iova(a5xx_gpu->pm4_bo, gpu->aspace);
drm_gem_object_put_unlocked(a5xx_gpu->pm4_bo);
}
if (a5xx_gpu->pfp_bo) {
- if (a5xx_gpu->pfp_iova)
- msm_gem_put_iova(a5xx_gpu->pfp_bo, gpu->aspace);
+ msm_gem_unpin_iova(a5xx_gpu->pfp_bo, gpu->aspace);
drm_gem_object_put_unlocked(a5xx_gpu->pfp_bo);
}
if (a5xx_gpu->gpmu_bo) {
- if (a5xx_gpu->gpmu_iova)
- msm_gem_put_iova(a5xx_gpu->gpmu_bo, gpu->aspace);
+ msm_gem_unpin_iova(a5xx_gpu->gpmu_bo, gpu->aspace);
drm_gem_object_put_unlocked(a5xx_gpu->gpmu_bo);
}
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 38b7a5a92bfb..9acf12c21b23 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -746,8 +746,7 @@ static void a6xx_destroy(struct msm_gpu *gpu)
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
if (a6xx_gpu->sqe_bo) {
- if (a6xx_gpu->sqe_iova)
- msm_gem_put_iova(a6xx_gpu->sqe_bo, gpu->aspace);
+ msm_gem_unpin_iova(a6xx_gpu->sqe_bo, gpu->aspace);
drm_gem_object_put_unlocked(a6xx_gpu->sqe_bo);
}
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
index ef6884f1fc34..8f2359dc87b4 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
@@ -128,7 +128,7 @@ static void unref_cursor_worker(struct drm_flip_work *work,
void *val)
struct mdp4_kms *mdp4_kms = get_kms(&mdp4_crtc->base);
struct msm_kms *kms = &mdp4_kms->base.base;
- msm_gem_put_iova(val, kms->aspace);
+ msm_gem_unpin_iova(val, kms->aspace);
drm_gem_object_put_unlocked(val);
}
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
b/drivers/gpu/drm
[PATCH 4/6] drm/msm: Clean up and enhance the output of the 'gem' debugfs node
Add headers for the 'gem' debugfs file to make it easier to remember
what all the values mean and move the list of virtual address regions
to the next line and add the name and map status to make it clearer
what we are looking at.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gem.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 189d7f0f1aad..805a300f8663 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -763,16 +763,23 @@ void msm_gem_describe(struct drm_gem_object *obj, struct
seq_file *m)
break;
}
- seq_printf(m, "%08x: %c %2d (%2d) %08llx %p\t",
+ seq_printf(m, "%08x: %c %2d (%2d) %08llx %p",
msm_obj->flags, is_active(msm_obj) ? 'A' : 'I',
obj->name, kref_read(&obj->refcount),
off, msm_obj->vaddr);
- /* FIXME: we need to print the address space here too */
- list_for_each_entry(vma, &msm_obj->vmas, list)
- seq_printf(m, " %08llx", vma->iova);
+ seq_printf(m, " %08zu%9s\n", obj->size, madv);
- seq_printf(m, " %zu%s\n", obj->size, madv);
+ if (!list_empty(&msm_obj->vmas)) {
+
+ seq_puts(m, " vmas:");
+
+ list_for_each_entry(vma, &msm_obj->vmas, list)
+ seq_printf(m, " [%s: %08llx,%s]", vma->aspace->name,
+ vma->iova, vma->mapped ? "mapped" : "unmapped");
+
+ seq_puts(m, "\n");
+ }
rcu_read_lock();
fobj = rcu_dereference(robj->fence);
@@ -799,9 +806,10 @@ void msm_gem_describe_objects(struct list_head *list,
struct seq_file *m)
int count = 0;
size_t size = 0;
+ seq_puts(m, " flags id ref offset kaddr size
madv\n");
list_for_each_entry(msm_obj, list, mm_list) {
struct drm_gem_object *obj = &msm_obj->base;
- seq_printf(m, " ");
+ seq_puts(m, " ");
msm_gem_describe(obj, m);
count++;
size += obj->size;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/msm: Add a common function to free kernel buffer objects
Buffer objects allocated with msm_gem_kernel_new() are mostly
freed the same way so we can save a few lines of code with a
common function.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 13 ++---
drivers/gpu/drm/msm/adreno/a5xx_power.c | 13 +
drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 14 ++
drivers/gpu/drm/msm/msm_drv.h | 2 ++
drivers/gpu/drm/msm/msm_gem.c | 15 +++
drivers/gpu/drm/msm/msm_gpu.c | 12 ++--
drivers/gpu/drm/msm/msm_ringbuffer.c | 7 ++-
7 files changed, 26 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 2d34643ef2e2..d6f8dedc028a 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1228,15 +1228,6 @@ static int a5xx_crashdumper_init(struct msm_gpu *gpu,
return 0;
}
-static void a5xx_crashdumper_free(struct msm_gpu *gpu,
- struct a5xx_crashdumper *dumper)
-{
- msm_gem_put_iova(dumper->bo, gpu->aspace);
- msm_gem_put_vaddr(dumper->bo);
-
- drm_gem_object_put(dumper->bo);
-}
-
static int a5xx_crashdumper_run(struct msm_gpu *gpu,
struct a5xx_crashdumper *dumper)
{
@@ -1329,7 +1320,7 @@ static void a5xx_gpu_state_get_hlsq_regs(struct msm_gpu
*gpu,
if (a5xx_crashdumper_run(gpu, &dumper)) {
kfree(a5xx_state->hlsqregs);
- a5xx_crashdumper_free(gpu, &dumper);
+ msm_gem_kernel_put(dumper.bo, gpu->aspace, true);
return;
}
@@ -1337,7 +1328,7 @@ static void a5xx_gpu_state_get_hlsq_regs(struct msm_gpu
*gpu,
memcpy(a5xx_state->hlsqregs, dumper.ptr + (256 * SZ_1K),
count * sizeof(u32));
- a5xx_crashdumper_free(gpu, &dumper);
+ msm_gem_kernel_put(dumper.bo, gpu->aspace, true);
}
static struct msm_gpu_state *a5xx_gpu_state_get(struct msm_gpu *gpu)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_power.c
b/drivers/gpu/drm/msm/adreno/a5xx_power.c
index 7a41e1c147e4..66bcd88dd8c0 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_power.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_power.c
@@ -298,7 +298,7 @@ void a5xx_gpmu_ucode_init(struct msm_gpu *gpu)
MSM_BO_UNCACHED | MSM_BO_GPU_READONLY, gpu->aspace,
&a5xx_gpu->gpmu_bo, &a5xx_gpu->gpmu_iova);
if (IS_ERR(ptr))
- goto err;
+ return;
while (cmds_size > 0) {
int i;
@@ -317,15 +317,4 @@ void a5xx_gpmu_ucode_init(struct msm_gpu *gpu)
msm_gem_put_vaddr(a5xx_gpu->gpmu_bo);
a5xx_gpu->gpmu_dwords = dwords;
-
- return;
-err:
- if (a5xx_gpu->gpmu_iova)
- msm_gem_put_iova(a5xx_gpu->gpmu_bo, gpu->aspace);
- if (a5xx_gpu->gpmu_bo)
- drm_gem_object_put(a5xx_gpu->gpmu_bo);
-
- a5xx_gpu->gpmu_bo = NULL;
- a5xx_gpu->gpmu_iova = 0;
- a5xx_gpu->gpmu_dwords = 0;
}
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
index fdb08fc68c2c..48481e663685 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
@@ -267,18 +267,8 @@ void a5xx_preempt_fini(struct msm_gpu *gpu)
struct a5xx_gpu *a5xx_gpu = to_a5xx_gpu(adreno_gpu);
int i;
- for (i = 0; i < gpu->nr_rings; i++) {
- if (!a5xx_gpu->preempt_bo[i])
- continue;
-
- msm_gem_put_vaddr(a5xx_gpu->preempt_bo[i]);
-
- if (a5xx_gpu->preempt_iova[i])
- msm_gem_put_iova(a5xx_gpu->preempt_bo[i], gpu->aspace);
-
- drm_gem_object_put(a5xx_gpu->preempt_bo[i]);
- a5xx_gpu->preempt_bo[i] = NULL;
- }
+ for (i = 0; i < gpu->nr_rings; i++)
+ msm_gem_kernel_put(a5xx_gpu->preempt_bo[i], gpu->aspace, true);
}
void a5xx_preempt_init(struct msm_gpu *gpu)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 9d11f321f5a9..3225f8fbd8c9 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -312,6 +312,8 @@ void *msm_gem_kernel_new(struct drm_device *dev, uint32_t
size,
void *msm_gem_kernel_new_locked(struct drm_device *dev, uint32_t size,
uint32_t flags, struct msm_gem_address_space *aspace,
struct drm_gem_object **bo, uint64_t *iova);
+void msm_gem_kernel_put(struct drm_gem_object *bo,
+ struct msm_gem_address_space *aspace, bool locked);
struct drm_gem_object *msm_gem_import(struct drm_device *dev,
struct dma_buf *dmabuf, struct sg_table *sgt);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 00c795ced02c..855f5721a14e 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -1073,3 +1073,18 @@ void *msm_gem_kernel_new_l
[PATCH 2/6] drm/msm: Remove sgt from the mmu unmap function
The scatter gather table doesn't need to be passed in for the
MMU unmap function.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.h | 2 +-
drivers/gpu/drm/msm/msm_gem.c | 2 +-
drivers/gpu/drm/msm/msm_gem_vma.c | 4 ++--
drivers/gpu/drm/msm/msm_iommu.c | 3 +--
drivers/gpu/drm/msm/msm_mmu.h | 3 +--
5 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 3225f8fbd8c9..3a0f2119127b 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -242,7 +242,7 @@ void msm_atomic_state_clear(struct drm_atomic_state *state);
void msm_atomic_state_free(struct drm_atomic_state *state);
void msm_gem_unmap_vma(struct msm_gem_address_space *aspace,
- struct msm_gem_vma *vma, struct sg_table *sgt);
+ struct msm_gem_vma *vma);
int msm_gem_map_vma(struct msm_gem_address_space *aspace,
struct msm_gem_vma *vma, struct sg_table *sgt, int npages);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 855f5721a14e..ff75e557b708 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -352,7 +352,7 @@ put_iova(struct drm_gem_object *obj)
WARN_ON(!mutex_is_locked(&msm_obj->lock));
list_for_each_entry_safe(vma, tmp, &msm_obj->vmas, list) {
- msm_gem_unmap_vma(vma->aspace, vma, msm_obj->sgt);
+ msm_gem_unmap_vma(vma->aspace, vma);
del_vma(vma);
}
}
diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c
b/drivers/gpu/drm/msm/msm_gem_vma.c
index ffbec224551b..704ae7e69500 100644
--- a/drivers/gpu/drm/msm/msm_gem_vma.c
+++ b/drivers/gpu/drm/msm/msm_gem_vma.c
@@ -40,14 +40,14 @@ void msm_gem_address_space_put(struct msm_gem_address_space
*aspace)
void
msm_gem_unmap_vma(struct msm_gem_address_space *aspace,
- struct msm_gem_vma *vma, struct sg_table *sgt)
+ struct msm_gem_vma *vma)
{
if (!aspace || !vma->iova)
return;
if (aspace->mmu) {
unsigned size = vma->node.size << PAGE_SHIFT;
- aspace->mmu->funcs->unmap(aspace->mmu, vma->iova, sgt, size);
+ aspace->mmu->funcs->unmap(aspace->mmu, vma->iova, size);
}
spin_lock(&aspace->lock);
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index b23d33622f37..9c313cb129ee 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -71,8 +71,7 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
return (ret == len) ? 0 : -EINVAL;
}
-static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t iova,
- struct sg_table *sgt, unsigned len)
+static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t iova, unsigned len)
{
struct msm_iommu *iommu = to_msm_iommu(mmu);
diff --git a/drivers/gpu/drm/msm/msm_mmu.h b/drivers/gpu/drm/msm/msm_mmu.h
index aa2c5d4580c8..94c0b83d8026 100644
--- a/drivers/gpu/drm/msm/msm_mmu.h
+++ b/drivers/gpu/drm/msm/msm_mmu.h
@@ -25,8 +25,7 @@ struct msm_mmu_funcs {
void (*detach)(struct msm_mmu *mmu, const char * const *names, int cnt);
int (*map)(struct msm_mmu *mmu, uint64_t iova, struct sg_table *sgt,
unsigned len, int prot);
- int (*unmap)(struct msm_mmu *mmu, uint64_t iova, struct sg_table *sgt,
- unsigned len);
+ int (*unmap)(struct msm_mmu *mmu, uint64_t iova, unsigned len);
void (*destroy)(struct msm_mmu *mmu);
};
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] RFC: drm/msm: separate iova allocation and mapping
Currently in the msm driver iova addresses are mapped in the IOMMU at allocation time and stay there for the life of the buffer. This may not be desirable for long lived user space buffers that could be temporarily swapped or moved. This first set of patches breaks up the allocation and mapping into distinct steps and adds reference counting for pinning and unpinning the memory. Future code can use this information to manipulate the memory when it isn't in use. Jordan Crouse (6): drm/msm: Add a common function to free kernel buffer objects drm/msm: Remove sgt from the mmu unmap function drm/msm: Split msm_gem_get_iova into two steps drm/msm: Clean up and enhance the output of the 'gem' debugfs node drm/msm: Add msm_gem_get_and_pin_iova() drm/msm: Count how many times iova memory is pinned drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 6 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 22 +-- drivers/gpu/drm/msm/adreno/a5xx_power.c | 13 +- drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 14 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 +- drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 6 +- drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 4 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 4 +- drivers/gpu/drm/msm/dsi/dsi_host.c| 4 +- drivers/gpu/drm/msm/msm_drv.c | 4 + drivers/gpu/drm/msm/msm_drv.h | 16 ++- drivers/gpu/drm/msm/msm_fb.c | 4 +- drivers/gpu/drm/msm/msm_fbdev.c | 2 +- drivers/gpu/drm/msm/msm_gem.c | 162 -- drivers/gpu/drm/msm/msm_gem.h | 2 + drivers/gpu/drm/msm/msm_gem_submit.c | 4 +- drivers/gpu/drm/msm/msm_gem_vma.c | 95 + drivers/gpu/drm/msm/msm_gpu.c | 16 +-- drivers/gpu/drm/msm/msm_iommu.c | 3 +- drivers/gpu/drm/msm/msm_mmu.h | 3 +- drivers/gpu/drm/msm/msm_ringbuffer.c | 7 +- 22 files changed, 242 insertions(+), 155 deletions(-) -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm: tinydrm driver for adafruit PiTFT 3.5" touchscreen
Den 25.10.2018 18.29, skrev Eric Anholt: Eric Anholt writes: I was going to start working on making the vc4 driver work with tinydrm panels, but it turned out tinydrm didn't have the panel I had previously bought. So, last night I ported the fbtft staging driver over to DRM. It seems to work (with DT at https://github.com/anholt/linux/commits/drm-misc-next-hx8357d) -- fbdev works great including rotated, and so does modetest. However, when X11 comes up at 16bpp, I get: https://photos.app.goo.gl/8tuhzPFFoDGamEfk8 If I have tinydrm set a preferred bpp of 24, X looks great. Noralf, any ideas? Also, with these patches and the format modifier patch I just sent, mesa with vc4 is now working with this driver on this branch: https://gitlab.freedesktop.org/anholt/mesa/commits/kmsro Now I wonder how we can improve performance of the SPI updates. I just remembered that tinydrm does a full flush on page flips. And if the dirtyfb ioctl is also used you end up with two flushes. This could explain bad performance. I have been waiting for the dirtyfb through atomic work to come to fruition, but nothing merged yet. That would give dirty tracking on page flips. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCHv2 4/9] drm/tidss: add new driver for TI Keystone platforms
Hi Laurent,
Tomi is busy with other things so I have taken over applying these
comments. The rest is more or less clear, or commented by Tomi, but this
is something have not addressed:
On 30/07/18 17:12, Laurent Pinchart wrote:
>> +static void tidss_crtc_atomic_flush(struct drm_crtc *crtc,
>> +struct drm_crtc_state *old_crtc_state)
>> +{
>> +struct tidss_crtc *tcrtc = to_tidss_crtc(crtc);
>> +struct drm_device *ddev = crtc->dev;
>> +struct tidss_device *tidss = ddev->dev_private;
>> +
>> +dev_dbg(ddev->dev, "%s, crtc enabled %d, event %p\n",
>> +__func__, tcrtc->enabled, crtc->state->event);
>> +
>> +/* Only flush the CRTC if it is currently enabled. */
>> +if (!tcrtc->enabled)
> In atomic drivers state should be stored in state structures. You could check
> old_crtc_state for this and remove the enabled field in struct tidss_crtc.
>
The variable is need for tracking the HW state trough the state
transition. I do not know which state variable I should use to keep that
state information stored trough the process where one state changes into
another.
The drm_crtc_state already contains couple of variables describing
whether crtc is enabled or not, or if the mode is going to change in the
state transition (giving a hint that crtc is going go through
disable-enable cycle). I tried to use all of those, and the old state
variable, to accomplish the same behaviour as the current code has, but
I could not.
One of the problematic cases was a new drm client making an atomic
commit, the old one being bf-console, with the same mode as the one was
using. In that situation the crtc goes trough disable-enable cycle, but
I could not find any way to detect the situation from the old and new
crtc state. Enable-disable cycle means that we should not flip the
go-bit, but just configure everything and enable the crtc, e.g skip the
atomic flush and wait for enable instead.
In any case this is for HW state, not for DRM state tracking. I could
add a call back to dispc ops for asking if the video port is enabled and
use that instead if you think that is more formally correct.
Best regards,
Jyri
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/4] drm: Document variable refresh properties
On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote: > On 10/31/18 10:12 AM, Michel Dänzer wrote: >> On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote: >>> On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote: I understand the issue you're describing now. The timestamp is supposed to signify the end of the current vblank. The call to get scanout position is supposed to return the number of lines until scanout (a negative value) or the number of lines since the next scanout began (a positive value). The amdgpu driver calculates the number of lines based on a hardware register status position which returns an increasing value from 0 that indicates the current vpos/hpos for the display. For any vpos below vbl_start we know the value is correct since the next vblank hasn't begun yet. But for anythign about vbl_start it's probably wrong since it applies a corrective offset based on the fixed value of crtc_vtotal. It's even worse when the value is above crtc_vtotal since it'll be calculating the number of lines since the last scanout since it'll be a positive value. So the issue becomes determining when the vfront porch will end. When the flip address gets written the vfront porch will end at the start of the next line leaving only the back porch plus part of the line. But we don't know when the flip will occur, if at all. It hasn't occurred yet in this case. Waiting for the wrap around to 0 might be the best choice here since there's no guarantee the flip will occur. >>> >>> I put some more thought into this and I don't think this is as bad as I >>> had originally thought. >>> >>> I think the vblank timestamp is supposed to be for the first active >>> pixel of the next scanout. The usage of which is for clients to time >>> their content/animation/etc. >>> >>> The client likely doesn't care when they issue their flip, just that >>> their content is matched for that vblank timestamp. The fixed refresh >>> model works really well for that kind of application. >>> >>> Utilizing variable refresh rate would be a mistake in that case since >>> the client would then have to time based on when they flip which is a >>> lot harder to "predict" precisely. >> >> It's only a "mistake" as long as the timestamps are misleading. :) As >> discussed before, accurate presentation timestamps are one requirement >> for achieving perfectly smooth animation. > > For most 3D games the game world/rendering can advance by an arbitrary > timestep - and faster will be smoother, which is what the native mode > would give you. > > For fixed interval content/animation where you can't do that variable > refresh rate could vastly improve the output. But like discussed before > that would need a way to specify the interval/presentation timestamp to > control that front porch duration. The timestamp will be misleading in > any other case. I don't agree that an accurate timestamp can ever be more "misleading" than an inaccurate one. But yeah, accurate timestamps and time-based presentation are two sides of the same coin which can buy the holy grail of perfectly smooth animation. :) >>> I did some more investigation into when amdgpu gets the scanout position >>> and what values we get back out of it. The timestamp is updated shortly >>> after the crtc irq vblank which is typically within a few lines of >>> vbl_start. This makes sense, since we can provide the prediction >>> timestamp early. Waiting for the vblank to wrap around to 0 doesn't >>> really make sense here since that would mean we already hit timeout or >>> the flip occurred >> >> Sounds like you're mixing up the two cases of "actual" vblank events >> (triggered by the "vblank" interrupt => drm_(crtc_)handle_vblank) and >> flip completion events (triggered by the PFLIP interrupt with our >> hardware => drm_crtc_send_vblank_event). >> >> Actual vblank events need to be delivered to userspace at the start of >> vblank, so we indeed can't wait until the timestamp is accurate for >> them. We just need to document the exact semantics of their timestamp >> with VRR. >> >> For page flip completion events though, the timestamp needs to be >> accurate and correspond to when the flipped frame starts being scanned >> out, otherwise we'll surely break at least some userspace relying on >> this information. >> > Yeah, I was. I guess what's sent is the estimated vblank timestamp > calculated at the start of the interrupt. s/interrupt/vblank/, yeah. > And since that's just a guess rather than what's actually going to > happen it's going to be wrong in a lot of cases. > > I could see the wrap-around method working if the vblank timestamp was > somehow updated in amdgpu or in drm_crtc_send_vblank_event. DC already calls drm_crtc_accurate_vblank_count before drm_crtc_send_vblank_event, we "just" need to make sure that results in an accurate timestamp. > T
Re: [PATCH v6 12/28] drm/i915/dp: Add DSC params and DSC config to intel_crtc_state
On Wed, Oct 31, 2018 at 09:05:05AM -0700, Manasi Navare wrote:
> On Wed, Oct 31, 2018 at 03:10:15PM +0200, Ville Syrjälä wrote:
> > On Tue, Oct 30, 2018 at 04:53:49PM -0700, Manasi Navare wrote:
> > > On Wed, Oct 24, 2018 at 03:28:24PM -0700, Manasi Navare wrote:
> > > > Basic DSC parameters and DSC configuration data needs to be computed
> > > > for each of the requested mode during atomic check. This is
> > > > required since for certain modes, valid DSC parameters and config
> > > > data might not be computed in which case compression cannot be
> > > > enabled for that mode.
> > > > For that reason we need to add these params and config structure
> > > > to the intel_crtc_state so that if valid this state information
> > > > can directly be used while enabling DSC in atomic commit.
> > > >
> > > > v2:
> > > > * Rebase on drm-tip (Manasi)
> > > >
> > > > Cc: Gaurav K Singh
> > > > Cc: Jani Nikula
> > > > Cc: Ville Syrjala
> > > > Cc: Anusha Srivatsa
> > > > Signed-off-by: Manasi Navare
> > > > Reviewed-by: Anusha Srivatsa
> > > > ---
> > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > drivers/gpu/drm/i915/intel_drv.h | 9 +
> > > > 2 files changed, 10 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 2d7761b8ac07..45fd7894722b 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -53,6 +53,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > >
> > > > #include "i915_params.h"
> > > > #include "i915_reg.h"
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > index 62c051098859..27d47950f438 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -931,6 +931,15 @@ struct intel_crtc_state {
> > > >
> > > > /* Output down scaling is done in LSPCON device */
> > > > bool lspcon_downsampling;
> > > > +
> > > > + /* Display Stream compression state */
> > > > + struct {
> > > > + bool compression_enable;
> > > > + bool dsc_split;
> > > > + u16 compressed_bpp;
> > > > + u8 slice_count;
> > > > + } dsc_params;
> > > > + struct drm_dsc_config dp_dsc_cfg;
> > >
> > > Ville, Jani should this be defined as a pointer to struct drm_dsc_config?
> > > struct drm_dsc_config *dp_dsc_cfg
> > > since we populate this in intel_dp_compute_config and then on only read
> > > during
> > > commit.
> >
> > Pointer to where exactly? You need the memory for it somewhere.
> >
>
> struct drm_dsc_config is defined in drm_dsc.h and gets populated later in
> the dp_compute_config.
> So I guess wwe can leave it as strcut drm_dsc_config dp_dsc_cfg; in
> crtc_state?
> Pass a pointer to that while populating in the compute-config() but then
> later in the commit
> when we have to read from this to write the sdp infoframe, we just pass the
> struct directly, no
> need to pass a pointer since its gonna be read and also crtc_state will be a
> const
>
> Is that correct?
You don't want to be passing large structures by value, if that's what
you're suggesting.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm/bridge/sii902x: Fix EDID readback
Hi Fabrizio,
thanks for your patch!
On Wed, Oct 31, 2018 at 1:58 PM Fabrizio Castro
wrote:
> While adding SiI9022A support to the iwg23s board it came up
> that when the HDMI transmitter is in pass through mode the
> device is not compliant with the I2C specification anymore,
> as it requires a far bigger tbuf due to a delay the HDMI
> transmitter is adding when relaying the STOP condition on the
> monitor i2c side of things. When not providing an appropriate
> delay after the STOP condition the i2c bus would get stuck.
> Also, any other traffic on the bus while talking to the monitor
> may cause the transaction to fail or even cause issues with the
> i2c bus as well.
>
> I2c-gates seemed to reach consent as a possible way to address
> these issues, and as such this patch is implementing a solution
> based on that. Since others are clearly relying on the current
> implementation of the driver, this patch won't require any DT
> changes.
>
> Since we don't want any interference during the DDC Bus
> Request/Grant procedure and while talking to the monitor, we have
> to use the adapter locking primitives rather than the i2c-mux
> locking primitives, but in order to achieve that I had to get
> rid of regmap.
Why did you have to remove regmap? It is perfectly possible
to override any reading/writing operations locally if you don't
want to use the regmap i2c variants.
The code in your patch does not make it evident to me exactly
where the problem is with regmap, also I bet the regmap
maintainer would love to hear about it so we can attempt to
fix it there instead of locally in this driver.
AFAICT there is some locked vs unlocked business and I
strongly hope there is some way to simply pass that down
into whatever functions regmap end up calling so we don't
have to change all call sites.
(So please include Mark Brown on CC in future iterations.)
> Signed-off-by: Fabrizio Castro
> ---
> Dear All,
>
> this is a follow up to:
> https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg32072.html
>
> Comments very welcome!
At the very least I think the patch needs to be split in two,
one dealing with the locking business and one dealing with
the buffer size. As it looks now it is very hard to review.
>
> Thanks,
> Fab
>
> drivers/gpu/drm/bridge/sii902x.c | 404
> ++-
> 1 file changed, 274 insertions(+), 130 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/sii902x.c
> b/drivers/gpu/drm/bridge/sii902x.c
> index e59a135..137a05a 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -21,9 +21,9 @@
> */
>
> #include
> +#include
> #include
> #include
> -#include
>
> #include
> #include
> @@ -82,12 +82,130 @@
>
> struct sii902x {
> struct i2c_client *i2c;
> - struct regmap *regmap;
> struct drm_bridge bridge;
> struct drm_connector connector;
> struct gpio_desc *reset_gpio;
> + struct i2c_mux_core *i2cmux;
> };
>
> +static int sii902x_transfer_read(struct i2c_client *i2c, u8 reg, u8 *val,
> +u16 len, bool locked)
> +{
> + struct i2c_msg xfer[] = {
> + {
> + .addr = i2c->addr,
> + .flags = 0,
> + .len = 1,
> + .buf = ®,
> + }, {
> + .addr = i2c->addr,
> + .flags = I2C_M_RD,
> + .len = len,
> + .buf = val,
> + }
> + };
> + unsigned char xfers = ARRAY_SIZE(xfer);
> + int ret, retries = 5;
> +
> + do {
> + if (locked)
> + ret = i2c_transfer(i2c->adapter, xfer, xfers);
> + else
> + ret = __i2c_transfer(i2c->adapter, xfer, xfers);
> + if (ret < 0)
> + return ret;
> + } while (ret != xfers && --retries);
> + return ret == xfers ? 0 : -1;
> +}
> +
> +static int sii902x_bulk_read(struct i2c_client *i2c, u8 reg, u8 *val, u16
> len)
> +{
> + return sii902x_transfer_read(i2c, reg, val, len, true);
> +}
> +
> +static int __sii902x_bulk_read(struct i2c_client *i2c, u8 reg, u8 *val, u16
> len)
> +{
> + return sii902x_transfer_read(i2c, reg, val, len, false);
> +}
I'm not a fan of __functions because it is syntactically
ambigous what that means.
Example set_bit() vs __set_bit() - is it obvious from context
that the latter is non-atomic? No.
Give these functions names that indicate exactly what they
do and why, please.
*_locked and *_unlocked variants?
> +static int sii902x_read(struct i2c_client *i2c, u8 reg, u8 *val)
> +{
> + return sii902x_bulk_read(i2c, reg, val, 1);
> +}
> +
> +static int __sii902x_read(struct i2c_client *i2c, u8 reg, u8 *val)
> +{
> + return __sii902x_bulk_read(i2c, reg, val, 1);
> +}
Dito
> +static int sii902x_transfer_write(struct i
Re: [PATCH v6 12/28] drm/i915/dp: Add DSC params and DSC config to intel_crtc_state
On Wed, Oct 31, 2018 at 03:10:15PM +0200, Ville Syrjälä wrote:
> On Tue, Oct 30, 2018 at 04:53:49PM -0700, Manasi Navare wrote:
> > On Wed, Oct 24, 2018 at 03:28:24PM -0700, Manasi Navare wrote:
> > > Basic DSC parameters and DSC configuration data needs to be computed
> > > for each of the requested mode during atomic check. This is
> > > required since for certain modes, valid DSC parameters and config
> > > data might not be computed in which case compression cannot be
> > > enabled for that mode.
> > > For that reason we need to add these params and config structure
> > > to the intel_crtc_state so that if valid this state information
> > > can directly be used while enabling DSC in atomic commit.
> > >
> > > v2:
> > > * Rebase on drm-tip (Manasi)
> > >
> > > Cc: Gaurav K Singh
> > > Cc: Jani Nikula
> > > Cc: Ville Syrjala
> > > Cc: Anusha Srivatsa
> > > Signed-off-by: Manasi Navare
> > > Reviewed-by: Anusha Srivatsa
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > drivers/gpu/drm/i915/intel_drv.h | 9 +
> > > 2 files changed, 10 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 2d7761b8ac07..45fd7894722b 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -53,6 +53,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include "i915_params.h"
> > > #include "i915_reg.h"
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 62c051098859..27d47950f438 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -931,6 +931,15 @@ struct intel_crtc_state {
> > >
> > > /* Output down scaling is done in LSPCON device */
> > > bool lspcon_downsampling;
> > > +
> > > + /* Display Stream compression state */
> > > + struct {
> > > + bool compression_enable;
> > > + bool dsc_split;
> > > + u16 compressed_bpp;
> > > + u8 slice_count;
> > > + } dsc_params;
> > > + struct drm_dsc_config dp_dsc_cfg;
> >
> > Ville, Jani should this be defined as a pointer to struct drm_dsc_config?
> > struct drm_dsc_config *dp_dsc_cfg
> > since we populate this in intel_dp_compute_config and then on only read
> > during
> > commit.
>
> Pointer to where exactly? You need the memory for it somewhere.
>
struct drm_dsc_config is defined in drm_dsc.h and gets populated later in the
dp_compute_config.
So I guess wwe can leave it as strcut drm_dsc_config dp_dsc_cfg; in crtc_state?
Pass a pointer to that while populating in the compute-config() but then later
in the commit
when we have to read from this to write the sdp infoframe, we just pass the
struct directly, no
need to pass a pointer since its gonna be read and also crtc_state will be a
const
Is that correct?
Manasi
> >
> > Manasi
> >
> > > };
> > >
> > > struct intel_crtc {
> > > --
> > > 2.18.0
> > >
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108608] Blank screen after KMS with Linux 4.19.0 on Hawaii (R9 290)
https://bugs.freedesktop.org/show_bug.cgi?id=108608 --- Comment #1 from Alex Deucher --- Please attach your full dmesg output. Can you bisect? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light room.
https://bugs.freedesktop.org/show_bug.cgi?id=99923 --- Comment #42 from Martin Pilarski --- With the fix commited in LLVM trunk/master (and obviously working), I guess this bug can be closed? I'd like to know if it can be backported, too. LLVM 8 is quite some time away and, depending on the distribution, it takes even longer to reach the users. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Outreachy kernel] Re: [PATCH] drm: Remove 80-column line in drm_mode_object.c
On Wed, Oct 31, 2018 at 4:13 PM Jani Nikula wrote:
>
> On Wed, 31 Oct 2018, Shayenne da Luz Moura wrote:
> > Add a new variable to make the drm_mode_object comparison before
> > idr_alloc and decrease line size.
> >
> > Signed-off-by: Shayenne da Luz Moura
> > ---
> > drivers/gpu/drm/drm_mode_object.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mode_object.c
> > b/drivers/gpu/drm/drm_mode_object.c
> > index be8b754eaf60..4b9eafddb409 100644
> > --- a/drivers/gpu/drm/drm_mode_object.c
> > +++ b/drivers/gpu/drm/drm_mode_object.c
> > @@ -36,9 +36,10 @@ int __drm_mode_object_add(struct drm_device *dev, struct
> > drm_mode_object *obj,
> > void (*obj_free_cb)(struct kref *kref))
> > {
> > int ret;
> > + struct drm_mode_object *obj_tmp = register_obj ? obj : NULL;
> >
> > mutex_lock(&dev->mode_config.idr_mutex);
> > - ret = idr_alloc(&dev->mode_config.crtc_idr, register_obj ? obj :
> > NULL, 1, 0, GFP_KERNEL);
> > + ret = idr_alloc(&dev->mode_config.crtc_idr, obj_tmp, 1, 0,
> > GFP_KERNEL);
>
> Please don't send checkpatch "fixes" to adhere to the 80-column rule. Or
> at least use --max-line-length=100 or something to look for worse
> offenders than this.
>
> And if you insist, please just add a newline and proper indentation
> after "NULL," instead of adding a temporary variable.
Breaking the line after NULL, seems reasonable, I'd be happy to merge that.
-Daniel
>
>
> BR,
> Jani.
>
> > if (ret >= 0) {
> > /*
> >* Set up the object linking under the protection of the idr
>
> --
> Jani Nikula, Intel Open Source Graphics Center
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/87a7mudu8t.fsf%40intel.com.
> For more options, visit https://groups.google.com/d/optout.
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108585] *ERROR* hw_init of IP block failed -22
https://bugs.freedesktop.org/show_bug.cgi?id=108585 --- Comment #14 from Alex Deucher --- Created attachment 142303 --> https://bugs.freedesktop.org/attachment.cgi?id=142303&action=edit possible fix (In reply to Benjamin Herrenschmidt from comment #12) > We have no control on what firmware is loaded by the target distro so the > right thing is going to reset the adapter. > > We'll probably need to add something to the amdgpu shutdown() path to force > an adapter reset. Does the attached patch help? I'd been hesitant to add reset to the shutdown path because it adds latency to the regular shutdown path and users complain when that slows down. > > Do you have details of what specific PCIe config space write you use ? FLR ? The reset sequence is asic specific. older parts just happened to use PCI config space to trigger a GPU reset via an AMD specific sequence. Newer GPUs reset via the PSP. FLR is only available on SR-IOV capable skus so it's not a general solution. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Remove 80-column line in drm_mode_object.c
On Wed, 31 Oct 2018, Shayenne da Luz Moura wrote:
> Add a new variable to make the drm_mode_object comparison before
> idr_alloc and decrease line size.
>
> Signed-off-by: Shayenne da Luz Moura
> ---
> drivers/gpu/drm/drm_mode_object.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_mode_object.c
> b/drivers/gpu/drm/drm_mode_object.c
> index be8b754eaf60..4b9eafddb409 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -36,9 +36,10 @@ int __drm_mode_object_add(struct drm_device *dev, struct
> drm_mode_object *obj,
> void (*obj_free_cb)(struct kref *kref))
> {
> int ret;
> + struct drm_mode_object *obj_tmp = register_obj ? obj : NULL;
>
> mutex_lock(&dev->mode_config.idr_mutex);
> - ret = idr_alloc(&dev->mode_config.crtc_idr, register_obj ? obj : NULL,
> 1, 0, GFP_KERNEL);
> + ret = idr_alloc(&dev->mode_config.crtc_idr, obj_tmp, 1, 0, GFP_KERNEL);
Please don't send checkpatch "fixes" to adhere to the 80-column rule. Or
at least use --max-line-length=100 or something to look for worse
offenders than this.
And if you insist, please just add a newline and proper indentation
after "NULL," instead of adding a temporary variable.
BR,
Jani.
> if (ret >= 0) {
> /*
>* Set up the object linking under the protection of the idr
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107947] REG_WAIT timeout 10us * 3500 tries - dce_mi_free_dmif line:563 during boot
https://bugs.freedesktop.org/show_bug.cgi?id=107947 --- Comment #7 from Alex Smith --- This is occurring for me on a Vega 64. When it occurs the machine boots to a black screen. It has started happening since upgrading to Fedora 27's 4.18.16, previously I was on 4.18.7 (does not happen there). I've since updated to Fedora 29, 4.18.16-300.fc29.x86_64, and it still happens there. [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3500 tries - dce_mi_free_dmif line:636 WARNING: CPU: 6 PID: 122 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254 generic_reg_wait+0xe8/0x160 [amdgpu] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c tun bridge stp llc ebtable_filter ebtables > ttm alx drm crc32c_intel mdio video CPU: 6 PID: 122 Comm: kworker/6:1 Not tainted 4.18.16-100.fc27.x86_64 #1 Hardware name: Gigabyte Technology Co., Ltd. Z170X-Gaming 3/Z170X-Gaming 3, BIOS F7 06/03/2016 Workqueue: events drm_mode_rmfb_work_fn [drm] RIP: 0010:generic_reg_wait+0xe8/0x160 [amdgpu] Code: 58 48 8b 4c 24 50 89 ee 8b 54 24 48 48 c7 c7 e0 93 75 c0 44 89 4c 24 08 e8 b5 4f c1 ff 41 83 7c 24 20 01 44 8b 4c 24 08 74 02 <0f> 0b 48 83 c4 10 44 89 c8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f af RSP: 0018:b846441e7a78 EFLAGS: 00010297 RAX: RBX: 0dad RCX: RDX: RSI: 9365c1d96938 RDI: 9365c1d96938 RBP: 000a R08: 0473 R09: 0002 R10: beee R11: 889a21ed R12: 93659551d900 R13: 35af R14: 0010 R15: 0001 FS: () GS:9365c1d8() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0250e080 CR3: 0005e720a005 CR4: 003606e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: dce_mi_free_dmif+0xf7/0x180 [amdgpu] dce110_reset_hw_ctx_wrap+0x13f/0x1e0 [amdgpu] dce110_apply_ctx_to_hw+0x58/0x9e0 [amdgpu] ? _cond_resched+0x15/0x40 ? pp_dpm_dispatch_tasks+0x41/0x60 [amdgpu] ? amdgpu_pm_compute_clocks.part.9+0xb7/0x590 [amdgpu] dc_commit_state+0x30a/0x590 [amdgpu] amdgpu_dm_atomic_commit_tail+0x385/0xd70 [amdgpu] ? _cond_resched+0x15/0x40 ? wait_for_completion_timeout+0x3a/0x190 ? wait_for_completion_interruptible+0x35/0x1c0 commit_tail+0x3d/0x70 [drm_kms_helper] drm_atomic_helper_commit+0xfc/0x110 [drm_kms_helper] drm_framebuffer_remove+0x30d/0x400 [drm] drm_mode_rmfb_work_fn+0x4f/0x60 [drm] process_one_work+0x18f/0x370 worker_thread+0x30/0x380 ? process_one_work+0x370/0x370 kthread+0x113/0x130 ? kthread_create_worker_on_cpu+0x70/0x70 ret_from_fork+0x35/0x40 ---[ end trace 9529270edb28c719 ]--- -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Remove 80-column line in drm_mode_object.c
Add a new variable to make the drm_mode_object comparison before
idr_alloc and decrease line size.
Signed-off-by: Shayenne da Luz Moura
---
drivers/gpu/drm/drm_mode_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mode_object.c
b/drivers/gpu/drm/drm_mode_object.c
index be8b754eaf60..4b9eafddb409 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -36,9 +36,10 @@ int __drm_mode_object_add(struct drm_device *dev, struct
drm_mode_object *obj,
void (*obj_free_cb)(struct kref *kref))
{
int ret;
+ struct drm_mode_object *obj_tmp = register_obj ? obj : NULL;
mutex_lock(&dev->mode_config.idr_mutex);
- ret = idr_alloc(&dev->mode_config.crtc_idr, register_obj ? obj : NULL,
1, 0, GFP_KERNEL);
+ ret = idr_alloc(&dev->mode_config.crtc_idr, obj_tmp, 1, 0, GFP_KERNEL);
if (ret >= 0) {
/*
* Set up the object linking under the protection of the idr
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/4] drm: Document variable refresh properties
On 10/31/18 10:12 AM, Michel Dänzer wrote: > On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote: >> On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote: >>> On 10/30/18 5:29 AM, Michel Dänzer wrote: On 2018-10-29 7:03 p.m., Ville Syrjälä wrote: > On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote: >> On 2018-10-26 7:59 p.m., Ville Syrjälä wrote: >>> On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote: On 10/26/18 10:53 AM, Ville Syrjälä wrote: > > Speaking of timestamps. What is the expected behaviour of vblank > timestamps when vrr is enabled? When vrr is enabled the duration of the vertical front porch will be extended until flip or timeout occurs. The vblank timestamp will vary based on duration of the vertical front porch. The min/max duration for the front porch can be specified by the driver via the min/max range. No changes to vblank timestamping handling should be necessary to accommodate variable refresh rate. >>> >>> The problem is that the timestamp is supposed to correspond to the first >>> active pixel. And since we don't know how long the front porch will be >>> we can't realistically report the true value. So I guess just assuming >>> min front porch length is as good as anything else? >> >> That (and documenting that the timestamp corresponds to the earliest >> possible first active pixel, not necessarily the actual one, with VRR) >> might be good enough for the actual vblank event timestamps. >> >> >> However, I'm not so sure about the timestamps of page flip completion >> events. Those could be very misleading if the flip completes towards the >> timeout, which could result in bad behaviour of applications which use >> them for animation timing. >> >> Maybe the timestamp could be updated appropriately (yes, I'm hand-waving >> :) in drm_crtc_send_vblank_event? > > Hmm. Updated how? Whether it's a page flip event or vblank even we won't > know when the first active pixel will come. Although I suppose if > there is some kind of vrr slew rate limit we could at least account > for that to report a more correct "this is the earliest you migth be > able to see your frame" timestamp. > > Oh, or are you actually saying that shceduling a new flip before the > timeout is actually going to latch that flip immediately? I figured > that the flip would get latched on the next start of vblank regardless, > and the act of scheduling a flip will just kick the hardware to start > scanning the previously latched frame earlier. > > scanout A | ... vblank | scanout A | ... vblank | scanout B | ... vblank > ^^^ ^ > ||flip C latch C > flip B latch B This would kind of defeat the point of VRR, wouldn't it? If a flip was scheduled after the start of vblank, the vblank would always time out, resulting in the minimum refresh rate. > scanout A | ... vblank | scanout B | ... vblank | scanout C | ... vblank > ^ ^ ^ ^ > | latch B| latch C > flip B flip C So this is what happens. Regardless, when the flip is latched, AMD hardware generates a "pflip" interrupt, and its handler calls drm_crtc_send_vblank_event (and in the case of DC drm_crtc_accurate_vblank_count before that). So the time when drm_crtc_send_vblank_event is called might be a good approximation of when scanout of the next frame starts. Another possibility might be to wait for the hardware vline counter to wrap around to 0 before calling drm_crtc_accurate_vblank_count, then the calculations should be based on 0 instead of crtc_vtotal. >>> >>> >>> I understand the issue you're describing now. The timestamp is supposed >>> to signify the end of the current vblank. The call to get scanout >>> position is supposed to return the number of lines until scanout (a >>> negative value) or the number of lines since the next scanout began (a >>> positive value). >>> >>> The amdgpu driver calculates the number of lines based on a hardware >>> register status position which returns an increasing value from 0 that >>> indicates the current vpos/hpos for the display. >>> >>> For any vpos below vbl_start we know the value is correct since the next >>> vblank hasn't begun yet. But for anythign about vbl_start it's probably >>> wrong since it applies a corrective offset based on the fixed value of >>> crtc_vtotal. It's even worse when the value is above crtc_vtotal since >>> it'll be calculating the number of lines since the last scan
[GIT PULL] fbdev changes for v4.20
Hi Linus, Please pull fbdev changes for v4.20. No major changes to the subsystem itself, mainly fb drivers fixes & cleanups (atyfb & udlfb updates stand out from the rest) + removal of no longer needed old clps711xfb driver. Please see the signed tag description for details. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics The following changes since commit 0238df646e6224016a45505d2c111a24669ebe21: Linux 4.19-rc7 (2018-10-07 17:26:02 +0200) are available in the git repository at: https://github.com/bzolnier/linux.git tags/fbdev-v4.20 for you to fetch changes up to 217188d9f985bd3ce8c9a0cd50ca35be62d0f8c6: video: fbdev: remove redundant 'default n' from Kconfig-s (2018-10-24 11:26:32 +0200) fbdev changes for v4.20: - update atyfb driver - improvements for ATI Mach64 chips: detect the dot clock divider correctly on Sparc, fix display corruptions (due to endianness issues and improper reading of accelerator registers), optimize scrolling performance and also fix debugging printks (Mikulas Patocka) - rewrite USB unplug handling in udlfb driver using framebuffer subsystem reference counting (Mikulas Patocka) - fix support for native-mode display-timings in atmel_lcdfb driver (Sam Ravnborg) - fix information leak & add missing access_ok() checks in sbuslib (Dan Carpenter) - allow using GPIO expanders that can sleep in ssd1307fb driver (Michal Vokáč) - convert omapfb driver to use GPIO descriptors instead of GPIO numbers for Amstrad Delta board (Janusz Krzysztofik) - fix broken Kconfig menu dependencies (Randy Dunlap) - convert fbdev subsystem to use %pOFn instead of device_node.name (Rob Herring) - remove the dead old CLPS711x LCD support driver (the new CLPS711x LCD support driver is still available) - misc fixes (Jia-Ju Bai, Gustavo A. R. Silva) - misc cleanups (Mehdi Bounya, Nathan Chancellor, YueHaibing) Bartlomiej Zolnierkiewicz (4): Merge tag 'v4.19-rc7' of https://git.kernel.org/.../torvalds/linux into fbdev-for-next Revert "video: ssd1307fb: Do not hard code active-low reset sequence" video: fbdev: remove dead old CLPS711x LCD support driver video: fbdev: remove redundant 'default n' from Kconfig-s Dan Carpenter (2): fbdev: sbuslib: use checked version of put_user() fbdev: sbuslib: integer overflow in sbusfb_ioctl_helper() Gustavo A. R. Silva (1): video: fbdev: arcfb: mark expected switch fall-through Janusz Krzysztofik (1): video: fbdev: omapfb: lcd_ams_delta: use GPIO lookup table Jia-Ju Bai (1): video: fbdev: add the dependency of broadsheetfb in Kconfig Mehdi Bounya (1): Video: vgastate: fixed a spacing coding style Michal Vokáč (2): video: ssd1307fb: Use gpiod_set_value_cansleep() for reset video: ssd1307fb: Do not hard code active-low reset sequence Mikulas Patocka (6): udlfb: handle unplug properly mach64: detect the dot clock divider correctly on sparc mach64: fix display corruption on big endian machines mach64: fix image corruption due to reading accelerator registers mach64: optimize wait_for_fifo atyfb: fix debugging printks Nathan Chancellor (1): video: fbdev: sis: Remove unnecessary parentheses and commented code Randy Dunlap (1): fbdev: fix broken menu dependencies Rob Herring (1): fbdev: Convert to using %pOFn instead of device_node.name Sam Ravnborg (1): atmel_lcdfb: support native-mode display-timings YueHaibing (1): pxa168fb: remove set but not used variables 'mi' drivers/video/fbdev/Kconfig | 59 + drivers/video/fbdev/Makefile | 1 - drivers/video/fbdev/arcfb.c | 2 + drivers/video/fbdev/atmel_lcdfb.c| 43 +--- drivers/video/fbdev/aty/atyfb.h | 15 +- drivers/video/fbdev/aty/atyfb_base.c | 43 ++-- drivers/video/fbdev/aty/mach64_accel.c | 32 ++- drivers/video/fbdev/aty/mach64_ct.c | 10 +- drivers/video/fbdev/cg14.c | 4 +- drivers/video/fbdev/cg3.c| 2 +- drivers/video/fbdev/clps711xfb.c | 314 --- drivers/video/fbdev/core/fbmon.c | 4 +- drivers/video/fbdev/imsttfb.c| 2 +- drivers/video/fbdev/leo.c| 2 +- drivers/video/fbdev/mmp/hw/Kconfig | 1 - drivers/video/fbdev/mmp/panel/Kconfig| 1 - drivers/video/fbdev/offb.c | 12 +- drivers/video/fbdev/omap/lcd_ams_delta.c | 55 ++--- drivers/video/fbdev/omap2/omapfb/dss/Kconfig | 7 - drivers/video/fbdev/p9100.c | 2 +- drivers/video/fbdev/pxa168fb.c | 3 - drivers/video/fbdev/sbuslib.c| 28 +-- drivers/video/fbdev/sis/init301.c
Re: [PATCH v4 3/4] drm: Document variable refresh properties
On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote: > On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote: >> On 10/30/18 5:29 AM, Michel Dänzer wrote: >>> On 2018-10-29 7:03 p.m., Ville Syrjälä wrote: On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote: > On 2018-10-26 7:59 p.m., Ville Syrjälä wrote: >> On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote: >>> On 10/26/18 10:53 AM, Ville Syrjälä wrote: Speaking of timestamps. What is the expected behaviour of vblank timestamps when vrr is enabled? >>> >>> When vrr is enabled the duration of the vertical front porch will be >>> extended until flip or timeout occurs. The vblank timestamp will vary >>> based on duration of the vertical front porch. The min/max duration for >>> the front porch can be specified by the driver via the min/max range. >>> >>> No changes to vblank timestamping handling should be necessary to >>> accommodate variable refresh rate. >> >> The problem is that the timestamp is supposed to correspond to the first >> active pixel. And since we don't know how long the front porch will be >> we can't realistically report the true value. So I guess just assuming >> min front porch length is as good as anything else? > > That (and documenting that the timestamp corresponds to the earliest > possible first active pixel, not necessarily the actual one, with VRR) > might be good enough for the actual vblank event timestamps. > > > However, I'm not so sure about the timestamps of page flip completion > events. Those could be very misleading if the flip completes towards the > timeout, which could result in bad behaviour of applications which use > them for animation timing. > > Maybe the timestamp could be updated appropriately (yes, I'm hand-waving > :) in drm_crtc_send_vblank_event? Hmm. Updated how? Whether it's a page flip event or vblank even we won't know when the first active pixel will come. Although I suppose if there is some kind of vrr slew rate limit we could at least account for that to report a more correct "this is the earliest you migth be able to see your frame" timestamp. Oh, or are you actually saying that shceduling a new flip before the timeout is actually going to latch that flip immediately? I figured that the flip would get latched on the next start of vblank regardless, and the act of scheduling a flip will just kick the hardware to start scanning the previously latched frame earlier. scanout A | ... vblank | scanout A | ... vblank | scanout B | ... vblank ^^^ ^ ||flip C latch C flip B latch B >>> >>> This would kind of defeat the point of VRR, wouldn't it? If a flip was >>> scheduled after the start of vblank, the vblank would always time out, >>> resulting in the minimum refresh rate. >>> >>> scanout A | ... vblank | scanout B | ... vblank | scanout C | ... vblank ^ ^ ^ ^ | latch B| latch C flip B flip C >>> >>> So this is what happens. >>> >>> Regardless, when the flip is latched, AMD hardware generates a "pflip" >>> interrupt, and its handler calls drm_crtc_send_vblank_event (and in the >>> case of DC drm_crtc_accurate_vblank_count before that). So the time when >>> drm_crtc_send_vblank_event is called might be a good approximation of >>> when scanout of the next frame starts. >>> >>> Another possibility might be to wait for the hardware vline counter to >>> wrap around to 0 before calling drm_crtc_accurate_vblank_count, then the >>> calculations should be based on 0 instead of crtc_vtotal. >> >> >> I understand the issue you're describing now. The timestamp is supposed >> to signify the end of the current vblank. The call to get scanout >> position is supposed to return the number of lines until scanout (a >> negative value) or the number of lines since the next scanout began (a >> positive value). >> >> The amdgpu driver calculates the number of lines based on a hardware >> register status position which returns an increasing value from 0 that >> indicates the current vpos/hpos for the display. >> >> For any vpos below vbl_start we know the value is correct since the next >> vblank hasn't begun yet. But for anythign about vbl_start it's probably >> wrong since it applies a corrective offset based on the fixed value of >> crtc_vtotal. It's even worse when the value is above crtc_vtotal since >> it'll be calculating the number of lines since the last scanout since >> it'll be a positive value. >> >> So the issue becomes determining when the vfront porch will end. >> >> When the flip address gets
Re: [PATCH v4 3/4] drm: Document variable refresh properties
On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote: > On 10/30/18 5:29 AM, Michel Dänzer wrote: >> On 2018-10-29 7:03 p.m., Ville Syrjälä wrote: >>> On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote: On 2018-10-26 7:59 p.m., Ville Syrjälä wrote: > On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote: >> On 10/26/18 10:53 AM, Ville Syrjälä wrote: >>> >>> Speaking of timestamps. What is the expected behaviour of vblank >>> timestamps when vrr is enabled? >> >> When vrr is enabled the duration of the vertical front porch will be >> extended until flip or timeout occurs. The vblank timestamp will vary >> based on duration of the vertical front porch. The min/max duration for >> the front porch can be specified by the driver via the min/max range. >> >> No changes to vblank timestamping handling should be necessary to >> accommodate variable refresh rate. > > The problem is that the timestamp is supposed to correspond to the first > active pixel. And since we don't know how long the front porch will be > we can't realistically report the true value. So I guess just assuming > min front porch length is as good as anything else? That (and documenting that the timestamp corresponds to the earliest possible first active pixel, not necessarily the actual one, with VRR) might be good enough for the actual vblank event timestamps. However, I'm not so sure about the timestamps of page flip completion events. Those could be very misleading if the flip completes towards the timeout, which could result in bad behaviour of applications which use them for animation timing. Maybe the timestamp could be updated appropriately (yes, I'm hand-waving :) in drm_crtc_send_vblank_event? >>> >>> Hmm. Updated how? Whether it's a page flip event or vblank even we won't >>> know when the first active pixel will come. Although I suppose if >>> there is some kind of vrr slew rate limit we could at least account >>> for that to report a more correct "this is the earliest you migth be >>> able to see your frame" timestamp. >>> >>> Oh, or are you actually saying that shceduling a new flip before the >>> timeout is actually going to latch that flip immediately? I figured >>> that the flip would get latched on the next start of vblank regardless, >>> and the act of scheduling a flip will just kick the hardware to start >>> scanning the previously latched frame earlier. >>> >>> scanout A | ... vblank | scanout A | ... vblank | scanout B | ... vblank >>> ^^^ ^ >>> ||flip C latch C >>> flip B latch B >> >> This would kind of defeat the point of VRR, wouldn't it? If a flip was >> scheduled after the start of vblank, the vblank would always time out, >> resulting in the minimum refresh rate. >> >> >>> scanout A | ... vblank | scanout B | ... vblank | scanout C | ... vblank >>> ^ ^ ^ ^ >>> | latch B| latch C >>> flip B flip C >> >> So this is what happens. >> >> Regardless, when the flip is latched, AMD hardware generates a "pflip" >> interrupt, and its handler calls drm_crtc_send_vblank_event (and in the >> case of DC drm_crtc_accurate_vblank_count before that). So the time when >> drm_crtc_send_vblank_event is called might be a good approximation of >> when scanout of the next frame starts. >> >> Another possibility might be to wait for the hardware vline counter to >> wrap around to 0 before calling drm_crtc_accurate_vblank_count, then the >> calculations should be based on 0 instead of crtc_vtotal. >> >> > > > I understand the issue you're describing now. The timestamp is supposed > to signify the end of the current vblank. The call to get scanout > position is supposed to return the number of lines until scanout (a > negative value) or the number of lines since the next scanout began (a > positive value). > > The amdgpu driver calculates the number of lines based on a hardware > register status position which returns an increasing value from 0 that > indicates the current vpos/hpos for the display. > > For any vpos below vbl_start we know the value is correct since the next > vblank hasn't begun yet. But for anythign about vbl_start it's probably > wrong since it applies a corrective offset based on the fixed value of > crtc_vtotal. It's even worse when the value is above crtc_vtotal since > it'll be calculating the number of lines since the last scanout since > it'll be a positive value. > > So the issue becomes determining when the vfront porch will end. > > When the flip address gets written the vfront porch will end at the > start of the next line leaving only the back porch plus part of the > line. But we don't know w
Re: [PATCH v6 12/28] drm/i915/dp: Add DSC params and DSC config to intel_crtc_state
On Tue, Oct 30, 2018 at 04:53:49PM -0700, Manasi Navare wrote:
> On Wed, Oct 24, 2018 at 03:28:24PM -0700, Manasi Navare wrote:
> > Basic DSC parameters and DSC configuration data needs to be computed
> > for each of the requested mode during atomic check. This is
> > required since for certain modes, valid DSC parameters and config
> > data might not be computed in which case compression cannot be
> > enabled for that mode.
> > For that reason we need to add these params and config structure
> > to the intel_crtc_state so that if valid this state information
> > can directly be used while enabling DSC in atomic commit.
> >
> > v2:
> > * Rebase on drm-tip (Manasi)
> >
> > Cc: Gaurav K Singh
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_drv.h | 9 +
> > 2 files changed, 10 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 2d7761b8ac07..45fd7894722b 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -53,6 +53,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "i915_params.h"
> > #include "i915_reg.h"
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 62c051098859..27d47950f438 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -931,6 +931,15 @@ struct intel_crtc_state {
> >
> > /* Output down scaling is done in LSPCON device */
> > bool lspcon_downsampling;
> > +
> > + /* Display Stream compression state */
> > + struct {
> > + bool compression_enable;
> > + bool dsc_split;
> > + u16 compressed_bpp;
> > + u8 slice_count;
> > + } dsc_params;
> > + struct drm_dsc_config dp_dsc_cfg;
>
> Ville, Jani should this be defined as a pointer to struct drm_dsc_config?
> struct drm_dsc_config *dp_dsc_cfg
> since we populate this in intel_dp_compute_config and then on only read during
> commit.
Pointer to where exactly? You need the memory for it somewhere.
>
> Manasi
>
> > };
> >
> > struct intel_crtc {
> > --
> > 2.18.0
> >
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 22/28] drm/i915/dp: Populate DSC PPS SDP and send PPS infoframes
On Tue, Oct 30, 2018 at 04:45:35PM -0700, Manasi Navare wrote:
> On Thu, Oct 25, 2018 at 05:09:42PM +0300, Ville Syrjälä wrote:
> > On Wed, Oct 24, 2018 at 03:28:34PM -0700, Manasi Navare wrote:
> > > DSC PPS secondary data packet infoframes are filled with
> > > DSC picure parameter set metadata according to the DSC standard.
> > > These infoframes are sent to the sink device and used during DSC
> > > decoding.
> > >
> > > v2:
> > > * Rebase ond drm-tip
> > >
> > > Cc: Jani Nikula
> > > Cc: Ville Syrjala
> > > Cc: Anusha Srivatsa
> > > Signed-off-by: Manasi Navare
> > > Reviewed-by: Anusha Srivatsa
> > > ---
> > > drivers/gpu/drm/i915/intel_vdsc.c | 21 +
> > > 1 file changed, 21 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
> > > b/drivers/gpu/drm/i915/intel_vdsc.c
> > > index b0fc716bbbfd..4b4b812d68f3 100644
> > > --- a/drivers/gpu/drm/i915/intel_vdsc.c
> > > +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> > > @@ -988,6 +988,25 @@ static void
> > > intel_configure_pps_for_dsc_encoder(struct intel_encoder *encoder,
> > > }
> > > }
> > >
> > > +static void intel_dp_send_dsc_pps_sdp(struct intel_encoder *encoder,
> > > + struct intel_crtc_state *crtc_state)
> >
> > const crtc_state
>
> Changing this to const crtc_state started giving me an error when I get the
> struct drm_dsc_config *vdsc_cfg = &crtc_state->dp_dsc_cfg;
const struct drm_dsc_config ...
>
> So this is making me think that since dp_dsc_cfg is written during
> compute_config,
> and there on we just read it, we dont need to pass *vdsc_cfg , we can
> just pass the struct directly right?
Not sure what you're asking here.
>
> Manasi
>
> >
> > s/send/write/ ?
> >
> > > +{
> > > + struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> > > + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > > + struct drm_dsc_config *vdsc_cfg = &crtc_state->dp_dsc_cfg;
> > > + struct drm_dsc_pps_infoframe dp_dsc_pps_sdp;
> > > +
> > > + /* Prepare DP SDP PPS header as per DP 1.4 spec, Table 2-123 */
> > > + drm_dsc_dp_pps_header_init(&dp_dsc_pps_sdp);
> > > +
> > > + /* Fill the PPS payload bytes as per DSC spec 1.2 Table 4-1 */
> > > + drm_dsc_pps_infoframe_pack(&dp_dsc_pps_sdp, vdsc_cfg);
> > > +
> > > + intel_dig_port->write_infoframe(encoder, crtc_state,
> > > + DP_SDP_PPS, &dp_dsc_pps_sdp,
> > > + sizeof(dp_dsc_pps_sdp));
> > > +}
> > > +
> > > void intel_dsc_enable(struct intel_encoder *encoder,
> > > struct intel_crtc_state *crtc_state)
> > > {
> > > @@ -997,5 +1016,7 @@ void intel_dsc_enable(struct intel_encoder *encoder,
> > >
> > > intel_configure_pps_for_dsc_encoder(encoder, crtc_state);
> > >
> > > + intel_dp_send_dsc_pps_sdp(encoder, crtc_state);
> > > +
> > > return;
> > > }
> > > --
> > > 2.18.0
> >
> > --
> > Ville Syrjälä
> > Intel
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omap4: support for manually updated display
Hi Tony, On Saturday, 20 October 2018 03:38:12 EET Tony Lindgren wrote: > * Sebastian Reichel [181019 15:58]: > > I uploaded my current status here. It's not based on the newest > > -next, but contains the interesting patches from Laurent. Also > > the last few patches are not yet cleaned up, sorry for the mess. > > Way to go, thanks :) Here's a quick fix for issues with loading > and unloading modules, seems like this should be fixed somewhere > else though? Thanks for the report, I'll have a look at this. > 8< --- > Unload of hdmi: > > Unable to handle kernel NULL pointer dereference at virtual address 0278 > (hdmi_runtime_resume [omapdss]) from [] > (__rpm_callback+0x144/0x1d8) (__rpm_callback) from [] > (rpm_callback+0x20/0x80) > (rpm_callback) from [] (rpm_resume+0x60c/0x828) > (rpm_resume) from [] (__pm_runtime_resume+0x4c/0x64) > (__pm_runtime_resume) from [] > (device_release_driver_internal+0x130/0x234) > (device_release_driver_internal) from [] > (driver_detach+0x38/0x6c) (driver_detach) from [] > (bus_remove_driver+0x4c/0xa4) > (bus_remove_driver) from [] > (platform_unregister_drivers+0x20/0x2c) (platform_unregister_drivers) from > [] (sys_delete_module+0x1c0/0x230) (sys_delete_module) from > [] (ret_fast_syscall+0x0/0x28) > > > Unload of dsi: > > Unable to handle kernel NULL pointer dereference at virtual address 0278 > (dsi_runtime_resume [omapdss]) from [] > (__rpm_callback+0x144/0x1d8) (__rpm_callback) from [] > (rpm_callback+0x20/0x80) > (rpm_callback) from [] (rpm_resume+0x60c/0x828) > (rpm_resume) from [] (__pm_runtime_resume+0x4c/0x64) > (__pm_runtime_resume) from [] (driver_probe_device+0x38/0x164) > (driver_probe_device) from [] (__driver_attach+0xe4/0xe8) > (__driver_attach) from [] (bus_for_each_dev+0x70/0xb4) > (bus_for_each_dev) from [] (bus_add_driver+0x198/0x1fc) > (bus_add_driver) from [] (driver_register+0x74/0x108) > (driver_register) from [] (do_one_initcall+0x80/0x31c) > (do_one_initcall) from [] (do_init_module+0x5c/0x1f8) > (do_init_module) from [] (load_module+0x1360/0x16c0) > (load_module) from [] (sys_finit_module+0xbc/0xdc) > (sys_finit_module) from [] (ret_fast_syscall+0x0/0x28) > > diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c > b/drivers/gpu/drm/omapdrm/dss/dsi.c --- a/drivers/gpu/drm/omapdrm/dss/dsi.c > +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c > @@ -5484,6 +5484,9 @@ static int dsi_runtime_resume(struct device *dev) > struct dsi_data *dsi = dev_get_drvdata(dev); > int r; > > + if (!dsi || !dsi->dss || !dsi->dss->dispc) > + return -ENODEV; > + > r = dispc_runtime_get(dsi->dss->dispc); > if (r) > return r; > diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c > b/drivers/gpu/drm/omapdrm/dss/hdmi4.c --- > a/drivers/gpu/drm/omapdrm/dss/hdmi4.c > +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c > @@ -847,6 +847,9 @@ static int hdmi_runtime_resume(struct device *dev) > struct omap_hdmi *hdmi = dev_get_drvdata(dev); > int r; > > + if (!hdmi || !hdmi->dss || !hdmi->dss->dispc) > + return -ENODEV; > + > r = dispc_runtime_get(hdmi->dss->dispc); > if (r < 0) > return r; -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #39 from Allan --- I can't clone the git repo using command : "git clone git://people.freedesktop.org/~agd5f/linux" Firstly it was checksum errors, found that the processor had a bug, replaced it through warranty process, and now I'm getting : " Cloning into 'linux'... remote: Enumerating objects: 6619592, done. remote: Counting objects: 100% (6619592/6619592), done. remote: Compressing objects: 100% (989580/989580), done. remote: Total 6619592 (delta 5587252), reused 6617842 (delta 5585574) Receiving objects: 100% (6619592/6619592), 1.18 GiB | 896.00 KiB/s, done. Resolving deltas: 100% (5587252/5587252), done. fatal: did not receive expected object 22906b31d43fbb88c62d2f4b18c5bd2d0e3cebc1 fatal: index-pack failed " I get this error even using : "git clone -b amd-staging-drm-next --single-branch git://people.freedesktop.org/~agd5f/linux" Any tip for me? Am I doing any mistake? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/syncobj: Mark local add/remove callback functions as static
drivers/gpu/drm/drm_syncobj.c:181:6: warning: no previous prototype for
‘drm_syncobj_add_callback’ [-Wmissing-prototypes]
drivers/gpu/drm/drm_syncobj.c:190:6: warning: no previous prototype for
‘drm_syncobj_remove_callback’ [-Wmissing-prototypes]
Fixing that leads to
drivers/gpu/drm/drm_syncobj.c:181:13: warning: ‘drm_syncobj_add_callback’
defined but not used [-Wunused-function]
so remove the unused drm_syncobj_add_callback() entirely.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index d3e2335b88f9..4dca5f7e8c4b 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -123,9 +123,9 @@ struct drm_syncobj *drm_syncobj_find(struct drm_file
*file_private,
}
EXPORT_SYMBOL(drm_syncobj_find);
-static struct dma_fence
-*drm_syncobj_find_signal_pt_for_point(struct drm_syncobj *syncobj,
- uint64_t point)
+static struct dma_fence *
+drm_syncobj_find_signal_pt_for_point(struct drm_syncobj *syncobj,
+uint64_t point)
{
struct drm_syncobj_signal_pt *signal_pt;
@@ -178,17 +178,8 @@ static void drm_syncobj_fence_get_or_add_callback(struct
drm_syncobj *syncobj,
mutex_unlock(&syncobj->cb_mutex);
}
-void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
- struct drm_syncobj_cb *cb,
- drm_syncobj_func_t func)
-{
- mutex_lock(&syncobj->cb_mutex);
- drm_syncobj_add_callback_locked(syncobj, cb, func);
- mutex_unlock(&syncobj->cb_mutex);
-}
-
-void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
-struct drm_syncobj_cb *cb)
+static void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
+ struct drm_syncobj_cb *cb)
{
mutex_lock(&syncobj->cb_mutex);
list_del_init(&cb->node);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108486] Incompatible result.json generation between igt_runner and piglit summary
https://bugs.freedesktop.org/show_bug.cgi?id=108486 Petri Latvala changed: What|Removed |Added Status|VERIFIED|CLOSED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v2 1/2] drm: Add colorspace property
This patch adds a colorspace property enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_connector.c | 44 +++
include/drm/drm_connector.h | 7 +++
include/drm/drm_mode_config.h | 6 ++
include/uapi/drm/drm_mode.h | 24 +
5 files changed, 85 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f31..9e1d46b 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -721,6 +721,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == config->content_type_property) {
state->content_type = val;
+ } else if (property == config->colorspace_property) {
+ state->colorspace = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -795,6 +797,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == config->colorspace_property) {
+ *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index aa18b1d..5ad52a0 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,38 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
};
DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+static const struct drm_prop_enum_list colorspace[] = {
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { COLORIMETRY_ITU_601, "601" },
+ { COLORIMETRY_ITU_709, "709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_601, "601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_709, "709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { COLORIMETRY_S_YCC_601, "s601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { COLORIMETRY_ADOBE_YCC_601, "adobe601" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { COLORIMETRY_ADOBE_RGB, "adobe_rgb" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { COLORIMETRY_BT2020_RGB, "BT2020_rgb" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { COLORIMETRY_BT2020_YCC, "BT2020_ycc" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { COLORIMETRY_BT2020_CYCC, "BT2020_cycc" },
+ /* DP MSA Colorimetry */
+ { COLORIMETRY_Y_CBCR_ITU_601, "YCBCR_ITU_601" },
+ { COLORIMETRY_Y_CBCR_ITU_709, "YCBCR_ITU_709" },
+ { COLORIMETRY_SRGB, "SRGB" },
+ { COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide Gamut" },
+ { COLORIMETRY_SCRGB, "SCRGB" },
+ { COLORIMETRY_DCI_P3, "DCIP3" },
+ { COLORIMETRY_CUSTOM_COLOR_PROFILE, "Custom Proflie" },
+ /* FOR HD 720p+, Default Colorimetry is based on ITU-R BT.709 */
+ { COLORIMETRY_DEFAULT, "Default: ITU_709" },
+};
+
/**
* DOC: standard connector properties
*
@@ -972,6 +1004,12 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
* can also expose this property to external outputs, in which case they
* must support "None", which should be the default (since external screens
* have a built-in scaler).
+ *
+ * colorspace:
+ * This property helps select a suitable colorspace based on the sink
+ * capability. Modern sink devices support wider gamut like BT2020.
+ * This helps switch to BT2020 mode if the BT2020 encoded video stream
+ * is being played by the user, same for any other colorspace.
*/
int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -1020,6 +1058,12 @@ int drm_connector_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.non_desktop_property = prop;
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
+ colorspace, ARRAY_SIZE(colorspace));
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_co
[v2 2/2] drm/i915: Attach colorspace property and enable modeset
This patch attaches the colorspace connector property to the hdmi connector. Based on colorspace change, modeset will be triggered to switch to new colorspace. Based on colorspace property value create an infoframe with appropriate colorspace. This can be used to send an infoframe packet with proper colorspace value set which will help to enable wider color gamut like BT2020 on sink. v2: Merged the changes of creating infoframe as well to this patch as per Maarten's suggestion. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_atomic.c | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 5 + 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c index a5a2c8f..35ef70a 100644 --- a/drivers/gpu/drm/i915/intel_atomic.c +++ b/drivers/gpu/drm/i915/intel_atomic.c @@ -125,6 +125,7 @@ int intel_digital_connector_atomic_check(struct drm_connector *conn, */ if (new_conn_state->force_audio != old_conn_state->force_audio || new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb || + new_state->colorspace != old_state->colorspace || new_conn_state->base.picture_aspect_ratio != old_conn_state->base.picture_aspect_ratio || new_conn_state->base.content_type != old_conn_state->base.content_type || new_conn_state->base.scaling_mode != old_conn_state->base.scaling_mode) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 129b880..8a41fb3 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -486,6 +486,8 @@ static void intel_hdmi_set_avi_infoframe(struct intel_encoder *encoder, else frame.avi.colorspace = HDMI_COLORSPACE_RGB; + frame.avi.extended_colorimetry = conn_state->colorspace; + drm_hdmi_avi_infoframe_quant_range(&frame.avi, adjusted_mode, crtc_state->limited_color_range ? HDMI_QUANTIZATION_RANGE_LIMITED : @@ -2125,6 +2127,9 @@ static void intel_hdmi_destroy(struct drm_connector *connector) intel_attach_broadcast_rgb_property(connector); intel_attach_aspect_ratio_property(connector); drm_connector_attach_content_type_property(connector); + drm_object_attach_property(&connector->base, + connector->dev->mode_config.colorspace_property, + COLORIMETRY_ITU_709); connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; } -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v2 0/2] Add Colorspace connector property interface
This patch series creates a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Kernel will not give the supported colorspaces since this is panel dependent and our curremt property infrastructure is not supporting it. Have tested this using xrandr by using below command: xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb" v2: Addressed Ville and Maarten's review comments. Merged the 2nd and 3rd patch into one common logical patch. Uma Shankar (2): drm: Add colorspace property drm/i915: Attach colorspace property and enable modeset drivers/gpu/drm/drm_atomic_uapi.c | 4 drivers/gpu/drm/drm_connector.c | 44 + drivers/gpu/drm/i915/intel_atomic.c | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 5 + include/drm/drm_connector.h | 7 ++ include/drm/drm_mode_config.h | 6 + include/uapi/drm/drm_mode.h | 24 7 files changed, 91 insertions(+) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2] MAINTAINERS: Add entry for VKMS
On 10/31, Daniel Vetter wrote: > On Wed, Oct 31, 2018 at 02:12:27AM +0300, Haneen Mohammed wrote: > > On Mon, Oct 22, 2018 at 08:31:42AM -0400, Sean Paul wrote: > > > On Sun, Oct 21, 2018 at 10:27:01PM -0300, Rodrigo Siqueira wrote: > > > > Add maintainers and reviewers for VKMS driver > > > > > > > > Signed-off-by: Rodrigo Siqueira > > > > > > Acked-by: Sean Paul > > > > > > > Reviewed-by: Haneen Mohammed > > Rodrigo, are you all set up with commit rights for drm-misc now? Yes! Daniel Stone already gave me permission :) I just have to study more about 'dim', in order to feel comfortable with the tool. > -Daniel > > > > > > > --- > > > > Changes in v2: > > > > - Insert the section in alphabetical order > > > > > > > > MAINTAINERS | 10 ++ > > > > 1 file changed, 10 insertions(+) > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > > index 39c3f6682ace..56572f0968ce 100644 > > > > --- a/MAINTAINERS > > > > +++ b/MAINTAINERS > > > > @@ -4733,6 +4733,16 @@ S: Odd Fixes > > > > F: drivers/gpu/drm/udl/ > > > > T: git git://anongit.freedesktop.org/drm/drm-misc > > > > > > > > +DRM DRIVER FOR VIRTUAL KERNEL MODESETTING (VKMS) > > > > +M: Rodrigo Siqueira > > > > +R: Haneen Mohammed > > > > +R: Daniel Vetter > > > > +T: git git://anongit.freedesktop.org/drm/drm-misc > > > > +S: Maintained > > > > +L: dri-devel@lists.freedesktop.org > > > > +F: drivers/gpu/drm/vkms/ > > > > +F: Documentation/gpu/vkms.rst > > > > + > > > > DRM DRIVER FOR VMWARE VIRTUAL GPU > > > > M: "VMware Graphics" > > > > M: Sinclair Yeh > > > > -- > > > > 2.19.1 > > > > > > > > > > -- > > > Sean Paul, Software Engineer, Google / Chromium OS > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Rodrigo Siqueira https://siqueira.tech https://twitter.com/siqueirajordao Graduate Student Department of Computer Science University of São Paulo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108585] *ERROR* hw_init of IP block failed -22
https://bugs.freedesktop.org/show_bug.cgi?id=108585 --- Comment #13 from Christian König --- (In reply to Benjamin Herrenschmidt from comment #12) > We'll probably need to add something to the amdgpu shutdown() path to force > an adapter reset. If that would be possible we would have already done that. The problem is that you do a full ASIC reset. So not only the GPU is affected, but also bridges, sound codecs etc... If any of those parts have a driver loaded while you do the reset you usually crash the system. Additional to that AFAIK this doesn't work on APUs. Because there the GPU is part of the CPU and so you would need to to reset both. How about stopping to use amdgpu in the boot loader? For just displaying a splash screen vesafb or efifb should do fine as well. > Do you have details of what specific PCIe config space write you use ? FLR ? Alex knows the details of that, but a FLR alone doesn't work AFAIK. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108542] hdmi issues with kernel 4.18
https://bugs.freedesktop.org/show_bug.cgi?id=108542 --- Comment #8 from davide26...@gmail.com --- (In reply to Nicholas Kazlauskas from comment #7) > Created attachment 142278 [details] [review] > 0001-Fix-unsigned-short-unsigned-long-mixup-for-usSymCloc.patch > > Does applying this patch help? > > Try this on top of the tree without reverting the other patches. Just tried, unfortunately it does not. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2] MAINTAINERS: Add entry for VKMS
On Wed, Oct 31, 2018 at 02:12:27AM +0300, Haneen Mohammed wrote: > On Mon, Oct 22, 2018 at 08:31:42AM -0400, Sean Paul wrote: > > On Sun, Oct 21, 2018 at 10:27:01PM -0300, Rodrigo Siqueira wrote: > > > Add maintainers and reviewers for VKMS driver > > > > > > Signed-off-by: Rodrigo Siqueira > > > > Acked-by: Sean Paul > > > > Reviewed-by: Haneen Mohammed Rodrigo, are you all set up with commit rights for drm-misc now? -Daniel > > > > --- > > > Changes in v2: > > > - Insert the section in alphabetical order > > > > > > MAINTAINERS | 10 ++ > > > 1 file changed, 10 insertions(+) > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index 39c3f6682ace..56572f0968ce 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -4733,6 +4733,16 @@ S: Odd Fixes > > > F: drivers/gpu/drm/udl/ > > > T: git git://anongit.freedesktop.org/drm/drm-misc > > > > > > +DRM DRIVER FOR VIRTUAL KERNEL MODESETTING (VKMS) > > > +M: Rodrigo Siqueira > > > +R: Haneen Mohammed > > > +R: Daniel Vetter > > > +T: git git://anongit.freedesktop.org/drm/drm-misc > > > +S: Maintained > > > +L: dri-devel@lists.freedesktop.org > > > +F: drivers/gpu/drm/vkms/ > > > +F: Documentation/gpu/vkms.rst > > > + > > > DRM DRIVER FOR VMWARE VIRTUAL GPU > > > M: "VMware Graphics" > > > M: Sinclair Yeh > > > -- > > > 2.19.1 > > > > > > > -- > > Sean Paul, Software Engineer, Google / Chromium OS -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] virgl: fence fd support
Hi Rob, On Thu, 25 Oct 2018 at 19:37, Robert Foss wrote: > > This series implements fence support for drm/virtio and > has been tested using qemu, kmscube and the below branches. > > Rob Herring solved a reference counting issue and > suggested a context check for the execbuf ioctl, his > changes have been included in the below commits to > keep the tree working at all commits. > I've put forward some mostly minor suggestions. The patches look pretty good but there's one piece missing: > > The linux series can be found here: > https://gitlab.collabora.com/robertfoss/linux/commits/virtio_fences_v3 > > As for mesa, the branch can be found here: > https://gitlab.collabora.com/robertfoss/mesa/commits/virtio_fences_v3 > Namely: This should be out for review. The kernel and userspace side of IOCTLs should happen roughly at the same time. Otherwise, there's a huge chance of merging one side of the component, while the other needs architectural changes. HTH Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/virtio: bump driver version after explicit synchronization addition
On Thu, 25 Oct 2018 at 19:38, Robert Foss wrote: > > From: Gustavo Padovan > > To reflect the (backward compatible) changes in the uabi we are bumping > the driver's version. > > Signed-off-by: Gustavo Padovan > Signed-off-by: Robert Foss Not strictly required, but doesn't hurt either. Reviewed-by: Emil Velikov -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/virtio: add out-fences support for explicit synchronization
Hi Rob,
On Thu, 25 Oct 2018 at 19:38, Robert Foss wrote:
>
> From: Gustavo Padovan
>
> On the out-fence side we get fence returned by the submitted draw call
> and attach it to a sync_file and send the sync_file fd to userspace. On
> error -1 is returned to userspace.
>
Can we have both an IN and OUT fence at the same time? Either way, please
mention that in the commit message.
> Signed-off-by: Gustavo Padovan
> Signed-off-by: Robert Foss
> Suggested-by: Rob Herring
> ---
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 50 +++---
> 1 file changed, 38 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index 0368195966aa..32e714a1c753 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -106,7 +106,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
> *dev, void *data,
> struct virtio_gpu_device *vgdev = dev->dev_private;
> struct virtio_gpu_fpriv *vfpriv = drm_file->driver_priv;
> struct drm_gem_object *gobj;
> - struct virtio_gpu_fence *fence;
> + struct virtio_gpu_fence *out_fence;
> struct virtio_gpu_object *qobj;
> int ret;
> uint32_t *bo_handles = NULL;
> @@ -116,7 +116,9 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
> *dev, void *data,
> int i;
> struct ww_acquire_ctx ticket;
> struct dma_fence *in_fence = NULL;
> + struct sync_file *sync_file;
> int in_fence_fd = exbuf->fence_fd;
> + int out_fence_fd = -1;
> void *buf;
>
> exbuf->fence_fd = -1;
> @@ -143,6 +145,14 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
> *dev, void *data,
> }
> }
>
> + if (exbuf->flags & VIRTGPU_EXECBUF_FENCE_FD_OUT) {
> + out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
> + if (out_fence_fd < 0) {
> + ret = out_fence_fd;
> + goto out_in_fence;
> + }
> + }
> +
If the answer to the above is "no" we want a check around here.
With that the patch is
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm/virtio: add uapi for in and out explicit fences
Hi Rob, On Thu, 25 Oct 2018 at 19:38, Robert Foss wrote: > > Add a new field called fence_fd that will be used by userspace to send > in-fences to the kernel and receive out-fences created by the kernel. > > This uapi enables virtio to take advantage of explicit synchronization of > dma-bufs. > > There are two new flags: > > * VIRTGPU_EXECBUF_FENCE_FD_IN to be used when passing an in-fence fd. > * VIRTGPU_EXECBUF_FENCE_FD_OUT to be used when requesting an out-fence fd > > The execbuffer IOCTL is now read-write to allow the userspace to read the > out-fence. > > On error -1 should be returned in the fence_fd field. > > Signed-off-by: Gustavo Padovan > Signed-off-by: Robert Foss > --- > Changes since v2: > - Since exbuf-flags is a new flag, check that unsupported >flags aren't set. > > drivers/gpu/drm/virtio/virtgpu_ioctl.c | 5 + > include/uapi/drm/virtgpu_drm.h | 13 ++--- > 2 files changed, 15 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c > b/drivers/gpu/drm/virtio/virtgpu_ioctl.c > index d01a9ed100d1..1af289b28fc4 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c > +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c > @@ -116,9 +116,14 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device > *dev, void *data, > struct ww_acquire_ctx ticket; > void *buf; > > + exbuf->fence_fd = -1; > + Move this after the sanity checking. > if (vgdev->has_virgl_3d == false) > return -ENOSYS; > > + if ((exbuf->flags & ~VIRTGPU_EXECBUF_FLAGS)) > + return -EINVAL; > + I assume this did this trigger when using old userspace? With those the patch is Reviewed-by: Emil Velikov Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/virtio: add virtio_gpu_alloc_fence()
Hi Rob,
On Thu, 25 Oct 2018 at 19:38, Robert Foss wrote:
>
> From: Gustavo Padovan
>
> Refactor fence creation to remove the potential allocation failure from
> the cmd_submit and atomic_commit paths. Now the fence should be allocated
> first and just after we should proceed with the rest of the execution.
>
Commit does a bit more that what the above says:
- dummy, factor out fence creation/destruction
- use per virtio_gpu_framebuffer fence
Personally I'd keep the two separate patches and elaborate on the latter.
Obviously in that case, one will need to add 3 lines worth of
virtio_gpu_fence_alloc() in virtio_gpu_cursor_plane_update which will be nuked
with the next patch.
Not a big deal, but it's up-to the maintainer to make the final call if it's
worth splitting or not.
Couple of minor nitpicks below.
> struct virtio_gpu_device *vgdev = dev->dev_private;
> struct virtio_gpu_output *output = NULL;
> struct virtio_gpu_framebuffer *vgfb;
> - struct virtio_gpu_fence *fence = NULL;
> struct virtio_gpu_object *bo = NULL;
> uint32_t handle;
> int ret = 0;
Add the virtio_gpu_fence_alloc()? And yes it will be nuked with patch 2/...
> +struct virtio_gpu_fence *virtio_gpu_fence_alloc(struct virtio_gpu_device
> *vgdev)
> +{
> + struct virtio_gpu_fence_driver *drv = &vgdev->fence_drv;
> + struct virtio_gpu_fence *fence = kzalloc(sizeof(struct
> virtio_gpu_fence), GFP_ATOMIC);
> + if (!fence)
> + return fence;
> +
> + fence->drv = drv;
> + dma_fence_init(&fence->f, &virtio_fence_ops, &drv->lock,
> drv->context, 0);
Oh no, lines over 80 col... while the original code is pretty and neat.
> +
> + return fence;
> +}
> +
> +void virtio_gpu_fence_cleanup(struct virtio_gpu_fence *fence)
> +{
> + if (!fence)
> + return;
> +
> + if (fence->drv)
> + dma_fence_put(&fence->f);
> + else
> + kfree(fence);
I'm not sure if/how we reach the else case here?
> +}
> +
> int virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
> struct virtio_gpu_ctrl_hdr *cmd_hdr,
> - struct virtio_gpu_fence **fence)
> + struct virtio_gpu_fence *fence)
> {
With a follow-up commit, we can drop the no longer needed return type.
Which it turns out was never checked ...
> @@ -319,6 +332,8 @@ static int virtio_gpu_resource_create_ioctl(struct
> drm_device *dev, void *data,
> dma_fence_put(&fence->f);
> }
> return 0;
> +fail_fence:
The error labels seems to be called after what they do, not what
fails. fail_backoff seems better IMHO.
> +ttm_eu_backoff_reservation(&ticket, &validate_list);
Indentation seems off (or my client ate it)?
HTH
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
