- 15 Dec, 2014 4 commits
-
-
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:
Deepak S <deepak.s@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
Jani Nikula <jani.nikula@intel.com> Signed-off-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:
Thomas Daniel <thomas.daniel@intel.com> Signed-off-by:
-
- 10 Dec, 2014 14 commits
-
-
Michel Thierry authored
We already implement this workaround, but it was missing its name. Reviewed-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-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:
Damien Lespiau <damien.lespiau@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:
Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-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 3 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:
-
Rickard Strandqvist authored
Remove the function intel_output_name() that is not used anywhere. This was partially found by using a static code analysis program called cppcheck. Signed-off-by:
Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by:
-
- 06 Dec, 2014 11 commits
-
-
John Harrison authored
Added the request structure's 'uniq' identifier to the trace information. Also renamed the '_complete' trace event to '_notify' as it actually happens in the IRQ 'notify_ring()' function. The intention is to add a new '_complete' trace event which occurs when a request structure is actually marked as complete. However, at the moment the completion status is re-tested every time the query is made so there isn't a completion event as such. v2: New patch added to series. v3: Rebased to remove completion caching as that is apparently contentious. Change-Id: Ic9bcde67d175c6c03b96217cdcb6e4cc4aa45d67 For: VIZ-4377 Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
-
John Harrison authored
For debugging purposes, it is useful to be able to uniquely identify a given request structure as it works its way through the system. This becomes especially tricky once the seqno value is lazily allocated as then the request has nothing but its pointer to identify it for much of its life. Change-Id: Ie76b2268b940467f4cdf5a4ba6f5a54cbb96445d For: VIZ-4377 Signed-off-by:
-
John Harrison authored
There is a general theory that kzmalloc is better/safer than kmalloc, especially for interesting data structures. This change updates the request structure allocation to be zero filled. This also fixes crashes in the reset code. Quoting Mika's patch: "Clean the request structure on alloc. Otherwise we might end up referencing uninitialized fields. This is apparent when we try to cleanup the preallocated request on ring reset, before any request has been submitted to the ring. The request->ctx is foobar and we end up freeing the foobarness." Note that this fixes a regression introduced in commit 9eba5d4a Author: John Harrison <John.C.Harrison@Intel.com> Date: Mon Nov 24 18:49:23 2014 +0000 drm/i915: Ensure OLS & PLR are always in sync References: https://bugs.freedesktop.org/show_bug.cgi?id=86959 References: https://bugs.freedesktop.org/show_bug.cgi?id=86962 References: https://bugs.freedesktop.org/show_bug.cgi?id=86992 Change-Id: I68715ef758025fab8db763941ef63bf60d7031e2 For: VIZ-4377 Signed-off-by:
-
John Harrison authored
The display related patches earlier in this series were edited during merge to improve the request unreferencing. Specifically, the need for de-referencing at interrupt time was removed. However, the resulting code did a 'deref(req) ; req = NULL' sequence rather than using the 'req_assign(req, NULL)' wrapper. The two are functionally equivalent, but using the wrapper is more consistent with all the other places where requests are assigned. Note that the whole point of the wrapper is that using it everywhere that request pointers are assigned means that the reference counting is done automatically and can't be accidentally forgotten about. Plus it allows simpler future maintainance if the reference counting mechanisms ever need to change. For: VIZ-4377 Signed-off-by:
-
Matt Roper authored
If we extend the commit_plane handlers for each plane type to be able to handle fb=0, then we can easily implement plane disable via the update_plane handler. The cursor plane already works this way, and this is the direction we need to go to integrate with the atomic plane handler. We can now kill off the type-specific disable functions, as well as the redundant intel_plane_disable() (not to be confused with intel_disable_plane()). Note that prepare_plane_fb() only gets called as part of update_plane when fb!=NULL (by design, to match the semantics of the atomic plane helpers); this means that our commit_plane handlers need to handle the frontbuffer tracking for the disable case, even though they don't handle it for normal updates. v2: - Change BUG_ON to WARN_ON (Ander/Daniel) v3: - Drop unnecessary plane->crtc check since a previous patch to plane update ensures that plane->crtc will always be non-NULL, even for disable calls that might pass NULL from userspace. (Ander) - Drop a s/crtc/plane->crtc/ hunk that was unnecessary. (Ander) v4: - Fix missing whitespace (Ander) v5: - Use state's crtc rather than plane's crtc in intel_check_primary_plane(). plane->crtc could be NULL, but we've already fixed up state->crtc to ensure it's non-NULL (even if userspace passed it as NULL during a disable call). (Ander) Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by:
-
Matt Roper authored
When disabling a plane, it is legal to pass crtc = NULL. Since planes on Intel hardware are tied to a fixed CRTC, go ahead and set state->crtc to the appropriate crtc in cases where it is passed to us as NULL. In a future patch, we will start using the update handler for plane disables, so this will help ensure we always have a non-NULL crtc pointer to work with. Signed-off-by:
-
Matt Roper authored
Our .update_plane() handlers do the same check/prepare/commit/cleanup steps regardless of plane type. Consolidate them all into a single function that calls check/commit through a vtable. Signed-off-by:
-
Matt Roper authored
All plane update functions need to unpin the old framebuffer when flipping to a new one. Pull this logic into a separate function to ease the integration with atomic plane helpers. v2: Don't wait for vblank if we don't have an old fb to cleanup (Ander) v3: Really don't wait for vblank if we don't have an old fb to cleanup. Previous version only handled this for primary planes; we need the same change on cursors/sprites too! (Ander) Signed-off-by: -
Matt Roper authored
The 'prepare' step for all types of planes are pretty similar; consolidate the three 'prepare' functions into a single function. This paves the way for future integration with the atomic plane handlers. Note that we pull the 'wait for pending flips' functionality out of the primary plane's prepare step and place it directly in the 'setplane' code. When we move to the atomic plane handlers, this code will be in the 'atomic begin' step. v2: Update GEM fb tracking for physical cursors also (Ander) Signed-off-by:
-
Matt Roper authored
Reviewed-by:
Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by:
-
Matt Roper authored
Primary and sprite planes have already been refactored to include a 'prepare' step which handles all the commit-time operations that could fail (i.e., pinning buffers and such). Refactor the cursor commit in a similar manner. For simplicity and consistency with other plane types, we also switch to using intel_pin_and_fence_fb_obj() to perform our pinning for non-physical cursors. This will allow us to more easily migrate the code into the atomic 'begin' handler in a plane-agnostic manner in a future patchset. v2: - Update GEM fb tracking for physical cursors too. (Ander) - Use intel_unpin_fb_obj() rather than i915_gem_object_unpin_from_display_plane() and do so while holding struct_mutex. (Ander) - Update plane->fb in commit_cursor_plane. This isn't really necessary since the DRM core does this for us in __setplane_internal(), but doing it in our driver once we know we're going to succeed helps avoid confusion. (Ander) Signed-off-by:
-
- 05 Dec, 2014 8 commits
-
-
Gustavo Padovan authored
After some refactor intel_primary_plane_setplane() does the same as intel_pipe_set_base() so we can get rid of it and replace the calls with intel_primary_plane_setplane(). v2: take Ville's comments: - get the right arguments for update_plane() - use drm_crtc_get_hv_timing() v3 (by Matt): - Rebase to latest di-nightly codebase - Use primary->funcs->update_plane() in __intel_set_mode() - Use primary->funcs->disable_plane() in intel_crtc_disable() v4 (by Matt): - Drop redundant calls to intel_crtc_wait_for_pending_flips() before calling update_plane() (Ville) Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
-
Gustavo Padovan authored
Merge it into the plane update_plane() callback and make other users use the update_plane() functions instead. The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj() so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane() and merge both paths into one. v5 (by Matt): - Rebase onto latest di-nightly codebase - Drop extra unreference call when we fail to pin (Ville) Reviewed-by(v4): Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Gustavo Padovan authored
We need to get hdisplay and vdisplay in a few places so create a helper to make our job easier. Note that drm_crtc_check_viewport() and intel_modeset_pipe_config() were previously making adjustments for doublescan modes and vscan > 1 modes, which was incorrect. Using our new helper fixes this mistake. v2 (by Matt): Use new stereo doubling function (suggested by Ville) v3 (by Matt): - Add missing kerneldoc (Daniel) - Use drm_mode_copy() (Jani) v4 (by Matt): - Drop stereo doubling function again; add 'stereo only' flag to drm_mode_set_crtcinfo() instead (Ville) v5 (by Matt): - Note behavioral change in drm_crtc_check_viewport() and intel_modeset_pipe_config(). (Ander) - Describe new adjustment flags in drm_mode_set_crtcinfo()'s kerneldoc. (Ander) Cc: dri-devel@lists.freedesktop.org Suggested-by:
Dave Airlie <airlied@gmail.com> Reviewed-by:
-
Daniel Vetter authored
Signed-off-by: -
Michel Thierry authored
We already have it for chv, but was missing for bdw. Signed-off-by:
-
Gaurav K Singh authored
We need to program both port registers during dual link enable path. v2: Address review comments by Jani - Used a for loop instead of do-while loop. v3: Used for_each_dsi_port macro instead of for loop v4: Renamed mode_hactive variable to mode_hdisplay Signed-off-by:Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by:
-
Gaurav K Singh authored
We need to program both port registers during dual link disable path. v2: Address review comments by Jani - Used a for loop instead of do-while loop. v3: Used for_each_dsi_port macro instead of for loop v4: Added comments for the usage of AFE latchout bit Signed-off-by: -
Gaurav K Singh authored
hactive, hfp, hbp, hsync needs to be halved for dual link MIPI Panels. Accordingly timing related mmio regs needs to be programmed for both MIPI Ports. v2: Address review comments by Jani - Used a for loop instead of do-while loop v3: Used for_each_dsi_port macro instead of for loop Signed-off-by:
-
