- 05 Aug, 2013 35 commits
-
-
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ä <ville.syrjala@linux.intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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 <ben@bwidawsk.net> 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:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Jani Nikula authored
VLV wants encoder enabling before the pipe is up. With the previously rearranged VLV DP and HDMI ->pre_enable and ->enable callbacks in place, this no longer depends on the early ->enable hook call. Move the ->enable call at the end of the sequence, similar to the crtc enable on other platforms. This will be needed e.g. for moving the eDP backlight enabling to the right place in the sequence, currently done too early on VLV. There should be no functional changes. v2: Rebase. v3: Explain why this is needed in the commit message (Chris). Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Jani Nikula authored
VLV wants encoder enabling before the pipe is up. This is currently achieved through calling the ->enable callback early, right after the ->pre_enable callback, in valleyview_crtc_enable(). This loses both the distinction between ->pre_enable and ->enable on VLV and the possibility to use a hook at the end of the modeset sequence. Rearrange the HDMI callbacks to make it possible to move ->enable call later. Basically do everything in ->pre_enable on VLV, and make ->enable a NOP. There should be no functional changes. v2: Rebase. v3: Explain why this is needed in the commit message (Chris). Signed-off-by:
-
Jani Nikula authored
VLV wants encoder enabling before the pipe is up. This is currently achieved through calling the ->enable callback early, right after the ->pre_enable callback, in valleyview_crtc_enable(). This loses both the distinction between ->pre_enable and ->enable on VLV and the possibility to use a hook at the end of the modeset sequence. Rearrange the DP callbacks to make it possible to move ->enable call later. Basically do everything in ->pre_enable on VLV, and make ->enable a NOP. There should be no functional changes. v2: Rebase. v3: Explain why this is needed in the commit message (Chris). Signed-off-by:
-
Chris Wilson authored
Otherwise we get flooded by the kernel warning us that we are doing long sequences of IO without serialisation. For example, WARNING: CPU: 0 PID: 11136 at drivers/gpu/drm/i915/intel_sideband.c:40 vlv_sideband_rw+0x48/0x1ef() Modules linked in: CPU: 0 PID: 11136 Comm: kworker/u2:0 Tainted: G W 3.11.0-rc2+ #4 Call Trace: [<c2028564>] ? warn_slowpath_common+0x63/0x78 [<c227ad43>] ? vlv_sideband_rw+0x48/0x1ef [<c20285dd>] ? warn_slowpath_null+0xf/0x13 [<c227ad43>] ? vlv_sideband_rw+0x48/0x1ef [<c227b060>] ? vlv_dpio_write+0x1c/0x21 [<c2262b3b>] ? intel_dp_set_signal_levels+0x24a/0x385 [<c2264909>] ? intel_dp_complete_link_train+0x25/0x1d1 [<c2264c55>] ? intel_dp_check_link_status+0xf7/0x106 [<c2238ced>] ? i915_hotplug_work_func+0x17b/0x221 [<c203a204>] ? process_one_work+0x12e/0x210 [<c203a5e4>] ? worker_thread+0x116/0x1ad [<c203a4ce>] ? rescuer_thread+0x1cb/0x1cb [<c203d8f5>] ? kthread+0x67/0x6c [<c2457ebb>] ? ret_from_kernel_thread+0x1b/0x30 [<c203d88e>] ? init_completion+0x18/0x18 v2: Retire the locking in vlv_crtc_enable() and do it close to the meat. Signed-off-by:
-
Jesse Barnes authored
Art confirms that this should work fine. Since most panels are 18bpp with dithering from 24bpp, the existing code wouldn't be enabled in most cases. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
-
Ville Syrjälä authored
SNB and IVB have slightly a different way to read out the watermark latency values. Signed-off-by:
-
Ville Syrjälä authored
The LP1+ watermark latency values need to be multiplied by 5 to make them suitable for watermark calculations. However on pre-HSW platforms we're going to need the raw value later when we have to write it to the WM_LPn registers' latency field. So delay the multiplication until it's needed. Note: Paulo complains that the units of wm (now in 100ns) aren't really clear and I agree. But that can be fixed later on ... Signed-off-by:
-
Ville Syrjälä authored
Move parsing of MCH_SSKPD to a separate function, we'll add other platforms there later. Note: Chris spotted an empty struct initializer and wondered whether that is hiding a compilier warning. Ville explained that it should have been part of the patch that extends this function to snb/ivb, which don't have all levels hsw has. I've figured it's ok to keep it here with a small note. Signed-off-by:
-
Ville Syrjälä authored
The latency values fit in uint16_t, so let's save a few bytes. Signed-off-by:
-
Ville Syrjälä authored
The FBC watermark doesn't depend on the latency value, so no point in passing it in. Note: It actually depends upon the latency, but only through priv_val ... Signed-off-by:
-
Ville Syrjälä authored
These functions are appropriate for everything since ILK. Signed-off-by:
-
Ville Syrjälä authored
hsw_wm_get_pixel_rate() isn't specific to HSW. In fact it should be made to handle all gens, but for now it depends on the PCH panel fitter state, so give it an ilk_ prefix. Signed-off-by:
-
Ville Syrjälä authored
Using the destination width in the sprite WM calculations isn't correct. We should be using the source width. Note: This doesn't affect hsw since it does not support sprite scaling. Signed-off-by:
-
Ville Syrjälä authored
Don't subtract one from the sprite width before watermark calculations. Signed-off-by:
-
Ville Syrjälä authored
For calculating watermarks we want to know whether sprites are scaled. Pass that information to update_sprite_watermarks() so that eventually we may do some watermark pre-computing. Signed-off-by:
-
Chris Wilson authored
Some of our macros we trying to convert from an drm_device to a drm_i915_private and then use the pointer inline. This is not only cumbersome but prone to error. Replacing it with a typesafe function should help catch those errors in future. Signed-off-by:
-
- 04 Aug, 2013 5 commits
-
-
Stéphane Marchesin authored
Signed-off-by:
Stéphane Marchesin <marcheu@chromium.org> Signed-off-by:
-
Chris Wilson authored
The PTE layouts are the same for both ppgtt and gtt, so we can simplify the setup for ppgtt by copying the encoding function pointer from gtt. This prevents bugs where we update one function pointer, but forget the other. For instance, commit 4d15c145 Author: Ben Widawsky <ben@bwidawsk.net> Date: Thu Jul 4 11:02:06 2013 -0700 drm/i915: Use eLLC/LLC by default when available only extends the gtt to use eLLC/LLC cacheing and forgets to also update the ppgtt function pointer. v2: Actually mention the bug being fixed (Kenneth) Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
-
Chris Wilson authored
Almost invariably the reason why FBC cannot be turned on is the same every time (disabled via parameter, too many pipes, pipe too large etc) as modesetting and framebuffer configuration changes less frequently than trying to enable FBC. Signed-off-by:
-
Daniel Vetter authored
In the old days of the crtc helpers we've only had the encoder and crtc ->mode_fixup callbacks. So when the lvds connector wanted to adjust the crtc timings it had to set a driver-private mode flag to tell the crtc mode fixup code to not overwrite them with the generic ones. When converting things to the new infrastructure I've kept the entire logic and only moved the flag to pipe_config->timings_set. But this logic is pretty tricky and already caused regressions: commit 21d8a475 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jul 12 08:07:30 2013 +0200 drm/i915: fix pfit regression for non-autoscaled resolutions So take advantage of the flexibility our own modeset infrastructure affords us and prefill default crtc timings. This allows us to rip out ->timings_set. Note that we overwrite things again when retrying the pipe config computation due to bandwidth constraints to avoid bogus crtc timings if the encoder only does relative adjustments (which is how the pfit code works). Only a theoretical concern though since platforms where we retry (pch-split platforms) do not need adjustements (since only the old gmch pfit needs that). But let's better be safe than sorry. Since we now initialize the crtc timings before calling the encoder->compute_config functions the crtc initialization in the gmch pfit code is now redudant and so can be removed. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add a paragraph to the commit message to explain why we can ditch the crtc timings initialization call from the gmch pfit code, to answer a question from Rodrigo's review.] Signed-off-by:
-
Daniel Vetter authored
The encoder->mode_set callback from the crtc helpers is now completely unused in our driver. Good riddance! Reviewed-by:
-
