- 13 May, 2016 23 commits
-
-
Matt Roper authored
In an upcoming patch we'll move this calculation to the atomic 'check' phase so that the display update can be rejected early if no valid watermark programming is possible. v2: - Drop intel_pstate_for_cstate_plane() helper and add note about how the code needs to evolve in the future if we start allowing more than one pending commit against a CRTC. (Maarten) v3: - Only have skl_compute_wm_level calculate watermarks for enabled planes; we can just set the other planes on a CRTC to disabled without having to look at the plane state. This is important because despite our CRTC lock we can still have racing commits that modify a disabled plane's property without turning it on. (Maarten) Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463061971-19638-13-git-send-email-matthew.d.roper@intel.com
-
Matt Roper authored
In a future patch we'll want to calculate plane watermarks for in-flight atomic state rather than the already-committed state. Signed-off-by:
-
Matt Roper authored
Now that we're properly pre-allocating the DDB during the atomic check phase and we trust that the allocation is appropriate, let's actually use the allocation computed and not duplicate that work during the commit phase. v2: - Significant rebasing now that we can use cached data rates and minimum block allocations to avoid grabbing additional plane states. Signed-off-by:
-
Matt Roper authored
Calculate the DDB blocks needed to satisfy the current atomic transaction at atomic check time. This is a prerequisite to calculating SKL watermarks during the 'check' phase and rejecting any configurations that we can't find valid watermarks for. Due to the nature of DDB allocation, it's possible for the addition of a new CRTC to make the watermark configuration already in use on another, unchanged CRTC become invalid. A change in which CRTC's are active triggers a recompute of the entire DDB, which unfortunately means we need to disallow any other atomic commits from racing with such an update. If the active CRTC's change, we need to grab the lock on all CRTC's and run all CRTC's through their 'check' handler to recompute and re-check their per-CRTC DDB allocations. Note that with this patch we only compute the DDB allocation but we don't actually use the computed values during watermark programming yet. For ease of review/testing/bisecting, we still recompute the DDB at watermark programming time and just WARN() if it doesn't match the precomputed values. A future patch will switch over to using the precomputed values once we're sure they're being properly computed. Another clarifying note: DDB allocation itself shouldn't ever fail with the algorithm we use today (i.e., we have enough DDB blocks on BXT to support the minimum needs of the worst-case scenario of every pipe/plane enabled at full size). However the watermarks calculations based on the DDB may fail and we'll be moving those to the atomic check as well in future patches. v2: - Skip DDB calculations in the rare case where our transaction doesn't actually touch any CRTC's at all. Assuming at least one CRTC state is present in our transaction, then it means we can't race with any transactions that would update dev_priv->active_crtcs (which requires _all_ CRTC locks). v3: - Also calculate DDB during initial hw readout, to prevent using incorrect bios values. (Maarten) v4: - Use new distrust_bios_wm flag instead of skip_initial_wm (which was never actually set). - Set intel_state->active_pipe_changes instead of just realloc_pipes Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Lyude Paul <cpaul@redhat.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
-
Matt Roper authored
SKL-style platforms can't fully trust the watermark/DDB settings programmed by the BIOS and need to do extra sanitization on their first atomic update. Add a flag to dev_priv that is set during hardware readout and cleared at the end of the first commit. Note that for the somewhat common case where everything is turned off when the driver starts up, we don't need to bother with a recompute...we know exactly what the DDB should be (all zero's) so just setup the DDB directly in that case. v2: - Move clearing of distrust_bios_wm up below the swap_state call since it's a more natural / self-explanatory location. (Maarten) - Use dev_priv->active_crtcs to test whether any CRTC's are turned on during HW WM readout rather than trying to count the active CRTC's again ourselves. (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Matt Roper authored
We eventually want to calculate watermark values at atomic 'check' time instead of atomic 'commit' time so that any requested configurations that result in impossible watermark requirements are properly rejected. The first step along this path is to allocate the DDB at atomic 'check' time. As we perform this transition, allow the main allocation function to operate successfully on either an in-flight state or an already-commited state. Once we complete the transition in a future patch, we'll come back and remove the unnecessary logic for the already-committed case. v2: Rebase/refactor; we should no longer need to grab extra plane states while allocating the DDB since we can pull cached data rates and minimum block counts from the CRTC state for any planes that aren't being modified by this transaction. v3: - Simplify memsets to clear DDB plane entries. (Maarten) - Drop a redundant memset of plane[pipe][PLANE_CURSOR] that was added by an earlier Coccinelle patch. (Maarten) - Assign *num_active at the top of skl_ddb_get_pipe_allocation_limits() so that no code paths return without setting it. (kbuild robot) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: -
Matt Roper authored
For the purposes of DDB re-allocation we need to know whether a transaction changes the list of CRTC's that are active. While state->modeset could be used for this purpose, that would be slightly too aggressive since it would lead us to re-allocate the DDB when a CRTC's mode changes, but not its final active state. Signed-off-by:
-
Matt Roper authored
This will eventually allow us to re-use old values without re-calculating them for unchanged planes (which also helps us avoid re-grabbing extra plane states). v2: - Drop unnecessary memset's; they were meant for a later patch (which got reworked anyway to not need them, but were mis-rebased into this one. (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: -
Matt Roper authored
Our skl_get_total_relative_data_rate() function gets passed a crtc state object to calculate the data rate for, but it currently always looks up the committed plane states that correspond to that CRTC. Let's check whether the CRTC state is an in-flight state (meaning cstate->state is non-NULL) and if so, use the corresponding in-flight plane states. We'll soon be using this function exclusively for in-flight states; at that time we'll be able to simplify the function a bit, but for now we allow it to be used in either mode. v2: - Rebase on top of changes to cache plane data rates. Signed-off-by:
-
Matt Roper authored
This will be important when we start calculating CRTC data rates for in-flight CRTC states since it will allow us to calculate the total data rate without needing to grab the plane state for any planes that aren't updated by the transaction. Signed-off-by:
-
Matt Roper authored
When we added atomic watermarks, we added a new display vfunc 'compute_pipe_wm' that is used to compute any pipe-specific watermark information that we can at atomic check time. This was a somewhat poor naming choice since we already had a 'skl_compute_pipe_wm' function that doesn't quite fit this model --- the existing SKL function is something that gets used at atomic commit time, after the DDB allocation has been determined. Let's rename the existing SKL function to avoid confusion. Signed-off-by:
-
Matt Roper authored
Reorganize the nested structures and unions we have for pipe watermark data in intel_crtc_state so that platform-specific data can be added in a more sensible manner (and save a bit of memory at the same time). The change basically changes the organization from: union { struct intel_pipe_wm ilk; struct intel_pipe_wm skl; } optimal; struct intel_pipe_wm intermediate /* ILK-only */ to union { struct { struct intel_pipe_wm intermediate; struct intel_pipe_wm optimal; } ilk; struct { struct intel_pipe_wm optimal; } skl; } There should be no functional change here, but it will allow us to add more platform-specific fields going forward (and more easily extend to other platform types like VLV). While we're at it, let's move the entire watermark substructure out to its own structure definition to make the code slightly more readable. Signed-off-by: -
Imre Deak authored
Marking function return types as const is redundant, as these are rvalues and as such constant by definition. Code checkers and GCC will warn about this so remove the modifier. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463059132-1720-5-git-send-email-imre.deak@intel.com
-
Imre Deak authored
A failure from these functions can lead to obscure bugs later, so it's better not to suppress them and just fail module loading. Signed-off-by:
-
Imre Deak authored
Code checkers may complain about the explicit casts between different enum types, so add comments for known-valid cases to help future triaging of such complaints. v2: - Make the comments more logical (Ville). Signed-off-by:
-
Imre Deak authored
scaler_id may be negative as shown by conditions later in the function, so don't use it as an array index in that case. v2: - Remove ps_ctrl while at it (Ville). Signed-off-by:
-
Chris Wilson authored
Following a GPU hang, we break out of the request loop in order to unlock the struct_mutex for use by the GPU reset. However, if we retire all the requests at that moment, we cannot identify the guilty request after performing the reset. v2: Not automatically retiring requests forces us to recheck for available ringspace. Fixes: f4457ae7 ("drm/i915: Prevent leaking of -EIO from i915_wait_request()") Testcase: igt/gem_reset_stats/ban-* Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Tested-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
Chris Wilson authored
In order to reduce the workload of the caller, we do not want to actually have to retire requests of others when checking the busy status of this object. This applies to both busy/wait ioctls as the wait ioctl has a semantically equivalent mode to the busy ioctl. At the present time, this is only a minor improvement to reduce the workload of the busy ioctl under the struct_mutex which helps to reduce its impact upon contention of struct_mutex. However, since it is mostly a victim in highly contended scenarios, the impact is very minor until we can eliminate the struct_mutex requirement for busy-ioctl in the near future. v2: Mention the patches intended limited impact. It is just paving the way for greater changes whilst reducing the impact of a bugfix in the next patch. Signed-off-by:
-
Chris Wilson authored
The get-reset-stats ioctls wasn't waiting for a pending reset before reporting its statistics, and so was ignoring a hang generated by the context that should have been reported against said context. Signed-off-by:
-
Chris Wilson authored
The get-reset-stats ioctl reports upon the statistics (number of hangs, be it as a victim or the guilty party) of a particular context. It is semantically better as being part of i915_gem_context.c user interface, as opposed to the hardware level access of intel_uncore.c Signed-off-by:
-
Ander Conselvan de Oliveira authored
The coding style documentation says the following about typedefs: "In general, a pointer, or a struct that has elements that can reasonably be directly accessed should _never_ be a typedef." intel_limit_t falls in that category, so just use "struct intel_limit" instead. Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462353119-9738-3-git-send-email-ander.conselvan.de.oliveira@intel.com
-
Ander Conselvan de Oliveira authored
Those are only used for defining struct intel_limit, so use anonymous structs instead. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Just use "struct dpll" everywhere. That's actually shorter than intel_clock_t. Signed-off-by:
-
- 12 May, 2016 4 commits
-
-
Nick Hoath authored
Issue: VIZ-7772 Signed-off-by:
Nick Hoath <nicholas.hoath@intel.com> Reviewed-by: peter.antoine@intel.com Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462531373-34819-2-git-send-email-nicholas.hoath@intel.com
-
Tom O'Rourke authored
Load guc firmware from file with major_minor number in filename instead of using symolic link with only major number. This change is so that new firmwares can only be used with a kernel change. This in case there is a regression with a new firmware, it won't be used by default without some testing. Issue: VIZ-7713 Signed-off-by:
Tom O'Rourke <Tom.O'Rourke@intel.com> Signed-off-by:
-
Chris Wilson authored
Another day, another long overdue conversion. Not much to update inside intel_overlay.c, but still text data bss dec hex filename 6309547 3578778 696320 10584645 a18245 vmlinux 6309291 3578778 696320 10584389 a18145 vmlinux a couple of hundred bytes of pointer misdirection. Whilst here, rename the ioctl entry points to include the _ioctl suffix so that the user entry points are clear (following the idiom). Signed-off-by:
-
Ville Syrjälä authored
SKL DPLLs shouldn't be called DPPLs. Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Fixes: 2edd6443 ("drm/i915: Use a table to initilize shared dplls") Signed-off-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com>
-
- 11 May, 2016 5 commits
-
-
Tvrtko Ursulin authored
To be used for more efficient Gen range checking. v2: Remove spurious chunk. (Chris Wilson) v3: Rebase. v4: Renamed from INTEL_GEN_RANGE and added GEN_FOREVER. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462874228-6601-1-git-send-email-tvrtko.ursulin@linux.intel.com
-
Tvrtko Ursulin authored
It just makes more work for the compiler and generates more code. Signed-off-by:
-
Tvrtko Ursulin authored
This way optimization from a previous patch works even better. v2: Rebase. Signed-off-by:
-
Tvrtko Ursulin authored
If we allow it a dedicated flag in dev_priv we enable the compiler to nicely optimize conditions like IS_HASSWELL || IS_BROADWELL. Signed-off-by:
-
Tvrtko Ursulin authored
If instead of numerical comparison me make these test a bitmask, we enable the compiler to optimize all instances of IS_GENx || IS_GENy. v2: Make bit zero of gen mask mean gen 1. Signed-off-by:
-
- 10 May, 2016 3 commits
-
-
Chris Wilson authored
Pass drm_i915_private to the uncore init/fini routines and their subservients as it is their native type. text data bss dec hex filename 6309978 3578778 696320 10585076 a183f4 vmlinux 6309530 3578778 696320 10584628 a18234 vmlinux a modest 400 bytes of saving, but 60 lines of code deleted! Signed-off-by:
-
Ville Syrjälä authored
Move the intel_enable_gtt() call to happen before we touch the GTT during resume. Right now it's done way too late. Before commit ebb7c78d ("agp/intel-gtt: Only register fake agp driver for gen1") it was actually done earlier on account of also getting called from the resume hook of the fake agp driver. With the fake agp driver no longer getting registered we must move the call up. The symptoms I've seen on my 830 machine include lowmem corruption, other kinds of memory corruption, and straight up hung machine during or just after resume. Not really sure what causes the memory corruption, but so far I've not seen any with this fix. I think we shouldn't really need to call this during init, but we have been doing that so I've decided to keep the call. However moving that call earlier could be prudent as well. Doing it right after the intel-gtt probe seems appropriate. Also tested this on 946gz,elk,ilk and all seemed quite happy with this change. v2: Reorder init_hw vs. enable_hw functions (Chris) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: drm-intel-fixes@lists.freedesktop.org Fixes: ebb7c78d ("agp/intel-gtt: Only register fake agp driver for gen1") Signed-off-by:
-
Chris Wilson authored
arch/x86/kernel/early-quirks.c: In function ‘intel_graphics_stolen’: arch/x86/kernel/early-quirks.c:539:9: warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘phys_addr_t’ [-Wformat=] "0x%llx-0x%llx\n", base, base + size - 1); ^ arch/x86/kernel/early-quirks.c:539:9: warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ [-Wformat=] v2: Use %pa for addresses Fixes: ee0629cf (drm/i915: Function per early graphics quirk) Signed-off-by:
-
- 09 May, 2016 5 commits
-
-
Ville Syrjälä authored
When the crtc is enabled but !active, we should still compute the watermarks as if the planes were visible. That would make it more likely that the we can later transition to active without errors. Add a FIXME to remind people that we're doing the wrong thing now. We should perhaps just move the wm computation for each individual plane into the .check_plane hook, and later we'd just combine the results from all active planes. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Ville Syrjälä authored
Use the cdclk we're going to be using when the pipe gets enabled to compute the IPS linetime watermark. The current cdclk frequency is irrelevant at this point since it can still change. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Chris Wilson authored
text data bss dec hex filename 6309351 3578714 696320 10584385 a18141 vmlinux 6308391 3578714 696320 10583425 a17d81 vmlinux Almost 1KiB of code reduction. v2: More s/INTEL_INFO()->gen/INTEL_GEN()/ and IS_GENx() conversions text data bss dec hex filename 6304579 3578778 696320 10579677 a16edd vmlinux 6303427 3578778 696320 10578525 a16a5d vmlinux Now over 1KiB! Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462545621-30125-3-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
Move all of the constant assignments up front and into a common function. This is primarily to ensure the backpointers are set as early as possible for later use during initialisation. v2: Use a constant struct so that all the similar values are set together. v3: Sanitize the engine's IMR to disable any potential interrupt before we are ready (enabled in init_hw). v4: Ignore the engine's IMR, to be resolved later Signed-off-by:
-
Tvrtko Ursulin authored
I have noticed some of our interrupt handlers use both dev and dev_priv while they could get away with only dev_priv in the huge majority of cases. Tidying that up had a cascading effect on changing functions prototypes, so relatively big churn factor, but I think it is for the better. For example even where changes cascade out of i915_irq.c, for functions prefixed with intel_, genX_ or <plat>_, it makes more sense to take dev_priv directly anyway. This allows us to eliminate local variables and intermixed usage of dev and dev_priv where only one is good enough. End result is shrinkage of both source and the resulting binary. i915.ko: - .text 000b0899 + .text 000b0619 Or if we look at the Gen8 display irq chain: -00000000000006ad t gen8_irq_handler +0000000000000663 t gen8_irq_handler -0000000000000028 T intel_opregion_asle_intr +0000000000000024 T intel_opregion_asle_intr -000000000000008c t ilk_hpd_irq_handler +000000000000007f t ilk_hpd_irq_handler -0000000000000116 T intel_check_page_flip +0000000000000112 T intel_check_page_flip -000000000000011a T intel_prepare_page_flip +0000000000000119 T intel_prepare_page_flip -0000000000000014 T intel_finish_page_flip_plane +0000000000000013 T intel_finish_page_flip_plane -0000000000000053 t hsw_pipe_crc_irq_handler +000000000000004c t hsw_pipe_crc_irq_handler -000000000000022e t cpt_irq_handler +0000000000000213 t cpt_irq_handler So small shrinkage but it is all fast paths so doesn't harm. Situation is similar in other interrupt handlers as well. v2: Tidy intel_queue_rps_boost_for_request as well. (Chris Wilson) Signed-off-by:
-
