- 16 Feb, 2018 1 commit
-
-
Christian König authored
i915 is the only driver using those fields in the drm_gem_object structure, so they only waste memory for all other drivers. Move the fields into drm_i915_gem_object instead and patch the i915 code with the following sed commands: sed -i "s/obj->base.read_domains/obj->read_domains/g" drivers/gpu/drm/i915/*.c drivers/gpu/drm/i915/*/*.c sed -i "s/obj->base.write_domain/obj->write_domain/g" drivers/gpu/drm/i915/*.c drivers/gpu/drm/i915/*/*.c Change is only compile tested. v2: move fields around as suggested by Chris. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180216124338.9087-1-christian.koenig@amd.comSigned-off-by:
-
- 15 Feb, 2018 20 commits
-
-
Mahesh Kumar authored
Register Address for CNL_PORT_DW5_LN0_D is 0x162E54, but current code is defining it as 0x162ED4. Similarly for CNL_PORT_DW7_LN0_D register address is defined 0x162EDC instead of 0x162E5C, fix it. Signed-off-by:
Mahesh Kumar <mahesh1.kumar@intel.com> Fixes: 04416108 ("drm/i915/cnl: Add registers related to voltage swing sequences.") Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
The frame counter may have got reset between disabling and enabling vblank interrupts due to DMC putting the hardware to DC5/6 states if PSR was active. The frame counter could also have stalled if PSR was active in case there was no DMC. The frame counter resetting has a user visible impact of screen freezes. Make use of drm_vblank_restore() to compute missed vblanks for the duration in which vblank interrupts were disabled and update the vblank counter with this value as diff. There's no need to check if PSR was actually active in the interrupt disabled duration, so simplify the check to a feature check. Enabling vblank interrupts wakes up the hardware from DC5/6 and prevents it from going back again as long as the there are pending interrupts. So, we don't have to explicity disallow DC5/6 after enabling vblank interrupts to keep the counter running. This change is not applicable to CHV, as enabling interrupts does not prevent the hardware from activating PSR. v2: Added comments(Rodrigo) and rewrote commit message. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Dhinakaran Pandiyan authored
The HW frame counter can get reset if device enters a low power state after vblank interrupts were disabled. This messes up any following vblank count update as a negative diff (huge unsigned diff) is calculated from the HW frame counter change. We cannot ignore negative diffs altogther as there could be legitimate wrap arounds. So, allow drivers to update vblank->count with missed vblanks for the time interrupts were disabled. This is similar to _crtc_vblank_on() except that vblanks interrupts are not enabled at the end as this function is expected to be called from the driver _enable_vblank() vfunc. v2: drm_crtc_vblank_restore should take crtc as arg. (Chris) Add docs and sprinkle some asserts. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Dänzer <michel@daenzer.net> Signed-off-by: -
Dhinakaran Pandiyan authored
Updating vblank counts requires register reads and these reads may not return meaningful values if the device was in a low power state after vblank interrupts were last disabled. So, update the count only if vblank interrupts are enabled. Secondly, this means the registers should be read before disabling vblank interrupts. v2: Don't check vblank->enabled outside it's lock (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Michel Dänzer <michel@daenzer.net> Signed-off-by:
-
Dhinakaran Pandiyan authored
570e8696 ("drm: Widen vblank count to 64-bits [v3]") changed the return type for drm_crtc_vblank_count() to u64. The flip ioctl receives a 32-bit target sequence from user space and is compared against the current sequence from drm_crtc_vblank_count(). So, typecast return from drm_crtc_vblank_count() explicitly to add clarity. __drm_crtcs_state.last_vblank_count however only ever stores the value from drm_crtc_vblank_count() and can be upgraded to u64. Cc: Keith Packard <keithp@keithp.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
570e8696 ("drm: Widen vblank count to 64-bits [v3]") changed the return type for drm_crtc_vblank_count() to u64. This could cause potential problems if the return value is used in arithmetic operations with a 32-bit reference HW vblank count. Explicitly typecasting this down to u32 either fixes a potential problem or serves to add clarity in case the implicit typecasting was already correct. Cc: Keith Packard <keithp@keithp.com> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
570e8696 ("drm: Widen vblank count to 64-bits [v3]") changed the return type for drm_crtc_vblank_count() to u64. This could cause potential problems if the return value is used in arithmetic operations with a 32-bit reference HW vblank count. Explicitly typecasting this down to u32 either fixes a potential problem or serves to add clarity in case the implicit typecasting was already correct. Cc: Keith Packard <keithp@keithp.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
570e8696 ("drm: Widen vblank count to 64-bits [v3]") changed the return type for drm_crtc_vblank_count() to u64. This could cause potential problems if the return value is used in arithmetic operations with a 32-bit reference HW vblank count. Explicitly typecasting this down to u32 either fixes a potential problem or serves to add clarity in case the typecasting was implicitly done. Cc: Keith Packard <keithp@keithp.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> for both this patch Signed-off-by:
-
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 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: -
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 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 1 commit
-
-
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:
-
