- 15 Jun, 2015 32 commits
-
-
Paulo Zanoni authored
This commit has two main advantages: simplify intel_fbc_update() and deduplicate the strings. v2: - Rebase due to changes on P1. - set_no_fbc_reason() can now return void (Chris). Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Because we're currently using FBC_UNSUPPORTED_MODE for two different cases. This commit will also allow us to write the next one without hiding information from the user. Signed-off-by:
-
Paulo Zanoni authored
We already had a few bugs in the past where FBC was compressing nothing when it was enabled, which makes the feature quite useless. Add this information to debugfs so the test suites can check for regressions in this piece of the code. Our igt/tests/kms_frontbuffer_tracking already has support for this message. v2: - Remove pointless VLV check (Ville). Signed-off-by:
-
Ville Syrjälä authored
The docs don't support the 64k linear scanout alignment we impose on gen2/3. And it really makes no sense since we have no DSPSURF register, so the only thing that the hardware will see is the linear offset which will be just pixel aligned anyway. There is one case where 64k comes into the picture, and that's FBC. The start of the line length buffer corresponds to a 64k aligned address of the uncompressed framebuffer. So if the uncompressed fb is not 64k aligned, the first actually used entry in the line length buffer will not be byte 0. There are 32 extra entries in the line length buffer to account for this extra alignment so we shouldn't have to worry about it when mapping the uncompressed fb to the GTT. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
VLV/CHV have problems with 4k aligned linear scanout buffers. The VLV docs got updated at some point to say that we need to align them to 128k, just like we do on gen4. So far I've seen the problem manifest when the stride is an odd multiple of 512 bytes, and the surface address meets the following pattern '(addr & 0xf000) == 0x1000' (also == 0x2000 is problematic on VLV). The result is a starcase effect (so some pages get dropped maybe?), with a few pages here and there clearly getting scannout out at the wrong position. I've not actually been able to reproduce this problem on gen4, so it's not clear of the issue is any way related to the 128k restrictions supposedly inherited from gen4. But let's hope the 128k alignment is sufficient to hide it all. Signed-off-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Reviewed-by:
Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Currently intel_gen4_compute_page_offset() simply picks the closest page boundary below the linear offset. That however may not be suitably aligned to satisfy any hardware specific restrictions. So let's make sure the page boundary we choose is properly aligned. Also to play it a bit safer lets split the remaining linear offset into x and y values instead of just x. This should make no difference for most platforms since we convert the x and y offsets back into a linear offset before feeding them to the hardware. HSW+ are different however and use x and y offsets even with linear buffers, so they might have trouble if either the x or y get too big. Signed-off-by:
-
Chandra Konduru authored
Delete the duplicate #defines introduced by: commit 6b457d31 Author: A.Sunil Kamath <sunil.kamath@intel.com> Date: Thu Apr 16 14:22:09 2015 +0530 drm/i915/skl: Implement enable/disable for Display C5 state. Signed-off-by:
Chandra Konduru <chandra.konduru@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Ramalingam C authored
Corrected the documentation on the intel_edp_drrs_flush and intel_edp_drrs_invalidate. And accordingly edp_drrs_flush function is modified to restart the idleness detection after upclocking. v2: Update kerneldoc Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (v1) Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Signed-off-by:
-
Daniel Vetter authored
The i915 atomic conversion is a real beast and it's not getting easier wrangling in a separate branch. I'm might be regretting this, but right after vacation nothing can burst my little bubble here! Signed-off-by:Daniel Vetter <daniel.vetter@intel.com>
-
Chris Wilson authored
In igt, we want to test handling of GPU hangs, both for recovery purposes and for reporting. However, we don't want to inject a genuine GPU hang onto a machine that cannot recover and so be permenantly wedged. Rather than embed heuristics into igt, have the kernel report exactly when it expects the GPU reset to work. This can also be usefully extended in future to indicate different levels of fine-grained resets. Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_runtime_pm_status’: drivers/gpu/drm/i915/i915_debugfs.c:2528:34: error: ‘struct dev_pm_info’ has no member named ‘usage_count’ atomic_read(&dev->dev->power.usage_count)); Regression from commit a6aaec8b Author: Damien Lespiau <damien.lespiau@intel.com> Date: Thu Jun 4 18:23:58 2015 +0100 drm/i915: Add runtime PM's usage_count in i915_runtime_pm_status Signed-off-by: -
Damien Lespiau authored
I noticed one of those and it turned out we have a few lingering around. Signed-off-by:
-
Damien Lespiau authored
It's handy to have debug message for the "big" events and this one qualifies IMHO. Also helpful to see what's happening while we're loading the firwmare and how much time it takes. Signed-off-by:
-
Damien Lespiau authored
In Linux, macros are usually well done and protect their arguments properly, even avoiding multiple evaluations of the parameters. Extra () are really not needed. Cc: Suketu Shah <suketu.j.shah@intel.com> Signed-off-by:
-
Francisco Jerez authored
Only bit 27 of SCRATCH1 and bit 6 of ROW_CHICKEN3 are allowed to be set because of security-sensitive bits we don't want userspace to mess with. On HSW hardware the whitelisted bits control whether atomic read-modify-write operations are performed on L3 or on GTI, and when set to L3 (which can be 10x-30x better performing than on GTI, depending on the application) require great care to avoid a system hang, so we currently program them to be handled on GTI by default. Beignet can immediately start taking advantage of this change to enable L3 atomics. Mesa should eventually switch to L3 atomics too, but a number of non-trivial changes are still required so it will continue using GTI atomics for now. Signed-off-by:
Francisco Jerez <currojerez@riseup.net> Reviewed-by:
Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by:
-
Francisco Jerez authored
In some cases it might be unnecessary or dangerous to give userspace the right to write arbitrary values to some register, even though it might be desirable to give it control of some of its bits. This patch extends the register whitelist entries to contain a mask/value pair in addition to the register offset. For registers with non-zero mask, any LRM writes and LRI writes where the bits of the immediate given by the mask don't match the specified value will be rejected. This will be used in my next patch to grant userspace partial write access to some sensitive registers. Signed-off-by:
-
Francisco Jerez authored
Until now the software command checker assumed that commands could read or write at most a single register per packet. This is not necessarily the case, MI_LOAD_REGISTER_IMM expects a variable-length list of offset/value pairs and writes them in sequence. The previous code would only check whether the first entry was valid, effectively allowing userspace to write unrestricted registers of the MMIO space by sending a multi-register write with a legal first register, with potential security implications on Gen6 and 7 hardware. Fix it by extending the drm_i915_cmd_descriptor table to represent multi-register access and making validate_cmd() iterate for all register offsets present in the command packet. Signed-off-by:
-
Ville Syrjälä authored
Switch from using 31 PFI credits to 63 PFI credits when cdclk>=czclk on CHV. The spec lists both 31 and 63 as "suggested" values, but based on feedback from hardware folks we should actually be using 63. Originally I picked the 31 basically by flipping a coin. Signed-off-by:
-
Thomas Richter authored
This patch fixes the resume from suspend-to-ram on the IBM X30 laptop. The problem is caused by the Bios missing to re-initialize the iVCH registers, especially the PLL registers. This patch records the iVCH registers during initialization, and re-installs this register set when resuming. Signed-off-by:
Thomas Richter <thor@math.tu-berlin.de> Signed-off-by:
-
Mika Kuoppala authored
We are always allocating a single page. No need to be verbose so remove the suffix. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
-
Mika Kuoppala authored
Free the scratch page if dma mapping fails. Signed-off-by:
-
Imre Deak authored
The divider value to convert from CZ clock rate to ms needs a +1 adjustment on VLV just like on CHV. This matches both the spec and the accuracy test by pm_rc6_residency. v2: - simplify logic checking for the CHV 320MHz special case (Rodrigo) Testcase: igt/pm_rc6_residency Signed-off-by:
Imre Deak <imre.deak@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76877Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Currently we're forgetting to double the port clock when using double clocked modes with 12bpc on HDMI. We're only accounting for the 1.5x factor due to the 12bpc. So further double the 1.5x port clock when we have a double clocked mode. Unfortunately I don't have any displays that support both 12bpc and double clocked modes, so I was unable to test this. Signed-off-by:
-
Ville Syrjälä authored
Account for the pixel multiplier when reading out the HDMI mode dotclock. Makes the state checked happier on my ILK when using double clocked modes. Signed-off-by:
-
Ville Syrjälä authored
Check that the DIP is enabled on the right port on IBX and VLV/CHV as we're doing on g4x, and also check for all the infoframe enable bits on all platforms. Eventually we should track each infoframe type independently, and also their contents. This is a small step in that direction as .infoframe_enabled() return value could be easily turned into a bitmask. Signed-off-by:
-
Ville Syrjälä authored
Currently we just disable the GCP infoframe when turning off the port. That means if the same transcoder is used on a DP port next, we might end up pushing infoframes over DP, which isn't intended. Just disable all the infoframes when turning off the port. Also protect against two ports stomping on each other on g4x due to the single video DIP instance. Now only the first port to enable gets to send infoframes. v2: Rebase Signed-off-by:
-
Ville Syrjälä authored
Follow the procedure listed in Bspec to toggle the port enable bit off and on when enabling HDMI with 12bpc and pixel repeat on IBX. The old code didn't actually enable the port before "toggling" the bit back off, so the whole workaround was essentially a nop. Also take the opportunity to clarify the code by splitting the gmch platforms to a separate (much more straightforward) function. v2: Rebased due to crtc->config changes Signed-off-by:
-
Ville Syrjälä authored
IBX BSpec says we must specify 8bpc in TRANSCONF for both 8bpc and 12bpc HDMI output. Do so. v2: Pass intel_crtc to intel_pipe_has_type() Signed-off-by:
-
Ville Syrjälä authored
When the video timings are suitably aligned so that all different periods start at phase 0 (ie. none of the periods start mid-pixel) we can inform the sink about this. Supposedly the sink can then optimize certain things. Obviously this is only relevant when outputting >8bpc data since otherwise there are no mid-pixel phases. v2: Rebased due to crtc->config changes Signed-off-by:
-
Ville Syrjälä authored
GCP infoframes are required to inform the HDMI sink about the color depth. Send the GCP infoframe whenever the sink supports any deep color modes since such sinks must anyway be capable of receiving them. For sinks that don't support deep color let's skip the GCP in case it might confuse the sink, although HDMI 1.4 spec does say all sinks must be capable of reciving them. In theory we could skip the GCP infoframe for deep color sinks in 8bpc mode as well since sinks must fall back to 8bpc whenever GCP isn't received for some time. BSpec says we should disable GCP after disabling the port, so do that as well. v2: s/intel_set_gcp_infoframe/intel_hdmi_set_gcp_infoframe/ Rebased due to crtc->config changes Signed-off-by:Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
CPT/PPT require a specific procedure for enabling 12bpc HDMI. Implement it, and to keep things neat pull the code into a function. v2: Rebased due to crtc->config changes s/HDMI_GC/HDMIUNIT_GC/ to match spec better Factor out intel_enable_hdmi_audio() Signed-off-by: -
Daniel Vetter authored
Pull in patches Jani applied while I was on vacation. Signed-off-by:
-
- 12 Jun, 2015 8 commits
-
-
Maarten Lankhorst authored
The cursor should only be enabled if it's visible. This fixes igt/kms_cursor_crc, which may otherwise produce the following warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 3425 at drivers/gpu/drm/i915/intel_display.c:9995 intel_crtc_update_cursor+0x14c/0x4d0 [i915]() Missing switch case (0) in i9xx_update_cursor Modules linked in: i915 CPU: 0 PID: 3425 Comm: kms_cursor_crc Tainted: G W 4.1.0-rc7-patser+ #4079 Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014 ffffffffc01aad10 ffff8800b083faa8 ffffffff817f7827 0000000080000001 ffff8800b083faf8 ffff8800b083fae8 ffffffff81084955 ffff8800b083fad8 ffff8800c4931148 0000000001200000 ffff8800c48b0000 0000000000000000 Call Trace: [<ffffffff817f7827>] dump_stack+0x4f/0x7b [<ffffffff81084955>] warn_slowpath_common+0x85/0xc0 [<ffffffff810849d1>] warn_slowpath_fmt+0x41/0x50 [<ffffffffc0139f2c>] intel_crtc_update_cursor+0x14c/0x4d0 [i915] [<ffffffffc01497f4>] __intel_set_mode+0x6c4/0x750 [i915] [<ffffffffc0150143>] intel_crtc_set_config+0x473/0x5c0 [i915] [<ffffffff81467da9>] drm_mode_set_config_internal+0x69/0x120 [<ffffffff8146c1b9>] drm_mode_setcrtc+0x189/0x540 [<ffffffff8145c7e0>] drm_ioctl+0x1a0/0x6a0 [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50 [<ffffffff811e9c28>] do_vfs_ioctl+0x2f8/0x530 [<ffffffff810d0f7d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff812e7746>] ? selinux_file_ioctl+0x56/0x100 [<ffffffff811e9ee1>] SyS_ioctl+0x81/0xa0 [<ffffffff81801617>] system_call_fastpath+0x12/0x6f ---[ end trace abf0f71163290a96 ]--- Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Maarten Lankhorst authored
This was introduced after converting hw readout to atomic, so it should have been part of the revert too. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90929Reported-by:
-
Maarten Lankhorst authored
Use a full atomic call instead. intel_crtc_page_flip will still have to live until async updates are allowed. This doesn't seem to be a regression from the convert to atomic, part 3 patch. During GPU reset it fixes the following warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 752 at drivers/gpu/drm/drm_crtc.c:5337 drm_mode_page_flip_ioctl+0x27b/0x360() Modules linked in: i915 CPU: 0 PID: 752 Comm: Xorg Not tainted 4.1.0-rc7-patser+ #4090 Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015 ffffffff81c90866 ffff8800d87c3ca8 ffffffff817f7d87 0000000080000001 0000000000000000 ffff8800d87c3ce8 ffffffff81084955 ffff880000000000 ffff8800d87c3dc0 ffff8800d93d1208 0000000000000000 ffff8800b7d1f3e0 Call Trace: [<ffffffff817f7d87>] dump_stack+0x4f/0x7b [<ffffffff81084955>] warn_slowpath_common+0x85/0xc0 [<ffffffff81084a35>] warn_slowpath_null+0x15/0x20 [<ffffffff8146dffb>] drm_mode_page_flip_ioctl+0x27b/0x360 [<ffffffff8145ccb0>] drm_ioctl+0x1a0/0x6a0 [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50 [<ffffffff812e5540>] ? avc_has_perm+0x20/0x280 [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50 [<ffffffff811ea0f8>] do_vfs_ioctl+0x2f8/0x530 [<ffffffff811f6001>] ? expand_files+0x261/0x270 [<ffffffff812e7c16>] ? selinux_file_ioctl+0x56/0x100 [<ffffffff811ea3b1>] SyS_ioctl+0x81/0xa0 [<ffffffff81801b97>] system_call_fastpath+0x12/0x6f ---[ end trace 9ce834560085bd64 ]--- Signed-off-by:
-
Maarten Lankhorst authored
This should fix fallout caused by making intel_crtc_control and update_dpms atomic, which became a problem after reverting the atomic hw readout patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90929Reported-by:
-
Maarten Lankhorst authored
This reverts commit 3bae26eb2991c00670df377cf6c3bc2b0577e82a. Seems it introduces regressions for 3 different reasons, oh boy.. In bug #90868 as I can see the atomic state will be restored on resume without the planes being set up properly. Because plane setup here requires the atomic state, we'll have to settle for committing atomic planes first. In bug #90861 the failure appears to affect mostly DP devices, and happens because reading out the atomic state prevents a modeset on boot, which would require better hw state readout. In bug #90874 it's shown that cdclk should be part of the atomic state, so only performing a single modeset during resume excarbated the issue. It's better to fix those issues first, and then commit this patch, so do that temporarily. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90868 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90861 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90874Signed-off-by:
-
Maarten Lankhorst authored
This reverts commit 490f400db5d886fc28566af69b02f6497f31be4b. We're not ready yet to make it atomic, we calculate some state in advance, but without atomic plane support atomic the hw readout will fail. It's required to revert this commit to revert the atomic hw state readout patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90868 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90861Signed-off-by:
-
Maarten Lankhorst authored
crtc->active will be gone eventually, and this check should be just as good. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
This is a small behavioral change because it leaves DVO_2X_MODE set between crtc_disable and crtc_enable. This is probably harmless though and if not should be fixed by calculating 2x mode before enable/disable pll. This is needed because intel_crtc->active will be removed eventually. Signed-off-by:
-
