- 24 Oct, 2016 3 commits
-
-
Jani Nikula authored
We haven't required AGP since 3e99a6b9 ("drm/i915: Stop depending upon CONFIG_AGP_INTEL"). Split/rearrange the paragraphs a bit while at it. Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477041257-8219-1-git-send-email-jani.nikula@intel.com
-
Daniel Stone authored
The previous code would wait for fences on the framebuffer from the old plane state to complete, rather than the new, so you would see tearing everywhere. Fix this to wait on the new state before we make it active. Signed-off-by:
Daniel Stone <daniels@collabora.com> Fixes: 94f05024 ("drm/i915: nonblocking commit") Cc: stable@vger.kernel.org Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
Signed-off-by:
-
- 22 Oct, 2016 1 commit
-
-
Chris Wilson authored
The min-freq-table is an array of values that match each CPU frequency to an equivalent GPU frequency. Setting a single value of 0 on init is both illegal (generates an error from the PCU) and nonsensical. Let's see if we survive without that error. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20161021205531.8651-1-chris@chris-wilson.co.ukReviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
- 21 Oct, 2016 6 commits
-
-
Matthew Auld authored
Currently it's entirely possible to go through the link training step without first determining the lane_count, which is silly since we end up doing a bunch of aux transfers of size = 0, as highlighted by WARN_ON(!msg->buffer != !msg->size), and can only ever result in a 'failed to update link training' message. This can be observed during intel_dp_long_pulse where we can do the link training step, but before we have had a chance to set the link params. To avoid this we add an extra check for the lane_count in intel_dp_check_link_status, which should prevent us from doing the link training step prematurely. v2: add WARN_ON_ONCE and FIXME comment (Ville) References: https://bugs.freedesktop.org/show_bug.cgi?id=97344 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476912593-10019-1-git-send-email-matthew.auld@intel.comSigned-off-by:
-
Ville Syrjälä authored
Fix the poorly indented port parameters to the aux ctl and data reg functions. This was fallout from the s/i915_mmio_reg_t/i915_reg_t/ that happened during the review of commit f0f59a00 ("drm/i915: Type safe register read/write") Signed-off-by:
Jim Bride <jim.bride@linux.intel.com>
-
Ville Syrjälä authored
Now that we use the AUX and GMBUS assignment from VBT for all ports, let's clean up the sanitization of the port information a bit. Previosuly we only did this for port E, and only complained about a non-standard assignment for the other ports. But as we know that non-standard assignments are a fact of life, let's expand the sanitization to all the ports. v2: Include a commit message, fix up the comments a bit v3: Don't clobber other ports if the current port has no alternate aux ch/ddc pin Cc: stable@vger.kernel.org Cc: Maarten Maathuis <madman2003@gmail.com> Tested-by:
Maarten Maathuis <madman2003@gmail.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=97877Signed-off-by:
-
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:
-
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:
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 6 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:
-
