- 21 Oct, 2016 3 commits
-
-
Ville Syrjälä authored
The VBT provides the platform a way to mix and match the DDI ports vs. GMBUS pins. Currently we only trust the VBT for DDI E, which I suppose has no standard GMBUS pin assignment. However, there are machines out there that use a non-standard mapping for the other ports as well. Let's start trusting the VBT on this one for all ports on DDI platforms. I've structured the code such that other platforms could easily start using this as well, by simply filling in the ddi_port_info. IIRC there may be CHV system that might actually need this. v2: Include a commit message, include a debug message during init Cc: stable@vger.kernel.org Cc: Maarten Maathuis <madman2003@gmail.com> Tested-by:
Maarten Maathuis <madman2003@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97877Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Jim Bride <jim.bride@linux.intel.com>
-
Ville Syrjälä authored
The VBT provides the platform a way to mix and match the DDI ports vs. AUX channels. Currently we only trust the VBT for DDI E, which has no corresponding AUX channel of its own. However it is possible that some board might use some non-standard DDI vs. AUX port routing even for the other ports. Perhaps for signal routing reasons or something, So let's generalize this and trust the VBT for all ports. For now we'll limit this to DDI platforms, as we trust the VBT a bit more there anyway when it comes to the DDI ports. I've structured the code in a way that would allow us to easily expand this to other platforms as well, by simply filling in the ddi_port_info. v2: Drop whitespace changes, keep MISSING_CASE() for unknown aux ch assignment, include a commit message, include debug message during init Cc: stable@vger.kernel.org Cc: Maarten Maathuis <madman2003@gmail.com> Tested-by: -
Arkadiusz Hiler authored
Dropping WA because it was for early steppings. It is fixed in newer preproduction and all production revisions. v2: add references, updated commit message References: HSD#2126385, HSD#2131381, BSID#0764 Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Signed-off-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
- 20 Oct, 2016 24 commits
-
-
Rodrigo Vivi authored
According to spec: "KBL re-uses SKL values, except where specific KBL values are listed." And recently spec has changed adding different table for Display Port only. But for all SKUs (H,S,U,Y) we have slightly different values. v2: Fix wrong condition spotted by Jani. v3: Fix 7th entry of KBL H and S table - by Manasi. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476806256-13318-1-git-send-email-rodrigo.vivi@intel.com
-
Rodrigo Vivi authored
No functional change. Only moving this fixup block out of ddi_translation definitions so we can split skl and kbl cleanly. v2: Remove useless comment. (Ville) Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
https://github.com/01org/gvt-linuxDaniel Vetter authored
Merge tag 'gvt-next-fix-2016-10-20' of https://github.com/01org/gvt-linux into drm-intel-next-queued gvt-next-fix-2016-10-20 This contains fix for first pull request. - clean up header mess between i915 core and gvt - new MAINTAINERS item - new kernel-doc section - fix compiling warnings - gvt gem fix series from Chris - fix for i915 intel_engine_cs change - some sparse fixes from Changbin Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Chris Wilson authored
If the kernel is old, more than a few releases old, chances are that the user is using an old kernel for a good reason, despite there being GPU hangs. After 180days since driver release stop suggesting that they should send those reports upstream. [Since Daniel acked this I expect he will pick up the dim patch to automatically update the DRIVER_TIMESTAMP everytime we tag a new release.] Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161014134428.29582-1-chris@chris-wilson.co.ukAcked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Chris Wilson authored
As we already capture all the information from the registers into the error-state, also dumping that to dmesg just generates noise that upsets CI and users alike (and doesn't provide us with any more information). Signed-off-by:
-
Du, Changbin authored
Function create_scratch_page() may fail in some cases. Signed-off-by:
Du, Changbin <changbin.du@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com>
-
Du, Changbin authored
The function return values should has type int if it return a integer value. Signed-off-by:
-
Du, Changbin authored
Mark all local functions & variables as static. Signed-off-by:
-
Du, Changbin authored
Add proper __iomem annotation for pointers obtained via ioremap(). Signed-off-by:
-
Zhenyu Wang authored
Switch to use new for_each_engine() helper to properly access enabled intel_engine_cs as i915 core has changed that to be dynamic managed. At GVT-g init time would still depend on ring mask to determine engine list as it's earlier. Signed-off-by: -
Chris Wilson authored
This code was removed from i915_cmd_parser.c but still an obsolete version wound up being duplicated into gvt/cmd_parser.c. Good riddance. Signed-off-by:
-
Chris Wilson authored
We have the ability to map an object, so use it rather than opencode it badly. Note that the object remains permanently pinned, this is poor practise. Signed-off-by:
-
Chris Wilson authored
We have the ability to map an object, so use it rather than opencode it badly. Signed-off-by:
-
Chris Wilson authored
For whatever reason, the gvt scheduler runs synchronously. At the very least, lets run synchronously without holding the struct_mutex. v2: cut'n'paste mutex_lock instead of unlock. Replace long hold of struct_mutex with a mutex to serialise the worker threads. Signed-off-by:
-
Chris Wilson authored
The kthread will not be interrupted, don't even bother checking. Signed-off-by:
-
Chris Wilson authored
The workload took a pointer to the request, and even waited upon, without holding a reference on the request. Take that reference explicitly and fix up the error path following request allocation that missed flushing the request. v2: [zhenyuw] - drop request put in error path for dispatch, as main thread caller will handle it identically to a real request. Signed-off-by:
-
Chris Wilson authored
Unpinning the pages prior to the object being release from the GPU may allow the GPU to read and write into system pages (i.e. use after free by the hw). Signed-off-by:
-
Chris Wilson authored
The purpose of returning the just-pinned VMA is so that we can use the information within, like its address. Also it should be tracked and used as the cookie to unpin... Signed-off-by:
-
Chris Wilson authored
On failure from i915_gem_object_create(), we need to check for an error pointer not NULL. Signed-off-by:
-
Chris Wilson authored
Manipulating the fence_list requires the runtime wakelock, as does writing to the fence registers. Acquire a wakelock for the former, and assert that the device is awake for the latter. Signed-off-by:
-
Zhenyu Wang authored
Update with brief overview and reference for more detailed arch design documents. Add new section for Intel GVT-g host support. Signed-off-by: -
Zhenyu Wang authored
Don't use obsolete drm_gem_object_unreference() but switch to i915_gem_object_put(). Signed-off-by: -
Zhenyu Wang authored
This adds new item for Intel GVT-g driver maintainer info. Signed-off-by: -
Zhenyu Wang authored
i915 core should only call functions and structures exposed through intel_gvt.h. Remove internal gvt.h and i915_pvinfo.h. Change for internal intel_gvt structure as private handler which not requires to expose gvt internal structure for i915 core. v2: Fix per Chris's comment - carefully handle dev_priv->gvt assignment - add necessary bracket for macro helper - forward declartion struct intel_gvt - keep free operation within same file handling alloc v3: fix use after free and remove intel_gvt.initialized v4: change to_gvt() to an inline Reviewed-by:
-
- 19 Oct, 2016 12 commits
-
-
cpaul@redhat.com authored
Wrapping strings is against the guidelines in Documentation/CodingStyle, chapter 2. Signed-off-by:
Lyude <cpaul@redhat.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
cpaul@redhat.com authored
Thanks to Paulo Zanoni for indirectly pointing this out. Looks like we never actually added any code for checking whether or not we actually wrote watermark levels properly. Let's fix that. Changes since v1: - Use %u instead of %d when printing WM state mismatches Signed-off-by:
-
cpaul@redhat.com authored
Helper we're going to be using for implementing verification of the wm levels in skl_verify_wm_level(). Signed-off-by:
-
cpaul@redhat.com authored
There's not much of a reason this should have the locations to read out the hardware state hardcoded, so allow the caller to specify the location and add this function to intel_drv.h. As well, we're going to need this function to be reusable for the next patch. Changes since v1: - Fix accidental behavior change in the code that Paulo pointed out Signed-off-by:
-
cpaul@redhat.com authored
Finally, add some debugging output for ddb changes in the atomic debug output. This makes it a lot easier to spot bugs from incorrect ddb allocations. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
cpaul@redhat.com authored
Now that we've make skl_wm_levels make a little more sense, we can remove all of the redundant wm information. Up until now we'd been storing two copies of all of the skl watermarks: one being the skl_pipe_wm structs, the other being the global wm struct in drm_i915_private containing the raw register values. This is confusing and problematic, since it means we're prone to accidentally letting the two copies go out of sync. So, get rid of all of the functions responsible for computing the register values and just use a single helper, skl_write_wm_level(), to convert and write the new watermarks on the fly. Changes since v1: - Fixup skl_write_wm_level() - Fixup skl_wm_level_from_reg_val() - Don't forget to copy *active to intel_crtc->wm.active.skl Changes since v2: - Fix usage of wrong cstate Changes since v3 (by Paulo): - Rebase Reviewed-by:
-
Chris Wilson authored
The STOP_MACHINE kconfig symbol was removed upstream after making stop_machine() always work, commit 86fffe4a ("kernel: remove stop_machine() Kconfig dependency"), and was removed from i915's Kconfig in commit 21fabbeb ("drm/i915: Remove select to deleted STOP_MACHINE from Kconfig"). However, I accidentally reintroduced the select when rebasing an older commit that also was dependent upon a working stop_machine. Fixes: 9f267eb8 ("drm/i915: Stop the machine whilst capturing...") Reported-by:
Valentin Rothberg <valentinrothberg@gmail.com> Signed-off-by:
-
Jani Nikula authored
Fix warnings on building htmldocs. v2: whitespace around '/' (Ville) Fixes: 056996b9 ("drm: Helper for lspcon in drm_dp_dual_mode") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: <dri-devel@lists.freedesktop.org> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476878884-2370-1-git-send-email-jani.nikula@intel.com
-
Chris Wilson authored
Try to catch the violation of unpinning the backing storage whilst still bound to the GPU. Signed-off-by:
-
Jani Nikula authored
Fixes sparse warning: drivers/gpu/drm/i915/intel_lspcon.c:30:22: warning: symbol 'lspcon_get_current_mode' was not declared. Should it be static? Fixes: dbe9e61b ("drm/i915: Add lspcon support for I915 driver") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
-
Jani Nikula authored
Fixes sparse warning: drivers/gpu/drm/drm_dp_dual_mode_helper.c:151:6: warning: symbol 'is_lspcon_adaptor' was not declared. Should it be static? Fixes: 056996b9 ("drm: Helper for lspcon in drm_dp_dual_mode") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: <dri-devel@lists.freedesktop.org> Reviewed-by:
-
Chris Wilson authored
After printing our welcome message to the user, also include supplementary details on what debugging is enabled (useful for us to sanity check what extra safeguards are on for any random kernel). Signed-off-by:
-
- 18 Oct, 2016 1 commit
-
-
Chris Wilson authored
When handling execbuf relocations, we play a delicate dance with pagefault. We first try to access the user pages underneath our struct_mutex. However, if those pages were inside a GEM object, we may trigger a pagefault and deadlock as i915_gem_fault() tries to recursively acquire struct_mutex. Instead, we choose to disable pagefaulting around the copy_from_user whilst inside the struct_mutex and handle the EFAULT by falling back to a copy outside the struct_mutex. We however presumed that disabling pagefaults would be expensive. It is just an operation on the local current task. Cheap enough that we can restrict the disable/enable to the critical section around the copy, and so avoid having to handle the atomic sections within the relocation handling itself. v2: Just illustrate the broken error handling rather than argue why it is safer to ignore it, for now. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161018120251.25043-4-chris@chris-wilson.co.uk
-
