Zhenyu Wang [Tue, 1 Apr 2014 22:39:48 +0000 (19:39 -0300)]
drm/i915: Allow i915_pc8_status debug info on BDW
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Tue, 1 Apr 2014 23:31:07 +0000 (16:31 -0700)]
drm/i915/bdw: Expand FADD to 64bit
For error state, like the recent modification to ACTHD, FADD also gets
an upper dword. This is useful for debug to make sure the fetch address
and head are similar.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
BSpec seems to tell us we need the MI_ARB_ON_OFF w/a around
MI_SET_CONTEXT on gen8.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Fri, 7 Mar 2014 23:12:37 +0000 (20:12 -0300)]
drm/i915: add BDW runtime PM support
This sould be enough.
v2: BDW should also run hsw_runtime_resume (Ben).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Fri, 7 Mar 2014 23:12:36 +0000 (20:12 -0300)]
drm/i915: BDW needs D_COMP writes through MCHBAR
That's what the spec said! And HSW needs it through pcode (you can
only read it through MCHBAR), so create hsw_write_dcomp to abstract
the weirdness.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Fri, 7 Mar 2014 23:12:35 +0000 (20:12 -0300)]
drm/i915: remove HAS_PC8 check
Now that PC8 is part of runtime PM, the check is useless.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We're adding runtime suspend support to more platforms, so organize
the code in a way that all a new platform needs to do is to add its
own gen-specific functions. Also rename the i915_ functions to intel_
to make it clear that it's the top level one, not something that just
runs on i915 platforms.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Fri, 7 Mar 2014 23:12:32 +0000 (20:12 -0300)]
drm/i915: kill dev_priv->pm.regsave
Now that we don't keep the hotplug interrupts enabled anymore, we can
kill the regsave struct and just cal the normal IRQ preinstall,
postinstall and uninstall functions. This makes it easier to add
runtime PM support to non-HSW platforms.
The only downside is in case we get a request to update interrupts
while they are disabled, won't be able to update the regsave struct.
But this should never happen anyway, so we're not losing too much.
v2: - Rebase.
v3: - Rebase.
v4: - Rebase.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:27 +0000 (15:37 -0300)]
drm/i915: only enable HWSTAM interrupts on postinstall on ILK+
We should only enable interrupts at postinstall.
And now on ILK/SNB/IVB/HSW the irq_preinstall and irq_postinstall
functions leave the hardware in the same state.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix compile fail due to drm_i915_private_t typedef removal.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:25 +0000 (15:37 -0300)]
drm/i915: add ironlake_irq_reset
To merge the common code of ironlake_irq_preinstall and
ironlake_irq_uninstall.
We should also probably do something about that HSWSTAM write on a
later commit.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix compile fail due to drm_i915_private_t typedef removal.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:24 +0000 (15:37 -0300)]
drm/i915: add missing intel_hpd_irq_uninstall
Missing from gen8_irq_uninstall.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:23 +0000 (15:37 -0300)]
drm/i915: remove ibx_irq_uninstall
After the latest changes, ibx_irq_preinstall and ibx_irq_uninstall are
the same, so remove one of the copies and rename the other to
ibx_irq_reset (since we're using the "reset" name for things which are
called both at preinstall and uninstall).
v2: - Rebase.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:22 +0000 (15:37 -0300)]
drm/i915: enable SDEIER later
On the preinstall stage we should just disable all the interrupts, but
we currently enable all the south display interrupts due to the way we
touch SDEIER at the IRQ handlers (note: they are still masked and our
IRQ handler is disabled). Instead of doing that, let's make the
preinstall stage just disable all the south interrupts, and do the
proper interrupt dance/ordering at the postinstall stage, including an
assert to check if everything is behaving as expected.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:21 +0000 (15:37 -0300)]
drm/i915: call ibx_irq_uninstall from gen8_irq_uninstall
After all, we call ibx_irq_preinstall from gen8_irq_preinstall.
v2: - Rebase.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:20 +0000 (15:37 -0300)]
drm/i915: extract ibx_irq_uninstall
Just like ibx_irq_preinstall. We'll call this from somewhere else in
the next patch.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:18 +0000 (15:37 -0300)]
drm/i915: fix GEN7_ERR_INT init/reset code
Same as SERR_INT and the other IIR registers: reset on
preinstall/uninstall and WARN for non-zero values at postinstall. This
one also doesn't need double-clear.
v2: - Remove the is_zero assertion (Ben).
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:17 +0000 (15:37 -0300)]
drm/i915: fix SERR_INT init/reset code
The SERR_INT register is very similar to the other IIR registers, so
let's zero it at preinstall/uninstall and WARN for a non-zero value at
postinstall, just like we do with the other IIR registers. For this
one, there's no need to double-clear since it can't store more than
one interrupt.
v2: - Remove the is_zero assertion (Ben).
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:16 +0000 (15:37 -0300)]
drm/i915: check if IIR is still zero at postinstall on Gen5+
It should already be masked and disabled and zeroed at the preinstall
and uninstall stages. Also, the current code just writes to IIR once,
and this is not a guarantee that it will be cleared, so it's wrong
anyway.
The whole reason for the paranoia is that we're going to start calling
the IRQ preinstall/postinstall/uninstall from the runtime PM
callbacks, so we need to make sure everything is behaving as expected.
v2: - Change the original DRM_ERROR to WARN and clear IIR in case it's
not zero (Ben).
- Improve commit message (Daniel).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:15 +0000 (15:37 -0300)]
drm/i915: add GEN5_IRQ_INIT
And the equivalent GEN8_IRQ_INIT_NDX macro. These macros are for the
postinstall functions. The next patch will improve this macro.
v2: - Adjust to the new POSTING_READ scheme (Ben).
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:14 +0000 (15:37 -0300)]
drm/i915: properly clear IIR at irq_uninstall on Gen5+
The IRQ_INIT and IRQ_FINI macros are basically the same thing, with
the exception that IRQ_FINI doesn't properly clear IIR twice and
doesn't have as many POSTING_READs as IRQ_INIT. So rename the INIT
macro to IRQ_RESET and use it everywhere.
v2: - Fix error in the commit message (Chris).
- Adjust to the new POSTING_READ scheme (Ben).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:13 +0000 (15:37 -0300)]
drm/i915: don't forget to uninstall the PM IRQs
It's the only thing missing, apparently.
v2: - Fix typo (Ben).
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:12 +0000 (15:37 -0300)]
drm/i915: add GEN5_IRQ_FINI
Same as the _INIT macro: the goal is to reuse the GEN8 macros, but
there are still some slight differences.
v2: - Rebase.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:11 +0000 (15:37 -0300)]
drm/i915: use GEN8_IRQ_INIT on GEN5
And rename it to GEN5_IRQ_INIT.
We have discussed doing equivalent changes on July 2013, and I even
sent a patch series for this: "[PATCH 00/15] Unify interrupt register
init/reset". Now that the BDW code was merged, I have one more
argument in favor of these changes.
Here's what really changes with the Gen 5 IRQ init code:
- We now clear the IIR registers at preinstall (they are also
cleared at postinstall, but we will change that later).
- We have an additional POSTING_READ at the IMR register.
v2: - Fix typo in commit message.
- Add POSTING_READ calls to the macros (Ben, Daniel, Jani).
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:10 +0000 (15:37 -0300)]
drm/i915: also use GEN5_IRQ_INIT with south display interrupts
This interrupt gets initialized with a different IER value, so it was
not using the macro. The problem is that we plan to modify the macro
to make it do additional things, and we want the SDE interrupts
updated too. So let's make sure we call the macro, then, after it, we
do the necessary SDE-specific changes.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 18:37:09 +0000 (15:37 -0300)]
drm/i915: add GEN5_IRQ_INIT macro
The goal is to reuse the GEN8 macros, but a few changes are needed, so
let's make things easier to review.
I could also use these macros on older code, but since I plan to
change how the interrupts are initialized, we'll risk breaking the
older code in the next commits, so I'll leave this out for now.
v2: - Rebase.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pradeep Bhat [Fri, 28 Mar 2014 04:44:57 +0000 (10:14 +0530)]
drm/i915: Adding VBT fields to support eDP DRRS feature
This patch reads the DRRS support and Mode type from VBT fields.
The read information will be stored in VBT struct during BIOS
parsing. The above functionality is needed for decision making
whether DRRS feature is supported in i915 driver for eDP panels.
This information helps us decide if seamless DRRS can be done
at runtime to support certain power saving features. This patch
was tested by setting necessary bit in VBT struct and merging
the new VBT with system BIOS so that we can read the value.
v2: Incorporated review comments from Chris Wilson
Removed "intel_" as a prefix for DRRS specific declarations.
v3: Incorporated Jani's review comments
Removed function which deducts drrs mode from panel_type. Modified some
print statements. Made changes to use DRRS_NOT_SUPPORTED as 0 instead of -1.
v4: Incorporated Jani's review comments.
Modifications around setting vbt drrs_type.
Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com> Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Jani Nikula <jani.nikula@linux.intel.com>
[danvet: Drop the misleading/redundant comment about the added drrs
field in the vbt struct as discussed with Jani on irc.] Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 1 Apr 2014 09:59:08 +0000 (12:59 +0300)]
drm: Make drm_clflush_virt_range() void*
Currently drm_cflush_virt_rage() takes a char* so the caller probably
has to do pointless casting to avoid compiler warnings. Make the
argument void* instead to avoid such issues.
v2: Use void* arithmetic (Chris)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 1 Apr 2014 07:54:36 +0000 (10:54 +0300)]
drm/i915: Refactor gmch hpd irq handling
Pull all the gmch platform hotplug interrupt handling into one
function.
v2: Move the IIR check to the caller
s/drm_i915_private_t/struct drm_i915_private/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add posting read comment suggested by Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Tue, 1 Apr 2014 00:16:42 +0000 (17:16 -0700)]
drm/i915/bdw: Extract rp_state_caps logic
We have a need for duplicated parsing of the RP_STATE_CAPS register (and
the setting of the associated fields). To reuse some code, we can
extract the function into a simple helper.
This patch also addresses the fact that we missed doing this for gen8,
something we should have done anyway.
This could be two patches, one to extract, and one to add gen8, but it's
trivial enough that I think one is fine. I will accept a request to
split it. Please notice the fix addressed by v2 below.
Valleyview is left untouched because it is different.
Note with the above change the fix for gen8 is also handled (which was
not the case in Jeff's original patch).
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Tue, 1 Apr 2014 00:16:41 +0000 (17:16 -0700)]
drm/i915/bdw: Set initial rps freq to RP1
Programming it outside of the rp0-rp1 range is considered a programming
error. Since we do not know that the previous value would actually be in
the range, program something we've read from the hardware, and therefore
know will work.
This is potentially an issue for platforms whose ranges are outside the
norms given in the programming guide (ie. early silicon)
v2: Use RP1 instead of RPn
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Mon, 31 Mar 2014 15:21:26 +0000 (18:21 +0300)]
drm/i915: Split dp post_disable hooks
Split the post_disable hooks for DP to g4x and vlv variants. We'll
need another variant soon, so this should make it look a bit cleaner.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Mon, 31 Mar 2014 18:29:41 +0000 (21:29 +0300)]
drm/i915: Kill crtc->plane checks from the primary plane update hooks
These were apparently meant to protect the SAREA which only has
room for two pipes, but things clearly went a bit wonky when
first the .update_plane() hooks were split up and then pipe C
got introduced.
The checks actually protecting the SAREA live in
intel_crtc_update_sarea() these days, so the checks in the primary
plane update hooks are just historical leftovers which are to be
eliminated.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jani Nikula [Mon, 31 Mar 2014 11:27:22 +0000 (14:27 +0300)]
drm/i915: drop the typedef for drm_i915_private_t
There are no longer users of drm_i915_private_t. Drop the typedef. Good
riddance.
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Chris Wilson <chris@chris-wislon.co.uk>
[danvet: Add the hunk in i915_cmd_parser.c here which had to be
relocated to the how this was merged.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Damien Lespiau [Mon, 31 Mar 2014 10:24:08 +0000 (11:24 +0100)]
drm/i915: Use a macro to express the range of valid gens for reg_read
The reg_read whitelist has a gen bitmask to code the gens we're allowing
the register to be read on. Until now, it was a literal, but we can be
a bit more expressive.
Damien Lespiau [Fri, 28 Mar 2014 16:54:26 +0000 (16:54 +0000)]
drm/i915: Hide the per forcewake-engine register ranges
These defines are only used in intel_uncore.c.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Damien Lespiau [Fri, 28 Mar 2014 16:54:25 +0000 (16:54 +0000)]
drm/i915: Hide vlv_force_wake_{get, put}() in intel_uncore.c
That function isn't used outside this file anymore.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Christoph Jaeger [Fri, 28 Mar 2014 09:19:24 +0000 (10:19 +0100)]
drm/i915: drop __FUNCTION__ as argument to DRM_DEBUG_KMS
DRM_DEBUG_KMS includes printing the function name.
Signed-off-by: Christoph Jaeger <christophjaeger@linux.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Damien Lespiau [Fri, 28 Mar 2014 14:17:49 +0000 (14:17 +0000)]
drm/i915: Don't store the max cursor width/height in the crtc
Those values are, global, only used in one function and already stored
in mode_config.cursor_{width,height}.
As a result, this initialization code has been moved from the
crtc_init() function to the global modeset_init() one.
I also renamed CURSOR_{WIDTH,HEIGHT} to MAX_CURSOR_{WIDTH,HEIGHT} to be
more accurate about what these value really are.
Cc: Sagar Kamble <sagar.a.kamble@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Imre Deak [Thu, 27 Mar 2014 15:45:11 +0000 (17:45 +0200)]
drm/i915: vlv: get power domain for eDP vdd
Besides D0 device state we need the proper power wells to be on on
some platforms, so get the port power domain reference instead of an RPM
reference.
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Imre Deak [Thu, 27 Mar 2014 15:45:10 +0000 (17:45 +0200)]
drm/i915: vlv: cache current CD clock rate
Instead of reading out the CD clock rate from the HW at each modeset, do
this only during driver init and resume and use the cached value during
modeset. This moves things towards a state where the sw and hw side
setup is separated. It's also needed for VLV RPM, where we don't put
device into D0 state until modeset_global_resources is called and thus
can't access any display/gfx registers.
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Thu, 27 Mar 2014 09:06:14 +0000 (09:06 +0000)]
drm/i915: Add PM interrupt details and RPS thresholds to debugfs
When trying to determine whether RPS is working as intended, more
information is better. In particular, what interrupts are being
generated and the various thresholds for generating them.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Kenneth Graunke [Wed, 26 Mar 2014 05:52:03 +0000 (22:52 -0700)]
drm/i915: Add OACONTROL to the command parser register whitelist.
Mesa needs to be able to write OACONTROL in order to expose the
Observability Architecture's performance counters via OpenGL.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
[danvet: Add comment that this is just a temporary work-around and
that we need to check more things before we can allow OACONTROL writes
for real everywhere.]
[danvet 2: Squash in fixup to avoid a DRM_ERROR due to unsorted reg
list, spotted by Jani.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Brad Volkin [Tue, 18 Feb 2014 18:15:55 +0000 (10:15 -0800)]
drm/i915: Reject commands that would store to global HWS page
PIPE_CONTROL and MI_FLUSH_DW have bits that would write to the
hardware status page. The driver stores request tracking info
there, so don't let userspace overwrite it.
v2: trailing comma fix, rebased
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Brad Volkin [Tue, 18 Feb 2014 18:15:54 +0000 (10:15 -0800)]
drm/i915: Enable PPGTT command parser checks
Various commands that access memory have a bit to determine whether
the graphics address specified in the command should use the GGTT or
PPGTT for translation. These checks ensure that the bit indicates
PPGTT translation.
Most of these checks use the existing bit-checking infrastructure.
The PIPE_CONTROL and MI_FLUSH_DW commands, however, are multi-function
commands. The GGTT/PPGTT bit is only relevant for certain uses of the
command. As such, this change also extends the bit-checking code to
include a "condition" mask and offset. If the condition mask is non-zero
then the parser only performs the bit check when the bits specified by
the condition mask/offset are also non-zero.
NOTE: At this point in the series PPGTT must be enabled for the parser
to work correctly. If it's not enabled, userspace will not be setting
the PPGTT bits the way the parser requires. VLV is the only platform
where this is a problem, so at this point, we disable parsing for VLV.
v2: whitespace and trailing commas fixes, rebased
OTC-Tracker: AXIA-4631
Change-Id: I3f4c76b6734f1956ec47e698230f97d0998ff92b Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Drop the unecessary cast Jani spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Brad Volkin [Tue, 18 Feb 2014 18:15:53 +0000 (10:15 -0800)]
drm/i915: Reject commands that explicitly generate interrupts
The driver leaves most interrupts masked during normal operation,
so there would have to be additional work to enable userspace to
safely request/receive an interrupt.
v2: trailing commas, rebased
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Brad Volkin [Tue, 18 Feb 2014 18:15:52 +0000 (10:15 -0800)]
drm/i915: Enable register whitelist checks
MI_STORE_REGISTER_MEM, MI_LOAD_REGISTER_MEM, and MI_LOAD_REGISTER_IMM
commands allow userspace access to registers. Only certain registers
should be allowed for such access, so enable checking for those commands.
Each ring gets its own register whitelist.
MI_LOAD_REGISTER_REG on HSW also allows register access but is currently
unused by userspace components. Leave it rejected.
PIPE_CONTROL and MEDIA_VFE_STATE allow register access based on certain
bits being set. Reject those as well.
v2: trailing commas, rebased
OTC-Tracker: AXIA-4631
Change-Id: Ie614a2f0eb2e5917de809e5a17957175d24cc44f Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Brad Volkin [Tue, 18 Feb 2014 18:15:48 +0000 (10:15 -0800)]
drm/i915: Reject privileged commands
The spec defines most of these commands as privileged. A few others,
like the semaphore mbox command and some display commands, are also
reserved for the driver's use. Subsequent patches relax some of
these restrictions.
v2: Rebased
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Tue, 25 Mar 2014 01:06:00 +0000 (18:06 -0700)]
drm/i915: Allow full PPGTT with param override
When PPGTT was disabled by default, the patch also prevented the user
from overriding this behavior via module parameter. Being able to test
this on arbitrary kernels is extremely beneficial to track down the
remaining bugs. The patch that prevented this was:
Ben Widawsky [Sun, 23 Mar 2014 05:47:21 +0000 (22:47 -0700)]
drm/i915: Split out GTT specific header file
This file contains all necessary defines, prototypes and typesdefs for
manipulating GEN graphics address translation (this does not include the
legacy AGP driver)
Reiterating the comment in the header,
"Please try to maintain the following order within this file unless it
makes sense to do otherwise. From top to bottom:
1. typedefs
2. #defines, and macros
3. structure definitions
4. function prototypes
Within each section, please try to order by generation in ascending
order, from top to bottom (ie. GEN6 on the top, GEN8 on the bottom)."
I've made some minor cleanups, and fixed a couple of typos while here -
but there should be no functional changes.
The purpose of the patch is to reduce clutter in our main header file,
making room for new growth, and make documentation of our interfaces
easier by splitting things out.
With a little more work, like making i915_gtt a pointer, we could
potentially completely isolate this header from i915_drv.h. At the
moment however, I don't think it's worth the effort.
Personally, I would have liked to put the PTE encoding functions in this
file too, but I didn't want to rock the boat too much.
A similar patch has been in use on my machine for some time. This exact
patch though has only been compile tested.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 18 Mar 2014 09:26:04 +0000 (10:26 +0100)]
drm/i915: make semaphore signaller detection more robust
Extract all this logic into a new helper function
semaphore_wait_to_signaller_ring because:
- The current code has way too much magic.
- The current code doesn't look at bi16, which encodes VECS signallers
on HSW. Those are just added after the fact, so can't be encoded in
a neat formula.
- The current logic can't blow up since it limits its value range
sufficiently, but that's a bit too tricky to rely on in my opinion.
Especially when we start to add bdw support.
- I'm not a big fan of the explicit ring->semaphore_register list, but
I think it's more robust to use the same mapping both when
constructing the semaphore commands and when decoding them.
- Finally add a FIXME comment about lack of broadwell support here,
like in the earlier ipehr semaphore cmd detection function.
Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Actually drop the untrue claim in the commit message Chris
pointed out.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Fri, 14 Mar 2014 23:08:56 +0000 (00:08 +0100)]
drm/i915: Add FIXME for bdw semaphore detection in hancheck
Currently not an issue since we don't emit sempahores, but better
not forget about those.
As a little prep work extract the ipehr decoding for cleaner control
flow. And apply a bit of polish.
Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Fri, 21 Mar 2014 17:18:54 +0000 (17:18 +0000)]
drm/i915: Rename GFX_TLB_INVALIDATE_ALWAYS
The documentation calls this GFX_MODE bit "Flush TLB invalidate Mode".
However, that is not a good name for an enable bit as it doesn't make it
clear what is enabled. An even worse name is GFX_TLB_INVALIDATE_ALWAYS
as enabling that bit actually prevents the TLB from being invalidated at
every flush. This leads to great confusion when reading code and
proposed patches. To get around this try to bake in what is enabled by
setting the bit and call it GFX_TLB_INVALIDATE_EXPLICIT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: "Gupta, Sourab" <sourab.gupta@intel.com> Acked-by: "Gupta, Sourab" <sourab.gupta@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 17:55:13 +0000 (14:55 -0300)]
drm/i915: don't get/put runtime PM at the debugfs forcewake file
Because gen6_gt_force_wake_{get,put} should already be responsible for
getting/putting runtime PM. If we keep these calls, debugfs will not
be testing the get/put calls of the forcewake functions.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 17:55:12 +0000 (14:55 -0300)]
drm/i915: fix WARNs when reading DDI state while suspended
If runtime PM is enabled and we unset all modes, we will runtime
suspend after __intel_set_mode() , then function
intel_modeset_check_state() will try to read the HW state while it is
suspended and trigger lots of WARNs because it shouldn't be reading
registers.
So on this patch we make intel_ddi_connector_get_hw_state() return
false in case the power domain is disabled, and we also make
intel_display_power_enabled() return false in case the device is
suspended. Notice that we can't just use
intel_display_power_enabled_sw() because while the driver is being
initialized the power domain refcounts are not reflecting the real
state of the hardware.
Just for reference, I have previously published an alternate patch for
this problem, called "drm/i915: get runtime PM at intel_set_mode".
Testcase: igt/pm_pc8 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 17:55:11 +0000 (14:55 -0300)]
drm/i915: don't read cursor registers on powered down pipes
At i915_display_info, don't call cursor_position() for a disabled
CRTC, since the CRTC may be on a powered down pipe, and this will
cause "Unclaimed register before interrupt" error messages.
Testcase: igt/pm_pc8/debugfs-read Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Tue, 1 Apr 2014 17:55:07 +0000 (14:55 -0300)]
drm/i915: don't schedule force_wake_timer at gen6_read
So far force_wake_timer was only used by gen6_gt_force_wake_put. Since
we always had balanced gen6_gt_force_wake_get/put calls, we could
guarantee balanced calls to intel_runtime_pm_get/put.
Commit 8232644ccf099548710843e97360a3fcd6d28e04, "drm/i915: Convert
the forcewake worker into a timer func" started scheduling the
force_wake_timer at gen6_read, which resulted in an unbalanced
runtime_pm refcount.
So this commit just reverts to the old behavior until we can find a
proper way to used delayed force_wake from the register read/write
macros without leaving the runtime_pm refcounts unbalanced and without
runtime suspending the driver while forcewake is active.
Testcase: igt/pm_pc8/rte
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76544 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Imre Deak [Mon, 31 Mar 2014 12:10:44 +0000 (15:10 +0300)]
drm/i915: vlv: reserve the GT power context only once during driver init
Atm we reserve/allocate and free the power context during GT power
enable/disable time. There is no need to do this, we can reserve/allocate
the buffer once during driver loading and free it during driver cleanup.
The re-reservation can also fail in case the driver previously manages to
allocate something on the given fixed address.
The buffer isn't exepected to move even if allocated by the BIOS, for
safety add an assert to check this assumption.
This also fixed a bug for Ville, where re-reserving the context failed
during a GPU reset (I assume because something else got allocated on its
fixed address).
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Fri, 28 Mar 2014 08:03:34 +0000 (08:03 +0000)]
drm/i915: Mask PM/RPS interrupt generation based on activity
The speculation is that we can conserve more power by masking off
the interrupts at source (PMINTRMSK) rather than filtering them by the
up/down thresholds (RPINTLIM). We can select which events we know will
be active based on the current frequency versus our imposed range, i.e.
if at minimum, we know we will not want to generate any more
down-interrupts and vice versa.
v2: We only need the TIMEOUT when above min frequency.
v3: Tweak VLV at the same time
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Deepak S <deepak.s@linux.intel.com>
Reviewed-by:Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Thu, 27 Mar 2014 08:24:20 +0000 (08:24 +0000)]
drm/i915: Refactor gen6_set_rps
What used to be a short-circuit now needs to adjust interrupt masking in
response to user requests for changing the min/max allowed frequencies.
This is currently done by a special case and early return, but the next
patch adds another common action to take, so refactor the code to reduce
duplication.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by:Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The partial application of interrupt masking without regard to other
pathways for adjusting the RPS frequency results in completely disabling
the PM interrupts. This leads to excessive power consumption as the GPU
is kept at max clocks (until the failsafe mechanism fires of explicitly
downclocking the GPU when all requests are idle). Or equally as bad for
the UX, the GPU is kept at minimum clocks and prevented from upclocking
in response to a requirement for more power.
Testcase: pm_rps/blocking Cc: Deepak S <deepak.s@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by:Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 28 Mar 2014 21:29:31 +0000 (23:29 +0200)]
drm/i915: Fix the interlace mode selection for gmch platforms
PIPECONF_INTERLACE_W_FIELD_INDICATION is only meant to be used for sdvo
since it implies a slightly weird vsync shift of htotal/2. For everything
else we should use PIPECONF_INTERLACE_W_SYNC_SHIFT and let the value in
the VSYNCSHIFT register take effect.
The only exception is gen3 simply because VSYNCSHIFT didn't exist yet.
Gen2 doesn't support interlaced modes at all, so we can drop the
explicit gen2 checks.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 28 Mar 2014 21:29:30 +0000 (23:29 +0200)]
drm/i915: Program VSYNCSHIFT in a more consistent manner
When interlaced sdvo output is used, vsyncshift should supposedly
be (htotal-1)/2. In reality PIPECONF/TRANSCONF will override it by
using the legacy vsyncshift interlace mode which causes the hardware
to ignore the VSYNCSHIFT register.
The only odd thing here is that on PCH platforms we program the
VSYNCSHIFT on both CPU and PCH, and it's not entirely clear if both
sides have to agree on the value or not. On the CPU side there's no
way to override the value via PIPECONF anymore, so if we want to make
the CPU side agree with the PCH side, we should probably program the
approriate value into VSYNCSHIFT manually. So let's do that, but for
now leave the PCH side to still use the legacy interlace mode in
TRANSCONF.
We can also drop the gen2 check since gen2 doesn't support interlaced
modes at all.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jesse Barnes [Thu, 27 Mar 2014 18:56:08 +0000 (11:56 -0700)]
drm/i915/vlv: use W_SYNC_SHIFT for interlaced modes on VLV
This makes HDMI testers happier on VLV platforms. It may be that we
need it for any non-SVO platform, but I don't have any tests to back
that up, so I'm leaving other pre-ILK platforms alone for now.
Tested-by: "Clint Taylor <clinton.a.taylor@intel.com>" Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74964 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 26 Mar 2014 22:42:53 +0000 (23:42 +0100)]
drm/i915: restrict vt-d stolen memory workaround to pre-gen8
We want future generations to at least attempt to use all features, so
restrict the stolen memory disabling when vt-d is enabled to the
latest generation we have reports for. Which is a HSW per the original
report.
Also once we get a bit a hold of some of the mysterious framebuffer in
stolen memory issues that still haunt bugzilla, we should probably
drop this hack again and see what happens.
drm/i915: Disable stolen memory when DMAR is active
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: David Woodhouse <dwmw2@infradead.org>
References: https://bugs.freedesktop.org/show_bug.cgi?id=68535 Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Linus Torvalds [Mon, 31 Mar 2014 00:26:08 +0000 (17:26 -0700)]
Merge branch 'for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Pull vfs fixes from Al Viro:
"Switch mnt_hash to hlist, turning the races between __lookup_mnt() and
hash modifications into false negatives from __lookup_mnt() (instead
of hangs)"
On the false negatives from __lookup_mnt():
"The *only* thing we care about is not getting stuck in __lookup_mnt().
If it misses an entry because something in front of it just got moved
around, etc, we are fine. We'll notice that mount_lock mismatch and
that'll be it"
* 'for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
switch mnt_hash to hlist
don't bother with propagate_mnt() unless the target is shared
keep shadowed vfsmounts together
resizable namespace.c hashes
Linus Torvalds [Mon, 31 Mar 2014 00:20:40 +0000 (17:20 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input updates from Dmitry Torokhov:
"Some more updates for the input subsystem.
You will get a fix for race in mousedev that has been causing quite a
few oopses lately and a small fixup for force feedback support in
evdev"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: mousedev - fix race when creating mixed device
Input: don't modify the id of ioctl-provided ff effect on upload failure
Eric Paris [Sun, 30 Mar 2014 23:07:54 +0000 (19:07 -0400)]
AUDIT: Allow login in non-init namespaces
It its possible to configure your PAM stack to refuse login if audit
messages (about the login) were unable to be sent. This is common in
many distros and thus normal configuration of many containers. The PAM
modules determine if audit is enabled/disabled in the kernel based on
the return value from sending an audit message on the netlink socket.
If userspace gets back ECONNREFUSED it believes audit is disabled in the
kernel. If it gets any other error else it refuses to let the login
proceed.
Just about ever since the introduction of namespaces the kernel audit
subsystem has returned EPERM if the task sending a message was not in
the init user or pid namespace. So many forms of containers have never
worked if audit was enabled in the kernel.
BUT if the container was not in net_init then the kernel network code
would send ECONNREFUSED (instead of the audit code sending EPERM). Thus
by pure accident/dumb luck/bug if an admin configured the PAM stack to
reject all logins that didn't talk to audit, but then ran the login
untility in the non-init_net namespace, it would work!! Clearly this was
a bug, but it is a bug some people expected.
With the introduction of network namespace support in 3.14-rc1 the two
bugs stopped cancelling each other out. Now, containers in the
non-init_net namespace refused to let users log in (just like PAM was
configfured!) Obviously some people were not happy that what used to let
users log in, now didn't!
This fix is kinda hacky. We return ECONNREFUSED for all non-init
relevant namespaces. That means that not only will the old broken
non-init_net setups continue to work, now the broken non-init_pid or
non-init_user setups will 'work'. They don't really work, since audit
isn't logging things. But it's what most users want.
In 3.15 we should have patches to support not only the non-init_net
(3.14) namespace but also the non-init_pid and non-init_user namespace.
So all will be right in the world. This just opens the doors wide open
on 3.14 and hopefully makes users happy, if not the audit system...
Reported-by: Andre Tomt <andre@tomt.net> Reported-by: Adam Richter <adam_richter2004@yahoo.com> Signed-off-by: Eric Paris <eparis@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Theodore Ts'o [Sun, 30 Mar 2014 14:20:01 +0000 (10:20 -0400)]
ext4: atomically set inode->i_flags in ext4_set_inode_flags()
Use cmpxchg() to atomically set i_flags instead of clearing out the
S_IMMUTABLE, S_APPEND, etc. flags and then setting them from the
EXT4_IMMUTABLE_FL, EXT4_APPEND_FL flags, since this opens up a race
where an immutable file has the immutable flag cleared for a brief
window of time.
Al Viro [Fri, 21 Mar 2014 01:10:51 +0000 (21:10 -0400)]
switch mnt_hash to hlist
fixes RCU bug - walking through hlist is safe in face of element moves,
since it's self-terminating. Cyclic lists are not - if we end up jumping
to another hash chain, we'll loop infinitely without ever hitting the
original list head.
[fix for dumb braino folded]
Spotted by: Max Kellermann <mk@cm4all.com> Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Al Viro [Fri, 21 Mar 2014 14:14:08 +0000 (10:14 -0400)]
don't bother with propagate_mnt() unless the target is shared
If the dest_mnt is not shared, propagate_mnt() does nothing -
there's no mounts to propagate to and thus no copies to create.
Might as well don't bother calling it in that case.
Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Al Viro [Fri, 28 Feb 2014 18:46:44 +0000 (13:46 -0500)]
resizable namespace.c hashes
* switch allocation to alloc_large_system_hash()
* make sizes overridable by boot parameters (mhash_entries=, mphash_entries=)
* switch mountpoint_hashtable from list_head to hlist_head
Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Linus Torvalds [Sat, 29 Mar 2014 22:01:09 +0000 (15:01 -0700)]
Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fix from Ingo Molnar:
"A late breaking fix from John. (The bug fixed has a hard lockup
potential, but that was not observed, warnings were)"
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
time: Revert to calling clock_was_set_delayed() while in irq context
projects / mirror_ubuntu-bionic-kernel.git / log