- 15 May, 2017 2 commits
-
-
Chris Wilson authored
Some 64b divides snuck in when doing the prng timing compensation. Fixes: 47979480 ("drm/i915: Squash repeated awaits on the same fence") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170513094154.3581-1-chris@chris-wilson.co.ukReviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Daniel Vetter authored
Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 13 May, 2017 8 commits
-
-
Robert Bragg authored
This change is pre-emptively aiming to avoid a potential cause of kernel logging noise in case some condition were to result in us seeing invalid OA reports. The workaround for the OA unit's tail pointer race condition is what avoids the primary known cause of invalid reports being seen and with that in place we aren't expecting to see this notice but it can't be entirely ruled out. Just in case some condition does lead to the notice then it's likely that it will be triggered repeatedly while attempting to append a sequence of reports and depending on the configured OA sampling frequency that might be a large number of repeat notices. v2: (Chris) avoid inconsistent warning on throttle with printk_ratelimit() v3: (Matt) init and summarise with stream init/close not driver init/fini Signed-off-by:Robert Bragg <robert@sixbynine.org> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170511154345.962-9-lionel.g.landwerlin@intel.comSigned-off-by:
-
Robert Bragg authored
This updates the tail pointer race workaround handling to updating the 'aged' pointer before looking to start aging a new one. There's the possibility that there is already new data available and so we can immediately start aging a new pointer without having to first wait for a later hrtimer callback (and then another to age). Signed-off-by:
-
Robert Bragg authored
A minor improvement to debugging output Signed-off-by:
-
Robert Bragg authored
There's a HW race condition between OA unit tail pointer register updates and writes to memory whereby the tail pointer can sometimes get ahead of what's been written out to the OA buffer so far (in terms of what's visible to the CPU). Although this can be observed explicitly while copying reports to userspace by checking for a zeroed report-id field in tail reports, we want to account for this earlier, as part of the _oa_buffer_check to avoid lots of redundant read() attempts. Previously the driver used to define an effective tail pointer that lagged the real pointer by a 'tail margin' measured in bytes derived from OA_TAIL_MARGIN_NSEC and the configured sampling frequency. Unfortunately this was flawed considering that the OA unit may also automatically generate non-periodic reports (such as on context switch) or the OA unit may be enabled without any periodic sampling. This improves how we define a tail pointer for reading that lags the real tail pointer by at least %OA_TAIL_MARGIN_NSEC nanoseconds, which gives enough time for the corresponding reports to become visible to the CPU. The driver now maintains two tail pointers: 1) An 'aging' tail with an associated timestamp that is tracked until we can trust the corresponding data is visible to the CPU; at which point it is considered 'aged'. 2) An 'aged' tail that can be used for read()ing. The two separate pointers let us decouple read()s from tail pointer aging. The tail pointers are checked and updated at a limited rate within a hrtimer callback (the same callback that is used for delivering POLLIN events) and since we're now measuring the wall clock time elapsed since a given tail pointer was read the mechanism no longer cares about the OA unit's periodic sampling frequency. The natural place to handle the tail pointer updates was in gen7_oa_buffer_is_empty() which is called as part of blocking reads and the hrtimer callback used for polling, and so this was renamed to oa_buffer_check() considering the added side effect while checking whether the buffer contains data. Signed-off-by: -
Robert Bragg authored
This avoids redundantly passing an (inout) head and tail pointer to gen7_append_oa_reports() from gen7_oa_read which doesn't need to reference either itself. Moving the head/tail reads and writes into gen7_append_oa_reports should have no functional effect except to avoid some redundant head pointer writes in cases where nothing was copied to userspace. This is a stepping stone towards updating how the head and tail pointer state is managed to improve the workaround for the OA unit's tail pointer race. It reduces the number of places we need to read/write the head and tail pointers. Signed-off-by:
-
Robert Bragg authored
There's no need for the driver to keep reading back the head pointer from hardware since the hardware doesn't update it automatically. This way we can treat any invalid head pointer value as a software/driver bug instead of spurious hardware behaviour. This change is also a small stepping stone towards re-working how the head and tail state is managed as part of an improved workaround for the tail register race condition. Signed-off-by:
-
Robert Bragg authored
If the function for checking whether there is OA buffer data available (during a poll or blocking read) has false positives then we want to avoid a situation where the subsequent read() returns EAGAIN (after a more accurate check) followed by a poll() immediately reporting the same false positive POLLIN event and effectively maintaining a busy loop until there really is data. This makes sure that we clear the .pollin event status whenever we return EAGAIN to userspace which will throttle subsequent POLLIN events and repeated attempts to read to the 5ms intervals of the hrtimer callback we have. Signed-off-by:
-
Robert Bragg authored
If I'm going to complain about a back-to-front convention then the least I can do is not muddle the comment up too. Signed-off-by:
-
- 12 May, 2017 6 commits
-
-
Puthikorn Voravootivat authored
Some panel will default to zero brightness when turning the panel off and on again. This patch restores last brightness level back when panel is turning back on. Signed-off-by:
Puthikorn Voravootivat <puthik@chromium.org> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170511230225.142870-8-puthik@chromium.org
-
Puthikorn Voravootivat authored
We should set backlight mode register before set register to enable the backlight. Signed-off-by:
-
Puthikorn Voravootivat authored
intel_dp_aux_enable_backlight() assumed that the register BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01 (DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize. This patch fixed that by handling all cases of that register. Signed-off-by:
-
Puthikorn Voravootivat authored
intel_dp_aux_backlight driver should check for the DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP before enable the driver. Signed-off-by:
-
Matthew Auld authored
If a vma is already bound to a ppgtt, we incorrectly call allocate_va_range again when doing a PIN_UPDATE, which will result in over accounting within our paging structures, such that when we do unbind something we don't actually destroy the structures and end up inadvertently recycling them. In reality this probably isn't too bad, but once we start touching PDEs and PDPEs for 64K/2M/1G pages this apparent recycling will manifest into lots of really, really subtle bugs. v2: Fix the testing of vma->flags for aliasing_ppgtt_bind_vma Fixes: ff685975 ("drm/i915: Move allocate_va_range to GTT") Signed-off-by:
-
Chuanxiao Dong authored
During execlist_context_deferred_alloc() we presumed that the context is uninitialised (we only just allocated the state object for it!) and chose to optimise away the later call to engine->init_context() if engine->init_context were NULL. This breaks with GVT's contexts that are marked as pre-initialised to avoid us annoyingly calling engine->init_context(). The fix is to not override ce->initialised if it is already true. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chuanxiao Dong <chuanxiao.dong@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1494497262-24855-1-git-send-email-chuanxiao.dong@intel.comReviewed-by:
-
- 11 May, 2017 6 commits
-
-
Joonas Lahtinen authored
Due to the complex dependencies between workqueues and RCU, which are not easily detected by lockdep, do not synchronize RCU during shrinking. On low-on-memory systems (mem=1G for example), the RCU sync leads to all system workqueus freezing and unrelated lockdep splats are displayed according to reports. GIT bisecting done by J. R. Okajima points to the commit where RCU syncing was extended. RCU sync gains us very little benefit in real life scenarios where the amount of memory used by object backing storage is dominant over the metadata under RCU, so drop it altogether. " Yeeeaah, if core could just, go ahead and reclaim RCU queues, that'd be great. " - Chris Wilson, 2016 (0eafec6d) v2: More information to commit message. v3: Remove "grep _rcu_" escapee from i915_gem_shrink_all (Andrea) Fixes: c053b5a5 ("drm/i915: Don't call synchronize_rcu_expedited under struct_mutex") Suggested-by:
J. R. Okajima <hooanon05g@gmail.com> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Hugh Dickins <hughd@google.com> Tested-by:
Andrea Arcangeli <aarcange@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: J. R. Okajima <hooanon05g@gmail.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Hugh Dickins <hughd@google.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: <stable@vger.kernel.org> # v4.11+ Link: http://patchwork.freedesktop.org/patch/msgid/1494414040-11160-1-git-send-email-joonas.lahtinen@linux.intel.com
-
Michal Wajdeczko authored
We are using some scratch registers in MMIO based send function. Make their base and count flexible in preparation of upcoming GuC firmware/hardware changes. While around, change cmd len parameter verification from WARN_ON to GEM_BUG_ON as we don't need this all the time. v2: call out WARN/GEM_BUG change in the commit msg (Daniele) v3: don't overqualify the ints (Chris) v4: rebase and use proper enum Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
-
Michal Wajdeczko authored
Prepare for alternate GuC notification mechanism. Signed-off-by:
-
Maarten Lankhorst authored
commit a667fb40 Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Thu Dec 15 15:29:44 2016 +0100 drm/i915: Disable all crtcs during driver unload, v2. made sure that all crtc's are disabled on driver unload, but only the following commit made sure all fb's are cleaned up correctly: commit 9b2104f4 Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Tue Feb 21 14:51:40 2017 +0100 drm/atomic: Make disable_all helper fully disable the crtc. Finally remove this and add a WARN_ON when vma is set. It should have been removed by intel_cleanup_plane_fb(). Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170511082844.13965-2-maarten.lankhorst@linux.intel.comReviewed-by:
-
Maarten Lankhorst authored
We shouldn't inspect crtc->state, instead grab the crtc state. At this point the hw state verifier should be able to run even if crtc->state has been updated (which cannot currently happen). Signed-off-by:
-
Oscar Mateo authored
We are missing pieces of information that could be useful for GuC debugging. v2: Reuse some code (Joonas) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Oscar Mateo <oscar.mateo@intel.com> [Joonas: Removed extra newline and s/uint32_t/u32/ for checkpatch.pl] Signed-off-by:
-
- 10 May, 2017 18 commits
-
-
Daniel Vetter authored
The unconditionally fallback to the blocking wait_for resulted in impressive fireworks at boot-up on my snb here. Make sure if we set the slow timeout to 0 that we never ever sleep. The tail of the callchain was intel_wait_for_register -> __intel_wait_for_register_fw -> usleep_range -> BOOM It blew up in intel_crt_detect load detection code on the ADPA_CRT_HOTPLUG_FORCE_TRIGGER in the ADPA register. v2: Shut up gcc. v3: Use uninitialized_var() (Chris). Fixes: 05646543 ("drm/i915: Acquire uncore.lock over intel_uncore_wait_for_register()") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1494429572-15118-1-git-send-email-daniel.vetter@ffwll.ch
-
Ville Syrjälä authored
It looks like simply writing all the cursor register every single time might be slightly faster than checking to see of each of them need to be written. So if any other register apart from CURPOS needs to be written let's just write all the registers. CURPOS is left as a special case mainly for 845/865 where we have to disable the cursor to change many of the cursor parameters. This introduces a slight chance of the cursor flickering when things get updated (since we're not currently doing the vblank evade for cursor updates). If we write CURPOS alone then that obviously can't happen. And let's follow the same pattern in the i9xx code just for symmetry. I wasn't able to see a singificant performance difference between this and just writing all the registers unconditionally. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170327185546.2977-16-ville.syrjala@linux.intel.comReviewed-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
Supposedly 845/865 require only 32 byte alignment for CURBASE. Let's relax the checks to allow that instead of demanding 4KiB alignment. This will allow cursor panning in 8 pixel units. Signed-off-by:
-
Ville Syrjälä authored
The cursor plane doesn't have any kind of source offset register, so the only form of panning possible is via a the base address register. The alignment required by CURBASE ranges from 32B to 16KiB depending on the platform. Let's make sure the user didn't ask for something we can't do. Obviously this is impossible to hit via the legacy cursor ioctl since the src offsets are always 0, but via the plane/atomic ioctls the user can ask for pretty much anything so we have to deal with this. Signed-off-by:
-
Ville Syrjälä authored
Bspec tells us that gen3 platforms need 4KiB alignment for CURBASE rather than the 256 byte alignment required by i85x. Let's fix that and pull the code to determine the correct alignment to a helper function. Signed-off-by:
-
Ville Syrjälä authored
IVB introduced the CUR_FBC_CTL register which allows reducing the cursor height down to 8 lines from the otherwise square cursor dimensions. Implement support for it. CUR_FBC_CTL can't be used when the cursor is rotated. Commandeer the otherwise unused cursor->cursor.size to track the current value of CUR_FBC_CTL to optimize away redundant CUR_FBC_CTL writes, and to notice when we need to arm the update via CURBASE if just CUR_FBC_CTL changes. v2: Reverse the gen check to make it sane v3: Only enable CUR_FBC_CTL when cursor is enabled, adapt to earlier code changes which means we now actually turn off the cursor when we're supposed to unlike v2 v4: Add a comment about rotation vs. CUR_FBC_CTL, rebase due to 'dirty' (Chris) v5: Rebase to the atomic world Handle 180 degree rotation Add HAS_CUR_FBC() v6: Rebase v7: Rebase due to I915_WRITE_FW/uncore.lock s/size/fbc_ctl/ Signed-off-by: -
Ville Syrjälä authored
The cursor code currently ignores fb->pitches[0] (except when creating the fb itself), and just uses the cursor_width*4 as the stride. Let's make sure fb->pitches[0] actually matches what we expect it to be. We can also relax the stride vs. cursor width relationship on 845/865 since the stride is programmed separately. The only constraint is that width*cpp doesn't exceed the stride, and that's already been checked by the core since it makes sure the entire plane fits within the fb. We can also drop the bo size check as that's already checked when we create the fb. That is the fb is guaranteed to fit within the bo. v2: Rebase due to i845_cursor_ctl() and i9xx_cursor_ctl() Signed-off-by:
-
Ville Syrjälä authored
We have the maximum cursor dimensions stored in the mode_config, so let's just consult that information instead of hardcoding the same information in multiple places. We still need to keep some per-platform checks as the limitations are quite diverse. Signed-off-by:
-
Ville Syrjälä authored
The 845/865 and 830/855/9xx+ style cursor don't have that much in common with each other, so let's just split the .check_plane() hook into two variants as well. v2: Keep the common stuff in one place (Chris) v3: s/DRM_FORMAT_MOD_NONE/DRM_FORMAT_MOD_LINEAR/ Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
There should be no need to do posting reads between all the cursor register accessess. Let's just drop them. v2: Rebase due to I915_WRITE_FW() and uncore.lock Signed-off-by:
-
Ville Syrjälä authored
Supposedly on some platforms we can get extra atomicity guarantees for CURPOS if we write it between the CURCNTR and CURBASE. Let's move the CURPOS handling into the platform specific hooks to make the possible without having to pass the calculated CURPOS around. And while at it, do the same for the CURBASE to avoid passing that either. v2: Use I915_WRITE_FW() and grab uncore.lock Signed-off-by:
-
Ville Syrjälä authored
Move the CURPOS calculations to seprate function. This will allow sharing the code between the 845/865 vs. others codepaths when we otherwise split them apart. v2: Don't pass intel_plane as it's not needed Signed-off-by:
-
Ville Syrjälä authored
Move cursor_base, cursor_cntl, and cursor_size from intel_crtc into intel_plane so that we don't need the crtc for cursor stuff so much. Also entirely nuke cursor_addr which IMO doesn't provide any benefit since it's not actually used by the cursor code itself. I'm not 100% sure what the SKL+ DDB is code is after by looking at cursor_addr so I just make it do its checks unconditionally. If that's not correct then we should likely replace it with somehting like plane_state->visible. Signed-off-by:
-
Ville Syrjälä authored
The remaining cursor base address calculations are spread around into several different locations. Just pull it all into one place. v2: Don't pass intel_plane as we don't really need it Signed-off-by:
-
Ville Syrjälä authored
Streamline things by passing intel_plane and intel_crtc instead of the drm types to our plane hooks. v2: s/ilk/g4x/ in sprite code Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Now that the watermarks are in order, it should be safe to enable sprite planes on g4x. We alreday have the code in fact, we just call it ilk_. Let's rename to g4x_ and let it loose. Signed-off-by:
-
Ville Syrjälä authored
Add a tracepoint for watermark programming on g4x, similar to what we have on vlv/chv. Should help in debugging watermark programming sequence issues. Signed-off-by:
-
