- 16 Dec, 2014 12 commits
-
-
Rob Clark authored
Many distro's have mechanism in place to collect and automatically file bugs for failed WARN()s. And since i915 has a lot of hw state sanity checks which result in WARN(), it generates quite a lot of noise which is somewhat disconcerting to the end user. Separate out the internal hw-is-in-the-state-I-expected checks into I915_STATE_WARN()s and allow configuration via i915.verbose_checks module param about whether this will generate a full blown stacktrace or just DRM_ERROR(). The new moduleparam defaults to true, so by default there is no change in behavior. And even when disabled, you will still get an error message logged. v2: paint the macro names blue, clarify that the default behavior remains the same as before Signed-off-by:Rob Clark <robdclark@gmail.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Michel Thierry authored
Otherwise, new platforms without workarounds will hit this warning for every new context created. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Michel Thierry authored
In Gen8+, full ppgtt needs execlist, otherwise the ctx switch can hang. Also remove the current restriction, a user should be able to explicitly set ppgtt=2. Note, this patch considers that execlist support has been enabled by default on Gen8. v2: Remove non-default restriction and clarify commit message (Daniel) Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Deepak S authored
With cherryview onwards, Gunit hardware itself save and restore all the Gunit registers. Skipping the "vlv_save_gunit_s0ix_state" & "vlv_restore_gunit_s0ix_state" for cherryview in S3/S0ix sequence. Signed-off-by:
Deepak S <deepak.s@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Deepak S authored
Higher RC6 residency is observed using timeout mode instead of EI mode. It's Recommended to use TO Method for RC6. v2: Add comment about timeout threshold. (Tom) Signed-off-by:
-
Jordan Justen authored
This will allow us to read the number of dispatched compute threads for GL_ARB_pipeline_statistics_query. Signed-off-by:
Jordan Justen <jordan.l.justen@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Brad Volkin authored
Move it to a separate function since the main do_execbuffer function already has so much going on. v2: - Move pin/unpin calls inside i915_parse_cmds() (Chris W, v4 7/7 feedback) Issue: VIZ-4719 Signed-off-by:
Brad Volkin <bradley.d.volkin@intel.com> Reviewed-By:
Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by:
-
Brad Volkin authored
By adding a new exec_entry flag, we cleanly mark the shadow objects as purgeable after they are on the active list. v2: - Move 'shadow_batch_obj->madv = I915_MADV_WILLNEED' inside _get fnc (danvet, from v4 6/7 feedback) v3: - Remove duplicate 'madv = I915_MADV_WILLNEED' (danvet, from v6 4/5) Issue: VIZ-4719 Signed-off-by:
-
Brad Volkin authored
Previously we couldn't trust the user-supplied batch length because it came directly from userspace (i.e. untrusted code). It would have affected what commands software parsed without regard to what hardware would actually execute, leaving a potential hole. With the parser now copying the user supplied batch buffer and writing MI_NOP commands to any space after the copied region, we can safely use the batch length input. This should be a performance win as the actual batch length is frequently much smaller than the allocated object size. v2: Fix handling of non-zero batch_start_offset Issue: VIZ-4719 Signed-off-by:
-
Brad Volkin authored
This patch sets up all of the tracking and copying necessary to use batch pools with the command parser and dispatches the copied (shadow) batch to the hardware. After this patch, the parser is in 'enabling' mode. Note that performance takes a hit from the copy in some cases and will likely need some work. At a rough pass, the memcpy appears to be the bottleneck. Without having done a deeper analysis, two ideas that come to mind are: 1) Copy sections of the batch at a time, as they are reached by parsing. Might improve cache locality. 2) Copy only up to the userspace-supplied batch length and memset the rest of the buffer. Reduces the number of reads. v2: - Remove setting the capacity of the pool - One global pool instead of per-ring pools - Replace batch_obj with shadow_batch_obj and hook into eb->vmas - Memset any space in the shadow batch beyond what gets copied - Rebased on execlist prep refactoring v3: - Rebase on chained batch handling - Squash in setting the secure dispatch flag - Add a note about the interaction w/secure dispatch pinning - Check for request->batch_obj == NULL in i915_gem_free_request v4: - Fix read domains for shadow_batch_obj - Remove the set_to_gtt_domain call from i915_parse_cmds - ggtt_pin/unpin in the parser block to simplify error handling - Check USES_FULL_PPGTT before setting DISPATCH_SECURE flag - Remove i915_gem_batch_pool_put calls v5: - Move 'pending_read_domains |= I915_GEM_DOMAIN_COMMAND' after the parser (danvet, from v4 0/7 feedback) Issue: VIZ-4719 Signed-off-by:
-
Brad Volkin authored
This adds a small module for managing a pool of batch buffers. The only current use case is for the command parser, as described in the kerneldoc in the patch. The code is simple, but separating it out makes it easier to change the underlying algorithms and to extend to future use cases should they arise. The interface is simple: init to create an empty pool, fini to clean it up, get to obtain a new buffer. Note that all buffers are expected to be inactive before cleaning up the pool. Locking is currently based on the caller holding the struct_mutex. We already do that in the places where we will use the batch pool for the command parser. v2: - s/BUG_ON/WARN_ON/ for locking assertions - Remove the cap on pool size - Switch from alloc/free to init/fini v3: - Idiomatic looping structure in _fini - Correct handling of purged objects - Don't return a buffer that's too much larger than needed v4: - Rebased to latest -nightly v5: - Remove _put() function and clean up comments to match v6: - Move purged check inside the loop (danvet, from v4 1/7 feedback) v7: - Use single list instead of two. (Chris W) - s/active_list/cache_list - Squashed in debug patches (Chris W) drm/i915: Add a batch pool debugfs file It provides some useful information about the buffers in the global command parser batch pool. v2: rebase on global pool instead of per-ring pools v3: rebase drm/i915: Add batch pool details to i915_gem_objects debugfs To better account for the potentially large memory consumption of the batch pool. v8: - Keep cache in LRU order (danvet, from v6 1/5 feedback) Issue: VIZ-4719 Signed-off-by:
-
Imre Deak authored
After commit a18c0af1 uthor: Thierry Reding <treding@nvidia.com> Date: Wed Dec 10 11:38:49 2014 +0100 drm: Zero out DRM object memory upon cleanup we will use the eDP encoder during destroying it. Fix this by calling drm_encoder_cleanup() at a point when the encoder is not used any more. This caused a NULL pointer dereference in pps_lock(), I can't see that it caused any other problem. All the other encoders seem to call drm_encoder_cleanup() at a safe place. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
- 15 Dec, 2014 12 commits
-
-
Damien Lespiau authored
I've checked that TRANS_DDI_MODE, DP_TP_CTL MST bits are identical to HSW/BDW on SKL, as well as the long vs short HPD bits. So we have a good chance to be working as well as prevous platforms. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Damien Lespiau authored
2 pieces of code need to read out the DDI clock: the DDI encoder and the MST encoder .get_config() vfuncs. Until now the SKL read out code was only in the former, so let's move the pre and post SKL logic in intel_ddi_clock_get() and this this one everywhere. Signed-off-by:
-
Deepak M authored
LFP brighness control from the VBT block 43 indicates which controller is used for brightness. LFP1 brightness control method: Bit 7-4 = This field controller number of the brightnes controller. 0 = Controller 0 1 = Controller 1 2 = Controller 2 3 = Controller 3 Others = Reserved Bits 3-0 = This field specifies the brightness control pin to be used on the platform. 0 = PMIC pin is used for brightness control 1 = LPSS PWM is used for brightness control 2 = Display DDI is used for brightness control 3 = CABC method to control brightness Others = Reserved Adding the above fields in dev_priv->vbt and corresponding changes in parse_backlight() v2: Jani's review comments addressed - Move PWM definitions to intel_bios.h - Moving vbt_version to intel_vbt_data - Rename brightness to bl_ctrl_data - Logging just control_pin instead of string - Avoid adding vbt_version in dev_priv - Since only DDI option is available as of now, let control pin DDI affect dev_priv->vbt.backlight.present v3: Jani's review comments addressed - Drop control_pin - Use bdb->version - set controller to 0 instead of using control pin define - check controller bounds - remove superfluous changes in intel_parse_bios Signed-off-by:
Deepak M <m.deepak@intel.com> Signed-off-by:
Vandana Kannan <vandana.kannan@intel.com> Reviewed-by:
-
Sonika Jindal authored
We were incorreectly bypassing the flush everytime which led to fifo underrun when more than one plane is enabled. Signed-off-by:
Sonika Jindal <sonika.jindal@intel.com> Reviewed-by:
-
Thomas Daniel authored
Execlist support in the i915 driver is now considered good enough for the feature to be enabled by default on Gen8 and later and routinely tested. Adjusted i915 parameters structure initialization to reflect this and updated the comment in intel_sanitize_enable_execlists(). There's still work to do before we can let the wider massive onto it, but there's still time left before the 3.20 cutoff. v2: Update the MODULE_PARM_DESC too. Issue: VIZ-2020 Signed-off-by:
Thomas Daniel <thomas.daniel@intel.com> [danvet: Add note that there's still some work left to do.] Signed-off-by:
-
Sonika Jindal authored
The pipe wm parameters is not correctly updated with sprite parameters because it copies them for each plane from plane_list to the sprite offset in pipe wm parameters. Since plane_list also contains primary and cursor planes, we end up updating wrong params for sprites. Signed-off-by:
-
Tvrtko Ursulin authored
A short section describing background, implementation and intended usage. v2: * Align section name between template and DOC comment. (Michel Thierry) For: VIZ-4544 Signed-off-by: -
Tvrtko Ursulin authored
Things like reliable GGTT mappings and mirrored 2d-on-3d display will need to map objects into the same address space multiple times. Added a GGTT view concept and linked it with the VMA to distinguish between multiple instances per address space. New objects and GEM functions which do not take this new view as a parameter assume the default of zero (I915_GGTT_VIEW_NORMAL) which preserves the previous behaviour. This now means that objects can have multiple VMA entries so the code which assumed there will only be one also had to be modified. Alternative GGTT views are supposed to borrow DMA addresses from obj->pages which is DMA mapped on first VMA instantiation and unmapped on the last one going away. v2: * Removed per view special casing in i915_gem_ggtt_prepare / finish_object in favour of creating and destroying DMA mappings on first VMA instantiation and last VMA destruction. (Daniel Vetter) * Simplified i915_vma_unbind which does not need to count the GGTT views. (Daniel Vetter) * Also moved obj->map_and_fenceable reset under the same check. * Checkpatch cleanups. v3: * Only retire objects once the last VMA is unbound. v4: * Keep scatter-gather table for alternative views persistent for the lifetime of the VMA. * Propagate binding errors to callers and handle appropriately. v5: * Explicitly look for normal GGTT view in i915_gem_obj_bound to align usage in i915_gem_object_ggtt_unpin. (Michel Thierry) * Change to single if statement in i915_gem_obj_to_ggtt. (Michel Thierry) * Removed stray semi-colon in i915_gem_object_set_cache_level. For: VIZ-4544 Signed-off-by: -
Deepak S authored
According to updated BSpec, Render/Common/media Wells register range changed. Updating the same to match the spec and avoid extra forcewake for none forcewake range. v2: Update media forcewake range (Ville) Signed-off-by:
-
Gaurav K Singh authored
From now on for both DSI Ports A & C, the seq_port value has been set to 0. seq_port value is parsed from Sequence block#53 of VBT. So, for packets that needs to be read/write for DSI single link on Port A and Port C will now be based on the DVO port from VBT block 2, instead of seq_port. Signed-off-by:
Gaurav K Singh <gaurav.k.singh@intel.com> Reviewed-by:
-
Daniel Vetter authored
Faster feedback to errors is always better. This is inspired by the addition to WARN_ONs to mask/enable helpers for registers to make sure callers have the arguments ordered correctly: Pretty much always the arguments are static. We use WARN_ON(1) a lot in default switch statements though where we should always handle all cases. So add a new macro specifically for that. The idea to use __builtin_constant_p is from Chris Wilson. v2: Use the ({}) gcc-ism to avoid the static inline, suggested by Dave. My first attempt used __cond as the temp var, which is the same used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so sprinkle i915 into the name. Also use a temporary variable to only evaluate the condition once, suggested by Damien. v3: It's crazy but apparently 32bit gcc can't compile out the BUILD_BUG_ON in a lot of cases and just falls over. I have no idea why, but until clue grows just disable this nifty idea on 32bit builds. Reported by 0-day builder. v4: Got it all wrong, apparently its the gcc version. We need 4.9+. Now reported by Imre. v5: Chris suggested to add the case to MISSING_CASE for speedier debug. v6: Even some gcc 4.9 versions don't see through the maze, so give up for now. Keep the skeleton and MISSING_CASE stuff though. Cc: Imre Deak <imre.deak@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by:Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
We consistently use the _irq_handler postfix for functions called in hardirq context. Especially when it's a non-static function hardirq is a crazy enough calling context to warrant this level of ocd. So rename it. Cc: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by:
-
- 10 Dec, 2014 14 commits
-
-
Michel Thierry authored
We already implement this workaround, but it was missing its name. Reviewed-by:
-
Daniel Vetter authored
Stupid userspace (there is no evil userspace in debugfs by assumption) might provoke a leak since we allocate the new array without holding any locks. Drop in an unconditional kfree to deal with this - kfree can handle NULL. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
Currently i915_pipe_crc_read() will drop pipe_crc->lock for the entire duration of the copy_to_user() loop, which means it'll access pipe_crc->entries without any protection. If another thread sneaks in and frees pipe_crc->entries the code will oops. Reorganize the code to hold the lock around everything except copy_to_user(). After the copy the lock is reacquired and the the number of available entries is rechecked. Since this is a debug feature simplify the error handling a bit by consuming the crc entry even if copy_to_user() would fail. Signed-off-by:
-
Ville Syrjälä authored
pipe_crc->entries[] is an array so allocate with kcalloc() instead of kzalloc(). Signed-off-by:
-
Ville Syrjälä authored
Set the pipe_crc->entries pointer while holding the relevant spinlock. Doesn't matter too much since a spurious pipe crc interrupt would then just update one entry but later that entry would get cleared when head and tail are both set to 0. But being a bit more paranoid doesn't hurt. Signed-off-by:
-
Ville Syrjälä authored
Add the missing CRC control register value for DP port D on CHV. Untested as I don't have a CHV machine with DP on port D. Signed-off-by:
-
Ville Syrjälä authored
To get stable CRCs from the DP CRC source we need to reset the scrambler for each frame. Enable the reset feature when grabbing CRCs for pipe C on CHV. Pipes A and B were already covered due sharing the code with VLV. We can safely extend PIPE_SCRAMBLE_RESET_MASK to deal with CHV since the extra bit was MBZ on the older platforms. Signed-off-by:
-
Damien Lespiau authored
intel-gpu-tools now generates the render state with license headers and the version of i-g-t that generated the files. A similar patch was previously sent but wasn't actually generated with the make target so was lacking the i-g-t revision. So here another version before we totally forget about this. Cc: Armin Reese <armin.c.reese@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
-
Rodrigo Vivi authored
No functional changes. v2 (Paulo): Rebase. v3: Accept Daniel's suggestions: * remove unclear and duplicated explanation. * remove marketing like doc and replace by a simple one. * remove bdw_fbc_sw_flush documentation. Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Gaurav K Singh authored
Due to hardware limitations on BYT, MIPI Port C DPI Enable bit does not get set. To check whether DSI Port C was enabled in BIOS, check the Pipe B enable bit for DSI Port C. In hardware, DSI Port C is linked with Pipe B. v2: Addressed review comments of Jani, Nikula - Used platform checks for this software workaround for BYT Signed-off-by: -
Gaurav K Singh authored
Common bit to be used for both DSI Port A & DSI Port C. Signed-off-by:
-
Gaurav K Singh authored
DSI Pll1 is used for enabling DSI on Port C. v2: Addressed review comments of Jani - Used & operator instead of == for intel_dsi->ports Signed-off-by: -
Michael H. Nguyen authored
Was missing. Issue: VIZ-4701 Signed-off-by:
Michael H. Nguyen <michael.h.nguyen@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
No functional changes. This is just the begin of a FBC rework. v2 (Paulo): - Revert intel_fbc_init() changed parameter. - Revert set_no_fbc_reason() rename. - Rebase. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
- 08 Dec, 2014 2 commits
-
-
Daniel Vetter authored
After a bit of irc discussion we've concluded that it would be prudent to check that callers use the mask/enable paramters correctly. So add a WARN_ON. Spurred by Damien's bugfix which added _MASKED_FIELD. v2: We use WARN_ON(1) a lot to catch default cases in switch blocks which should always be extended. So this doesn't work really. Dunno why gcc only started complaining when I've moved the WARN out of the static inline helper to address a feedback from Jani. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: -
Daniel Vetter authored
Similar to a patch from Thomas Daniel for lrc contexts. This keeps both sides somewhat in sync and should make Dave Gordon happy. Note that both the wa and the golden context init code suffer a bit from an inssuficient split into driver load and hw init code. Which means we have a bunch of tests all over the place to check whether the one-time initialization has been done already or not. All that one-tim code should be moved into the one-time ring setup code, but that's work for later. Cc: Dave Gordon <david.s.gordon@intel.com> Cc: Thomas Daniel <thomas.daniel@intel.com> Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
-
