- 13 May, 2016 10 commits
-
-
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 <imre.deak@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463059132-1720-4-git-send-email-imre.deak@intel.com
-
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 12 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:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
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:
-
Ville Syrjälä authored
DP dual mode type 1 DVI adaptors aren't required to implement any registers, so it's a bit hard to detect them. The best way would be to check the state of the CONFIG1 pin, but we have no way to do that. So as a last resort, check the VBT to see if the HDMI port is in fact a dual mode capable DP port. v2: Deal with VBT code reorganization Deal with DRM_DP_DUAL_MODE_UNKNOWN Reduce DEVICE_TYPE_DP_DUAL_MODE_BITS a bit Accept both DP and HDMI dvo_port in VBT as my BSW at least declare its DP port as HDMI :( v3: Ignore DEVICE_TYPE_NOT_HDMI_OUTPUT (Shashank) Cc: stable@vger.kernel.org Cc: Tore Anderson <tore@fud.no> Reported-by:Tore Anderson <tore@fud.no> Fixes: 7a0baa62 ("Revert "drm/i915: Disable 12bpc hdmi for now"") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com>
-
Ville Syrjälä authored
To save a bit of power, let's try to turn off the TMDS output buffers in DP++ adaptors when we're not driving the port. v2: Let's not forget DDI, toss in a debug message while at it v3: Just do the TMDS output control based on adaptor type. With the helper getting passed the type, we wouldn't actually have to check at all in the driver, but the check eliminates the debug output more honest Cc: stable@vger.kernel.org Cc: Tore Anderson <tore@fud.no> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: -
Ville Syrjälä authored
Try to detect the max TMDS clock limit for the DP++ adaptor (if any) and take it into account when checking the port clock. Note that as with the sink (HDMI vs. DVI) TMDS clock limit we'll ignore the adaptor TMDS clock limit in the modeset path, in case users are already "overclocking" their TMDS links. One subtle change here is that we'll have to respect the adaptor TMDS clock limit when we decide whether to do 12bpc or 8bpc, otherwise we might end up picking 12bpc and accidentally driving the TMDS link out of spec even when the user chose a mode that fits wihting the limits at 8bpc. This means you can't "overclock" your DP++ dongle at 12bpc anymore, but you can continue to do so at 8bpc. Note that for simplicity we'll use the I2C access method for all dual mode adaptors including type 2. Otherwise we'd have to start mixing DP AUX and HDMI together. In the future we may need to do that if we come across any board designs that don't hook up the DDC pins to the DP++ connectors. Such boards would obviously only work with type 2 dual mode adaptors, and not type 1. v2: Store adaptor type under indel_hdmi->dp_dual_mode Deal with DRM_DP_DUAL_MODE_UNKNOWN Pass adaptor type to drm_dp_dual_mode_max_tmds_clock(), and use it for type1 adaptors as well Cc: stable@vger.kernel.org Reported-by: -
Ville Syrjälä authored
Add a helper which aids in the identification of DP dual mode (aka. DP++) adaptors. There are several types of adaptors specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors may go as high as 300MHz and they provide a register informing the source device what the actual limit is. Supposedly also type 1 adaptors may optionally implement this register. This TMDS clock limit is the main reason why we need to identify these adaptors. Type 1 adaptors provide access to their internal registers and the sink DDC bus through I2C. Type 2 adaptors provide this access both via I2C and I2C-over-AUX. A type 2 source device may choose to implement either of these methods. If a source device implements the I2C-over-AUX method, then the driver will obviously need specific support for such adaptors since the port is driven like an HDMI port, but DDC communication happes over the AUX channel. This helper should be enough to identify the adaptor type (some type 1 DVI adaptors may be a slight exception) and the maximum TMDS clock limit. Another feature that may be available is control over the TMDS output buffers on the adaptor, possibly allowing for some power saving when the TMDS link is down. Other user controllable features that may be available in the adaptors are downstream i2c bus speed control when using i2c-over-aux, and some control over the CEC pin. I chose not to provide any helper functions for those since I have no use for them in i915 at this time. The rest of the registers in the adaptor are mostly just information, eg. IEEE OUI, hardware and firmware revision, etc. v2: Pass adaptor type to helper functions to ease driver implementation Fix a bunch of typoes (Paulo) Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know the type (Paulo) Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo) Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to ease future LSPCON enabling Remove the unused DP_DUAL_MODE_LAST_RESERVED define v3: Fix kernel doc function argument descriptions (Jani) s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs Add kernel doc for enum drm_dp_dual_mode_type Actually build the docs Fix more typoes v4: Adjust code indentation of type2 adaptor detection (Shashank) Add debug messages for failurs cases (Shashank) v5: EXPORT_SYMBOL(drm_dp_dual_mode_read) (Paulo) Cc: stable@vger.kernel.org Cc: Tore Anderson <tore@fud.no> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: -
Maarten Lankhorst authored
This makes it easier to debug issues like https://bugs.freedesktop.org/show_bug.cgi?id=93477Signed-off-by:
-
Daniel Vetter authored
This reverts commit 3543995a. I mixed up maintainers and thought Linus' ack was for the mfd tree. But Lee Jones (the real maintainer) wants to merge this through the mfd tree, so revert here. Cc: Lee Jones <lee.jones@linaro.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Kenneth Graunke authored
Allowing register copies where the source and destination are both whitelisted should be safe, and is useful. For example, Mesa uses this to load the command streamer math registers with data from the pipeline statistics counters. v2: Reject writes to OACONTROL (and reads as well :( Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> # v1 Signed-off-by:
-
- 08 May, 2016 1 commit
-
-
Daniel Vetter authored
Signed-off-by:
-
- 05 May, 2016 3 commits
-
-
Rodrigo Vivi authored
Version 1.01. This firmware is made for Kabylake platform so it doesn't need the stepping workaround that we had before. v2: Rebased on top of latest nightly with min version required change. v3: With right CSR_VERSION (Patrik). Cc: Christophe Prigent <christophe.prigent@intel.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1) Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461707991-15336-1-git-send-email-rodrigo.vivi@intel.com
-
Chris Wilson authored
As i915_ppgtt_init() is not used outside of i915_gem_gtt.c we can make it static. Signed-off-by:
Matthew Auld <matthew.auld@intel.com>
-
Chris Wilson authored
If the command parser is not active, then it is appropriate to report it as operating at version 0 as no higher mode is supported. This greatly simplifies userspace querying for the command parser as we then do not need to second guess when it will be active (a mixture of module parameters and generational support, which may change over time). v2: s/comand/command/ misspelling in comment Signed-off-by:
-
- 04 May, 2016 2 commits
-
-
Daniel Vetter authored
LPT is pch, so might run into the fdi bandwidth constraint (especially since it has only 2 lanes). But right now we just force pipe_bpp back to 24, resulting in a nice loop (which we bail out with a loud WARN_ON). Fix this. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=93477Signed-off-by:
-
Matthew Auld authored
Only has one user and is nothing more than a shim on top of i915_vma_unbind, so let's just get rid of it. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Suggested-by:
-
