- 13 Sep, 2013 12 commits
-
-
Paulo Zanoni authored
We don't seem to be using the pointer after it's unmapped, so this patch doesn't fix any bug I can reproduce. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
The cursor is supposed to be disabled during crtc mode set (disabled by ctrc disable). Assert this is the case. v2: move cursor disabled assert next to plane asserts (Ville) Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
The buf pointer used during l3_write is just char *, therefore it does not require the silly any addition of offset. v2: Also fix i915_l3_read with a suggested logic from Ville Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
We always read a register for l3 parity reads, and we don't really want to ever let userspace trick us into giving back less than the dword. Writes are okay because we assume everything will be 0 filled, and as such, if a user really wants to write less than a dword, let them. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
Sadly, this isn't the first time we've done this: http://lists.freedesktop.org/archives/intel-gfx/2013-June/029065.htmlSigned-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
We want to do fuzzy clock checks for other things besides adjusted_mode.clock, so just pass two two clocks to compare to intel_fuzzy_clock_check(). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Add functions to read out the CPU and PCH transcoder M/N values, and use them to fill out the pipe config dp_m_n information. And while at it populate has_dp_encoder too. Also refactor ironlake_get_fdi_m_n_config() to simply call the new intel_cpu_transcoder_get_m_n() function. v2: Remember the DDI Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
On CTG+ read out the pipe bpp setting from hardware and fill it into pipe config. Also check it appropriately. v2: Don't do the pipe_bpp extraction inside the PCH only code block on ILK+. Avoid the PIPECONF read as we already have read it for the PIPECONF_EANBLE check. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
It would be easier if adjusted_mode.clock would be the pipe pixel clock, and it actually is, except for the cases where pixel_multiplier > 1. So let's change intel_sdvo to use port_clock as the multiplied clock, and then we can leave adjusted_mode.clock as pipe pixel clock. v2: Improve port_clock documentation Rebased on top of SDVO pixel_multiplier fixes Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
We feed the non-multiplied clock to intel_link_compute_m_n(), so the opposite operation should use the same order of operations. So we just multiply by pixel_multiplier in the end now. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Because this PCI config register doesn't exist on Gen5+. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Both callers had code to sanitize the uncore and restore the GTT mappings just before calling __i915_drm_thaw, so Chris suggested I should unify the code. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 12 Sep, 2013 3 commits
-
-
Ben Widawsky authored
When reserving objects during execbuf, it is possible to come across an object which will not fit given the current fragmentation of the address space. We do not have any defragment in drm_mm, so the strategy is to instead evict everything, and reallocate objects. With the upcoming addition of multiple VMs, there is no point to evict everything since doing so is overkill for the specific case mentioned above. Recommended-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: One additional s/evict_everything/evict_vm/ to update a comment in the code.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
As we'll see in the next patch, being able to evict for just 1 VM is handy. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
lifted from Daniel: pread/pwrite isn't about the object's domain at all, but purely about synchronizing for outstanding rendering. Replacing the call to set_to_gtt_domain with a wait_rendering would imo improve code readability. Furthermore we could pimp pread to only block for outstanding writes and not for reads. Since you're not the first one to trip over this: Can I volunteer you for a follow-up patch to fix this? v2: Switch the pwrite patch to use \!read_only. This was a typo in the original code. (Chris, Daniel) Recommended-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Fix up the logic fumble - wait_rendering has a bool readonly paramater, set_to_gtt_domain otoh has bool write. Breakage reported by Jani Nikula, I've double-checked that igt/gem_concurrent_blt/prw-* would have caught this.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 10 Sep, 2013 9 commits
-
-
Jesse Barnes authored
Fixed with commit 10603caa Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Aug 26 19:51:06 2013 -0300 drm/i915: Apply the force-detect VGA w/a to Valleyview Signed-off-by: Jesse Barnes <jbarnes@virtuosugeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
intel_ddi_enable_transcoder_func() picked the sync flags from crtc->mode instead of the pipe config adjusted_mode. Fix the problem and hopefully rid my HSW machine of the remaining pipe config warnings. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
The purpose of the function is to find out whether the object is still bound in any address space. This can be easily checked by looking at the vma currently associated with the object, rather than asking if any of the global address spaces have an active vma on the object. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
Ignoring the legacy DRI1 code, and a couple of special cases (to be discussed later), all access to the ring is mediated through requests. The first write to a ring will grab a seqno and mark the ring as having an outstanding_lazy_request. Either through explicitly adding a request after an execbuffer or through an implicit wait (either by the CPU or by a semaphore), that sequence of writes will be terminated with a request. So we can ellide all the intervening writes to the tail register and send the entire command stream to the GPU at once. This will reduce the number of *serialising* writes to the tail register by a factor or 3-5 times (depending upon architecture and number of workarounds, context switches, etc involved). This becomes even more noticeable when the register write is overloaded with a number of debugging tools. The astute reader will wonder if it is then possible to overflow the ring with a single command. It is not. When we start a command sequence to the ring, we check for available space and issue a wait in case we have not. The ring wait will in this case be forced to flush the outstanding register write and then poll the ACTHD for sufficient space to continue. The exception to the rule where everything is inside a request are a few initialisation cases where we may want to write GPU commands via the CS before userspace wakes up and page flips. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Pull the expected max WM level determinations out to a separate function. Will have another user soon. 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
Unify the code a bit to use ilk_compute_wm_level for all watermark levels. 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
hsw_pipe_wm_parameters and hsw_wm_maximums typically are read only. Make them const. 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
Make the call to intel_update_watermarks() just once or twice during modeset. Ideally it should happen independently when each plane gets enabled/disabled, but for now it seems better to keep it in central place. We can improve things when we get all the planes sorted out in a better way. When enabling set up the watermarks just before the pipe is enabled. And when disabling we need to wait until we've marked the crtc as inactive, as otherwise intel_crtc_active() would still think the pipe is enabled and the computed watermarks would reflect that. v2: Pimp up the commit message a bit Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Passing the appropriate crtc to intel_update_watermarks() should help in avoiding needless work in the future. v2: Avoid clash with internal 'crtc' variable in some wm functions Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 06 Sep, 2013 6 commits
-
-
Mika Kuoppala authored
Score and action reveals what all the rings were doing and why hang was declared. Add idle state so that we can distinguish between waiting and idle ring. v2: - add idle as a hangcheck action - consensed hangcheck status to single line (Chris) - mark active explicitly when we are making progress (Chris) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Mika Kuoppala authored
Now when we have mechanism in place to track which context was guilty of hanging the gpu, it is possible to punish for bad behaviour. If context has recently submitted a faulty batchbuffers guilty of gpu hang and submits another batch which hangs gpu in quick succession, ban it permanently. If ctx is banned, no more batchbuffers will be queued for execution. There is no need for global wedge machinery anymore and it would be unwise to wedge the whole gpu if we have multiple hanging batches queued for execution. Instead just ban the guilty ones and carry on. v2: Store guilty ban status bool in gpu_error instead of pointers that might become danling before hang is declared. v3: Use return value for banned status instead of stashing state into gpu_error (Chris Wilson) v4: - rebase on top of fixed hang stats api - add define for ban period - rename commit and improve commit msg v5: - rely context banning instead of wedging the gpu - beautification and fix for ban calculation (Chris) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
VLV has per-pipe PP registers. Set up power sequencing on mode set. The connector init time setup is problematic, since we don't have a pipe at that time. Cook up something. v2: - use vlv_power_sequencer_pipe() also in _pp_{ctrl,stat}_reg() - use PANEL_PORT_SELECT_DPC_VLV (Ville) v3: make checkpatch happier Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Make checkpatch a bit more happier still ...] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Remove duplicates, add VLV specific macros for port B and C. v2: also add PANEL_PORT_SELECT_DPC_VLV for clarity (Ville) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Follow-up to commit 5004945f Author: Jani Nikula <jani.nikula@intel.com> Date: Tue Jul 30 12:20:32 2013 +0300 drm/i915: move encoder->enable callback later in VLV crtc enable v2: Rebase on the renamed enable hooks, adding clarity (Ville) Reference: http://mid.gmane.org/CAKMK7uFs9EMvMW8BnS24e5UNm1D7JrfVg3SD5SDFtVEamGfOOg@mail.gmail.comSigned-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
In line with the rest of the code base. No functional changes. v2: also s/intel_pre_enable_dp/g4x_pre_enable_dp/ for consistency (Ville) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 05 Sep, 2013 4 commits
-
-
Damien Lespiau authored
It's totally unused, so remove the last mode_fixup appearance in i915. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chon Ming Lee authored
The patch doesn't contain functional change, but is to prepare for future platform which has different DPIO phy. The additional pipe parameter will use to select which phy to target for. v2: Update the commit message and add static for the new function. (Jani/Ville) Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
It is possible for us to be forced to perform an allocation for the lazy request whilst running the shrinker. This allocation may fail, leaving us unable to reclaim any memory leading to premature OOM. A neat solution to the problem is to preallocate the request at the same time as acquiring the seqno for the ring transaction. This means that we can report ENOMEM prior to touching the rings. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
Prior to preallocating an request for lazy emission, rename the existing field to make way (and differentiate the seqno from the request struct). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 04 Sep, 2013 6 commits
-
-
Ville Syrjälä authored
ironlake_fdi_compute_config() already checks that we have enough FDI bandwidth. And it doesn't just use a hardcoded value but takes into account factors such as the actual FDI frequency, shared FDI B/C lanes, etc. Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chon Ming Lee authored
For DP pll settings, there is only two golden configs. Instead of running through the algorithm to determine it, hardcode the value and get it determine in intel_dp_set_clock. v2: Rework on the intel_limit compiler warning. (Jani) Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> [danvet: Fix up checkpatch issues.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chon Ming Lee authored
eDP 1.4 supports 4-5 extra link rates in additional to current 2 link rate. Create a structure to store the DPLL divisor data to improve readability. v2: Fix the gen4_dpll/pch_dpll initialization to C99 designated initializers, and use a single loop for all platforms. (Jani and Daniel) Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> [danvet: Fix up checkpatch warnings.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
The spec says to notify prior to power down and after power up. It is unclear whether it makes a difference. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Notifying the bios lets it enter power saving states. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
The bios interface seems messy, and it's hard to tell what the bios really wants. At first, only add support for DDI based machines (hsw+), and see how it turns out. The spec says to notify prior to power down and after power up. It is unclear whether it makes a difference. v2: - squash notification function and callers patches together (Daniel) - move callers to haswell_crtc_{enable,disable} (Daniel) - rename notification function (Chris) v3: - separate notification function and callers again, as it's not clear whether the display power state notification is the right thing to do after all v4: per Paulo's review: - drop LVDS - WARN on unsupported encoder types Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-