aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2016-12-05drm/i915: Remove duplicated wm setup for vlv and chvVille Syrjälä1-4/+1
The code for vlv and chv wm latency/function pointer setup is identical. Drop one of the copies. Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Maarten Lankhorst <[email protected]>
2016-12-05drm/i915: Clean up VLV/CHV maxfifo watermark setupVille Syrjälä1-10/+2
Let's compute the maxfifo watermarks using max() instead of min(). Can't even recall why I did it the other way originally. Anyways using max() avoids having to initialize the watermarks to the max value first. Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Maarten Lankhorst <[email protected]>
2016-12-05drm/i915: Fix the level 0 max_wm hack on VLV/CHVVille Syrjälä1-2/+2
The watermark should never exceed the FIFO size, so we need to check against the current FIFO size instead of the theoretical maximum when we clamp the level 0 watermark. Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Maarten Lankhorst <[email protected]>
2016-12-05drm/i915: Use the ilk_disable_lp_wm() return valueVille Syrjälä1-3/+1
ilk_disable_lp_wm() will tell us whether the LP1+ watermarks were disabled or not, and hence whether we need to for the vblank wait or not. Let's use that information to eliminate some useless vblank waits. Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Maarten Lankhorst <[email protected]>
2016-12-05drm/i915: Drop the nop intel_update_watermarks() call from haswell_crtc_enable()Ville Syrjälä1-4/+1
HSW+ all use the .initial_watermarks() hook, so there's no point in calling intel_update_watermarks() from HSW+ specific code. We'll still hang on to the .initial_watermarks NULL check since theoretically if the memory latencies are not populated we would not populate the function pointer either. Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Maarten Lankhorst <[email protected]>
2016-12-05drm/i915: Validate mode against max. link data rate for DP MSTDhinakaran Pandiyan3-3/+15
Not validating the mode rate against max. link rate results in not pruning invalid modes. For e.g, a HBR2 5.4 Gbps 2-lane configuration does not support 4k@60Hz. But, we do not reject this mode. So, make use of the helpers in intel_dp to validate mode data rate against max. link data rate of a configuration. v3: Renamed local variables again for consistency (Manasi) v2: Renamed mode data rate local variable to be more explanatory. Signed-off-by: Dhinakaran Pandiyan <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]>
2016-12-05drm/i915: Fix DP link rate mathDhinakaran Pandiyan1-20/+15
We store DP link rates as link clock frequencies in kHz, just like all other clock values. But, DP link rates in the DP Spec. are expressed in Gbps/lane, which seems to have led to some confusion. E.g., for HBR2 Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 2160000 kBps where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion Using link clock frequency, like we do Max. data rate = 540000 kHz * 4 lanes = 2160000 kSymbols/s Because, each symbol has 8 bit of data, this is 2160000 kBps and there is no need to account for channel encoding here. But, currently we do 540000 kHz * 4 lanes * (8/10) = 1728000 kBps Similarly, while computing the required link bandwidth for a mode, there is a mysterious 1/10 term. This should simply be pixel_clock kHz * (bpp/8) to give the final result in kBps v2: Changed to DIV_ROUND_UP() and comment changes (Ville) Signed-off-by: Dhinakaran Pandiyan <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]>
2016-12-05drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependencyJavier Martinez Canillas1-1/+1
Commit aeefb36832e5 ("drm/exynos: gsc: add device tree support and remove usage of static mappings") made the DRM_EXYNOS_GSC Kconfig symbol to only be selectable if the exynos-gsc V4L2 driver isn't enabled, since both use the same HW IP block. But added the dependency as depends on !VIDEO_SAMSUNG_EXYNOS_GSC which is not correct since Kconfig expressions are not boolean but tristate. So it will only evaluate to 'n' if VIDEO_SAMSUNG_EXYNOS_GSC=y but will evaluate to 'm' if VIDEO_SAMSUNG_EXYNOS_GSC=m. This means that both the V4L2 and DRM drivers can be enabled if the former is enabled as a module, which isn't what we want since otherwise 2 drivers could attempt to use the hardware at the same time. Signed-off-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2016-12-05drm/exynos: gsc: fix spelling mistakesColin Ian King2-2/+2
Trivial fixes to spelling mistakes "precalser" to "prescaler" in dev_err messages Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2016-12-05exynos-drm: Fix error messages to print flags and sizeShuah Khan1-2/+2
Fix exynos_drm_gem_create() error messages to include flags and size when flags and size are invalid. Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2016-12-05drm/exynos/hdmi: refactor infoframe codeAndrzej Hajda2-101/+42
Use core helpers to generate infoframes and generate vendor frame if necessary. Changelog: - changed 'ret >= 0' checks to '!ret' Signed-off-by: Andrzej Hajda <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2016-12-05drm/i915: Add I2C and DP-AUX char devices to debug kconfigImre Deak1-0/+2
These char devices exposing the driver's I2C and DP-AUX adapters for user space tools are useful to debug display output related issues. Enable them with the rest of additional driver debug options. Suggested-by: Chris Wilson <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-12-05drm/i915: Move priority bumping for flips earlierChris Wilson1-1/+1
David found another issue with priority bumping from mmioflips, where we are accessing the requests concurrently to them being retired and freed. Whilst we are skipping the dependency if has been submitted, that is not sufficient to stop the dependency from disappearing if another thread retires that request. To prevent we can either employ the struct_mutex (or a request mutex in the future) to serialise retiring before it is freed. Alternatively, we need to keep the dependencies alive using RCU whilst they are being accessed via the DFS. [ 1746.698111] general protection fault: 0000 [#1] PREEMPT SMP [ 1746.698305] Modules linked in: snd_hda_intel snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_hda_core coretemp crct10dif_pclmul crc32_pclmul snd_pcm ghash_clmulni_intel mei_me mei i915 e1000e ptp pps_core i2c_hid [ 1746.698750] CPU: 1 PID: 6716 Comm: kworker/u8:2 Not tainted 4.9.0-rc6-CI-Nightly_816+ #1 [ 1746.698871] Hardware name: GIGABYTE GB-BKi7A-7500/MFLP7AP-00, BIOS F1 07/27/2016 [ 1746.699125] Workqueue: events_unbound intel_mmio_flip_work_func [i915] [ 1746.699266] task: ffff880260a5e800 task.stack: ffffc90000f6c000 [ 1746.699361] RIP: 0010:[<ffffffffa006595d>] [<ffffffffa006595d>] execlists_schedule+0x8d/0x300 [i915] [ 1746.699632] RSP: 0018:ffffc90000f6fcd8 EFLAGS: 00010206 [ 1746.699724] RAX: dead0000000000f8 RBX: ffff8801f64b2bf0 RCX: ffff8801f64b2c10 [ 1746.699842] RDX: dead000000000100 RSI: 0000000000000000 RDI: ffff8801f64b0458 [ 1746.699972] RBP: ffffc90000f6fd68 R08: ffff88026488dc00 R09: 0000000000000002 [ 1746.700090] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000400 [ 1746.700195] R13: ffffc90000f6fcf0 R14: ffff88020955aa40 R15: ffff88020955aa68 [ 1746.700307] FS: 0000000000000000(0000) GS:ffff88026dc80000(0000) knlGS:0000000000000000 [ 1746.700435] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1746.700532] CR2: 0000000002a69e90 CR3: 0000000002c07000 CR4: 00000000003406e0 [ 1746.700635] Stack: [ 1746.700682] ffff880260a5e880 ffffc90000f6fd50 ffffffff810af69a ffffc90000f6fd28 [ 1746.700827] ffff88020955a628 ffff8801e1eaebf0 0000000000000020 0000000000000000 [ 1746.700947] 00000196af1edc96 ffff88025dfa4000 ffff8801f0b030a8 ffffc90000f6fcf0 [ 1746.701071] Call Trace: [ 1746.701117] [<ffffffff810af69a>] ? dequeue_entity+0x25a/0xb50 [ 1746.701260] [<ffffffffa00516be>] fence_set_priority+0x7e/0x80 [i915] [ 1746.701406] [<ffffffffa0051a15>] i915_gem_object_wait_priority+0x85/0x160 [i915] [ 1746.701599] [<ffffffffa008ccd7>] intel_mmio_flip_work_func+0x47/0x2b0 [i915] [ 1746.701717] [<ffffffff81094c4d>] process_one_work+0x14d/0x470 [ 1746.701809] [<ffffffff81094fb3>] worker_thread+0x43/0x4e0 [ 1746.701888] [<ffffffff81094f70>] ? process_one_work+0x470/0x470 [ 1746.701969] [<ffffffff81094f70>] ? process_one_work+0x470/0x470 [ 1746.702072] [<ffffffff8109a4d5>] kthread+0xc5/0xe0 [ 1746.702152] [<ffffffff81771c59>] ? _raw_spin_unlock_irq+0x9/0x10 [ 1746.702234] [<ffffffff8109a410>] ? kthread_park+0x60/0x60 [ 1746.702318] [<ffffffff81772272>] ret_from_fork+0x22/0x30 [ 1746.702387] Code: 89 42 08 48 8b 45 88 48 89 55 c0 4c 89 6d c8 4c 8d 70 d8 4d 8d 7e 28 4d 39 ef 74 72 49 8b 1e 48 8b 13 48 39 d3 48 8d 42 f8 74 3e <48> 8b 10 8b 52 38 41 39 d4 7e 26 48 8b 50 30 48 8b 78 28 48 8d [ 1746.702921] RIP [<ffffffffa006595d>] execlists_schedule+0x8d/0x300 [i915] Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.703027] RSP <ffffc90000f6fcd8> Fixes: 27745e829a5c ("drm/i915/execlists: Use a local lock for dfs_link access") Fixes: 9a151987d709 ("drm/i915: Add execution priority boosting for mmioflips") Signed-off-by: Chris Wilson <[email protected]> Cc: David Weinehall <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Tvrtko Ursulin <[email protected]> (cherry picked from commit 92117f0bce64268b841261774e45462cc7ff80af) Signed-off-by: Jani Nikula <[email protected]>
2016-12-05drm/i915: Hold a reference on the request for its fence chainChris Wilson2-7/+32
Currently, we have an active reference for the request until it is retired. Though it cannot be retired before it has been executed by hardware, the request may be completed before we have finished processing the execute fence, i.e. we may continue to process that fence as we free the request. Fixes: 5590af3e115a ("drm/i915: Drive request submission through fence callbacks") Fixes: 23902e49c999 ("drm/i915: Split request submit/execute phase into two") Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 48bc2a4a427ad81578f887d71d45794619a77211) Signed-off-by: Jani Nikula <[email protected]>
2016-12-05drm/i915/audio: fix hdmi audio noise issueLibin Yang1-2/+5
Some monitors will have noise or even no sound after applying the patch 6014ac12. In patch 6014ac12, it will reset the cts value to 0 for HDMI. However, we need to disable Enable CTS or M Prog bit. This is the initial setting after HW reset. Fixes: 6014ac122ed0 ("drm/i915/audio: set proper N/M in modeset") Signed-off-by: Libin Yang <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 60abfbb86a8d51576f90c5adcbb4f547a2952782) Signed-off-by: Jani Nikula <[email protected]>
2016-12-05drm/i915/debugfs: Increment return value of gt.next_seqnoChris Wilson1-1/+1
The i915_next_seqno read value is to be the next seqno used by the kernel. However, in the conversion to atomics ops for gt.next_seqno, in commit 28176ef4cfa5 ("drm/i915: Reserve space in the global seqno during request allocation"), this was changed from a post-increment to a pre-increment. This increment was missed from the value reported by debugfs, so in effect it was reporting the current seqno (last assigned), not the next seqno. Fixes: 28176ef4cfa5 ("drm/i915: Reserve space in the global seqno during request allocation") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81209 Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Joonas Lahtinen <[email protected]> (cherry picked from commit 9607ae79710afb453173b90d5bf564788a6e09b1) Signed-off-by: Jani Nikula <[email protected]>
2016-12-05drm/i915/debugfs: Drop i915_hws_infoChris Wilson1-25/+0
i915_hws_info() has not been kept upto date (missing new engines) and so I consider it to be unused. HWS is included in the error state, which would be an avenue to retrieving it if required in future (possibly via i915_engine_info). As it is currently oopsing with an rpm testcase, just remove it. Fixes: 3b3f1650b1ca ("drm/i915: Allocate intel_engine_cs structure only for the enabled engines") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98838 Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Tvrtko Ursulin <[email protected]> (cherry picked from commit 30576a2c462d9658508c3de67601aa565f973064) Signed-off-by: Jani Nikula <[email protected]>
2016-12-05drm/i915: Initialize dev_priv->atomic_cdclk_freq at init timeVille Syrjälä1-0/+1
Looks like we're only initializing dev_priv->atomic_cdclk_freq at resume and commit times, not at init time. Let's do that as well. We're now hitting the 'WARN_ON(intel_state->cdclk == 0)' in hsw_compute_linetime_wm() on account of populating intel_state->cdclk from dev_priv->atomic_cdclk_freq. Previously we were mispopulating intel_state->cdclk with dev_priv->cdclk_freq which always had a proper value at init time and hence the WARN_ON() didn't trigger. Cc: <[email protected]> # 4.6+: 14676ec6b1a6 drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things Cc: <[email protected]> # 4.6+ Cc: Matthew Auld <[email protected]> Reported-by: Matthew Auld <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98902 Fixes: 14676ec6b1a6 ("drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things") Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Tested-by: Matthew Auld <[email protected]> Reviewed-by: Matthew Auld <[email protected]> (cherry picked from commit 6a259b1f8a9e99b1ed114f8bf8b0cfccee130e54) Signed-off-by: Jani Nikula <[email protected]>
2016-12-05drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing thingsVille Syrjälä1-3/+5
When we end up not recomputing the cdclk, we need to populate intel_state->cdclk with the "atomic_cdclk_freq" instead of the current cdclk_freq. When no pipes are active, the actual cdclk_freq may be lower than what the configuration of the planes and pipes would require from the point of view of the software state. This fixes bogus WARNS from skl_max_scale() which is trying to check the plane software state against the cdclk frequency. So any time it got called during DPMS off for instance, we might have tripped the warn if the current mode would have required a higher than minimum cdclk. v2: Drop the dev_cdclk stuff (Maarten) Cc: Maarten Lankhorst <[email protected]> Cc: Mika Kahola <[email protected]> Cc: [email protected] Cc: Daniel J Blueman <[email protected]> Cc: Paul Bolle <[email protected]> Cc: Joseph Yasi <[email protected]> Tested-by: Paul Bolle <[email protected]> Tested-by: Joseph Yasi <[email protected]> (v1) Cc: <[email protected]> # v4.6+ Fixes: 1a617b77658e ("drm/i915: Keep track of the cdclk as if all crtc's were active.") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98214 Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit e0ca7a6be38ce603d26df5707c22e53870a623e0) Signed-off-by: Jani Nikula <[email protected]>
2016-12-05Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queuedDaniel Vetter227-2872/+12890
Resync, and we need all the fancy new drm_mm stuff to implement more efficient evict algorithms for softpin. Signed-off-by: Daniel Vetter <[email protected]>
2016-12-05drm/i915: Make skl_write_{plane,cursor}_wm() staticVille Syrjälä1-7/+7
Someone forgot to make skl_write_{plane,cursor}_wm() static when removing the prototypes from the header. Sparse isn't pleased. Cc: Maarten Lankhorst <[email protected]> Cc: Lyude <[email protected]> Cc: Matt Roper <[email protected]> Fixes: e62929b3f628 ("drm/i915/gen9+: Program watermarks as a separate step during evasion, v3.") Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Lyude <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> (cherry picked from commit d9348dec902ff36e0f1b25ccf1f4be25fc1ac409) Signed-off-by: Jani Nikula <[email protected]>
2016-12-05drm/i915: Complete requests in nop_submit_requestChris Wilson1-0/+2
Since the submit/execute split in commit d55ac5bf97c6 ("drm/i915: Defer transfer onto execution timeline to actual hw submission") the global seqno advance was deferred until the submit_request callback. After wedging the GPU, we were installing a nop_submit_request handler (to avoid waking up the dead hw) but I had missed converting this over to the new scheme. Under the new scheme, we have to explicitly call i915_gem_submit_request() from the submit_request handler to mark the request as on the hardware. If we don't the request is always pending, and any waiter will continue to wait indefinitely and hangcheck will not be able to resolve the lockup. References: https://bugs.freedesktop.org/show_bug.cgi?id=98748 Testcase: igt/gem_eio/in-flight Fixes: d55ac5bf97c6 ("drm/i915: Defer transfer onto execution timeline to actual hw submission") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 3dcf93f7f23a61e867a5ccadaf651cb2d29229fd) Signed-off-by: Jani Nikula <[email protected]>
2016-12-05drm/i915: Update DRIVER_DATE to 20161205Daniel Vetter1-2/+2
Signed-off-by: Daniel Vetter <[email protected]>
2016-12-05drm/qxl: Don't register debugfs for control minorsDaniel Vetter1-6/+0
They're gone since 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"). Spotted while doing a full audit when revieng a similar patch from Nicolai for radeon. v2: Drink coffee first aka don't forget the unregister side. Cc: Dave Airlie <[email protected]> Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes") Cc: Nicolai Stange <[email protected]> Acked-by: Dave Airlie <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-12-05drm/radeon: don't add files at control minor debugfs directoryNicolai Stange1-6/+0
Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a struct drm_device's ->control member is always NULL. In the case of CONFIG_DEBUG_FS=y, radeon_debugfs_add_files() accesses ->control->debugfs_root though. This results in the following Oops: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 IP: radeon_debugfs_add_files+0x90/0x100 [radeon] PGD 0 Oops: 0000 [#1] SMP [...] Call Trace: ? work_on_cpu+0xb0/0xb0 radeon_fence_driver_init+0x120/0x150 [radeon] si_init+0x122/0xd50 [radeon] ? _raw_spin_unlock_irq+0x2c/0x40 ? device_pm_check_callbacks+0xb3/0xc0 radeon_device_init+0x958/0xda0 [radeon] radeon_driver_load_kms+0x9a/0x210 [radeon] drm_dev_register+0xa9/0xd0 [drm] drm_get_pci_dev+0x9c/0x1e0 [drm] radeon_pci_probe+0xb8/0xe0 [radeon] [...] Fix this by omitting the drm_debugfs_create_files() call for the control minor debugfs directory which is now non-existent anyway. Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes") Signed-off-by: Nicolai Stange <[email protected]> Acked-by: Dave Airlie <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-12-05Backmerge tag 'v4.9-rc8' into drm-nextDave Airlie25-253/+227
Linux 4.9-rc8 Daniel requested this so we could apply some follow on fixes cleanly to -next.
2016-12-04don't open-code file_inode()Al Viro3-13/+13
Signed-off-by: Al Viro <[email protected]>
2016-12-04Merge tag 'drm-intel-fixes-2016-12-01' of ↵Dave Airlie2-3/+5
git://anongit.freedesktop.org/git/drm-intel into drm-fixes 2 intel fixes. * tag 'drm-intel-fixes-2016-12-01' of git://anongit.freedesktop.org/git/drm-intel: drm/i915: drop the struct_mutex when wedged or trying to reset drm/i915: Don't touch NULL sg on i915_gem_object_get_pages_gtt() error
2016-12-02drm/i915: Only poll DW3_A when init DDI PHY for ports B and C.Rodrigo Vivi1-12/+3
According to Bspec we need to "Poll for PORT_REF_DW3_A grc_done == 1b" only on ports B and C initialization sequence when copying rcomp from port A. So let's follow the spec and only poll for that case and not on every port A initialization. v2: Also remove the grc_done check from bxt_ddi_phy_is_enabled() otherwise it might believe it is disabled and force it to re program. Cc: Imre Deak <[email protected]> Cc: Ander Conselvan de Oliveira <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: Imre Deak <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-12-02drm/etnaviv: move linear window on MC1.0 parts if necessaryLucas Stach1-0/+4
On i.MX6SX the physical memory is placed above the 2GB mark, so the GPU linear window has to be moved for the GPU to work at all. This doesn't mix with the FAST_CLEAR feature, as the TS unit doesn't take the linear window offset into account and will corrupt memory when used with a non-zero offset. Move the linear window if it's necessary for the GPU to work, but avoid announcing FAST_CLEAR support to userspace in this case. Signed-off-by: Lucas Stach <[email protected]> Tested-by: Marek Vasut <[email protected]>
2016-12-02drm/etnaviv: don't invoke OOM killer from dump codeLucas Stach1-1/+2
The dumper is only a debugging aid so we don't want to invoke the OOM killer if buffer for the potentially large GPU state can't be vmalloced. Signed-off-by: Lucas Stach <[email protected]>
2016-12-02drm/etnaviv: fix gem_prime_get_sg_table to return new SG tableLucas Stach1-2/+4
The object internal SG table must not be returned, as the caller will take ownership of the returned table. Construct a new table from the object pages and return this one instead. Signed-off-by: Lucas Stach <[email protected]>
2016-12-02drm/etnaviv: Allow DRAW_INSTANCED commandsWladimir J. van der Laan2-4/+57
Vivante GPUs with HALTI0 feature support a DRAW_INSTANCED command in the command stream to draw a number of instances of the same geometry. The information that has been figured out about the command can be found here: https://github.com/etnaviv/etna_viv/blob/master/rnndb/cmdstream.xml#L270 This command is not allowed currently by the DRM driver because it was not known before. This patch enables parsing it in command streams and allows using it by userspace drivers. Signed-off-by: Wladimir J. van der Laan <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2016-12-02drm/etnaviv: implement dma-buf mmapLucas Stach3-0/+16
This adds the required boilerplate to allow direct mmap of exported etnaviv BOs. Signed-off-by: Lucas Stach <[email protected]> Tested-by: Philipp Zabel <[email protected]>
2016-12-02drm/vmwgfx: Switch to mode_cmd2Daniel Vetter3-84/+53
Surprisingly few changes needed to make it happen. Compile-tested only. The idea is that this replaces the 2 patches from Ville's big fb->format patch series as a prep patch. Only impact to later patches should be the one instace added in this patch where we look at fb->pixel_format (instead of fb->bpp and fb->depth), so minor adjustements in the cocci-generated patches needed. v2: Restore pitch computation in vmw_fb_kms_framebuffer (Sinclair). Cc: [email protected] Cc: Laurent Pinchart <[email protected]> Cc: [email protected] Cc: Sinclair Yeh <[email protected]> Cc: Thomas Hellstrom <[email protected]> Reviewed-by: Sinclair Yeh <[email protected]> Acked-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-12-02drm/vgem: Use ww_mutex_(un)lock even with a NULL contextNicolai Hähnle1-2/+2
v2: use resv->lock instead of resv->lock.base (Christian König) Cc: Peter Zijlstra <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Chris Wilson <[email protected]> Cc: [email protected] Signed-off-by: Nicolai Hähnle <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-12-02drm/i915/glk: Configure number of sprite planes properlyAnder Conselvan de Oliveira1-1/+4
Geminilake has 4 planes (3 sprites) per pipe. Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-10-git-send-email-ander.conselvan.de.oliveira@intel.com
2016-12-02drm/i915/glk: Implement core display init/uninit sequence for geminilakeAnder Conselvan de Oliveira1-2/+2
The sequence is pretty much the same as broxton, except that bspec requires the AUX domains to be enabled. But since those can't be enabled before the phys are initialized, we just use the same sequence as broxton. v2: Don't manually enable AUX domains. (Ander) Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-9-git-send-email-ander.conselvan.de.oliveira@intel.com
2016-12-02drm/i915/glk: Allow dotclock up to 2 * cdclk on geminilakeAnder Conselvan de Oliveira1-4/+6
Geminilake has double wide pipes so it can output two pixels per CD clock. Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-8-git-send-email-ander.conselvan.de.oliveira@intel.com
2016-12-02drm/i915/glk: Reuse broxton's cdclk code for GLKAnder Conselvan de Oliveira1-8/+65
Geminilake has the same register layout, reference clock and programming sequence as broxton. The difference is that it doesn't support the 1.5 divider and has different ratios, but a lot of code can be shared between the two platforms. v2: Rebase (s/broxton/bxt). v3: Fix vco calculation in glk_de_pll_vco(). Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-7-git-send-email-ander.conselvan.de.oliveira@intel.com
2016-12-02drm/i915/glk: Update Port PLL enable sequence for GeminilkaeMadhav Chauhan2-0/+22
Add steps for enabling and disabling Port PLL as per bspec. Signed-off-by: Madhav Chauhan <[email protected]> Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-6-git-send-email-ander.conselvan.de.oliveira@intel.com
2016-12-02drm/i915/glk: Set DCC delay range 2 in PLL enable sequenceAnder Conselvan de Oliveira2-0/+21
Follow the PLL enable sequence updated in bspec, which requires the DCC delay range 2 bit to be set. v2: Moved from DDI init sequence to PLL enable. v3: Don't read value from GRP register. (Rodrido) Cc: Rodrigo Vivi <[email protected]> Signed-off-by: Ander Conselvan De Oliveira <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-5-git-send-email-ander.conselvan.de.oliveira@intel.com
2016-12-02drm/i915/glk: Implement Geminilake DDI init sequenceAnder Conselvan de Oliveira5-24/+155
Implement the DDI initsequence and add information about the different phys in GLK. v2: Rebase on the move of phys to be power wells. v3: Rebase on addition of struct bxt_ddi_phy_info. Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-4-git-send-email-ander.conselvan.de.oliveira@intel.com
2016-12-02drm/i915/glk: Add power wells for GeminilakeAnder Conselvan de Oliveira2-3/+117
Geminilake has power wells are similar to SKL, but with the misc IO well being split into separate AUX IO wells. Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-3-git-send-email-ander.conselvan.de.oliveira@intel.com
2016-12-02drm/i915/glk: Reuse broxton code for geminilakeAnder Conselvan de Oliveira18-85/+84
Geminilake is mostly backwards compatible with broxton, so change most of the IS_BROXTON() checks to IS_GEN9_LP(). Differences between the platforms will be implemented in follow-up patches. v2: Don't reuse broxton's path in intel_update_max_cdclk(). Don't set plane count as in broxton. v3: Rebase v4: Include the check intel_bios_is_port_hpd_inverted(). Commit message. v5: Leave i915_dmc_info() out; glk's csr version != bxt's. (Rodrigo) v6: Rebase. v7: Convert a few mode IS_BROXTON() occurances in pps, ddi, dsi and pll code. (Rodrigo) v8: Squash a couple of DDI patches with more conversions. (Rodrigo) Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-2-git-send-email-ander.conselvan.de.oliveira@intel.com
2016-12-02drm/i915/gen6+: Clear upper data byte during PCODE writeImre Deak1-0/+1
The spec calls for the upper data byte to be cleared before most of the PCODE write commands, for others like IPS control it doesn't say anything about this byte. Let's clear it in case it's clobbered somehow, especially that there are places where we only do a PCODE write without a preceding PCODE read. Cc: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-12-02Merge tag 'gvt-next-2016-11-30' of https://github.com/01org/gvt-linux into ↵Jani Nikula3-4/+9
drm-intel-next-fixes From Zhenyu Wang <[email protected]> gvt-next-2016-11-30 - initialize vgpu as primary for correct cfg space setting - fix 64 bit bar emulation - fix un-released lock issue on dispatch workload err path Signed-off-by: Jani Nikula <[email protected]>
2016-12-02drm/i915/audio: extend audio sync rate support for DP MSTLibin Yang1-3/+1
Remove the type judgement in i915_audio_component_sync_audio_rate(). Audio rate sync is necessary for all i915 digital audio now. Signed-off-by: Libin Yang <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-12-02drm/i915/audio: extend get_saved_enc() to support more scenariosLibin Yang1-4/+28
In initialization, audio driver will call functions get_eld() and etc. But at that time, audio driver may not know whether it is DP MST or not. In the original function get_saved_enc(), if it is DP MST, it requires to set the pipe to the correct value, otherwise, pipe to be -1. Although audio driver can get the knowledge whether it is in DP MST mode or not by reading the codec register. It will drop performance each time before it calls the get_eld and other similar functions. As gfx driver can easily know whether it is in DP MST mode or not. Let's extend the get_saved_enc() function to handle the situation that audio driver still sends the device id info even it is in DP SST mode and return the correct intel_encoder instead of panic. Signed-off-by: Libin Yang <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-12-02drm/i915: make i915_suspend_switcheroo staticMatthew Auld1-1/+1
Looks like this was missed when unexporting, so let's keep sparse happy. Cc: Tvrtko Ursulin <[email protected]> Fixes: 7f26cb88014a ("drm/i915: Unexport VGA switcheroo functions") Signed-off-by: Matthew Auld <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.