aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2015-07-14drm/i915: Remove unused compat32 codeDaniel Vetter1-125/+0
Totatlly forgotten that we have these when nuking all the UMS code. Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Remove plane_config from struct intel_crtc, v2.Maarten Lankhorst2-10/+10
Nothing depends on this outside initial hw readout, so keep this struct on the stack instead. Changes since v1: - Remove unrelated changes. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Update missing properties in find_initial_plane_objMaarten Lankhorst1-2/+11
The src and crtc rectangles were never set, resulting in the primary plane being made invisible on first atomic update. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Allow fuzzy matching in pipe_config_compare, v2.Maarten Lankhorst1-61/+157
Instead of doing ad-hoc checks we already have a way of checking if the state is compatible or not. Use this to force a modeset. Only during modesets, or with PIPE_CONFIG_QUIRK_INHERITED_MODE we should check if a full modeset is really needed. Fastboot will allow the adjust parameter to ignore some stuff too, and it will fix up differences in state that are ignored by the compare function. Changes since v1: - Increase the value of the lowest m/n to prevent truncation. - Dump pipe config when fastboot's used, without a modeset. - Add adjust parameter to intel_compare_link_m_n, which is used to adjust m2_n2 if it's a multiple of m_n. - Add exact parameter intel_compare_m_n. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Do not use plane_config in intel_fbdev.cMaarten Lankhorst1-8/+6
Use the atomic state instead, this allows removing plane_config from the crtc after the full hw readout is completed. The size can be found in the fb, no need for the plane_config. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Do not update pfit state when toggling crtc enabled.Maarten Lankhorst4-38/+48
There's not much point for calculating the changes for the old state. Instead just disable all scalers when disabling. It's probably good enough to just disable the crtc_scaler, but just in case there's a bug disable all scalers. This means intel_atomic_setup_scalers is only called in the crtc check function now, so all the transitional code can be removed. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Only update state on crtc's that are part of the atomic state.Maarten Lankhorst1-1/+2
This is probably hard to hit right now because in most cases all atomic locks are taken, but after conversion to atomic this will make it more likely to corrupt the crtc->config pointer, resulting in hard to find bugs. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Do not call intel_crtc_disable if the crtc is already disabled.Maarten Lankhorst1-4/+2
When resuming with dpms off, the following warn can happen: [ 118.334082] ------------[ cut here ]------------ [ 118.334105] WARNING: CPU: 2 PID: 2274 at drivers/gpu/drm/i915/intel_display.c:6319 __intel_set_mode+0xae5/0xb90 [i915]() [ 118.334106] WARN_ON(!crtc->state->enable) [ 118.334137] Modules linked in: i915 [ 118.334139] CPU: 2 PID: 2274 Comm: kworker/u16:117 Not tainted 4.2.0-rc2-fixes+ #4148 [ 118.334140] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014 [ 118.334144] Workqueue: events_unbound async_run_entry_fn [ 118.334147] ffffffffc017eef0 ffff8800ada93998 ffffffff817aa62a 0000000080000001 [ 118.334149] ffff8800ada939e8 ffff8800ada939d8 ffffffff810807e1 ffff8800ada939c8 [ 118.334151] ffff8800cea3b3d8 0000000000000000 ffff8800ad86b008 ffff880117705668 [ 118.334151] Call Trace: [ 118.334155] [<ffffffff817aa62a>] dump_stack+0x4f/0x7b [ 118.334157] [<ffffffff810807e1>] warn_slowpath_common+0x81/0xc0 [ 118.334158] [<ffffffff81080861>] warn_slowpath_fmt+0x41/0x50 [ 118.334173] [<ffffffffc0120375>] __intel_set_mode+0xae5/0xb90 [i915] [ 118.334188] [<ffffffffc0121312>] ? intel_modeset_compute_config+0x52/0xb40 [i915] [ 118.334191] [<ffffffff8144de53>] ? drm_atomic_set_fb_for_plane+0x63/0x80 [ 118.334205] [<ffffffffc01269d9>] intel_set_mode+0x29/0x60 [i915] [ 118.334219] [<ffffffffc012730a>] intel_crtc_restore_mode+0x13a/0x1f0 [i915] [ 118.334232] [<ffffffffc0101160>] ? gen6_write16+0x250/0x250 [i915] [ 118.334246] [<ffffffffc01283ec>] intel_modeset_setup_hw_state+0x89c/0xcd0 [i915] [ 118.334248] [<ffffffff8137d260>] ? pci_pm_thaw+0x90/0x90 [ 118.334255] [<ffffffffc00ac11b>] i915_drm_resume+0xcb/0x160 [i915] [ 118.334262] [<ffffffffc00ac1d2>] i915_pm_resume+0x22/0x30 [i915] [ 118.334263] [<ffffffff8137d2c3>] pci_pm_resume+0x63/0xa0 [ 118.334266] [<ffffffff81467550>] dpm_run_callback+0x70/0x420 [ 118.334267] [<ffffffff81467cbd>] device_resume+0x9d/0x1c0 [ 118.334269] [<ffffffff814673d0>] ? initcall_debug_start+0x60/0x60 [ 118.334270] [<ffffffff81467dfc>] async_resume+0x1c/0x50 [ 118.334271] [<ffffffff810a6a94>] async_run_entry_fn+0x34/0xd0 [ 118.334273] [<ffffffff8109d4ad>] process_one_work+0x1dd/0x7e0 [ 118.334275] [<ffffffff8109d41a>] ? process_one_work+0x14a/0x7e0 [ 118.334276] [<ffffffff8109daf9>] worker_thread+0x49/0x450 [ 118.334278] [<ffffffff8109dab0>] ? process_one_work+0x7e0/0x7e0 [ 118.334280] [<ffffffff810a3cb9>] kthread+0xf9/0x110 [ 118.334282] [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90 [ 118.334284] [<ffffffff817b414f>] ret_from_fork+0x3f/0x70 [ 118.334286] [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90 [ 118.334287] ---[ end trace 01f2cf6371b82d7a ]--- This warn is harmless, and can be fixed by not calling intel_crtc_disable when the crtc is already disabled. Reported-and-Tested-by: Jörg Otte <[email protected]> Signed-off-by: Maarten Lankhorst <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14Revert "drm/i915: Declare the swizzling unknown for L-shaped configurations"Daniel Vetter1-11/+1
This reverts commit 19ee835cdb0b5a8eb11a68f25a51b8039d564488. It breaks existing old userspace which doesn't handle UNKNOWN swizzling correct. Yes UNKNOWN was a thing back in 2009 and probably still is on some other platforms, but it still pretty clearly broke the testers machine. If we want this we need to extend the ioctl with new paramters that only new userspace looks at. Cc: Harald Arnesen <[email protected]> Cc: Chris Wilson <[email protected]> Reported-by: Harald Arnesen <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/gem: rip out drm vma accounting for gem mmapsDaniel Vetter1-10/+1
Doesn't really add anything which can't be figured out through proc files. And more clearly separates the new gem mmap handling code from the old drm maps mmap handling code, which is surely a good thing. Cc: Martin Peres <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915/skl: Restrict the ring frequency table programming to SKLAkash Goel1-1/+2
Ring frequency table programming is not required on BXT. Added separate checks to enable the programming only for SKL & skip for BXT. v2: Removed the BXT check from gen6_update_ring_freq function Issue: VIZ-5144 Signed-off-by: Akash Goel <[email protected]> Reviewed-by: Rodrigo Vivi <rodrigo.vivi at intel.com> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Forward all core DRM ioctls to core compat handlingTvrtko Ursulin1-1/+1
Previously only core DRM ioctls under the DRM_COMMAND_BASE were being forwarded, but the drm.h header suggests (and reality confirms) ones after (and including) DRM_COMMAND_END should be forwarded as well. We need this to correctly forward the compat ioctl for the botched-up addfb2.1 extension. Signed-off-by: Tvrtko Ursulin <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] # 4.1+ [danvet: Explain why this is suddenly needed and add cc: stable.] Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: fix oops in primary_check_planeDaniel Vetter1-1/+1
On Sun, Jul 12, 2015 at 09:52:51AM -0700, Linus Torvalds wrote: > On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte <[email protected]> wrote: > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000009 > > IP: [<ffffffffbd3447bb>] 0xffffffffbd3447bb > > Ugh. Please enable KALLSYMS to get sane symbols. > > But yes, "crtc_state->base.active" is at offset 9 from "crtc_state", > so it's pretty clearly just that change frm > > - if (intel_crtc->active) { > + if (crtc_state->base.active) { > > and "crtc_state" is NULL. > > And the code very much knows that crtc_state can be NULL, since it's > initialized with > > crtc_state = state->base.state ? > intel_atomic_get_crtc_state(state->base.state, > intel_crtc) : NULL; > > Tssk. Daniel? Should I just revert that commit dec4f799d0a4 > ("drm/i915: Use crtc_state->active in primary check_plane func") for > now, or is there a better fix? Like just checking crtc_state for NULL? Indeed embarrassing. I've missed that we still have 1 caller left that's using the transitional helpers, and those don't fill out plane_state->state backpointers to the global atomic update since there is no global atomic update for transitional helpers. Below diff should fix this - we need to preferentially check crts_state->active and if that's not set intel_crtc->active should yield the right result for the one remaining caller (it's in the crtc_disable paths). This fixes a regression introduced in commit dec4f799d0a4c9edae20512fa60b0a36f3299ca2 Author: Daniel Vetter <[email protected]> Date: Tue Jul 7 11:15:47 2015 +0200 drm/i915: Use crtc_state->active in primary check_plane func which was quickly reverted in commit 01e2d0627a9a6edb24c37db45db5ecb31e9de808 Author: Linus Torvalds <[email protected]> Date: Sun Jul 12 15:00:20 2015 -0700 Revert "drm/i915: Use crtc_state->active in primary check_plane func" Cc: Linus Torvalds <[email protected]> Cc: Jörg Otte <[email protected]> Reported-and-tested-by: Jörg Otte <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: remove unused has_dma_mapping flagImre Deak5-15/+2
After the previous patch this flag will check always clear, as it's never set for shmem backed and userptr objects, so we can remove it. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> [danvet: Yeah this isn't really fixes but it's a nice cleanup to clarify the code but not really worth the hassle of backmerging. So just add to -fixes, we're still early in -rc.] Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: Fix missing return warning for !CONFIG_DEBUGFSDaniel Vetter1-1/+2
This broken code was introduced in commit aa7471d228eb6dfddd0d201ea9746d6a2020972a Author: Jani Nikula <[email protected]> Date: Wed Apr 1 11:15:21 2015 +0300 drm/i915: add i915 specific connector debugfs file for DPCD v2: Drop hunk that accidentally crept in. Cc: Jani Nikula <[email protected]> Cc: Bob Paauwe <[email protected]> Cc: François Valenduc <[email protected]> Reported-by: François Valenduc <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: avoid leaking DMA mappingsImre Deak2-17/+43
We have 3 types of DMA mappings for GEM objects: 1. physically contiguous for stolen and for objects needing contiguous memory 2. DMA-buf mappings imported via a DMA-buf attach operation 3. SG DMA mappings for shmem backed and userptr objects For 1. and 2. the lifetime of the DMA mapping matches the lifetime of the corresponding backing pages and so in practice we create/release the mapping in the object's get_pages/put_pages callback. For 3. the lifetime of the mapping matches that of any existing GPU binding of the object, so we'll create the mapping when the object is bound to the first vma and release the mapping when the object is unbound from its last vma. Since the object can be bound to multiple vmas, we can end up creating a new DMA mapping in the 3. case even if the object already had one. This is not allowed by the DMA API and can lead to leaked mapping data and IOMMU memory space starvation in certain cases. For example HW IOMMU drivers (intel_iommu) allocate a new range from their memory space whenever a mapping is created, silently overriding a pre-existing mapping. Fix this by moving the creation/removal of DMA mappings to the object's get_pages/put_pages callbacks. These callbacks already check for and do an early return in case of any nested calls. This way objects of the 3. case also become more like the other object types. I noticed this issue by enabling DMA debugging, which got disabled after a while due to its internal mapping tables getting full. It also reported errors in connection to random other drivers that did a DMA mapping for an address that was previously mapped by i915 but was never released. Besides these diagnostic messages and the memory space starvation problem for IOMMUs, I'm not aware of this causing a real issue. The fix is based on a patch from Chris. v2: - move the DMA mapping create/remove calls to the get_pages/put_pages callbacks instead of adding new callbacks for these (Chris) v3: - also fix the get_page cache logic on the userptr async path (Chris) Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: Snapshot seqno of most recently submitted request.Tomas Elf3-10/+11
The hang checker needs to inspect whether or not the ring request list is empty as well as if the given engine has reached or passed the most recently submitted request. The problem with this is that the hang checker cannot grab the struct_mutex, which is required in order to safely inspect requests since requests might be deallocated during inspection. In the past we've had kernel panics due to this very unsynchronized access in the hang checker. One solution to this problem is to not inspect the requests directly since we're only interested in the seqno of the most recently submitted request - not the request itself. Instead the seqno of the most recently submitted request is stored separately, which the hang checker then inspects, circumventing the issue of synchronization from the hang checker entirely. This fixes a regression introduced in commit 44cdd6d219bc64f6810b8ed0023a4d4db9e0fe68 Author: John Harrison <[email protected]> Date: Mon Nov 24 18:49:40 2014 +0000 drm/i915: Convert 'ring_idle()' to use requests not seqnos v2 (Chris Wilson): - Pass current engine seqno to ring_idle() from i915_hangcheck_elapsed() rather than compute it over again. - Remove extra whitespace. Issue: VIZ-5998 Signed-off-by: Tomas Elf <[email protected]> Cc: [email protected] Reviewed-by: Chris Wilson <[email protected]> [danvet: Add regressing commit citation provided by Chris.] Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: Store device pointer in contexts for late tracepoint usafeChris Wilson3-3/+4
[ 1572.417121] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1572.421010] IP: [<ffffffffa00b2514>] ftrace_raw_event_i915_context+0x5d/0x70 [i915] [ 1572.424970] PGD 1766a3067 PUD 1767a2067 PMD 0 [ 1572.428892] Oops: 0000 [#1] SMP [ 1572.432787] Modules linked in: ipv6 dm_mod iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore serio_raw pcspkr lpc_ich i2c_i801 mfd_core battery ac acpi_cpufreq i915 button video drm_kms_helper drm [ 1572.441720] CPU: 2 PID: 18853 Comm: kworker/u8:0 Not tainted 4.0.0_kcloud_3f0360_20150429+ #588 [ 1572.446298] Workqueue: i915 i915_gem_retire_work_handler [i915] [ 1572.450876] task: ffff880002f428f0 ti: ffff880035724000 task.ti: ffff880035724000 [ 1572.455557] RIP: 0010:[<ffffffffa00b2514>] [<ffffffffa00b2514>] ftrace_raw_event_i915_context+0x5d/0x70 [i915] [ 1572.460423] RSP: 0018:ffff880035727ce8 EFLAGS: 00010286 [ 1572.465262] RAX: ffff880073f1643c RBX: ffff880002da9058 RCX: ffff880073e5db40 [ 1572.470179] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880035727ce8 [ 1572.475107] RBP: ffff88007bb11a00 R08: 0000000000000000 R09: 0000000000000000 [ 1572.480034] R10: 0000000000362200 R11: 0000000000000008 R12: 0000000000000000 [ 1572.484952] R13: ffff880035727d78 R14: ffff880002dc1c98 R15: ffff880002dc1dc8 [ 1572.489886] FS: 0000000000000000(0000) GS:ffff88017fd00000(0000) knlGS:0000000000000000 [ 1572.494883] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1572.499859] CR2: 0000000000000000 CR3: 000000017572a000 CR4: 00000000001006e0 [ 1572.504842] Stack: [ 1572.509834] ffff88017b0090c0 ffff880073f16438 ffff880002da9058 ffff880073f1643c [ 1572.514904] 0000000000000246 ffff880100000000 ffff88007bb11a00 ffff880002ddeb10 [ 1572.519985] ffff8801759f79c0 ffffffffa0092ff0 0000000000000000 ffff88007bb11a00 [ 1572.525049] Call Trace: [ 1572.530093] [<ffffffffa0092ff0>] ? i915_gem_context_free+0xa8/0xc1 [i915] [ 1572.535227] [<ffffffffa009b969>] ? i915_gem_request_free+0x4e/0x50 [i915] [ 1572.540347] [<ffffffffa00b5533>] ? intel_execlists_retire_requests+0x14c/0x159 [i915] [ 1572.545500] [<ffffffffa009d9ea>] ? i915_gem_retire_requests+0x9d/0xeb [i915] [ 1572.550664] [<ffffffffa009dd8c>] ? i915_gem_retire_work_handler+0x4c/0x61 [i915] [ 1572.555825] [<ffffffff8104ca7f>] ? process_one_work+0x1b2/0x31d [ 1572.560951] [<ffffffff8104d278>] ? worker_thread+0x24d/0x339 [ 1572.566033] [<ffffffff8104d02b>] ? cancel_delayed_work_sync+0xa/0xa [ 1572.571140] [<ffffffff81050b25>] ? kthread+0xce/0xd6 [ 1572.576191] [<ffffffff81050a57>] ? kthread_create_on_node+0x162/0x162 [ 1572.581228] [<ffffffff8179b3c8>] ? ret_from_fork+0x58/0x90 [ 1572.586259] [<ffffffff81050a57>] ? kthread_create_on_node+0x162/0x162 [ 1572.591318] Code: de 48 89 e7 e8 09 4d 00 e1 48 85 c0 74 27 48 89 68 10 48 8b 55 38 48 89 e7 48 89 50 18 48 8b 55 10 48 8b 12 48 8b 12 48 8b 52 38 <8b> 12 89 50 08 e8 95 4d 00 e1 48 83 c4 30 5b 5d 41 5c c3 41 55 [ 1572.596981] RIP [<ffffffffa00b2514>] ftrace_raw_event_i915_context+0x5d/0x70 [i915] [ 1572.602464] RSP <ffff880035727ce8> [ 1572.607911] CR2: 0000000000000000 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90112#c23 Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: Don't forget to mark crtc as inactive after disablePatrik Jakobsson1-0/+9
Watermark calculations depend on the intel_crtc->active flag to be set properly. Suspend/resume is broken on SKL and we also get DDB mismatches without this patch. The regression was introduced in: commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6 Author: Maarten Lankhorst <[email protected]> Date: Mon Jun 15 12:33:53 2015 +0200 drm/i915: Update less state during modeset. No need to repeatedly call update_watermarks, or update_fbc. Down to a single call to update_watermarks in .crtc_enable Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Matt Roper <[email protected]> Tested-by(IVB): Matt Roper <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> v2: Don't touch disable_shared_dpll() Signed-off-by: Patrik Jakobsson <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91203 Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: Update PM interrupts before updating the freqDeepak S1-2/+2
Currently we update the freq before masking the interrupts, which can allow new interrupts to occur before the frequency has changed. These extra interrupts might waste some cpu cycles. This patch corrects this by masking interrupts prior to updating the frequency. Note from Chris: "Well it won't waste CPU cycles as the interrupt is also masked by the threshold limits, but there should be no harm at all in reordering the patch so, and it does make a certain amount of sense." Signed-off-by: Deepak S <[email protected]> Signed-off-by: Praveen Paneri <[email protected]> Reviewed-by: Chris Wilson <[email protected]> [danvet: Add note from Chris.] Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: storm detection documentation updateThulasimani,Sivakumar1-0/+8
Update the hotplug documentation to explain that hotplug storm is not expected for Display port panels and hence is not handled in current code. v2: update the statements as recommended by Daniel Signed-off-by: Sivakumar Thulasimani <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: Adjust BXT HDMI port clock limitsVille Syrjälä1-3/+6
Since commit e62925567c7926e78bc8ca976cde5c28ea265a49 Author: Vandana Kannan <[email protected]> Date: Wed Jul 1 17:02:57 2015 +0530 drm/i915/bxt: BUNs related to port PLL BXT DPLL can now generate frequencies in the 216-223 MHz range. Adjust the HDMI port clock checks to account for the reduced range of invalid frequencies. Cc: Vandana Kannan <[email protected]> Cc: Imre Deak <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: Refactor VLV display power well init/deinitVille Syrjälä1-29/+23
We do the exact same steps around the disp2d/pipe A power well enable/disable on VLV and CHV. Refactor the shared code into some helpers. Note that this means we now call vlv_power_sequencer_reset() before turning off the power well, whereas before we did it after. That doesn't matter though since vlv_power_sequencer_reset() just resets the power sequencer software tracking and doesn't touch the hardware at all. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Sivakumar Thulasimani <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: Simplify CHV pipe A power well codeVille Syrjälä1-27/+20
The pipe A power well is the "disp2d" well on CHV and pipe B and C wells don't even exist. Thereforce we can remove the checks for pipe A vs. others and just assume it's always pipe A. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Sivakumar Thulasimani <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: Apply OCD to VLV/CHV DPLL definesVille Syrjälä4-17/+17
Drop the spurious 'A' from the VLV/CHV ref clock enable define, and add the "REF" to the VLV ref clock selection bit. Also s/CLOCK/CLK/ for extra consistency. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Sivakumar Thulasimani <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: Keep GMCH DPLL VGA mode always disabledVille Syrjälä3-8/+10
We disable the DPLL VGA mode when enabling the DPLL, but we enaable it again when disabling the DPLL. Having VGA mode enabled even in unused DPLLs can cause problems for CHV, so it seems wiser to always keep it disabled. And let's just do that on all GMCH platforms to keep things as similar as possible between them. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Sivakumar Thulasimani <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915/skl: Updated the i915_ring_freq_table debugfs functionAkash Goel1-4/+15
Updated the i915_ring_freq_table debugfs function to support the read of ring frequency table, through Punit interface, for SKL also. Issue: VIZ-5144 Signed-off-by: Akash Goel <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915/skl: Ring frequency table programming changesAkash Goel1-4/+19
Ring frequency table programming changes for SKL. No need for a floor on ring frequency, as the issue of performance impact with ring running below DDR frequency, is believed to be fixed on SKL v2: Removed the check for avoiding ring frequency programming for BXT (Rodrigo) Issue: VIZ-5144 Signed-off-by: Akash Goel <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915/skl: Retrieve the Rpe value from PcodeAkash Goel1-8/+11
Read the efficient frequency (aka RPe) value through the the mailbox command (0x1A) from the pcode, as done on Haswell and Broadwell. The turbo minimum frequency softlimit is not revised as per the efficient frequency value. v2: Replaced the conditional expression operator with 'if' statement (Tom) v3: Corrected the derivation of efficient frequency & shifted the GEN9_FREQ_SCALER multiplications downwards (Ville) Issue: VIZ-5143 Signed-off-by: Akash Goel <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/rockchip: vop: remove hardware cursor windowyao mark1-11/+0
hardware cursor windows only have some fixed size, and not support width virtual, when move hardware cursor windows outside of left, the display would be wrong, so this window can't for cursor now. And Tag hardware cursor window as a overlay is wrong, will make userspace wrong behaviour. So just remove the hardware cursor window Signed-off-by: Mark Yao <[email protected]>
2015-07-13drm/rockchip: vop: switch cursor plane to window 3yao mark1-3/+4
Window 1 support scale and yuv format, it's waste use it for a cursor, use window 3 is enough. Signed-off-by: Mark Yao <[email protected]> Reviewed-by: Tomasz Figa <[email protected]>
2015-07-13drm/rockchip: Drop owner assignment from platform_driverKrzysztof Kozlowski1-1/+0
platform_driver does not need to set an owner because platform_driver_register() will set it. Signed-off-by: Krzysztof Kozlowski <[email protected]>
2015-07-13drm/rockchip: use drm_gem_mmap helpersDaniel Kurtz1-33/+34
Rather than (incompletely [0]) re-implementing drm_gem_mmap() and drm_gem_mmap_obj() helpers, call them directly from the rockchip mmap routines. Once the core functions return successfully, the rockchip mmap routines can still use dma_mmap_attrs() to simply mmap the entire buffer. [0] Previously, we were performing the mmap() without first taking a reference on the underlying gem buffer. This could leak ptes if the gem object is destroyed while userspace is still holding the mapping. Signed-off-by: Daniel Kurtz <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Cc: [email protected]
2015-07-13drm/rockchip: only call drm_fb_helper_hotplug_event if fb_helper presentHeiko Stübner1-1/+2
Add a check for the presence of fb_helper to rockchip_drm_output_poll_changed() to only call drm_fb_helper_hotplug_event if there is actually a fb_helper available. Without this check I see NULL pointer dereferences when the hdmi hotplug irq fires before the fb_helper got initialized. Signed-off-by: Heiko Stuebner <[email protected]>
2015-07-13drm/rockchip: Add BGR formats to VOPTomasz Figa1-0/+33
VOP can support BGR formats in all windows thanks to red/blue swap option provided in WINx_CTRL0 registers. This patch enables support for ABGR8888, XBGR8888, BGR888 and BGR565 formats by using this feature. Signed-off-by: Tomasz Figa <[email protected]>
2015-07-12Revert "drm/i915: Use crtc_state->active in primary check_plane func"Linus Torvalds1-1/+1
This reverts commit dec4f799d0a4c9edae20512fa60b0a36f3299ca2. Jörg Otte reports a NULL pointder dereference due to this commit, as 'crtc_state' very much can be NULL: crtc_state = state->base.state ? intel_atomic_get_crtc_state(state->base.state, intel_crtc) : NULL; So the change to test 'crtc_state->base.active' cannot possibly be correct as-is. There may be some other minimal fix (like just checking crtc_state for NULL), but I'm just reverting it now for the rc2 release, and people like Daniel Vetter who actually know this code will figure out what the right solution is in the longer term. Reported-and-bisected-by: Jörg Otte <[email protected]> Cc: Ander Conselvan de Oliveira <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Daniel Vetter <[email protected]> CC: Maarten Lankhorst <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-07-10drm/imx: tve: fix media bus format for VGA outputPhilipp Zabel1-1/+1
Commit a7c6e76feeb1 ("drm/imx: switch to use media bus formats") accidentally replaced IPU_PIX_FMT_GBR24 with MEDIA_BUS_FMT_YUV8_1X24 instead of the correct MEDIA_BUS_FMT_GBR888_1X24. This patch is needed to fix VGA output in i.MX53. Signed-off-by: Philipp Zabel <[email protected]>
2015-07-10GPU: ipu: fix lockup caused by pending chained interruptsRussell King1-0/+3
Even with the oops fixed by a previous patch, the system still fails to kexec, due to a stuck chained interrupt locking the system. We must disable the child interrupts prior to setting up the irq chip to ensure we don't get stuck here. Signed-off-by: Russell King <[email protected]> Signed-off-by: Philipp Zabel <[email protected]>
2015-07-10drm/imx: parallel-display: fix drm_panel supportPhilipp Zabel1-6/+15
The parallel-display driver used an undocumented, non-standard property "fsl,panel" to optionally associate with a drm_panel device. This patch fixes the driver to use the same OF graph bindings as the LDB driver instead: parallel-display { compatible = "fsl,imx-parallel-display"; ... port@1 { reg = <1>; parallel_out: endpoint { remote_endpoint = <&panel_in>; }; }; }; panel { ... port { panel_in: endpoint { remote-endpoint = <&parallel_out>; }; }; }; Signed-off-by: Philipp Zabel <[email protected]> Tested-by: Gary Bisson <[email protected]>
2015-07-10Merge tag 'omapdrm-4.2-fixes' of ↵Dave Airlie6-29/+49
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-fixes omapdrm fixes for 4.2 Small fixes for omapdrm, including: * Fix packed 24 bit color formats * Ensure the planes are inside the crtc * Handle out-of-dma-memory error * tag 'omapdrm-4.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: drm/omap: replace ALIGN(PAGE_SIZE) by PAGE_ALIGN drm/omap: fix align_pitch() for 24 bits per pixel drm/omap: fix omap_gem_put_paddr() error handling drm/omap: fix omap_framebuffer_unpin() error handling drm/omap: increase DMM transaction timeout drm/omap: check that plane is inside crtc drm/omap: return error if dma_alloc_writecombine fails
2015-07-10Merge tag 'drm-intel-fixes-2015-07-09' of ↵Dave Airlie4-14/+37
git://anongit.freedesktop.org/drm-intel into drm-fixes Pile of fixes for either 4.2 issues or cc: stable. This should fix the 2nd kind of WARNING Linus's been seeing, please ask him to scream if that's not the case. * tag 'drm-intel-fixes-2015-07-09' of git://anongit.freedesktop.org/drm-intel: Revert "drm/i915: Allocate context objects from stolen" drm/i915: Declare the swizzling unknown for L-shaped configurations drm/i915: Use crtc_state->active in primary check_plane func drm/i915: Check crtc->active in intel_crtc_disable_planes drm/i915: Restore all GGTT VMAs on resume drm/i915/chv: fix HW readout of the port PLL fractional divider
2015-07-10Merge tag 'drm-amdkfd-fixes-2015-07-09' of ↵Dave Airlie1-2/+7
git://people.freedesktop.org/~gabbayo/linux into drm-fixes A single fix so far for 4.2: - checking a pointer is not null before using it * tag 'drm-amdkfd-fixes-2015-07-09' of git://people.freedesktop.org/~gabbayo/linux: drm/amdkfd: validate pdd where it acquired first
2015-07-09drm/i915: fbdev restore mode needs to invalidate frontbufferRodrigo Vivi1-3/+12
This fbdev restore mode was another corner case that was now calling frontbuffer flip and flush and making we miss screen updates with PSR enabled. So let's also add the invalidate hack here while we don't have a reliable dirty fbdev op. v2: As pointed by Paulo: removed seg fault risk, used fb_helper when possible and put brackets on if. Cc: Paulo Zanoni <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Testcase: igt/kms_fbcon_fbt/psr Signed-off-by: Daniel Vetter <[email protected]>
2015-07-09drm/i915: fbdev_set_par reliably invalidating frontbufferRodrigo Vivi1-2/+1
fbdev_set_par is called when fbcon is taking over control. In the past frontbuffer was being invalidated on set_to_gtt_domain, but it moved to set_domain fixing that case, but left this behind and broken in commit 031b698a77a70a6c394568034437b5486a44e868 Author: Daniel Vetter <[email protected]> Date: Fri Jun 26 19:35:16 2015 +0200 drm/i915: Unconditionally do fb tracking invalidate in set_domain Note that even before this commit it wasn't perfect since the invalidate was omitted if the fbcon was already in the GTT domain, which it usually was. Since we are also invalidating in other fbdev cases this one was masked here. At least until now that I found this corner case: On boot with plymouth doing a splash screen when returning to the console frontbuffer wans't being invalidated causing missed screen updates with PSR enabled. So this patch fixes this issue. v2: Make invalidate directly and unconditionally and fix commit message indicating the set_domain fix as pointed out by Daniel. v3: Remove unecessary if(obj) added by mistake Cc: Paulo Zanoni <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> [danvet: Try to clarify commit message a bit and make it clear the referenced commit made this worse.] Signed-off-by: Daniel Vetter <[email protected]>
2015-07-09drm/i915: PSR: Increase idle_framesRodrigo Vivi1-2/+5
Idle frames the number of identical frames needed before panel can enter PSR. There are some panels that requires up to minimum of 4 idle frames available on the market. For these cases usually VBT should be used to configure the number of idle frames, but unfortunately this isn't always true and VBT isn't being set at all. Let's trust VBT when it is set + 1 and use minimum of 4 + 1 when VBT isn't set. "+1" covers the "of-by-one" case. Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-09drm/i915: PSR: Remove Low Power HW tracking mask.Rodrigo Vivi1-1/+1
By Spec we should only mask memup and hotplug detection for hardware tracking cases. However we always masked LPSP because with power well always enabled on audio PSR was never being activated and residency was always zeroed. Apparently audio driver is tying power well management and runtime PM for some reason. But with audio runtime PM working or with audio completely out of picture we should remove this mask, otherwise we have a high risk of miss screen updates as faced by Matthew. WARNING: With this patch if snd_intel_hda driver is running and not releasing power well properly PSR will constant Exit and Performance Counter will be 0. But the best thing of this patch is that with one more HW tracking working the risks of missed blank screen are minimized at most. This affects just core platforms where PSR exit are also helped by HW tracking: Haswell, Broadwell and Skylake for now. v2: Fix commit message explanation. It has nothing to do with runtime PM on i915 as previously advertised. Cc: Daniel Vetter <[email protected]> Cc: Matthew Garrett <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-09drm/i915: fix intel_frontbuffer_flip documentationPaulo Zanoni1-1/+0
Reported by the kbuild test robot. Regression introduced by: commit fdbff9282c0f5f61ffc87d57461b04d943250910 Author: Daniel Vetter <[email protected]> Date: Thu Jun 18 11:23:24 2015 +0200 drm/i915: Clear fb_tracking.busy_bits also for synchronous flips (I reviewed this commit, so it's also my fault) Signed-off-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-09drm/i915: intel_frontbuffer_flush can now be staticPaulo Zanoni2-6/+3
So make it static. Signed-off-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-09drm/i915: fix intel_fb_obj_flush documentationPaulo Zanoni1-0/+1
Reported by the kbuild test robot. Regression introduced by: commit de152b627eb3018de91ec5c5a50b38e17d80a88b Author: Rodrigo Vivi <[email protected]> Date: Tue Jul 7 16:28:51 2015 -0700 drm/i915: Add origin to frontbuffer tracking flush (I reviewed this commit, so it's also my fault) Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-09drm/radeon: disable vce init on cayman (v2)Alex Deucher1-11/+14
Cayman does not have vce. There were a few places in the shared cayman/TV code where we were trying to do vce stuff. v2: remove -ENOENT check Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.