- 10 Aug, 2013 3 commits
-
-
Chris Wilson authored
As mentioned in the previous commit, reads and writes from both the CPU and GPU go through the LLC. This gives us coherency between the CPU and GPU irrespective of the attribute settings either device sets. We can use to avoid having to clflush even uncached memory. Except for the scanout. The scanout resides within another functional block that does not use the LLC but reads directly from main memory. So in order to maintain coherency with the scanout, writes to uncached memory must be flushed. In order to optimize writes elsewhere, we start tracking whether an framebuffer is attached to an object. v2: Use pin_display tracking rather than fb_count (to ensure we flush cursors as well etc) and only force the clflush along explicit writes to the scanout paths (i.e. pin_to_display_plane and pwrite into scanout). v3: Force the flush after hitting the slowpath in pwrite, as after dropping the lock the object's cache domain may be invalidated. (Ville) Based on a patch by Ville Syrjälä. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
The display engine has unique coherency rules such that it requires special handling to ensure that all writes to cursors, scanouts and sprites are clflushed. This patch introduces the infrastructure to simply track when an object is being accessed by the display engine. v2: Explain the is_pin_display() magic as the sources for obj->pin_count and their individual rules is not obvious. (Ville) Signed-off-by:
-
Chris Wilson authored
The LLC is a fun device. The cache is a distinct functional block within the SA that arbitrates access from both the CPU and GPU cores. As such all writes to memory land first in the LLC before further action is taken. For example, an uncached write from either the CPU or GPU will then proceed to memory and evict the cacheline from the LLC. This means that a read from the LLC always returns the correct information even if the PTE bit in the GPU differs from the PAT bit in the CPU. For the older snooping architecture on non-LLC, the fundamental principle still holds except that some coordination is required between the CPU and GPU to explicitly perform the snooping (which is handled by our request tracking). The upshot of this is that we know that we can issue a read from either LLC devices or snoopable memory and trust the contents of the cache - i.e. we can forgo a clflush before a read in these circumstances. Writing to memory from the CPU is a little more tricky as we have to consider that the scanout does not read from the CPU cache at all, but from main memory. So we have to currently treat all requests to write to uncached memory as having to be flushed to main memory for coherency with all consumers. Signed-off-by:
-
- 09 Aug, 2013 11 commits
-
-
Ville Syrjälä authored
Due to a misplaced memset(), we never actually enabled the FBC WM on HSW. Move the memset() to happen a bit earlier, so that it won't clobber results->enable_fbc_wm. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Jesse Barnes authored
Ryan noticed that on his board, HDMI was wired up to port C but not exposed by the kernel, which had only expected DP on that port. Fix that up by enumerating both ports if possible. Tested-by:
"Matsumura, Ryan" <ryan.matsumura@intel.com> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Fix up the whitespace fail. Tsk.] Signed-off-by:
-
Dan Carpenter authored
The '!' here was not intended. Since '!' has higher precedence than compare, it means the check is never true. This regression was introduced in commit 71fff20f Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Aug 6 22:24:03 2013 +0300 drm/i915: Kill fbc_enable from hsw_lp_wm_results Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Dan Carpenter authored
There is an extra semi-colon here so we just leak and never unbind anything. This regression has been introduced in commit 07fe0b12 Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Jul 31 17:00:10 2013 -0700 drm/i915: plumb VM into bind/unbind code Cc: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Damien Lespiau authored
Caught by the dead code police! Signed-off-by:
-
Damien Lespiau authored
And also fix a small typo in the intel_encoder_dpms() comment. Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Did you say OCD? Signed-off-by:
-
Damien Lespiau authored
This code was dead since: commit 432e58ed Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Nov 25 19:32:06 2010 +0000 drm/i915: Avoid allocation for execbuffer object list so just put it to rest for good. Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
- 08 Aug, 2013 26 commits
-
-
Chris Wilson authored
I was curious as to what objects were currently allocated from stolen memory, and so exported it from debugfs. Signed-off-by:
-
Ville Syrjälä authored
ILK and VLV codepaths didn't update sprite watermarks when disabling a sprite. Make them do that. Signed-off-by:
-
Ville Syrjälä authored
We're going to want to know the crtc in the watermark code to avoid doing more work than we have to. We should also pass the plane we're disabling so that we know where to stick our watermark parameters without having to go look the plane up. Signed-off-by:
-
Ville Syrjälä authored
Check plane->fb in intel_disable_plane() to determine if the plane is already disabled. If the plane has an fb, then it must also have a crtc, so we can drop the plane->crtc check and just call intel_enable_primary() directly. v2: WARN and bail if the plane doesn't have a crtc when it should Signed-off-by:
-
Ville Syrjälä authored
We're going to want to know which CRTC we're dealing with, so pass it down to the update/disable_plane hooks. Signed-off-by:
-
Ville Syrjälä authored
Give a name to the plane watermark related data we have currently stored under intel_plane->wm. We also observe that this data is more or less the same that we have in the hsw_pipe_wm_parameters structure, so use it there as well. v2: Make pahole happier Reviewed-by:
-
Ville Syrjälä authored
There is a bunch of global state that needs to be considered when checking watermarks for validity. Move most of that to a new structure intel_wm_config, to avoid having to pass around so many variables. One notable thing left out is the DDB partitioning information, since we often anyway need to check the same watermarks against both 1/2 and 5/6 DDB partitioning layouts. v2: s/pipes_active/num_pipes_active Reviewed-by:
-
Ville Syrjälä authored
There are quite a few variables we need to take into account to determine the maximum watermark levels, so it feels a bit cleaner to calculate those rather than just have a bunch of what look like magic numbers. v2: s/pipes_active/num_pipes_active s/othwewise/otherwise Reviewed-by: -
Ville Syrjälä authored
Let's call hsw_lp_wm_result intel_wm_level from now on and move it to i915_drv.h for later use. Signed-off-by:
-
Ville Syrjälä authored
Refactor the code a bit to split the watermark level validity check into a separate function. Also add hack there that allows us to use it even for LP0 watermarks. ATM we don't pre-compute/check the LP0 watermarks, so we just have to clamp them to the maximum and hope things work out. v2: Add some debug prints when we exceed max WM0 Kill pointless ret = false' assignment. Include the check for the already disabled 'result' which got shuffled around when the patchs got reorderd Signed-off-by: -
Ben Widawsky authored
With the current code there shouldn't be a distinction - however with an upcoming change we intend to allocate a vma much earlier, before it's actually bound anywhere. To do this we have to check node allocation as well for the _bound() check. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> [danvet: move list_del(&vma->vma_link) from vma_unbind to vma_destroy, again fallout from the loss of "rm/i915: Cleanup more of VMA in destroy".] Signed-off-by:
-
Ben Widawsky authored
formerly: "drm/i915: Create VMAs (part 4) - Error capture" Since the active/inactive lists are per VM, we need to modify the error capture code to be aware of this, and also extend it to capture the buffers from all the VMs. For now all the code assumes only 1 VM, but it will become more generic over the next few patches. NOTE: If the number of VMs in a real world system grows significantly we'll have to focus on only capturing the guilty VM, or else it's likely there won't be enough space for error capture. v2: Squashed in the "part 6" which had dependencies on the mm_list change. Since I've moved the mm_list change to an earlier point in the series, we were able to accomplish it here and now. v3: Rebased over new error capture Signed-off-by:
-
Ben Widawsky authored
formerly: "drm/i915: Create VMAs (part 5) - move mm_list" The mm_list is used for the active/inactive LRUs. Since those LRUs are per address space, the link should be per VMx . Because we'll only ever have 1 VMA before this point, it's not incorrect to defer this change until this point in the patch series, and doing it here makes the change much easier to understand. Shamelessly manipulated out of Daniel: "active/inactive stuff is used by eviction when we run out of address space, so needs to be per-vma and per-address space. Bound/unbound otoh is used by the shrinker which only cares about the amount of memory used and not one bit about in which address space this memory is all used in. Of course to actual kick out an object we need to unbind it from every address space, but for that we have the per-object list of vmas." v2: only bump GGTT LRU in i915_gem_object_set_to_gtt_domain (Chris) v3: Moved earlier in the series v4: Add dropped message from v3 Signed-off-by:
-
Ben Widawsky authored
formerly: "drm/i915: Create VMAs (part 3.5) - map and fenceable tracking" The map_and_fenceable tracking is per object. GTT mapping, and fences only apply to global GTT. As such, object operations which are not performed on the global GTT should not effect mappable or fenceable characteristics. Functionally, this commit could very well be squashed in to a previous patch which updated object operations to take a VM argument. This commit is split out because it's a bit tricky (or at least it was for me). Signed-off-by:
-
Ville Syrjälä authored
drivers/gpu/drm/i915/i915_debugfs.c:2136:3: warning: symbol 'i915_debugfs_files' was not declared. Should it be static? Signed-off-by:
-
Ville Syrjälä authored
We're going to use the 1/2 vs. 5/6 split option already on IVB so the HSW name is not proper. Just give it an intel_ prefix and move it to i915_drv.h so that we can use it there later. Signed-off-by:
-
Ville Syrjälä authored
We don't need to store the FBC WM enabled status in each watermark level. We anyway have to reduce it down to a single boolean, so just delay checking the FBC WM limit until we're computing the final value. Signed-off-by:
-
Ville Syrjälä authored
Refactor the watermarks computation for one level to a separate function. This function will now set the ->enable flag to true, even if the watermark level wasn't actually checked yet. In the future we will delay the checking so we must consider all unchecked watermarks as possibly valid. v2: Preserve comment about latency units Signed-off-by:
-
Ville Syrjälä authored
Let's be consistent and always call our variables 'enabled' insted of the occasional 'enable'. Signed-off-by:
-
Damien Lespiau authored
set_frame() wraps the write_frame() vfunc. Be consistent and name the wrapping function like the vfunc being called. It's doubly confusing as we also have a set_infoframes() vfunc and set_infoframe() doesn't wrap it. Reviewed-by:
-
Damien Lespiau authored
I cannot find any evidence what we shouldn't try to set those fields when setting a non-CEA mode on an HDMI sink. So just kill that return. Suggested-by:
Dave Airlie <airlied@gmail.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Damien Lespiau authored
Suggested-by:
-
Damien Lespiau authored
All the HDMI infoframe code has been ported to use video/hdmi.c, so it's time to say bye bye to this code. Reviewed-by:
-
Damien Lespiau authored
Reviewed-by:
-
Damien Lespiau authored
Let's use the drivers/video/hmdi.c and drm infoframe helpers to build our infoframes. v2: Simplify the logic to compute the buffer size. We can just take the maximum infoframe size rounded to 32, which happens to be what the hardware let us write anyway. v3: Remove unnecessary memset() (Ville Syrjälä) Signed-off-by:
-
Damien Lespiau authored
First step in the move to the shared infoframe infrastructure, let's move the different infoframe helpers and the write_infoframe() vfunc to a type (enum hdmi_infoframe_type) and a buffer + len instead of using our struct dip_infoframe. v2: constify the infoframe pointer and don't mix signs (Ville Syrjälä) Signed-off-by:
-
