- 15 Feb, 2018 7 commits
-
-
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 <chris@chris-wilson.co.uk> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180215081930.11477-2-chris@chris-wilson.co.uk
-
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 <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214160720.19673-1-chris@chris-wilson.co.uk
-
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:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> 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 14 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:
-
Paulo Zanoni authored
This code is similar enough to the CNL code that I considered just adding ICL support to the CNL function, but I think it's still different enough, and having a function specific to ICL allows us to more easily adapt code in case the spec changes more later. We're still missing the power wells and the mbus code, so leave those pieces with a FIXME comment while they're not here yet. v2: Don't use _PICK, don't WARN_ON(1), don't forget the chicken bits. v3: Use _MMIO_PORT() (Ville). Reviewed-by: James Ausmus <james.ausmus@intel.com> (v2) Signed-off-by:
-
Paulo Zanoni authored
This commit adds the basic CDCLK functions, but it's still missing pieces of the display initialization sequence. v2: - Implement the voltage levels. - Rebase. v3: - Adjust to the new "bypass" clock (Imre). - Call intel_dump_cdclk_state() too. - Rename a variable to avoid confusion. - Simplify the DVFS part. v4: - Remove wrong bit definition (James). - Also drive-by fix the coding style for the register definition we touched. v5: - Comment style (checkpatch). Cc: James Ausmus <james.ausmus@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Paulo Zanoni authored
On ICL we have two sets of registers: one for port A and another for port B. The set of port A registers is the same as the CNL registers. Since the procmon table on ICL is the same we want to reuse the CNL function. To do that we add a port argument and make CNL always call the function passing port A. This way, we'll be able to easily reuse the function on ICL when we add icl_display_core_init(). v2: Don't use _PICK() when you can use a ternary operator. v3: Don't use a ternary operation when you can use _MMIO_PORT (Ville). Add an extra comment about why we're passing PORT_A (James). Reviewed-by: -
David Weinehall authored
While the comment singles out Port A or B, the code says Port A or *D*. Looking at the history it seems that the comment was added after the code, so it seems likely that the code is correct, not the comment. CC: Jani Nikula <jani.nikula@intel.com> CC: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
David Weinehall <david.weinehall@linux.intel.com> Reviewed-by:
-
- 12 Feb, 2018 1 commit
-
-
Chris Wilson authored
When initialising the page directories, we set the GTT entries and the tree to the scratch page. We have already replaced the DMA fill with memset64(), but we can similarly use memset_p() to set the pointer array. References: 4dd504f7 ("drm/i915: Use memset64() to prefill the GTT page") Signed-off-by:
-
