- 13 Sep, 2013 6 commits
-
-
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ä 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ä 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:
-
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:
-
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:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 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:
Ben Widawsky <ben@bwidawsk.net> [danvet: One additional s/evict_everything/evict_vm/ to update a comment in the code.] Signed-off-by:
-
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 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:
-
- 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:
-
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:
-
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 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:
-
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ä authored
Unify the code a bit to use ilk_compute_wm_level for all watermark levels. Signed-off-by:
-
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ä 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:
-
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:
-
- 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:Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
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: -
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 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 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 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:
-
- 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:
-
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:
-
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 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:
-
- 04 Sep, 2013 12 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:
-
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 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:
-
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 authored
Notifying the bios lets it enter power saving states. Signed-off-by:
-
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 authored
In preparation for followup work. Signed-off-by:
-
Jani Nikula authored
SWSCI is a driver to bios call interface. This checks for SWSCI availability and bios requested callbacks, and filters out any calls that shouldn't happen. This way the callers don't need to do the checks all over the place. v2: silence some checkpatch nagging v3: set PCI_SWSCI bit 0 to trigger interrupt (Mengdong Lin) v4: remove an extra #define (Jesse) v5: spec says s/w is responsible for clearing PCI_SWSCI bit 0 too v6: per Paulo's review and more: - fix sub-function mask - add exit parameter - add define for set panel details call - return more errors from swsci - clean up the supported/requested callbacks bit masks mess - use DSLP for timeout - fix build for CONFIG_ACPI=n v7: tiny adjustment of requested vs. supported SBCB callbacks handling (Paulo) Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Chris Wilson authored
The comments were a little out-of-sequence with the code, forcing the reader to jump around whilst reading. Whilst moving the comments around, add one to explain the context reference. Signed-off-by:
-
Chris Wilson authored
We use the request to ensure we hold a reference to the context for the duration that it remains in use by the ring. Each request only holds a reference to the current context, hence we emit a request after switching contexts with the final reference to the old context. However, the extra interrupt caused by that request is not useful (no timing critical function will wait for the context object), instead the overhead of servicing the IRQ shows up in some (lightweight) benchmarks. In order to keep the useful property of using the request to manage the context lifetime, we want to add a dummy request that is associated with the interrupt from the subsequent real request following the batch. The extra interrupt was added as a side-effect of using i915_add_request() in commit 112522f6 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu May 2 16:48:07 2013 +0300 drm/i915: put context upon switching v2: Daniel convinced me that the request here was solely for context lifetime tracking and that we have the active ref to keep the object alive whilst the MI_SET_CONTEXT. So the only concern then is which context should get the blame for MI_SET_CONTEXT failing. The old scheme added a request for the old context so that any hang upto and including the switch away would mark the old context as guilty. Now any hang here implicates the new context. However since we have already gone through a complete flush with the last context in its last request, and all that lies in no-man's-land is an invalidate flush and the MI_SET_CONTEXT, we should be safe in not unduly placing blame on the new context. Signed-off-by:
-
Daniel Vetter authored
The saga around the breadcrumb vmas used by execbuf continues ... This time around we've managed to unconditionally move the object to the unbound list on the last vma unbind even though it might never have been on either the bound or unbound list. Hilarity ensued. Chris Wilson tracked this one down but compared to his patches I've simply opted to completely separate the unbound case for not-yet bound vmas. Otherwise we imo end up with semantically hard to parse checks around the list_move_tail(global_list, ...). Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68462Reviewed-by:
-
