- 15 Feb, 2018 12 commits
-
-
Dhinakaran Pandiyan authored
570e8696 ("drm: Widen vblank count to 64-bits [v3]") changed the return type for drm_crtc_vblank_count() to u64, store all the bits without truncating. There is no need to type cast this value down to 32-bits. Cc: Keith Packard <keithp@keithp.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180203051302.9974-3-dhinakaran.pandiyan@intel.com
-
Dhinakaran Pandiyan authored
Core returns a u64 vblank count and intel_crtc_get_vblank_counter() expects a 32-bit value. Make the typecast explicit to add clarity. Cc: Keith Packard <keithp@keithp.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
drm_vblank_count() has an u32 type returning what is a 64-bit vblank count. The effect of this is when drm_wait_vblank_ioctl() tries to widen the user space requested vblank sequence using this clipped 32-bit count(when the value is >= 2^32) as reference, the requested sequence remains a 32-bit value and gets queued like that. However, the code that checks if the requested sequence has passed compares this against the 64-bit vblank count. With drm_vblank_count() returning all bits of the vblank count, update drm_crtc_accurate_vblank_count() so that drm_crtc_arm_vblank_event() queues the correct sequence. Otherwise, this leads to prolonged waits for a vblank sequence when the current count is >=2^32. Finally, fix drm_wait_one_vblank() too. v2: Commit message fix (Keith) Squash commits (Rodrigo) Fixes: 570e8696 ("drm: Widen vblank count to 64-bits [v3]") Cc: Keith Packard <keithp@keithp.com> Cc: Michel Dänzer <michel@daenzer.net> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Gustavo A. R. Silva authored
Fix inconsistent IS_ERR and PTR_ERR in shrink_boom. The proper pointer to use is _explode_ instead of _purge_. This issue was detected with the help of Coccinelle. Fixes: fe215c8b ("drm/i915/selftests: add missing gtt shrinker test") Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214211234.GA22341@embeddedgusReviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Rather than deriving the platform_mask from the intel_device_static_info->platform at runtime, pre-fill it in the static data. v2: Undefine macros at end of their scope Signed-off-by:
-
Chris Wilson authored
Be consistent and define the device's GEN as part of the GENx_FEATURE. It will be overridden by the next gen upon inheriting, as per usual. Signed-off-by:
-
Chris Wilson authored
Rather than deriving the gen_mask from the static intel_device_info->gen at runtime, pre-fill it in the static data. v2: Undefine local macros at end of their scope. Signed-off-by:
-
Chris Wilson authored
As we presume that we have sufficient coverage of CI for new machines and new code paths, we do not need to have user impacting WARN_ON for programming errors inside i915_gem_gtt.c, so convert those over to GEM_BUG_ON. This leaves the memory debugging WARN_ON in place as they are not so easy to exercise with CI. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180215110759.28603-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
As befitting a file dedicated to the mistakes of the past, drivers/gpu/drm/i915/i915_ioc32.c:2: warning: Cannot understand * \file i915_ioc32.c on line 2 - I thought it was a doc line drivers/gpu/drm/i915/i915_ioc32.c:82: warning: Function parameter or member 'filp' not described in 'i915_compat_ioctl' drivers/gpu/drm/i915/i915_ioc32.c:82: warning: Function parameter or member 'cmd' not described in 'i915_compat_ioctl' drivers/gpu/drm/i915/i915_ioc32.c:82: warning: Function parameter or member 'arg' not described in 'i915_compat_ioctl' Signed-off-by:
-
Jani Nikula authored
Turns out -1 >= ARRAY_SIZE() is always true. Move the bounds check where we know pipe >= 0 and next to the array indexing where it makes most sense. Fixes: 9965db26 ("drm/i915: Check for fused or unused pipes") Fixes: 0b7029b7 ("drm/i915: Check for fused or unused pipes") Cc: <stable@vger.kernel.org> # v4.10+ Cc: Mika Kahola <mika.kahola@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
We now have a stable cnl on our CI and it seems mostly green without big risks of blank screen or anything blowing up on linux installations in the future. As a reminder i915.alpha_support was created to protect future linux installation's iso images that might contain a kernel from the enabling time of the new platform. Without this protection most of linux installation was recommending nomodeset option during installation that was getting stick there after installation. Specifically, alpha support says nothing about the development state of the hardware, and everything about the state of the driver in a kernel release. This is semantically no different from the old preliminary_hw_support flag, but the old one was all too often interpreted as (preliminary hw) support instead of the intended (preliminary) hw support, and it was misleading for everyone. Hence the rename. v2: Fix the typos and include more history about the parameter rename on commit message. (Jani) Reference: https://intel-gfx-ci.01.org/tree/drm-tip/fi-cnl-y3.html Cc: James Ausmus <james.ausmus@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Saarinen <jani.saarinen@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Rodrigo Vivi authored
Add one missing PCI ID and sort them in a way that gets easier to review and compare against spec's table. When trying to sync libdrm and mesa id list with kernel and spec I noticed something was wrong and we were missing a pci id. So to make our lives easier when checking against spec let's simplify and sort like spec does. BSpec: 13621 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: James Ausmus <james.ausmus@intel.com> Signed-off-by:
James Ausmus <james.ausmus@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180208073219.27860-1-rodrigo.vivi@intel.com
-
- 14 Feb, 2018 18 commits
-
-
Daniele Ceraolo Spurio authored
GENMASK_ULL wants the high bit of the mask first. The current value cancels the in-fence when an out-fence is returned. Fixes: fec0445c ("drm/i915: Support explicit fencing for execbuf") Testcase: igt/gem_exec_fence/keep-in-fence* Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/intel_pm.c:750: warning: Function parameter or member 'fifo_size' not described in 'intel_calculate_wm' drivers/gpu/drm/i915/intel_pm.c:5900: warning: Function parameter or member 'crtc' not described in 'intel_update_watermarks' Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Chris Wilson authored
drivers/gpu/drm/i915/intel_display.c:569: warning: Function parameter or member 'dev_priv' not described in 'intel_PLL_is_valid' drivers/gpu/drm/i915/intel_display.c:569: warning: Function parameter or member 'limit' not described in 'intel_PLL_is_valid' drivers/gpu/drm/i915/intel_display.c:569: warning: Function parameter or member 'clock' not described in 'intel_PLL_is_valid' drivers/gpu/drm/i915/intel_display.c:4769: warning: Function parameter or member 'crtc_state' not described in 'skl_update_scaler_plane' drivers/gpu/drm/i915/intel_display.c:4769: warning: Excess function parameter 'state' description in 'skl_update_scaler_plane' drivers/gpu/drm/i915/intel_display.c:4967: warning: Function parameter or member 'new_crtc_state' not described in 'intel_post_enable_primary' drivers/gpu/drm/i915/intel_display.c:12650: warning: Function parameter or member 'new_state' not described in 'intel_prepare_plane_fb' drivers/gpu/drm/i915/intel_display.c:12650: warning: Excess function parameter 'fb' description in 'intel_prepare_plane_fb' drivers/gpu/drm/i915/intel_display.c:12763: warning: Function parameter or member 'old_state' not described in 'intel_cleanup_plane_fb' drivers/gpu/drm/i915/intel_display.c:12763: warning: Excess function parameter 'fb' description in 'intel_cleanup_plane_fb' Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/intel_atomic.c:198: warning: Function parameter or member 'state' not described in 'intel_crtc_destroy_state' drivers/gpu/drm/i915/intel_atomic.c:222: warning: Function parameter or member 'intel_crtc' not described in 'intel_atomic_setup_scalers' drivers/gpu/drm/i915/intel_atomic.c:222: warning: Excess function parameter 'crtc' description in 'intel_atomic_setup_scalers' Signed-off-by:
-
Chris Wilson authored
Just a parameter name change that was lost to kerneldoc. drivers/gpu/drm/i915/intel_uc_fw.c:209: warning: Function parameter or member 'xfer' not described in 'intel_uc_fw_upload' drivers/gpu/drm/i915/intel_uc_fw.c:209: warning: Excess function parameter 'loader' description in 'intel_uc_fw_upload' v2: Add the Returns: Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214105332.30230-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
During the recent upheaval to uc, the parameters to huc_ucode_xfer were changed, but the kerneldoc left behind. drivers/gpu/drm/i915/intel_huc.c:128: warning: Function parameter or member 'huc_fw' not described in 'huc_ucode_xfer' drivers/gpu/drm/i915/intel_huc.c:128: warning: Function parameter or member 'vma' not described in 'huc_ucode_xfer' drivers/gpu/drm/i915/intel_huc.c:128: warning: Excess function parameter 'dev_priv' description in 'huc_ucode_xfer' Signed-off-by:
-
Chris Wilson authored
Remove the kerneldoc markup applied to non-kerneldoc comments and convert the multiline comments to the canonical style. drivers/gpu/drm/i915/intel_lvds.c:313: warning: Function parameter or member 'encoder' not described in 'intel_enable_lvds' drivers/gpu/drm/i915/intel_lvds.c:313: warning: Function parameter or member 'pipe_config' not described in 'intel_enable_lvds' drivers/gpu/drm/i915/intel_lvds.c:313: warning: Function parameter or member 'conn_state' not described in 'intel_enable_lvds' drivers/gpu/drm/i915/intel_lvds.c:453: warning: Function parameter or member 'connector' not described in 'intel_lvds_detect' drivers/gpu/drm/i915/intel_lvds.c:453: warning: Function parameter or member 'force' not described in 'intel_lvds_detect' drivers/gpu/drm/i915/intel_lvds.c:471: warning: Function parameter or member 'connector' not described in 'intel_lvds_get_modes' drivers/gpu/drm/i915/intel_lvds.c:932: warning: Function parameter or member 'dev_priv' not described in 'intel_lvds_init' drivers/gpu/drm/i915/intel_lvds.c:932: warning: Excess function parameter 'dev' description in 'intel_lvds_init' Signed-off-by:
-
Chris Wilson authored
Remove the kerneldoc markup applied to non-kerneldoc comments and convert the multiline comments to the canonical style. drivers/gpu/drm/i915/intel_dvo.c:303: warning: Function parameter or member 'connector' not described in 'intel_dvo_detect' drivers/gpu/drm/i915/intel_dvo.c:303: warning: Function parameter or member 'force' not described in 'intel_dvo_detect' drivers/gpu/drm/i915/intel_dvo.c:382: warning: Function parameter or member 'encoder' not described in 'intel_dvo_get_current_mode' Signed-off-by:
-
Chris Wilson authored
Regular comments where being marked up for kerneldoc, but were not formatted properly. Remove the markup to remove the warnings. drivers/gpu/drm/i915/dvo_ivch.c:192: warning: Function parameter or member 'dvo' not described in 'ivch_read' drivers/gpu/drm/i915/dvo_ivch.c:192: warning: Function parameter or member 'addr' not described in 'ivch_read' drivers/gpu/drm/i915/dvo_ivch.c:192: warning: Function parameter or member 'data' not described in 'ivch_read' Signed-off-by:
-
Chris Wilson authored
The code describes what it is doing quite well; and that is now much more complex than what the old comment would let you believe. drivers/gpu/drm/i915/intel_crt.c:486: warning: Function parameter or member 'connector' not described in 'intel_crt_detect_hotplug' Signed-off-by:
-
Chris Wilson authored
Split the 64b multiplication from the division so that it doesn't sprawl across a couple of lines and use mul_u32_u32() instead of open-coding the 64b conversion. Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/intel_panel.c:409: warning: Function parameter or member 'source_min' not described in 'scale' drivers/gpu/drm/i915/intel_panel.c:409: warning: Function parameter or member 'source_max' not described in 'scale' drivers/gpu/drm/i915/intel_panel.c:409: warning: Function parameter or member 'target_min' not described in 'scale' drivers/gpu/drm/i915/intel_panel.c:409: warning: Function parameter or member 'target_max' not described in 'scale' Signed-off-by:
-
Chris Wilson authored
Drop the kerneldoc markup from the non-kerneldoc comments and convert the multi-line comments to the canonical format. drivers/gpu/drm/i915/intel_sdvo.c:223: warning: Function parameter or member 'intel_sdvo' not described in 'intel_sdvo_write_sdvox' drivers/gpu/drm/i915/intel_sdvo.c:223: warning: Function parameter or member 'val' not described in 'intel_sdvo_write_sdvox' drivers/gpu/drm/i915/intel_sdvo.c:653: warning: Function parameter or member 'intel_sdvo' not described in 'intel_sdvo_get_trained_inputs' drivers/gpu/drm/i915/intel_sdvo.c:653: warning: Function parameter or member 'input_1' not described in 'intel_sdvo_get_trained_inputs' drivers/gpu/drm/i915/intel_sdvo.c:653: warning: Function parameter or member 'input_2' not described in 'intel_sdvo_get_trained_inputs' drivers/gpu/drm/i915/intel_sdvo.c:2311: warning: Function parameter or member 'dev_priv' not described in 'intel_sdvo_select_ddc_bus' drivers/gpu/drm/i915/intel_sdvo.c:2311: warning: Function parameter or member 'sdvo' not described in 'intel_sdvo_select_ddc_bus' Signed-off-by:
-
Chris Wilson authored
The ages old kerneldoc-esque comments still refer to the original stubs and not the more complete functions. As they were only describing the external entry points (or at least thought themselves to be, they had drifted!), they don't provide any commentary for the code flow. drivers/gpu/drm/i915/intel_tv.c:379: warning: cannot understand function prototype: 'const struct tv_mode tv_modes[] = ' drivers/gpu/drm/i915/intel_tv.c:1133: warning: bad line: drivers/gpu/drm/i915/intel_tv.c:1140: warning: Function parameter or member 'intel_tv' not described in 'intel_tv_detect_type' drivers/gpu/drm/i915/intel_tv.c:1140: warning: Function parameter or member 'connector' not described in 'intel_tv_detect_type' drivers/gpu/drm/i915/intel_tv.c:1272: warning: Function parameter or member 'connector' not described in 'intel_tv_detect' drivers/gpu/drm/i915/intel_tv.c:1272: warning: Function parameter or member 'ctx' not described in 'intel_tv_detect' drivers/gpu/drm/i915/intel_tv.c:1272: warning: Function parameter or member 'force' not described in 'intel_tv_detect' drivers/gpu/drm/i915/intel_tv.c:1351: warning: Function parameter or member 'connector' not described in 'intel_tv_get_modes' Signed-off-by:
-
Hans de Goede authored
So far models of the Dell Venue 8 Pro, with a panel with MIPI panel index = 3, one of which has been kindly provided to me by Jan Brummer, where not working with the i915 driver, giving a black screen on the first modeset. The problem with at least these Dells is that their VBT defines a MIPI ASSERT sequence, but not a DEASSERT sequence. Instead they DEASSERT the reset in their INIT_OTP sequence, but the deassert must be done before calling intel_dsi_device_ready(), so that is too late. Simply doing the INIT_OTP sequence earlier is not enough to fix this, because the INIT_OTP sequence also sends various MIPI packets to the panel, which can only happen after calling intel_dsi_device_ready(). This commit fixes this by splitting the INIT_OTP sequence into everything before the first DSI packet and everything else, including the first DSI packet. The first part (everything before the first DSI packet) is then used as deassert sequence. Changed in v2: -Split the init OTP sequence into a deassert reset and the actual init OTP sequence, instead of calling it earlier and then having the first mipi_exec_send_packet() call call intel_dsi_device_ready(). Changes in v3: -Move the whole shebang to intel_bios.c Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82880 References: https://bugs.freedesktop.org/show_bug.cgi?id=101205 Cc: Jan-Michael Brummer <jan.brummer@tabos.org> Reported-by:
Jan-Michael Brummer <jan.brummer@tabos.org> Tested-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
Hans de Goede authored
Make intel_bios_cleanup function free the DSI VBT data structures which are memdup-ed by parse_mipi_config() and parse_mipi_sequence(). Reviewed-by:
-
Hans de Goede authored
Add an intel_bios_cleanup() function to act as counterpart of intel_bios_init() and move the cleanup of vbt related resources there, putting it in the same file as the allocation. Changed in v2: -While touching the code anyways, remove the unnecessary: if (dev_priv->vbt.child_dev) done before kfree(dev_priv->vbt.child_dev) Reviewed-by:
-
Joonas Lahtinen authored
Signed-off-by:Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 13 Feb, 2018 10 commits
-
-
Tvrtko Ursulin authored
We can implement limited RC6 counter wrap-around protection under the assumption that clients will be reading this value more frequently than the wrap period on a given platform. With the typical wrap-around period being ~90 minutes, even with the exception of Baytrail which wraps every 13 seconds, this sounds like a reasonable assumption. Implementation works by storing a 64-bit software copy of a hardware RC6 counter, along with the previous HW counter snapshot. This enables it to detect wrap is polled frequently enough and keep the software copy monotonically incrementing. v2: * Missed GEN6_GT_GFX_RC6_LOCKED when considering slot sizing and indexing. * Fixed off-by-one in wrap-around handling. (Chris Wilson) v3: * Simplify index checking by using unsigned int. (Chris Wilson) * Expand the comment to explain why indexing works. v4: * Use __int128 if supported. v5: * Use mul_u64_u32_div. (Chris Wilson) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94852 Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> # v3 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
Header uses I915_NUM_ENGINES so needs to include i915.gem.h, and also it uses requests so we can forward declare struct drm_i915_gem_request. Signed-off-by:
-
Jani Nikula authored
Cleanup similar to INTEL_PCH_TYPE(). No functional changes. Reviewed-by:
-
Jani Nikula authored
Simplify intel_virt_detect_pch() by making it return a PCH id rather than returning the PCH type and setting PCH id for some PCHs. Map the PCH id to PCH type using the shared routine. This gives us sanity check on the supported combinations also in the virtualized setting. Reviewed-by:
-
Jani Nikula authored
Make the code slightly more pleasant to look at. No functional changes. Reviewed-by:
-
Jani Nikula authored
Make the logic in intel_detect_pch() easier to follow, and make the PCH id to type mapping reusable. No functional changes. Reviewed-by:
-
Chris Wilson authored
igt_partial_tiling managed to fail with an -EBUSY. This usually means a pin leak, but that should be impossible given the test setup. Add a couple of error messages to help identify the path that failed. References: https://bugs.freedesktop.org/show_bug.cgi?id=105073Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180213120940.21579-1-chris@chris-wilson.co.uk
-
Mahesh Kumar authored
This patch program default values of MBus credit during pipe enable. Changes Since V1: - Add WARN_ON (Paulo) - Remove TODO comment - Program 0 during pipe disable - Rebase Changes since V2: - We don't need to do anything when disabling the pipe Changes since V3 (from Paulo): - Remove WARN() that we'll never be able to trigger (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by:
-
Mahesh Kumar authored
This patch initializes MBus during display initialization. Changes since V2 (from Paulo): - Don't forget to remove the WARN_ON(1) call. Changes since V1: - Rebase to use function like Macros Reviewed-by:
-
Mahesh Kumar authored
ICL has 2 slices of DBuf, enable both the slices during display init. Ideally we should only enable the second slice when needed in order to save power, but while we're not there yet, adopt the simpler solution to keep us bug-free. v2 (from Paulo): - Add the TODO comment. - Reorganize where things are defined. - Fix indentation. - Remove unnecessary POSTING_READ() calls. - Improve the commit message. Reviewed-by:
-
