- 06 Mar, 2018 8 commits
-
-
Changbin Du authored
GTT entry has similar format with the CPU PTE. We'd prefer named macro instead of hardcode. Signed-off-by:
Changbin Du <changbin.du@intel.com> Reviewed-by:
Zhi Wang <zhi.a.wang@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com>
-
Changbin Du authored
Factor out these two interfaces so we can kill some duplicated code in scheduler.c. v2: - rename to intel_vgpu_{get,put}_ppgtt_mm - refine handle_g2v_notification Signed-off-by: -
Changbin Du authored
Accurate names help to avoid confusing so improve readability. Signed-off-by:
-
Changbin Du authored
This add a new macro gvt_vdbg_mm() to print more verbose logs for gtt shadowing. The added verbose logs are very useful for debugging. gvt_vdbg_mm() only comes into effect if VERBOSE_DEBUG is defined by the developer. Signed-off-by:
-
Changbin Du authored
Less code and use existed helper ggtt_set_host_entry. Signed-off-by:
-
Changbin Du authored
Separate ggtt and ppgtt since they are different. A little more code but straightforward. And move these helpers to gtt.c since that is the only client. Signed-off-by:
-
Changbin Du authored
If we manage an object with a reference count, then its life cycle must flow the reference count operations. Meanwhile, change the operation functions to generic name *put* and *get*. Signed-off-by:
-
Changbin Du authored
This is a big one and the GVT shadow graphic memory management code is heavily refined. The new code is more straightforward with less code. The struct intel_vgpu_mm is restructured to be clearly defined, use accurate names and some of the original fields are removed which are really redundant. Now we only manage ppgtt mm object with mm->ppgtt_mm.lru_list. No need to mix ppgtt and ggtt together, since one vGPU only has one ggtt object. v4: Don't invoke ppgtt_free_all_shadow_page before intel_vgpu_destroy_all_ppgtt_mm. v3: Add GVT_RING_CTX_NR_PDPS to avoid confusing about the PDPs. v2: Split some changes into small standalone patches. Signed-off-by:
-
- 05 Mar, 2018 1 commit
-
-
Joonas Lahtinen authored
Signed-off-by:Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 02 Mar, 2018 12 commits
-
-
Michal Wajdeczko authored
If we fail to authenticate HuC firmware, we should change its load status to FAIL. While around, print HUC_STATUS on firmware verification failure. v2: keep the variables sorted by length (Chris) Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Michal Wajdeczko authored
We want to use higher level 'uc' functions as the main entry points to the GuC/HuC code to hide some details and keep code layered. While here, move call to disable_guc_interrupts after sending suspend action to the GuC to allow it work also with CTB as comm mechanism. v2: update commit msg (Sagar) Signed-off-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
-
Chris Wilson authored
During reset/wedging, we have to clean up the requests on the timeline and flush the pending interrupt state. Currently, we are abusing the irq disabling of the timeline spinlock to protect the irq state in conjunction to the engine's timeline requests, but this is accidental and conflates the spinlock with the irq state. A baffling state of affairs for the reader. Instead, explicitly disable irqs over the critical section, and separate modifying the irq state from the timeline's requests. Suggested-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
Although this state (execlists->active and engine->irq_posted) itself is not protected by the engine->timeline spinlock, it does conveniently ensure that irqs are disabled. We can use this to protect our manipulation of the state and so ensure that the next IRQ to arrive sees consistent state and (hopefully) ignores the reset engine. Suggested-by:
-
Chris Wilson authored
After staring hard at sequences like [ 28.199013] systemd-1 2..s. 26062228us : execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?] [ 28.199095] systemd-1 2..s. 26062229us : execlists_submission_tasklet: rcs0 csb[1]: status=0x00000018:0x00000000, active=0x1 [ 28.199177] systemd-1 2..s. 26062230us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024 [ 28.199258] systemd-1 2..s. 26062231us : execlists_submission_tasklet: rcs0 completed ctx=0 [ 28.199340] gem_eio-829 1..s1 26066853us : execlists_submission_tasklet: rcs0 in[0]: ctx=1.1, seqno=1, prio=0 [ 28.199421] <idle>-0 2..s. 26066863us : execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?] [ 28.199503] <idle>-0 2..s. 26066865us : execlists_submission_tasklet: rcs0 csb[2]: status=0x00000001:0x00000000, active=0x1 [ 28.199585] gem_eio-829 1..s1 26067077us : execlists_submission_tasklet: rcs0 in[1]: ctx=3.1, seqno=2, prio=0 [ 28.199667] gem_eio-829 1..s1 26067078us : execlists_submission_tasklet: rcs0 in[0]: ctx=1.2, seqno=1, prio=0 [ 28.199749] <idle>-0 2..s. 26067084us : execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?] [ 28.199830] <idle>-0 2..s. 26067085us : execlists_submission_tasklet: rcs0 csb[3]: status=0x00008002:0x00000001, active=0x1 [ 28.199912] <idle>-0 2..s. 26067086us : execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0 [ 28.199994] gem_eio-829 2..s. 28246084us : execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?] [ 28.200096] gem_eio-829 2..s. 28246088us : execlists_submission_tasklet: rcs0 csb[4]: status=0x00000014:0x00000001, active=0x5 [ 28.200178] gem_eio-829 2..s. 28246089us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0 [ 28.200260] gem_eio-829 2..s. 28246127us : execlists_submission_tasklet: execlists_submission_tasklet:886 GEM_BUG_ON(buf[2 * head + 1] != port->context_id) the conclusion is that the only place where the ports are reset to zero, is from engine->cancel_requests called during i915_gem_set_wedged(). The race is horrible as it results from calling set-wedged on active HW (the GPU reset failed) and as such we need to be careful as the HW state changes beneath us. Fortunately, it's the same scary conditions as affect normal reset, so we can reuse the same machinery to disable state tracking as we clobber it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945Signed-off-by:
-
Ville Syrjälä authored
We have two instances of the code to fill out the header for the aux message. Pull it into a small helper. v2: Rebase due to txbuf[] changes Cc: Sean Paul <seanpaul@chromium.org> Cc: Ramalingam C <ramalingam.c@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180222212802.4826-1-ville.syrjala@linux.intel.comReviewed-by:
Ramalingam C <ramalingam.c@intel.com>
-
Ville Syrjälä authored
Let's try to keep the details on the AKSV stuff concentrated in one place. So move the control bit and +5 data size handling there. v2: Increase txbuf[] to include the payload which intel_dp_aux_xfer() will still load into the registers even though the hardware will ignore it Cc: Sean Paul <seanpaul@chromium.org> Cc: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: -
Ville Syrjälä authored
Rename intel_dp_aux_ch() to intel_dp_aux_xfer() to better convey what it actually does. Signed-off-by:
-
Imre Deak authored
Enabling FBC on a plane having a Y-offset that isn't divisible by 4 may cause pipe FIFO underruns and flickers, so disable FBC on such a config. I tried the followings to work around the issue: - enable each HW work around in ILK_DPFC_CHICKEN - disable each compression algorithm in ILK_DPFC_CONTROL - disable low-power watermarks None of the above got rid of the problem. I haven't found this issue in the Bspec/WA database either. Besides the igt testcase below (yet to be merged) an easy way to reproduce the issue is to enable a plane with FBC and a plane Y-offset not aligned to 4 and then just enable/disable FBC in a loop, keeping the plane enabled. I could trigger the problem on BXT/GLK/SKL/CNL, so assume for now that it's only present on GEN9 and GEN10. v2: (Ville) - Run the test/apply the WA on CNL as well. - Use IS_GEN() instead of INTEL_GEN(). - Fix spelling. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Testcase: igt/kms_plane/plane-clipping-pipe-A-planes Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
In decimal its just a weird big number, while in hex can actually log which engines were requested to be wedged. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
-
Sagar Arun Kamble authored
GuC load function is named intel_guc_fw_upload() and HuC load function is named intel_huc_init_hw(). Make them consistent intel_*_fw_upload. Also move HuC fw loading functions and declarations to separate files intel_huc_fw.c|h like GuC. While at this, do below changes 1. Update kernel-doc comment for intel_*_fw_upload() functions 2. s/huc_ucode_xfer/huc_fw_xfer 3. Introduce intel_huc_fw_init_early() v2: Changed patch to update HuC functions instead of changing guc_fw_upload and update file structure. (Michal Wajdeczko) v3: Added SPDX License identifier to huc_fw.c|h. (Michal Wajdeczko) Signed-off-by: -
Maarten Lankhorst authored
Moving the check upwards will mean we we no longer have to add planes and connectors manually, because everything is handled correctly by drm_atomic_helper_check_modeset() as intended. [applied with whitespace changes to make sparse happy] Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
- 01 Mar, 2018 8 commits
-
-
Chris Wilson authored
Now that we can pass arbitrary commands into the base __wait_for() macro, we can reimplement the open-coded wait-for inside i915_gem_idle_work_handler() using the new macro. This means that instead of using ktime, we now use jiffies, and benefit from the exponential sleep backoff that allows a fast response if the HW settles quickly. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180301103338.5380-1-chris@chris-wilson.co.uk
-
Lionel Landwerlin authored
We're seeing on CI that some contexts don't have the programmed OA period timer that directs the OA unit on how often to write reports. The issue is that we're not holding the drm lock from when we edit the context images down to when we set the exclusive_stream variable. This leaves a window for the deferred context allocation to call i915_oa_init_reg_state() that will not program the expected OA timer value, because we haven't set the exclusive_stream yet. v2: Drop need_lock from gen8_configure_all_contexts() (Matt) Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
-
Mika Kuoppala authored
v2: Rebase. v3: * Remove DPF, it has been removed from SKL+. * Fix -internal rebase wrt. execlists interrupt handling. v4: Rebase. v5: * Updated for POR changes. (Daniele Ceraolo Spurio) * Merged with irq handling fixes by Daniele Ceraolo Spurio: * Simplify the code by using gen8_cs_irq_handler. * Fix interrupt handling for the upstream kernel. v6: * Remove early bringup debug messages (Tvrtko) * Add NB about arbitrary spin wait timeout (Tvrtko) v7 (from Paulo): * Don't try to write RO bits to registers. * Don't check for PCH types that don't exist. PCH interrupts are not here yet. v9: * squashed in selector and shared register handling (Daniele) * skip writing of irq if data is not valid (Daniele) * use time_after32 (Chris) * use I915_MAX_VCS and I915_MAX_VECS (Daniele) * remove fake pm interrupt handling for later patch (Mika) v10: * Direct processing of banks. clear banks early (Chris) * remove poll on valid bit, only clear valid bit (Mika) * use raw accessors, better naming (Chris) v11: * adapt to raw_reg_[read|write] * bring back polling the valid bit (Daniele) v12: * continue if unset intr_dw (Daniele) * comment the usage of gen8_de_irq_handler bits (Daniele) Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
Gen11 will add more VCS and VECS rings so prepare the infrastructure to support that. Bspec: 7021 v2: Rebase. v3: Rebase. v4: Rebase. v5: Rebase. v6: - Update for POR changes. (Daniele Ceraolo Spurio) - Add provisional guc engine ids - to be checked and confirmed. v7: - Rebased. - Added the new ring masks. - Added the new HW ids. v8: - Introduce I915_MAX_VCS/VECS to avoid magic numbers (Michal) v9: increase MAX_ENGINE_INSTANCE to 3 Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Joonas Lahtinen authored
To pull in the HDCP changes, especially wait_for changes to drm/i915 that Chris wants to build on top of. Signed-off-by: -
Manasi Navare authored
dp_rates[] array is a superset of all the link rates supported by sink devices. DP 1.3 specification adds HBR3 (8.1Gbps) link rate to the set of link rates supported by sink. This patch adds this rate to dp_rates[] array that gets used to populate the sink_rates[] array limited by max rate obtained from DP_MAX_LINK_RATE DPCD register. v2: * Rebased on top of Jani's localized rates patch Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1519857110-26916-1-git-send-email-manasi.d.navare@intel.com
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
Driver Changes: - Lift alpha_support protection from Cannonlake (Rodrigo) * Meaning the driver should mostly work for the hardware we had at our disposal when testing * Used to be preliminary_hw_support - Add missing Cannonlake PCI device ID of 0x5A4C (Rodrigo) - Cannonlake port register fix (Mahesh) - Fix Dell Venue 8 Pro black screen after modeset (Hans) - Fix for always returning zero out-fence from execbuf (Daniele) - Fix HDMI audio when no no relevant video output is active (Jani) - Fix memleak of VBT data on driver_unload (Hans) - Fix for KASAN found locking issue (Maarten) - RCU barrier consolidation to improve igt/gem_sync/idle (Chris) - Optimizations to IRQ handlers (Chris) - vblank tracking improvements (64-bit resolution, PM) (Dhinakaran) - Pipe select bit corrections (Ville) - Reduce runtime computed device_info fields (Chris) - Tune down some WARN_ONs to GEM_BUG_ON now that CI has good coverage (Chris) - A bunch of kerneldoc warning fixes (Chris) * tag 'drm-intel-next-2018-02-21' of git://anongit.freedesktop.org/drm/drm-intel: (113 commits) drm/i915: Update DRIVER_DATE to 20180221 drm/i915/fbc: Use PLANE_HAS_FENCE to determine if the plane is fenced drm/i915/fbdev: Use the PLANE_HAS_FENCE flags from the time of pinning drm/i915: Move the policy for placement of the GGTT vma into the caller drm/i915: Also check view->type for a normal GGTT view drm/i915: Drop WaDoubleCursorLP3Latency:ivb drm/i915: Set the primary plane pipe select bits on gen4 drm/i915: Don't set cursor pipe select bits on g4x+ drm/i915: Assert that we don't overflow frontbuffer tracking bits drm/i915: Track number of pending freed objects drm/i915/: Initialise trans_min for skl_compute_transition_wm() drm/i915: Clear the in-use marker on execbuf failure drm/i915: Prune gen8_gt_irq_handler drm/i915: Track GT interrupt handling using the master iir drm/i915: Remove WARN_ONCE for failing to pm_runtime_if_in_use drm: intel_dpio_phy: fix kernel-doc comments at nested struct drm/i915: Release connector iterator on a digital port conflict. drm/i915/execlists: Remove too early assert drm/i915: Assert that we always complete a submission to guc/execlists drm: move read_domains and write_domain into i915 ...
-
https://github.com/jsarha/linuxDave Airlie authored
drm/tilcdc changes to v4.17 * tag 'tilcdc-4.17' of https://github.com/jsarha/linux: drm/tilcdc: tilcdc_panel: Rename device from "panel" to "tilcdc-panel" drm/tilcdc: Add support for drm panels drm/tilcdc: panel: Use common error handling code in of_get_panel_info() drm/tilcdc: Delete an error message for a failed memory allocation in seven functions
-
- 28 Feb, 2018 11 commits
-
-
Jani Nikula authored
Localize link rate arrays by moving them to the functions where they're used. Further clarify the distinction between source and sink capabilities. Split pre and post Haswell arrays, and get rid of the array size arithmetics. Use a direct rate value in the paranoia case of no common rates find. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
While it seems totally unlikely that any system would mix a cpu/north aux channel with a pch/south port (or vice versa) we should still consult intel_dp->aux_ch rather than encoder->port when figuring out which clock is actually used by the aux ch. Signed-off-by:
-
Chris Wilson authored
Although we protect the request itself, we don't lock inside intel_engine_dump() and so the request maybe retired as we peek into it. One consequence is that the request->ctx may be freed before we dereference it, leading to a use-after-free. Replace the hw_id we are peeking from inside request->ctx with the request->fence.context, with which we can still track from which context the request originated (although to tie to HW reports requires a little more legwork, but is good enough to follow the GEM traces). [52640.729670] general protection fault: 0000 [#2] SMP [52640.729694] Dumping ftrace buffer: [52640.729701] (ftrace buffer empty) [52640.729705] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_\ temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul snd_hda_intel snd_hda_codec snd_hwdep gha\ sh_clmulni_intel snd_hda_core snd_pcm mei_me mei i915 r8169 mii prime_numbers i2c_hid [52640.729748] CPU: 2 PID: 4335 Comm: gem_exec_schedu Tainted: G UD W 4.16.0-rc3+ #7 [52640.729759] Hardware name: Acer Aspire E5-575G/Ironman_SK , BIOS V1.12 08/02/2016 [52640.729803] RIP: 0010:print_request+0x2b/0xb0 [i915] [52640.729811] RSP: 0018:ffffc90001453c18 EFLAGS: 00010206 [52640.729820] RAX: 6b6b6b6b6b6b6b6b RBX: ffff8801e0292d40 RCX: 0000000000000006 [52640.729829] RDX: ffffc90001453c60 RSI: ffff8801e0292d40 RDI: 0000000000000003 [52640.729838] RBP: ffffc90001453d80 R08: 0000000000000000 R09: 0000000000000001 [52640.729847] R10: ffffc90001453bd0 R11: ffffc90001453c73 R12: ffffc90001453c60 [52640.729856] R13: ffffc90001453d80 R14: ffff8801d5a683c8 R15: ffff8801e0292d40 [52640.729866] FS: 00007f1ee50548c0(0000) GS:ffff8801e8200000(0000) knlGS:0000000000000000 [52640.729876] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [52640.729884] CR2: 00007f1ee5077000 CR3: 00000001d9411004 CR4: 00000000003606e0 [52640.729893] Call Trace: [52640.729922] intel_engine_print_registers+0x623/0x890 [i915] [52640.729948] intel_engine_dump+0x4a3/0x590 [i915] [52640.729957] ? seq_printf+0x3a/0x50 [52640.729977] i915_engine_info+0xb8/0xe0 [i915] [52640.729984] ? drm_mode_gamma_get_ioctl+0xf0/0xf0 [52640.729990] seq_read+0xd5/0x410 [52640.729997] full_proxy_read+0x4b/0x70 [52640.730004] __vfs_read+0x1e/0x120 [52640.730009] ? do_sys_open+0x134/0x220 [52640.730015] ? kmem_cache_free+0x174/0x2b0 [52640.730021] vfs_read+0xa1/0x150 [52640.730026] SyS_read+0x40/0xa0 [52640.730032] do_syscall_64+0x65/0x1a0 [52640.730038] entry_SYSCALL_64_after_hwframe+0x42/0xb7 Reported-by:
-
Ville Syrjälä authored
On pre-HSW we have dedicated hardware for the RGB limited range handling, and so we don't want to compress with the CSC matrix. Toss in a FIXME about gamma LUT vs. limited range using the CSC. Cc: Johnson Lin <johnson.lin@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com>
-
Ville Syrjälä authored
The pipe CSC was introduced by ILK, so change everything related to use ilk_ as the prefix. Cc: Johnson Lin <johnson.lin@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
-
Ville Syrjälä authored
If we don't have to frob with the user provided ctm matrix there's no point in copying it over. Just point at the user ctm directly. Also the matrix gets fully populated by ctm_mult_by_limited() so no need to zero initialize it. Cc: Johnson Lin <johnson.lin@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
-
Joonas Lahtinen authored
To pull in the HDCP changes, especially wait_for changes to drm/i915 that Chris wants to build on top of. Signed-off-by: -
Jyri Sarha authored
Rename the bundled tilcdc_panel driver from just "panel" to "tilcdc-panel" to avoid noisy error messages from the driver trying to probe all device nodes named "panel". Signed-off-by:
Jyri Sarha <jsarha@ti.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Jyri Sarha authored
Add support for drm panels to tilcdc. Adding the support on top of the existing bridge support needs only couple of lines of code when using using the drm panel bridge helpers. Signed-off-by:
-
Mustamin B Mustaffa authored
Currently, BXT_PP is hardcoded with value '0'. It practically disabled eDP backlight on MRB (BXT) platform. This patch will tell which BXT_PP registers (there are two set of PP_CONTROL in the spec) to be used as defined in VBT (Video Bios Timing table) and this will enabled eDP backlight controller on MRB (BXT) platform. v2: - Remove unnecessary information in commit message. - Assign vbt.backlight.controller to a backlight_controller variable and return the variable value. v3: - Rebased to latest code base. - updated commit title. Signed-off-by:
Mustamin B Mustaffa <mustamin.b.mustaffa@intel.com> Signed-off-by:
-
Chris Wilson authored
As the ftrace log is overflowing the pstore capture, we lose the last gasps from dmesg which includes the GEM_BUG_ON function:line and condition that failed. Vital information for tracking down the bug, so append it to the frace log as well. Signed-off-by:
-
