- 18 Jun, 2015 2 commits
-
-
Mika Kuoppala authored
In order for gen8+ hardware to guarantee that no context switch takes place during engine reset and that current context is properly saved, the driver needs to notify and query hw before commencing with reset. There are gpu hangs where the engine gets so stuck that it never will report to be ready for reset. We could proceed with reset anyway, but with some hangs with skl, the forced gpu reset will result in a system hang. By inspecting the unreadiness for reset seems to correlate with the probable system hang. We will only proceed with reset if all engines report that they are ready for reset. If root cause for system hang is found and can be worked around with another means, we can reconsider if we can reinstate full reset for unreadiness case. v2: -EIO, Recovery, gen8 (Chris, Tomas, Daniel) v3: updated commit msg v4: timeout_ms, simpler error path (Chris) References: https://bugs.freedesktop.org/show_bug.cgi?id=89959 References: https://bugs.freedesktop.org/show_bug.cgi?id=90854 Testcase: igt/gem_concurrent_blit/prw-blt-overwrite-source-read-rcs-forked Testcase: igt/gem_concurrent_blit/gtt-blt-overwrite-source-read-rcs-forked Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tomas Elf <tomas.elf@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Vandana Kannan authored
Changes for BXT - added a IS_BROXTON check to use the macro related to PPS registers for BXT. BXT does not have PP_DIV register. Making changes to handle this. Second set of PPS registers have been defined but will be used when VBT provides a selection between the 2 sets of registers. v2: [Jani] Added 2nd set of PPS registers and the macro Jani's review comments - remove reference in i915_suspend.c - Use BXT PP macro Squashing all PPS related patches into one. v3: Jani's review comments addressed - Use pp_ctl instead of pp - ironlake_get_pp_control() is not required for BXT - correct the use of && in the print statement - drop the shift in the print statement v4: Jani's comments - modify ironlake_get_pp_control() - dont set unlock key for bxt v5: Sonika's comments addressed - check alignment - move pp_ctrl_reg write (after ironlake_get_pp_control()) to !IS_BROXTON case. - check before subtracting 1 for t11_t12 Signed-off-by:
Vandana Kannan <vandana.kannan@intel.com> Signed-off-by:
A.Sunil Kamath <sunil.kamath@intel.com> Reviewed-by:
Sonika Jindal <sonika.jindal@intel.com> Signed-off-by:
-
- 17 Jun, 2015 1 commit
-
-
Matt Roper authored
We need to call drm_atomic_set_mode_for_crtc() rather than copying the mode in manually. As of commit commit 99cf4a29 Author: Daniel Stone <daniels@collabora.com> Date: Mon May 25 19:11:51 2015 +0100 drm/atomic: Add current-mode blob to CRTC state the helper now also takes care of setting up the mode property blob for us; if we don't use the helper and never setup the mode blob, this will also trigger a failure in drm_atomic_crtc_check() when we have the DRIVER_ATOMIC flag set (i.e., when using the nuclear pageflip support via i915.nuclear_pageflip kernel command line parameter). Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
- 15 Jun, 2015 35 commits
-
-
Daniel Vetter authored
Leftover from the big purge commit a5611654 Author: John Harrison <John.C.Harrison@Intel.com> Date: Thu Mar 5 14:03:03 2015 +0000 drm/i915: Remove ironlake rc6 support Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Rob Clark <robdclark@gmail.com> Reported-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Mika Kahola authored
Limit CHV maximum cdclk to 320MHz. v2: Rebase to the latest v3: Clean up of if-else tree Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Paulo Zanoni authored
This commit is just to make the intentions explicit: on HSW+ these bits are MBZ, but since we only support plane A and the macro evaluates to zero when plane A is the parameter, we're not fixing any bug. v2: - Remove useless extra blank like (Chris). - Init dpfc_ctl in another place (Chris). Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
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 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ä 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: -
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:
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 2 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:
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:
-
