- 24 Mar, 2020 6 commits
-
-
Chris Wilson authored
On Ivybridge, we can go lower than rc6 to rc6p. And this is required for Ivybridge to hit the same minimum power consumption as rc6 on other platforms, so make it so. v2: Update selftest to include all rc6 residency counters Note that Andi did mention that we should be converting the magic numbers into opaque magic macros, so if they ever get reused (unlikely given only Ivybridge used the extra modes) we'll need to pay back the technical debt. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1518 Fixes: 730eaeb5 ("drm/i915/gt: Manual rc6 entry upon parking") Testcase: igt/i915_pm_rc6_residency/rc6-idle Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200324134232.8773-1-chris@chris-wilson.co.uk
-
Vandita Kulkarni authored
On dsi cmd mode we do not receive vblanks instead we would get TE and these flags indicate TE is expected on which port. Signed-off-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Vandita Kulkarni authored
If the GOP has programmed periodic command mode, we need to disable that which would need a deconfigure and configure sequence. v2: Fix sparse error, pass only intel_dsi (Jani) v3: Use intel_de_read Signed-off-by:
-
Vandita Kulkarni authored
Adding TE flags and periodic command mode flags as part of private flags to indicate what TE interrupts we would be getting instead of vblanks in case of mipi dsi command mode. v2: Add TE flag description (Jani) Reviewed-by:
-
Vandita Kulkarni authored
Transcoder timing calculation differ for command mode. v2: Use is_vid_mode, and use same I915_WRITE (Jani) v3: Adjust the calculations to reflect dsc compression ratio v4: Rearrange the vertical and horizontal timing calc, optimize local variables usage. (Jani) v5: Fix the values used for calculation, use afe_clk for byte clock calculation, use intel_de_write/read (Jani) Signed-off-by: -
Vandita Kulkarni authored
Configure the transcoder to operate in TE GATE command mode and take TE events from GPIO. Also disable the periodic command mode, that GOP would have programmed. v2: Disable util pin (Jani) v3: Use intel_de_write (Jani) Signed-off-by:
-
- 23 Mar, 2020 10 commits
-
-
Chris Wilson authored
It is strictly sufficient to only delay the intel_engine_pm_put from the context barrier (and not from the context exit) in order to prevent the gem_exec_nop contention. Adding the delay to the context exit incurs noticably extra penalty for soft-rc6. Fixes: edee52c9 ("drm/i915/gt: Delay release of engine-pm after last retirement") Testcase: igt/i915_pm_rc6_residency/rc6-idle Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200323192029.20723-1-chris@chris-wilson.co.uk
-
Matthew Auld authored
It looks like some callers expect a non-volatile object, that they do not want the contents of the pages lost if they happen to not be looking at it. The shrinker however sees that we mark the pages as DONTNEED and believes that it can freely reap them. However, since the huge object use plain pages, they cannot be swapped out as they have no backing storge, and the only way we can shrink them is by discarding the contents. In light of the callers wanting to keep the contents around, both IS_SHRINKABLE and marking the pages as volatile are incorrect. If we drop the IS_SHRINKABLE flag we avoid the immediate issue of the shrinker accidentally removing valuable content. We will have to remember that a huge object is not suitable for exercising the shrinker interaction -- although we can introduce a shrinkable one if we require. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
-
Chris Wilson authored
Keep the engine-pm awake until the next jiffie, to avoid immediate ping-pong under moderate load. (Forcing the idle barrier excerbates the moderate load, dramatically increasing the driver overhead.) On the other hand, delaying the idle-barrier slightly incurs longer rc6-off and so more power consumption. Closes: https://gitlab.freedesktop.org/drm/intel/issues/848Signed-off-by:
-
Chris Wilson authored
In some cases we want to hold onto the wakeref for a little after the last user so that we can avoid having to drop and then immediately reacquire it. Allow the last user to specify if they would like to keep the wakeref alive for a short hysteresis. v2: Embrace bitfield.h for adjustable flags. Signed-off-by:
-
Matthew Auld authored
Stolen memory is allocated at creation, returning -ENOSPC if we run out space. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1424Signed-off-by:
-
Chris Wilson authored
Drop the pretense of kicking the tasklet (used only for the defunct guc submission backend, it should just take ownership of the submit!) and so remove the bh-kicking from around submission. Signed-off-by:
-
Chris Wilson authored
As we store the handle lookup inside a radix tree, we do not need the gem_context->mutex except until we need to insert our lookup into the common radix tree. This takes a small bit of rearranging to ensure that the lut we insert into the tree is ready prior to actually inserting it (as soon as it is exposed via the radixtree, it is visible to any other submission). v2: For brownie points, remove the goto spaghetti. v3: Tighten up the closed-handle checks. Signed-off-by:
-
Chris Wilson authored
Abuse^W Take advantage that we know we are inside the GT wakeref and that prevents any client execbuf from reopening the i915_vma in order to claim all the vma to close without having to drop the spinlock to free each one individually. By keeping the spinlock, we do not have to restart if we run concurrently with i915_gem_free_objects -- which causes them both to restart continually and make very very slow progress. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1361 Fixes: 77853186 ("drm/i915: Claim vma while under closed_lock in i915_vma_parked()") Signed-off-by:
-
Chris Wilson authored
Since we take advantage of RCU for some i915_active objects, like the intel_timeline_cacheline, we need to delay the i915_active_fini until after the RCU grace period and we perform the kfree -- that is until after all RCU protected readers. <3> [108.204873] ODEBUG: assert_init not available (active state 0) object type: i915_active hint: __cacheline_active+0x0/0x80 [i915] <4> [108.207377] WARNING: CPU: 3 PID: 2342 at lib/debugobjects.c:488 debug_print_object+0x67/0x90 <4> [108.207400] Modules linked in: vgem snd_hda_codec_hdmi x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_hda_intel ghash_clmulni_intel snd_intel_dspcfg snd_hda_codec ax88179_178a snd_hwdep usbnet btusb snd_hda_core btrtl mii btbcm btintel snd_pcm bluetooth ecdh_generic ecc i915 i2c_hid pinctrl_sunrisepoint pinctrl_intel intel_lpss_pci prime_numbers <4> [108.207587] CPU: 3 PID: 2342 Comm: gem_exec_parall Tainted: G U 5.6.0-rc6-CI-Patchwork_17047+ #1 <4> [108.207609] Hardware name: Google Soraka/Soraka, BIOS MrChromebox-4.10 08/25/2019 <4> [108.207639] RIP: 0010:debug_print_object+0x67/0x90 <4> [108.207668] Code: 83 c2 01 8b 4b 14 4c 8b 45 00 89 15 87 d2 8a 02 8b 53 10 4c 89 e6 48 c7 c7 38 2b 32 82 48 8b 14 d5 80 2f 07 82 e8 49 d5 b7 ff <0f> 0b 5b 83 05 c3 f6 22 01 01 5d 41 5c c3 83 05 b8 f6 22 01 01 c3 <4> [108.207692] RSP: 0018:ffffc90000e7f890 EFLAGS: 00010282 <4> [108.207723] RAX: 0000000000000000 RBX: ffffc90000e7f8b0 RCX: 0000000000000001 <4> [108.207747] RDX: 0000000080000001 RSI: ffff88817ada8cb8 RDI: 00000000ffffffff <4> [108.207770] RBP: ffffffffa0341cc0 R08: ffff88816b5a8948 R09: 0000000000000000 <4> [108.207792] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82322d54 <4> [108.207814] R13: ffffffffa0341cc0 R14: ffffffff83df9568 R15: ffff88816064f400 <4> [108.207839] FS: 00007f437d753700(0000) GS:ffff88817ad80000(0000) knlGS:0000000000000000 <4> [108.207863] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [108.207887] CR2: 00007f2ad1fb5000 CR3: 00000001725d8004 CR4: 00000000003606e0 <4> [108.207907] Call Trace: <4> [108.207959] debug_object_assert_init+0x15c/0x180 <4> [108.208475] ? i915_active_acquire_if_busy+0x10/0x50 [i915] <4> [108.208513] ? rcu_read_lock_held+0x4d/0x60 <4> [108.208970] i915_active_acquire_if_busy+0x10/0x50 [i915] <4> [108.209380] intel_timeline_read_hwsp+0x81/0x540 [i915] <4> [108.210262] __emit_semaphore_wait+0x45/0x1b0 [i915] <4> [108.210726] ? i915_request_await_dma_fence+0x143/0x560 [i915] <4> [108.211156] i915_request_await_dma_fence+0x28a/0x560 [i915] <4> [108.211633] i915_request_await_object+0x24a/0x3f0 [i915] <4> [108.212102] eb_submit.isra.47+0x58f/0x920 [i915] <4> [108.212622] i915_gem_do_execbuffer+0x1706/0x2c70 [i915] <4> [108.213071] ? i915_gem_execbuffer2_ioctl+0xc0/0x470 [i915] Signed-off-by:
-
Anshuman Gupta authored
Few edp panels like Sharp is triggering short and long hpd pulse after panel is getting powered off. Currently driver is already ignoring long pulse for eDP panel but in order to process the short pulse, it turns on the VDD which requires panel power_cycle_delay + panel_power_on_delay these delay on Sharp panel introduced the responsiveness overhead of 800ms in the modeset sequence and as well is in suspend sequence. Ignoring any short pulse if panel is powered off. FIXME: It requires to wait for panel_power_off delay in order to check the panel power status due to pps_lock because panel triggers short pulse immediately after writing PP_OFF to PP_CTRL register and wait_panel_off waits for panel_power_off delay with pps_lock held. This still creates responsiveness overhead of panel_power_off delay. v2: - checking vdd along with panel power to ignore the hpd. [Jani,Ville] v3: - safer side check to ignore the long hpd when eDP have power, adding type of hpd to debug log. [Jani] Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200318081837.23983-1-anshuman.gupta@intel.com
-
- 22 Mar, 2020 3 commits
-
-
Chris Wilson authored
Don't override our previous frequency we used after parking, and avoid continually spiking back to the efficient frequency for mostly idle workloads. Trust our ability to autotune across a workload switch. Signed-off-by:
-
Chris Wilson authored
If we park/unpark faster than we can respond to RPS events, we never will process a downclock event after expiring a waitboost, and thus we will forever restart the GPU at max clocks even if the workload switches and doesn't justify full power. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1500 Fixes: 3e7abf81 ("drm/i915: Extract GT render power state management") Signed-off-by:
-
Chris Wilson authored
A silly cut'n'paste copied the unlocked error path and used it inside the pin_mutex lock, we need to drop that lock before returning. Fixes: b412c63f ("drm/i915/gt: Report context-is-closed prior to pinning") Signed-off-by:
-
- 20 Mar, 2020 6 commits
-
-
Chris Wilson authored
Our assertion caught that we do try to pin a closed context if userspace is viciously racing context-closure with execbuf, so make it fail gracefully. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1492Signed-off-by:
-
Ville Syrjälä authored
We only consider crtc_state->enable when initially calculating plane visibility. Later on we try to override the plane's state to invisible if the crtc is in DPMS off state (crtc_state->active==false). Unfortunately the code doing that only updates the plane_state.visible flag and the crtc_state.active_planes bimask, but forgets to update some of the other plane bitmasks stored in the crtc_state. Namely crtc_state.nv12_planes is left set up based on the original visibility check which makes icl_check_nv12_planes() pick a slave plane for the flagged plane in the bitmask. Later on we hit the watermark code which sees a plane with a slave assigned and it then makes the logical assumption that the master plane must itself be visible. Since the master's plane_state.visible flag was already cleared we get a WARN. Fix the problem by clearing all the plane bitmasks for DPMS off. This is more or less the wrong approach and instead we should calculate all the plane related state purely based crtc_state->enable (to guarantee that the subsequent DPMS on can't fail). However in the past we definitely had some roadblocks to making that happen. Not sure how many are left these days, but let's stick to the current approach since it's a much simpler fix to the immediate problem (the WARN). v2: Keep the visible=false, it's important (Rodrigo) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200318174515.31637-1-ville.syrjala@linux.intel.comReviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Gwan-gyeong Mun authored
It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by:Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
-
Gwan-gyeong Mun authored
It stores computed dp hdr metadata infoframe sdp to infoframes.drm of crtc state. It referenced intel_hdmi_compute_drm_infoframe(). While computing, we'll also fill out the infoframes.enable bitmask appropriately. v2: Wrap a long line. v4: Use struct drm_device logging macros v5: Fix typo [Uma] Signed-off-by:
-
Gwan-gyeong Mun authored
In order to support state readout for DP VSC SDP, we need to have a structure which holds DP VSC SDP payload data such as "union hdmi_infoframe drm" which is used for DRM infoframe. It adds a struct drm_dp_vsc_sdp vsc to intel_crtc_state.infoframes. And it stores computed dp vsc sdp to infoframes.vsc of crtc state. While computing we'll also fill out the inforames.enable bitmask appropriately. The compute routine follows DP 1.4 spec [Table 2-117: VSC SDP Payload for DB16 through DB18]. v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp v5: - Rebased - Add warning where a bpc is 6 and a pixel format is RGB. v7: Fix the wrong check of combination bpc 6 and RGB pixelformat Signed-off-by:
-
Gwan-gyeong Mun authored
It adds new enumeration definitions for VSC SDP Payload for Pixel Encoding/Colorimetry Format. And it adds a new drm data structure for DP VSC SDP. enum dp_colorspace and enum dp_colorimetry correspond "Pixel Encoding and Colorimetry Formats". enum dp_dynamic_range corresponds "Dynamic Range". And enum dp_content_type corresponds "Content Type" All of them are based on DP 1.4 spec [Table 2-117: VSC SDP Payload for DB16 through DB18]. v3: Add a new drm data structure for DP VSC SDP v5: Addressed review comments from Uma - Add kernel docs for added data structures - Rename enum dp_colorspace to dp_pixelformat - Polish commit message - Fix typos - Drop self-explanatory comments Signed-off-by:Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
- 19 Mar, 2020 11 commits
-
-
Chris Wilson authored
Use the restored ability to check if a context is closed to decide whether or not to immediately ban the context from further execution after a hang. Fixes: be90e344 ("drm/i915/gt: Cancel banned contexts after GT reset") Signed-off-by:
-
Chris Wilson authored
I need to keep the GEM context around a bit longer so adding an explicit flag for syncing execbuf with closed/abandonded contexts. v2: * Use already available context flags. (Chris) Signed-off-by:
-
Chris Wilson authored
%pS includes the offset, which is useful for return addresses but noise when we are pretty printing a known (and expected) function entry point. Signed-off-by:
-
Wambui Karuga authored
Replace the use of printk based drm logging macros with the struct drm_device based logging macros. Note that this converts DRM_DEBUG_DRIVER() to drm_dbg(). References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by:
Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by:
-
Wambui Karuga authored
Replace the use of the printk based drm logging macros with the struct drm_device based logging macros in i915/gt/intel_rps.c. This also involves extracting the drm_i915_private device pointer from various intel types. This converts the instances of DRM_DEBUG_DRIVER to drm_dbg() while not converting DRM_DEBUG() instances due to the lack of an analogous drm_device based macro. References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by:
-
Wambui Karuga authored
Replace the use of printk based drm logging macros to the struct drm_device based logging macros in i915/gt/intel_ring_submission.c. This was done using the following semantic patch that transforms based on the existence of a drm_i915_private device: @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } New checkpatch warnings were fixed manually. Note that this converts DRM_DEBUG_DRIVER to drm_dbg(). References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by: -
Wambui Karuga authored
Replace the use of the printk based drm logging macros with the struct drm_device based logging macros. Signed-off-by:
-
Wambui Karuga authored
Converts various instances of the printk based drm logging macros to use the struct drm_device logging macros. This also involves extracting the drm_i915_private device from intel types in some cases. Note that this converts DRM_DEBUG_DRIVER() to drm_dbg(). References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by:
-
Wambui Karuga authored
Convert various instances of the printk based drm logging macros to the struct drm_device based logging macros. Note that this converts DRM_DEBUG_DRIVER() to drm_dbg() but does not convert DRM_DEBUG() due to the lack of an analogous drm_device based macro. References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by:
-
Wambui Karuga authored
Converts various instances of the printk based drm logging macros to use the struct drm_device based logging macros in i915/gt/intel_ggtt.c. This change was done using the following coccinelle script that matches based on the existence of a drm_i915_private device: @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } New checkpatch warnings were fixed manually. Note that this converts DRM_DEBUG_DRIVER to drm_dbg() References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by: -
Swathi Dhanavanthri authored
Adding 4 new PCI IDs to TGL Bspec: 44455 Signed-off-by:
Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200318221240.8180-1-swathi.dhanavanthri@intel.comReviewed-by:
-
- 18 Mar, 2020 4 commits
-
-
Mario Kleiner authored
This fixes a problem found on the MacBookPro 2017 Retina panel. The panel reports 10 bpc color depth in its EDID, and the firmware chooses link settings at boot which support enough bandwidth for 10 bpc (324000 kbit/sec = multiplier 0xc), but the DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps (multiplier value 0xa) as possible, in direct contradiction of what the firmware successfully set up. This restricts the panel to 8 bpc, not providing the full color depth of the panel. This patch adds a quirk specific to the MBP 2017 15" Retina panel to add the additiional 324000 kbps link rate during edp setup. Link to previous discussion of a different attempted fix with Ville and Jani: https://patchwork.kernel.org/patch/11325935/ v2: Follow Jani's proposal of defining quirk_rates[] instead of just appending 324000. This for better clarity. v3: Rebased onto current drm-tip, as of 16-March-2020. Adapt to new edid_quirks parameter of drm_dp_has_quirk(). Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by:
-
Wambui Karuga authored
Converts various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_hdcp.c. This also involves extracting the drm_i915_private device from the intel_connector type for use in the macros. v2 by Jani: - rebase Signed-off-by:
-
Wambui Karuga authored
Convert various instances of printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_fbdev.c. This also involves extracting the drm_i915_private device from various intel types. v2 by Jani: - fix the final one too Signed-off-by:
-
Wambui Karuga authored
This replaces the uses of the printk based drm logging macros with the struct drm_device based logging macros in i915/display/intel_fbc.c. This transformation was done using the following coccinelle semantic patch that matches based on the existence of a drm_i915_private device pointer: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } New checkpatch warnings were addressed manually. v2 by Jani: - also convert pr_info_once to drm based logging Signed-off-by:
-
