aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2020-01-20drm/i915: Align engine->uabi_class/instance with i915_drm.hTvrtko Ursulin2-8/+8
In our ABI we have defined I915_ENGINE_CLASS_INVALID_NONE and I915_ENGINE_CLASS_INVALID_VIRTUAL as negative values which creates implicit coupling with type widths used in, also ABI, struct i915_engine_class_instance. One place where we export engine->uabi_class I915_ENGINE_CLASS_INVALID_VIRTUAL is from our our tracepoints. Because the type of the former is u8 in contrast to u16 defined in the ABI, 254 will be returned instead of 65534 which userspace would legitimately expect. Another place is I915_CONTEXT_PARAM_ENGINES. Therefore we need to align the type used to store engine ABI class and instance. v2: * Update the commit message mentioning get_engines and cc stable. (Chris) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: <stable@vger.kernel.org> # v5.3+ Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200116134508.25211-1-tvrtko.ursulin@linux.intel.com
2020-01-20drm/i915/gvt: remove unused vblank_done completionJulian Stecklina2-4/+0
This variable is used nowhere, so remove it. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Julian Stecklina <julian.stecklina@cyberus-technology.de> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200109171357.115936-3-julian.stecklina@cyberus-technology.de
2020-01-20drm/i915/gvt: Enable vfio edid for all GVT supported platformZhenyu Wang1-3/+1
All GVT supported platform has virtual display which should be able to handle VFIO edid region. Enable this for all supported platform. Cc: Hang Yuan <hang.yuan@linux.intel.com> Cc: Fred Gao <fred.gao@intel.com> Reviewed-by: Hang Yuan <hang.yuan@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20191202070109.73924-3-zhenyuw@linux.intel.com
2020-01-20Merge tag 'drm-msm-next-2020-01-14' of https://gitlab.freedesktop.org/drm/msm into drm-nextDave Airlie48-425/+1039
+ sc7180 display + DSI support + a618 (sc7180) support + more UBWC (bandwidth compression) support + various cleanups to handle devices that use vs don't use zap fw, etc + usual random cleanups and fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/ <CAF6AEGvv03ifuP0tp7-dmqZtr1iS=s8Vc=az8BNGtEoSMD-dkw@mail.gmail.com
2020-01-20Backmerge v5.5-rc7 into drm-nextDave Airlie17-47/+224
msm needs 5.5-rc4, go to the latest. Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-01-19drm: tiny: st7735r: Add support for Okaya RH128128TGeert Uytterhoeven2-4/+13
Add support for the Okaya RH128128T display to the st7735r driver on DT-enabled systems. The RH128128T is a 128x128 1.44" TFT display driven by a Sitronix ST7715R TFT Controller/Driver. The latter is very similar to the ST7735R, and can be handled by the existing st7735r driver. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200115124548.3951-6-geert+renesas@glider.be
2020-01-19drm: tiny: st7735r: Prepare for adding support for more displaysGeert Uytterhoeven1-14/+53
Currently the st7735r driver supports only a single display panel. Prepare for adding support for other display panels by factoring out the display-specific parameters in struct st7735r_cfg. For now, the following parameters can be configured: - Display resolution, - Horizontal/vertical display offsets, - Read-write versus read-only controllers, - RGB versus BGR color component ordering. Rename jd_t18003_t01_pipe_enable() and jd_t18003_t01_pipe_funcs() to st7735r_pipe_enable() resp. st7735r_pipe_funcs(), as they are not really specific to the Jianda JD-T18003-T01 display anymore. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200115124548.3951-5-geert+renesas@glider.be
2020-01-19drm/mipi_dbi: Add support for display offsetsGeert Uytterhoeven1-10/+20
If the resolution of the TFT display is smaller than the maximum resolution supported by the display controller, the display may be connected to the driver output arrays with a horizontal and/or vertical offset, leading to a shifted image. Add support for specifying these offsets. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200115124548.3951-4-geert+renesas@glider.be
2020-01-18Merge tag 'drm-fixes-2020-01-19' of git://anongit.freedesktop.org/drm/drmLinus Torvalds9-17/+88
Pull drm fixes from Dave Airlie: "Back from LCA2020, fixes wasn't too busy last week, seems to have quieten down appropriately, some amdgpu, i915, then a core mst fix and one fix for virtio-gpu and one for rockchip: core mst: - serialize down messages and clear timeslots are on unplug amdgpu: - Update golden settings for renoir - eDP fix i915: - uAPI fix: Remove dash and colon from PMU names to comply with tools/perf - Fix for include file that was indirectly included - Two fixes to make sure VMA are marked active for error capture virtio: - maintain obj reservation lock when submitting cmds rockchip: - increase link rate var size to accommodate rates" * tag 'drm-fixes-2020-01-19' of git://anongit.freedesktop.org/drm/drm: drm/amd/display: Reorder detect_edp_sink_caps before link settings read. drm/amdgpu: update goldensetting for renoir drm/dp_mst: Have DP_Tx send one msg at a time drm/dp_mst: clear time slots for ports invalid drm/i915/pmu: Do not use colons or dashes in PMU names drm/rockchip: fix integer type used for storing dp data rate drm/i915/gt: Mark ring->vma as active while pinned drm/i915/gt: Mark context->state vma as active while pinned drm/i915/gt: Skip trying to unbind in restore_ggtt_mappings drm/i915: Add missing include file <linux/math64.h> drm/virtio: add missing virtio_gpu_array_lock_resv call
2020-01-18drm: fix parameters documentation style in drm_dmaBenjamin Gaignard1-10/+11
Remove old documentation style and use new one to avoid warnings when compiling with W=1 Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200114160135.14990-1-benjamin.gaignard@st.com
2020-01-18drm/i915/gt: Be paranoid and reset the GPU before releaseChris Wilson1-0/+16
Just in the very unlikely case we have not stopped the GPU before we return the pages being used by the GPU to the system, force a reset. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200117180309.3249427-1-chris@chris-wilson.co.uk
2020-01-18Merge tag 'amd-drm-next-5.6-2020-01-17' of git://people.freedesktop.org/~agd5f/linux into drm-nextDave Airlie140-1771/+4549
amd-drm-next-5.6-2020-01-17: amdgpu: - Fix 32 bit harder - Powerplay cleanups - VCN fixes for Arcturus - RAS fixes - eDP/DP fixes - SR-IOV fixes - Re-enable S/G display for PCO/RV2 - Free stolen memory after init on gmc10 - DF hashing optimizations for Arcturus - Properly handle runtime pm in sysfs and debugfs - Unify more GC programming between amdgpu and amdkfd - Golden settings updates for gfx10 - GDDR6 training fixes - Freesync fixes - DSC fixes - TMDS fixes - Renoir USB-C fixes - DC dml updates from hw team - Pollock support - Mutex init regresson fix amdkfd: - Unify more GC programming between amdgpu and amdkfd - Use KIQ to setup HIQ rather than using MMIO scheduler: - Documentation fixes - Improve job distribution with load sharing drm: - DP MST fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200117213625.4722-1-alexander.deucher@amd.com
2020-01-18Merge tag 'drm-misc-fixes-2020-01-16' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixesDave Airlie3-4/+38
virtio: maintain obj reservation lock when submitting cmds (Gerd) rockchip: increase link rate var size to accommodate rates (Tobias) mst: serialize down messages and clear timeslots are on unplug (Wayne) Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Tobias Schramm <t.schramm@manjaro.org> Cc: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200116162856.GA11524@art_vandelay
2020-01-18Merge tag 'drm-intel-fixes-2020-01-16' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixesDave Airlie4-11/+48
- uAPI fix: Remove dash and colon from PMU names to comply with tools/perf - Fix for include file that was indirectly included - Two fixes to make sure VMA are marked active for error capture Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116161419.GA13594@jlahtine-desk.ger.corp.intel.com
2020-01-17drm/dp_mst: Handle SST-only branch device caseWayne Lin1-60/+80
[Why] While handling LINK_ADDRESS reply, current code expects a peer device can handle sideband message once the peer device type is reported as DP_PEER_DEVICE_MST_BRANCHING. However, when the connected device is a SST branch case, it can't handle the sideband message(MST_CAP=0 in DPCD 00021h). Current code will try to send LINK_ADDRESS to SST branch device and end up with message timeout and monitor can't display normally. As the result of that, we should take SST branch device into account. [How] According to DP 1.4 spec, we can use Peer_Device_Type as DP_PEER_DEVICE_MST_BRANCHING and Message_Capability_Status as 0 to indicate peer device as a SST-only branch device. Fix following: - Add the function drm_dp_mst_is_dp_mst_end_device() to decide whether a peer device connected to a DFP is mst end device. Which also indicates if the peer device is capable of handling message or not. - Take SST-only branch device case into account in drm_dp_port_set_pdt() and add a new parameter 'new_mcs'. Take sst branch device case as the same case as DP_PEER_DEVICE_DP_LEGACY_CONV and DP_PEER_DEVICE_SST_SINK. All original handling logics remain. - Take SST-only branch device case into account in drm_dp_mst_port_add_connector(). - Fix some parts in drm_dp_mst_handle_link_address_port() to have SST branch device case into consideration. - Fix the arguments of drm_dp_port_set_pdt() in drm_dp_mst_handle_conn_stat(). - Have SST branch device also report connector_status_connected when the ddps is true in drm_dp_mst_detect_port() - Fix the arguments of drm_dp_port_set_pdt() in drm_dp_delayed_destroy_port() Changes since v1:(https://patchwork.kernel.org/patch/11323079/) * Squash previous patch into one patch and merge the commit message here. * Combine the if statements mentioned in comments Fixes: c485e2c97dae ("drm/dp_mst: Refactor pdt setup/teardown, add more locking") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Lyude Paul <lyude@redhat.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200117060350.26358-2-Wayne.Lin@amd.com
2020-01-17drm/mst: Some style improvements in drm_dp_mst_topology_mgr_set_mst()José Roberto de Souza1-8/+6
Removing this lose code block and removing unnecessary bracket. Cc: Lyude Paul <lyude@redhat.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200117015837.402239-2-jose.souza@intel.com
2020-01-17drm/mst: Don't do atomic checks over disabled managersJosé Roberto de Souza1-0/+3
When a main MST port is disconnected drivers should call drm_dp_mst_topology_mgr_set_mst() disabling the MST manager, this function will set manager mst_primary to NULL and it will cause the crash bellow on the next atomic check when trying to access mst_primary->port. As there is no use in running checks over managers that are not active this patch will skip it. [ 305.616450] [drm:drm_dp_mst_atomic_check] [MST PORT:00000000cc2049e9] releases all VCPI slots [ 305.625085] [drm:drm_dp_mst_atomic_check] [MST PORT:00000000020ab43e] releases all VCPI slots [ 305.633729] [drm:drm_dp_mst_atomic_check] [MST MGR:00000000cdd467d4] mst state 00000000b67672eb VCPI avail=63 used=0 [ 305.644405] BUG: kernel NULL pointer dereference, address: 0000000000000030 [ 305.651448] #PF: supervisor read access in kernel mode [ 305.656640] #PF: error_code(0x0000) - not-present page [ 305.661807] PGD 0 P4D 0 [ 305.664396] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 305.668789] CPU: 3 PID: 183 Comm: kworker/3:2 Not tainted 5.5.0-rc6+ #1404 [ 305.675703] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3201.A00.1905140358 05/14/2019 [ 305.689425] Workqueue: events drm_dp_delayed_destroy_work [ 305.694874] RIP: 0010:drm_dp_mst_atomic_check+0x138/0x2c0 [ 305.700306] Code: 00 00 00 41 29 d9 41 89 d8 4c 89 fa 4c 89 f1 48 c7 c6 b0 b1 34 82 bf 10 00 00 00 45 31 ed e8 3f 99 02 00 4d 8b bf 80 04 00 00 <49> 8b 47 30 49 8d 5f 30 4c 8d 60 e8 48 39 c3 74 35 49 8b 7c 24 28 [ 305.719169] RSP: 0018:ffffc90001687b58 EFLAGS: 00010246 [ 305.724434] RAX: 0000000000000000 RBX: 000000000000003f RCX: 0000000000000000 [ 305.731611] RDX: 0000000000000000 RSI: ffff88849fba8cb8 RDI: 00000000ffffffff [ 305.738785] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 [ 305.745962] R10: ffffc900016879a0 R11: ffffc900016879a5 R12: 0000000000000000 [ 305.753139] R13: 0000000000000000 R14: ffff8884905c9bc0 R15: 0000000000000000 [ 305.760315] FS: 0000000000000000(0000) GS:ffff88849fb80000(0000) knlGS:0000000000000000 [ 305.768452] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 305.774263] CR2: 0000000000000030 CR3: 0000000005610006 CR4: 0000000000760ee0 [ 305.781441] PKRU: 55555554 [ 305.784228] Call Trace: [ 305.786739] intel_atomic_check+0xb2e/0x2560 [i915] [ 305.791678] ? printk+0x53/0x6a [ 305.794856] ? drm_atomic_check_only+0x3e/0x810 [ 305.799417] ? __drm_dbg+0x82/0x90 [ 305.802848] drm_atomic_check_only+0x56a/0x810 [ 305.807322] drm_atomic_commit+0xe/0x50 [ 305.811185] drm_client_modeset_commit_atomic+0x1e2/0x250 [ 305.816619] drm_client_modeset_commit_force+0x4d/0x180 [ 305.821921] drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0 [ 305.827963] drm_fb_helper_set_par+0x2b/0x40 [ 305.832265] drm_fb_helper_hotplug_event.part.0+0xb2/0xd0 [ 305.837755] drm_kms_helper_hotplug_event+0x21/0x30 [ 305.842694] process_one_work+0x25b/0x5b0 [ 305.846735] worker_thread+0x4b/0x3b0 [ 305.850439] kthread+0x100/0x140 [ 305.853690] ? process_one_work+0x5b0/0x5b0 [ 305.857901] ? kthread_park+0x80/0x80 [ 305.861588] ret_from_fork+0x24/0x50 [ 305.865202] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 btusb btrtl btbcm btintel bluetooth prime_numbers snd_hda_intel snd_intel_dspcfg snd_hda_codec e1000e snd_hwdep snd_hda_core thunderbolt mei_hdcp mei_me asix cdc_ether x86_pkg_temp_thermal r8152 mei coretemp usbnet snd_pcm mii crct10dif_pclmul ptp crc32_pclmul ecdh_generic ghash_clmulni_intel pps_core ecc i2c_i801 intel_lpss_pci [ 305.903096] CR2: 0000000000000030 [ 305.906431] ---[ end trace 70ee364eed801cb0 ]--- [ 305.940816] RIP: 0010:drm_dp_mst_atomic_check+0x138/0x2c0 [ 305.946261] Code: 00 00 00 41 29 d9 41 89 d8 4c 89 fa 4c 89 f1 48 c7 c6 b0 b1 34 82 bf 10 00 00 00 45 31 ed e8 3f 99 02 00 4d 8b bf 80 04 00 00 <49> 8b 47 30 49 8d 5f 30 4c 8d 60 e8 48 39 c3 74 35 49 8b 7c 24 28 [ 305.965125] RSP: 0018:ffffc90001687b58 EFLAGS: 00010246 [ 305.970382] RAX: 0000000000000000 RBX: 000000000000003f RCX: 0000000000000000 [ 305.977571] RDX: 0000000000000000 RSI: ffff88849fba8cb8 RDI: 00000000ffffffff [ 305.984747] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 [ 305.991921] R10: ffffc900016879a0 R11: ffffc900016879a5 R12: 0000000000000000 [ 305.999099] R13: 0000000000000000 R14: ffff8884905c9bc0 R15: 0000000000000000 [ 306.006271] FS: 0000000000000000(0000) GS:ffff88849fb80000(0000) knlGS:0000000000000000 [ 306.014407] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 306.020185] CR2: 0000000000000030 CR3: 000000048b3aa003 CR4: 0000000000760ee0 [ 306.027404] PKRU: 55555554 [ 306.030127] BUG: sleeping function called from invalid context at include/linux/percpu-rwsem.h:38 [ 306.039049] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 183, name: kworker/3:2 [ 306.047272] INFO: lockdep is turned off. [ 306.051217] irq event stamp: 77505 [ 306.054647] hardirqs last enabled at (77505): [<ffffffff81a0c147>] _raw_spin_unlock_irqrestore+0x47/0x60 [ 306.064270] hardirqs last disabled at (77504): [<ffffffff81a0bedf>] _raw_spin_lock_irqsave+0xf/0x50 [ 306.073404] softirqs last enabled at (77402): [<ffffffff81e00389>] __do_softirq+0x389/0x47f [ 306.081885] softirqs last disabled at (77395): [<ffffffff810b83a9>] irq_exit+0xa9/0xc0 [ 306.089859] CPU: 3 PID: 183 Comm: kworker/3:2 Tainted: G D 5.5.0-rc6+ #1404 [ 306.098167] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3201.A00.1905140358 05/14/2019 [ 306.111882] Workqueue: events drm_dp_delayed_destroy_work [ 306.117314] Call Trace: [ 306.119780] dump_stack+0x71/0xa0 [ 306.123135] ___might_sleep.cold+0xf7/0x10b [ 306.127399] exit_signals+0x2b/0x360 [ 306.131014] do_exit+0xa7/0xc70 [ 306.134189] ? kthread+0x100/0x140 [ 306.137615] rewind_stack_do_exit+0x17/0x20 Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check") Cc: Mikita Lipski <mikita.lipski@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Lyude Paul <lyude@redhat.com> Acked-by: Mikita Lipski <mikita.lipski@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-17drm/amdgpu: add the lost mutex_init backPan, Xinhui1-0/+1
Initialize notifier_lock. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1016 Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: xinhui pan <xinhui.pan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-01-17Revert "drm/dp_mst: Remove VCPI while disabling topology mgr"Lyude Paul1-13/+0
This reverts commit 64e62bdf04ab8529f45ed0a85122c703035dec3a. This commit ends up causing some lockdep splats due to trying to grab the payload lock while holding the mgr's lock: [ 54.010099] [ 54.011765] ====================================================== [ 54.018670] WARNING: possible circular locking dependency detected [ 54.025577] 5.5.0-rc6-02274-g77381c23ee63 #47 Not tainted [ 54.031610] ------------------------------------------------------ [ 54.038516] kworker/1:6/1040 is trying to acquire lock: [ 54.044354] ffff888272af3228 (&mgr->payload_lock){+.+.}, at: drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.054957] [ 54.054957] but task is already holding lock: [ 54.061473] ffff888272af3060 (&mgr->lock){+.+.}, at: drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4 [ 54.071193] [ 54.071193] which lock already depends on the new lock. [ 54.071193] [ 54.080334] [ 54.080334] the existing dependency chain (in reverse order) is: [ 54.088697] [ 54.088697] -> #1 (&mgr->lock){+.+.}: [ 54.094440] __mutex_lock+0xc3/0x498 [ 54.099015] drm_dp_mst_topology_get_port_validated+0x25/0x80 [ 54.106018] drm_dp_update_payload_part1+0xa2/0x2e2 [ 54.112051] intel_mst_pre_enable_dp+0x144/0x18f [ 54.117791] intel_encoders_pre_enable+0x63/0x70 [ 54.123532] hsw_crtc_enable+0xa1/0x722 [ 54.128396] intel_update_crtc+0x50/0x194 [ 54.133455] skl_commit_modeset_enables+0x40c/0x540 [ 54.139485] intel_atomic_commit_tail+0x5f7/0x130d [ 54.145418] intel_atomic_commit+0x2c8/0x2d8 [ 54.150770] drm_atomic_helper_set_config+0x5a/0x70 [ 54.156801] drm_mode_setcrtc+0x2ab/0x833 [ 54.161862] drm_ioctl+0x2e5/0x424 [ 54.166242] vfs_ioctl+0x21/0x2f [ 54.170426] do_vfs_ioctl+0x5fb/0x61e [ 54.175096] ksys_ioctl+0x55/0x75 [ 54.179377] __x64_sys_ioctl+0x1a/0x1e [ 54.184146] do_syscall_64+0x5c/0x6d [ 54.188721] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 54.194946] [ 54.194946] -> #0 (&mgr->payload_lock){+.+.}: [ 54.201463] [ 54.201463] other info that might help us debug this: [ 54.201463] [ 54.210410] Possible unsafe locking scenario: [ 54.210410] [ 54.217025] CPU0 CPU1 [ 54.222082] ---- ---- [ 54.227138] lock(&mgr->lock); [ 54.230643] lock(&mgr->payload_lock); [ 54.237742] lock(&mgr->lock); [ 54.244062] lock(&mgr->payload_lock); [ 54.248346] [ 54.248346] *** DEADLOCK *** [ 54.248346] [ 54.254959] 7 locks held by kworker/1:6/1040: [ 54.259822] #0: ffff888275c4f528 ((wq_completion)events){+.+.}, at: worker_thread+0x455/0x6e2 [ 54.269451] #1: ffffc9000119beb0 ((work_completion)(&(&dev_priv->hotplug.hotplug_work)->work)){+.+.}, at: worker_thread+0x455/0x6e2 [ 54.282768] #2: ffff888272a403f0 (&dev->mode_config.mutex){+.+.}, at: i915_hotplug_work_func+0x4b/0x2be [ 54.293368] #3: ffffffff824fc6c0 (drm_connector_list_iter){.+.+}, at: i915_hotplug_work_func+0x17e/0x2be [ 54.304061] #4: ffffc9000119bc58 (crtc_ww_class_acquire){+.+.}, at: drm_helper_probe_detect_ctx+0x40/0xfd [ 54.314855] #5: ffff888272a40470 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_lock+0x74/0xe2 [ 54.324385] #6: ffff888272af3060 (&mgr->lock){+.+.}, at: drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4 [ 54.334597] [ 54.334597] stack backtrace: [ 54.339464] CPU: 1 PID: 1040 Comm: kworker/1:6 Not tainted 5.5.0-rc6-02274-g77381c23ee63 #47 [ 54.348893] Hardware name: Google Fizz/Fizz, BIOS Google_Fizz.10139.39.0 01/04/2018 [ 54.357451] Workqueue: events i915_hotplug_work_func [ 54.362995] Call Trace: [ 54.365724] dump_stack+0x71/0x9c [ 54.369427] check_noncircular+0x91/0xbc [ 54.373809] ? __lock_acquire+0xc9e/0xf66 [ 54.378286] ? __lock_acquire+0xc9e/0xf66 [ 54.382763] ? lock_acquire+0x175/0x1ac [ 54.387048] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.393177] ? __mutex_lock+0xc3/0x498 [ 54.397362] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.403492] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.409620] ? drm_dp_dpcd_access+0xd9/0x101 [ 54.414390] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.420517] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.426645] ? intel_digital_port_connected+0x34d/0x35c [ 54.432482] ? intel_dp_detect+0x227/0x44e [ 54.437056] ? ww_mutex_lock+0x49/0x9a [ 54.441242] ? drm_helper_probe_detect_ctx+0x75/0xfd [ 54.446789] ? intel_encoder_hotplug+0x4b/0x97 [ 54.451752] ? intel_ddi_hotplug+0x61/0x2e0 [ 54.456423] ? mark_held_locks+0x53/0x68 [ 54.460803] ? _raw_spin_unlock_irqrestore+0x3a/0x51 [ 54.466347] ? lockdep_hardirqs_on+0x187/0x1a4 [ 54.471310] ? drm_connector_list_iter_next+0x89/0x9a [ 54.476953] ? i915_hotplug_work_func+0x206/0x2be [ 54.482208] ? worker_thread+0x4d5/0x6e2 [ 54.486587] ? worker_thread+0x455/0x6e2 [ 54.490966] ? queue_work_on+0x64/0x64 [ 54.495151] ? kthread+0x1e9/0x1f1 [ 54.498946] ? queue_work_on+0x64/0x64 [ 54.503130] ? kthread_unpark+0x5e/0x5e [ 54.507413] ? ret_from_fork+0x3a/0x50 The proper fix for this is probably cleanup the VCPI allocations when we're enabling the topology, or on the first payload allocation. For now though, let's just revert. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 64e62bdf04ab ("drm/dp_mst: Remove VCPI while disabling topology mgr") Cc: Sean Paul <sean@poorly.run> Cc: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200117205149.97262-1-lyude@redhat.com
2020-01-17drm/i915/userptr: fix size calculationMatthew Auld3-4/+7
If we create a rather large userptr object(e.g 1ULL << 32) we might shift past the type-width of num_pages: (int)num_pages << PAGE_SHIFT, resulting in a totally bogus sg_table, which fortunately will eventually manifest as: gen8_ppgtt_insert_huge:463 GEM_BUG_ON(iter->sg->length < page_size) kernel BUG at drivers/gpu/drm/i915/gt/gen8_ppgtt.c:463! v2: more unsigned long prefer I915_GTT_PAGE_SIZE Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200117132413.1170563-2-matthew.auld@intel.com
2020-01-17drm/i915/userptr: add user_size limit checkMatthew Auld1-0/+17
Don't allow a mismatch between obj->base.size/vma->size and the actual number of pages for the backing store, which is limited to INT_MAX pages. v2: document what are missing before we can safely drop the limit check Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200117132413.1170563-1-matthew.auld@intel.com
2020-01-17drm/panel: Add Feixin K101 IM2BA02 panelIcenowy Zheng3-0/+536
Feixin K101 IM2BA02 is a 800x1280 4-lane MIPI-DSI LCD panel. Add a panel driver for it. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200116033636.512461-4-icenowy@aosc.io
2020-01-17drm/panel: support for auo, b101uan08.3 wuxga dsi video mode panelJitao Shi1-0/+78
Auo,auo,b101uan08.3's connector is same as boe,tv101wum-nl6. The most codes can be reuse. So auo,b101uan08.3 and boe,tv101wum-nl6 use one driver file. Add the different parts in driver data. Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200116021511.22675-6-jitao.shi@mediatek.com
2020-01-17drm/panel: support for boe, tv101wum-n53 wuxga dsi video mode panelJitao Shi1-0/+31
Boe,tv101wum-n53's connector is same as boe,tv101wum-nl6. The most codes can be reuse. So boe,tv101wum-n53 and boe,tv101wum-nl6 use one driver file. Add the different parts in driver data. Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200116021511.22675-5-jitao.shi@mediatek.com
2020-01-17drm/panel: support for auo, kd101n80-45na wuxga dsi video mode panelJitao Shi2-9/+61
Auo,kd101n80-45na's connector is same as boe,tv101wum-nl6. The most codes can be reuse. So auo,kd101n80-45na and boe,tv101wum-nl6 use one driver file. Add the different parts in driver data. Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200116021511.22675-4-jitao.shi@mediatek.com
2020-01-17drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panelJitao Shi3-0/+703
Add driver for BOE tv101wum-nl6 panel is a 10.1" 1200x1920 panel. Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200116021511.22675-3-jitao.shi@mediatek.com
2020-01-17drm/i915/gt: Report the currently active execlists requestChris Wilson1-0/+17
Since commit 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy"), we prune the engine->active.requests list prior to preemption, thus removing the trace of the currently executing request. If that request hangs rather than be preempted, we conclude that no active request was on the GPU. Fortunately, this only impacts our debugging, and not our means of hang detection or recovery. v2: Use from to check the current iterator before continuing, and report active as NULL if the current request is already completed. References: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200117113259.3023890-1-chris@chris-wilson.co.uk
2020-01-17drm/i915: convert to new logging macros in i915/intel_memory_region.cWambui Karuga1-1/+3
Replace the use of printk based logging macros with the new struct drm_device based logging macro in i915/intel_memory_region.c. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1bf4d362e72c619843d44aac96c3561f54e4b23a.1578560355.git.wambui.karugax@gmail.com
2020-01-17drm/i915: convert to new logging macros in i915/intel_gvt.cWambui Karuga1-5/+8
This converts the use of printk based logging macros in i915/intel_gvt.c with the new struct drm_device based logging macros. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/44f3839820a32ed03d73dc56a6ef3581994802c9.1578560355.git.wambui.karugax@gmail.com
2020-01-17drm/i915: conversion to new logging macros in i915/intel_device_info.cWambui Karuga1-11/+14
This replaces the printk and struct device based logging macros with the new struct drm_device style based logging macros i915/intel_device_info.c. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e404429ff2a5e5080867f577beccd7b578a671cd.1578560355.git.wambui.karugax@gmail.com
2020-01-17drm/i915: conversion to new logging macros in i915/intel_csr.cWambui Karuga1-10/+14
Replace the use of printk and struct device based logging macros with the new struct drm_device based logging macros in i915/intel_csr.c Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0ea8e0f39013a73ed66052893a8f8abf8cc23ba6.1578560355.git.wambui.karugax@gmail.com
2020-01-17drm/i915: conversion to new logging macros in i915/i915_vgpu.cWambui Karuga1-16/+25
Replace the use of printk based logging macros with the struct drm_device based macros in i915/i915_vgpu.c Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/45e8bffff8cbffd72ed41901c3db9f7f6dbe79f3.1578560355.git.wambui.karugax@gmail.com
2020-01-17drm/i915/guc: Introduce CT_DEBUGMichal Wajdeczko1-22/+19
As we now have "ct" available almost in all functions we can start using dev variants of logs also for debug. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200117082039.65644-6-michal.wajdeczko@intel.com
2020-01-17drm/i915/guc: Switch to CT_ERROR in ct_readMichal Wajdeczko1-8/+8
As we now have "ct" available in ct_read function we can switch from generic DRM_ERROR to our custom CT_ERROR. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200117082039.65644-5-michal.wajdeczko@intel.com
2020-01-17drm/i915/guc: Don't pass CTB while readingMichal Wajdeczko1-3/+3
Since we only have one RECV buffer we don't need to explicitly pass it to the read function. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200117082039.65644-4-michal.wajdeczko@intel.com
2020-01-17drm/i915/guc: Don't pass CTB while writingMichal Wajdeczko1-6/+7
Since we only have one SEND buffer we don't need to explicitly pass it to the write function. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200117082039.65644-3-michal.wajdeczko@intel.com
2020-01-17drm/i915/guc: Don't GEM_BUG_ON on corrupted G2H CTBMichal Wajdeczko1-16/+22
We should never BUG_ON on any corruption in CTB descriptor as data there can be also modified by the GuC. Instead we can use flag "is_in_error" to indicate that we will not process any further messages over this CTB (until reset). While here move descriptor error reporting to the function that actually touches that descriptor. Note that unexpected content of the specific CT messages, that still complies with generic CT message format, shall not trigger disabling whole CTB, as that might just indicate new unsupported message types. v2: drop redundant message (Daniele) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200117082039.65644-2-michal.wajdeczko@intel.com
2020-01-17drm/i915: Satisfy smatch that a loop has at least one iterationChris Wilson1-0/+1
Smatch worries that the engine->mask may be 0 leading to the loop being shortcircuited leaving the next pointer unset, drivers/gpu/drm/i915/i915_active.c:667 i915_active_acquire_preallocate_barrier() error: uninitialized symbol 'next'. Assert that mask is not 0 and smatch can then verify that next must be initialised before use. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200117110603.2982286-1-chris@chris-wilson.co.uk
2020-01-17drm/i915: Fix typo in kerneldoc function nameChris Wilson1-1/+1
A forgetful copy'n'paste left the name of the old function intact, and did not introduce the new function 'i915_request_is_ready' Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200117101639.2908469-1-chris@chris-wilson.co.uk
2020-01-17drm/i915: Fix i915_error_state_store error definationZhang Xiaoxu1-2/+1
Since commit 742379c0c4001 ("drm/i915: Start chopping up the GPU error capture"), function 'i915_error_state_store' was defined and used with only one parameter. But if no 'CONFIG_DRM_I915_CAPTURE_ERROR', this function was defined with two parameter. This may lead compile error. This patch fix it. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200117073436.6507-1-zhangxiaoxu5@huawei.com
2020-01-17drm/i915: Include the debugfs params header for its own definitionChris Wilson1-0/+1
drivers/gpu/drm/i915/i915_debugfs_params.c:228:15: warning: symbol 'i915_debugfs_params' was not declared. Should it be static? drivers/gpu/drm/i915/i915_debugfs_params.c:228:16: error: no previous prototype for ‘i915_debugfs_params’ [-Werror=missing-prototypes] 228 | struct dentry *i915_debugfs_params(struct drm_i915_private *i915) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Fixes: c43c5a8818d4 ("drm/i915/params: add i915 parameters to debugfs") Link: https://patchwork.freedesktop.org/patch/msgid/20200117102145.2948244-1-chris@chris-wilson.co.uk
2020-01-17drm/i915: Auto detect DPCD backlight support by defaultLyude Paul2-2/+2
Turns out we actually already have some companies, such as Lenovo, shipping machines with AMOLED screens that don't allow controlling the backlight through the usual PWM interface and only allow controlling it through the standard EDP DPCD interface. One example of one of these laptops is the X1 Extreme 2nd Generation. Since we've got systems that need this turned on by default now to have backlight controls working out of the box, let's start auto-detecting it for systems by default based on what the VBT tells us. We do this by changing the default value for the enable_dpcd_backlight module param from 0 to -1. Tested-by: AceLan Kao <acelan.kao@canonical.com> Tested-by: Perry Yuan <pyuan@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116211623.53799-6-lyude@redhat.com
2020-01-17drm/i915: Fix DPCD register order in intel_dp_aux_enable_backlight()Lyude Paul1-1/+2
For eDP panels, it appears it's expected that so long as the panel is in DPCD control mode that the brightness value is never set to 0. Instead, if the desired effect is to set the panel's backlight to 0 we're expected to simply turn off the backlight through the DP_EDP_DISPLAY_CONTROL_REGISTER. We already do the latter correctly in intel_dp_aux_disable_backlight(). But, we make the mistake of writing the DPCD registers in the wrong order when enabling the backlight in intel_dp_aux_enable_backlight() since we currently enable the backlight through DP_EDP_DISPLAY_CONTROL_REGISTER before writing the brightness level. On the X1 Extreme 2nd Generation, this appears to have the potential of confusing the panel in such a way that further attempts to set the brightness don't actually change the backlight as expected and leave it off. Presumably, this happens because the incorrect register writing order briefly leaves the panel with DPCD mode enabled and a 0 brightness level set. So, reverse the order we write the DPCD registers when enabling the panel backlight so that we write the brightness value first, and enable the backlight second. This fix appears to be the final bit needed to get the backlight on the ThinkPad X1 Extreme 2nd Generation's AMOLED screen working. Tested-by: AceLan Kao <acelan.kao@canonical.com> Tested-by: Perry Yuan <pyuan@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116211623.53799-4-lyude@redhat.com
2020-01-17drm/i915: Assume 100% brightness when not in DPCD control modeLyude Paul1-0/+17
Currently we always determine the initial panel brightness level by simply reading the value from DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB. This seems wrong though, because if the panel is not currently in DPCD control mode there's not really any reason why there would be any brightness value programmed in the first place. This appears to be the case on the Lenovo ThinkPad X1 Extreme 2nd Generation, where the default value in these registers is always 0 on boot despite the fact the panel runs at max brightness by default. Getting the initial brightness value correct here is important as well, since the panel on this laptop doesn't behave well if it's ever put into DPCD control mode while the brightness level is programmed to 0. So, let's fix this by checking what the current backlight control mode is before reading the brightness level. If it's in DPCD control mode, we return the programmed brightness level. Otherwise we assume 100% brightness and return the highest possible brightness level. This also prevents us from accidentally programming a brightness level of 0. This is one of the many fixes that gets backlight controls working on the ThinkPad X1 Extreme 2nd Generation with optional 4K AMOLED screen. Changes since v1: * s/DP_EDP_DISPLAY_CONTROL_REGISTER/DP_EDP_BACKLIGHT_MODE_SET_REGISTER/ - Jani Tested-by: AceLan Kao <acelan.kao@canonical.com> Tested-by: Perry Yuan <pyuan@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116211623.53799-3-lyude@redhat.com
2020-01-17drm/i915: Fix eDP DPCD aux max backlight calculationsLyude Paul2-47/+95
Max backlight value for the panel was being calculated using byte count i.e. 0xffff if 2 bytes are supported for backlight brightness and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT determines the number of active control bits used for the brightness setting. Thus, even if the panel uses 2 byte setting, it might not use all the control bits. Thus, max backlight should be set based on the value of EDP_PWMGEN_BIT_COUNT instead of assuming 65535 or 255. Additionally, EDP_PWMGEN_BIT_COUNT was being updated based on the VBT frequency which results in a different max backlight value. Thus, setting of EDP_PWMGEN_BIT_COUNT is moved to setup phase instead of enable so that max backlight can be calculated correctly. Only the frequency divider is set during the enable phase using the value of EDP_PWMGEN_BIT_COUNT. This is based off the original patch series from Furquan Shaikh <furquan@google.com>: https://patchwork.freedesktop.org/patch/317255/?series=62326&rev=3 Changes since original patch: * Remove unused intel_dp variable in intel_dp_aux_setup_backlight() * Fix checkpatch issues * Make sure that we rewrite the pwmgen bit count whenever we bring the panel out of D3 mode v2 by Jani: * rebase * fix readb return value check Cc: Furquan Shaikh <furquan@google.com> Tested-by: AceLan Kao <acelan.kao@canonical.com> Tested-by: Perry Yuan <pyuan@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116211623.53799-2-lyude@redhat.com
2020-01-17drm/i915/dsi: Lookup the i2c bus from ACPI NS only if CONFIG_ACPI=y (v2)Vivek Kasireddy1-16/+31
Perform the i2c bus/adapter lookup from ACPI Namespace only if ACPI is enabled in the kernel config. If ACPI is not enabled or if the lookup fails, we'll fallback to using the VBT for identifying the i2c bus. v2: Add fixes tag (Jani) Fixes: 8cbf89db2941 ("drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)") Cc: Hans de Goede <hdegoede@redhat.com> Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115012305.27395-1-vivek.kasireddy@intel.com
2020-01-16drm/i915/execlists: Offline error captureChris Wilson1-2/+120
Currently, we skip error capture upon forced preemption. We apply forced preemption when there is a higher priority request that should be running but is being blocked, and we skip inline error capture so that the preemption request is not further delayed by a user controlled capture -- extending the denial of service. However, preemption reset is also used for heartbeats and regular GPU hangs. By skipping the error capture, we remove the ability to debug GPU hangs. In order to capture the error without delaying the preemption request further, we can do an out-of-line capture by removing the guilty request from the execution queue and scheduling a worker to dump that request. When removing a request, we need to remove the entire context and all descendants from the execution queue, so that they do not jump past. Closes: https://gitlab.freedesktop.org/drm/intel/issues/738 Fixes: 3a7a92aba8fb ("drm/i915/execlists: Force preemption") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116184754.2860848-3-chris@chris-wilson.co.uk
2020-01-16drm/i915/gt: Allow temporary suspension of inflight requestsChris Wilson5-6/+321
In order to support out-of-line error capture, we need to remove the active request from HW and put it to one side while a worker compresses and stores all the details associated with that request. (As that compression may take an arbitrary user-controlled amount of time, we want to let the engine continue running on other workloads while the hanging request is dumped.) Not only do we need to remove the active request, but we also have to remove its context and all requests that were dependent on it (both in flight, queued and future submission). Finally once the capture is complete, we need to be able to resubmit the request and its dependents and allow them to execute. v2: Replace stack recursion with a simple list. v3: Check all the parents, not just the first, when searching for a stuck ancestor! References: https://gitlab.freedesktop.org/drm/intel/issues/738 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116184754.2860848-2-chris@chris-wilson.co.uk
2020-01-16drm/i915: Keep track of request among the scheduling listsChris Wilson4-18/+38
If we keep track of when the i915_request.sched.link is on the HW runlist, or in the priority queue we can simplify our interactions with the request (such as during rescheduling). This also simplifies the next patch where we introduce a new in-between list, for requests that are ready but neither on the run list or in the queue. v2: Update i915_sched_node.link explanation for current usage where it is a link on both the queue and on the runlists. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116184754.2860848-1-chris@chris-wilson.co.uk
2020-01-16drm/amd/display: skip opp blank or unblank if test pattern enabledWenjing Liu1-0/+3
[why] DPG is used to generate both blank and test automation test pattern. When test automation is running the requested test pattern can be overriden by the blank or unblank call because it is using the same hardware. [how] When test pattern is requested, skip blank or unblank. Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com> Reviewed-by: Nikola Cornij <Nikola.Cornij@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.