- 08 9月, 2016 15 次提交
-
-
由 Carlos Santa 提交于
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platform - possible to see supported features when dumping struct definitions Signed-off-by: NCarlos Santa <carlos.santa@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Carlos Santa 提交于
Make the .hws_needs_physical the exception by switching the flag on earlier platforms since they are fewer to support. Remove the flag on later GPUs hardware since they all use GTT hws by default. Switch the logic as well in the driver to reflect this change Signed-off-by: NCarlos Santa <carlos.santa@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Carlos Santa 提交于
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: NCarlos Santa <carlos.santa@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Carlos Santa 提交于
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: NCarlos Santa <carlos.santa@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Carlos Santa 提交于
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: NCarlos Santa <carlos.santa@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Carlos Santa 提交于
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: NCarlos Santa <carlos.santa@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Carlos Santa 提交于
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: NCarlos Santa <carlos.santa@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Carlos Santa 提交于
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: NCarlos Santa <carlos.santa@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Carlos Santa 提交于
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: NCarlos Santa <carlos.santa@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Carlos Santa 提交于
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: NCarlos Santa <carlos.santa@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Carlos Santa 提交于
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: NCarlos Santa <carlos.santa@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Carlos Santa 提交于
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: NCarlos Santa <carlos.santa@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Carlos Santa 提交于
No need for HAS_CORE_RING_FREQ as that flag is actually the same as .has_llc. Feedback from V. Syrjala. Signed-off-by: NCarlos Santa <carlos.santa@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Carlos Santa 提交于
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: NCarlos Santa <carlos.santa@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Carlos Santa 提交于
[patch series] Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definition Signed-off-by: NCarlos Santa <carlos.santa@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
- 07 9月, 2016 1 次提交
-
-
由 Chris Wilson 提交于
We don't have safe 64-bit mmio writes as they are really split into 2x32-bit writes. This tearing is dangerous as the hardware *will* operate on the intermediate value, requiring great care when assigning. (See, for example, i965_write_fence_reg.) As such we don't currently use them and strongly advise not to us them. Go one step further and remove the 64-bit write vfuncs. v2: Add some more details to the comment about why WRITE64 is absent, and why you need to think twice before using READ64. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160906144538.4204-1-chris@chris-wilson.co.uk
-
- 02 9月, 2016 5 次提交
-
-
由 Imre Deak 提交于
In an upcoming patch we'll need the actual mask of subslices in addition to their count, so convert the subslice_per_slice field to a mask. Also we can easily calculate subslice_total from the other fields, so instead of storing a cached version of this, add a helper to calculate it. v2: - Use hweight8() on u8 typed vars instead of hweight32(). (Ben) Reviewed-by: Robert Bragg <robert@sixbynine.org> (v1) Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1) Tested-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1) Signed-off-by: NImre Deak <imre.deak@intel.com>
-
由 Imre Deak 提交于
In an upcoming patch we'll need the actual mask of slices in addition to their count, so replace the count field with a mask. v2: - Use hweight8() on u8 typed vars instead of hweight32(). (Ben) Reviewed-by: Robert Bragg <robert@sixbynine.org> (v1) Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1) Tested-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1) Signed-off-by: NImre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1472659987-10417-5-git-send-email-imre.deak@intel.com
-
由 Imre Deak 提交于
Move all slice/subslice/eu related properties to the sseu_dev_info struct. No functional change. v2: - s/info/sseu/ based on the new struct name. (Ben) Reviewed-by: Robert Bragg <robert@sixbynine.org> (v1) Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1) Tested-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1) Signed-off-by: NImre Deak <imre.deak@intel.com>
-
由 Imre Deak 提交于
The data in this struct is provided both by getting the slice/subslice/eu features available on a given platform and the actual runtime state of these same features which depends on the HW's current power saving state. Atm members of this struct are duplicated in sseu_dev_status and intel_device_info. For clarity and code reuse we can share one struct for both of the above purposes. This patch only moves the struct to the header file, the next patch will convert users of intel_device_info to use this struct too. Instead of unsigned int u8 is used now, which is big enough and is used anyway in intel_device_info. No functional change. v2: - s/stat/sseu/ based on the new struct name (Ben) Reviewed-by: Robert Bragg <robert@sixbynine.org> (v1) Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1) Tested-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1) Signed-off-by: NImre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1472659987-10417-2-git-send-email-imre.deak@intel.com
-
由 Daniel Vetter 提交于
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 01 9月, 2016 1 次提交
-
-
由 Joonas Lahtinen 提交于
Use atomic type and operands for dev_priv->mm.bsd_engine_dispatch_index to avoid one struct_mutex locking scenario. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Cc: Zhao Yakui <yakui.zhao@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1472731101-21982-1-git-send-email-joonas.lahtinen@linux.intel.com
-
- 29 8月, 2016 1 次提交
-
-
由 Maarten Lankhorst 提交于
The mentioned commit changes intel_display_crc_init to take a dev_priv, but forgets to change the stub. Cc: David Weinehall <david.weinehall@linux.intel.com> Fixes: 36cdd013 ("drm/i915: debugfs spring cleaning") Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-and-by: NKim Lidström <kim@dxtr.im> Link: http://patchwork.freedesktop.org/patch/msgid/1472116022-17598-1-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
-
- 27 8月, 2016 1 次提交
-
-
由 Chris Wilson 提交于
Rather than walk the full array of engines checking whether each is in the mask in turn, we can use the mask to jump to the right engines. This should quicker for a sparse array of engines or mask, whilst generating smaller code: text data bss dec hex filename 1251010 4579 800 1256389 132bc5 drivers/gpu/drm/i915/i915.ko 1250530 4579 800 1255909 1329e5 drivers/gpu/drm/i915/i915.ko The downside is that we have to pass in a temporary, alas no C99 iterators yet. [P.S. Joonas doesn't like having to pass extra temporaries into the macro, and even less that I called them tmp. As yet, we haven't found a macro that avoids passing in a temporary that is smaller. We probably will get C99 iterators first!] Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160827075401.16470-2-chris@chris-wilson.co.uk
-
- 26 8月, 2016 1 次提交
-
-
由 Chris Wilson 提交于
Now that we have working partial VMA and faulting support for all objects, including fence support, advertise to userspace that it can take advantage of unlimited GGTT mmaps. v2: Make room in the kerneldoc for a more detailed explanation of the limitations of the GTT mmap interface. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20160825180519.11341-1-chris@chris-wilson.co.uk
-
- 25 8月, 2016 1 次提交
-
-
由 Lyude 提交于
Since we have to write ddb allocations at the same time as we do other plane updates, we're going to need to be able to control the order in which we execute modesets on each pipe. The easiest way to do this is to just factor this section of intel_atomic_commit_tail() (intel_atomic_commit() for stable branches) into it's own function, and add an appropriate display function hook for it. Based off of Matt Rope's suggestions Changes since v1: - Drop pipe_config->base.active check in intel_update_crtcs() since we check that before calling the function Signed-off-by: NLyude <cpaul@redhat.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> [omitting CC for stable, since this patch will need to be changed for such backports first] Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: NLyude <cpaul@redhat.com> Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1471961565-28540-1-git-send-email-cpaul@redhat.com
-
- 23 8月, 2016 1 次提交
-
-
由 Maarten Lankhorst 提交于
This is required for supporting nonblocking modesets. Iterating over the connector list will no longer be allowed when we don't hold connection_mutex, so we have to use the atomic state. Fix disable_noatomic by populating the minimal state required to disable a connector. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-3-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 22 8月, 2016 6 次提交
-
-
由 David Weinehall 提交于
Just like with sysfs, we do some major overhaul. Pass dev_priv instead of dev to all feature macros (IS_, HAS_, INTEL_, etc.). This has the side effect that a bunch of functions now get dev_priv passed instead of dev. All calls to INTEL_INFO()->gen have been replaced with INTEL_GEN(). We want access to to_i915(node->minor->dev) in a lot of places, so add the node_to_i915() helper to accommodate for this. Finally, we have quite a few cases where we get a void * pointer, and need to cast it to drm_device *, only to run to_i915() on it. Add cast_to_i915() to do this. v2: Don't introduce extra dev (Chris) v3: Make pipe_crc_info have a pointer to drm_i915_private instead of drm_device. This saves a bit of space, since we never use drm_device anywhere in these functions. Also some minor fixup that I missed in the previous version. v4: Changed the code a bit so that dev_priv is passed directly to various functions, thus removing the need for the cast_to_i915() helper. Also did some additional cleanup. v5: Additional cleanup of newly introduced changes. v6: Rebase again because of conflict. Signed-off-by: NDavid Weinehall <david.weinehall@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160822105931.pcbe2lpsgzckzboa@boomReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 David Weinehall 提交于
Various cleanup for i915_sysfs.c; we now use dev_priv whenever possible. The kdev_to_drm_minor() helper function has been replaced by one that converts from struct device * to struct drm_i915_private *. We already have a seemingly identical helper (kdev_to_i915()) in i915_drv.h. But that one cannot be used here. Unlike the version in i915_drv.h, this helper reaches i915 through drm_minor. v2: Rename kdev_to_i915_dm() to kdev_minor_to_i915() (Chris) Signed-off-by: NDavid Weinehall <david.weinehall@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160822103245.24069-4-david.weinehall@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 David Weinehall 提交于
We currently have a mix of struct device *device, struct device *kdev, and struct device *dev (the latter forcing us to refer to struct drm_device as something else than the normal dev). To simplify things, always use kdev when referring to struct device. v2: Replace the dev_to_drm_minor() macro with the inline function kdev_to_drm_minor(). Signed-off-by: NDavid Weinehall <david.weinehall@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160822103245.24069-3-david.weinehall@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 David Weinehall 提交于
Fix minor whitespace issues plus a typo. Signed-off-by: NDavid Weinehall <david.weinehall@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160822103245.24069-2-david.weinehall@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Lyude 提交于
Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this however, is the mysterious issue of underruns causing full system hangs. An easy way to reproduce this with a skylake system: - Get a laptop with a skylake GPU, and hook up two external monitors to it - Move the cursor from the built-in LCD to one of the external displays as quickly as you can - You'll get a few pipe underruns, and eventually the entire system will just freeze. After doing a lot of investigation and reading through the bspec, I found the existence of the SAGV, which is responsible for adjusting the system agent voltage and clock frequencies depending on how much power we need. According to the bspec: "The display engine access to system memory is blocked during the adjustment time. SAGV defaults to enabled. Software must use the GT-driver pcode mailbox to disable SAGV when the display engine is not able to tolerate the blocking time." The rest of the bspec goes on to explain that software can simply leave the SAGV enabled, and disable it when we use interlaced pipes/have more then one pipe active. Sure enough, with this patchset the system hangs resulting from pipe underruns on Skylake have completely vanished on my T460s. Additionally, the bspec mentions turning off the SAGV with more then one pipe enabled as a workaround for display underruns. While this patch doesn't entirely fix that, it looks like it does improve the situation a little bit so it's likely this is going to be required to make watermarks on Skylake fully functional. This will still need additional work in the future: we shouldn't be enabling the SAGV if any of the currently enabled planes can't enable WM levels that introduce latencies >= 30 µs. Changes since v11: - Add skl_can_enable_sagv() - Make sure we don't enable SAGV when not all planes can enable watermarks >= the SAGV engine block time. I was originally going to save this for later, but I recently managed to run into a machine that was having problems with a single pipe configuration + SAGV. - Make comparisons to I915_SKL_SAGV_NOT_CONTROLLED explicit - Change I915_SAGV_DYNAMIC_FREQ to I915_SAGV_ENABLE - Move printks outside of mutexes - Don't print error messages twice Changes since v10: - Apparently sandybridge_pcode_read actually writes values and reads them back, despite it's misleading function name. This means we've been doing this mostly wrong and have been writing garbage to the SAGV control. Because of this, we no longer attempt to read the SAGV status during initialization (since there are no helpers for this). - mlankhorst noticed that this patch was breaking on some very early pre-release Skylake machines, which apparently don't allow you to disable the SAGV. To prevent machines from failing tests due to SAGV errors, if the first time we try to control the SAGV results in the mailbox indicating an invalid command, we just disable future attempts to control the SAGV state by setting dev_priv->skl_sagv_status to I915_SKL_SAGV_NOT_CONTROLLED and make a note of it in dmesg. - Move mutex_unlock() a little higher in skl_enable_sagv(). This doesn't actually fix anything, but lets us release the lock a little sooner since we're finished with it. Changes since v9: - Only enable/disable sagv on Skylake Changes since v8: - Add intel_state->modeset guard to the conditional for skl_enable_sagv() Changes since v7: - Remove GEN9_SAGV_LOW_FREQ, replace with GEN9_SAGV_IS_ENABLED (that's all we use it for anyway) - Use GEN9_SAGV_IS_ENABLED instead of 0x1 for clarification - Fix a styling error that snuck past me Changes since v6: - Protect skl_enable_sagv() with intel_state->modeset conditional in intel_atomic_commit_tail() Changes since v5: - Don't use is_power_of_2. Makes things confusing - Don't use the old state to figure out whether or not to enable/disable the sagv, use the new one - Split the loop in skl_disable_sagv into it's own function - Move skl_sagv_enable/disable() calls into intel_atomic_commit_tail() Changes since v4: - Use is_power_of_2 against active_crtcs to check whether we have > 1 pipe enabled - Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0 enabled - Call skl_sagv_enable/disable() from pre/post-plane updates Changes since v3: - Use time_before() to compare timeout to jiffies Changes since v2: - Really apply minor style nitpicks to patch this time Changes since v1: - Added comments about this probably being one of the requirements to fixing Skylake's watermark issues - Minor style nitpicks from Matt Roper - Disable these functions on Broxton, since it doesn't have an SAGV Signed-off-by: NLyude <cpaul@redhat.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-3-git-send-email-cpaul@redhat.com [mlankhorst: ENOSYS -> ENXIO, whitespace fixes]
-
由 Daniel Vetter 提交于
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 20 8月, 2016 1 次提交
-
-
由 Chris Wilson 提交于
Very old numbers indicate this is a 66% improvement when remapping the entire object for fence contention - due to the elimination of track_pfn_insert and its strcmp. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Testcase: igt/gem_fence_upload/performance Testcase: igt/gem_mmap_gtt Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160819155428.1670-6-chris@chris-wilson.co.uk
-
- 19 8月, 2016 6 次提交
-
-
由 Dave Gordon 提交于
In the recent patch bc3d6744 drm/i915: Allow userspace to request no-error-capture upon ... the final version moved the flags and the associated #defines around so they were adjacent; unfortunately, they ended up between a comment and the thing (hw_id) to which the comment applies :( So this patch reshuffles the comment and subject back together. Also, as we're touching 'hw_id', let's change it from just 'unsigned' to a fully-specified 'unsigned int', because some code checking tools (including checkpatch) object to plain 'unsigned'. Fixes: bc3d6744 ("drm/i915: Allow userspace to request no-error-capture...") Signed-off-by: NDave Gordon <david.s.gordon@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1471616622-6919-1-git-send-email-david.s.gordon@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Chris Wilson 提交于
If the developer adds a register in the wrong order, we BUG during boot. That makes development and testing very difficult. Let's be a bit more friendly and disable the command parser with a big warning if the tables are invalid. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160818161718.27187-31-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
If FBC is set on a framebuffer that is unmapped, all GTT faults will be from a partial mapping. Writes by the user through the partial VMA are then untracked by the FBC and so we must use the ORIGIN_CPU when flushing the I915_GEM_DOMAIN_GTT. v2: Keep ORIGIN_CPU for set-to-domain(.write=CPU) Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160818161718.27187-25-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
In order to handle tiled partial GTT mmappings, we need to associate the fence with an individual vma. v2: A couple of silly drops replaced spotted by Joonas Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160818161718.27187-21-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Our current practice is to only name the actual list (here dev_priv->fence_list) using "list", and elements upon that list are referred to as "link". Further, the lru nature is of the list and not of the node and including in the name does not disambiguate the link from anything else. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160818161718.27187-20-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
By moving map-and-fenceable tracking from the object to the VMA, we gain fine-grained tracking and the ability to track individual fences on the VMA (subsequent patch). Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160818161718.27187-16-chris@chris-wilson.co.uk
-