aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2017-07-27drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'Christophe JAILLET1-1/+1
Goto the right label in case of error, otherwise there is a leak. This has been introduced by c5cf9a9147ff. In this patch a goto has not been updated. Fixes: c5cf9a9147ff ("drm/i915: Create a kmem_cache to allocate struct i915_priolist from") Signed-off-by: Christophe JAILLET <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Chris Wilson <[email protected]> (cherry picked from commit a5ec7fe81a6ec38cb8b8a798d0552cbcadce7aa9) Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Unbreak gpu reset vs. modeset lockingDaniel Vetter1-42/+18
Taking the modeset locks unconditionally isn't the greatest idea, because atm that part is still broken and times out (and then atomic keels over). And there's really no reason to do so, the old code didn't do that either. To make the patch a bit simpler let's also nuke 2 cases that are only around for the old mmioflip paths. Atomic nonblocking workers will not die (minus bugs) when a gpu reset happens. And of course this doesn't fix any of the gpu reset vs. modeset deadlock fun, but it at least stop modern CI machines from keeling over all over the place for no reason at all. And we still have the explicit testcases to run the fake gpu reset, so coverage isn't that much worse. v2: Split out additional changes on top, restrict this to purely reducing the critical section of modeset locks. v2: Review from Maarten - update comments - don't oops when state is NULL in intel_finish_reset, but try to at least still drop locks properly. The hw is going to be toast anyway. Fixes: 739748939974 ("drm/i915: Fix modeset handling during gpu reset, v5.") Cc: Maarten Lankhorst <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit ce87ea15ebc60a9f8f156b2549f7b2cf7fe48d04) Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/amdgpu: fix header on gfx9 clear stateAlex Deucher1-20/+21
This got missed when we open sourced this. Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2017-07-27gpu: host1x: Free the IOMMU domain when there is no device to attachPaul Kocialkowski1-1/+7
When there is no device to attach to the IOMMU domain, as may be the case when the device-tree does not contain the proper iommu node, it is best to keep going without IOMMU support rather than failing. This allows the driver to probe and function instead of taking down all of the tegra drm driver, leading to missing display support. Signed-off-by: Paul Kocialkowski <[email protected]> Fixes: 404bfb78daf3 ("gpu: host1x: Add IOMMU support") Reviewed-by: Mikko Perttunen <[email protected]> Tested-by: Marcel Ziswiler <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-07-27drm/amdgpu: fix header on gfx9 clear stateAlex Deucher1-20/+21
This got missed when we open sourced this. Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2017-07-27drm/i915: Fix cursor updates on some platformsVille Syrjälä1-1/+11
Turns out that just writing CURPOS isn't sufficient to move the cursor on some platforms. My 830 works just fine, but eg. 945 and PNV don't. On those platforms we need to arm even the CURPOS update with a CURBASE write. Even worse, a write to any of the cursor register apart from CURBASE will cancel an already pending cursor update. So if we have armed a CURCNTR/CURBASE update, a subsequent CURPOS write prior to vblank would cancel that armed update. Thus we're left with a cursor that doesn't appear to move, or even change shape. Fix the problem by always performing the CURBASE write after a CURPOS write. Bspec is somewhat unclear which platforms actually require this CURBASE write and which don't. So to keep it simple and to make sure we really fix the problem across all supported devices, let's just perform the CURBASE write unconditionally. Cc: Paul Menzel <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101790 Fixes: 75343a44c901 ("drm/i915: Drop useless posting reads from cursor commit") Signed-off-by: Ville Syrjälä <[email protected]> Tested-by: Paul Menzel <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 8753d2bc5e49daad301ce65f5dada57ed924fad6) Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Fix user ptr check size in eb_relocate_vma()Imre Deak1-1/+1
Fix the sizeof(ptr) vs. sizeof(*ptr) typo. Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit edd9003f7f9dddd28fdd768e6e7569d996c769cb) Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/sdvo: Shut up state checker with hdmi cards on gen3Daniel Vetter1-2/+10
The hdmi bits simply don't exist, so nerf them. I think audio doesn't work on gen3 at all, and for the limited color range we should probably use the colorimetry sdvo paramater instead of the bit in the port. But fixing sdvo isn't my goal, I just want to get the backtrace out of the way, and this takes care of that. Still, while at it fix the missing read-out of the gen4 audio bit, maybe that part even works ... v2: Instead of trying to plug the damage in ->compute_config() make sure we never set intel_sdvo->is_hdmi, which stops the bad state at the source. Suggested by Chris Wilson. Also make sure we don't break this by accident by putting a WARN_ON in place. Cc: Chris Wilson <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-07-27drm/i915: Rework sdvo proxy i2c lockingDaniel Vetter2-14/+84
lockdep complaints about a locking recursion for the i2c bus lock because both the sdvo ddc proxy bus and the gmbus nested within use the same locking class. It's not really a deadlock since we never nest the other way round, but it's annoying. Fix it by pulling the gmbus locking into the i2c lock_ops for both i2c_adapater and making sure that the ddc_proxy_xfer function is entirely lockless. Re-layouting the extracted function resulted in some whitespace cleanups, I figured we might as well keep them. v2: Review from Chris: - s/locked/unlocked/ since I got the naming backwards - Use the vfuncs of the proxied adatper instead of re-rolling copies. That's more consistent with the other proxying we're doing. Cc: Chris Wilson <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-07-27drm/i915: Call the unlocked version of i915_gem_object_get_pages()Chris Wilson1-1/+1
When we hold for the lock for swapping out the shmem pages for the physically contiguous pages, we have to call the unlocked version of get_pages! Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101934 Fixes: 35d23516946e ("drm/i915: Make i915_gem_object_phys_attach() use obj->mm.lock more appropriately") Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Move i915_gem_object_phys_attach()Chris Wilson1-60/+58
Prevent a forward declaration in the next patch. Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Pin the pages before acquiring struct_mutex for displayChris Wilson1-1/+8
Since we don't need the struct_mutex to acquire the object's pages, call i915_gem_object_pin_pages() before we bind the object into the GGTT. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Make i915_gem_object_phys_attach() use obj->mm.lock more appropriatelyChris Wilson1-15/+35
Actually transferring from shmemfs to the physically contiguous set of pages should be wholly guarded by its obj->mm.lock! v2: Remember to free the old pages. Signed-off-by: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Trim struct_mutex usage for kmsChris Wilson1-48/+34
Reduce acquisition of struct_mutex to the critical regions that must hold it; for KMS, we need struct_mutex currently only for the purpose of pinning/unpinning the framebuffer's VMA into the global GTT. This allows us to avoid taking the struct_mutex when disabling the CRTC (i.e. NULL framebuffer objects) before a reset. (Not yet achieving the full goal of avoiding the strut_mutex nesting, but good enough to break the first half of the reset deadlock.) v2: Keep pages pinning inside struct_mutex for the moment. Signed-off-by: Chris Wilson <[email protected]> Cc: Maarten Lankhorst <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] [danvet: Drop another case of grabbing dev->struct_mutex around cleanup_planes, which popped up because I had to redo the drm-next backmerge for entirely different reasons. Acked by Chris on irc.] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Handle msr read failure gracefullyGabriel Krisman Bertazi1-6/+9
When reading the i915_energy_uJ debugfs file, it tries to fetch MSR_RAPL_POWER_UNIT, which might not be available, like in a vm environment, causing the exception shown below. We can easily prevent it by doing a rdmsrl_safe read instead, which will handle the exception, allowing us to abort the debugfs file read. This was caught by the new igt@debugfs_test@read_all_entries testcase in the CI. unchecked MSR access error: RDMSR from 0x606 at rIP:0xffffffffa0078f66 (i915_energy_uJ+0x36/0xb0 [i915]) Call Trace: seq_read+0xdc/0x3a0 full_proxy_read+0x4f/0x70 __vfs_read+0x23/0x120 ? putname+0x4f/0x60 ? rcu_read_lock_sched_held+0x75/0x80 ? entry_SYSCALL_64_fastpath+0x5/0xb1 vfs_read+0xa0/0x150 SyS_read+0x44/0xb0 entry_SYSCALL_64_fastpath+0x1c/0xb1 RIP: 0033:0x7f1f5e9f4500 RSP: 002b:00007ffc77e65cf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: ffffffff8146e003 RCX: 00007f1f5e9f4500 RDX: 0000000000000200 RSI: 00007ffc77e65d10 RDI: 0000000000000006 RBP: ffffc900007abf88 R08: 0000000001eaff20 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000006 R14: 0000000000000005 R15: 0000000001eb94db ? __this_cpu_preempt_check+0x13/0x20 v2: - Drop unsigned long long cast and improve calculation (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101901 Signed-off-by: Gabriel Krisman Bertazi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Force CPU synchronisation even if userspace requests ASYNCChris Wilson3-8/+11
The goal here was to minimise doing any thing or any check inside the kernel that was not strictly required. For a userspace that assumes complete control over the cache domains, the kernel is usually using outdated information and may trigger clflushes where none were required. However, swapping is a situation where userspace has no knowledge of the domain transfer, and will leave the object in the CPU cache. The kernel must flush this out to the backing storage prior to use with the GPU. As we use an asynchronous task tracked by an implicit fence for this, we also need to cancel the ASYNC flag on the object so that the object will wait for the clflush to complete before being executed. This also absolves userspace of the responsibility imposed by commit 77ae9957897d ("drm/i915: Enable userspace to opt-out of implicit fencing") that its needed to ensure that the object was out of the CPU cache prior to use on the GPU. Fixes: 77ae9957897d ("drm/i915: Enable userspace to opt-out of implicit fencing") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101571 Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Jason Ekstrand <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Joonas Lahtinen <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Only skip updating execobject.offset after errorChris Wilson1-3/+3
I was being overly paranoid in not updating the execobject.offset after performing the fallback copy where we set reloc.presumed_offset to -1. The thinking was to ensure that a subsequent NORELOC execbuf would be forced to process the invalid relocations. However this is overkill so long as we *only* update the execobject.offset following a successful update of the relocation value witin the batch. If we have to repeat the execbuf due to a later interruption, then we may skip the relocations on the second pass (honouring NORELOC) since the execobject.offset match the actual offsets (even though reloc.presumed_offset is garbage). Subsequent calls to execbuf with NORELOC should themselves ensure that the reloc.presumed_offset have been corrected in case of future migration. Reporting back the actual execobject.offset, even when reloc.presumed_offset is garbage, ensures that reuse of those objects use the latest information to avoid relocations. Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101635 Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Joonas Lahtinen <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Only mark the execobject as pinned on successChris Wilson1-3/+3
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: 0000 [#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: ffff8800785d4c40 task.stack: ffffc90001768000 [ 3194.046339] RIP: 0010:eb_release_vmas.isra.6+0x119/0x180 [i915] [ 3194.052234] RSP: 0018:ffffc9000176ba80 EFLAGS: 00010246 [ 3194.057439] RAX: 00000000000003c0 RBX: ffff8800710fc2d8 RCX: ffff8800588e4f48 [ 3194.064546] RDX: ffffffff1fffffff RSI: 00000000ffffffff RDI: ffff8800588e00d0 [ 3194.071654] RBP: ffffc9000176bab0 R08: 0000000000000000 R09: 0000000000000000 [ 3194.078761] R10: 0000000000000040 R11: 0000000000000001 R12: ffff880060822f00 [ 3194.085867] R13: 0000000000000310 R14: 00000000000003b8 R15: ffffc9000176bbb0 [ 3194.092975] FS: 00007fd2b94aba40(0000) GS:ffff88007d200000(0000) knlGS:0000000000000000 [ 3194.101033] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3194.106754] CR2: 00007ffbec3ff000 CR3: 0000000074e67000 CR4: 00000000000006f0 [ 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:00007fff074845b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 3194.200855] RAX: ffffffffffffffda RBX: ffffffff8146da43 RCX: 00007fd2b76a8587 [ 3194.207962] RDX: 00007fff074846e0 RSI: 0000000040406469 RDI: 0000000000000003 [ 3194.215068] RBP: ffffc9000176bf88 R08: 0000000000000000 R09: 0000000000000003 [ 3194.222175] R10: 00007fd2b796bb58 R11: 0000000000000246 R12: 00007fff07484880 [ 3194.229280] R13: 0000000000000003 R14: 0000000040406469 R15: 0000000000000000 [ 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: ffffc9000176ba80 [ 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 <[email protected]> Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Joonas Lahtinen <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Remove assertion from raw __i915_vma_unpin()Chris Wilson1-1/+1
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 <[email protected]> Cc: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Joonas Lahtinen <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/cnl: Fix loadgen select programming on ddi vswing sequenceNavare, Manasi D1-2/+2
The condition for setting the Loadgen Select bit of PORT_TX_DW4 register during DDI Vswing Sequence should be Bit rate <=6 GHz whereas the existing code checks only Bit Rate < 6GHz. This patch fixes this condition. While at it also remove the redundant paranthesis. Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.") Cc: Paulo Zanoni <[email protected]> Cc: Rodrigo Vivi <[email protected]> Signed-off-by: Manasi Navare <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/fbc: add comments to the FBC auxiliary structsPaulo Zanoni1-0/+12
I wrote this code an year and a half ago and I couldn't exactly remember the main differences of these two structures when reviewing a new FBC patch. Add some comments to help explain what's the purpose of each struct. For the record, the original commits are: b183b3f14395 ("drm/i915/fbc: introduce struct intel_fbc_reg_params") aaf78d276ba0 ("drm/i915/fbc: introduce struct intel_fbc_state_cache") Cc: Praveen Paneri <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: cleanup the CHICKEN_MISC_2 (re)definitionsPaulo Zanoni2-7/+5
* Don't define it twice. * Define MSBs first, like the rest of i915_reg.h. * Add CNL_ prefix to the bit that arrived in CNL. Cc: Ville Syrjälä <[email protected]> Cc: Rodrigo Vivi <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/selftests: Fix kbuild errorChris Wilson1-1/+1
After applying af2788925ae0 ("drm/i915: Squelch reset messages during selftests") out of sequence, I missed fixing up a call to i915_reset(). Reported-by: kbuild test robot <[email protected]> Fixes: af2788925ae0 ("drm/i915: Squelch reset messages during selftests") Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: David Weinehall <[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Squelch reset messages during selftestsChris Wilson5-31/+39
During our selftests, we try reseting the GPU tens of thousands of times, flooding the dmesg with our 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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Michel Thierry <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/selftest: Refactor reset lockingChris Wilson1-15/+43
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 <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Michel Thierry <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Michel Thierry <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Don't touch fence->error when resetting an innocent requestChris Wilson1-19/+34
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: 0000 [#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: ffff8801f42e9780 task.stack: ffff8801f42f8000 [ 231.743489] RIP: 0010:i915_gem_reset_engine+0x45a/0x460 [i915] [ 231.743505] RSP: 0018:ffff8801f42ff770 EFLAGS: 00010202 [ 231.743521] RAX: 0000000000000007 RBX: ffff8801bf6b1880 RCX: ffffffffa02881a6 [ 231.743537] RDX: dffffc0000000000 RSI: dffffc0000000000 RDI: ffff8801bf6b18c8 [ 231.743551] RBP: ffff8801f42ff7c8 R08: 0000000000000001 R09: 0000000000000000 [ 231.743566] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801edb02d00 [ 231.743581] R13: ffff8801e19d4200 R14: 000000000000001d R15: ffff8801ce2a4000 [ 231.743599] FS: 0000000000000000(0000) GS:ffff8801f5a80000(0000) knlGS:0000000000000000 [ 231.743614] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 231.743629] CR2: 00007f0ebd1add10 CR3: 0000000002621000 CR4: 00000000000406e0 [ 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: ffff8801f42ff770 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 <[email protected]> Fixes: c64992e035d7 ("drm/i915: Look for active requests earlier in the reset path") Signed-off-by: Chris Wilson <[email protected]> Cc: Michel Thierry <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Joonas Lahtinen <[email protected]> #v1 Reviewed-by: Michel Thierry <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Enforce that CS packets are qword alignedChris Wilson1-0/+3
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 <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/glk: set HDMI 2.0 identifierShashank Sharma1-0/+3
This patch sets the is_hdmi2_src identifier in drm connector for GLK platform. GLK contains a native HDMI 2.0 controller. This identifier will help the EDID handling functions to save lot of work which is specific to HDMI 2.0 sources. V3: Added this patch V4: Rebase V4: Rebase V5: Added r-b from Ander V6: Rebase V7: Rebase V8: Rebase V9: Added r-b from Ville V9: Added r-b from Imre Cc: Ville Syrjala <[email protected]> Cc: Ander Conselvan de Oliveira <[email protected]> Cc: Imre Deak <[email protected]> Reviewed-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Ville Syrjala <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: set colorspace for YCBCR420 outputsShashank Sharma1-0/+6
When output colorspace is YCBCR420, we have to load the corresponding colorspace in AVI infoframe. This patch fills the colorspace of AVI infoframe as per the output mode. V2: Rebase V3: Rebase V4: Rebase V5: Added r-b from Ander V6: Checking RGB/YCBCR420 output only (Ville) V7: Add colorspace info in driver(not drm layer) (Ville) V8: Rebase V9: Added r-b from Ville V10: Added r-b from Imre Cc: Ville Syrjala <[email protected]> Cc: Ander Conselvan de Oliveira <[email protected]> Cc: Imre Deak <[email protected]> Reviewed-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Ville Syrjala <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: prepare csc unit for YCBCR420 outputShashank Sharma2-1/+54
To support ycbcr output, we need a pipe CSC block to do RGB->YCBCR conversion. Current Intel platforms have only one pipe CSC unit, so we can either do color correction using it, or we can perform RGB->YCBCR conversion. This function adds a csc handler, which uses recommended bspec values to perform RGB->YCBCR conversion (target color space BT709) V2: Rebase V3: Rebase V4: Rebase V5: Addressed review comments from Ander - Remove extra line added in the patch - Add the spec details in the commit message - Combine two if(cond) while calling intel_crtc_compute_config V6: Handle YCBCR420 outputs only (Ville) V7: Addressed review comments from Ville: - Add description about target colorspace - Remove the comments from CSC function - DRM_DEBUG->DEBUG_KMS for atomic failure due to CSC unit busy - Remove unnecessary debug message about YCBCR420 possibe V8: Addressed review comments from Ville: - Remove extra comment, not required. - Do not add extra variable for CTM, reuse pipe_config Added r-b from Ville V9: Remove extra whitespace (Imre) V10: Added r-b from Imre Cc: Ville Syrjala <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Ander Conselvan de Oliveira <[email protected]> Cc: Imre Deak <[email protected]> Reviewed-by: Ville Syrjala <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: prepare pipe for YCBCR420 outputShashank Sharma4-0/+36
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 <[email protected]> Cc: Ander Conselvan de Oliveira <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Imre Deak <[email protected]> Reviewed-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Ville Syrjala <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: prepare scaler for YCBCR420 modesetShashank Sharma3-1/+17
To get a YCBCR420 output from intel platforms, we need one scaler to scale down YCBCR444 samples to YCBCR420 samples. This patch: - Does scaler allocation for HDMI ycbcr420 outputs. - Programs PIPE_MISC register for ycbcr420 output. V2: rebase V3: rebase V4: rebase V5: addressed review comments from Ander: - No need to check both scaler_user && hdmi_output. Check for scaler_user is enough. V6: rebase V7: Do not create a new scaler user, use existing pipe scaler user. V8: rebase V9: Addressed review comments from Ville: - Remove leftover comment for HDMI scaler user. - Remove unnecessary blank line. - Make scaler alocation failure a DEBUG log instead of ERROR. Added r-b from Ville V10: Update commit message as per latest code (Imre) Added r-b from Imre Cc: Ville Syrjala <[email protected]> Cc: Ander Conselvan De Oliveira <[email protected]> Cc: Imre Deak <[email protected]> Reviewed-by: Ville Syrjala <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: add config function for YCBCR420 outputsShashank Sharma3-3/+41
This patch checks encoder level support for YCBCR420 outputs. The logic goes as simple as this: If the input mode is YCBCR420-only mode: prepare HDMI for YCBCR420 output, else continue with RGB output mode. It checks if the mode is YCBCR420 and source can support this output then it marks the ycbcr_420 output indicator into crtc state, for further staging in driver. V2: Split the patch into two, kept helper functions in DRM layer. V3: Changed the compute_config function based on new DRM API. V4: Rebase V5: Rebase V6: Check and handle YCBCR420-only modes, discard the property based approach (Ville) V7: Addressed review comments from Ville - add else case in 12BPC check. - extract ycbcr420 state inside hdmi_12bpc_possible function. V8: Addressed review comments from Ville - Remove extra blank lines. - Remove "HDMI" from the description of ycbcr420 state variable. - Remove local variable, use crtc_state->ycbcr420 instead. Added r-b from Ville. V9: Rebase V10: Added r-b from Imre Cc: Ville Syrjala <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Ville Syrjala <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Gather all the power well->domain mappings to one placeImre Deak1-204/+204
Shuffle the power well->domain mapping macros around so they are at one place in old->new GEN order. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Arkadiusz Hiler <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Move hsw_power_well_enable() next to the rest of HSW helpersImre Deak1-14/+14
Move the helper next to the rest of HSW specific code. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Arkadiusz Hiler <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/gen9+: Unify the HSW/BDW and GEN9+ power well helpersImre Deak1-188/+43
After the previous refactorings the HSW/BDW and GEN9+ power well helpers are practically identical, so use the HSW power well helpers for GEN9+ too. This means using the HSW power well ops instead of the SKL one and setting the irq_pipe_mask, has_vga and has_fuses attributes as needed. v2: - Rebased on v2 of patch 15. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Arkadiusz Hiler <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/hsw+: Add has_fuses power well attributeImre Deak4-14/+48
The pattern of a power well backing a set of fuses whose initialization we need to wait for during power well enabling is common to all GEN9+ platforms. Adding support for this to the HSW power well enable helper allows us to use the HSW/BDW power well code for GEN9+ as well in a follow-up patch. v2: - Use an enum for power gates instead of raw numbers. (Ville) Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Arkadiusz Hiler <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/hsw, bdw: Wait for the power well disabled stateImre Deak1-17/+11
Similarly to GEN9+ waiting for the power well disabled state is a safer option and also provides diagnostic info if the disabling didn't succeed or the power well was forced on by an external requester. While at it also use the existing GEN9+ helper to wait for the enabled state. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Arkadiusz Hiler <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/hsw, bdw: Add irq_pipe_mask, has_vga power well attributesImre Deak4-17/+31
The pattern of a power well backing a set of pipe IRQ or VGA functionality applies to all HSW+ platforms. Using power well attributes instead of platform checks to decide whether to init/reset pipe IRQs and VGA correspondingly is cleaner and it allows us to unify the HSW/BDW and GEN9+ power well code in follow-up patches. Also use u8 for pipe_mask in related helpers to match the type in the power well struct. v2: - Use u8 instead of u32 for irq_pipe_mask. (Ville) v3: - Use u8 for pipe_mask in related helpers too for clarity. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Arkadiusz Hiler <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/hsw+: Unify the hsw/bdw and gen9+ power well req/state macrosImre Deak3-30/+44
Although on HSW/BDW there is only a single display global power well, it's programmed the same way as other GEN9+ power wells. This also means we can get at the HSW/BDW request and status flags the same way it's done on GEN9+ by assigning the corresponding HSW/BDW power well ID. This ID was assigned in a recent patch, so we can now switch to using the same macros everywhere on HSW+. Updating the HSW power well control register with RMW is not strictly necessary, but this will allow us to use the same code for GEN9+. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Arkadiusz Hiler <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/hsw, bdw: Split power well set to enable/disable helpersImre Deak1-33/+17
We can reduce the code indentation by splitting the set helper to separate enable/disable helpers. This also allows us to unify the HSW/BDW and GEN9+ power well ops in follow-up patches, which introduces some differences between the enable and disable helpers. While at it also remove the redundant enable/disable debug messages, the same info is printed already elsewhere. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Arkadiusz Hiler <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/hsw, bdw: Remove redundant state check during power well togglingImre Deak1-23/+13
Similarly to the GEN9 power well toggling, saving an occasional extra MMIO write is not worth the code complexity, let's simplify things. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Arkadiusz Hiler <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/gen9+: Remove redundant state check during power well togglingImre Deak1-16/+9
Atm we enable/disable a power well only if it wasn't already enabled/disabled respectively. The only reason for this I can think of is to save the extra MMIO writes. Since the HW state matches the power well's usage counter most of the time the overhead due to these MMIOs is insignificant. Let's simplify the code by making the writes unconditional. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Arkadiusz Hiler <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/gen9+: Remove redundant power well state assert during enablingImre Deak1-6/+1
We check already for power wells that are unexpectedly on (or forced on) during power well disabling. Those checks also account for other power well requesters like KVMR or DEBUG. As such this check is redundant, let's remove it to simplify things. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Arkadiusz Hiler <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/bxt, glk: Give a proper name to the power well struct phy fieldImre Deak2-12/+16
Follow-up patches will add new fields to the i915_power_well struct that are specific to the hsw_power_well_ops helpers. Prepare for this by changing the generic 'data' field to a union of platform specific structs. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Arkadiusz Hiler <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Check for duplicated power well IDsImre Deak1-0/+18
Check that all the power well IDs are unique on the given platform. v2: - Fix using BIT_ULL() instead of BIT() for 64 bit mask. v3: - Move the check to a separate function. (Ville) Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Arkadiusz Hiler <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/hsw, bdw: Add an ID for the global display power wellImre Deak2-0/+8
Add an ID for the HSW/BDW global display power well for consistency. The ID is selected so that it can be used to get at the HW request and status flags with the corresponding GEN9+ macros. Unifying the HSW/BDW and GEN9+ versions of these macros and the power well ops using them will be done in follow-up patches. v2: - Rebased on v2 of patch 2. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915/gen2: Add an ID for the display pipes power wellImre Deak2-0/+7
Make the I830 power well ID assignment explicit for consistency. v2: - s/GEN2/I830/ in the comment, since other GEN2s don't have the power well. (Ville) Cc: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Assign everywhere the always-on power well IDImre Deak1-0/+8
Power well IDs are used for lookup so they must be unique. To ensure this assign the always-on power well ID everywhere where it's missing. This didn't cause a problem so far, since we didn't need to look up power wells that happened to share their IDs. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Unify power well ID enumsImre Deak3-28/+45
Atm, the power well IDs are defined in separate platform specific enums, which isn't ideal for the following reasons: - the IDs are used by helpers like lookup_power_well() in a platform independent way - the always-on power well is used by multiple platforms and so needs now separate IDs, although these IDs refer to the same thing To make things more consistent use a single enum instead of the two separate ones, listing the IDs per platform (or set of very similar platforms like all GEN9/10). Replace the separate always-on power well IDs with a single ID. While at it also add a note clarifying the distinction between regular power wells that follow a common programming pattern and custom ones that are programmed in some other way. The IDs for regular power wells need to stay fixed, since they also define the request and state HW flag positions in their corresponding power well control register(s). v2: - Add comment about id to req,status bit mapping to the enum. (Rodrigo) Cc: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.