diff options
author | Hans de Goede <j.w.r.degoede@gmail.com> | 2017-10-19 14:16:20 +0300 |
---|---|---|
committer | Hans de Goede <hdegoede@redhat.com> | 2017-11-10 15:14:03 +0300 |
commit | a5266db4d31410fbfb4f40118e58085994e83dbc (patch) | |
tree | b099422f48b315d1e9f83da9b80a722dd7fd36ec /mm/internal.h | |
parent | af0ab55ffe2467fab82bc0909e469cba7701fac7 (diff) | |
download | linux-a5266db4d31410fbfb4f40118e58085994e83dbc.tar.xz |
drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset()
intel_uncore_forcewake_reset() does forcewake puts and gets as such
we need to make sure that no-one tries to access the PUNIT->PMIC bus
(on systems where this bus is shared) while it runs, otherwise bad
things happen.
Normally this is taken care of by the i915_pmic_bus_access_notifier()
which does an intel_uncore_forcewake_get(FORCEWAKE_ALL) when some other
driver tries to access the PMIC bus, so that later forcewake gets are
no-ops (for the duration of the bus access).
But intel_uncore_forcewake_reset gets called in 3 cases:
1) Before registering the pmic_bus_access_notifier
2) After unregistering the pmic_bus_access_notifier
3) To reset forcewake state on a GPU reset
In all 3 cases the i915_pmic_bus_access_notifier() protection is
insufficient.
This commit fixes this race by calling iosf_mbi_punit_acquire() before
calling intel_uncore_forcewake_reset(). In the case where it is called
directly after unregistering the pmic_bus_access_notifier, we need to
hold the punit-lock over both calls to avoid a race where
intel_uncore_fw_release_timer() may execute between the 2 calls.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171019111620.26761-3-hdegoede@redhat.com
Diffstat (limited to 'mm/internal.h')
0 files changed, 0 insertions, 0 deletions