- 14 Aug, 2015 25 commits
-
-
Jani Nikula authored
There is currently conflicting documentation on which steppings the workaround is needed, up to C vs. forever. However there is post-C stepping hardware that doesn't report port presence on DDI A, leading to black screen on eDP. Assume the strap isn't connected, and try to enable DDI A on these machines. (We'll still check the VBT for the info in DDI init.) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Mika Westerberg <mika.westerberg@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Thulasimani,Sivakumar authored
DP spec requires the checksum of the last block read to be written when replying to TEST_EDID_READ. This patch fixes the current code to do the same. v2: removed loop for jumping blocks and performed direct addition as recommended by Daniel Signed-off-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Reviewed-by:
Sonika Jindal <sonika.jindal@intel.com> Signed-off-by:
-
Mika Kuoppala authored
Prevent leaking the if scoping by containing the WA_REG macro inside its own scope. Reported-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Dave Gordon <david.s.gordon@intel.com> [danvet: Appease checkpatch.] Signed-off-by:
-
Chris Wilson authored
If we encounter an allocation failure during ppggt creation (trivial even with 16Gib+ RAM!), we need to remove the dead context from the fpriv->context_idr along with the references. gem_exec_ctx: page allocation failure: order:0, mode:0x8004 CPU: 3 PID: 27272 Comm: gem_exec_ctx Tainted: G W 4.2.0-rc5+ #37 0000000000000000 ffff880086ff7a78 ffffffff816b947a ffff88041ed90038 0000000000008004 ffff880086ff7b08 ffffffff8114b1a5 ffff880086ff7ac8 ffffffff8108d848 0000000000000000 ffffffff81ce84b8 0000000000000000 Call Trace: [<ffffffff816b947a>] dump_stack+0x45/0x57 [<ffffffff8114b1a5>] warn_alloc_failed+0xd5/0x120 [<ffffffff8108d848>] ? __wake_up+0x48/0x60 [<ffffffff8114e0ed>] __alloc_pages_nodemask+0x73d/0x8e0 [<ffffffffc0472238>] ? i915_gem_execbuffer2+0x148/0x240 [i915] [<ffffffffc0474240>] __setup_page_dma+0x30/0x110 [i915] [<ffffffffc0477f61>] gen8_ppgtt_init+0x31/0x2f0 [i915] [<ffffffffc04785e0>] i915_ppgtt_init+0x30/0x80 [i915] [<ffffffffc0478928>] i915_ppgtt_create+0x48/0xc0 [i915] [<ffffffffc046c9c2>] i915_gem_create_context+0x1c2/0x390 [i915] [<ffffffffc046d9cb>] i915_gem_context_create_ioctl+0x5b/0xa0 [i915] leading to an oops in i915_gem_context_close. Also note that this benchmark should not be running out of memory in the first place... Testcase: igt/benchmark/gem_exec_ctx -b create # ppgtt >= 2 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Chris Wilson authored
The IOMMU for Intel graphics has historically had many issues resulting in random GPU hangs. Lets include its status when capturing the GPU hang error state for post-mortem analysis. Signed-off-by:
-
Mika Kuoppala authored
If idle to active bit is set, the rest of the fields in CSQ are not valid. Bail out early if this is the case in order to prevent rest of the loop inspecting stale values. This was found by Bspec/code inspection. Doesn't seem to fix any of the known issues. Signed-off-by:
-
Rodrigo Vivi authored
There is no correspondent Aux channel for DDI-E. So we need to rely on VBT to let us know witch one is being used instead. v2: Removing some trailing spaces and giving proper credit to Xiong that added a nice way to avoid port conflicts by setting supports_dp = 0 when using equivalent aux for DDI-E. Credits-to: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
DDI-E and DDI-A share 4 the same DDI-A lanes. Signed-off-by:
-
Paulo Zanoni authored
I started digging this when I noticed that the BDW code was just reserving 1mb by coincidence since it was reading reserved fields. Then I noticed we didn't have any values set for SNB and earlier, and that the HSW sizes were wrong. After that, I noticed that the reserved area has a specific start, and may not exactly end where the stolen memory ends. I also noticed the base pointer can be zero. So I decided to just write a single patch fixing everything instead of 20 patches that would be much harder to review. This patch may solve random stolen memory corruption/problems on almost all platforms. Notice that since this is always dealing with the top of the stolen memory, the problems are not so easy to reproduce - especially since FBC is still disabled by default. One of the major differences of this patch is that we now look at both the size and base address. By only looking at the size we were assuming that the reserved area was always at the very top of stolen, which is not always true. After we merge the patch series that allows user space to allocate stolen memory we'll be able to write IGT tests that maybe catch the bugs fixed by this patch. v2: - s/BIOS reserved/stolen reserved/g (Chris) - Don't DRM_ERROR if we can't do anything about it (Chris) - Improve debug messages (Chris). - Use the gen7 version instead of gen6 on HSW. Tom found some documentation problems, so I think with gen7 we're on the safer side (Tom). Signed-off-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Mika Kuoppala authored
This register needs to be updated with masked writes. This was found by code inspection and comparison with Bspec and doesn't seem to fix any known issue. Signed-off-by:
Michel Thierry <michel.thierry@intel.com> [danvet: Add note about impact.] Signed-off-by:
-
Mika Kuoppala authored
Add WaDisableSbeCacheDispatchPortSharing:skl Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by:
-
Mika Kuoppala authored
If we encounter frequent problems with dp aux channel communications, we end up spamming the dmesg with the exact similar trace and status. Inject a new backtrace only if we have new information to share as otherwise we flush out all other important stuff. Signed-off-by:
-
Maarten Lankhorst authored
-EDEADLK has special meaning in atomic, but get_fence may call i915_find_fence_reg which can return -EDEADLK. This has special meaning in the atomic world, so convert the error to -EBUSY for this case. Changes since v1: - Add comment in the code. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Maarten Lankhorst authored
The rest will be a noop anyway, since without modeset there will be no updated dplls and no modeset state to update. Signed-off-by:
-
Maarten Lankhorst authored
There are no more users, byebye! Signed-off-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
-
Maarten Lankhorst authored
Now that everything's atomic, checking encoder->base.crtc is enough. This function doesn't have the locks to dereference crtc->state, but stealing an encoder bound to any crtc is probably enough reason to warn. Changes since v1: - Commit message. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Maarten Lankhorst authored
connectors_active will be removed, so just calculate this instead. Changes since v1: - Look for the right pointer in intel_sanitize_encoder. Signed-off-by:
-
Maarten Lankhorst authored
This is now done completely atomically. Keep connectors_active for now, but make it mirror crtc_state->active. Signed-off-by:
-
Maarten Lankhorst authored
Instead of allocating pipe_config on the stack use the old crtc_state, it's only going to freed from this point on. All crtc' are now only checked once during modeset, because false positives can happen with encoders after dpms changes and to limit the amount of errors for 1 failure. Changes since v1: - crtc_state -> old_crtc_state - state -> old_state Signed-off-by:
-
Maarten Lankhorst authored
Connectors are updated atomically now, so the only interaction with the encoder is through base.crtc. If it's NULL the encoder's not part of any crtc, and if it's not NULL then active should be equal to crtc_state->active. Signed-off-by:
-
Maarten Lankhorst authored
This is handled by the atomic core now, no need to check this for ourself. Signed-off-by:
-
Maarten Lankhorst authored
Right now dpms callbacks can still fiddle with the connector state, but it can only turn connectors off. This is remediated by only checking crtc->state->active when the connector is active, and ignore crtc->state->active when the connector is off. connectors_active is no longer checked, and will be removed later in this series together with dpms. Another check for !encoder->crtc is performed by check_encoder_state too, so it can be removed. Changes since v1: - Add commit message. - rename state to old_state. - Move deletion of mst_port check to mst patch. Changes since v2: - Fix a null pointer dereference on MST now hw readout is fixed. Signed-off-by:
-
Maarten Lankhorst authored
Fully remove the MST connector from the atomic state, and remove the early returns in check_*_state for MST connectors. With atomic the state can be made consistent all the time. Thanks to Sivakumar Thulasimani for the idea of using drm_atomic_helper_set_config. Changes since v1: - Remove the MST check in intel_connector_check_state too. Changes since v2: - Use drm_atomic_helper_set_config. Signed-off-by:
-
Maarten Lankhorst authored
First step in removing dpms and validating atomic state. There can still be a mismatch in the connector state because the dpms callbacks are still used, but this can not happen immediately after a modeset. Signed-off-by:
-
Maarten Lankhorst authored
Set connectors_changed to force a modeset if the panel fitter's force enabled on eDP. Changes since v1: - Use connectors_changed instead of active_changed because it's a routing update. Signed-off-by:
-
- 06 Aug, 2015 1 commit
-
-
Daniel Vetter authored
We need a few core drm patches to be able to merge Maarten's series to convert DPMS over to atomic. Signed-off-by:Daniel Vetter <daniel.vetter@intel.com>
-
- 05 Aug, 2015 14 commits
-
-
Jesse Barnes authored
Looks like commit eddfcbcd Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Mon Jun 15 12:33:53 2015 +0200 drm/i915: Update less state during modeset. introduced the unconditional calling of disable_shared_dpll, but didn't fix up pre-gen5 to avoid the BUG_ON at the top of the function. So change the BUG_ON into a gen check (alternately we could move the BUG_ON until later, since we shouldn't have a pll struct here either, but this seems clearer to read). This fixes a crash on load on my x200s platform. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
-
Arun Siluvery authored
Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
-
Animesh Manna authored
This patch contains the changes to remove the byte swapping logic introduced with old dmc firmware. While debugging PC10 entry issue for skylake found with latest dmc firmware version 1.18 without byte swapping dmc is working fine and able to enter PC10. Note that apparently this was changed with dmc version 1.0 and earlier ones indeed are byteswapped like this ... v1: Initial version. v2: Corrected firmware size during memcpy(). (Suggested by Sunil) Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Signed-off-by:
Vathsala Nagaraju <vathsala.nagaraju@intel.com> Reviewed-by:
A.Sunil Kamath <sunil.kamath@intel.com> [danvet: Add note that this only holds for released dmc firmware.] Signed-off-by:
-
Thulasimani,Sivakumar authored
BPP bits defined in VBT should be used only on panels whose edid version is 1.3 or older. EDID version 1.4 introduced offsets where bpp is defined and read into display_info, hence bpp from VBT will be used only when bpc in display_info is zero. v2: use display_info.bpc for deciding when to use vbt_bpp (Jani) Signed-off-by:
-
Paulo Zanoni authored
I was told that the "repurposed D1 definition" is still valid for SKL. It is BDW that is special due to its hotplug bug, so let's special-case BDW instead of HSW. Cc: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by:
-
Damien Lespiau authored
Similar to the ->enable vfunc in patch "drm/i915: Extract a intel_power_well_enable() function". v2 (from Paulo): - Same s/i915_/intel_/ bikeshed as the previous patch. - Update the commit hash. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
-
Damien Lespiau authored
We need a bit book keeping around power wells' ops->enable(), namely a nice debug message and updating hw_enabled. Let's introduce a intel_power_well_enable() function to make sure all the callers do the same things. v2 (from Paulo): - s/i915_power_well_enable/intel_power_well_enable/ since everything else on this file uses intel_ instead of i915_. - Fix typo in commit message. Signed-off-by: -
Marc Herbert authored
With this simple git diff command one can see that skl_init_workarounds() got two copies of WaBarrierPerformanceFixDisable:skl: git diff -U21 ca6e4405^1 ca6e4405 drivers/gpu/drm/i915/intel_ringbuffer.c This happened when the backmerge of drm-intel-fixes-2015-07-15 Merged the same fix on both sides. Same fix but not identical enough for git: with a different surrounding context; hence the code duplication. This commit merely reverts the output of the git command above = the duplication introduced in the backmerge. (This duplication was found while running git sanity checks on a _linearized_ i915 forklift for ChromeOS.) Signed-off-by:
Marc Herbert <marc.herbert@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
Since active function on VLV immediately activate PSR let's give more time for idleness. Different from core platforms where we have idle_frames count. Also kms_psr_sink_crc now is automated and always get this: [drm:intel_enable_pipe] enabling pipe A [drm:intel_edp_backlight_on] [drm:intel_panel_enable_backlight] pipe [drm:intel_panel_enable_backlight] pipe A [drm:intel_panel_actually_set_backlight] set backlight PWM = 7812 PSR gets enabled somewhere here after backlight. [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x0 [drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511 [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp PSR gets flushed around here by intel_atomic_commit [drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511 [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp [drm:intel_set_memory_cxsr] memory self-refresh is enabled [drm:intel_connector_check_state] [CONNECTOR:39:eDP-1] [drm:check_encoder_state] [ENCODER:30:DAC-30] [drm:check_encoder_state] [ENCODER:31:TMDS-31] [drm:check_encoder_state] [ENCODER:36:TMDS-36] [drm:check_encoder_state] [ENCODER:38:TMDS-38] [drm:check_crtc_state] [CRTC:21] [drm:check_crtc_state] [CRTC:26] [drm:intel_psr_activate [i915]] *ERROR* PSR Active [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO Underrun. It is true that in a product we won't keep disabling and enabling planes so frequently, but for safeness let's stay conservative. It is also true that 500ms is an etternity. But PSR is anyway a power saving feature for idle scenario. So if it is idle feature stays on and 500ms to get it reanabled is not that insane. v2: Rebase over intel_psr.c and fix typo. v3: Revival: Manual tests indicated that this is needed. With a short delay there is a huge risk of getting blank screens when planes are being enabled. v4: Revival 2 with reasonable delay. 1/2 sec instead of 5. VBT is 10 sec but actually time for link training what we aren't doing, but with only 100 sec in some cases kms_psr_sink_crc manual was showing blank screen, so let's use this for now. Also changed comment by a FIXME. v5: Rebase after a long time, remove FIXME and update comment above. v6: msecs_to_jiffies is already on delay. remove duplication. v7: use msecs_to_jiffies on schedule_delayed_work call. Reviewed-by: Durgadoss R <durgadoss.r@intel.com> (v4) Signed-off-by: -
Rodrigo Vivi authored
This is just a preparation patch to make clear what operation we are performing. There is no functional change on the sink crc logic. hsw_disable_ips has been moved a bit further in the start function to avoid disabling ips when sink crc is not going to be started. and to avoid goto on this function. v2: explain why hsw_disable_ips() call place has changed. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Rafael Antognolli <rafael.antognolli@intel.com> Signed-off-by:
-
Paulo Zanoni authored
First, an introduction. We currently have two types of GTT mmaps: the "normal" old mmap, and the WC mmap. For frontbuffer-related features that have automatic hardware tracking, only the non-WC mmap writes are detected by the hardware. Since inside the Kernel both are treated as ORIGIN_GTT, any features ignoring ORIGIN_GTT because of the hardware tracking are destined to fail. One of the special rules defined for the WC mmaps is that the user should call the dirtyfb IOCTL after he is done using the pointers, so that results in an intel_fb_obj_flush() call. The problem is that the dirtyfb is passing ORIGIN_GTT, so it is being ignored by FBC - even though the hardware tracking is not detecing the WC mmap operations. So in order to fix that without having to give up the automatic hardware tracking for GTT mmaps we transform the flush operation from dirtyfb into a special operation: ORIGIN_DIRTYFB. This commit fixes all the kms_frontbuffer_tracking subtests that contain "fbc" and "mmap-wc" in their names and are currently failing (for a total of 16 subtests). Signed-off-by:
-
Paulo Zanoni authored
Use the appropriate call. I know there's a discussion about whether we need this call here at all, but removing the call means we'll only update FBC after we get the page flip IRQ. So the user may only see the new frame a little after it should. Let's wait just a little bit more before removing this call since we can rely in the HW tracking for accurate flips. Signed-off-by:
-
Paulo Zanoni authored
Because intel_unpin_work_fn() already calls intel_frontbuffer_flip_complete() which will call intel_fbc_flush() which will call intel_fbc_update() when needed. We couldn't fix this previously due to the fact that FBC was not properly behaving as intended on frontbuffer flushes, but now that this is fixed, we can remove the additional call. Signed-off-by:
-
Paulo Zanoni authored
Due to the way busy_bits was handled, we were not doing any flushes if we didn't previously get an invalidate. Since it's possible to get flushes without an invalidate first, remove the busy_bits early return. So now that we don't have the busy_bits guard anymore we'll need the origin check for the GTT tracking (we were not doing anything on GTT flushes due to the GTT check at invalidate()). As a last detail, since we can get multiple consecutive flushes, disable FBC before updating it, otherwise intel_fbc_update() will just keep FBC enabled instead of restarting it. Notice that this does not fix any of the current IGT tests due to the fact that we still have a few intel_fbc() calls at points where we also have the frontbuffer tracking calls: we didn't fully convert to frontbuffer tracking yet. Once we remove those calls and start relying only on the frontbuffer tracking infrastructure we'll need this patch. Signed-off-by:
-
