Re: [Intel-gfx] [PATCH] drm/i915: Enforce that CS packets are qword aligned
On 21/07/2017 17:11, Chris Wilson wrote: We require the caller to ensure that the packets they wish to emit into the CS ring are qword aligned (i.e. have an even number of dwords). Double check this. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index aa59290cb8bf..0b06f66507a0 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1397,6 +1397,9 @@ u32 *intel_ring_begin(struct drm_i915_gem_request *req, unsigned int total_bytes; u32 *cs; + /* Packets must be qword aligned. */ + GEM_BUG_ON(num_dwords & 1); + total_bytes = bytes + req->reserved_space; GEM_BUG_ON(total_bytes > ring->effective_size); Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Making IGT runnable by CI and developers
On 21/07/2017 16:45, Daniel Vetter wrote: On Fri, Jul 21, 2017 at 12:56 PM, Tvrtko Ursulin wrote: On 20/07/2017 17:23, Martin Peres wrote: Hi everyone, As some of you may already know, we have made great strides in making our CI system usable, especially in the last 6 months when everything started clicking together. The CI team is no longer overwhelmed with fires and bug reports, so we started working on increasing the coverage from just fast-feedback, to a bigger set of IGT tests. As some of you may know, running IGT has been a challenge that few manage to overcome. Not only is the execution time counted in machine months, but it can also lead to disk corruption, which does not encourage developers to run it either. One test takes 21 days, on its own, and it is a subset of another test which we never ran for obvious reasons. I would thus like to get the CI team and developers to work together to decrease sharply the execution time of IGT, and get these tests run multiple times per day! There are three usages that the CI team envision (up for debate): - Basic acceptance testing: Meant for developers and CI to check quickly if a patch series is not completely breaking the world (< 10 minutes, timeout per test of 30s) - Full run: Meant to be ran overnight by developers and users (< 6 hours) We could start by splitting this budget to logical components/teams. So far we have been talking about GEM and KMS, but I was just thinking that we may want to have a separate units on this level of likes of power management, DRM (core), external stuff like sw fences? TBD I guess. Assuming GEM/KMS split only, fair thing seems to be split the time budget 50-50 and let the respective teams start working. Yes, KMS is also not perfect, but there it's maybe a factor of 2x that it's taking too long. GEM is 50x or worse. Also note KMS includes everything, so core drm, PM tests. 2x is something can be fixed as we go, which is good, since it means we should be able to pre-merge test any changes to igt before pushing. GEM is not even close. I assume this is x hours on the slowest machine? Teams would also need easy access to up-to-date test run times. Right now you can't have that for GEM, because it takes 24d. That means 1 run of GEM takes away 50 runs of everything else (need to check, it might be worse). There's simply no way we can even hand out that data without blocking pre-merge CI for everyone else. We might be able to schedule the occasional manual run over the w/e, but that's about it. I did not explain well here what I was thinking about by access to up-to-date runtime. I assumed we would start from a cut down list, the one which fits in the time budget. As Martin and me chatted on Friday, I would be completely fine with the CI team just picking a list of GEM tests which fits, and then the GEM team responsibility is to add, remove and improve tests until this time is used in the most optimal way. This was we would be getting daily test run time updates. We also talked about the idea to set up an IGT trybot, where we could send test changes, followed by a testlist updates, and so see the specific test runtimes across the platforms. Once that looks ok, we could submit a patch to the real test list and so keep iterating until the above goal is reached. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Making IGT runnable by CI and developers
On 21/07/2017 16:52, Daniel Vetter wrote: On Fri, Jul 21, 2017 at 5:13 PM, Jani Nikula wrote: [snip] I agree the goal should be to run all tests by default. And this means we should start being more critical of the tests we add. For stress tests I would like to look more into splitting up the tests in a way that you could run one iteration fast (as part of default), and repeat the tests for more stress and coverage. I don't know how feasible this is, and if it requires carrying over state from one iteration to other, but I like the goal of running also some of this by default. This would better catch silly bugs in tests too. (We discussed this offline with Martin and Tomi.) I think right now, and for the near future (up to at least a year) the only time we'll run stress tests if developers need nastier testcases to help reproduce a bug locally. We simply don't have neither the CI nor the QA resources to run these tests. If we're making really great progress on overall quality and CI infrastructure (that needs budget we don't have right now) and pre-merge testing we might be able to start looking into running stress tests in CI or QA. I think a good example is kms_frontbuffer_tracking --show-hidden, which Paulo used to debug issues on his own machine. Just on this particular point - to make this facility generic would be a flavour of test tagging, so pretty much the same high level effect as the RFC I sent. I am not pushing it (again), just saying it would be effectively the same approach/effort, only that tags are more generic/flexible. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree
On Mon, Jul 24, 2017 at 2:03 AM, Stephen Rothwell wrote: > Hi Daniel, > > On Fri, 21 Jul 2017 09:24:49 +0200 Daniel Vetter > wrote: >> >> How are we going to handle this now? The refactor is deeply burried in >> drm-misc, I guess you could cherry-pick the relevant patches over. But >> that'll probably lead to more conflicts because git will get confused. > > I'll just keep applying the merge resolution patch and will remind Dave > and Greg about it during the week before the merge window opens so that > they can let Linus know that the fix up is needed. Well, Greg squeezed the vbox driver into -rc2, so now we already get to resolve this in a backmerge. And hopefully the bikeshed patches in -staging won't interfere too badly with whatever refactoring we'll do in drm-next. Greg, fyi this is the last time I'll ack a drm driver for staging. This just doesn't work. We're spending more time here working the -staging vs. drm-next conflicts than the actual vbox driver review has taken me. And probly less than the cleanup for merging directly to drm-next will end up taking. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Remove assertion from raw __i915_vma_unpin()
On pe, 2017-07-21 at 15:50 +0100, Chris Wilson wrote:
> After we detect a i915_vma pin overflow, we call __i915_vma_unpin to
> cleanup. However, on an overflow the pin_count bitfield will be zero,
> triggering an assertion, even though we the intention is to merely warn
> and report the error back to the user (as historically the culprit has
> be a leak in the display code).
>
> Fixes: 20dfbde463c8 ("drm/i915: Wrap vma->pin_count accessors with small
> inline helpers")
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Only mark the execobject as pinned on success
On pe, 2017-07-21 at 15:50 +0100, Chris Wilson wrote:
> If we fail to acquire a fence (for old school fenced GPU access) then we
> unwind the vma reservation, including its pin. However, we were making
> the execobject as holding the pin before erring out, leading to a double
> unpin:
>
> [ 3193.991802] kernel BUG at drivers/gpu/drm/i915/i915_vma.h:287!
> [ 3193.998131] invalid opcode: [#1] PREEMPT SMP
> [ 3194.002816] Modules linked in: snd_hda_intel i915 vgem
> snd_hda_codec_analog snd_hda_codec_generic coretemp snd_hda_codec snd_hwdep
> snd_hda_core snd_pcm lpc_ich mei_me e1000e mei prime_numbers ptp pps_core
> [last unloaded: i915]
> [ 3194.022841] CPU: 0 PID: 8123 Comm: kms_flip Tainted: G U
> 4.13.0-rc1-CI-CI_DRM_471+ #1
> [ 3194.031765] Hardware name: Dell Inc. OptiPlex 755 /0PU052,
> BIOS A04 11/05/2007
> [ 3194.040343] task: 8800785d4c40 task.stack: c90001768000
> [ 3194.046339] RIP: 0010:eb_release_vmas.isra.6+0x119/0x180 [i915]
> [ 3194.052234] RSP: 0018:c9000176ba80 EFLAGS: 00010246
> [ 3194.057439] RAX: 03c0 RBX: 8800710fc2d8 RCX:
> 8800588e4f48
> [ 3194.064546] RDX: 1fff RSI: RDI:
> 8800588e00d0
> [ 3194.071654] RBP: c9000176bab0 R08: R09:
>
> [ 3194.078761] R10: 0040 R11: 0001 R12:
> 880060822f00
> [ 3194.085867] R13: 0310 R14: 03b8 R15:
> c9000176bbb0
> [ 3194.092975] FS: 7fd2b94aba40() GS:88007d20()
> knlGS:
> [ 3194.101033] CS: 0010 DS: ES: CR0: 80050033
> [ 3194.106754] CR2: 7ffbec3ff000 CR3: 74e67000 CR4:
> 06f0
> [ 3194.113861] Call Trace:
> [ 3194.116321] eb_relocate_slow+0x67/0x4e0 [i915]
> [ 3194.120861] i915_gem_do_execbuffer+0x429/0x1260 [i915]
> [ 3194.126070] ? lock_acquire+0xb5/0x210
> [ 3194.129803] ? __might_fault+0x39/0x90
> [ 3194.133563] i915_gem_execbuffer2+0x9b/0x1b0 [i915]
> [ 3194.138447] ? i915_gem_execbuffer+0x2b0/0x2b0 [i915]
> [ 3194.143478] drm_ioctl_kernel+0x64/0xb0
> [ 3194.147298] drm_ioctl+0x2cd/0x390
> [ 3194.150710] ? i915_gem_execbuffer+0x2b0/0x2b0 [i915]
> [ 3194.155741] ? finish_task_switch+0xa5/0x210
> [ 3194.159993] ? finish_task_switch+0x6a/0x210
> [ 3194.164247] do_vfs_ioctl+0x90/0x670
> [ 3194.167806] ? entry_SYSCALL_64_fastpath+0x5/0xb1
> [ 3194.172492] ? __this_cpu_preempt_check+0x13/0x20
> [ 3194.177176] ? trace_hardirqs_on_caller+0xe7/0x1c0
> [ 3194.181946] SyS_ioctl+0x3c/0x70
> [ 3194.185159] entry_SYSCALL_64_fastpath+0x1c/0xb1
> [ 3194.189756] RIP: 0033:0x7fd2b76a8587
> [ 3194.193314] RSP: 002b:7fff074845b8 EFLAGS: 0246 ORIG_RAX:
> 0010
> [ 3194.200855] RAX: ffda RBX: 8146da43 RCX:
> 7fd2b76a8587
> [ 3194.207962] RDX: 7fff074846e0 RSI: 40406469 RDI:
> 0003
> [ 3194.215068] RBP: c9000176bf88 R08: R09:
> 0003
> [ 3194.222175] R10: 7fd2b796bb58 R11: 0246 R12:
> 7fff07484880
> [ 3194.229280] R13: 0003 R14: 40406469 R15:
>
> [ 3194.236386] ? __this_cpu_preempt_check+0x13/0x20
> [ 3194.241070] Code: 24 b0 00 00 00 48 85 c9 0f 84 6c ff ff ff 8b 41 20 85 c0
> 7e 73 83 e8 01 89 41 20 41 8b 84 24 e8 00 00 00 a8 0f 0f 85 5f ff ff ff <0f>
> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d f3 c3 49 8b 84
> [ 3194.259943] RIP: eb_release_vmas.isra.6+0x119/0x180 [i915] RSP:
> c9000176ba80
> [ 3194.268047] ---[ end trace 1d7348c6575d8800 ]---
> [ 3673.658819] softdog: Initiating panic
> [ 3673.662471] Kernel panic - not syncing: Software Watchdog Timer expired
> [ 3673.669066] Kernel Offset: disabled
> [ 3673.672541] Rebooting in 1 seconds..
>
> Reported-by: Tomi Sarvela
> Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the
> execobjects array")
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lut
bdw_load_gamma_lut is writing beyond the array to the maximum value.
The intend of the function is to clamp values > 1 to 1, so write
the intended color to the max register.
This fixes the following KASAN warning:
[ 197.020857] [IGT] kms_pipe_color: executing
[ 197.063434] [IGT] kms_pipe_color: starting subtest ctm-0-25-pipe0
[ 197.078989]
==
[ 197.079127] BUG: KASAN: slab-out-of-bounds in
bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
[ 197.079188] Read of size 2 at addr 8800d38db150 by task
kms_pipe_color/1839
[ 197.079208] CPU: 2 PID: 1839 Comm: kms_pipe_color Tainted: G U
4.13.0-rc1-patser+ #5211
[ 197.079215] Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355
03/09/2015
[ 197.079220] Call Trace:
[ 197.079230] dump_stack+0x68/0x9e
[ 197.079239] print_address_description+0x6f/0x250
[ 197.079251] kasan_report+0x216/0x370
[ 197.079374] ? bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
[ 197.079451] ? gen8_write16+0x4e0/0x4e0 [i915]
[ 197.079460] __asan_report_load2_noabort+0x14/0x20
[ 197.079535] bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
[ 197.079612] broadwell_load_luts+0x1df/0x550 [i915]
[ 197.079690] intel_color_load_luts+0x7b/0x80 [i915]
[ 197.079764] intel_begin_crtc_commit+0x138/0x760 [i915]
[ 197.079783] drm_atomic_helper_commit_planes_on_crtc+0x1a3/0x820
[drm_kms_helper]
[ 197.079859] ? intel_pre_plane_update+0x571/0x580 [i915]
[ 197.079937] intel_update_crtc+0x238/0x330 [i915]
[ 197.080016] intel_update_crtcs+0x10f/0x210 [i915]
[ 197.080092] intel_atomic_commit_tail+0x1552/0x3340 [i915]
[ 197.080101] ? _raw_spin_unlock+0x3c/0x40
[ 197.080110] ? __queue_work+0xb40/0xbf0
[ 197.080188] ? skl_update_crtcs+0xc00/0xc00 [i915]
[ 197.080195] ? trace_hardirqs_on+0xd/0x10
[ 197.080269] ? intel_atomic_commit_ready+0x128/0x13c [i915]
[ 197.080329] ? __i915_sw_fence_complete+0x5b8/0x6d0 [i915]
[ 197.080336] ? debug_object_activate+0x39e/0x580
[ 197.080397] ? i915_sw_fence_await+0x30/0x30 [i915]
[ 197.080409] ? __might_sleep+0x15b/0x180
[ 197.080483] intel_atomic_commit+0x944/0xa70 [i915]
[ 197.080490] ? refcount_dec_and_test+0x11/0x20
[ 197.080567] ? intel_atomic_commit_tail+0x3340/0x3340 [i915]
[ 197.080597] ? drm_atomic_crtc_set_property+0x303/0x580 [drm]
[ 197.080674] ? intel_atomic_commit_tail+0x3340/0x3340 [i915]
[ 197.080704] drm_atomic_commit+0xd7/0xe0 [drm]
[ 197.080722] drm_atomic_helper_crtc_set_property+0xec/0x130 [drm_kms_helper]
[ 197.080749] drm_mode_crtc_set_obj_prop+0x7d/0xb0 [drm]
[ 197.080775] drm_mode_obj_set_property_ioctl+0x50b/0x5d0 [drm]
[ 197.080783] ? __might_fault+0x104/0x180
[ 197.080809] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
[ 197.080838] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
[ 197.080861] drm_ioctl_kernel+0x154/0x1a0 [drm]
[ 197.080885] drm_ioctl+0x624/0x8f0 [drm]
[ 197.080910] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
[ 197.080934] ? drm_getunique+0x210/0x210 [drm]
[ 197.080943] ? __handle_mm_fault+0x1bd0/0x1ce0
[ 197.080949] ? lock_downgrade+0x610/0x610
[ 197.080957] ? __lru_cache_add+0x15a/0x180
[ 197.080967] do_vfs_ioctl+0xd92/0xe40
[ 197.080975] ? ioctl_preallocate+0x1b0/0x1b0
[ 197.080982] ? selinux_capable+0x20/0x20
[ 197.080991] ? __do_page_fault+0x7b7/0x9a0
[ 197.080997] ? lock_downgrade+0x5bb/0x610
[ 197.081007] ? security_file_ioctl+0x57/0x90
[ 197.081016] SyS_ioctl+0x4e/0x80
[ 197.081024] entry_SYSCALL_64_fastpath+0x18/0xad
[ 197.081030] RIP: 0033:0x7f61f287a987
[ 197.081035] RSP: 002b:7fff7d44d188 EFLAGS: 0246 ORIG_RAX:
0010
[ 197.081043] RAX: ffda RBX: RCX: 7f61f287a987
[ 197.081048] RDX: 7fff7d44d1c0 RSI: c01864ba RDI: 0003
[ 197.081053] RBP: 7f61f2b3eb00 R08: 0059 R09:
[ 197.081058] R10: 002ea5c4a290 R11: 0246 R12: 7f61f2b3eb58
[ 197.081063] R13: 1010 R14: 7f61f2b3eb58 R15: 2702
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101659
Signed-off-by: Maarten Lankhorst
Reported-by: Martin Peres
Cc: Martin Peres
Fixes: 82cf435b3134 ("drm/i915: Implement color management on bdw/skl/bxt/kbl")
Cc: Shashank Sharma
Cc: Kiran S Kumar
Cc: Kausal Malladi
Cc: Lionel Landwerlin
Cc: Matt Roper
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.7+
---
drivers/gpu/drm/i915/intel_color.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index f85d57555957..1813d84989c9 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -398,6 +398,7 @@ static void bdw_load_gamma_lut(struct drm_crtc_state
*state, u32 offset)
}
/* Program the max register to clamp values > 1.0. */
+ i = lut_size - 1;
Re: [Intel-gfx] Making IGT runnable by CI and developers
On Mon, Jul 24, 2017 at 09:21:39AM +0100, Tvrtko Ursulin wrote: > > On 21/07/2017 16:52, Daniel Vetter wrote: > > On Fri, Jul 21, 2017 at 5:13 PM, Jani Nikula > > wrote: > > [snip] > > > > I agree the goal should be to run all tests by default. And this means > > > we should start being more critical of the tests we add. > > > > > > For stress tests I would like to look more into splitting up the tests > > > in a way that you could run one iteration fast (as part of default), and > > > repeat the tests for more stress and coverage. I don't know how feasible > > > this is, and if it requires carrying over state from one iteration to > > > other, but I like the goal of running also some of this by default. This > > > would better catch silly bugs in tests too. (We discussed this offline > > > with Martin and Tomi.) > > > > I think right now, and for the near future (up to at least a year) the > > only time we'll run stress tests if developers need nastier testcases > > to help reproduce a bug locally. We simply don't have neither the CI > > nor the QA resources to run these tests. If we're making really great > > progress on overall quality and CI infrastructure (that needs budget > > we don't have right now) and pre-merge testing we might be able to > > start looking into running stress tests in CI or QA. > > > > I think a good example is kms_frontbuffer_tracking --show-hidden, > > which Paulo used to debug issues on his own machine. > > Just on this particular point - to make this facility generic would be a > flavour of test tagging, so pretty much the same high level effect as the > RFC I sent. I am not pushing it (again), just saying it would be effectively > the same approach/effort, only that tags are more generic/flexible. The one difference would be it's binary, as in it only differentiates between real regression tests everyone should care about vs. tools and stuff that is only useful for the feature developer. It's _not_ tagging of everything (which I fully agree with Jani is not going to work if we put it into the source files). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Making IGT runnable by CI and developers
On Mon, Jul 24, 2017 at 09:15:28AM +0100, Tvrtko Ursulin wrote: > > On 21/07/2017 16:45, Daniel Vetter wrote: > > On Fri, Jul 21, 2017 at 12:56 PM, Tvrtko Ursulin > > wrote: > > > > > > On 20/07/2017 17:23, Martin Peres wrote: > > > > > > > > Hi everyone, > > > > > > > > As some of you may already know, we have made great strides in making > > > > our > > > > CI system usable, especially in the last 6 months when everything > > > > started > > > > clicking together. > > > > > > > > The CI team is no longer overwhelmed with fires and bug reports, so we > > > > started working on increasing the coverage from just fast-feedback, to a > > > > bigger set of IGT tests. > > > > > > > > As some of you may know, running IGT has been a challenge that few > > > > manage > > > > to overcome. Not only is the execution time counted in machine months, > > > > but > > > > it can also lead to disk corruption, which does not encourage > > > > developers to > > > > run it either. One test takes 21 days, on its own, and it is a subset of > > > > another test which we never ran for obvious reasons. > > > > > > > > I would thus like to get the CI team and developers to work together to > > > > decrease sharply the execution time of IGT, and get these tests run > > > > multiple > > > > times per day! > > > > > > > > There are three usages that the CI team envision (up for debate): > > > >- Basic acceptance testing: Meant for developers and CI to check > > > > quickly > > > > if a patch series is not completely breaking the world (< 10 minutes, > > > > timeout per test of 30s) > > > >- Full run: Meant to be ran overnight by developers and users (< 6 > > > > hours) > > > > > > > > > We could start by splitting this budget to logical components/teams. > > > > > > So far we have been talking about GEM and KMS, but I was just thinking > > > that > > > we may want to have a separate units on this level of likes of power > > > management, DRM (core), external stuff like sw fences? TBD I guess. > > > > > > Assuming GEM/KMS split only, fair thing seems to be split the time budget > > > 50-50 and let the respective teams start working. > > > > Yes, KMS is also not perfect, but there it's maybe a factor of 2x that > > it's taking too long. GEM is 50x or worse. Also note KMS includes > > everything, so core drm, PM tests. 2x is something can be fixed as we > > go, which is good, since it means we should be able to pre-merge test > > any changes to igt before pushing. GEM is not even close. > > > > > I assume this is x hours on the slowest machine? > > > > > > Teams would also need easy access to up-to-date test run times. > > > > Right now you can't have that for GEM, because it takes 24d. That > > means 1 run of GEM takes away 50 runs of everything else (need to > > check, it might be worse). There's simply no way we can even hand out > > that data without blocking pre-merge CI for everyone else. > > > > We might be able to schedule the occasional manual run over the w/e, > > but that's about it. > > I did not explain well here what I was thinking about by access to > up-to-date runtime. I assumed we would start from a cut down list, the one > which fits in the time budget. > > As Martin and me chatted on Friday, I would be completely fine with the CI > team just picking a list of GEM tests which fits, and then the GEM team > responsibility is to add, remove and improve tests until this time is used > in the most optimal way. > > This was we would be getting daily test run time updates. > > We also talked about the idea to set up an IGT trybot, where we could send > test changes, followed by a testlist updates, and so see the specific test > runtimes across the platforms. > > Once that looks ok, we could submit a patch to the real test list and so > keep iterating until the above goal is reached. Atm we have 99% of GEM stuff that we simply cannot run. I dont think it's a good idea to carry that around forever (simply because enumerating all these tests alone kills machine time if you try to run stuff locally). Is the plan to not clean that up? 2nd issue I have with an explicit gem test suite: New testcases won't get tested by default, which means no pressure on them to be fast or useful or stable. That's imo a big reason for why we ended up here. So if you think an explicit gem test list is the way to go, then I think the only way to do that is with a blacklist (which would start out with all gem tests). And after a few months we'd just go through the sources and delete all the tests still blacklisted, or something like that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Unclaimed read from register 0x1f0034
Hello all, I'm not too sure where to report this but I got an unusual output in dmesg a couple of days ago and wanted to pass it on. Please let me know if I need to submit a bug report too. [ 4056.074906] Unclaimed read from register 0x1f0034 [ 4056.074990] [ cut here ] [ 4056.075021] WARNING: CPU: 0 PID: 5286 at drivers/gpu/drm/i915/intel_uncore.c:792 __unclaimed_reg_debug+0x43/0x60 [ 4056.075030] Modules linked in: [ 4056.075036] CPU: 0 PID: 5286 Comm: systemd-sleep Not tainted 4.13.0-rc1+ #2 [ 4056.075038] Hardware name: GOOGLE Banon, BIOS 07/01/2016 [ 4056.075040] task: 98dd76c1f2c0 task.stack: b391007f4000 [ 4056.075044] RIP: 0010:__unclaimed_reg_debug+0x43/0x60 [ 4056.075046] RSP: 0018:b391007f78e8 EFLAGS: 00010092 [ 4056.075049] RAX: 0025 RBX: RCX: 0002 [ 4056.075051] RDX: 8002 RSI: 0086 RDI: 0002 [ 4056.075052] RBP: b391007f7900 R08: R09: 0025 [ 4056.075054] R10: 0018 R11: R12: 001f0034 [ 4056.075056] R13: 0001 R14: 98dd76c90688 R15: [ 4056.075059] FS: 7f16edaba740() GS:98ddbc80() knlGS: [ 4056.075061] CS: 0010 DS: ES: CR0: 80050033 [ 4056.075062] CR2: 7ffc7e05b3f9 CR3: 377b6000 CR4: 001006f0 [ 4056.075066] Call Trace: [ 4056.075074] fwtable_read32+0x1dd/0x1f0 [ 4056.075083] vlv_program_watermarks+0x3ea/0x670 [ 4056.075088] vlv_optimize_watermarks+0xa4/0xc0 [ 4056.075093] intel_atomic_commit_tail+0x33e/0xf90 [ 4056.075098] intel_atomic_commit+0x3a0/0x490 [ 4056.075103] ? intel_runtime_pm_put+0x56/0xa0 [ 4056.075108] drm_atomic_commit+0x4b/0x50 [ 4056.075115] drm_atomic_helper_commit_duplicated_state+0xc4/0xd0 [ 4056.075118] __intel_display_resume+0x86/0xd0 [ 4056.075121] intel_display_resume+0xc1/0xe0 [ 4056.075128] i915_drm_resume+0xde/0x180 [ 4056.075131] i915_pm_restore+0x1e/0x30 [ 4056.075134] i915_pm_resume+0xe/0x10 [ 4056.075139] pci_pm_resume+0x64/0xa0 [ 4056.075145] dpm_run_callback+0x56/0x180 [ 4056.075148] ? pci_pm_freeze+0xe0/0xe0 [ 4056.075151] device_resume+0xe1/0x1f0 [ 4056.075154] dpm_resume+0x10d/0x320 [ 4056.075157] dpm_resume_end+0x11/0x20 [ 4056.075162] suspend_devices_and_enter+0x13c/0x7b0 [ 4056.075166] pm_suspend+0x31d/0x390 [ 4056.075169] state_store+0x82/0xf0 [ 4056.075177] kobj_attr_store+0xf/0x20 [ 4056.075183] sysfs_kf_write+0x37/0x40 [ 4056.075186] kernfs_fop_write+0x107/0x180 [ 4056.075193] __vfs_write+0x28/0x130 [ 4056.075199] ? __this_cpu_preempt_check+0x13/0x20 [ 4056.075204] ? __sb_start_write+0xa0/0xe0 [ 4056.075207] vfs_write+0xb8/0x1b0 [ 4056.075210] SyS_write+0x46/0xa0 [ 4056.075217] entry_SYSCALL_64_fastpath+0x1e/0xa9 [ 4056.075221] RIP: 0033:0x7f16ed1c0290 [ 4056.075223] RSP: 002b:7fffe4f9c618 EFLAGS: 0246 ORIG_RAX: 0001 [ 4056.075226] RAX: ffda RBX: 7f16ed48db20 RCX: 7f16ed1c0290 [ 4056.075228] RDX: 0004 RSI: 006d029693d0 RDI: 0004 [ 4056.075229] RBP: 1011 R08: 006d02969280 R09: 7f16edaba740 [ 4056.075231] R10: 7f16ed48db78 R11: 0246 R12: 7f16ed48db78 [ 4056.075233] R13: 7f16ed48db78 R14: 270f R15: 7f16ed48db78 [ 4056.075236] Code: fe ff ff 38 d8 76 2d 45 84 ed 48 c7 c0 98 40 41 ac 48 c7 c6 a2 40 41 ac 48 0f 45 f0 44 89 e2 48 c7 c7 ab 40 41 ac e8 5e 51 a5 ff <0f> ff 83 2d b0 8d 0f 01 01 5b 41 5c 41 5d 5d c3 0f 1f 00 66 2e [ 4056.075296] ---[ end trace 1bdf66ea2a802075 ]--- I believe this is the result of a wake command and I don't believe that it caused any loss in functionality. Let me know if I should do some testing. Thanks, Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lut
== Series Details == Series: drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lut URL : https://patchwork.freedesktop.org/series/27783/ State : success == Summary == Series 27783v1 drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lut https://patchwork.freedesktop.org/api/1.0/series/27783/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test kms_flip: Subgroup basic-flip-vs-modeset: skip -> PASS (fi-skl-x1585l) fdo#101781 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:445s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:440s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:355s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:538s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:511s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:490s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:486s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:603s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:442s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:417s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:409s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:505s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:484s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:473s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:578s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:584s fi-pnv-d510 total:279 pass:221 dwarn:3 dfail:0 fail:0 skip:55 time:556s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:458s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:584s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:469s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:478s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:438s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:492s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:544s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:405s 2a4f73050a961e1a176d35561e39386da9ea9c67 drm-tip: 2017y-07m-21d-15h-30m-47s UTC integration manifest 363d665 drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lut == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5264/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 3/6] drm/i915: prepare pipe for YCBCR420 output
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
This patch:
- Adds definition of these bits.
- Programs PIPEMISC for YCBCR420 outputs.
- Adds readouts to compare HW and SW states.
V2: rebase
V3: rebase
V4: rebase
V5: added r-b from Ander
V6: Handle only YCBCR420 outputs (ville)
V7: rebase
V8: Addressed review comments from Ville
- Add readouts for state->ycbcr420 and 420 pixel_clock.
- Handle warning due to mismatch in clock for ycbcr420 clock.
- Rename PIPEMISC macros to match the Bspec.
- Add a debug print stating if YCBCR 4:2:0 output enabled.
Added r-b from Ville
V9: Addressed review comments from Imre:
- Add 420 mode clock adjustment in intel_hdmi_mode_valid to
prevent 420_only modes getting rejected for high clock.
- Add port clock adjustment for ycbcr420 modes in ddi_get_clock
- Rename macros as per Ville's suggestion.
- Remove unnecessary wl changes.
V10: Added r-b from Imre
V11: Fixed faulty dotclock handling, and addressed missing comment
from previous set of review comments (Imre)
Cc: Ville Syrjala
Cc: Ander Conselvan de Oliveira
Cc: Daniel Vetter
Cc: Imre Deak
Reviewed-by: Ander Conselvan de Oliveira
Reviewed-by: Ville Syrjala
Reviewed-by: Imre Deak
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_ddi.c | 3 +++
drivers/gpu/drm/i915/intel_display.c | 25 +
drivers/gpu/drm/i915/intel_hdmi.c| 3 +++
4 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c712d01..e5b4e2f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5227,6 +5227,9 @@ enum {
#define _PIPE_MISC_A 0x70030
#define _PIPE_MISC_B 0x71030
+#define PIPEMISC_YUV420_ENABLE (1<<27)
+#define PIPEMISC_YUV420_MODE_FULL_BLEND (1<<26)
+#define PIPEMISC_OUTPUT_COLORSPACE_YUV (1<<11)
#define PIPEMISC_DITHER_BPC_MASK (7<<5)
#define PIPEMISC_DITHER_8_BPC(0<<5)
#define PIPEMISC_DITHER_10_BPC (1<<5)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index efb1358..aee18a3 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1174,6 +1174,9 @@ static void ddi_dotclock_get(struct intel_crtc_state
*pipe_config)
else
dotclock = pipe_config->port_clock;
+ if (pipe_config->ycbcr420)
+ dotclock = pipe_config->port_clock * 2;
+
if (pipe_config->pixel_multiplier)
dotclock /= pipe_config->pixel_multiplier;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 05ba0e9..9fb545a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8034,6 +8034,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_crtc_state *config = intel_crtc->config;
if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
u32 val = 0;
@@ -8059,6 +8060,12 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
if (intel_crtc->config->dither)
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
+ if (config->ycbcr420) {
+ val |= PIPEMISC_OUTPUT_COLORSPACE_YUV |
+ PIPEMISC_YUV420_ENABLE |
+ PIPEMISC_YUV420_MODE_FULL_BLEND;
+ }
+
I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
}
}
@@ -9128,6 +9135,21 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
pipe_config->scaler_state.scaler_users &= ~(1 <<
SKL_CRTC_INDEX);
}
+ if (IS_BROADWELL(dev_priv) || dev_priv->info.gen >= 9) {
+ u32 tmp = I915_READ(PIPEMISC(crtc->pipe));
+ bool clrspace_yuv = tmp & PIPEMISC_OUTPUT_COLORSPACE_YUV;
+ bool blend_mode_420 = tmp & PIPEMISC_YUV420_MODE_FULL_BLEND;
+
+ if (IS_GEMINILAKE(dev_priv) || dev_priv->info.gen >= 10) {
+ pipe_config->ycbcr420 = tmp & PIPEMISC_YUV420_ENABLE;
+ if (pipe_config->ycbcr420 != clrspace_yuv ||
+ pipe_config->ycbcr420 != blend_mode_420)
+ DRM_DEBUG_KMS("Bad 4:2:0 mode (%08x)\n", tmp);
+ } else if (clrspace_yuv || blend_mode_420) {
+ DRM_DEBUG_KMS("YCbCr 4:2:0 Unsupported\n");
+ }
+ }
+
power_domain = POWER_DOMAIN_PIPE_PANEL_
[Intel-gfx] ✓ Fi.CI.BAT: success for YCBCR 4:2:0 handling in i915 layer (rev3)
== Series Details == Series: YCBCR 4:2:0 handling in i915 layer (rev3) URL : https://patchwork.freedesktop.org/series/27412/ State : success == Summary == Series 27412v3 YCBCR 4:2:0 handling in i915 layer https://patchwork.freedesktop.org/api/1.0/series/27412/revisions/3/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 +1 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-n2820) fdo#101705 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:445s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:441s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:358s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:545s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:512s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:494s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:482s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:597s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:435s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:414s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:411s fi-ivb-3520m total:279 pass:260 dwarn:0 dfail:0 fail:1 skip:18 time:506s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:466s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:578s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:588s fi-pnv-d510 total:279 pass:221 dwarn:3 dfail:0 fail:0 skip:55 time:558s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:469s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:583s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:474s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:476s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:436s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:476s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:548s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:413s 2a4f73050a961e1a176d35561e39386da9ea9c67 drm-tip: 2017y-07m-21d-15h-30m-47s UTC integration manifest 6cd2245 drm/i915: prepare scaler for YCBCR420 modeset e7f1b4c drm/i915: add config function for YCBCR420 outputs == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5265/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lut
Reviewed-by: Lionel Landwerlin
On 24/07/17 10:14, Maarten Lankhorst wrote:
bdw_load_gamma_lut is writing beyond the array to the maximum value.
s/writing/reading/ ?
The intend of the function is to clamp values > 1 to 1, so write
s/intend/intent/
the intended color to the max register.
This fixes the following KASAN warning:
[ 197.020857] [IGT] kms_pipe_color: executing
[ 197.063434] [IGT] kms_pipe_color: starting subtest ctm-0-25-pipe0
[ 197.078989]
==
[ 197.079127] BUG: KASAN: slab-out-of-bounds in
bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
[ 197.079188] Read of size 2 at addr 8800d38db150 by task
kms_pipe_color/1839
[ 197.079208] CPU: 2 PID: 1839 Comm: kms_pipe_color Tainted: G U
4.13.0-rc1-patser+ #5211
[ 197.079215] Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355
03/09/2015
[ 197.079220] Call Trace:
[ 197.079230] dump_stack+0x68/0x9e
[ 197.079239] print_address_description+0x6f/0x250
[ 197.079251] kasan_report+0x216/0x370
[ 197.079374] ? bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
[ 197.079451] ? gen8_write16+0x4e0/0x4e0 [i915]
[ 197.079460] __asan_report_load2_noabort+0x14/0x20
[ 197.079535] bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
[ 197.079612] broadwell_load_luts+0x1df/0x550 [i915]
[ 197.079690] intel_color_load_luts+0x7b/0x80 [i915]
[ 197.079764] intel_begin_crtc_commit+0x138/0x760 [i915]
[ 197.079783] drm_atomic_helper_commit_planes_on_crtc+0x1a3/0x820
[drm_kms_helper]
[ 197.079859] ? intel_pre_plane_update+0x571/0x580 [i915]
[ 197.079937] intel_update_crtc+0x238/0x330 [i915]
[ 197.080016] intel_update_crtcs+0x10f/0x210 [i915]
[ 197.080092] intel_atomic_commit_tail+0x1552/0x3340 [i915]
[ 197.080101] ? _raw_spin_unlock+0x3c/0x40
[ 197.080110] ? __queue_work+0xb40/0xbf0
[ 197.080188] ? skl_update_crtcs+0xc00/0xc00 [i915]
[ 197.080195] ? trace_hardirqs_on+0xd/0x10
[ 197.080269] ? intel_atomic_commit_ready+0x128/0x13c [i915]
[ 197.080329] ? __i915_sw_fence_complete+0x5b8/0x6d0 [i915]
[ 197.080336] ? debug_object_activate+0x39e/0x580
[ 197.080397] ? i915_sw_fence_await+0x30/0x30 [i915]
[ 197.080409] ? __might_sleep+0x15b/0x180
[ 197.080483] intel_atomic_commit+0x944/0xa70 [i915]
[ 197.080490] ? refcount_dec_and_test+0x11/0x20
[ 197.080567] ? intel_atomic_commit_tail+0x3340/0x3340 [i915]
[ 197.080597] ? drm_atomic_crtc_set_property+0x303/0x580 [drm]
[ 197.080674] ? intel_atomic_commit_tail+0x3340/0x3340 [i915]
[ 197.080704] drm_atomic_commit+0xd7/0xe0 [drm]
[ 197.080722] drm_atomic_helper_crtc_set_property+0xec/0x130 [drm_kms_helper]
[ 197.080749] drm_mode_crtc_set_obj_prop+0x7d/0xb0 [drm]
[ 197.080775] drm_mode_obj_set_property_ioctl+0x50b/0x5d0 [drm]
[ 197.080783] ? __might_fault+0x104/0x180
[ 197.080809] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
[ 197.080838] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
[ 197.080861] drm_ioctl_kernel+0x154/0x1a0 [drm]
[ 197.080885] drm_ioctl+0x624/0x8f0 [drm]
[ 197.080910] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
[ 197.080934] ? drm_getunique+0x210/0x210 [drm]
[ 197.080943] ? __handle_mm_fault+0x1bd0/0x1ce0
[ 197.080949] ? lock_downgrade+0x610/0x610
[ 197.080957] ? __lru_cache_add+0x15a/0x180
[ 197.080967] do_vfs_ioctl+0xd92/0xe40
[ 197.080975] ? ioctl_preallocate+0x1b0/0x1b0
[ 197.080982] ? selinux_capable+0x20/0x20
[ 197.080991] ? __do_page_fault+0x7b7/0x9a0
[ 197.080997] ? lock_downgrade+0x5bb/0x610
[ 197.081007] ? security_file_ioctl+0x57/0x90
[ 197.081016] SyS_ioctl+0x4e/0x80
[ 197.081024] entry_SYSCALL_64_fastpath+0x18/0xad
[ 197.081030] RIP: 0033:0x7f61f287a987
[ 197.081035] RSP: 002b:7fff7d44d188 EFLAGS: 0246 ORIG_RAX:
0010
[ 197.081043] RAX: ffda RBX: RCX: 7f61f287a987
[ 197.081048] RDX: 7fff7d44d1c0 RSI: c01864ba RDI: 0003
[ 197.081053] RBP: 7f61f2b3eb00 R08: 0059 R09:
[ 197.081058] R10: 002ea5c4a290 R11: 0246 R12: 7f61f2b3eb58
[ 197.081063] R13: 1010 R14: 7f61f2b3eb58 R15: 2702
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101659
Signed-off-by: Maarten Lankhorst
Reported-by: Martin Peres
Cc: Martin Peres
Fixes: 82cf435b3134 ("drm/i915: Implement color management on bdw/skl/bxt/kbl")
Cc: Shashank Sharma
Cc: Kiran S Kumar
Cc: Kausal Malladi
Cc: Lionel Landwerlin
Cc: Matt Roper
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.7+
---
drivers/gpu/drm/i915/intel_color.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index f85d57555957..1813d84989c9 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -398,6 +398,7 @@ static void bdw_load_gamma_lut(struct drm_crtc_state
*state, u32 offset)
[Intel-gfx] [PATCH] drm/i915: Disable GPU resets for 915g (earliest gen3 desktop)
The CI farm reports that trying to write to the PCI config (GDRST: 0xc0)
results in an immediate and silent reboot on Grantsdale (i915g). Until
that is resolved, stop killing the machine!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101852
Fixes: 59ea90543f57 ("drm/i915: Implement GPU reset for 915/945")
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä gen >= 3)
+ else if (INTEL_INFO(dev_priv)->gen >= 3 &&
+INTEL_INFO(dev_priv)->platform != INTEL_I915G)
return i915_do_reset;
else
return NULL;
--
2.13.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Disable GPU resets for 915g (earliest gen3 desktop)
== Series Details == Series: drm/i915: Disable GPU resets for 915g (earliest gen3 desktop) URL : https://patchwork.freedesktop.org/series/27785/ State : success == Summary == Series 27785v1 drm/i915: Disable GPU resets for 915g (earliest gen3 desktop) https://patchwork.freedesktop.org/api/1.0/series/27785/revisions/1/mbox/ Test kms_force_connector_basic: Subgroup force-connector-state: pass -> SKIP (fi-ivb-3520m) fdo#101048 +3 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-j1900) fdo#101705 fdo#101048 https://bugs.freedesktop.org/show_bug.cgi?id=101048 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:440s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:439s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:348s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:536s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:514s fi-byt-j1900 total:279 pass:255 dwarn:0 dfail:0 fail:0 skip:24 time:488s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:484s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:609s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:438s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:413s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:420s fi-ivb-3520m total:279 pass:257 dwarn:0 dfail:0 fail:0 skip:22 time:502s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:473s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:462s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:572s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:586s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:572s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:460s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:591s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:471s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:479s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:437s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:475s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:543s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:406s 2a4f73050a961e1a176d35561e39386da9ea9c67 drm-tip: 2017y-07m-21d-15h-30m-47s UTC integration manifest e91abaa drm/i915: Disable GPU resets for 915g (earliest gen3 desktop) == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5266/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] docs: Update documentation generation with missing entries
On Thu, Jul 20, 2017 at 05:11:52PM +0300, Paul Kocialkowski wrote: > This adds missing entries for documentation generation, both for tests > and the API reference. > > The list of tests is made complete and ordered alphabetically, with > modified descriptions for consistency. > > More files are added to the API reference, with a minimalistic > description block added to them when it was missing. > > Signed-off-by: Paul Kocialkowski Reviewed-by: Arkadiusz Hiler pushed, thanks! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 3/6] drm/i915: prepare pipe for YCBCR420 output
On Mon, Jul 24, 2017 at 03:04:54PM +0530, Shashank Sharma wrote:
> To get HDMI YCBCR420 output, the PIPEMISC register should be
> programmed to:
> - Generate YCBCR output (bit 11)
> - In case of YCBCR420 outputs, it should be programmed in full
> blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
>
> This patch:
> - Adds definition of these bits.
> - Programs PIPEMISC for YCBCR420 outputs.
> - Adds readouts to compare HW and SW states.
>
> V2: rebase
> V3: rebase
> V4: rebase
> V5: added r-b from Ander
> V6: Handle only YCBCR420 outputs (ville)
> V7: rebase
> V8: Addressed review comments from Ville
> - Add readouts for state->ycbcr420 and 420 pixel_clock.
> - Handle warning due to mismatch in clock for ycbcr420 clock.
> - Rename PIPEMISC macros to match the Bspec.
> - Add a debug print stating if YCBCR 4:2:0 output enabled.
> Added r-b from Ville
> V9: Addressed review comments from Imre:
> - Add 420 mode clock adjustment in intel_hdmi_mode_valid to
> prevent 420_only modes getting rejected for high clock.
> - Add port clock adjustment for ycbcr420 modes in ddi_get_clock
> - Rename macros as per Ville's suggestion.
> - Remove unnecessary wl changes.
> V10: Added r-b from Imre
> V11: Fixed faulty dotclock handling, and addressed missing comment
> from previous set of review comments (Imre)
>
> Cc: Ville Syrjala
> Cc: Ander Conselvan de Oliveira
> Cc: Daniel Vetter
> Cc: Imre Deak
>
> Reviewed-by: Ander Conselvan de Oliveira
> Reviewed-by: Ville Syrjala
> Reviewed-by: Imre Deak
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_ddi.c | 3 +++
> drivers/gpu/drm/i915/intel_display.c | 25 +
> drivers/gpu/drm/i915/intel_hdmi.c| 3 +++
> 4 files changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c712d01..e5b4e2f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5227,6 +5227,9 @@ enum {
>
> #define _PIPE_MISC_A 0x70030
> #define _PIPE_MISC_B 0x71030
> +#define PIPEMISC_YUV420_ENABLE (1<<27)
> +#define PIPEMISC_YUV420_MODE_FULL_BLEND (1<<26)
> +#define PIPEMISC_OUTPUT_COLORSPACE_YUV (1<<11)
> #define PIPEMISC_DITHER_BPC_MASK (7<<5)
> #define PIPEMISC_DITHER_8_BPC (0<<5)
> #define PIPEMISC_DITHER_10_BPC (1<<5)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index efb1358..aee18a3 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1174,6 +1174,9 @@ static void ddi_dotclock_get(struct intel_crtc_state
> *pipe_config)
> else
> dotclock = pipe_config->port_clock;
>
> + if (pipe_config->ycbcr420)
> + dotclock = pipe_config->port_clock * 2;
This is still incorrect for 12bpc. So:
if (pipe_config->ycbcr420)
dotclock *= 2;
> +
> if (pipe_config->pixel_multiplier)
> dotclock /= pipe_config->pixel_multiplier;
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 05ba0e9..9fb545a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8034,6 +8034,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct intel_crtc_state *config = intel_crtc->config;
>
> if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
> u32 val = 0;
> @@ -8059,6 +8060,12 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
> if (intel_crtc->config->dither)
> val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
>
> + if (config->ycbcr420) {
> + val |= PIPEMISC_OUTPUT_COLORSPACE_YUV |
> + PIPEMISC_YUV420_ENABLE |
> + PIPEMISC_YUV420_MODE_FULL_BLEND;
> + }
> +
> I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
> }
> }
> @@ -9128,6 +9135,21 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->scaler_state.scaler_users &= ~(1 <<
> SKL_CRTC_INDEX);
> }
>
> + if (IS_BROADWELL(dev_priv) || dev_priv->info.gen >= 9) {
> + u32 tmp = I915_READ(PIPEMISC(crtc->pipe));
> + bool clrspace_yuv = tmp & PIPEMISC_OUTPUT_COLORSPACE_YUV;
> + bool blend_mode_420 = tmp & PIPEMISC_YUV420_MODE_FULL_BLEND;
The YUV420 blend mode flag is only defined for GLK and GEN >= 10, so it
must be checked only on those platforms.
> +
> + if (IS_GEMINILAKE(dev_priv) || dev_priv->info.gen >= 10) {
> + pipe_config->ycbcr420 = tmp & PIPEMI
Re: [Intel-gfx] [RFC v2] drm/hdcp: drm enum property for HDCP State
On Fri, Jul 21, 2017 at 9:02 AM, Ramalingam C wrote:
> Sorry for late response.
>
>
> On Friday 14 July 2017 07:25 PM, Sean Paul wrote:
>
> On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote:
>
> DRM connector property is created to represent the content protection
> state of the connector and to configure the same.
>
> CP States defined:
> DRM_CP_UNSUPPORTED - CP is not supported
> DRM_CP_DISABLE - CP is disabled
> DRM_CP_ENABLE - CP is enabled
>
> Why are we changing the names from the original version (that's used in
> CrOS)? It's not
> obvious what "CP" stands for when looking at the name.
>
> Sean,
>
> Considering that we want to test this interface for CrOS stack as a
> consumer, I will try to align the property names.
> Meanwhile got few questions with respect to designing this CP interface
> aligned with existing CrOS stack.
>
> I want to understand what all are the bare minimal content protection
> interface required for existing CrOS Userspace stack.
> Whether this drm enum property will be sufficient for CrOS Content
> protection needs of HDCP1.4.?
Yep, just the property. Userspace sets it to desired and polls it
until it's enabled. Here are the code pointers, I sent this to Marc
Herbert, so perhaps it's already gotten to you.
Threads to set/query hdcp state:
https://cs.chromium.org/chromium/src/ui/display/manager/chromeos/apply_content_protection_task.cc
https://cs.chromium.org/chromium/src/ui/display/manager/chromeos/query_content_protection_task.cc
Code which actually tweaks the drm props:
https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_display.cc
> Could you please help me on that direction?
>
> When i refer your RFC at
> https://lists.freedesktop.org/archives/dri-devel/2014-December/073418.html
> there is a drm range property called "Content Protection KSV", claimed to
> stand for content protection state.
> Is this used by current CrOS userspace stack?
>
No, it's not.
> As per the design I am proposing, SRM is passed to KMD and revocation check
> is done in kernel space.
I'm not completely against this, however I'm more partial to having
userspace handle SRM/revocation since it's not really a hardware
feature.
> How is this done in CrOS? CrOS uses the above mentioned ksv property for
> that purpose, to pass the ksv to UMD for revocation check?
We don't have SRM or revocation lists, but that was the idea should we
have needed it.
Sean
>
>
>
> V2: Redesigned the property to match with CP needs of CrOS.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/drm_connector.c | 14 +
> include/drm/drm_hdcp.h | 44
> +
> include/drm/drm_mode_config.h | 5 +
> 3 files changed, 63 insertions(+)
> create mode 100644 include/drm/drm_hdcp.h
>
> diff --git a/drivers/gpu/drm/drm_connector.c
> b/drivers/gpu/drm/drm_connector.c
> index 5cd61af..64895fb 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #include "drm_crtc_internal.h"
> #include "drm_internal.h"
> @@ -617,6 +618,13 @@ static const struct drm_prop_enum_list
> drm_link_status_enum_list[] = {
> };
> DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
>
> +static const struct drm_prop_enum_list drm_cp_enum_list[] = {
> + { DRM_CP_UNSUPPORTED, "CP Not Supported" },
> + { DRM_CP_DISABLE, "Disable CP" },
> + { DRM_CP_ENABLE, "Enable CP for Type0 content" },
>
> Type0 has no meaning in this case. The whole point of using "Content
> Protection"
> is to abstract the means of protection from userspace. The names are also
> much
> more verbose than they need be. "Unsupported", "Disabled", "Enabled" are
> fine.
>
> Looks like i was still trying to reflect that "Type1 is coming" ;). I will
> rename these in next revision. Thanks
>
>
> +};
> +DRM_ENUM_NAME_FN(drm_get_cp_status_name, drm_cp_enum_list)
> +
> /**
> * drm_display_info_set_bus_formats - set the supported bus formats
> * @info: display info to store bus formats in
> @@ -789,6 +797,12 @@ int drm_connector_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.link_status_property = prop;
>
> + prop = drm_property_create_enum(dev, 0, "cp", drm_cp_enum_list,
> + ARRAY_SIZE(drm_cp_enum_list));
>
> Your property name here, on the other hand, is not descriptive enough.
> Please
> expand to something meaningful.
>
> Will change it to "content protection"
>
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.cp_property = prop;
> +
> return 0;
> }
>
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
>
> Why create a new header for this? That seems a little excessive.
>
> But I am planning to use this header for all hdcp protocol specific
> definitions like HDCP2.2 messages and Panel's HDCP2.2 register definitions
> etc.
> With that I felt it justifies a header on it own.
> And this will grow fur
Re: [Intel-gfx] [PATCH 15/20] drm/i915: Don't touch fence->error when resetting an innocent request
Quoting Chris Wilson (2017-07-21 13:32:33)
> If the request has been completed before the reset took effect, we don't
> need to mark it up as being a victim. Touching fence->error after the
> fence has been signaled is detected by dma_fence_set_error() and
> triggers a BUG:
>
> [ 231.743133] kernel BUG at ./include/linux/dma-fence.h:434!
> [ 231.743156] invalid opcode: [#1] SMP KASAN
> [ 231.743172] Modules linked in: i915 drm_kms_helper drm iptable_nat
> nf_nat_ipv4 nf_nat x86_pkg_temp_thermal iosf_mbi i2c_algo_bit cfbfillrect
> syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea fb font
> fbdev [last unloaded: drm]
> [ 231.743221] CPU: 2 PID: 20 Comm: kworker/2:0 Tainted: G U
> 4.13.0-rc1+ #52
> [ 231.743236] Hardware name: Hewlett-Packard HP EliteBook 8460p/161C, BIOS
> 68SCF Ver. F.01 03/11/2011
> [ 231.743363] Workqueue: events_long i915_hangcheck_elapsed [i915]
> [ 231.743382] task: 8801f42e9780 task.stack: 8801f42f8000
> [ 231.743489] RIP: 0010:i915_gem_reset_engine+0x45a/0x460 [i915]
> [ 231.743505] RSP: 0018:8801f42ff770 EFLAGS: 00010202
> [ 231.743521] RAX: 0007 RBX: 8801bf6b1880 RCX:
> a02881a6
> [ 231.743537] RDX: dc00 RSI: dc00 RDI:
> 8801bf6b18c8
> [ 231.743551] RBP: 8801f42ff7c8 R08: 0001 R09:
>
> [ 231.743566] R10: R11: R12:
> 8801edb02d00
> [ 231.743581] R13: 8801e19d4200 R14: 001d R15:
> 8801ce2a4000
> [ 231.743599] FS: () GS:8801f5a8()
> knlGS:
> [ 231.743614] CS: 0010 DS: ES: CR0: 80050033
> [ 231.743629] CR2: 7f0ebd1add10 CR3: 02621000 CR4:
> 000406e0
> [ 231.743643] Call Trace:
> [ 231.743752] i915_gem_reset+0x6c/0x150 [i915]
> [ 231.743853] i915_reset+0x175/0x210 [i915]
> [ 231.743958] i915_reset_device+0x33b/0x350 [i915]
> [ 231.744061] ? valleyview_pipestat_irq_handler+0xe0/0xe0 [i915]
> [ 231.744081] ? trace_hardirqs_off_caller+0x70/0x110
> [ 231.744102] ? _raw_spin_unlock_irqrestore+0x46/0x50
> [ 231.744120] ? find_held_lock+0x119/0x150
> [ 231.744138] ? mark_lock+0x6d/0x850
> [ 231.744241] ? gen8_gt_irq_ack+0x1f0/0x1f0 [i915]
> [ 231.744262] ? work_on_cpu_safe+0x60/0x60
> [ 231.744284] ? rcu_read_lock_sched_held+0x57/0xa0
> [ 231.744400] ? gen6_read32+0x2ba/0x320 [i915]
> [ 231.744506] i915_handle_error+0x382/0x5f0 [i915]
> [ 231.744611] ? gen6_rps_reset_ei+0x20/0x20 [i915]
> [ 231.744630] ? vsnprintf+0x128/0x8e0
> [ 231.744649] ? pointer+0x6b0/0x6b0
> [ 231.744667] ? debug_check_no_locks_freed+0x1a0/0x1a0
> [ 231.744688] ? scnprintf+0x92/0xe0
> [ 231.744706] ? snprintf+0xb0/0xb0
> [ 231.744820] hangcheck_declare_hang+0x15a/0x1a0 [i915]
> [ 231.744932] ? engine_stuck+0x440/0x440 [i915]
> [ 231.744951] ? rcu_read_lock_sched_held+0x57/0xa0
> [ 231.745062] ? gen6_read32+0x2ba/0x320 [i915]
> [ 231.745173] ? gen6_read16+0x320/0x320 [i915]
> [ 231.745284] ? intel_engine_get_active_head+0x91/0x170 [i915]
> [ 231.745401] i915_hangcheck_elapsed+0x3d8/0x400 [i915]
> [ 231.745424] process_one_work+0x3e8/0xac0
> [ 231.745444] ? pwq_dec_nr_in_flight+0x110/0x110
> [ 231.745464] ? do_raw_spin_lock+0x8e/0x120
> [ 231.745484] worker_thread+0x8d/0x720
> [ 231.745506] kthread+0x19e/0x1f0
> [ 231.745524] ? process_one_work+0xac0/0xac0
> [ 231.745541] ? kthread_create_on_node+0xa0/0xa0
> [ 231.745560] ret_from_fork+0x27/0x40
> [ 231.745581] Code: 8b 7d c8 e8 49 0d 02 e1 49 8b 7f 38 48 8b 75 b8 48 83 c7
> 10 e8 b8 89 be e1 e9 95 fc ff ff 4c 89 e7 e8 4b b9 ff ff e9 30 ff ff ff <0f>
> 0b 0f 1f 40 00 55 48 89 e5 41 57 41 56 41 55 41 54 49 89 fe
> [ 231.745767] RIP: i915_gem_reset_engine+0x45a/0x460 [i915] RSP:
> 8801f42ff770
>
> At first glance this looks to be related to commit c64992e035d7
> ("drm/i915: Look for active requests earlier in the reset path"), but it
> could easily happen before as well. On the other hand, we no longer
> logged victims due to the active_request being dropped earlier.
>
> v2: Be trickier to unwind the incomplete request as we cannot rely on
> request retirement for the lockless per-engine reset.
> v3: Reprobe the active request at the time of the reset.
>
> Reported-by: Daniel Vetter
> Fixes: c64992e035d7 ("drm/i915: Look for active requests earlier in the reset
> path")
> Signed-off-by: Chris Wilson
> Cc: Michel Thierry
> Cc: Mika Kuoppala
> Cc: Daniel Vetter
Reviewed-by: Joonas Lahtinen #v1
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v2] drm/hdcp: drm enum property for HDCP State
On Monday 24 July 2017 06:53 PM, Sean Paul wrote:
On Fri, Jul 21, 2017 at 9:02 AM, Ramalingam C wrote:
Sorry for late response.
On Friday 14 July 2017 07:25 PM, Sean Paul wrote:
On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote:
DRM connector property is created to represent the content protection
state of the connector and to configure the same.
CP States defined:
DRM_CP_UNSUPPORTED - CP is not supported
DRM_CP_DISABLE - CP is disabled
DRM_CP_ENABLE - CP is enabled
Why are we changing the names from the original version (that's used in
CrOS)? It's not
obvious what "CP" stands for when looking at the name.
Sean,
Considering that we want to test this interface for CrOS stack as a
consumer, I will try to align the property names.
Meanwhile got few questions with respect to designing this CP interface
aligned with existing CrOS stack.
I want to understand what all are the bare minimal content protection
interface required for existing CrOS Userspace stack.
Whether this drm enum property will be sufficient for CrOS Content
protection needs of HDCP1.4.?
Yep, just the property. Userspace sets it to desired and polls it
until it's enabled. Here are the code pointers, I sent this to Marc
Herbert, so perhaps it's already gotten to you.
Threads to set/query hdcp state:
https://cs.chromium.org/chromium/src/ui/display/manager/chromeos/apply_content_protection_task.cc
https://cs.chromium.org/chromium/src/ui/display/manager/chromeos/query_content_protection_task.cc
Code which actually tweaks the drm props:
https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_display.cc
Could you please help me on that direction?
When i refer your RFC at
https://lists.freedesktop.org/archives/dri-devel/2014-December/073418.html
there is a drm range property called "Content Protection KSV", claimed to
stand for content protection state.
Is this used by current CrOS userspace stack?
No, it's not.
As per the design I am proposing, SRM is passed to KMD and revocation check
is done in kernel space.
I'm not completely against this, however I'm more partial to having
userspace handle SRM/revocation since it's not really a hardware
feature.
How is this done in CrOS? CrOS uses the above mentioned ksv property for
that purpose, to pass the ksv to UMD for revocation check?
We don't have SRM or revocation lists, but that was the idea should we
have needed it.
Sean
Thank you sean. This clears my doubts. I will share the reworked patch soon.
--Ram
V2: Redesigned the property to match with CP needs of CrOS.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/drm_connector.c | 14 +
include/drm/drm_hdcp.h | 44
+
include/drm/drm_mode_config.h | 5 +
3 files changed, 63 insertions(+)
create mode 100644 include/drm/drm_hdcp.h
diff --git a/drivers/gpu/drm/drm_connector.c
b/drivers/gpu/drm/drm_connector.c
index 5cd61af..64895fb 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -617,6 +618,13 @@ static const struct drm_prop_enum_list
drm_link_status_enum_list[] = {
};
DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
+static const struct drm_prop_enum_list drm_cp_enum_list[] = {
+ { DRM_CP_UNSUPPORTED, "CP Not Supported" },
+ { DRM_CP_DISABLE, "Disable CP" },
+ { DRM_CP_ENABLE, "Enable CP for Type0 content" },
Type0 has no meaning in this case. The whole point of using "Content
Protection"
is to abstract the means of protection from userspace. The names are also
much
more verbose than they need be. "Unsupported", "Disabled", "Enabled" are
fine.
Looks like i was still trying to reflect that "Type1 is coming" ;). I will
rename these in next revision. Thanks
+};
+DRM_ENUM_NAME_FN(drm_get_cp_status_name, drm_cp_enum_list)
+
/**
* drm_display_info_set_bus_formats - set the supported bus formats
* @info: display info to store bus formats in
@@ -789,6 +797,12 @@ int drm_connector_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.link_status_property = prop;
+ prop = drm_property_create_enum(dev, 0, "cp", drm_cp_enum_list,
+ ARRAY_SIZE(drm_cp_enum_list));
Your property name here, on the other hand, is not descriptive enough.
Please
expand to something meaningful.
Will change it to "content protection"
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cp_property = prop;
+
return 0;
}
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
Why create a new header for this? That seems a little excessive.
But I am planning to use this header for all hdcp protocol specific
definitions like HDCP2.2 messages and Panel's HDCP2.2 register definitions
etc.
With that I felt it justifies a header on it own.
And this will grow further when multiple spec versions are supported in
future.
-
[Intel-gfx] [PATCH v7 3/6] drm/i915: prepare pipe for YCBCR420 output
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
This patch:
- Adds definition of these bits.
- Programs PIPEMISC for YCBCR420 outputs.
- Adds readouts to compare HW and SW states.
V2: rebase
V3: rebase
V4: rebase
V5: added r-b from Ander
V6: Handle only YCBCR420 outputs (ville)
V7: rebase
V8: Addressed review comments from Ville
- Add readouts for state->ycbcr420 and 420 pixel_clock.
- Handle warning due to mismatch in clock for ycbcr420 clock.
- Rename PIPEMISC macros to match the Bspec.
- Add a debug print stating if YCBCR 4:2:0 output enabled.
Added r-b from Ville
V9: Addressed review comments from Imre:
- Add 420 mode clock adjustment in intel_hdmi_mode_valid to
prevent 420_only modes getting rejected for high clock.
- Add port clock adjustment for ycbcr420 modes in ddi_get_clock
- Rename macros as per Ville's suggestion.
- Remove unnecessary wl changes.
V10: Added r-b from Imre
V11: Fixed faulty dotclock handling, and addressed missing comment
from previous set of review comments (Imre)
V12: Fixed dotclock for 12bpc too, removed 420 check for GEN < 10
Cc: Ville Syrjala
Cc: Ander Conselvan de Oliveira
Cc: Daniel Vetter
Cc: Imre Deak
Reviewed-by: Ander Conselvan de Oliveira
Reviewed-by: Ville Syrjala
Reviewed-by: Imre Deak
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_ddi.c | 3 +++
drivers/gpu/drm/i915/intel_display.c | 27 +++
drivers/gpu/drm/i915/intel_hdmi.c| 3 +++
4 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c712d01..e5b4e2f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5227,6 +5227,9 @@ enum {
#define _PIPE_MISC_A 0x70030
#define _PIPE_MISC_B 0x71030
+#define PIPEMISC_YUV420_ENABLE (1<<27)
+#define PIPEMISC_YUV420_MODE_FULL_BLEND (1<<26)
+#define PIPEMISC_OUTPUT_COLORSPACE_YUV (1<<11)
#define PIPEMISC_DITHER_BPC_MASK (7<<5)
#define PIPEMISC_DITHER_8_BPC(0<<5)
#define PIPEMISC_DITHER_10_BPC (1<<5)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index efb1358..4a0e35e 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1174,6 +1174,9 @@ static void ddi_dotclock_get(struct intel_crtc_state
*pipe_config)
else
dotclock = pipe_config->port_clock;
+ if (pipe_config->ycbcr420)
+ dotclock *= 2;
+
if (pipe_config->pixel_multiplier)
dotclock /= pipe_config->pixel_multiplier;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 77d8119..146b817 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7933,6 +7933,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_crtc_state *config = intel_crtc->config;
if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
u32 val = 0;
@@ -7958,6 +7959,12 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
if (intel_crtc->config->dither)
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
+ if (config->ycbcr420) {
+ val |= PIPEMISC_OUTPUT_COLORSPACE_YUV |
+ PIPEMISC_YUV420_ENABLE |
+ PIPEMISC_YUV420_MODE_FULL_BLEND;
+ }
+
I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
}
}
@@ -9022,6 +9029,23 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
pipe_config->gamma_mode =
I915_READ(GAMMA_MODE(crtc->pipe)) & GAMMA_MODE_MODE_MASK;
+ if (IS_BROADWELL(dev_priv) || dev_priv->info.gen >= 9) {
+ u32 tmp = I915_READ(PIPEMISC(crtc->pipe));
+ bool clrspace_yuv = tmp & PIPEMISC_OUTPUT_COLORSPACE_YUV;
+
+ if (IS_GEMINILAKE(dev_priv) || dev_priv->info.gen >= 10) {
+ bool blend_mode_420 = tmp &
+ PIPEMISC_YUV420_MODE_FULL_BLEND;
+
+ pipe_config->ycbcr420 = tmp & PIPEMISC_YUV420_ENABLE;
+ if (pipe_config->ycbcr420 != clrspace_yuv ||
+ pipe_config->ycbcr420 != blend_mode_420)
+ DRM_DEBUG_KMS("Bad 4:2:0 mode (%08x)\n", tmp);
+ } else if (clrspace_yuv) {
+ DRM_DEBUG_KMS("YCbCr 4:2:
[Intel-gfx] ✓ Fi.CI.BAT: success for YCBCR 4:2:0 handling in i915 layer (rev4)
== Series Details == Series: YCBCR 4:2:0 handling in i915 layer (rev4) URL : https://patchwork.freedesktop.org/series/27412/ State : success == Summary == Series 27412v4 YCBCR 4:2:0 handling in i915 layer https://patchwork.freedesktop.org/api/1.0/series/27412/revisions/4/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:441s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:433s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:356s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:541s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:512s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:490s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:489s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:600s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:435s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:416s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:415s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:504s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:472s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:456s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:573s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:590s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:560s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:466s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:586s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:470s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:477s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:436s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:477s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:546s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:404s 2a4f73050a961e1a176d35561e39386da9ea9c67 drm-tip: 2017y-07m-21d-15h-30m-47s UTC integration manifest 9959a2f drm/i915/glk: set HDMI 2.0 identifier c7dde1f drm/i915: set colorspace for YCBCR420 outputs 38b8b12 drm/i915: prepare csc unit for YCBCR420 output fd738aa drm/i915: prepare pipe for YCBCR420 output 21dfa85 drm/i915: prepare scaler for YCBCR420 modeset 1493aee drm/i915: add config function for YCBCR420 outputs == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5267/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 0/3] Add support for loadable OA configs
Hi, Just a quick update, I forgot Chris' comment about renaming the pointers fields in the uapi. Cheers, Lionel Landwerlin (3): drm/i915/perf: fix flex eu registers programming drm/i915/perf: prune OA configs drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface drivers/gpu/drm/i915/i915_drv.c |2 + drivers/gpu/drm/i915/i915_drv.h | 91 +- drivers/gpu/drm/i915/i915_oa_bdw.c| 5360 + drivers/gpu/drm/i915/i915_oa_bdw.h|8 +- drivers/gpu/drm/i915/i915_oa_bxt.c| 2623 +--- drivers/gpu/drm/i915/i915_oa_bxt.h|8 +- drivers/gpu/drm/i915/i915_oa_chv.c| 2806 + drivers/gpu/drm/i915/i915_oa_chv.h|8 +- drivers/gpu/drm/i915/i915_oa_glk.c| 2535 +--- drivers/gpu/drm/i915/i915_oa_glk.h|8 +- drivers/gpu/drm/i915/i915_oa_hsw.c| 764 + drivers/gpu/drm/i915/i915_oa_hsw.h|8 +- drivers/gpu/drm/i915/i915_oa_kblgt2.c | 2971 +- drivers/gpu/drm/i915/i915_oa_kblgt2.h |8 +- drivers/gpu/drm/i915/i915_oa_kblgt3.c | 3020 +-- drivers/gpu/drm/i915/i915_oa_kblgt3.h |8 +- drivers/gpu/drm/i915/i915_oa_sklgt2.c | 3458 + drivers/gpu/drm/i915/i915_oa_sklgt2.h |8 +- drivers/gpu/drm/i915/i915_oa_sklgt3.c | 3019 +-- drivers/gpu/drm/i915/i915_oa_sklgt3.h |8 +- drivers/gpu/drm/i915/i915_oa_sklgt4.c | 3073 +-- drivers/gpu/drm/i915/i915_oa_sklgt4.h |8 +- drivers/gpu/drm/i915/i915_perf.c | 708 +++-- drivers/gpu/drm/i915/i915_reg.h |2 + include/uapi/drm/i915_drm.h | 20 + 25 files changed, 969 insertions(+), 29563 deletions(-) -- 2.13.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 1/3] drm/i915/perf: fix flex eu registers programming
We were reserving fewer dwords in the ring than necessary. Indeed
we're always writing all registers once, so discard the actual number
of registers given by the user and just program the whitelisted ones
once.
Fixes: 19f81df2859e ("drm/i915/perf: Add OA unit support for Gen 8+")
Reported-by: Matthew Auld
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
Cc: # v4.12+
---
drivers/gpu/drm/i915/i915_perf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 96682fd86f82..df78bfa9e574 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1601,11 +1601,11 @@ static int gen8_emit_oa_config(struct
drm_i915_gem_request *req)
u32 *cs;
int i;
- cs = intel_ring_begin(req, n_flex_regs * 2 + 4);
+ cs = intel_ring_begin(req, ARRAY_SIZE(flex_mmio) * 2 + 4);
if (IS_ERR(cs))
return PTR_ERR(cs);
- *cs++ = MI_LOAD_REGISTER_IMM(n_flex_regs + 1);
+ *cs++ = MI_LOAD_REGISTER_IMM(ARRAY_SIZE(flex_mmio) + 1);
*cs++ = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
*cs++ = (dev_priv->perf.oa.period_exponent <<
GEN8_OA_TIMER_PERIOD_SHIFT) |
--
2.13.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 3/3] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface
The motivation behind this new interface is expose at runtime the
creation of new OA configs which can be used as part of the i915 perf
open interface. This will enable the kernel to learn new configs which
may be experimental, or otherwise not part of the core set currently
available through the i915 perf interface.
v2: Drop DRM_ERROR for userspace errors (Matthew)
Add padding to userspace structure (Matthew)
s/guid/uuid/ (Matthew)
v3: Use u32 instead of int to iterate through registers (Matthew)
v4: Lock access to dynamic config list (Lionel)
v5: by Matthew:
Fix uninitialized error values
Fix incorrect unwiding when opening perf stream
Use kmalloc_array() to store register
Use uuid_is_valid() to valid config uuids
Declare ioctls as write only
Check padding members are set to 0
by Lionel:
Return ENOENT rather than EINVAL when trying to remove non
existing config
v6: by Chris:
Use ref counts for OA configs
Store UUID in drm_i915_perf_oa_config rather then using pointer
Shuffle fields of drm_i915_perf_oa_config to avoid padding
v7: by Chris
Rename uapi pointers fields to end with '_ptr'
Signed-off-by: Matthew Auld
Signed-off-by: Lionel Landwerlin
Signed-off-by: Andrzej Datczuk
---
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 47 +
drivers/gpu/drm/i915/i915_perf.c | 414 +--
drivers/gpu/drm/i915/i915_reg.h | 2 +
include/uapi/drm/i915_drm.h | 20 ++
5 files changed, 471 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3ac8215c0e36..95849ba3b6aa 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2725,6 +2725,8 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM,
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM,
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG,
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
};
static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 36b217f852ab..fda22803580b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1912,6 +1912,8 @@ struct i915_oa_config {
struct attribute_group sysfs_metric;
struct attribute *attrs[2];
struct device_attribute sysfs_metric_id;
+
+ atomic_t ref_count;
};
struct i915_perf_stream;
@@ -2038,6 +2040,25 @@ struct i915_perf_stream {
*/
struct i915_oa_ops {
/**
+* @is_valid_b_counter_reg: Validates register's address for
+* programming boolean counters for a particular platform.
+*/
+ bool (*is_valid_b_counter_reg)(struct drm_i915_private *dev_priv,
+ u32 addr);
+
+ /**
+* @is_valid_mux_reg: Validates register's address for programming mux
+* for a particular platform.
+*/
+ bool (*is_valid_mux_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+ /**
+* @is_valid_flex_reg: Validates register's address for programming
+* flex EU filtering for a particular platform.
+*/
+ bool (*is_valid_flex_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+ /**
* @init_oa_buffer: Resets the head and tail pointers of the
* circular buffer for periodic OA reports.
*
@@ -2421,10 +2442,32 @@ struct drm_i915_private {
struct kobject *metrics_kobj;
struct ctl_table_header *sysctl_header;
+ /*
+* Lock associated with adding/modifying/removing OA configs
+* in dev_priv->perf.metrics_idr.
+*/
+ struct mutex metrics_lock;
+
+ /*
+* List of dynamic configurations, you need to hold
+* dev_priv->perf.metrics_lock to access it.
+*/
+ struct idr metrics_idr;
+
+ /*
+* Lock associated with anything below within this structure
+* except exclusive_stream.
+*/
struct mutex lock;
struct list_head streams;
struct {
+ /*
+* The stream currently using the OA unit. If accessed
+* outside a syscall associated to its file
+* descriptor, you need to hold
+* dev_priv->drm.struct_mutex.
+*/
struct i915_per
[Intel-gfx] [PATCH] dim: remove debug output
Oops. It caused some concerns from people running dim rebuild-tip. Signed-off-by: Daniel Vetter --- dim | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/dim b/dim index dca73687b69e..1849a0d0e6ba 100755 --- a/dim +++ b/dim @@ -516,10 +516,9 @@ function commit_rerere_cache rm $(rr_cache_dir)/rr-cache -Rf &> /dev/null || true cp $(rr_cache_dir)/* rr-cache -r --preserve=timestamps git add ./*.patch >& /dev/null || true - for file in $(git ls-files); do + for file in $(find rr-cache/); do if ! git log --since="60 days ago" --name-only -- $file | grep $file &> /dev/null; then git rm $file &> /dev/null - echo deleting $file fi done find rr-cache/ -ctime -1 -type f -print0 | xargs -0 git add > /dev/null -- 2.13.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Unify the HSW/BDW and GEN9+ power well code (rev9)
On Wed, Jul 12, 2017 at 08:17:00PM +0300, Imre Deak wrote: > On Wed, Jul 12, 2017 at 04:17:08PM +, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: Unify the HSW/BDW and GEN9+ power well code (rev9) > > URL : https://patchwork.freedesktop.org/series/26922/ > > State : failure > > > > == Summary == > > > > Series 26922v9 drm/i915: Unify the HSW/BDW and GEN9+ power well code > > https://patchwork.freedesktop.org/api/1.0/series/26922/revisions/9/mbox/ Thanks for the reviews I pushed the patchset to -dinq. > > > > Test core_auth: > > Subgroup basic-auth: > > pass -> DMESG-WARN (fi-ivb-3770) > > Test core_prop_blob: > > Subgroup basic: > > pass -> DMESG-WARN (fi-ivb-3770) > > Test drv_getparams_basic: > > Subgroup basic-eu-total: > > pass -> DMESG-WARN (fi-ivb-3770) > > Subgroup basic-subslice-total: > > pass -> DMESG-WARN (fi-ivb-3770) > > Test drv_hangman: > > Subgroup error-state-basic: > > pass -> DMESG-WARN (fi-ivb-3770) > > Test gem_basic: > > Subgroup bad-close: > > pass -> DMESG-WARN (fi-ivb-3770) > > Subgroup create-close: > > pass -> DMESG-WARN (fi-ivb-3770) > > Subgroup create-fd-close: > > pass -> DMESG-WARN (fi-ivb-3770) > > Test gem_busy: > > Subgroup basic-busy-default: > > pass -> DMESG-WARN (fi-ivb-3770) > > Subgroup basic-hang-default: > > pass -> DMESG-WARN (fi-ivb-3770) > > Test gem_close_race: > > Subgroup basic-process: > > pass -> DMESG-WARN (fi-ivb-3770) > > Subgroup basic-threads: > > pass -> DMESG-WARN (fi-ivb-3770) > > Test gem_cpu_reloc: > > Subgroup basic: > > pass -> DMESG-WARN (fi-ivb-3770) > > Test gem_cs_tlb: > > Subgroup basic-default: > > pass -> DMESG-WARN (fi-ivb-3770) > > Test gem_ctx_basic: > > pass -> DMESG-WARN (fi-ivb-3770) > > Test gem_ctx_create: > > Subgroup basic: > > pass -> DMESG-WARN (fi-ivb-3770) > > Subgroup basic-files: > > pass -> DMESG-WARN (fi-ivb-3770) > > Test gem_ctx_exec: > > Subgroup basic: > > pass -> DMESG-WARN (fi-ivb-3770) > > Test gem_ctx_param: > > Subgroup basic: > > pass -> DMESG-WARN (fi-ivb-3770) > > Subgroup basic-default: > > pass -> DMESG-WARN (fi-ivb-3770) > > Test gem_ctx_switch: > > Subgroup basic-default: > > pass -> DMESG-WARN (fi-ivb-3770) > > Subgroup basic-default-heavy: > > pass -> DMESG-WARN (fi-ivb-3770) > > Test gem_exec_basic: > > Subgroup basic-blt: > > pass -> DMESG-WARN (fi-ivb-3770) > > Subgroup basic-bsd: > > pass -> DMESG-WARN (fi-ivb-3770) > > Subgroup basic-default: > > pass -> INCOMPLETE (fi-ivb-3770) > > Can't see how the above failures could be related to the change. The log has a > few errors: > [1.892721] irq 16: nobody cared (try booting with the "irqpoll" option) > ... > [1.892826] Disabling IRQ #16 > > But that IRQ belongs to the USB driver. Then some ACPI errors like: > > [2.246024] ACPI Warning: SystemIO range > 0x0428-0x042F conflicts with OpRegion > 0x0400-0x047F (\PMIO) (20170303/utaddress-247) > > followed by vblank and flip timeouts on pipe A. The first one: > > [4.768197] vblank wait timed out on crtc 0 > [4.768210] [ cut here ] > [4.768215] WARNING: CPU: 4 PID: 148 at drivers/gpu/drm/drm_vblank.c:1066 > drm_wait_one_vblank+0x191/0x1a0 > [4.768216] Modules linked in: i915 x86_pkg_temp_thermal intel_powerclamp > coretemp crct10dif_pclmul crc32_pclmul r8169 snd_hda_intel > ghash_clmulni_intel snd_hda_codec snd_hwdep mii snd_hda_core snd_pcm mei_me > mei lpc_ich prime_numbers > [4.768234] CPU: 4 PID: 148 Comm: kworker/u16:4 Not tainted > 4.12.0-CI-Patchwork_5174+ #1 > [4.768235] Hardware name: Hewlett-Packard HP Pro 3500 Series/2ABF, BIOS > 8.11 10/24/2012 > [4.768238] Workqueue: events_unbound async_run_entry_fn > [4.768240] task: 880117690040 task.stack: c9758000 > [4.768242] RIP: 0010:drm_wait_one_vblank+0x191/0x1a0 > [4.768243] RSP: 0018:c975b710 EFLAGS: 00010282 > [4.768245] RAX: 001f RBX: 88010e8a RCX: > 0006 > [4.768246] RDX: 0006 RSI: 81cba7da RDI: > 81c99e7f > [4.768247] RBP: c975b768 R08: R09: > 0001 > [4.768248] R10: R11: R12: > 000
[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for loadable OA configs
== Series Details == Series: Add support for loadable OA configs URL : https://patchwork.freedesktop.org/series/27803/ State : success == Summary == Series 27803v1 Add support for loadable OA configs https://patchwork.freedesktop.org/api/1.0/series/27803/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: pass -> FAIL (fi-snb-2600) fdo#100215 Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> SKIP (fi-skl-x1585l) fdo#101781 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-b: dmesg-warn -> PASS (fi-pnv-d510) fdo#101597 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:428s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:419s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:360s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:481s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:483s fi-byt-j1900 total:279 pass:255 dwarn:0 dfail:0 fail:0 skip:24 time:489s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:485s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:579s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:431s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:404s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:413s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:508s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:471s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:455s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:563s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:566s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:567s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:445s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:577s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:631s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:462s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:423s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:471s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:541s fi-snb-2600 total:279 pass:248 dwarn:0 dfail:0 fail:2 skip:29 time:412s 4de285ac1e74f3e1b7bf6a65be720bc6ac9ddbf3 drm-tip: 2017y-07m-24d-13h-58m-27s UTC integration manifest 654cf1d drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface 5e5600e drm/i915/perf: prune OA configs 7f6c5e5 drm/i915/perf: fix flex eu registers programming == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5268/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable fine-grained kcov instrumentation
Quoting Chris Wilson (2016-08-03 20:38:53)
> In the next merge, we can build support for kcov at the individual file,
Since a4691deabf28 ("kcov: allow more fine-grained coverage instrumentation"),
> or driver level. This is useful to filter out the noise when doing
> coverage test, i.e. we do get edges through code outside of i915.ko.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/Kconfig.debug | 12
> drivers/gpu/drm/i915/Makefile | 1 +
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig.debug
> b/drivers/gpu/drm/i915/Kconfig.debug
> index cee87bfd10c4..eb38270d0ecd 100644
> --- a/drivers/gpu/drm/i915/Kconfig.debug
> +++ b/drivers/gpu/drm/i915/Kconfig.debug
> @@ -42,3 +42,15 @@ config DRM_I915_DEBUG_GEM
>
>If in doubt, say "N".
>
> +config DRM_I915_KCOV
> + bool "Generate fine-grained code coverage (for kcov)"
> + default n
> + select KCOV
> + help
> + Enable instrumentation of i915.ko to generate coverage via kcov
> + (/sys/kernel/debug/kcov). This allows coverage driven fuzzing,
> + such as AFL, to be used and focused on the driver.
> +
> + Recommended for driver developers only.
> +
> + If in doubt, say "N".
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 0afe7b3cad07..2f4bbaca5b60 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -3,6 +3,7 @@
> # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>
> subdir-ccflags-$(CONFIG_DRM_I915_WERROR) := -Werror
> +subdir-ccflags-$(CONFIG_DRM_I915_KCOV) := $(CFLAGS_KCOV)
> subdir-ccflags-y += \
> $(call as-instr,movntdqa (%eax)$(comma)%xmm0,-DCONFIG_AS_MOVNTDQA)
>
> --
> 2.8.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable fine-grained kcov instrumentation
Quoting Chris Wilson (2016-08-03 20:38:53) > In the next merge, we can build support for kcov at the individual file, > or driver level. This is useful to filter out the noise when doing > coverage test, i.e. we do get edges through code outside of i915.ko. > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/Kconfig.debug | 12 > drivers/gpu/drm/i915/Makefile | 1 + > 2 files changed, 13 insertions(+) > > diff --git a/drivers/gpu/drm/i915/Kconfig.debug > b/drivers/gpu/drm/i915/Kconfig.debug > index cee87bfd10c4..eb38270d0ecd 100644 > --- a/drivers/gpu/drm/i915/Kconfig.debug > +++ b/drivers/gpu/drm/i915/Kconfig.debug > @@ -42,3 +42,15 @@ config DRM_I915_DEBUG_GEM > >If in doubt, say "N". > > +config DRM_I915_KCOV > + bool "Generate fine-grained code coverage (for kcov)" > + default n > + select KCOV > + help > + Enable instrumentation of i915.ko to generate coverage via kcov > + (/sys/kernel/debug/kcov). This allows coverage driven fuzzing, > + such as AFL, to be used and focused on the driver. > + > + Recommended for driver developers only. > + > + If in doubt, say "N". > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile > index 0afe7b3cad07..2f4bbaca5b60 100644 > --- a/drivers/gpu/drm/i915/Makefile > +++ b/drivers/gpu/drm/i915/Makefile > @@ -3,6 +3,7 @@ > # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. > > subdir-ccflags-$(CONFIG_DRM_I915_WERROR) := -Werror > +subdir-ccflags-$(CONFIG_DRM_I915_KCOV) := $(CFLAGS_KCOV) s/:=/+=/ > subdir-ccflags-y += \ > $(call as-instr,movntdqa (%eax)$(comma)%xmm0,-DCONFIG_AS_MOVNTDQA) > > -- > 2.8.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Detect monitor change from EDID change after resume
This introduces a dedicated work and related helpers to detect whether
a monitor was replaced by another one during suspend. This detection is
based on EDID change detection, using the associated generic drm helper.
This requires storing more information to the intel_connector structure,
such as the i2c adapter required to get the EDID.
Support for this is introduced for DP, HDMI and VGA.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 5
drivers/gpu/drm/i915/intel_crt.c | 3 +++
drivers/gpu/drm/i915/intel_display.c | 50
drivers/gpu/drm/i915/intel_dp.c | 3 +++
drivers/gpu/drm/i915/intel_drv.h | 6 +
drivers/gpu/drm/i915/intel_hdmi.c| 3 +++
7 files changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3ac8215c0e36..b3cf4112fc65 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1702,6 +1702,8 @@ static int i915_drm_resume(struct drm_device *dev)
intel_display_resume(dev);
+ intel_edid_changes_detect(dev);
+
drm_kms_helper_poll_enable(dev);
/*
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b051122c960b..2c189a5b714e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3904,6 +3904,11 @@ intel_display_capture_error_state(struct
drm_i915_private *dev_priv);
extern void intel_display_print_error_state(struct drm_i915_error_state_buf *e,
struct intel_display_error_state
*error);
+/* edid change */
+void intel_edid_change_init(struct intel_connector *connector,
+ struct i2c_adapter *adapter);
+void intel_edid_changes_detect(struct drm_device *dev);
+
int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32
*val);
int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox, u32
val);
int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32 request,
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 84a1f5e85153..63e2184a6ea4 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -925,6 +925,9 @@ void intel_crt_init(struct drm_i915_private *dev_priv)
*/
crt->force_hotplug_required = 0;
+ intel_edid_change_init(intel_connector,
+ intel_gmbus_get_adapter(dev_priv,
dev_priv->vbt.crt_ddc_pin));
+
/*
* TODO: find a proper way to discover whether we need to set the the
* polarity and link reversal bits or not, instead of relying on the
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6c823cc02db3..69e306759a02 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15016,3 +15016,53 @@ intel_display_print_error_state(struct
drm_i915_error_state_buf *m,
}
#endif
+
+static void intel_edid_change_work_func(struct work_struct *work)
+{
+ struct intel_connector *connector =
+ container_of(work, struct intel_connector, edid_change_work);
+ bool changed;
+
+ changed = drm_check_edid_changed(&connector->base, connector->adapter);
+ if (changed) {
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] EDID change detected\n",
+ connector->base.base.id, connector->base.name);
+
+ drm_kms_helper_hotplug_event(connector->base.dev);
+ }
+}
+
+/**
+ * intel_edid_change_init - init the EDID change data
+ * @connector: DRM connector device to use
+ * @adapter: i2c adapter
+ *
+ * Store the i2c adapter and initialize the EDID change detection work.
+ */
+void intel_edid_change_init(struct intel_connector *connector,
+ struct i2c_adapter *adapter)
+{
+ connector->adapter = adapter;
+
+ INIT_WORK(&connector->edid_change_work, intel_edid_change_work_func);
+}
+
+/**
+ * intel_edid_changes_detect - detect EDID changes to connectors
+ * @dev: DRM device to get connectors from
+ *
+ * Schedule the EDID detection change work for all registered connectors.
+ */
+void intel_edid_changes_detect(struct drm_device *dev)
+{
+ struct intel_connector *connector;
+ struct drm_connector_list_iter conn_iter;
+
+ drm_connector_list_iter_begin(dev, &conn_iter);
+ for_each_intel_connector_iter(connector, &conn_iter) {
+ if (!connector->adapter)
+ continue;
+
+ schedule_work(&connector->edid_change_work);
+ }
+}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2d42d09428c9..bc4dbb076096 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6063,6 +6063,9 @@ intel_dp_init_connector(struct int
[Intel-gfx] [PATCH 1/2] drm/edid: Add helper to detect whether EDID changed
This adds a common drm helper to detect whether the EDID changed from
the last known cached one. This is useful help detect that a monitor was
changed during a suspend/resume cycle.
When that happens (a monitor is replaced by another one during suspend),
no hotplug event will be triggered so the change will not be caught at
resume time. Detecting that the EDID changed allows detecting it.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/drm_edid.c | 45 +
include/drm/drm_edid.h | 3 +++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6bb6337be920..f6ce8bc2907a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5036,3 +5036,48 @@ static void drm_get_displayid(struct drm_connector
*connector,
}
return;
}
+
+/**
+ * drm_check_edid_changed - Check whether the EDID changed since the last
update
+ * @connector: connector we're probing
+ * @adapter: I2C adapter to use for DDC
+ *
+ * Check whether the EDID changed since the last time it was updated in the
+ * drm blob cache.
+ *
+ * Return: A boolean indicating whether a change happened or not.
+ */
+bool drm_check_edid_changed(struct drm_connector *connector,
+ struct i2c_adapter *adapter)
+{
+ struct drm_property_blob *edid_blob;
+ struct edid *edid_stored;
+ struct edid *edid_read;
+ int ret = 0;
+
+ if (!connector->edid_blob_ptr)
+ return false;
+
+ edid_blob = drm_property_blob_get(connector->edid_blob_ptr);
+ if (!edid_blob)
+ return false;
+
+ if (!edid_blob->data || edid_blob->length != sizeof(struct edid))
+ goto out;
+
+ edid_stored = (struct edid *) edid_blob->data;
+
+ edid_read = drm_get_edid(connector, adapter);
+ if (!edid_read)
+ goto out;
+
+ ret = memcmp(edid_stored, edid_read, sizeof(struct edid));
+
+ kfree(edid_read);
+
+out:
+ drm_property_blob_put(edid_blob);
+
+ return ret != 0;
+}
+EXPORT_SYMBOL_GPL(drm_check_edid_changed);
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 1e1908a6b1d6..593a97b269c3 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -485,4 +485,7 @@ void drm_edid_get_monitor_name(struct edid *edid, char
*name,
struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
int hsize, int vsize, int fresh,
bool rb);
+bool drm_check_edid_changed(struct drm_connector *connector,
+ struct i2c_adapter *adapter);
+
#endif /* __DRM_EDID_H__ */
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for YCBCR 4:2:0 handling in i915 layer (rev4)
On Mon, Jul 24, 2017 at 02:03:31PM +, Patchwork wrote: > == Series Details == > > Series: YCBCR 4:2:0 handling in i915 layer (rev4) > URL : https://patchwork.freedesktop.org/series/27412/ > State : success > > == Summary == > > Series 27412v4 YCBCR 4:2:0 handling in i915 layer > https://patchwork.freedesktop.org/api/1.0/series/27412/revisions/4/mbox/ Thanks for the patches and reviews, I pushed the patches to -dinq. A note about commit logs for the future: you should only add your own Signed-off-by line, whoever commits it will add their own. > > Test gem_exec_flush: > Subgroup basic-batch-kernel-default-uc: > fail -> PASS (fi-snb-2600) fdo#17 > > fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 > > fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 > time:441s > fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 > time:433s > fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 > time:356s > fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 > time:541s > fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 > time:512s > fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 > time:490s > fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 > time:489s > fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 > time:600s > fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 > time:435s > fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 > time:416s > fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 > time:415s > fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:504s > fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:472s > fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:456s > fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:573s > fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:590s > fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 > time:560s > fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:466s > fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 > time:586s > fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:470s > fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:477s > fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 > time:436s > fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 > time:477s > fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 > time:546s > fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 > time:404s > > 2a4f73050a961e1a176d35561e39386da9ea9c67 drm-tip: 2017y-07m-21d-15h-30m-47s > UTC integration manifest > 9959a2f drm/i915/glk: set HDMI 2.0 identifier > c7dde1f drm/i915: set colorspace for YCBCR420 outputs > 38b8b12 drm/i915: prepare csc unit for YCBCR420 output > fd738aa drm/i915: prepare pipe for YCBCR420 output > 21dfa85 drm/i915: prepare scaler for YCBCR420 modeset > 1493aee drm/i915: add config function for YCBCR420 outputs > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5267/ > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/edid: Add helper to detect whether EDID changed
== Series Details == Series: series starting with [1/2] drm/edid: Add helper to detect whether EDID changed URL : https://patchwork.freedesktop.org/series/27807/ State : warning == Summary == Series 27807v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/27807/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s3: pass -> DMESG-WARN (fi-blb-e6850) pass -> DMESG-WARN (fi-ilk-650) pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-ivb-3520m) pass -> DMESG-WARN (fi-ivb-3770) pass -> DMESG-WARN (fi-byt-j1900) pass -> DMESG-WARN (fi-byt-n2820) pass -> DMESG-WARN (fi-hsw-4770) pass -> DMESG-WARN (fi-hsw-4770r) pass -> DMESG-WARN (fi-bdw-5557u) fdo#101891 pass -> DMESG-WARN (fi-bdw-gvtdvm) pass -> DMESG-WARN (fi-bsw-n3050) pass -> DMESG-WARN (fi-skl-6260u) pass -> DMESG-WARN (fi-skl-6700hq) pass -> DMESG-WARN (fi-skl-6700k) pass -> DMESG-WARN (fi-skl-6770hq) pass -> DMESG-WARN (fi-skl-gvtdvm) pass -> DMESG-WARN (fi-skl-x1585l) pass -> DMESG-WARN (fi-bxt-j4205) pass -> DMESG-WARN (fi-kbl-7500u) pass -> DMESG-WARN (fi-kbl-7560u) pass -> DMESG-WARN (fi-kbl-r) pass -> DMESG-WARN (fi-glk-2a) Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-blb-e6850) pass -> DMESG-WARN (fi-ilk-650) pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-ivb-3520m) pass -> DMESG-WARN (fi-ivb-3770) pass -> DMESG-WARN (fi-byt-j1900) pass -> DMESG-WARN (fi-byt-n2820) pass -> DMESG-WARN (fi-hsw-4770) pass -> DMESG-WARN (fi-hsw-4770r) pass -> DMESG-WARN (fi-bdw-5557u) pass -> DMESG-WARN (fi-bdw-gvtdvm) pass -> DMESG-WARN (fi-bsw-n3050) pass -> DMESG-WARN (fi-skl-6260u) pass -> DMESG-WARN (fi-skl-6700hq) pass -> DMESG-WARN (fi-skl-6700k) pass -> DMESG-WARN (fi-skl-6770hq) pass -> DMESG-WARN (fi-skl-gvtdvm) pass -> DMESG-WARN (fi-skl-x1585l) pass -> DMESG-WARN (fi-bxt-j4205) pass -> DMESG-WARN (fi-kbl-7500u) pass -> DMESG-WARN (fi-kbl-7560u) pass -> DMESG-WARN (fi-kbl-r) pass -> DMESG-WARN (fi-glk-2a) Test gem_flink_basic: Subgroup bad-flink: pass -> DMESG-WARN (fi-bdw-gvtdvm) pass -> DMESG-WARN (fi-skl-6700hq) pass -> DMESG-WARN (fi-skl-gvtdvm) pass -> DMESG-WARN (fi-kbl-r) Subgroup bad-open: pass -> DMESG-WARN (fi-bdw-gvtdvm) pass -> DMESG-WARN (fi-skl-6700hq) pass -> DMESG-WARN (fi-skl-gvtdvm) pass -> DMESG-WARN (fi-kbl-r) Subgroup basic: pass -> DMESG-WARN (fi-bdw-gvtdvm) pass -> DMESG-WARN (fi-skl-6700hq) pass -> DMESG-WARN (fi-skl-gvtdvm) pass -> DMESG-WARN (fi-kbl-r) Subgroup double-flink: pass -> DMESG-WARN (fi-bdw-gvtdvm) pass -> DMESG-WARN (fi-skl-6700hq) pass -> DMESG-WARN (fi-skl-gvtdvm) pass -> DMESG-WARN (fi-kbl-r) Subgroup flink-lifetime: pass -> DMESG-WARN (fi-bdw-gvtdvm) pass -> DMESG-WARN (fi-skl-6700hq) pass -> DMESG-WARN (fi-skl-gvtdvm) pass -> DMESG-WARN (fi-kbl-r) Test gem_linear_blits: Subgroup basic: pass -> DMESG-WARN (fi-bdw-gvtdvm) pass -> DMESG-WARN (fi-skl-6700hq) pass -> DMESG-WARN (fi-skl-gvtdvm) pass -> DMESG-WARN (fi-kbl-r) Test gem_mmap: Subgroup basic: pass -> DMESG-WARN (fi-bdw-gvtdvm) pass -> DMESG-WARN (fi-skl-6700hq) pass -> DMESG-WARN (fi-skl-gvtdvm) pas
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for YCBCR 4:2:0 handling in i915 layer (rev4)
On Mon, Jul 24, 2017 at 06:02:46PM +0300, Imre Deak wrote: > On Mon, Jul 24, 2017 at 02:03:31PM +, Patchwork wrote: > > == Series Details == > > > > Series: YCBCR 4:2:0 handling in i915 layer (rev4) > > URL : https://patchwork.freedesktop.org/series/27412/ > > State : success > > > > == Summary == > > > > Series 27412v4 YCBCR 4:2:0 handling in i915 layer > > https://patchwork.freedesktop.org/api/1.0/series/27412/revisions/4/mbox/ > > Thanks for the patches and reviews, I pushed the patches to -dinq. > > A note about commit logs for the future: you should only add your own > Signed-off-by line, whoever commits it will add their own. The above Signed-off-by lines for me weren't actually added by you, but dim apply-queued automatically, so the patches you sent were fine. Sorry for the noise, Imre > > > > > Test gem_exec_flush: > > Subgroup basic-batch-kernel-default-uc: > > fail -> PASS (fi-snb-2600) fdo#17 > > > > fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 > > > > fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 > > time:441s > > fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 > > time:433s > > fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 > > time:356s > > fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 > > time:541s > > fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 > > time:512s > > fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 > > time:490s > > fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 > > time:489s > > fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 > > time:600s > > fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 > > time:435s > > fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 > > time:416s > > fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 > > time:415s > > fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > > time:504s > > fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > > time:472s > > fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > > time:456s > > fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > > time:573s > > fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > > time:590s > > fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 > > time:560s > > fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > > time:466s > > fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 > > time:586s > > fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > > time:470s > > fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > > time:477s > > fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 > > time:436s > > fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 > > time:477s > > fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 > > time:546s > > fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 > > time:404s > > > > 2a4f73050a961e1a176d35561e39386da9ea9c67 drm-tip: 2017y-07m-21d-15h-30m-47s > > UTC integration manifest > > 9959a2f drm/i915/glk: set HDMI 2.0 identifier > > c7dde1f drm/i915: set colorspace for YCBCR420 outputs > > 38b8b12 drm/i915: prepare csc unit for YCBCR420 output > > fd738aa drm/i915: prepare pipe for YCBCR420 output > > 21dfa85 drm/i915: prepare scaler for YCBCR420 modeset > > 1493aee drm/i915: add config function for YCBCR420 outputs > > > > == Logs == > > > > For more details see: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5267/ > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/edid: Add helper to detect whether EDID changed
On 2017-07-24 10:54 AM, Paul Kocialkowski wrote:
> This adds a common drm helper to detect whether the EDID changed from
> the last known cached one. This is useful help detect that a monitor was
> changed during a suspend/resume cycle.
>
> When that happens (a monitor is replaced by another one during suspend),
> no hotplug event will be triggered so the change will not be caught at
> resume time. Detecting that the EDID changed allows detecting it.
>
This makes sense and could be used by other drivers.
Acked-by: Harry Wentland
Harry
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/gpu/drm/drm_edid.c | 45 +
> include/drm/drm_edid.h | 3 +++
> 2 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 6bb6337be920..f6ce8bc2907a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5036,3 +5036,48 @@ static void drm_get_displayid(struct drm_connector
> *connector,
> }
> return;
> }
> +
> +/**
> + * drm_check_edid_changed - Check whether the EDID changed since the last
> update
> + * @connector: connector we're probing
> + * @adapter: I2C adapter to use for DDC
> + *
> + * Check whether the EDID changed since the last time it was updated in the
> + * drm blob cache.
> + *
> + * Return: A boolean indicating whether a change happened or not.
> + */
> +bool drm_check_edid_changed(struct drm_connector *connector,
> + struct i2c_adapter *adapter)
> +{
> + struct drm_property_blob *edid_blob;
> + struct edid *edid_stored;
> + struct edid *edid_read;
> + int ret = 0;
> +
> + if (!connector->edid_blob_ptr)
> + return false;
> +
> + edid_blob = drm_property_blob_get(connector->edid_blob_ptr);
> + if (!edid_blob)
> + return false;
> +
> + if (!edid_blob->data || edid_blob->length != sizeof(struct edid))
> + goto out;
> +
> + edid_stored = (struct edid *) edid_blob->data;
> +
> + edid_read = drm_get_edid(connector, adapter);
> + if (!edid_read)
> + goto out;
> +
> + ret = memcmp(edid_stored, edid_read, sizeof(struct edid));
> +
> + kfree(edid_read);
> +
> +out:
> + drm_property_blob_put(edid_blob);
> +
> + return ret != 0;
> +}
> +EXPORT_SYMBOL_GPL(drm_check_edid_changed);
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 1e1908a6b1d6..593a97b269c3 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -485,4 +485,7 @@ void drm_edid_get_monitor_name(struct edid *edid, char
> *name,
> struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
> int hsize, int vsize, int fresh,
> bool rb);
> +bool drm_check_edid_changed(struct drm_connector *connector,
> + struct i2c_adapter *adapter);
> +
> #endif /* __DRM_EDID_H__ */
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3] drm/hdcp: drm enum property for CP State
DRM connector property is created to represent the content protection
state of the connector and to configure the same.
Content protection states defined:
DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED - Unsupported
DRM_MODE_CONTENT_PROTECTION_DISABLE - Disabled
DRM_MODE_CONTENT_PROTECTION_ENABLE - Enabled
v2: Redesigned the property to match with CP needs of CrOS [Sean].
v3: Renamed the state names. Header is removed [sean].
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/drm_connector.c | 14 ++
include/drm/drm_mode_config.h | 5 +
include/uapi/drm/drm_mode.h | 5 +
3 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5cd61af..d6aaa08 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -617,6 +617,13 @@ static const struct drm_prop_enum_list
drm_link_status_enum_list[] = {
};
DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
+static const struct drm_prop_enum_list drm_cp_enum_list[] = {
+ { DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED, "Unsupported" },
+ { DRM_MODE_CONTENT_PROTECTION_DISABLE, "Disabled" },
+ { DRM_MODE_CONTENT_PROTECTION_ENABLE, "Enabled" },
+};
+DRM_ENUM_NAME_FN(drm_get_cp_status_name, drm_cp_enum_list)
+
/**
* drm_display_info_set_bus_formats - set the supported bus formats
* @info: display info to store bus formats in
@@ -789,6 +796,13 @@ int drm_connector_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.link_status_property = prop;
+ prop = drm_property_create_enum(dev, 0, "Content Protection",
+ drm_cp_enum_list,
+ ARRAY_SIZE(drm_cp_enum_list));
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cp_property = prop;
+
return 0;
}
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 4298171..7acb8b2 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -538,6 +538,11 @@ struct drm_mode_config {
*/
struct drm_property *link_status_property;
/**
+* @cp_property: Default connector property for CP
+* of a connector
+*/
+ struct drm_property *cp_property;
+ /**
* @plane_type_property: Default plane property to differentiate
* CURSOR, PRIMARY and OVERLAY legacy uses of planes.
*/
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 403339f..554a770 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -127,6 +127,11 @@ extern "C" {
#define DRM_MODE_LINK_STATUS_GOOD 0
#define DRM_MODE_LINK_STATUS_BAD 1
+/* Content Protection options */
+#define DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED0
+#define DRM_MODE_CONTENT_PROTECTION_DISABLE1
+#define DRM_MODE_CONTENT_PROTECTION_ENABLE 2
+
/*
* DRM_MODE_ROTATE_
*
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree
On Mon, Jul 24, 2017 at 10:24:41AM +0200, Daniel Vetter wrote: > On Mon, Jul 24, 2017 at 2:03 AM, Stephen Rothwell > wrote: > > Hi Daniel, > > > > On Fri, 21 Jul 2017 09:24:49 +0200 Daniel Vetter > > wrote: > >> > >> How are we going to handle this now? The refactor is deeply burried in > >> drm-misc, I guess you could cherry-pick the relevant patches over. But > >> that'll probably lead to more conflicts because git will get confused. > > > > I'll just keep applying the merge resolution patch and will remind Dave > > and Greg about it during the week before the merge window opens so that > > they can let Linus know that the fix up is needed. > > Well, Greg squeezed the vbox driver into -rc2, so now we already get > to resolve this in a backmerge. And hopefully the bikeshed patches in > -staging won't interfere too badly with whatever refactoring we'll do > in drm-next. > > Greg, fyi this is the last time I'll ack a drm driver for staging. > This just doesn't work. We're spending more time here working the > -staging vs. drm-next conflicts than the actual vbox driver review has > taken me. And probly less than the cleanup for merging directly to > drm-next will end up taking. Hey, I was amazed that you all acked it, and it's why I required that you do so before I took it :) Good luck with the merges! greg k-h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/20] drm/i915/selftest: Refactor reset locking
On 7/21/2017 5:32 AM, Chris Wilson wrote:
Extract the common barrier against rogue hangchecks from disrupting our
direct testing of resets, and in the process expand the lock to include
the per-engine reset shortcuts.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
I don't know how you trigger that, but
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 58 ++--
1 file changed, 43 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index dbfcb31ba9f4..3ece564e4d96 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -297,6 +297,37 @@ static int igt_hang_sanitycheck(void *arg)
return err;
}
+static void global_reset_lock(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ while (test_and_set_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags))
+ wait_event(i915->gpu_error.reset_queue,
+ !test_bit(I915_RESET_BACKOFF,
+&i915->gpu_error.flags));
+
+ for_each_engine(engine, i915, id) {
+ while (test_and_set_bit(I915_RESET_ENGINE + id,
+ &i915->gpu_error.flags))
+ wait_on_bit(&i915->gpu_error.flags,
+ I915_RESET_ENGINE + id,
+ TASK_UNINTERRUPTIBLE);
+ }
+}
+
+static void global_reset_unlock(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ for_each_engine(engine, i915, id)
+ clear_bit(I915_RESET_ENGINE + id, &i915->gpu_error.flags);
+
+ clear_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags);
+ wake_up_all(&i915->gpu_error.reset_queue);
+}
+
static int igt_global_reset(void *arg)
{
struct drm_i915_private *i915 = arg;
@@ -305,7 +336,7 @@ static int igt_global_reset(void *arg)
/* Check that we can issue a global GPU reset */
- set_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags);
+ global_reset_lock(i915);
set_bit(I915_RESET_HANDOFF, &i915->gpu_error.flags);
mutex_lock(&i915->drm.struct_mutex);
@@ -320,8 +351,7 @@ static int igt_global_reset(void *arg)
mutex_unlock(&i915->drm.struct_mutex);
GEM_BUG_ON(test_bit(I915_RESET_HANDOFF, &i915->gpu_error.flags));
- clear_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags);
- wake_up_all(&i915->gpu_error.reset_queue);
+ global_reset_unlock(i915);
if (i915_terminally_wedged(&i915->gpu_error))
err = -EIO;
@@ -572,7 +602,7 @@ static int igt_wait_reset(void *arg)
/* Check that we detect a stuck waiter and issue a reset */
- set_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags);
+ global_reset_lock(i915);
mutex_lock(&i915->drm.struct_mutex);
err = hang_init(&h, i915);
@@ -617,8 +647,7 @@ static int igt_wait_reset(void *arg)
hang_fini(&h);
unlock:
mutex_unlock(&i915->drm.struct_mutex);
- clear_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags);
- wake_up_all(&i915->gpu_error.reset_queue);
+ global_reset_unlock(i915);
if (i915_terminally_wedged(&i915->gpu_error))
return -EIO;
@@ -639,7 +668,8 @@ static int igt_reset_queue(void *arg)
if (!igt_can_mi_store_dword_imm(i915))
return 0;
- set_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags);
+ global_reset_lock(i915);
+
mutex_lock(&i915->drm.struct_mutex);
err = hang_init(&h, i915);
if (err)
@@ -733,8 +763,7 @@ static int igt_reset_queue(void *arg)
hang_fini(&h);
unlock:
mutex_unlock(&i915->drm.struct_mutex);
- clear_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags);
- wake_up_all(&i915->gpu_error.reset_queue);
+ global_reset_unlock(i915);
if (i915_terminally_wedged(&i915->gpu_error))
return -EIO;
@@ -756,7 +785,8 @@ static int igt_render_engine_reset_fallback(void *arg)
if (!intel_has_reset_engine(i915))
return 0;
- set_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags);
+ global_reset_lock(i915);
+
mutex_lock(&i915->drm.struct_mutex);
err = hang_init(&h, i915);
@@ -786,8 +816,7 @@ static int igt_render_engine_reset_fallback(void *arg)
/* unlock since we'll call handle_error */
mutex_unlock(&i915->drm.struct_mutex);
- clear_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags);
- wake_up_all(&i915->gpu_error.reset_queue);
+ global_reset_unlock(i915);
i915_handle_error(i915, intel_engine_flag(engine), "live test");
@@ -809,7 +838,7 @@ static int igt_render_engine_reset_fallback(void *arg)
* more full reset to re-enable the hw.
Re: [Intel-gfx] [PATCH 17/20] drm/i915/selftest: Refactor reset locking
Quoting Michel Thierry (2017-07-24 20:25:52) > On 7/21/2017 5:32 AM, Chris Wilson wrote: > > Extract the common barrier against rogue hangchecks from disrupting our > > direct testing of resets, and in the process expand the lock to include > > the per-engine reset shortcuts. > > > > Signed-off-by: Chris Wilson > > Cc: Mika Kuoppala > > Cc: Michel Thierry > > I don't know how you trigger that, but Unexplained bugs in hangcheck, it likes to fire for the active ring whilst we are running live_hangcheck -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/20] drm/i915: Don't touch fence->error when resetting an innocent request
On 7/24/2017 6:32 AM, Chris Wilson wrote:
Quoting Chris Wilson (2017-07-21 13:32:33)
If the request has been completed before the reset took effect, we don't
need to mark it up as being a victim. Touching fence->error after the
fence has been signaled is detected by dma_fence_set_error() and
triggers a BUG:
[ 231.743133] kernel BUG at ./include/linux/dma-fence.h:434!
[ 231.743156] invalid opcode: [#1] SMP KASAN
[ 231.743172] Modules linked in: i915 drm_kms_helper drm iptable_nat
nf_nat_ipv4 nf_nat x86_pkg_temp_thermal iosf_mbi i2c_algo_bit cfbfillrect
syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea fb font
fbdev [last unloaded: drm]
[ 231.743221] CPU: 2 PID: 20 Comm: kworker/2:0 Tainted: G U
4.13.0-rc1+ #52
[ 231.743236] Hardware name: Hewlett-Packard HP EliteBook 8460p/161C, BIOS
68SCF Ver. F.01 03/11/2011
[ 231.743363] Workqueue: events_long i915_hangcheck_elapsed [i915]
[ 231.743382] task: 8801f42e9780 task.stack: 8801f42f8000
[ 231.743489] RIP: 0010:i915_gem_reset_engine+0x45a/0x460 [i915]
[ 231.743505] RSP: 0018:8801f42ff770 EFLAGS: 00010202
[ 231.743521] RAX: 0007 RBX: 8801bf6b1880 RCX: a02881a6
[ 231.743537] RDX: dc00 RSI: dc00 RDI: 8801bf6b18c8
[ 231.743551] RBP: 8801f42ff7c8 R08: 0001 R09:
[ 231.743566] R10: R11: R12: 8801edb02d00
[ 231.743581] R13: 8801e19d4200 R14: 001d R15: 8801ce2a4000
[ 231.743599] FS: () GS:8801f5a8()
knlGS:
[ 231.743614] CS: 0010 DS: ES: CR0: 80050033
[ 231.743629] CR2: 7f0ebd1add10 CR3: 02621000 CR4: 000406e0
[ 231.743643] Call Trace:
[ 231.743752] i915_gem_reset+0x6c/0x150 [i915]
[ 231.743853] i915_reset+0x175/0x210 [i915]
[ 231.743958] i915_reset_device+0x33b/0x350 [i915]
[ 231.744061] ? valleyview_pipestat_irq_handler+0xe0/0xe0 [i915]
[ 231.744081] ? trace_hardirqs_off_caller+0x70/0x110
[ 231.744102] ? _raw_spin_unlock_irqrestore+0x46/0x50
[ 231.744120] ? find_held_lock+0x119/0x150
[ 231.744138] ? mark_lock+0x6d/0x850
[ 231.744241] ? gen8_gt_irq_ack+0x1f0/0x1f0 [i915]
[ 231.744262] ? work_on_cpu_safe+0x60/0x60
[ 231.744284] ? rcu_read_lock_sched_held+0x57/0xa0
[ 231.744400] ? gen6_read32+0x2ba/0x320 [i915]
[ 231.744506] i915_handle_error+0x382/0x5f0 [i915]
[ 231.744611] ? gen6_rps_reset_ei+0x20/0x20 [i915]
[ 231.744630] ? vsnprintf+0x128/0x8e0
[ 231.744649] ? pointer+0x6b0/0x6b0
[ 231.744667] ? debug_check_no_locks_freed+0x1a0/0x1a0
[ 231.744688] ? scnprintf+0x92/0xe0
[ 231.744706] ? snprintf+0xb0/0xb0
[ 231.744820] hangcheck_declare_hang+0x15a/0x1a0 [i915]
[ 231.744932] ? engine_stuck+0x440/0x440 [i915]
[ 231.744951] ? rcu_read_lock_sched_held+0x57/0xa0
[ 231.745062] ? gen6_read32+0x2ba/0x320 [i915]
[ 231.745173] ? gen6_read16+0x320/0x320 [i915]
[ 231.745284] ? intel_engine_get_active_head+0x91/0x170 [i915]
[ 231.745401] i915_hangcheck_elapsed+0x3d8/0x400 [i915]
[ 231.745424] process_one_work+0x3e8/0xac0
[ 231.745444] ? pwq_dec_nr_in_flight+0x110/0x110
[ 231.745464] ? do_raw_spin_lock+0x8e/0x120
[ 231.745484] worker_thread+0x8d/0x720
[ 231.745506] kthread+0x19e/0x1f0
[ 231.745524] ? process_one_work+0xac0/0xac0
[ 231.745541] ? kthread_create_on_node+0xa0/0xa0
[ 231.745560] ret_from_fork+0x27/0x40
[ 231.745581] Code: 8b 7d c8 e8 49 0d 02 e1 49 8b 7f 38 48 8b 75 b8 48 83 c7 10 e8
b8 89 be e1 e9 95 fc ff ff 4c 89 e7 e8 4b b9 ff ff e9 30 ff ff ff <0f> 0b 0f 1f
40 00 55 48 89 e5 41 57 41 56 41 55 41 54 49 89 fe
[ 231.745767] RIP: i915_gem_reset_engine+0x45a/0x460 [i915] RSP:
8801f42ff770
At first glance this looks to be related to commit c64992e035d7
("drm/i915: Look for active requests earlier in the reset path"), but it
could easily happen before as well. On the other hand, we no longer
logged victims due to the active_request being dropped earlier.
v2: Be trickier to unwind the incomplete request as we cannot rely on
request retirement for the lockless per-engine reset.
v3: Reprobe the active request at the time of the reset.
Reported-by: Daniel Vetter
Fixes: c64992e035d7 ("drm/i915: Look for active requests earlier in the reset
path")
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Mika Kuoppala
Cc: Daniel Vetter
Reviewed-by: Joonas Lahtinen #v1
-Chris
and v3 is
Reviewed-by: Michel Thierry
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/20] drm/i915: Squelch reset messages during selftests
On 7/21/2017 5:32 AM, Chris Wilson wrote:
During our selftests, we try reseting the GPU tens of thousands of
times, flooding the dmesg with out reset spam drowning out any potential
warnings. Add an option to i915_reset()/i915_reset_engine() to specify a
quiet reset for selftesting.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 48 +---
drivers/gpu/drm/i915/i915_drv.h | 8 +++-
drivers/gpu/drm/i915/i915_gem_request.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 4 +-
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 8 ++--
5 files changed, 39 insertions(+), 31 deletions(-)
...
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5244fb16fa55..469f854dd395 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2624,7 +2624,7 @@ static void i915_reset_device(struct drm_i915_private
*dev_priv)
*/
do {
if (mutex_trylock(&dev_priv->drm.struct_mutex)) {
- i915_reset(dev_priv);
+ i915_reset(dev_priv, 0);
I guess adding a wrapper to make flags=0 the default it's an overkill,
plus I see the benefit of not flooding dmesg.
Reviewed-by: Michel Thierry
mutex_unlock(&dev_priv->drm.struct_mutex);
}
} while (wait_on_bit_timeout(&dev_priv->gpu_error.flags,
@@ -2739,7 +2739,7 @@ void i915_handle_error(struct drm_i915_private *dev_priv,
&dev_priv->gpu_error.flags))
continue;
- if (i915_reset_engine(engine) == 0)
+ if (i915_reset_engine(engine, 0) == 0)
engine_mask &= ~intel_engine_flag(engine);
clear_bit(I915_RESET_ENGINE + engine->id,
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index e83503db3b66..4129d01b67a1 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -342,7 +342,7 @@ static int igt_global_reset(void *arg)
mutex_lock(&i915->drm.struct_mutex);
reset_count = i915_reset_count(&i915->gpu_error);
- i915_reset(i915);
+ i915_reset(i915, I915_RESET_QUIET);
if (i915_reset_count(&i915->gpu_error) == reset_count) {
pr_err("No GPU reset recorded!\n");
@@ -378,7 +378,7 @@ static int igt_reset_engine(void *arg)
reset_engine_count = i915_reset_engine_count(&i915->gpu_error,
engine);
- err = i915_reset_engine(engine);
+ err = i915_reset_engine(engine, I915_RESET_QUIET);
if (err) {
pr_err("i915_reset_engine failed\n");
break;
@@ -512,7 +512,7 @@ static int igt_reset_active_engines(void *arg)
set_bit(I915_RESET_ENGINE + engine->id, &i915->gpu_error.flags);
do {
- err = i915_reset_engine(engine);
+ err = i915_reset_engine(engine, I915_RESET_QUIET);
if (err) {
pr_err("i915_reset_engine(%s) failed, err=%d\n",
engine->name, err);
@@ -716,7 +716,7 @@ static int igt_reset_queue(void *arg)
reset_count = fake_hangcheck(prev);
- i915_reset(i915);
+ i915_reset(i915, I915_RESET_QUIET);
GEM_BUG_ON(test_bit(I915_RESET_HANDOFF,
&i915->gpu_error.flags));
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use AUX for backlight only if eDP 1.4 or later
I saw a DP 1.3 panel that advertise AUX backlight brightness control
but not working properly. So it should work but not in real world.
I think that is good reason enough to add this as a heuristic.
On Thu, Jul 20, 2017 at 1:27 PM, Pandiyan, Dhinakaran
wrote:
>
>
>
> On Thu, 2017-07-20 at 10:06 +, Tc, Jenny wrote:
>> > >> With older panels, AUX pin for backlight doesn't work.
>> >
>> > What evidence do you have to back up that claim?
>>
>> Debugging further it's found that the panel I am having doesn't support AUX
>> Backlight.
>>
>> cat /sys/kernel/debug/dri/0/eDP-1/i915_dpcd
>> ...
>> 0701: bb ff 00 00
>>
>>
>> With below change its working for my panel. But doesn't address issue
>> reported in
>> https://bugs.freedesktop.org/show_bug.cgi?id=101619 which seems to have a
>> wrong DPCD data.
>> Since we don't have a proper fix for all panels, I agree for revert.
>>
>> intel_dp_aux_display_control_heuristic(struct intel_connector *connector)
>> struct intel_dp *intel_dp =
>> enc_to_intel_dp(&connector->encoder->base);
>> uint8_t reg_val;
>>
>> + /* Panel dosn't support enabling AUX Backlight control */
>> + if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP)) {
>> + return false;
>> + }
>
> AUX backlight brightness control should work even without AUX enable
> capability.
>
>
>> /* Panel doesn't support adjusting backlight brightness via PWN pin
>> */
>> if (!(intel_dp->edp_dpcd[2] &
>> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
>> return true;
>>
>> > >> On some panels, this causes backlight issues on S3 resume.
>> > >
>> > > What is it that we are missing in the resume path?
>> > >
>> > >> Enable the
>> > >> feature only for eDP1.4 or later.
>> > >
>> > > I can't find the eDP 1.4 requirement in the spec. Regional brightness
>> > > control was added in eDP 1.4, but we don't enable that. My concern is
>> > > we might be missing a real fix by ignoring < eDP 1.4 panels.
>> >
>> > Agreed.
>> >
>> > This has been going on too long now, with no real effort to get at the
>> > roots of
>> > the problem. The right approach is to revert the regressing commits now,
>> > and start over. Reverts posted [1].
>> >
>> > BR,
>> > Jani.
>> >
>> > [1] https://patchwork.freedesktop.org/series/27623/
>> >
>> > >
>> > >
>> > >>
>> > >> Fix-suggested-by: Puthikorn Voravootivat
>> > >
>> > > 1. Please use the "Fixes" tag to refer to the commit that introduced
>> > > the code you are fixing.
>> > > 2. The "Suggested-by" tag is more common to give credits to the person
>> > > who suggested the fix.
>> > > 3. Please use the "Bugzilla" tag to point to the bug that David
>> > > reported.
>> > >
>> > >
>> > >> Signed-off-by: Jenny TC
>> > >> ---
>> > >> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 6 +-
>> > >> 1 file changed, 5 insertions(+), 1 deletion(-)
>> > >>
>> > >> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> > >> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> > >> index b25cd88..421f31f 100644
>> > >> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> > >> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> > >> @@ -292,7 +292,7 @@ static int intel_dp_aux_setup_backlight(struct
>> > intel_connector *connector,
>> > >> * via PWM pin or using AUX is better than using PWM pin.
>> > >> *
>> > >> * The heuristic to determine that using AUX pin is better than
>> > >> using PWM pin is
>> > >> - * that the panel support any of the feature list here.
>> > >> + * that the panel is eDP 1.4 or later and support any of the feature
>> > >> + list here
>> > >> * - Regional backlight brightness adjustment
>> > >> * - Backlight PWM frequency set
>> > >> * - More than 8 bits resolution of brightness level @@ -310,6
>> > >> +310,10 @@ static int intel_dp_aux_setup_backlight(struct
>> > intel_connector *connector,
>> > >> if (!(intel_dp->edp_dpcd[2] &
>> > DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
>> > >> return true;
>> > >>
>> > >> +/* Enable this for eDP 1.4 panel or later. */
>> > >> +if (intel_dp->edp_dpcd[0] < DP_EDP_14)
>> > >> +return false;
>> > >> +
>> > >> /* Panel supports regional backlight brightness adjustment */
>> > >> if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_GENERAL_CAP_3,
>> > >>®_val) != 1) {
>> >
>> > --
>> > Jani Nikula, Intel Open Source Technology Center
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Add support for CCS modifiers
Hi Ben,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.13-rc2 next-20170724]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Ben-Widawsky/drm-Plumb-modifiers-through-plane-init/20170725-062539
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/intel_display.c:105:2: error:
>> 'I915_FORMAT_MOD_Yf_TILED_CCS' undeclared here (not in a function)
I915_FORMAT_MOD_Yf_TILED_CCS,
^~~~
>> drivers/gpu/drm/i915/intel_display.c:106:2: error:
>> 'I915_FORMAT_MOD_Y_TILED_CCS' undeclared here (not in a function)
I915_FORMAT_MOD_Y_TILED_CCS,
^~~
drivers/gpu/drm/i915/intel_display.c: In function 'skl_mod_supported':
>> drivers/gpu/drm/i915/intel_display.c:13642:16: warning: comparison between
>> pointer and integer
if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
^~
drivers/gpu/drm/i915/intel_display.c:13643:16: warning: comparison between
pointer and integer
modifier == I915_FORMAT_MOD_Y_TILED_CCS)
^~
--
>> drivers/gpu/drm/i915/intel_sprite.c:1092:2: error:
>> 'I915_FORMAT_MOD_Yf_TILED_CCS' undeclared here (not in a function)
I915_FORMAT_MOD_Yf_TILED_CCS,
^~~~
>> drivers/gpu/drm/i915/intel_sprite.c:1093:2: error:
>> 'I915_FORMAT_MOD_Y_TILED_CCS' undeclared here (not in a function)
I915_FORMAT_MOD_Y_TILED_CCS,
^~~
vim +/I915_FORMAT_MOD_Yf_TILED_CCS +105 drivers/gpu/drm/i915/intel_display.c
103
104 static const uint64_t skl_format_modifiers_ccs[] = {
> 105 I915_FORMAT_MOD_Yf_TILED_CCS,
> 106 I915_FORMAT_MOD_Y_TILED_CCS,
107 I915_FORMAT_MOD_Yf_TILED,
108 I915_FORMAT_MOD_Y_TILED,
109 I915_FORMAT_MOD_X_TILED,
110 DRM_FORMAT_MOD_LINEAR,
111 DRM_FORMAT_MOD_INVALID
112 };
113
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 01/14] RFC drm/i915: Expose a PMU interface for perf queries
On 17-07-18 15:36:05, Tvrtko Ursulin wrote:
From: Chris Wilson
The first goal is to be able to measure GPU (and invidual ring) busyness
without having to poll registers from userspace. (Which not only incurs
holding the forcewake lock indefinitely, perturbing the system, but also
runs the risk of hanging the machine.) As an alternative we can use the
perf event counter interface to sample the ring registers periodically
and send those results to userspace.
To be able to do so, we need to export the two symbols from
kernel/events/core.c to register and unregister a PMU device.
v2: Use a common timer for the ring sampling.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 23 ++
drivers/gpu/drm/i915/i915_pmu.c | 452
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +
include/uapi/drm/i915_drm.h | 41 +++
kernel/events/core.c| 1 +
7 files changed, 522 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_pmu.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f8227318dcaf..1c720013dc42 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -26,6 +26,7 @@ i915-y := i915_drv.o \
i915-$(CONFIG_COMPAT) += i915_ioc32.o
i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
+i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
# GEM code
i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..f18ce519f6a2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1194,6 +1194,7 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
struct drm_device *dev = &dev_priv->drm;
i915_gem_shrinker_init(dev_priv);
+ i915_pmu_register(dev_priv);
/*
* Notify a valid surface after modesetting,
@@ -1247,6 +1248,7 @@ static void i915_driver_unregister(struct
drm_i915_private *dev_priv)
intel_opregion_unregister(dev_priv);
i915_perf_unregister(dev_priv);
+ i915_pmu_unregister(dev_priv);
i915_teardown_sysfs(dev_priv);
i915_guc_log_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7c6fab08a2e6..de518503e033 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2093,6 +2094,12 @@ struct intel_cdclk_state {
unsigned int cdclk, vco, ref;
};
+enum {
+ __I915_SAMPLE_FREQ_ACT = 0,
+ __I915_SAMPLE_FREQ_REQ,
+ __I915_NUM_PMU_SAMPLERS
+};
+
struct drm_i915_private {
struct drm_device drm;
@@ -2591,6 +2598,13 @@ struct drm_i915_private {
int irq;
} lpe_audio;
+ struct {
+ struct pmu base;
+ struct hrtimer timer;
+ u64 enable;
+ u64 sample[__I915_NUM_PMU_SAMPLERS];
+ } pmu;
+
/*
* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
* will be rejected. Instead look for a better place.
@@ -3760,6 +3774,15 @@ extern void i915_perf_fini(struct drm_i915_private
*dev_priv);
extern void i915_perf_register(struct drm_i915_private *dev_priv);
extern void i915_perf_unregister(struct drm_i915_private *dev_priv);
+/* i915_pmu.c */
+#ifdef CONFIG_PERF_EVENTS
+extern void i915_pmu_register(struct drm_i915_private *i915);
+extern void i915_pmu_unregister(struct drm_i915_private *i915);
+#else
+static inline void i915_pmu_register(struct drm_i915_private *i915) {}
+static inline void i915_pmu_unregister(struct drm_i915_private *i915) {}
+#endif
+
/* i915_suspend.c */
extern int i915_save_state(struct drm_i915_private *dev_priv);
extern int i915_restore_state(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
new file mode 100644
index ..f03ddad44da6
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -0,0 +1,452 @@
+#include
+#include
+
+#include "i915_drv.h"
+#include "intel_ringbuffer.h"
+
+#define FREQUENCY 200
+#define PERIOD max_t(u64, 1, NSEC_PER_SEC / FREQUENCY)
+
+#define RING_MASK 0x
+#define RING_MAX 32
+
+static void engines_sample(struct drm_i915_private *dev_priv)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ bool fw = false;
+
+ if ((dev_priv->pmu.enable & RING_MASK) == 0)
+ return;
+
+ if (!dev_priv->gt.awake)
+ return;
+
+ if (!intel_runtime_pm_get_if_in_use(dev_priv))
+ return;
+
+ for_each_engine(engine, dev_priv, id) {
+ u32 val;
+
+ if ((dev_priv->pmu.enable & (0x7 << (4*id))) == 0)
+ continue;
+
Re: [Intel-gfx] [RFC 04/14] drm/i915/pmu: Decouple uAPI engine ids
On 17-07-18 15:36:08, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As elsewhere in the code we have to decouple the binary
engine identifiers for easier maintenance.
Also the sampler mask was incorrect in the timer callback.
I don't quite understand the point of this patch... can you perhaps embellish
the commit message?
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pmu.c | 44 -
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index f03ddad44da6..9a8208dba7a9 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -10,6 +10,25 @@
#define RING_MASK 0x
#define RING_MAX 32
+#define ENGINE_SAMPLE_MASK (0xf)
+#define ENGINE_SAMPLE_BITS (4)
+
+static const unsigned int engine_map[I915_NUM_ENGINES] = {
+ [RCS] = I915_SAMPLE_RCS,
+ [BCS] = I915_SAMPLE_BCS,
+ [VCS] = I915_SAMPLE_VCS,
+ [VCS2] = I915_SAMPLE_VCS2,
+ [VECS] = I915_SAMPLE_VECS,
+};
+
+static const unsigned int user_engine_map[I915_NUM_ENGINES] = {
+ [I915_SAMPLE_RCS] = RCS,
+ [I915_SAMPLE_BCS] = BCS,
+ [I915_SAMPLE_VCS] = VCS,
+ [I915_SAMPLE_VCS2] = VCS2,
+ [I915_SAMPLE_VECS] = VECS,
+};
+
static void engines_sample(struct drm_i915_private *dev_priv)
{
struct intel_engine_cs *engine;
@@ -26,9 +45,16 @@ static void engines_sample(struct drm_i915_private *dev_priv)
return;
for_each_engine(engine, dev_priv, id) {
+ unsigned int user_engine = engine_map[id];
u32 val;
- if ((dev_priv->pmu.enable & (0x7 << (4*id))) == 0)
+ if (WARN_ON_ONCE(id >= ARRAY_SIZE(engine_map)))
+ continue;
+ else
+ user_engine = engine_map[id];
+
+ if (!(dev_priv->pmu.enable &
+ (ENGINE_SAMPLE_MASK << (ENGINE_SAMPLE_BITS * user_engine
continue;
if (i915_seqno_passed(intel_engine_get_seqno(engine),
@@ -112,6 +138,11 @@ static int engine_event_init(struct perf_event *event)
int engine = event->attr.config >> 2;
int sample = event->attr.config & 3;
+ if (WARN_ON_ONCE(engine >= ARRAY_SIZE(user_engine_map)))
+ return -ENOENT;
+ else
+ engine = user_engine_map[engine];
+
switch (sample) {
case I915_SAMPLE_QUEUED:
case I915_SAMPLE_BUSY:
@@ -125,9 +156,6 @@ static int engine_event_init(struct perf_event *event)
return -ENOENT;
}
- if (engine >= I915_NUM_ENGINES)
- return -ENOENT;
-
if (!i915->engine[engine])
return -ENODEV;
@@ -369,7 +397,13 @@ static void i915_pmu_event_read(struct perf_event *event)
if (event->attr.config < 32) {
int engine = event->attr.config >> 2;
int sample = event->attr.config & 3;
- val = i915->engine[engine]->pmu_sample[sample];
+
+ if (WARN_ON_ONCE(engine >= ARRAY_SIZE(user_engine_map))) {
+ /* Do nothing */
+ } else {
+ engine = user_engine_map[engine];
+ val = i915->engine[engine]->pmu_sample[sample];
+ }
} else switch (event->attr.config) {
case I915_PMU_ACTUAL_FREQUENCY:
val = i915->pmu.sample[__I915_SAMPLE_FREQ_ACT];
--
2.9.4
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 07/14] drm/i915/pmu: Add fake regs
On 17-07-18 15:36:11, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Without this I can get a null ptr deref when trying to access
our events with perf.
Signed-off-by: Tvrtko Ursulin
This definitely seems unsafe, but should be squashed in somewhere earlier...
---
drivers/gpu/drm/i915/i915_pmu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 4d61a1e72ee6..4195d89b1c82 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -183,8 +183,11 @@ static int engine_event_init(struct perf_event *event)
return 0;
}
+static DEFINE_PER_CPU(struct pt_regs, i915_pmu_pt_regs);
+
static enum hrtimer_restart hrtimer_sample(struct hrtimer *hrtimer)
{
+ struct pt_regs *regs = this_cpu_ptr(&i915_pmu_pt_regs);
struct perf_sample_data data;
struct perf_event *event;
u64 period;
@@ -196,7 +199,7 @@ static enum hrtimer_restart hrtimer_sample(struct hrtimer
*hrtimer)
event->pmu->read(event);
perf_sample_data_init(&data, 0, event->hw.last_period);
- perf_event_overflow(event, &data, NULL);
+ perf_event_overflow(event, &data, regs);
period = max_t(u64, 1, event->hw.sample_period);
hrtimer_forward_now(hrtimer, ns_to_ktime(period));
--
2.9.4
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 12/14] drm/i915: Interface for controling engine stats collection
On 17-07-19 10:34:14, Tvrtko Ursulin wrote:
Hi Ben,
On 18/07/2017 15:36, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Enables other i915 components to enable and disable
the facility as needed.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 53 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 5
2 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 3e5e08c6b5ef..03e7459bad06 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -29,6 +29,8 @@
#include "intel_lrc.h"
DEFINE_STATIC_KEY_FALSE(i915_engine_stats_key);
+static DEFINE_MUTEX(i915_engine_stats_mutex);
+static int i915_engine_stats_ref;
/* Haswell does have the CXT_SIZE register however it does not appear to be
* valid. Now, docs explain in dwords what is in the context object. The full
@@ -1340,6 +1342,57 @@ void intel_engines_mark_idle(struct drm_i915_private
*i915)
}
}
+int intel_enable_engine_stats(struct drm_i915_private *dev_priv)
+{
+ if (!i915.enable_execlists)
+ return -ENODEV;
+
+ mutex_lock(&i915_engine_stats_mutex);
+ if (i915_engine_stats_ref++ == 0) {
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ for_each_engine(engine, dev_priv, id) {
+ memset(&engine->stats, 0, sizeof(engine->stats));
+ spin_lock_init(&engine->stats.lock);
+ }
+
+ static_branch_enable(&i915_engine_stats_key);
+ }
+ mutex_unlock(&i915_engine_stats_mutex);
+
+ return 0;
+}
+
+void intel_disable_engine_stats(void)
+{
+ mutex_lock(&i915_engine_stats_mutex);
+ if (--i915_engine_stats_ref == 0)
+ static_branch_disable(&i915_engine_stats_key);
+ mutex_unlock(&i915_engine_stats_mutex);
+}
+
+u64 intel_engine_get_current_busy_ns(struct intel_engine_cs *engine)
+{
+ unsigned long flags;
+ u64 total;
+
+ spin_lock_irqsave(&engine->stats.lock, flags);
+
+ total = engine->stats.total;
+
+ /*
+* If the engine is executing something at the moment
+* add it to the total.
+*/
+ if (engine->stats.ref)
+ total += ktime_get_real_ns() - engine->stats.start;
+
+ spin_unlock_irqrestore(&engine->stats.lock, flags);
+
+ return total;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/mock_engine.c"
#endif
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 2eb1e970ad06..e0f495a6d0d9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -776,4 +776,9 @@ static inline void intel_engine_context_out(struct
intel_engine_cs *engine)
}
}
+int intel_enable_engine_stats(struct drm_i915_private *i915);
+void intel_disable_engine_stats(void);
+
+u64 intel_engine_get_current_busy_ns(struct intel_engine_cs *engine);
If we exported these symbols for other modules to use, what kind of
API would they need? Presumably not per-engine but something to give
the aggregated busyness of all engines? Or I have misunderstood you
that there is this requirement?
Regards,
Tvrtko
No misunderstanding. For our current usage, busyness of all engines would be
easiest. If one of the engines doesn't contribute much to the total TDP though,
it wouldn't need to actually be included, so we could perhaps leave room for
per-engine.
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm: Plumb modifiers through plane init
Hi Ben, [auto build test WARNING on drm/drm-next] [also build test WARNING on v4.13-rc2 next-20170724] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ben-Widawsky/drm-Plumb-modifiers-through-plane-init/20170725-062539 base: git://people.freedesktop.org/~airlied/linux.git drm-next reproduce: make htmldocs All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) arch/x86/include/asm/uaccess_32.h:1: warning: no structured comments found include/linux/init.h:1: warning: no structured comments found include/linux/mod_devicetable.h:687: warning: Excess struct/union/enum/typedef member 'ver_major' description in 'fsl_mc_device_id' include/linux/mod_devicetable.h:687: warning: Excess struct/union/enum/typedef member 'ver_minor' description in 'fsl_mc_device_id' kernel/sched/core.c:2088: warning: No description found for parameter 'rf' kernel/sched/core.c:2088: warning: Excess function parameter 'cookie' description in 'try_to_wake_up_local' include/linux/kthread.h:26: warning: Excess function parameter '...' description in 'kthread_create' kernel/sys.c:1: warning: no structured comments found include/linux/device.h:969: warning: No description found for parameter 'dma_ops' drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found include/linux/iio/iio.h:597: warning: No description found for parameter 'trig_readonly' include/linux/iio/trigger.h:151: warning: No description found for parameter 'indio_dev' include/linux/iio/trigger.h:151: warning: No description found for parameter 'trig' include/linux/device.h:970: warning: No description found for parameter 'dma_ops' include/linux/usb/gadget.h:230: warning: No description found for parameter 'claimed' include/linux/usb/gadget.h:230: warning: No description found for parameter 'enabled' include/linux/usb/gadget.h:408: warning: No description found for parameter 'quirk_altset_not_supp' include/linux/usb/gadget.h:408: warning: No description found for parameter 'quirk_stall_not_supp' include/linux/usb/gadget.h:408: warning: No description found for parameter 'quirk_zlp_not_supp' include/drm/drm_drv.h:537: warning: No description found for parameter 'set_busid' include/drm/drm_drv.h:537: warning: No description found for parameter 'debugfs_init' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_open_object' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_close_object' include/drm/drm_drv.h:537: warning: No description found for parameter 'prime_handle_to_fd' include/drm/drm_drv.h:537: warning: No description found for parameter 'prime_fd_to_handle' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_export' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_import' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_pin' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_unpin' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_res_obj' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_get_sg_table' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_import_sg_table' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_vmap' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_vunmap' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_mmap' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_vm_ops' include/drm/drm_drv.h:537: warning: No description found for parameter 'major' include/drm/drm_drv.h:537: warning: No description found for parameter 'minor' include/drm/drm_drv.h:537: warning: No description found for parameter 'patchlevel' include/drm/drm_drv.h:537: warning: No description found for parameter 'name' include/drm/drm_drv.h:537: warning: No description found for parameter 'desc' include/drm/drm_drv.h:537: warning: No description found for parameter 'date' include/drm/drm_drv.h:537: warning: No description found for parameter 'driver_features' include/drm/drm_drv.h:537: warning:
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Add perf property support for context HW id
On 2017.07.21 14:01:01 +0100, Lionel Landwerlin wrote: > I think Chris' comments show this isn't actually tested. It turned out that's true...so currently Pengyuan just tried to filter by exposed vGPU ctx_hw_id with global mode in gputop. Would that be ok with you? If yes, then we don't need i915 perf change. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm: Create a format/modifier blob
Hi Ben, [auto build test WARNING on drm/drm-next] [also build test WARNING on v4.13-rc2 next-20170724] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ben-Widawsky/drm-Plumb-modifiers-through-plane-init/20170725-062539 base: git://people.freedesktop.org/~airlied/linux.git drm-next reproduce: make htmldocs All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) arch/x86/include/asm/uaccess_32.h:1: warning: no structured comments found include/linux/init.h:1: warning: no structured comments found include/linux/mod_devicetable.h:687: warning: Excess struct/union/enum/typedef member 'ver_major' description in 'fsl_mc_device_id' include/linux/mod_devicetable.h:687: warning: Excess struct/union/enum/typedef member 'ver_minor' description in 'fsl_mc_device_id' kernel/sched/core.c:2088: warning: No description found for parameter 'rf' kernel/sched/core.c:2088: warning: Excess function parameter 'cookie' description in 'try_to_wake_up_local' include/linux/kthread.h:26: warning: Excess function parameter '...' description in 'kthread_create' kernel/sys.c:1: warning: no structured comments found include/linux/device.h:969: warning: No description found for parameter 'dma_ops' drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found include/linux/iio/iio.h:597: warning: No description found for parameter 'trig_readonly' include/linux/iio/trigger.h:151: warning: No description found for parameter 'indio_dev' include/linux/iio/trigger.h:151: warning: No description found for parameter 'trig' include/linux/device.h:970: warning: No description found for parameter 'dma_ops' include/linux/usb/gadget.h:230: warning: No description found for parameter 'claimed' include/linux/usb/gadget.h:230: warning: No description found for parameter 'enabled' include/linux/usb/gadget.h:408: warning: No description found for parameter 'quirk_altset_not_supp' include/linux/usb/gadget.h:408: warning: No description found for parameter 'quirk_stall_not_supp' include/linux/usb/gadget.h:408: warning: No description found for parameter 'quirk_zlp_not_supp' include/drm/drm_drv.h:537: warning: No description found for parameter 'set_busid' include/drm/drm_drv.h:537: warning: No description found for parameter 'debugfs_init' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_open_object' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_close_object' include/drm/drm_drv.h:537: warning: No description found for parameter 'prime_handle_to_fd' include/drm/drm_drv.h:537: warning: No description found for parameter 'prime_fd_to_handle' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_export' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_import' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_pin' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_unpin' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_res_obj' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_get_sg_table' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_import_sg_table' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_vmap' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_vunmap' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_prime_mmap' include/drm/drm_drv.h:537: warning: No description found for parameter 'gem_vm_ops' include/drm/drm_drv.h:537: warning: No description found for parameter 'major' include/drm/drm_drv.h:537: warning: No description found for parameter 'minor' include/drm/drm_drv.h:537: warning: No description found for parameter 'patchlevel' include/drm/drm_drv.h:537: warning: No description found for parameter 'name' include/drm/drm_drv.h:537: warning: No description found for parameter 'desc' include/drm/drm_drv.h:537: warning: No description found for parameter 'date' include/drm/drm_drv.h:537: warning: No description found for parameter 'driver_features' include/drm/drm_drv.h:537: warning:
Re: [Intel-gfx] [PATCH 1/4] drm: Plumb modifiers through plane init
Hi Ben,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.13-rc2 next-20170724]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Ben-Widawsky/drm-Plumb-modifiers-through-plane-init/20170725-062539
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
drivers/gpu/drm/sun4i/sun8i_layer.c: In function 'sun8i_layer_init_one':
>> drivers/gpu/drm/sun4i/sun8i_layer.c:93:12: error: incompatible type for
>> argument 7 of 'drm_universal_plane_init'
plane->type, NULL);
^
In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu/drm/sun4i/sun8i_layer.c:16:
include/drm/drm_plane.h:550:5: note: expected 'const uint64_t * {aka const
long long unsigned int *}' but argument is of type 'const enum drm_plane_type'
int drm_universal_plane_init(struct drm_device *dev,
^~~~
In file included from include/uapi/linux/posix_types.h:4:0,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/mod_devicetable.h:11,
from include/linux/i2c.h:29,
from include/drm/drm_crtc.h:28,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu/drm/sun4i/sun8i_layer.c:16:
>> include/linux/stddef.h:7:14: error: incompatible type for argument 8 of
>> 'drm_universal_plane_init'
#define NULL ((void *)0)
^
>> drivers/gpu/drm/sun4i/sun8i_layer.c:93:25: note: in expansion of macro 'NULL'
plane->type, NULL);
^~~~
In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu/drm/sun4i/sun8i_layer.c:16:
include/drm/drm_plane.h:550:5: note: expected 'enum drm_plane_type' but
argument is of type 'void *'
int drm_universal_plane_init(struct drm_device *dev,
^~~~
>> drivers/gpu/drm/sun4i/sun8i_layer.c:90:8: error: too few arguments to
>> function 'drm_universal_plane_init'
ret = drm_universal_plane_init(drm, &layer->plane, 0,
^~~~
In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu/drm/sun4i/sun8i_layer.c:16:
include/drm/drm_plane.h:550:5: note: declared here
int drm_universal_plane_init(struct drm_device *dev,
^~~~
--
drivers/gpu//drm/sun4i/sun8i_layer.c: In function 'sun8i_layer_init_one':
drivers/gpu//drm/sun4i/sun8i_layer.c:93:12: error: incompatible type for
argument 7 of 'drm_universal_plane_init'
plane->type, NULL);
^
In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu//drm/sun4i/sun8i_layer.c:16:
include/drm/drm_plane.h:550:5: note: expected 'const uint64_t * {aka const
long long unsigned int *}' but argument is of type 'const enum drm_plane_type'
int drm_universal_plane_init(struct drm_device *dev,
^~~~
In file included from include/uapi/linux/posix_types.h:4:0,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/mod_devicetable.h:11,
from include/linux/i2c.h:29,
from include/drm/drm_crtc.h:28,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu//drm/sun4i/sun8i_layer.c:16:
>> include/linux/stddef.h:7:14: error: incompatible type for argument 8 of
>> 'drm_universal_plane_init'
#define NULL ((void *)0)
^
drivers/gpu//drm/sun4i/sun8i_layer.c:93:25: note: in expansion of macro
'NULL'
plane->type, NULL);
^~~~
In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu//drm/sun4i/sun8i_layer.c:16:
include
Re: [Intel-gfx] [PATCH 1/2] drm/edid: Add helper to detect whether EDID changed
On Mon, Jul 24, 2017 at 05:54:46PM +0300, Paul Kocialkowski wrote:
> This adds a common drm helper to detect whether the EDID changed from
> the last known cached one. This is useful help detect that a monitor was
> changed during a suspend/resume cycle.
>
> When that happens (a monitor is replaced by another one during suspend),
> no hotplug event will be triggered so the change will not be caught at
> resume time. Detecting that the EDID changed allows detecting it.
>
> Signed-off-by: Paul Kocialkowski
I can't find the older mails I've typed about this, but the plan we've
discussed a while back was:
- Add a generational counter to each connector, maybe even expose it to
userspace.
- Increment that counter every time something changed, e.g.
connector->status in the propbe helpers, or when attaching a new edid
with the set_edid helper.
- Tada, no changes needed to drivers, and easily extensible to other
things than edid!
Cheers, Daniel
> ---
> drivers/gpu/drm/drm_edid.c | 45 +
> include/drm/drm_edid.h | 3 +++
> 2 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 6bb6337be920..f6ce8bc2907a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5036,3 +5036,48 @@ static void drm_get_displayid(struct drm_connector
> *connector,
> }
> return;
> }
> +
> +/**
> + * drm_check_edid_changed - Check whether the EDID changed since the last
> update
> + * @connector: connector we're probing
> + * @adapter: I2C adapter to use for DDC
> + *
> + * Check whether the EDID changed since the last time it was updated in the
> + * drm blob cache.
> + *
> + * Return: A boolean indicating whether a change happened or not.
> + */
> +bool drm_check_edid_changed(struct drm_connector *connector,
> + struct i2c_adapter *adapter)
> +{
> + struct drm_property_blob *edid_blob;
> + struct edid *edid_stored;
> + struct edid *edid_read;
> + int ret = 0;
> +
> + if (!connector->edid_blob_ptr)
> + return false;
> +
> + edid_blob = drm_property_blob_get(connector->edid_blob_ptr);
> + if (!edid_blob)
> + return false;
> +
> + if (!edid_blob->data || edid_blob->length != sizeof(struct edid))
> + goto out;
> +
> + edid_stored = (struct edid *) edid_blob->data;
> +
> + edid_read = drm_get_edid(connector, adapter);
> + if (!edid_read)
> + goto out;
> +
> + ret = memcmp(edid_stored, edid_read, sizeof(struct edid));
> +
> + kfree(edid_read);
> +
> +out:
> + drm_property_blob_put(edid_blob);
> +
> + return ret != 0;
> +}
> +EXPORT_SYMBOL_GPL(drm_check_edid_changed);
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 1e1908a6b1d6..593a97b269c3 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -485,4 +485,7 @@ void drm_edid_get_monitor_name(struct edid *edid, char
> *name,
> struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
> int hsize, int vsize, int fresh,
> bool rb);
> +bool drm_check_edid_changed(struct drm_connector *connector,
> + struct i2c_adapter *adapter);
> +
> #endif /* __DRM_EDID_H__ */
> --
> 2.13.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
