- 26 Mar, 2015 18 commits
-
-
Ander Conselvan de Oliveira authored
Instead of using connector->new_encoder, get the same information from the pipe_config, thus making the function ready for the atomic conversion. Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ander Conselvan de Oliveira authored
Move towards atomic by using the legacy modeset's drm_atomic_state instead. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Move towards atomic by using the legacy modeset's drm_atomic_state instead. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Move towards atomic by using the legacy modeset's drm_atomic_state instead. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Move towards atomic by using the legacy modeset's drm_atomic_state instead. v2: Move call to drm_atomic_add_affected_connectors() to intel_modeset_compute_config(). (Daniel) Signed-off-by: -
Ander Conselvan de Oliveira authored
With this in place, we can start converting pieces of the modeset code to look at the connector atomic state instead of the staged config. v2: Handle the load detect staged config changes too. (Ander) Remove unnecessary blank line. (Daniel) Signed-off-by: -
Ander Conselvan de Oliveira authored
Keep that state updated so that we can write code that depends on it on the follow up patches. v2: Fix BUG due to stale connector_state->crtc value. (Chandra) v3: Update comment about dummy state connectors. (Chandra) Signed-off-by:
-
Ander Conselvan de Oliveira authored
So that we can add connector states to the drm_atomic_state used in the legacy modeset. Signed-off-by:
-
kbuild test robot authored
drivers/gpu/drm/i915/intel_pm.c:2913:4-5: Unneeded semicolon Removes unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Ander Conselvan de Oliveira authored
For consistency, allocate a new crtc_state for a crtc that is being disabled. Previously only the enabled value of the current state would change. v2: Rebase on v5 of previous patch. (Ander) Signed-off-by:
-
Ander Conselvan de Oliveira authored
For the atomic conversion, the mode set paths need to be changed to rely on an atomic state instead of using the staged config. By using an atomic state for the legacy code, we will be able to convert the code base in small chunks. v2: Squash patch that adds stat argument to intel_set_mode(). (Ander) Make every caller of intel_set_mode() allocate state. (Daniel) Call drm_atomic_state_clear() in set config's error path. (Daniel) v3: Copy staged config to atomic state in force restore path. (Ander) v4: Don't update ->new_config for disabled pipes in __intel_set_mode(), since it is expected to be NULL in that case. (Ander) v5: Don't change return type of intel_modeset_pipe_config(). (Chandra) Signed-off-by: -
Ander Conselvan de Oliveira authored
For now this is not necessary since intel_set_mode() doesn't acquire any new locks. However, once that function is converted to atomic, that will change, since we'll pass an atomic state to it, and that needs to have the right acquire context set. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The pattern of getting the crtc state with drm_atomic_get_crtc_state() and then converting it to intel_crtc_state will repeat quite often in the following patches, so add a helper function to save some typing. v2: Fix upcasting so that crtc_state base field could be moved. (Daniel) Signed-off-by:
-
Daniel Vetter authored
Currently we only set preserve_bios_swizzling when the initial fb is shared and totally miss the single-screen case. Fix this by consolidating all the logic for both cases. This seems to go back to when swizzle preservation was originally merged in commit d9ceb816 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Oct 9 12:57:43 2014 -0700 drm/i915: preserve swizzle settings if necessary v4 Cc: Kristian Høgsberg <hoegsberg@gmail.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
In spirit with commit 5724dbd1 Author: Damien Lespiau <damien.lespiau@intel.com> Date: Tue Jan 20 12:51:52 2015 +0000 drm/i915: Rename plane_config to initial_plane_config to make it clear that this code is all special-purpose for the initial plane takeover. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
psr.active is being unset out of the if so this here is useless and duplicated. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Daniel Vetter authored
This is a very similar bug in the load detect code fixed in commit 9128b040 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Mar 3 17:31:21 2015 +0100 drm/i915: Fix modeset state confusion in the load detect code But this time around it was the initial fb code that forgot to update the plane->crtc pointer. Otherwise it's the exact same bug, with the exact same restrains (any set_config call/ioctl that doesn't disable the pipe papers over the bug for free, so fairly hard to hit in normal testing). So if you want the full explanation just go read that one over there - it's rather long ... Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Josh Boyer <jwboyer@fedoraproject.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reported-and-tested-by:
Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by:
-
Rodrigo Vivi authored
This flag was being mostly used as a meta flag in some cases and not covering other cases. One of the risks is that it was masking some frontbuffer trackings without disabling PSR. So, better to kill this at once and avoid umbrella parameters. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> [danvet: Drop unused out: label to appease gcc.] Signed-off-by:
-
- 25 Mar, 2015 3 commits
-
-
Mika Kuoppala authored
The faulting virtual address is >32bits and has been moved to different registers. Add to error state and output upper register first, in the same line for easy reconstruction of the fault address. v2: correct gen masking (Michel) v3: s/TBL/TLB (Ville) Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
It should have been negative since it is returned with ERR_PTR(). Introduced in new code commit: commit 50470bb0 Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Date: Mon Mar 23 11:10:36 2015 +0000 drm/i915/skl: Support secondary (rotated) frame buffer mapping Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Jesse Barnes authored
Or users can just spam the log all they want. Issue introduced in commit 9a8f0a12 Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Date: Fri Feb 27 11:15:24 2015 +0000 drm/i915/skl: Allow Y (and Yf) frame buffer creation References: https://bugs.freedesktop.org/show_bug.cgi?id=89628Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 24 Mar, 2015 3 commits
-
-
Ramalingam C authored
As part of allocation of the drm_i915_private variable, drrs capability enum is initialized to DRRS_NOT_SUPPORTED. Hence need not initialize at each connector init. Moreover initializing this enum at connector init will reset the successful DRRS initialization of previous connector, as we have the DRRS support for only one panel at a time. Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
-
Imre Deak authored
The logical place for clearing the RPS latched interrupt bits is when resetting the RPS interrupts, so move the corresponding part from the RPS disable function to the reset function. During resetting we already cleared the IIR bits, so the only thing missing there was clearing pm_iir. Note that we call gen6_disable_rps_interrupts() also during driver load and resume time via intel_uncore_sanitize() when i915 interrupts are still not installed. If there are any pending RPS bits at this point (which after this patch wouldn't be cleared) they will be cleared by the reset code via the interrupt preinstall hooks. Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Imre Deak authored
When disabling RPS interrupts there is a race where we disable RPS inerrupts while the interrupt handler is running and the handler has already latched the pending RPS interrupt from the master IIR register. Afterwards the disabling path clears the PM IIR bits, making the state of pending interrupts inconsistent from the interrupt handler's point of view. This triggers the following warning: "The master control interrupt lied (PM)!". To fix this make sure that any running interrupt handler (which may have already latched the master IIR) finishes before clearing the IIR bits. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87347Signed-off-by:
-
- 23 Mar, 2015 8 commits
-
-
Tvrtko Ursulin authored
v2: Pass in rotation info to sprite plane updates as well. v3: Use helper to determine 90/270 rotation. (Michel Thierry) v4: Rebased for fb modifiers and atomic changes. For: VIZ-4546 Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
Need to do this in order to support 90/270 rotated display. v2: Pass in drm_plane instead of plane index to intel_obj_display_address. v3: * Renamed intel_obj_display_address to intel_plane_obj_offset. (Chris Wilson) * Simplified rotation check to bitwise AND. (Chris Wilson) v4: * Extracted 90/270 rotation check into a helper function. (Michel Thierry) v5: * Rebased for ggtt view changes. For: VIZ-4545 Signed-off-by: -
Tvrtko Ursulin authored
90/270 rotated scanout needs a rotated GTT view of the framebuffer. This is put in a separate VMA with a dedicated ggtt view and wired such that it is created when a framebuffer is pinned to a 90/270 rotated plane. Rotation is only possible with Yb/Yf buffers and error is propagated to user space in case of a mismatch. Special rotated page view is constructed at the VMA creation time by borrowing the DMA addresses from obj->pages. v2: * Do not bother with pages for rotated sg list, just populate the DMA addresses. (Daniel Vetter) * Checkpatch cleanup. v3: * Rebased on top of new plane handling (create rotated mapping when setting the rotation property). * Unpin rotated VMA on unpinning from display plane. * Simplify rotation check using bitwise AND. (Chris Wilson) v4: * Fix unpinning of optional rotated mapping so it is really considered to be optional. v5: * Rebased for fb modifier changes. * Rebased for atomic commit. * Only pin needed view for display. (Ville Syrjälä, Daniel Vetter) v6: * Rebased after preparatory work has been extracted out. (Daniel Vetter) v7: * Slightly simplified tiling geometry calculation. * Moved rotated GGTT view implementation into i915_gem_gtt.c (Daniel Vetter) v8: * Do not use i915_gem_obj_size to get object size since that actually returns the size of an VMA which may not exist. * Rebased for ggtt view changes. v9: * Rebased after code review changes on the preceding patches. * Tidy function definitions. (Joonas Lahtinen) For: VIZ-4726 Signed-off-by: -
Tvrtko Ursulin authored
For now only default implementation defaulting to normal view. v2: Some code review cleanups. (Joonas Lahtinen) Signed-off-by:
-
Tvrtko Ursulin authored
Plane state carries the rotation information which is needed for determining the appropriate GGTT view type. This just adds the parameter with the actual usage coming in future patches. Signed-off-by:
-
Tvrtko Ursulin authored
To support frame buffer rotation we need to be able to pass on the information on what kind of GGTT view is required for display. This patch just adds the parameter and makes all the callers default to the normal view. v2: Rebased for ggtt view changes. v3: Don't limit PIN_MAPPABLE to normal views just yet. (Joonas Lahtinen) Signed-off-by:
-
Tvrtko Ursulin authored
It will be used in a later patch and also convert all height parameters from int to unsigned int. v2: Rebased for fb modifiers. v3: Fixed v2 rebase. v4: * Height should be unsigned int. * Make it take pixel_format for consistency and simplicity. Signed-off-by:
-
Ville Syrjälä authored
msleep() can sleep for way too long, so switch wait_for() to use usleep_range() instead. Following a totally unscientific method I just picked the range as W-2W. This cuts the i915 init time on my BSW to almost half: - initcall i915_init+0x0/0xa8 [i915] returned 0 after 419977 usecs + initcall i915_init+0x0/0xa8 [i915] returned 0 after 238419 usecs Note that I didn't perform any other benchmarks on this so far. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 20 Mar, 2015 8 commits
-
-
Michel Thierry authored
While running kmemleak chasing a different memleak, I saw that the capture_error_state function was leaking some objects, for example: unreferenced object 0xffff8800a9b72148 (size 8192): comm "kworker/u16:0", pid 1499, jiffies 4295201243 (age 990.096s) hex dump (first 32 bytes): 00 00 04 00 00 00 00 00 5d f4 ff ff 00 00 00 00 ........]....... 00 30 b0 01 00 00 00 00 37 00 00 00 00 00 00 00 .0......7....... backtrace: [<ffffffff811e5ae4>] create_object+0x104/0x2c0 [<ffffffff8178f50a>] kmemleak_alloc+0x7a/0xc0 [<ffffffff811cde4b>] __kmalloc+0xeb/0x220 [<ffffffffa038f1d9>] kcalloc.constprop.12+0x2d/0x2f [i915] [<ffffffffa0316064>] i915_capture_error_state+0x3f4/0x1660 [i915] [<ffffffffa03207df>] i915_handle_error+0x7f/0x660 [i915] [<ffffffffa03210f7>] i915_hangcheck_elapsed+0x2e7/0x470 [i915] [<ffffffff8108d574>] process_one_work+0x144/0x490 [<ffffffff8108dfbd>] worker_thread+0x11d/0x530 [<ffffffff81094079>] kthread+0xc9/0xe0 [<ffffffff817a2398>] ret_from_fork+0x58/0x90 [<ffffffffffffffff>] 0xffffffffffffffff The following objects are allocated in i915_gem_capture_buffers, but not released in i915_error_state_free: - error->active_bo_count - error->pinned_bo - error->pinned_bo_count - error->active_bo[vm_count] (allocated in i915_gem_capture_vm). The leaks were introduced by commit 95f5301d Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Jul 31 17:00:15 2013 -0700 drm/i915: Update error capture for VMs v2: Reuse iterator and add culprit commit details (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: -
Ville Syrjälä authored
Write the PLANE_SURF register instead of PLANE_CTL to arm the double buffer regisrter update. Signed-off-by:
-
Ville Syrjälä authored
Replace the RMW access with explicit initialization of the entire plane control register, as was done for primary planes in: commit f45651ba Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Aug 8 21:51:10 2014 +0300 drm/i915: Eliminate rmw from .update_primary_plane() The automagic primary plane disable is still doing RMWs, but that will require more work to untangle, so leave it alone for now. Signed-off-by:
-
Ville Syrjälä authored
Store the colorkey in intel_plane and kill off all the RMW stuff handling it. This is just an intermediate step and eventually the colorkey needs to be converted into some properties. v2: Actually update the hardware state in the set_colorkey ioctl (Daniel) Signed-off-by:
-
Matt Roper authored
Determining whether we'll need to wait for vblanks is something we should determine during the atomic 'check' phase, not the 'commit' phase. Note that we only set these bits in the branch of 'check' where intel_crtc->active is true so that we don't try to wait on a disabled CRTC. The whole 'wait for vblank after update' flag should go away in the future, once we start handling watermarks in a proper atomic manner. This regression has been introduced in commit 2fdd7def16dd7580f297827930126c16b152ec11 Author: Matt Roper <matthew.d.roper@intel.com> Date: Wed Mar 4 10:49:04 2015 -0800 drm/i915: Don't clobber plane state on internal disables Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Root-cause-analysis-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89550 Testcase: igt/pm_rpm/legacy-planes Testcase: igt/pm_rpm/legacy-planes-dpms Testcase: igt/pm_rpm/universal-planes Testcase: igt/pm_rpm/universal-planes-dpms Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Tested-by:
-
Imre Deak authored
Prepare chv_find_best_dpll to be used for BXT too, where we want to consider the error between target and calculated frequency too when choosing a better PLL configuration. No functional change. Signed-off-by:
-
Imre Deak authored
Signed-off-by:
-
Imre Deak authored
Factor out the logic to decide whether the newly calculated dividers are better than the best found so far. Do this for clarity and to prepare for the upcoming BXT helper needing the same. No functional change. Signed-off-by:
-
