- 06 Dec, 2014 9 commits
-
-
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 <John.C.Harrison@Intel.com> Reviewed-by:
Thomas Daniel <Thomas.Daniel@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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 15 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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-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:
Michel Thierry <michel.thierry@intel.com> Reviewed-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:Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by:
Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-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: -
Gaurav K Singh authored
Instead of pipe configuration reg, cck reg to be used for checking whether DSI Pll is getting locked or not. v2: dpio_lock unlocked now in case DSI PLL lock fails Signed-off-by:
-
Gaurav K Singh authored
For Dual link MIPI Panels, dsipll clock for both DSI0 and DSI1 needs to be enabled. v2: Address review comments by Jani - Added wait time for PLL to be locked. v3: separate patch created for cck read for checking PLL to be locked Signed-off-by: -
Gaurav K Singh authored
For dual link MIPI panels, SHUTDOWN packet needs to send to both Ports A & C during MIPI encoder disabling sequence. Similarly, TURN ON packet to be sent to both Ports during MIPI encoder enabling sequence. 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: -
Gaurav K Singh authored
For dual link MIPI Panels, each port needs half of pixel clock. Pixel overlap can be enabled if needed by panel, then in that case, pixel clock will be increased for extra pixels. v2 : Address review comments by Jani - Removed the bit mask used for ->dual_link - Used DSI instead of MIPI for #define variables v3: Added the VLV_DISPLAY_BASE to VLV_CHICKEN_3 register Signed-off-by: -
Gaurav K Singh authored
For Dual Link MIPI Panels, both Port A and Port C should be enabled during the MIPI encoder enabling sequence. Similarly, during the disabling sequence, both ports needs to be disabled. v2: Used for_each_dsi_port macro instead of for loop v3: Used intel_dsi->ports instead of dual_link var for dual link configuration check v4: Masking of the required MIPI port bits before writing proper values Signed-off-by:
-
Ville Syrjälä authored
MI_STORE_DWORD_IMM length has been the same ever since gen4. Rename the define to avoid potential confusion if someone tries to use this on pre-gen8. Also correct the comment on MI_MEM_VIRTUAL bit. It's present on 945,g33 and 965 only. Cc: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:
-
Jani Nikula authored
Release struct_mutex if init_rings() fails. This is a regression introduced in commit 35a57ffb Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Nov 20 00:33:07 2014 +0100 drm/i915: Only init engines once Reported-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
-
- 04 Dec, 2014 4 commits
-
-
Gaurav K Singh authored
This patch is in preparation of DSI dual link panels. For dual link panels, few packets needs to be sent to Port A or Port C or both. Based on the portno from MIPI Sequence Block#53, these sequences needs to be sent accordingly. v2: Addressed review comments by Jani - port variables named properly Signed-off-by: -
Gaurav K Singh authored
This patch is in preparation for the DSI dual link port enable and disable related changes. Signed-off-by:
-
Damien Lespiau authored
When playing around with debugfs and a HSW machine I noticed that we were displaying some garbled value in i915_ddb_info. This debugfs file is only meaningful for gen9+, so don't display anything on earlier platforms. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
Multiple GGTT VMAs per object will be introduced in the near future which will make it impossible to guarantee normal GGTT view is at the head of the list. Purpose of this patch is to break this assumption straight away so any potential hidden assumptions in the code base can be bisected to this simple patch. For: VIZ-4544 Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
- 03 Dec, 2014 12 commits
-
-
Damien Lespiau authored
Hardware team updated the recommended translation values for DP/eDP 1.3. This should help with some stability and HBR2 issues. Signed-off-by:
-
Daniel Vetter authored
We need to do that every time we resume the rings, not just at load. I've overlooked this in my untangling of the ring init code. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
-
Thomas Daniel authored
A previous commit introduced engine init changes: commit 372ee59699d9 ("drm/i915: Only init engines once") This broke execlists as intel_lr_context_render_state_init was trying to emit commands to the RCS for the default context before the ring->init_hw was called. Made a new gen8_init_rcs_context function and assign in to render ring init_context. Moved call to intel_logical_ring_workarounds_emit into gen8_init_rcs_context to maintain previous functionality. Moved call to render_state_init from lr_context_deferred_create into gen8_init_rcs_context, and modified deferred_create to call ring->init_context for non-default contexts. Modified i915_gem_context_enable to call ring->init_context for the default context. So init_context will now always be called when the hw is ready - in i915_gem_context_enable for the default context and in lr_context_deferred_create for other contexts. Signed-off-by: -
Mika Kuoppala authored
The conversion table can be replaced with simple enough function. text data bss dec hex filename 839688 10987 24 850699 cfb0b drivers/gpu/drm/i915/i915.ko 839224 10987 24 850235 cf93b drivers/gpu/drm/i915/i915.ko Result is 494 saved bytes (.05525%). v2: - no run on sentences from subject (Chris, Jani) - be verbose about the savings (Chris, Daniel) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by:Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Daniel Vetter authored
Now that sanity prevails and we have the clean split between software init and starting the engines we can drop all the "have we allocate this struct already?" nonsense. Execlist code could benefit quite a bit more still, but that's for another patch. Reviewed-by:
-
Ander Conselvan de Oliveira authored
The same logic can be implemented without it, and it even saves a line of code. Signed-off-by:
-
Daniel Vetter authored
We can do this. And now there's finally the clean split between software setup and hardware setup I kinda wanted since multi-ring support was merged aeons ago. It only took almost 5 years. Signed-off-by:
-
Daniel Vetter authored
With this all the ->init_hw hooks really only set up hw state needed to start the ring, all the software state setup and memory/buffer allocations happen beforehand. v2: We need to call intel_init_pipe_control after the ring init since otherwise engine->dev is NULL and it falls over. Currently that's now after the hw ring is enabled but a) we'll be fine as long as no one submits a batch b) this will change soon. Signed-off-by:
-
Daniel Vetter authored
This is (mostly, some exceptions that need fixing) the hw setup function which starts the ring. And not the function which allocates all the resources. Make this clear by giving it a better name. Signed-off-by:
-
Dave Gordon authored
There are numerous places in the code where the driver's idea of how much space is left in a ring is updated using the driver's latest notions of the positions of 'head' and 'tail' for the ring. Among them are some that update one or both of these values before (re)doing the calculation. In particular, there are four different places in the code where 'last_retired_head' is copied to 'head' and then set to -1; and two of these do not have a guard to check that it has actually been updated since last time it was consumed, leaving the possibility that the dummy -1 can be transferred from 'last_retired_head' to 'head', causing the space calculation to produce 'impossible' results (previously seen on Android/VLV). This code therefore consolidates all the calculation and updating of these values, such that there is only one place where the ring space is updated, and it ALWAYS uses (and consumes) 'last_retired_head' if (and ONLY if) it has been updated since the last call. Signed-off-by:
-
Dave Gordon authored
The used space in a ring is given by the cyclic distance from the consumer (HEAD) to the producer (TAIL), i.e. ((tail-head) MOD size); conversely, the available space in a ring is the cyclic distance from the producer to the consumer, MINUS the amount reserved for a "gap" that is supposed to guarantee that the producer never catches up with or overruns the consumer. Note that some GEN h/w requires that TAIL never approach to within one cacheline of HEAD, so the gap is usually set to twice the cacheline size to ensure this. While the existing code gives the correct answer for correct inputs, if the producer HAS overrun into the reserved space, the result can be a value larger than the maximum valid value (size-reserved). We can improve this by reorganising the calculation, so that in the event of overrun the result will be negative rather than over-large. This means that the commonly-used test (available >= required) will then reject further writes into the ring after an overrun, giving some chance that we can recover from or at least diagnose the original problem; whereas allowing more writes would likely both confuse the h/w and destroy the evidence of what went wrong. Signed-off-by:
-
Jani Nikula authored
Later on this can include multiple ports (e.g. (1 << PORT_A) | (1 << PORT_C)) to describe dual link DSI. Signed-off-by:
-
