Re: [Intel-gfx] [PATCH 1/3] drm/i915/skl+: Don't trust cached ddb values

Hi, On Saturday 27 May 2017 02:53 AM, Rodrigo Vivi wrote: On Fri, May 26, 2017 at 8:15 AM, Mahesh Kumar wrote: Don't trust cached DDB values. Recalculate the ddb value if cached value is zero. If i915 is build as a module, there may be a race condition when

Re: [Intel-gfx] [PATCH RESEND] drm: i915: Don't try detecting sinks on ports already in use

Chris Wilson writes: > The key problem here is say a race between DP unplug and HDMI plug, and > users are evil enough (or common enough) for it to happen. > > I thought the idea was reasonable though, and perhaps we could make > more use of the knowlege of the shared

Re: [Intel-gfx] [PATCH] drm: i915: Preserve old FBC status for update without new planes

Gabriel Krisman Bertazi writes: > If the atomic commit doesn't include any new plane, there is no need to > choose a new CRTC for FBC, and the intel_fbc_choose_crtc() will bail out > early. Although, if the FBC setup failed in the previous commit, if the > current

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier

Hi, On 19-05-17 15:27, Hans de Goede wrote: assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier even though it gets unregistered on (runtime) suspend, this is caused by a race happening under the following circumstances: intel_runtime_pm_put does:

Re: [Intel-gfx] [PULL] drm-misc-fixes

On Fri, May 26, 2017 at 08:36:45AM +0200, Daniel Vetter wrote: > On Thu, May 25, 2017 at 7:44 PM, Sean Paul wrote: > > The pull is noisy because it includes -rc2. > > dim has you covered for this, in case you've rolled forward but Dave > hasn't yet, you can regenerate