- 28 Oct, 2015 6 commits
-
-
Deepak S authored
v2: (Rodrigo) Rebase after commit 3cb27f38 ("drm/i915: remove an extra level of indirection in PCI ID list") Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Deepak S <deepak.s@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446060072-19489-1-git-send-email-rodrigo.vivi@intel.comSigned-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Deepak S authored
v2: separate out device info into different GT (Damien) v3: Add is_kabylake to the KBL gt3 structuer (Damien) Sort the platforms in older -> newer order (Damien) v4: Split platform definition since is_skylake=1 on kabylake structure was Nacked. (Rodrigo) v5: (Rodrigo) Rebase after commit 3cb27f38 ("drm/i915: remove an extra level of indirection in PCI ID list") Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: -
Rodrigo Vivi authored
Kabylake is a Intel
® Processor containing Intel® HD Graphics following Skylake. It is Gen9p5, so it inherits everything from Skylake. Let's start by adding the platform separated from Skylake but reusing most of all features, functions etc. Later we rebase the PCI-ID patch without is_skylake=1 so we don't replace what original Author did there. Few IS_SKYLAKEs if statements are not being covered by this patch on purpose: - Workarounds: Kabylake is derivated from Skylake H0 so no W/As apply here. - GuC: A following patch removes Kabylake support with an explanation: No firmware available yet. - DMC/CSR: Done in a separated patch since we need to be carefull and load the version for revision 7 since Kabylake is Skylake H0. v2: relative cleaner commit message and added the missed IS_KABYLAKE to intel_i2c.c as pointed out by Jani. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: -
Rodrigo Vivi authored
Kabylake will also be defined as gen9 and !is_skylake. So we need start by creating a proper Broxton definition, otherwise we will break broxton with the introduction of Kabylake. Signed-off-by:
-
Jani Nikula authored
Add the PCI IDs directly in the pciidlist array instead of defining an extra macro. The minor benefit from this is neater diffs when adding to the end of the list. v2: drop the "aka" comment (Ville) Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
Having flushed all requests from all queues, we know that all ringbuffers must now be empty. However, since we do not reclaim all space when retiring the request (to prevent HEADs colliding with rapid ringbuffer wraparound) the amount of available space on each ringbuffer upon reset is less than when we start. Do one more pass over all the ringbuffers to reset the available space Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Dave Gordon <david.s.gordon@intel.com>
-
- 26 Oct, 2015 6 commits
-
-
Ville Syrjälä authored
v2: Rebase due to SKL_DPLLx usage Signed-off-by:
-
Ville Syrjälä authored
Include an early NEEDS_FORCEWAKE() check for vlv and chv. Hopefully that will avoid doing so many range checks in for many register accesses (at least for all display registers). Note that vlv already had the check in the write path since it shares the gen6+ code for that. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Ville Syrjälä authored
Change the fw domain handling in the vlv/chv register read/write functions to look more like the SKL code, ie. have a single __force_wake_get() get call instead of multiple ones. Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Change FORCEWAKE & co. reads for the error state to use I915_READ_FW(). Reading a FORCEWAKE register using a function that can frob forcewake just seems wrong. There is a check to skip grabbing the forcewake for accessing FORCEWAKE in intel_uncore.c, but there's no such check for FORCEWAKE_MT. So no idea what is currently happening with FORCEWAKE_MT reads. FORCEWAKE_VLV is fortunately outside the forcewake range anyway, so no actual issue with that one. So let's just make the rule that you can't access FORCEWAKE registers with the normal I915_READ() stuff, and we can drop the extra FORCEWAKE check from NEEDS_FORCEWAKE(). While at it use NEEDS_FORCEWAKE() on BDW, where it was skipped for whatever bikeshed reason that I've already forgotten. Signed-off-by:
-
Ville Syrjälä authored
There's no need for __raw_i915_read8() & co. to be macros, so make them inline functions. To avoid typo mistakes generate the inline functions using preprocessor templates. We have a few users of the raw register acces functions outside intel_uncore.c, so let's also move the functions into intel_drv.h. While doing that switch I915_READ_FW() & co. to use the __raw_i915_read() functions, and use the _FW macros everywhere outside intel_uncore.c where we want to read registers without grabbing forcewake and whatnot. The only exception is i915_check_vgpu() which itself gets called from intel_uncore.c, so using the __raw_i915_read stuff there seems appropriate. v2: Squash in the intel_uncore.c->i915_drv.h move Convert I915_READ_FW() to use __raw_i915_read(), and use I915_READ_FW() outside of intel_uncore.c (Chris) Signed-off-by:
-
- 23 Oct, 2015 4 commits
-
-
Tomas Elf authored
Since we're not synchronizing the ring request list during error state capture the request list state might change between the time the corresponding error request list was allocated and dimensioned to the time when the ring request list is actually captured into the error state. If this happens then do an early exit and be aware that the captured error state might not be fully reliable. * v2: - Chris Wilson: Removed WARN_ON from size check since having the error state request list and the live driver request list diverge like this is a legitimate behaviour. - Tomas Elf: Removed update of num_request field since this made no sense. Just exit and move on. * v3: - Chris Wilson: Removed error message at the point of early exit. The user is not interested in any state changes happening during the error state capture, only in the state that we're trying to capture at the point of the error. Signed-off-by:
Tomas Elf <tomas.elf@intel.com> Signed-off-by:
-
Daniel Vetter authored
This reverts commit 51056723. I somehow managed to combine a patch from Tomas Elf with a totally unrelated commit message from Chris Wilson. Let's revert this and reapply properly. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
Signed-off-by: -
Daniel Vetter authored
We get tons of cases where the master interrupt handler apparently set a bit, with the SDEIIR disagreeing. No idea what's going on there, but it's consistent on gen8+, no one seems to care about it and it's making CI results flaky. Shut it up. No idea what's going on here, but we've had fun with PCH interrupts before: commit 44498aea Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Feb 22 17:05:28 2013 -0300 drm/i915: also disable south interrupts when handling them Note that there's a regression report in Bugzilla, and other regression reports on the mailing lists keep croping up. But no ill effects have ever been reported. But for paranoia still keep the message at a debug level as a breadcrumb, just in case. This message was introduced in commit 38cc46d7 Author: Oscar Mateo <oscar.mateo@intel.com> Date: Mon Jun 16 16:10:59 2014 +0100 drm/i915/bdw: Ack interrupts before handling them (GEN8) v2: Improve commit message a bit. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
- 22 Oct, 2015 2 commits
-
-
Tomas Elf authored
Grab execlist lock when cleaning up execlist queues after GPU reset to avoid concurrency problems between the context event interrupt handler and the reset path immediately following a GPU reset. * v2 (Chris Wilson): Do execlist check and use simpler form of spinlock functions. Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
-
Chris Wilson authored
Userspace can pass in an offset that it presumes the object is located at. The kernel will then do its utmost to fit the object into that location. The assumption is that userspace is handling its own object locations (for example along with full-ppgtt) and that the kernel will rarely have to make space for the user's requests. v2: Fix i915_gem_evict_range() (now evict_for_vma) to handle ordinary and fixed objects within the same batch Signed-off-by:
-
- 21 Oct, 2015 16 commits
-
-
Matt Roper authored
v2: Don't forget to actually check the cstate->active value when tallying up the number of active CRTC's. (Ander) Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Smoke-tested-by:
Paulo Zanoni <przanoni@gmail.com> Link: http://patchwork.freedesktop.org/patch/59561/
-
Matt Roper authored
We already ensure that pstate->visible = false when crtc->active = false during runtime programming; make sure we follow the same logic when reading out initial hardware state. Signed-off-by:
-
Matt Roper authored
Calculate pipe watermarks during atomic calculation phase, based on the contents of the atomic transaction's state structure. We still program the watermarks at the same time we did before, but the computation now happens much earlier. While this patch isn't too exciting by itself, it paves the way for future patches. The eventual goal (which will be realized in future patches in this series) is to calculate multiple sets up watermark values up front, and then program them at different times (pre- vs post-vblank) on the platforms that need a two-step watermark update. While we're at it, s/intel_compute_pipe_wm/ilk_compute_pipe_wm/ since this function only applies to ILK-style watermarks and we have a completely different function for SKL-style watermarks. Note that the original code had a memcmp() in ilk_update_wm() to avoid calling ilk_program_watermarks() if the watermarks hadn't changed. This memcmp vanishes here, which means we may do some unnecessary result generation and merging in cases where watermarks didn't change, but the lower-level function ilk_write_wm_values already makes sure that we don't actually try to program the watermark registers again. v2: Squash a few commits from the original series together; no longer leave pre-calculated wm's in a separate temporary structure since it's easier to follow the logic if we just cut over to using the pre-calculated values directly. v3: - Pass intel_crtc instead of drm_crtc to .compute_pipe_wm() entrypoint and use intel_atomic_get_crtc_state() to avoid need for extra casting. (Ander) - Drop unused intel_check_crtc() function prototype. (Ander) Signed-off-by: -
Matt Roper authored
A future patch will calculate these during the atomic 'check' phase rather than at WM programming time, so let's store the watermark values we're planning to use in the CRTC state; the values actually active on the hardware remains in intel_crtc. While we're at it, do some minor restructuring to keep ILK and SKL values in a union. v2: Don't move cxsr_allowed to state (Maarten) v3: Only calculate watermarks in state. Still keep active watermarks in intel_crtc itself. (Ville) Signed-off-by: -
Ville Syrjälä authored
Split ilk_update_wm() into two parts; one doing the programming and the other the calculations. v2: Fix typo in commit message v3 (by Matt): Heavily rebased for current codebase. Signed-off-by:
-
Matt Roper authored
The only platform that still has an update_sprite_wm entrypoint is SKL; on SKL, intel_update_sprite_watermarks just updates intel_plane->wm and then performs a regular watermark update. However intel_plane->wm is only used to update a couple fields in intel_wm_config, and those fields are never used by the SKL code, so on SKL an update_sprite_wm is effectively identical to an update_wm call. Since we're already ensuring that the regular intel_update_wm is called any time we'd try to call intel_update_sprite_watermarks, the whole call is redundant and can be dropped. Signed-off-by:
-
Matt Roper authored
Determine whether we need to apply this workaround at atomic check time and just set a flag that will be used by the main watermark update routine. Moving this workaround into the atomic framework reduces ilk_update_sprite_wm() to just a standard watermark update, so drop it completely and just ensure that ilk_update_wm() is called whenever a sprite plane is updated in a way that would affect watermarks. Signed-off-by:
-
Daniel Vetter authored
Requested by Chris, and since we're no longer rebasing the -next queue I can't rectify history. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Nick Hoath <nicholas.hoath@intel.com> Signed-off-by:
-
Alex Dai authored
The size / offset information of all firmware ingredients are now caculated from header. Driver will validate the header and rsa key size. If any component is out of boundary, driver will reject the loading too. v6: Clean up warnings from make docs v5: Tidy up GuC titles in kernel/Doc v4: Now using 'size_dw' for those defined in css_header v3: 1) Move DOC to intel_guc_fwif.h right before css_header definition. Add more comments. 2) Change 'size' to 'len' or 'length' to avoid confusion. 3) Add UOS_RSA_SCRATCH_MAX_COUNT according to BSpec. And driver validate size of RSA key now. 4) Add fw component size/offset info to intel_guc_fw. v2: Add indent into DOC to make fixed-width format rather than change the tmpl. v1: 1) guc_css_header is defined as __packed now 2) Add and correct GuC related topics in kernel/Doc Signed-off-by:Alex Dai <yu.dai@intel.com> Reviewed-by:
-
Jani Nikula authored
Revision checks are almost always accompanied by a platform check. (The exceptions are platform specific code.) Add helpers to check for a platform and a revision range: IS_SKL_REVID() and IS_BXT_REVID(). In most places this simplifies and clarifies the code. It will be obvious that revid macros are used for the correct platform. This should make it easier to find all the revision checks for workarounds for each platform, and make it easier to remove them once we drop support for early hardware revisions. This should also make it easier to differentiate between Skylake and Kabylake revision checks when Kabylake support is added. v2: rebase Acked-by:
-
Jani Nikula authored
Prefer inclusive ranges for revision checks rather than "below B0". Per specs A2 is not used, so revid <= A1 matches revid < B0. Acked-by:
-
Jani Nikula authored
Totally unnecessary. Acked-by:
-
Maarten Lankhorst authored
intel_crtc_disable_noatomic is called from hw readout during init, resume and possibly reset. During init it's too early to have a page flip queued, before suspending all page flips should be finished and during hw reset all page flips should be removed. It's a bug when there are pending flips here, complain with WARN_ON instead of handling it. Signed-off-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Reviewed-by:
-
Tvrtko Ursulin authored
Previously rotation was ignored and wrong stride programmed into the plane registers resulting in a corrupt image on screen. v2: Do not access potentialy old plane state at flip time, but store the rotation value at the time of queing the flip. (Ville) v3: No need to pass rotation to intel_queue_mmio_flip since it is available in the crtc. (Ville) Signed-off-by:Tvrtko Ursulin <tvrtko.ursulin@intel.com> Testcase: igt/kms_rotation_crc/primary-rotation-90-flip-stress (SKL) Reviewed-by:
-
Tvrtko Ursulin authored
Cdclk < crtc_clock is not allowed and suggests a different problem elsewhere in the code. It is more robust and safe to assume no scaling is possible in this case with no other downsides since it will also WARN_ON_ONCE so that this definitely gets noticed. Call it an assert to help new platform bring-up in simulation. v2: Better commit msg and use WARN_ON_ONCE to signify the unexpectedness. v3: Move zero crtc_clock check under the warn. (Ville) Signed-off-by:
-
Shobhit Kumar authored
Especially in cases where pre-os does not enable display, cdclk might not be in sane state. During sanitization initialize cdclk with maximum value till we get dynamic cdclk support. v2: Check if BIOS programmed correctly rather than always calling init - Do validation of programmed cdctl and what it is expected - Only do slk_init_cdclk if validation failed else reuse BIOS programmed value v3: Move the validation logic in a separate sanitize function (Ville) v4: No need to check LCPLL after sanitize and use max_cdclk_freq instead of hardcoded value (Ville) Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:Shobhit Kumar <shobhit.kumar@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445344992-14658-1-git-send-email-shobhit.kumar@intel.comReviewed-by:
-
- 20 Oct, 2015 2 commits
-
-
Nick Hoath authored
Break out common code from gen8_gt_irq_handler and put it in to an always inlined function. gcc optimises out the shift at compile time. (Thomas Daniel/Daniel Vetter/Chris Wilson) Issue: VIZ-4277 Signed-off-by:
Nick Hoath <nicholas.hoath@intel.com> Cc: Thomas Daniel <thomas.daniel@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1445333036-22164-3-git-send-email-nicholas.hoath@intel.comSigned-off-by:
-
Nick Hoath authored
Renamed tmp variable to the more descriptive iir. (Daniel Vetter/ Thomas Daniel) Issue: VIZ-4277 Signed-off-by:
-
- 19 Oct, 2015 4 commits
-
-
Matt Roper authored
Just pull the info out of the state structures rather than staging it in an additional set of structures. To make this more straightforward, we change the signature of several internal WM functions to take the crtc state as a parameter. v2: - Don't forget to skip cursor planes on a loop in the DDB allocation function to match original behavior. (Ander) - Change a use of intel_crtc->active to cstate->active. They should be identical, but it's better to be consistent. (Ander) - Rework more function signatures to pass states rather than crtc for consistency. (Ander) v3: - Add missing "+ 1" to skl_wm_plane_id()'s 'overlay' case. (Maarten) - Packed formats should pass '0' to drm_format_plane_cpp(), not 1. (Maarten) - Drop unwanted WARN_ON() for disabled planes when calculating data rate for SKL. (Maarten) v4: - Don't include cursor plane in total relative data rate calculation; we've already handled the cursor allocation earlier. - Fix 'bytes_per_pixel' calculation braindamage. Somehow I hardcoded the NV12 format as a parameter rather than the actual fb->pixel_format, and even then still managed to get the format plane wrong. (Ville) - Use plane->state->fb rather than plane->fb in skl_allocate_pipe_ddb(); the plane->fb pointer isn't updated until after we've done our watermark recalculation, so it has stale values. (Bob Paauwe) Signed-off-by: -
David Henningsson authored
Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Link: http://patchwork.freedesktop.org/patch/msgid/1444987464-8657-1-git-send-email-david.henningsson@canonical.comSigned-off-by:
-
Chris Wilson authored
Since the beginning we have conflated the size of the global GTT with that of the per-process context sizes. In recent times (gen8+), those are no longer the same where the global GTT is limited to 2/4GiB but the per-process GTT may be anything up to 256TiB. Userspace knows nothing of this discrepancy and outside of one or two hacks, uses the getaperture ioctl to determine the maximum size it can use. Let's leave that as reporting the global GTT and use the context reporting method to describe the per-process value (which naturally fallsback to reporting the aliasing or global on older platforms, so userspace can always use this method where available). Testcase: igt/gem_userptr_blits/minor-normal-sync Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90065Signed-off-by:
-
Chris Wilson authored
If we have llc coherency, we can write directly into the ringbuffer using ordinary cached writes rather than forcing WC access. v2: An important consequence is that we can forgo the mappable request for WB ringbuffers, allowing for many more simultaneous contexts. Signed-off-by:
-
