Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Damien Lespiau [Thu, 5 Feb 2015 19:35:13 +0000 (19:35 +0000)]
drm/i915: Make sure the primary plane is enabled before reading out the fb state
We don't want to end up in a state where we track that the pipe has its
primary plane enabled when primary plane registers are programmed with
values that look possible but the plane actually disabled.
Refuse to read out the fb state when the primary plane isn't enabled.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reported-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Reported-by: Steven Rostedt <rostedt@goodmis.org>
Reference: http://mid.gmane.org/20150203191507.GA2374@crion86 Tested-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Mika Kuoppala [Fri, 13 Mar 2015 13:21:53 +0000 (15:21 +0200)]
drm/i915: Fix vmap_batch page iterator overrun
vmap_batch() calculates amount of needed pages for the mapping
we are going to create. And it uses this page count as an
argument for the for_each_sg_pages() macro. The macro takes the number
of sg list entities as an argument, not the page count. So we ended
up iterating through all the pages on the mapped object, corrupting
memory past the smaller pages[] array.
Fix this by bailing out when we have enough pages.
Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jeff McGee [Mon, 9 Mar 2015 23:06:54 +0000 (16:06 -0700)]
drm/i915: Export total subslice and EU counts
Setup new I915_GETPARAM ioctl entries for subslice total and
EU total. Userspace drivers need these values when constructing
GPGPU commands. This kernel query method is intended to replace
the PCI ID-based tables that userspace drivers currently maintain.
The kernel driver can employ fuse register reads as needed to
ensure the most accurate determination of GT config attributes.
This first became important with Cherryview in which the config
could differ between devices with the same PCI ID.
The kernel detection of these values is device-specific and not
included in this patch. Because zero is not a valid value for any of
these parameters, a value of zero is interpreted as unknown for the
device. Userspace drivers should continue to maintain ID-based tables
for older devices not supported by the new query method.
v2: Increment our I915_GETPARAM indices to fit after REVISION
which was merged ahead of us.
For: VIZ-4636 Signed-off-by: Jeff McGee <jeff.mcgee@intel.com> Tested-by: Zhigang Gong <zhigang.gong@linux.intel.com> Acked-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 11 Mar 2015 20:52:08 +0000 (22:52 +0200)]
drm/i915: Read CHV_PLL_DW8 from the correct offset
We accidentally pass 'pipe' instead of 'port' to CHV_PLL_DW8() and
with PIPE_C we end up at register offset 0x8320 which isn't the
0x8020 we wanted. Fix it.
The problem was fortunately caught by the sanity check in vlv_dpio_read():
WARNING: CPU: 1 PID: 238 at ../drivers/gpu/drm/i915/intel_sideband.c:200 vlv_dpio_read+0x77/0x80 [i915]()
DPIO read pipe C reg 0x8320 == 0xffffffff
The problem got introduced with this commit:
commit 71af07f91f12bbab96335e202c82525d31680960
Author: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Date: Thu Mar 5 19:33:08 2015 +0530
drm/i915: Update prop, int co-eff and gain threshold for CHV
Cc: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ignore the current state of the pipe and just check crtc_state->enable
and the number of FDI lanes required. This means we don't accidentally
mistake the FDI lanes as being available of one of the pipes just
happens to be disabled at the time of the check. Also we no longer
consider pipe C to require FDI lanes when it's driving the eDP
transcoder.
We also take the opportunity to make the code a bit nicer looking by
hiding the ugly bits in the new pipe_required_fdi_lanes() function.
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 11 Mar 2015 16:52:30 +0000 (18:52 +0200)]
drm/i915: Rewrite some some of the FDI lane checks
The logic in the FDI lane checks is very hard for my poor brain to
grasp. Rewrite it in a more straightforward way.
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Akash Goel [Fri, 6 Mar 2015 05:37:23 +0000 (11:07 +0530)]
drm/i915/skl: Enabling processing of Turbo interrupts
Earlier Turbo interrupts were not being processed for SKL,
as something was amiss in turbo programming for SKL.
Now missing changes have been added, so enabling the Turbo
interrupt processing for SKL.
drm/i915: Simplify the way BC bifurcation state consistency is kept
Remove the global modeset resource function that would disable the
bifurcation bit, and instead enable/disable it when enabling the pch
transcoder. The mode set consistency check should prevent us from
disabling the bit if pipe C is enabled so the change should be safe.
Note that this doens't affect the logic that prevents the bit being
set while a pipe is active, since the patch retains the behavior of
only chaging the bit if necessary. Because of the checks during mode
set, the first change would necessarily happen with both pipes B and
C disabled, and any subsequent write would be skipped.
v2: Only change the bit during pch trancoder enable. (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Akash Goel [Fri, 6 Mar 2015 05:37:20 +0000 (11:07 +0530)]
drm/i915/skl: Updated the gen9_enable_rps function
On SKL, GT frequency is programmed in units of 16.66 MHZ units compared
to 50 MHZ for older platforms. Also the time value specified for Up/Down EI &
Up/Down thresholds are expressed in units of 1.33 us, compared to 1.28
us for older platforms. So updated the gen9_enable_rps function as per that.
v2: Updated to use new macro GT_INTERVAL_FROM_US
v3: Removed the initial setup of certain registers, from gen9_enable_rps,
which gets overridden later from gen6_set_rps (Damien)
v4: Removed the enabling of rps interrupts, from gen9_enable_rps.
To be done from intel_gen6_powersave_work only, as done for other
platforms also.
Akash Goel [Fri, 6 Mar 2015 05:37:18 +0000 (11:07 +0530)]
drm/i915/skl: Restructured the gen6_set_rps_thresholds function
Prior to SKL, the time period programmed in Up/Down EI & Up/Down
threshold registers was in units of 1.28 micro seconds. But for
SKL, the units have changed (1.333 micro seconds).
Have generalized the implementation of gen6_set_rps_thresholds function,
by removing the hard coding done in it as per 1.28 micro seconds.
v2: Renamed the local variables & removed superfluous comments (Chris)
Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Akash Goel [Fri, 6 Mar 2015 05:37:17 +0000 (11:07 +0530)]
drm/i915/skl: Updated the gen6_set_rps function
On SKL, the frequency is programmed differently in RPNSWREQ (A008)
register (from bits 23 to 31, compared to bits 24 to 31). So updated
the gen6_set_rps function, as per this change.
Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Akash Goel [Fri, 6 Mar 2015 05:37:16 +0000 (11:07 +0530)]
drm/i915/skl: Updated the gen6_init_rps_frequencies function
On SKL the frequency is specified in units of 16.66 MHZ, barring the
RP_STATE_CAP(0x5998) register, which still reports frequency in units
of 50 MHZ. So an extra conversion is required in gen6_init_rps_frequencies
function for SKL, to store the frequency values as per the actual hardware unit.
v2: Corrected the conversion from 50 to 16.66 MHZ (Ville)
Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Akash Goel [Fri, 6 Mar 2015 05:37:15 +0000 (11:07 +0530)]
drm/i915/skl: Updated intel_gpu_freq() and intel_freq_opcode()
On SKL, frequency is specified in units of 16.66 MHZ.
Updated the intel_gpu_freq() and intel_freq_opecode() functions
to do the conversion appropriately.
Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Akash Goel [Fri, 6 Mar 2015 05:37:14 +0000 (11:07 +0530)]
drm/i915/skl: Added new macros
For SKL, register definition for RPNSWREQ (A008), RPSTAT1(A01C)
have changed slightly. Also on SKL, frequency is specified in
units of 16.66 MHZ, compared to 50 MHZ for most of the earlier
platforms and the time values are expressed in units of 1.33 us,
compared to 1.28 us for earlier platforms.
Added new macros for the aforementioned changes.
v2: Renamed the GT_FREQ_FROM_PERIOD macro to GT_INTERVAL_FROM_US (Damien)
v3: Removed the implicit use of dev_priv in GT_INTERVAL_FROM_US macro (Chris)
Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jani Nikula [Tue, 3 Feb 2015 12:34:05 +0000 (14:34 +0200)]
drm/i915: remove indirection in the PCI ID macros
Spell all the PCI IDs out to be able to quickly grep for the IDs. No
functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Add GT1/2 to comments to not loose that distinction.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 10 Mar 2015 14:16:28 +0000 (16:16 +0200)]
drm/i915: Add polish to VLV WM shift+mask operations
Wrap the FW register value shift+mask operations into a macro to hide
the ugliness a bit. Also might avoid bugs due to typos.
Also rename all the primary/sprite plane low order bit masks to have the
_VLV suffix, so that we can use the FW_WM_VLV() macro instead of the
FW_WM() macro for them in a consistent manner. Cursor and all the high
order bits are left to use the FW_WM() macro as there's no real
confusion with them.
Cc: Daniel Vetter <daniel@ffwll.ch> 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ä [Tue, 10 Mar 2015 11:15:23 +0000 (13:15 +0200)]
drm/i915: Use plane->state->fb instead of plane->fb in intel_plane_restore()
plane->fb is not as reliable as plane->state->fb so let's convert
intel_plane_restore() over the the new way of thinking as well.
Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 10 Mar 2015 11:15:21 +0000 (13:15 +0200)]
drm/i915: Remove debug prints from primary plane update funcs
These are now called from the plane commit hooks, so they really need to
be fast or else we risk atomic update failures. So kill the debug prints
which are slowing things down massively.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Matt Roper [Mon, 9 Mar 2015 18:06:02 +0000 (11:06 -0700)]
drm/i915: Don't assume primary & cursor are always on for wm calculation (v4)
Current ILK-style watermark code assumes the primary plane and cursor
plane are always enabled. This assumption, along with the combination
of two independent commits that got merged at the same time, results in
a NULL dereference. The offending commits are:
The first commit causes us to use the FB from plane->state->fb rather
than the legacy plane->fb, which is updated a bit later in the process.
The second commit includes a change that now triggers watermark
reprogramming on primary plane enable/disable where we didn't have one
before (which wasn't really correct, but we had been getting lucky
because we always calculated as if the primary plane was on).
Together, these two commits cause the watermark calculation to
(properly) see plane->state->fb = NULL when we're in the process of
disabling the primary plane. However the existing watermark code
assumes there's always a primary fb and tries to dereference it to find
out pixel format / bpp information.
The fix is to make ILK-style watermark calculation actually check the
true status of primary & cursor planes and adjust our watermark logic
accordingly.
v2: Update unchecked uses of state->fb for other platforms (pnv, skl,
etc.). Note that this is just a temporary fix. Ultimately the
useful information is going to be computed at check time and stored
right in the state structures so that we don't have to figure this
all out while we're supposed to be programming the watermarks.
(caught by Tvrtko)
v3: Fix a couple copy/paste mistakes in SKL code. (Tvrtko)
v4: Only add FB checks for ILK/SKL codepaths. Older platforms still use
intel_crtc_active() and will shortcircuit out of watermark
calculations before ever trying to dereference the primary plane's
framebuffer.
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reported-by: Michael Leuchtenburg <michael@slashhome.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89388 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Mon, 16 Feb 2015 14:31:49 +0000 (14:31 +0000)]
drm/i915: Move drm_framebuffer_unreference out of struct_mutex for flips
intel_user_framebuffer_destroy() requires the struct_mutex for its
object bookkeeping, so this means that all calls to
drm_framebuffer_unreference must not hold that lock.
Ville Syrjälä [Thu, 5 Mar 2015 19:19:52 +0000 (21:19 +0200)]
drm/i915: Disable DDR DVFS on CHV
DDR DVFS introduces massive memory latencies which can't be handled by
the PND deadline stuff. Instead the watermarks will need to be
programmed to compensate for the latency and the deadlines will need to
be programmed to tight fixed values. That means DDR DVFS can only be
enabled if the display FIFOs are large enough, and that pretty much
means we have to manually repartition them to suit the needs of the
moment.
That's a lot of change, so in the meantime let's just disable DDR DVFS
to get the display(s) to be stable.
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ä [Thu, 5 Mar 2015 19:19:51 +0000 (21:19 +0200)]
drm/i915: Enable the maxfifo PM5 mode when appropriate on CHV
CHV has a new knob in Punit to select between some memory power savings
modes PM2 and PM5. We can allow the deeper PM5 when maxfifo mode is
enabled, so let's do so in the hopes for moar power savings.
v2: Put the thing into a separate function to avoid churn later
v3: Don't break VLV
Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Vidya Srinivas [Thu, 5 Mar 2015 19:19:50 +0000 (21:19 +0200)]
drm/i915: Program PFI credits for VLV
PFI credit programming is required when CD clock (related to data flow from
display pipeline to end display) is greater than CZ clock (related to data
flow from memory to display plane). This programming should be done when all
planes are OFF to avoid intermittent hangs while accessing memory even from
different Gfx units (not just display).
If cdclk/czclk >=1, PFI credits could be set as any number. To get better
performance, larger PFI credit can be assigned to PND. Otherwise if
cdclk/czclk<1, the default PFI credit of 8 should be set.
v2:
- Change log to lower log level instead of DRM_ERROR
- Change function name to valleyview_program_pfi_credits
- Move program PFI credits to modeset_init instead of intel_set_mode
- Change magic numbers to logical constants
[vsyrjala v3:
- only program in response to cdclk update
- program the credits also when cdclk<czclk
- add CHV bits
v4:
- Change CHV cdclk<czclk credits to 12 (Vijay)]
Ville Syrjälä [Thu, 5 Mar 2015 19:19:49 +0000 (21:19 +0200)]
drm/i915: Rewrite VLV/CHV watermark code
Assuming the PND deadline mechanism works reasonably we should do
memory requests as early as possible so that PND has schedule the
requests more intelligently. Currently we're still calculating
the watermarks as if VLV/CHV are identical to g4x, which isn't
the case.
The current code also seems to calculate insufficient watermarks
and hence we're seeing some underruns, especially on high resolution
displays.
To fix it just rip out the current code and replace is with something
that tries to utilize PND as efficiently as possible.
We now calculate the WM watermark to trigger when the FIFO still has
256us worth of data. 256us is the maximum deadline value supoorted by
PND, so issuing memory requests earlier would mean we probably couldn't
utilize the full FIFO as PND would attempt to return the data at
least in at least 256us. We also clamp the watermark to at least 8
cachelines as that's the magic watermark that enabling trickle feed
would also impose. I'm assuming it matches some burst size.
In theory we could just enable trickle feed and ignore the WM values,
except trickle feed doesn't work with max fifo mode anyway, so we'd
still need to calculate the SR watermarks. It seems cleaner to just
disable trickle feed and calculate all watermarks the same way. Also
trickle feed wouldn't account for the 256us max deadline value, thoguh
that may be a moot point in non-max fifo mode sicne the FIFOs are fairly
small.
On VLV max fifo mode can be used with either primary or sprite planes.
So the code now also checks all the planes (apart from the cursor)
when calculating the SR plane watermark.
We don't have to worry about the WM1 watermarks since we're using the
PND deadline scheme which means the hardware ignores WM1 values.
v2: Use plane->state->fb instead of plane->fb
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>
Rodrigo Vivi [Tue, 10 Mar 2015 00:57:07 +0000 (17:57 -0700)]
drm/i915: Make sure we invalidate frontbuffer on fbcon.
There are some cases like suspend/resume or dpms off/on sequences
that can flush frontbuffer bits. In these cases features that relies
on frontbuffer tracking can start working and user can stop getting
screen updates on fbcon having impression the system is frozen.
So, let's make sure we also invalidate frontbuffer on fbdev blank.
v2: Daniel was right, backtrace didn't show other path than this blank
one so let's make sure frontbuffer bits gets invalidate here instead of
on random write operations that doesn't garantee we track all frontbuffer
writes.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[danvet: Exchange code comments for one that complains about the
locking, like in set_par.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Initialize CHV digital lock detect threshold
Initialize lock detect threshold and select coarse threshold for the
case where M2 fraction division is disabled.
v2: Split the changes into multiple smaller patches (Ville)
v3: Clear out the old bits before we modify those bits as RMW (Ville)
v4: Reset coarse threshold when M2 fraction is enabled (Ville)
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Matt Roper [Mon, 9 Mar 2015 17:19:24 +0000 (10:19 -0700)]
drm/i915: Use crtc->state->active in ilk/skl watermark calculations (v3)
Existing watermark code calls intel_crtc_active() to determine whether a CRTC
is active for the purpose of watermark calculations (and bails out early if it
determines the CRTC is not active). However intel_crtc_active() only returns
true if crtc->primary->fb is non-NULL, which isn't appropriate in the modern
age of universal planes and atomic modeset since userspace can now disable the
primary plane, but leave the CRTC (and other planes) running.
adds a test for primary plane enable/disable to trigger a watermark update
(previously we ignored updates to primary planes, which wasn't really correct,
but we got lucky since we always pretended the primary plane was on). Tvrtko's
patch tries to update watermarks when we re-enable the primary plane, but that
watermark computation gets aborted early because intel_crtc_active() returns
false due to the disabled primary plane.
Switch the ILK and SKL watermark code over to use crtc->state->active rather
than calling intel_crtc_active() so that we'll properly compute watermarks when
re-enabling the primary plane.
Note that this commit doesn't touch callsites in the watermark code for
older platforms since there were concerns that doing so would lead to
other types of breakage.
Also note that all of the watermark calculation at the moment takes place after
new crtc/plane states are swapped into the DRM objects. This will change in
the future, so we'll be working with in-flight state objects, but for the time
being, crtc->state is what we want to operate on.
v2: Don't drop primary->fb check from intel_crtc_active(), but rather replace
ILK/SKL callsites with direct tests of crtc->state->active. There is
concern that messing with intel_crtc_active() will lead to other breakage for
old hardware platforms. (Ville)
v3: Use intel_crtc->active for now rather than crtc->state->active since
we don't have CRTC states properly hooked up and initialized yet.
We'll defer the switch to crtc->state->active until the atomic CRTC
state work is farther along. (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Matt Roper [Mon, 9 Mar 2015 17:19:23 +0000 (10:19 -0700)]
drm/i915: Update intel_crtc_active() to use state values (v2)
With the switch to atomic plumbing for planes, some of our commit-time
work (e.g., watermarks) is done after the new atomic state is swapped
into the relevant DRM object, but before the DRM core has a chance to
update its legacy state values. Switch intel_crtc_active() to look at
the state objects rather than legacy fields to ensure we operate on the
proper values.
Note that we're continuing to use intel_crtc->active here for the time
being since crtc->state isn't really hooked up yet. Once CRTC states
are wired up properly, we'll want to switch this over to use
crtc->state->active instead.
v2: Switch back to intel_crtc->active for now; when Ander's work on CRTC
states is ready, we can flip this over to use crtc->state->active
instead. (Ville)
Cc: Ander Conselvan De Oliveira <conselvan2@gmail.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Damien Lespiau [Mon, 9 Mar 2015 14:17:58 +0000 (14:17 +0000)]
drm/i915: Exit early from psr_status if PSR is not supported by the device
Static analysis was complaining that a path existed where we could use
stat[] uninitialized. Fix this by simplifying the logic to exit early if
PSR isn't supported.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Mon, 2 Mar 2015 18:07:17 +0000 (20:07 +0200)]
drm/i915: Fix chv cdclk support
The specs seem to be full of misinformation wrt. the Punit register
0x36. Some versions still show the old VLV bit layout, some the new
layout, and all of them seem to tell us nonsense about the cdclk
value encoding.
Testing on actual hardware has shown that we simply need to program
the desired CCK divider into the Punit register using the new layout of
the bits. Doing that, the status bit change to indicate the same value,
and the CCK 0x6b register also changes accordingly to indicate that CCK
is now using the new divider.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com> Reviewed-by: Yogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Mon, 2 Mar 2015 18:07:16 +0000 (20:07 +0200)]
drm/i915: Allow pixel clock up to 95% of cdclk on CHV
Supposedly CHV can sustain a pixel clock of up to 95% of
cdclk, as opposed to the 90% limit that was used old older
platforms. Update the cdclk selection code to allow for this.
This will allow eg. HDMI 4k modes with their 297MHz pixel clock
while still respecting the 320 MHz cdclk limit on CHV.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com> Reviewed-by: Yogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Damien Lespiau [Fri, 6 Mar 2015 18:50:53 +0000 (18:50 +0000)]
drm/i915/skl: Restore the DDI translation tables when enabling PW1
I was dumping the DDI translation tables to make sure my patch updating
the HDMI entry was doing the right thing when I noticed that the table
was showing reset values after DPMS.
And indeed, the DDI translation registers are in power well 1 on SKL,
and so we're losing their values when shutting down eDP.
Calling intel_prepare_ddi() on PW1 enabling re-programs the table.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Damien Lespiau [Fri, 6 Mar 2015 18:50:48 +0000 (18:50 +0000)]
drm/i915/skl: Make gen8_irq_power_well_post_enable() take a pipe mask
While we only need to restore pipe B/C interrupt registers on BDW when
enabling the power well, skylake a bit more flexible and we'll also need
to restore the pipe A registers as it has its own power well that can be
toggled.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jeff McGee [Fri, 27 Feb 2015 18:22:32 +0000 (10:22 -0800)]
drm/i915/chv: Add CHV HW status to SSEU status
Collect the currently enabled counts of slice, subslice, and
execution units using the power gate control ack message
registers specific to Cherryview.
Slice/subslice/EU info and hardware status can now be
determined for CHV, so allow the debugfs SSEU status dump
to proceed for CHV devices.
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jeff McGee [Fri, 27 Feb 2015 20:12:28 +0000 (12:12 -0800)]
drm/i915/chv: Determine CHV slice/subslice/EU info
Total EU was already being detected on CHV, so we just add the
additional info parameters. The detection method is changed to
be more robust in the case of subslice fusing - we don't want
to trust the EU fuse bits corresponding to subslices which are
fused-off.
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 5 Mar 2015 19:19:48 +0000 (21:19 +0200)]
drm/i915: Make sure PND deadline mode is enabled on VLV/CHV
Poke at the CBR1_VLV register during init_clock_gating to make sure the
PND deadline scheme is used.
The hardware has two modes of operation wrt. watermarks:
1) PND deadline mode:
- memory request deadline is calculated from actual FIFO level * DDL
- WM1 watermark values are unused (AFAIK)
- WM watermark level defines when to start fetching data from memory
(assuming trickle feed is not used)
2) backup mode
- deadline is based on FIFO status, DDL is unused
- FIFO split into three regions with WM and WM1 watermarks, each
part specifying a different FIFO status
We want to use the PND deadline mode, so let's make sure the chicken
bit is in the correct position on init.
Also take the opportunity to refactor the shared code between VLV and
CHV to a shared function.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 5 Mar 2015 19:19:47 +0000 (21:19 +0200)]
drm/i915: Read out display FIFO size on VLV/CHV
VLV/CHV have similar DSPARB registers as older platforms, just more of
them due to more planes. Add a bit of code to read out the current FIFO
split from the registers. Will be useful later when we improve the WM
calculations.
v2: Add display_mmio_offset to DSPARB
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 5 Mar 2015 19:19:46 +0000 (21:19 +0200)]
drm/i915: Pass plane to vlv_compute_drain_latency()
Now that we have drm_planes for the cursor and primary we can move the
pixel_size handling into vlv_compute_drain_latency() and just pass the
appropriate plane to it.
v2: Check plane->state->fb instead of plane->fb
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Resolve conflict with Matt's s/plane->fb/plane->state->fb/
patch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 5 Mar 2015 19:19:43 +0000 (21:19 +0200)]
drm/i915: Simplify VLV drain latency computation
The current drain lantency computation relies on hardcoded limits to
determine when the to use the low vs. high precision multiplier.
Rewrite the code to use a more straightforward approach.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 5 Mar 2015 19:19:41 +0000 (21:19 +0200)]
drm/i915: Reduce CHV DDL multiplier to 16/8
Apparently we must yet halve the DDL drain latency from what we're
using currently. This little nugget is not in any spec, but came
down through the grapevine.
This makes the displays a bit more stable. Not quite fully stable but at
least they don't fall over immediately on driver load.
v2: Update high_precision in valleyview_update_sprite_wm() too (Jesse)
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Thu, 18 Dec 2014 10:55:50 +0000 (10:55 +0000)]
drm/i915: Disable the mmio.debug WARN after it fires
If we have a single unclaimed register, we will have lots. A WARN for
each one makes the machine unusable and does not aid debugging. Convert
the i915.mmio_debug option to a counter for how many WARNs to fire
before shutting up. Even when i915.mmio_debug was disabled it would
continue to shout an *ERROR* for every interrupt, without any
information at all for debugging.
The massive verbiage was added in
commit 5978118c39c2f72fd8b39ef9c086723542384809
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Wed Jul 16 17:49:29 2014 -0300
drm/i915: reorganize the unclaimed register detection code
v2: Automatically enable invalid mmio reporting for the *next* invalid
access if mmio_debug is disabled by default. This should give us clearer
debug information without polluting the logs too much.
v3: Compile fixes, rebase.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Update modparam text per the thread.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Fri, 27 Feb 2015 16:11:09 +0000 (18:11 +0200)]
drm/i915: Do both mt and gen6 style forcewake reset on ivb probe
commit 05a2fb157e44 ("drm/i915: Consolidate forcewake code")
failed to take into account that we have used to reset both
the gen6 style and the multithreaded style forcewake registers.
This is due to fact that ivb can use either, depending on how the
bios has set up the machine.
Mimic the old semantics before we have determined the correct variety
and reset both before the ecobus probe.
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Huang Ying <ying.huang@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
John Harrison [Thu, 5 Mar 2015 14:03:03 +0000 (14:03 +0000)]
drm/i915: Remove ironlake rc6 support
Apparently, this has never worked reliably and is currently disabled. Also, the
gains are not particularly impressive. Thus rather than try to keep unused code
from decaying and having to update it for other driver changes, it was decided
to simply remove it.
For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Matt Roper [Wed, 4 Mar 2015 18:49:04 +0000 (10:49 -0800)]
drm/i915: Don't clobber plane state on internal disables
We need to disable all sprite planes when disabling the CRTC. We had
been using the top-level atomic 'disable' entrypoint to accomplish this,
which was wrong. Not only can this lead to various locking issues, it
also modifies the actual plane state, making it impossible to restore
the plane properly later. For example, a DPMS off followed by a DPMS on
will result in any sprite planes in use not being restored properly.
The proper solution here is to call directly into our 'commit plane'
hook with a copy of the plane's current state that has 'visible' set to
false. Committing this dummy state will turn off the plane, but will
not touch the actual plane->state pointer, allowing us to properly
restore the plane state later.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Wed, 4 Mar 2015 12:55:17 +0000 (14:55 +0200)]
drm/i915: Setup all page directories for gen8
If the requested size is less than what the full range
of pdps can address, we end up setting pdps for only the
requested area.
The logical context however needs all pdp entries to be valid.
Prior to commit 06fda602dbca ("drm/i915: Create page table allocators")
we have been writing pdp entries with dma address of zero instead
of valid pdps. This is supposedly bad even if those pdps are not
addressed.
As commit 06fda602dbca ("drm/i915: Create page table allocators")
introduced more dynamic structure for pdps, we ended up oopsing
when we populated the lrc context. Analyzing this oops revealed
the fact that we have not been writing valid pdps with bsw, as
it is doing the ppgtt init with 2GB limit in some cases.
We should do the right thing and setup the non addressable part
pdps/pde/pte to scratch page through the minimal structure by
having just pdp with pde entries pointing to same page with
pte entries pointing to scratch page.
But instead of going through that trouble, setup all the pdps
through individual pd pages and pt entries, even for non
addressable parts. And let the clear range point them to scratch
page. This way we populate the lrc with valid pdps and wait
for dynamic page allocation work to land, and do the heavy lifting
for truncating page table tree according to usage.
The regression of oopsing in init was introduced by
commit 06fda602dbca ("drm/i915: Create page table allocators")
v2: Clear the range for the unused part also (Ville)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89350 Cc: Michel Thierry <michel.thierry@intel.com> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Valtteri Rantala <valtteri.rantala@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Sonika Jindal [Thu, 5 Mar 2015 04:32:30 +0000 (10:02 +0530)]
drm/i915/skl: Add support for edp 1.4 intermediate frequencies
eDp 1.4 supports custom frequencies.
Skylake supports following intermediate frequencies : 3.24 GHz, 2.16 GHz and
4.32 GHz along with usual LBR, HBR and HBR2 frequencies.
Read sink supported frequencies and get common frequencies from sink and
source and use these for link training.
v2: Rebased, removed calculation of min_clock since for edp it is taken as
max_clock (as per comment).
v3: Keeping single array for link rates (Satheesh)
v4: Setting LINK_BW_SET to 0 when setting LINK_RATE_SET (Satheesh)
v5: Some minor nits (Ville)
v6: Keeping separate arrays for source and sink rates (Ville)
v7: Remove redundant setting of DP_LINK_BW_SET to 0 (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Sonika Jindal [Thu, 5 Mar 2015 04:33:58 +0000 (10:03 +0530)]
drm/i915/skl: Read sink supported rates from edp panel
v2: Using DP_SUPPORTED_LINK_RATES macro for supported_rates array (Satheesh).
v3: Reading dpcd's supported link rates tables based upon edp version in the
same patch.
v4: Move version check under is_edp (Satheesh)
v5: Using le16 for rates, some naming, and removing nested if block (Ville)
v6: Correctly using DP_MAX_SUPPORTED_RATES and removing DP_SUPPORTED_LINK_RATES
(Ville)
v7: Incorrectly removed DP_SUPPORTED_LINK_RATES in v6, re-adding it
v8: Checking return value of intel_dp_dpcd_read_wake() (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Fri, 13 Feb 2015 19:23:46 +0000 (17:23 -0200)]
drm/i915: add frontbuffer tracking to FBC
Kill the blt/render tracking we currently have and use the frontbuffer
tracking infrastructure.
Don't enable things by default yet.
v2: (Rodrigo) Fix small conflict on rebase and typo at subject.
v3: (Paulo) Rebase on RENDER_CS change.
v4: (Paulo) Rebase.
v5: (Paulo) Simplify: flushes don't have origin (Daniel).
Also rebase due to patch order changes.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ramalingam C [Tue, 3 Mar 2015 06:41:46 +0000 (12:11 +0530)]
drm/i915: Fixing mutex deadlock window at eDP DRRS
In invalidate and flush functions of eDP DRRS, if deferred downclock
work starts execution at a time window between acquiring the drrs
mutex and cancellation of the deferred work
(intel_edp_drrs_downclock_work), then deferred work will find
drrs mutex locked and wait for the same.
Meanwhile the function that acquired mutex drrs invalidate/flush will
wait for the completion of the deferred work before releasing the mutex.
Thats a deadlock.
To avoid such deadlock scenario, this change cancels the deferred work
before acquiring the mutex at invalidate and flush functions.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Vandana Kannan [Tue, 3 Mar 2015 15:23:10 +0000 (20:53 +0530)]
drm/i915: Add debugfs entry for DRRS
Adding a debugfs entry to determine if DRRS is supported or not
V2: [By Ram]: Following details about the active crtc will be filled
in seq-file of the debugfs
1. Encoder output type
2. DRRS Support on this CRTC
3. DRRS current state
4. Current Vrefresh
Format is as follows:
CRTC 1: Output: eDP, DRRS Supported: Yes (Seamless), DRRS_State: DRRS_HIGH_RR, Vrefresh: 60
CRTC 2: Output: HDMI, DRRS Supported : No, VBT DRRS_type: Seamless
CRTC 1: Output: eDP, DRRS Supported: Yes (Seamless), DRRS_State: DRRS_LOW_RR, Vrefresh: 40
CRTC 2: Output: HDMI, DRRS Supported : No, VBT DRRS_type: Seamless
V3: [By Ram]: Readability is improved.
Another error case is covered [Daniel]
V4: [By Ram]: Current status of the Idleness DRRS along with
the Front buffer bits are added to the debugfs. [Rodrigo]
V5: [By Ram]: Rephrased to make it easy to understand.
And format is modified. [Rodrigo]
V6: [By Ram]: Modeset mutex are acquired for each crtc along with
renaming the Idleness detection states [Daniel]
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[danvet: dump full busy_frontbuffer_bits and remove the dubios
computed logical state of DRRS - debugfs is about what is fact,
developers should reach their own conclusion when debugging issues.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Neil Roberts [Wed, 4 Mar 2015 14:41:16 +0000 (14:41 +0000)]
drm/i915: Add I915_PARAM_REVISION
Adds a parameter which can be used with DRM_I915_GETPARAM to query the
GPU revision. The intention is to use this in Mesa to implement the
WaDisableSIMD16On3SrcInstr workaround on Skylake but only for
revision 2.
Signed-off-by: Neil Roberts <neil@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When logging that full mode switch is necessary, log which connector,
encoder or crtc has caused it, so it is easier to figure out what is
goind on by just looking at the log.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 26 Feb 2015 19:01:52 +0000 (21:01 +0200)]
drm/i915: Reduce CHV DPLL min vco frequency to 4.8 GHz
The current minimum vco frequency leaves us with a gap in our supported
frequencies at 233-243 MHz. Your typical 2560x1440@60 display wants a
pixel clock of 241.5 MHz, which is just withing that gap. Reduce the
allowed vco min frequency to 4.8GHz to reduce the gap to 233-240 MHz,
and thus allow such displays to work.
4.8 GHz is actually the documented (at least in some docs) limit of the
PLL, and we just picked 4.86 GHz originally because that was the lowest
value produced by the PLL spreadsheet, which obviously didn't consider
2560x1440 displays.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Fri, 13 Feb 2015 19:23:44 +0000 (17:23 -0200)]
drm/i915: pass which operation triggered the frontbuffer tracking
We want to port FBC to the frontbuffer tracking infrastructure, but
for that we need to know what caused the object invalidation so
we can react accordingly: CPU mmaps need manual, GTT mmaps and
flips don't need handling and ring rendering needs nukes.
v2: - s/ORIGIN_RENDER/ORIGIN_CS/ (Daniel, Rodrigo)
- Fix copy/pasted wrong documentation
- Rebase
v3: - Rebase
v4: - Don't pass the operation to flushes (Daniel).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We've been a bit too optimistic with this one here :(
The trouble is that internally we're still using these plane
update/disable hooks. Which was totally ok pre-atomic since the drm
core did all the book-keeping updating and these just mostly updated
hw state. But with atomic there's lots more going on, and it causes
heaps of trouble with the load detect code.
This one specifically cause a deadlock since both the load detect code
and the nested plane atomic helper functions tried to grab the same
locks. It only blows up because of the evil tricks though we play with
the implicit ww acquire context.
Applying this revert unearths the NULL deref on already freed
framebuffer objects reported as a regression in 4.0 by various people.
Fixing this will be fairly invasive, hence revert even for the
4.1-next queue.
Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul Bolle <pebolle@tiscali.nl> Acked-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Damien Lespiau [Mon, 2 Mar 2015 16:19:36 +0000 (16:19 +0000)]
drm/i915/skl: Only use the 800mV+2bB HDMI translation entry
This translation entry was updated after electrical validation by the hw
team. The other entries are removed from existence as they aren't
validated and because the sole use of a certain type of level shifter
for SKL products is anticipated.
v2: Remove all the other entries and force the use of the 800mv+2dB
config (Sonika)
Damien Lespiau [Sat, 28 Feb 2015 14:54:09 +0000 (14:54 +0000)]
drm/i915: Make for_each_sprite() take dev_priv as argument
Implicit usage of local variables in macros isn't exactly the greatest
thing in the world, especially when that variable is the drm device and
we want to move towards a broader use of the i915 device structure.
Let's make for_each_sprite() take dev_priv as its first argument then.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Damien Lespiau [Sat, 28 Feb 2015 14:54:08 +0000 (14:54 +0000)]
drm/i915: Make for_each_plane() take dev_priv as argument
Implicit usage of local variables in macros isn't exactly the greatest
thing in the world, especially when that variable is the drm device and
we want to move towards a broader use of the i915 device structure.
Let's make for_each_plane() take dev_priv as its first argument then.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 23 Feb 2015 11:03:28 +0000 (12:03 +0100)]
drm/i915: Remove irq-related FIXME in reset code
With the two-step reset counter increments which braket the actual
reset code and the subsequent wake-up we're guaranteeing that all the
lockless waiters _will_ be woken up. And since we unconditionally bail
out of waits with -EAGAIN (or -EIO) in that case there is not risk of
lost interrupt enabling bits when the lockless wait code races against
a gpu reset.
Let's remove this FIXME as resolved then.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Matt Roper [Fri, 27 Feb 2015 18:12:01 +0000 (10:12 -0800)]
drm/i915: Use plane->state->fb in watermark code (v2)
plane->fb is a legacy pointer that not always be up-to-date (or updated
early enough). Make sure the watermark code uses plane->state->fb so
that we're always doing our calculations based on the correct
framebuffers.
This patch was generated by Coccinelle with the following semantic
patch:
@@
struct drm_plane *P;
@@
- P->fb
+ P->state->fb
v2: Rebase
Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The cursor size fields in intel_crtc just duplicate the data from
cursor->state.crtc_{w,h} so we don't need them any more. Worse, their
use in the watermark code actually introduces a subtle bug since they
don't get updated to mirror the state values until the plane commit
stage, which is *after* we've already used them to calculate new
watermark values. This happens because we had to move watermark updates
slightly earlier (outside vblank evasion) in commit
drm/i915: Refactor work that can sleep out of commit (v7)
Dropping the intel_crtc fields and just using the state values (which
are properly updated by the time watermark updates happen) should solve
the problem.
Aside from the actual removal of the struct fields (which are formatted
in a way that I couldn't figure out how to match in Coccinelle), the
rest of this patch was generated via the following semantic patch:
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Joe Konno <joe.konno@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89346 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Xi Ruoyao [Thu, 12 Mar 2015 12:16:32 +0000 (20:16 +0800)]
drm/i915: Ensure plane->state->fb stays in sync with plane->fb
plane->state->fb and plane->fb should always reference the same FB so
that atomic and legacy codepaths have the same view of display state.
However, there are some places in kernel code that directly set
plane->fb and neglect to update plane->state->fb. If we never do a
successful update through the atomic pipeline, the RmFB cleanup code
will look at the plane->state->fb pointer, which has never actually
been set to a legitimate value, and try to clean it up, leading to
BUG's.
Add a quick helper function to synchronize plane->state->fb with
plane->fb and call it everywhere the driver tries to manually set
plane->fb outside of the atomic pipeline. In this function, use
drm_atomic_set_fb_for_plane instead of writing plane->state->fb
directly to keep the reference count right.
This is modified from Matt Roper's patch to drm-intel-nightly with
commit id
drm/i915: Ensure plane->state->fb stays in sync with plane->fb
However this bug exists in mainline kernel too, so I created this to fix
it in mainline kernel.
A minor change is to use drm_atomic_set_fb_for_plane instead of update
reference count manually.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88909
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93711 Signed-off-by: Xi Ruoyao <xry111@outlook.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
[Jani: included the patch notes in the commit message] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Linus Torvalds [Sun, 15 Mar 2015 22:07:08 +0000 (15:07 -0700)]
Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clock framework fixes from Michael Turquette:
"The clk fixes for 4.0-rc4 comprise three themes.
First are the usual driver fixes for new regressions since v3.19.
Second are fixes to the common clock divider type caused by recent
changes to how we round clock rates. This affects many clock drivers
that use this common code.
Finally there are fixes for drivers that improperly compared struct
clk pointers (drivers must not deref these pointers). While some of
these drivers have done this for a long time, this did not cause a
problem until we started generating unique struct clk pointers for
every consumer. A new function, clk_is_match was introduced to get
these drivers working again and they are fixed up to no longer deref
the pointers themselves"
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
ASoC: kirkwood: fix struct clk pointer comparing
ASoC: fsl_spdif: fix struct clk pointer comparing
ARM: imx: fix struct clk pointer comparing
clk: introduce clk_is_match
clk: don't export static symbol
clk: divider: fix calculation of initial best divider when rounding to closest
clk: divider: fix selection of divider when rounding to closest
clk: divider: fix calculation of maximal parent rate for a given divider
clk: divider: return real rate instead of divider value
clk: qcom: fix platform_no_drv_owner.cocci warnings
clk: qcom: fix platform_no_drv_owner.cocci warnings
clk: qcom: Add PLL4 vote clock
clk: qcom: lcc-msm8960: Fix PLL rate detection
clk: qcom: Fix slimbus n and m val offsets
clk: ti: Fix FAPLL parent enable bit handling
Krzysztof Kolasa [Sun, 15 Mar 2015 19:22:36 +0000 (20:22 +0100)]
[PATCH] drm/mm: Fix support 4 GiB and larger ranges
bad argument if(tmp)... in check_free_hole
fix oops: kernel BUG at drivers/gpu/drm/drm_mm.c:305!
[airlied: excellent, this was my task for today].
Signed-off-by: Krzysztof Kolasa <kkolasa@winsoft.pl> Reviewed-by: Chris wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
Linus Torvalds [Sun, 15 Mar 2015 17:49:38 +0000 (10:49 -0700)]
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Arnd Bergmann:
"This is a rather unpleasantly large set of bug fixes for arm-soc, Most
of them because of cross-tree dependencies for Exynos where we should
have figured out the right path to merge things before the merge
window, and then the maintainer being unable to sort things out in
time during a business trip.
The other changes contained here are the usual collection:
MAINTAINERS file updates
- Gregory Clement is now a co-maintainer for the legacy Marvell EBU
platforms
- A MAINTAINERS entry for the Freescale Vybrid platform that was
added last year
- Matt Porter no longer works as a maintainer on Broadcom SoCs
Build-time issues
- A compile-time error for at91
- Several minor DT fixes on at91, imx, exynos, socfpga, and omap
- The new digicolor platform was not correctly enabled at all
Configuration issues
- Two defconfig fix for regressions using USB on versatile express
and on OMAP3
- Enabling all 8 CPUs on Allwinner/SUNxi
- Enabling the new STiH410 platform to be usable
Bug fixes in platform code
- A missing barrier for socfpga
- Fixing LPDDR1 self-refresh mode on at91
- Fixing RTC interrupt numbers on Exynos3250
- Fixing a cache-coherency issues in CPU power-down on Exynos5
- Multiple small OMAP power management fixes"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (69 commits)
MAINTAINERS: Add myself as co-maintainer to the legacy support of the mvebu SoCs
ARM: at91: pm_slowclock: fix the compilation error
ARM: at91/dt: fix USB high-speed clock to select UTMI
ARM: at91/dt: fix at91 udc compatible strings
ARM: at91/dt: declare matrix node as a syscon device
ARM: vexpress: update CONFIG_USB_ISP1760 option
ARM: digicolor: add the machine directory to Makefile
ARM: STi: Add STiH410 SoC support
MAINTAINERS: add Freescale Vybrid SoC
MAINTAINERS: Remove self as ARM mach-bcm co-maintainer
ARM: imx6sl-evk: set swbst_reg as vbus's parent reg
ARM: imx6qdl-sabresd: set swbst_reg as vbus's parent reg
ARM: at91/dt: at91sam9261: fix clocks and clock-names in udc definition
ARM: OMAP2+: Fix wl12xx on dm3730-evm with mainline u-boot
ARM: OMAP: enable TWL4030_USB in omap2plus_defconfig
ARM: dts: dra7x-evm: avoid possible contention while muxing on CAN lines
ARM: dts: dra7x-evm: Don't use dcan1_rx.gpio1_15 in DCAN pinctrl
ARM: dts: am43xx: fix SLEWCTRL_FAST pinctrl binding
ARM: dts: am33xx: fix SLEWCTRL_FAST pinctrl binding
ARM: dts: OMAP5: fix polling intervals for thermal zones
...
Linus Torvalds [Sun, 15 Mar 2015 17:41:30 +0000 (10:41 -0700)]
Merge tag 'irqchip-fixes-4.0' of git://git.infradead.org/users/jcooper/linux
Pull irqchip fixes from Jason Cooper:
"armada-370-xp:
- Chained per-cpu interrupts
gic{,-v3,v3-its}"
- Various fixes for safer operation"
* tag 'irqchip-fixes-4.0' of git://git.infradead.org/users/jcooper/linux:
irqchip: gicv3-its: Support safe initialization
irqchip: gicv3-its: Define macros for GITS_CTLR fields
irqchip: gicv3-its: Add limitation to page order
irqchip: gicv3-its: Use 64KB page as default granule
irqchip: gicv3-its: Zero itt before handling to hardware
irqchip: gic-v3: Fix out of bounds access to cpu_logical_map
irqchip: gic: Fix unsafe locking reported by lockdep
irqchip: gicv3-its: Fix unsafe locking reported by lockdep
irqchip: gicv3-its: Iterate over PCI aliases to generate ITS configuration
irqchip: gicv3-its: Allocate enough memory for the full range of DeviceID
irqchip: gicv3-its: Fix ITS CPU init
irqchip: armada-370-xp: Fix chained per-cpu interrupts
projects / linux-beck.git / log