- 08 Aug, 2013 13 commits
-
-
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
-
Damien Lespiau authored
From CEA-861: Data Byte 1, bit A0 indicates whether Active Format Data is present in Data Byte 2 bits R3 through R0. A source device shall set A0=1 when any of the AFD bits are set. ie. if we want to set active_aspect, we need to set the active_info_valid bit to 1 as well. Cc: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by:
Dave Airlie <airlied@gmail.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Damien Lespiau authored
If the user if this API is providing a bigger buffer than the infoframe size, it could be for a could reason. For instance it could be because it gives the buffer that will be written to the hardware, up to the maximum of an infoframe size. Instead of just zeroing up to the infoframe size, let's zero the whole incoming buffer as those extra bytes are also used to compute the ECC and need to be 0. Signed-off-by:
-
Damien Lespiau authored
Cc: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by:
-
Damien Lespiau authored
And a way to pack hdmi_infoframe generically. Cc: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by:
-
Damien Lespiau authored
Cc: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by:
-
Ben Widawsky authored
In some places, we want to know if an object is bound in any address space, and not just the global GTT. This often applies when there is a single global resource (object, pages, etc.) function | reason -------------------------------------------------- i915_gem_object_is_inactive | global object i915_gem_object_put_pages | object's pages 915_gem_object_unpin | global object i915_gem_execbuffer_unreserve_object | temporary until we plumb vma pread/pwrite | see the note below Note: set_to_gtt_domain in pwrite/pread is abused as a wait_rendering call - but that once only worked if the object is bound. We really should replace this with a plain wait_rendering call, which would have the upside that in pread it would be clearer that we actually only wait for oustanding gpu writes. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> [danvet: Explain the set_to_gtt_domain in pwrite/pread and volunteer Ben to replace those with wait_rendering calls.] Signed-off-by:
-
Ben Widawsky authored
Eviction code, like the rest of the converted code needs to be aware of the address space for which it is evicting (or the everything case, all addresses). With the updated bind/unbind interfaces of the last patch, we can now safely move the eviction code over. Signed-off-by:
-
Ben Widawsky authored
As alluded to in several patches, and it will be reiterated later... A VMA is an abstraction for a GEM BO bound into an address space. Therefore it stands to reason, that the existing bind, and unbind are the ones which will be the most impacted. This patch implements this, and updates all callers which weren't already updated in the series (because it was too messy). This patch represents the bulk of an earlier, larger patch. I've pulled out a bunch of things by the request of Daniel. The history is preserved for posterity with the email convention of ">" One big change from the original patch aside from a bunch of cropping is I've created an i915_vma_unbind() function. That is because we always have the VMA anyway, and doing an extra lookup is useful. There is a caveat, we retain an i915_gem_object_ggtt_unbind, for the global cases which might not talk in VMAs. > drm/i915: plumb VM into object operations > > This patch was formerly known as: > "drm/i915: Create VMAs (part 3) - plumbing" > > This patch adds a VM argument, bind/unbind, and the object > offset/size/color getters/setters. It preserves the old ggtt helper > functions because things still need, and will continue to need them. > > Some code will still need to be ported over after this. > > v2: Fix purge to pick an object and unbind all vmas > This was doable because of the global bound list change. > > v3: With the commit to actually pin/unpin pages in place, there is no > longer a need to check if unbind succeeded before calling put_pages(). > Make put_pages only BUG() after checking pin count. > > v4: Rebased on top of the new hangcheck work by Mika > plumbed eb_destroy also > Many checkpatch related fixes > > v5: Very large rebase > > v6: > Change BUG_ON to WARN_ON (Daniel) > Rename vm to ggtt in preallocate stolen, since it is always ggtt when > dealing with stolen memory. (Daniel) > list_for_each will short-circuit already (Daniel) > remove superflous space (Daniel) > Use per object list of vmas (Daniel) > Make obj_bound_any() use obj_bound for each vm (Ben) > s/bind_to_gtt/bind_to_vm/ (Ben) > > Fixed up the inactive shrinker. As Daniel noticed the code could > potentially count the same object multiple times. While it's not > possible in the current case, since 1 object can only ever be bound into > 1 address space thus far - we may as well try to get something more > future proof in place now. With a prep patch before this to switch over > to using the bound list + inactive check, we're now able to carry that > forward for every address space an object is bound into. Signed-off-by:
-
Ben Widawsky authored
In order to do this for all VMs, it's convenient to rework the logic a bit. This should have no functional impact. Signed-off-by:
-
- 06 Aug, 2013 5 commits
-
-
Ben Widawsky authored
Signed-off-by:
-
Chris Wilson authored
Rather than open-code the teardown of a framebuffer, export the routine from intel_display.c. This then make intel_fbdev symmetric in its use of the common intel_framebuffer routines to initialise and clean up the struct intel_framebuffer. (And new features need only be added in one location!) Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Chris Wilson authored
MLC_LLC was never validated for Sandybridge and was superseded by a new level of cacheing for the GPU in Ivybridge. Update our names to be consistent with usage, and in the process stop setting the unwanted bit on Sandybridge. Signed-off-by:
-
Paulo Zanoni authored
We set the mode based on the port, and we already pass the port as an argument. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Paulo Zanoni authored
These messages are not really useful since it's very easy to check which mode is used for each port: The values programmed are based on the port type, then assigned to the ddi_translations variable. Currently we use DP mode for ports A-D and FDI mode for port E. Also, when we add the code to enable/disable PC8+, intel_prepare_ddi_buffers will be called more often and will eat your dmesg buffers. While at it, fix the coding style of the "for" statement above. Signed-off-by:
-
- 05 Aug, 2013 22 commits
-
-
Ben Widawsky authored
The code itself is no longer accurate without updating once we have multiple address space since clearing the domains of every object requires scanning the inactive list for all VMs. "This code is dead. Just remove it rather than port it to vma." - Chris Wilson Recommended-by:
Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by:
-
Ville Syrjälä authored
All the ILK+ WM compute functions take the latency values in 0.1us units. Add a few comments to remind people about that. Signed-off-by:
-
Ville Syrjälä authored
Adjust the current ILK/SNB/IVB watermark codepaths to use the pre-populated latency values from dev_priv instead of reading them out from the registers every time. Signed-off-by:
-
Ville Syrjälä authored
Return UINT_MAX for the calculated WM level if the latency is zero. This will lead to marking the WM level as disabled. I'm not sure if latency==0 should mean that we want to disable the level. But that's the implication I got from the fact that we don't even enable the watermark code of the SSKDP register is 0. v2: Use WARN() to scare people Signed-off-by:
-
Ville Syrjälä authored
Seeing the watermark latency values in dmesg might help sometimes. v2: Use DRM_ERROR() when expected latency values are missing Note: We might hit the DRM_ERROR added in this patch and apparently there's not much we can do about that. But I think it'd be interesting to figure out whether that actually happens in the real world, so I didn't apply a s/DRM_ERROR/DRM_DEBUG_KMS/ bikeshed while applying. Signed-off-by:
-
Ville Syrjälä authored
Rather than pass around the plane latencies, just grab them from dev_priv nearer to where they're needed. Do the same for cursor latencies. v2: Add some comments about latency units Signed-off-by:
-
Ville Syrjälä authored
Rather than having to read the latency values out every time, just store them in dev_priv. On ILK and IVB there is a difference between some of the latency values for different planes, so store the latency values for each plane type separately, and apply the necesary fixups during init. v2: Fix some checkpatch complaints Signed-off-by:
-
Ville Syrjälä authored
ILK has a slightly different way to read out the watermark latency values. On ILK the LP0 latenciy values are in fact not stored in any register, and instead we must use fixed values. Signed-off-by:
-
Ben Widawsky authored
Hangcheck, and some of the recent reset code for guilty batches need to know which address space the object was in at the time of a hangcheck. This is because we use offsets in the (PP|G)GTT to determine this information, and those offsets can differ depending on which VM they are bound into. Since we still only have 1 VM ever, this code shouldn't yet have any impact. Signed-off-by:
-
Ben Widawsky authored
With multiple VMs, the eviction code benefits from being able to blindly put pages without needing to know if there are any entities still holding on to those pages. As such it's preferable to return the -EBUSY before the BUG. Eviction code is the only user for now, but overall it makes sense anyway, IMO. Signed-off-by:
-
Ben Widawsky authored
For now, objects will maintain the same cache levels amongst all address spaces. This is to limit the risk of bugs, as playing with cacheability in the different domains can be very error prone. In the future, it may be optimal to allow setting domains per VMA (ie. an object bound into an address space). Signed-off-by:
-
Ben Widawsky authored
This represents the first half of hooking up VMs to execbuf. Here we basically pass an address space all around to the different internal functions. It should be much more readable, and have less risk than the second half, which begins switching over to using VMAs instead of an obj,vm. The overall series echoes this style of, "add a VM, then make it smart later" Signed-off-by:
-
Ben Widawsky authored
Make it aware of which domain it is bound into GGTT, or PPGTT. While modifying the function, add a global gtt flag to the object description. Global is more interesting than aliasing since aliasing is the default. v2: Access VMA directly for start/size instead of helpers (Daniel) Signed-off-by:
-
Ben Widawsky authored
Just some small cleanups, and a rename of vm->ggtt_vm requested by Daniel. Signed-off-by:
-
Ben Widawsky authored
To verbalize it, one can say, "pin an object into the given address space." The semantics of pinning remain the same otherwise. Certain objects will always have to be bound into the global GTT. Therefore, global GTT is a special case, and keep a special interface around for it (i915_gem_obj_ggtt_pin). v2: s/i915_gem_ggtt_pin/i915_gem_obj_ggtt_pin Signed-off-by:
-
Ben Widawsky authored
Do to the move active/inactive lists, it no longer makes sense to use them for shrinking, since shrinking isn't VM specific (such a need may also exist, but doesn't yet). What we can do instead is use the global bound list to find all objects which aren't active. Signed-off-by:
-
Ben Widawsky authored
Earlier in the conversion sequence we attempted to quickly wedge in the transitional interface as static inlines. Now that we're sure these interfaces are sane, for easier debug and to decrease code size (since many of these functions may be called quite a bit), make them real functions While at it, kill off the set_color interface. We'll always have the VMA, or easily get to it. Signed-off-by:
-
Ben Widawsky authored
With an upcoming change to bind, to make checkpatch happy and keep the code clean, we need to rework this code a bit. This should have no functional impact. Signed-off-by:
-
Ben Widawsky authored
Move all the similar address space (VM) initialization code to one function. Until we have multiple VMs, there should only ever be 1 VM. The aliasing ppgtt is a special case without it's own VM (since it doesn't need it's own address space management). Signed-off-by:
-
Ben Widawsky authored
The default LLC age was changed: commit 0d8ff15e Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Thu Jul 4 11:02:03 2013 -0700 drm/i915/hsw: Set correct Haswell PTE encodings. On the surface it would seem setting a default age wouldn't matter because all GEM BOs are aged similarly, so the order in which objects are evicted would not be subject to aging. The current working theory as to why this caused a regression though is that LLC is a bit special in that it is shared with the CPU. Presumably (not verified) the CPU fetches cachelines with age 3, and therefore recently cached GPU objects would be evicted before similar CPU object first when the LLC is full. It stands to reason therefore that this would negatively impact CPU bound benchmarks - but those seem to be low on the priority list. eLLC OTOH does not have this same property as LLC. It should be used entirely for the GPU, and so the age really shouldn't matter. Furthermore, we have no evidence to suggest one is better than another on eLLC. Since we've never properly supported eLLC before no, there should be no regression. If the GPU client really wants "younger" objects, they should use MOCS. v2: Drop the extra #define (Chad) v3: Actually git add v4: Pimped commit message Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67062Signed-off-by:
Chad Versace <chad.versace@linux.intel.com> Signed-off-by:
-
Peter Wu authored
Since commit 29a241cc (ACPICA: Add argument typechecking for all predefined ACPI names), _DSM parameters are validated which trigger the following warning: ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95) ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95) ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95) ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95) As the Intel _DSM method seems to ignore this parameter, let's comply to the ACPI spec and use a Package instead. Signed-off-by:
Peter Wu <lekensteyn@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32602Signed-off-by:
-
Imre Deak authored
Userspace can pass a mode with an unspecified vsync/hsync polarity setting. All encoders in the Intel driver take this to mean a negative polarity setting. The HW readout/state checker code on the other hand needs these flags to be explicitly set, otherwise the state checker will WARN about the mismatch. Get rid of the WARN by making the polarity setting explicit in the adjusted mode flags based on the requested mode flags. This will keep the existing behavior otherwise. Note that we could guess from the other timing parameters whether the user wanted a VESA or other standard mode and set the polarity accordingly. This is what the NV driver does (drivers/gpu/drm/nouveau/dispnv04/crtc.c), but I think that's not very exact and would change the existing behavior of the Intel driver. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65442Signed-off-by:
Imre Deak <imre.deak@intel.com> Tested-by:
cancan,feng <cancan.feng@intel.com> Reviewed-by:
-
