- 17 Mar, 2015 40 commits
-
-
Daniel Vetter authored
Without this Dave's 32bit rhel compiler is annoyed. Don't ask me about the exact rules for this stuff though, but this should be safe. Reported-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
I have no idea about the exact rules, but this angered Dave's 32bit rhel gcc. Reported-by:
-
Matt Roper authored
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: commit fd2d61341bf39d1054256c07d6eddd624ebc4241 Author: Matt Roper <matthew.d.roper@intel.com> Date: Fri Feb 27 10:12:01 2015 -0800 drm/i915: Use plane->state->fb in watermark code (v2) and commit 0fda6568 Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Date: Fri Feb 27 15:12:35 2015 +0000 drm/i915/skl: Update watermarks for Y tiling 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=89388Signed-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 authored
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. Regression from commit ab8d6675 Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Date: Mon Feb 2 15:44:15 2015 +0000 drm/i915: Track old framebuffer instead of object Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89166 Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by:
-
Vidya Srinivas authored
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)] Signed-off-by:Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by:
Gajanan Bhat <gajanan.bhat@intel.com> Signed-off-by:
Vandana Kannan <vandana.kannan@intel.com> Signed-off-by:
-
Ville Syrjälä authored
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:
-
Rodrigo Vivi authored
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:
-
Vijay Purushothaman authored
This patch implements latest PHY changes in Gain, prop and int co-efficients based on the vco freq. v2: Split the original changes into multiple smaller patches based on review by Ville v3: Addressed Ville's review comments. Fixed the error introduced in v2. Clear the old bits before we modify those bits as part of RMW. v4: TDC target cnt is 10 bits and not 8 bits (Ville) Signed-off-by:
-
Vijay Purushothaman authored
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 authored
v2 : Handle M2 frac division for both M2 frac and int cases v3 : Addressed Ville's review comments. Cleared the old bits for RMW v4 : Fix feedfwd gain (Ville) Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Matt Roper authored
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. Note that commit commit 0fda6568 Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Date: Fri Feb 27 15:12:35 2015 +0000 drm/i915/skl: Update watermarks for Y tiling 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 authored
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: -
Damien Lespiau authored
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:
-
Ville Syrjälä authored
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:
Yogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com> Signed-off-by:
-
Ville Syrjälä authored
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:
-
Jesse Barnes authored
So try to enumerate eDP unconditionally in those cases. Signed-off-by:
-
Damien Lespiau authored
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 authored
We don't use this function on gen9, no need for that test here. Reviewed-by:
-
Damien Lespiau authored
The pipe interrupt registers are in the actual pipe power well, so we need to restore them when re-enable the corresponding power well. I've also copied what we do on HSW/BDW for VGA, even if the we haven't enabled unclaimed registers just yet. v2: Don't run skl_power_well_post_enable() if the power well is already enabled (Paulo) Signed-off-by: -
Damien Lespiau authored
Just to be more consistent with what we do on HSW. Signed-off-by:
-
Damien Lespiau authored
Just like what we do for HSW/BDW, having those variables makes it a bit easier to parse the code. Suggested-by:
-
Damien Lespiau authored
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:
-
Jeff McGee authored
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:
-
Jeff McGee authored
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. v2: Fixed subslice disable bitmasks and removed unnecessary ? operation (Ville) Signed-off-by: -
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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ä authored
Introduce struct vlv_wm_values to house VLV watermark/drain latency values. We start by using it when computing the drain latency values. Reviewed-by:
-
Ville Syrjälä authored
Move the DDL precision handling into vlv_compute_drain_latency() so the callers don't have to duplicate the same code to deal with it. Reviewed-by:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
Kill the silly DRAIN_LATENCY_PRECISION_* defines and just use the raw number instead. v2: Move the sprite 32/16 -> 16/8 preision multiplier change to another patch (Jesse) Reviewed-by: -
Ville Syrjälä authored
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:
-
Chris Wilson authored
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 5978118c 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:
-
kbuild test robot authored
drivers/gpu/drm/i915/intel_ringbuffer.c:435:1-4: WARNING: end returns can be simpified Simplify a trivial if-return sequence. Possibly combine with a preceding function call. Generated by: scripts/coccinelle/misc/simple_return.cocci CC: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Mika Kuoppala authored
commit 05a2fb15 ("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:
-
John Harrison authored
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:
-
Matt Roper authored
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:
-
