aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2018-11-07drm/amd/powerplay: set a default fclk/gfxclk ratioEvan Quan3-1/+19
Otherwise big gap between these two clocks may causes some hangs. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Feifei Xu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-07drm/amdgpu/display/dce11: only enable FBC when selectedAlex Deucher1-1/+2
Causes a black screen on a Stoney laptop. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=108577 Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-07drm/amdgpu/display/dm: handle FBC dc feature parameterAlex Deucher1-0/+3
Set the dc_config properly when the option is enabled. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-07drm/amdgpu/display/dc: add FBC to dc_configAlex Deucher1-0/+1
Add FBC to the list of features that can be enabled from the DM. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-07drm/amdgpu: add DC feature mask module parameterAlex Deucher3-0/+16
Similar to ppfeaturemask. Allows you to selectively enable/disable DC features. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-07drm/amdgpu/display: check if fbc is available in set_static_screen_control (v2)Alex Deucher1-1/+6
The value is dependent on whether fbc is available. v2: only check if num_pipes is valid Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-07drm/amdgpu: disable page queue on Vega10 SR-IOV VFTrigger Huang1-1/+4
Currently, SDMA page queue is not used under SR-IOV VF, and this queue will cause ring test failure in amdgpu module reload case. So just disable it. Signed-off-by: Trigger Huang <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-07drm/amdgpu: set Vega20 LBPW as disabled at defaultEvan Quan1-0/+14
For Vega20, LBPW feature is disabled at default. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Feifei Xu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-07drm/amd/powerplay: always use fast UCLK switching when UCLK DPM enabledEvan Quan1-20/+17
With UCLK DPM enabled, slow switching is not supported any more. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Feifei Xu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-07drm/amd/powerplay: set a default fclk/gfxclk ratioEvan Quan3-1/+19
Otherwise big gap between these two clocks may causes some hangs. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Feifei Xu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-07drm/ttm: Fix bo_global and mem_global kfree errorTrigger Huang2-10/+0
ttm_bo_glob and ttm_mem_glob are defined as structure instance, while not allocated by kzalloc, so kfree should not be invoked to release them anymore. Otherwise, it will cause the following kernel BUG when unloading amdgpu module [ 48.419294] kernel BUG at /build/linux-5s7Xkn/linux-4.15.0/mm/slub.c:3894! [ 48.419352] invalid opcode: 0000 [#1] SMP PTI [ 48.419387] Modules linked in: amdgpu(OE-) amdchash(OE) amdttm(OE) amd_sched(OE) amdkcl(OE) amd_iommu_v2 drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi pcbc snd_seq snd_seq_device snd_timer aesni_intel snd soundcore joydev aes_x86_64 crypto_simd glue_helper cryptd input_leds mac_hid serio_raw binfmt_misc nfsd auth_rpcgss nfs_acl lockd grace sunrpc sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 8139too psmouse i2c_piix4 8139cp mii floppy pata_acpi [ 48.419782] CPU: 1 PID: 1281 Comm: modprobe Tainted: G OE 4.15.0-20-generic #21-Ubuntu [ 48.419838] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 [ 48.419901] RIP: 0010:kfree+0x137/0x180 [ 48.419934] RSP: 0018:ffffb02101273bf8 EFLAGS: 00010246 [ 48.419974] RAX: ffffeee1418ad7e0 RBX: ffffffffc075f100 RCX: ffff8fed7fca7ed0 [ 48.420025] RDX: 0000000000000000 RSI: 000000000003440e RDI: 0000000022400000 [ 48.420073] RBP: ffffb02101273c10 R08: 0000000000000010 R09: ffff8fed7ffd3680 [ 48.420121] R10: ffffeee1418ad7c0 R11: ffff8fed7ffd3000 R12: ffffffffc075e2c0 [ 48.420169] R13: ffffffffc074ec10 R14: ffff8fed73063900 R15: ffff8fed737428e8 [ 48.420216] FS: 00007fdc912ec540(0000) GS:ffff8fed7fc80000(0000) knlGS:0000000000000000 [ 48.420267] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 48.420308] CR2: 000055fa40c30060 CR3: 000000023470a006 CR4: 00000000003606e0 [ 48.420358] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 48.420405] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 48.420452] Call Trace: [ 48.420485] ttm_bo_global_kobj_release+0x20/0x30 [amdttm] [ 48.420528] kobject_release+0x6a/0x180 [ 48.420562] kobject_put+0x28/0x50 [ 48.420595] ttm_bo_global_release+0x36/0x50 [amdttm] [ 48.420636] amdttm_bo_device_release+0x119/0x180 [amdttm] [ 48.420678] ? amdttm_bo_clean_mm+0xa6/0xf0 [amdttm] [ 48.420760] amdgpu_ttm_fini+0xc9/0x180 [amdgpu] [ 48.420821] amdgpu_bo_fini+0x12/0x40 [amdgpu] [ 48.420889] gmc_v9_0_sw_fini+0x40/0x50 [amdgpu] [ 48.420947] amdgpu_device_fini+0x36f/0x4c0 [amdgpu] [ 48.421007] amdgpu_driver_unload_kms+0xb4/0x150 [amdgpu] [ 48.421058] drm_dev_unregister+0x46/0xf0 [drm] [ 48.421102] drm_dev_unplug+0x12/0x70 [drm] Signed-off-by: Trigger Huang <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-07drm/amd/amdgpu/dm: Fix dm_dp_create_fake_mst_encoder()Lyude Paul1-5/+0
[why] Removing connector reusage from DM to match the rest of the tree ended up revealing an issue that was surprisingly subtle. The original amdgpu code for DC that was submitted appears to have left a chunk in dm_dp_create_fake_mst_encoder() that tries to find a "master encoder", the likes of which isn't actually used or stored anywhere. It does so at the wrong time as well by trying to access parts of the drm_connector from the encoder init before it's actually been initialized. This results in a NULL pointer deref on MST hotplugs: [ 160.696613] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 [ 160.697234] PGD 0 P4D 0 [ 160.697814] Oops: 0010 [#1] SMP PTI [ 160.698430] CPU: 2 PID: 64 Comm: kworker/2:1 Kdump: loaded Tainted: G O 4.19.0Lyude-Test+ #2 [ 160.699020] Hardware name: HP HP ZBook 15 G4/8275, BIOS P70 Ver. 01.22 05/17/2018 [ 160.699672] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] [ 160.700322] RIP: 0010: (null) [ 160.700920] Code: Bad RIP value. [ 160.701541] RSP: 0018:ffffc9000029fc78 EFLAGS: 00010206 [ 160.702183] RAX: 0000000000000000 RBX: ffff8804440ed468 RCX: ffff8804440e9158 [ 160.702778] RDX: 0000000000000000 RSI: ffff8804556c5700 RDI: ffff8804440ed000 [ 160.703408] RBP: ffff880458e21800 R08: 0000000000000002 R09: 000000005fca0a25 [ 160.704002] R10: ffff88045a077a3d R11: ffff88045a077a3c R12: ffff8804440ed000 [ 160.704614] R13: ffff880458e21800 R14: ffff8804440e9000 R15: ffff8804440e9000 [ 160.705260] FS: 0000000000000000(0000) GS:ffff88045f280000(0000) knlGS:0000000000000000 [ 160.705854] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 160.706478] CR2: ffffffffffffffd6 CR3: 000000000200a001 CR4: 00000000003606e0 [ 160.707124] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 160.707724] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 160.708372] Call Trace: [ 160.708998] ? dm_dp_add_mst_connector+0xed/0x1d0 [amdgpu] [ 160.709625] ? drm_dp_add_port+0x2fa/0x470 [drm_kms_helper] [ 160.710284] ? wake_up_q+0x54/0x70 [ 160.710877] ? __mutex_unlock_slowpath.isra.18+0xb3/0x110 [ 160.711512] ? drm_dp_dpcd_access+0xe7/0x110 [drm_kms_helper] [ 160.712161] ? drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper] [ 160.712762] ? drm_dp_check_and_send_link_address+0xa3/0xd0 [drm_kms_helper] [ 160.713408] ? drm_dp_mst_link_probe_work+0x4b/0x80 [drm_kms_helper] [ 160.714013] ? process_one_work+0x1a1/0x3a0 [ 160.714667] ? worker_thread+0x30/0x380 [ 160.715326] ? wq_update_unbound_numa+0x10/0x10 [ 160.715939] ? kthread+0x112/0x130 [ 160.716591] ? kthread_create_worker_on_cpu+0x70/0x70 [ 160.717262] ? ret_from_fork+0x35/0x40 [ 160.717886] Modules linked in: amdgpu(O) vfat fat snd_hda_codec_generic joydev i915 chash gpu_sched ttm i2c_algo_bit drm_kms_helper snd_hda_codec_hdmi hp_wmi syscopyarea iTCO_wdt sysfillrect sparse_keymap sysimgblt fb_sys_fops snd_hda_intel usbhid wmi_bmof drm snd_hda_codec btusb snd_hda_core intel_rapl btrtl x86_pkg_temp_thermal btbcm btintel coretemp snd_pcm crc32_pclmul bluetooth psmouse snd_timer snd pcspkr i2c_i801 mei_me i2c_core soundcore mei tpm_tis wmi tpm_tis_core hp_accel ecdh_generic lis3lv02d tpm video rfkill acpi_pad input_polldev hp_wireless pcc_cpufreq crc32c_intel serio_raw tg3 xhci_pci xhci_hcd [last unloaded: amdgpu] [ 160.720141] CR2: 0000000000000000 Somehow the connector reusage DM was using for MST connectors managed to paper over this issue entirely; hence why this was never caught until now. [how] Since this code isn't used anywhere and seems useless anyway, we can just drop it entirely. This appears to fix the issue on my HP ZBook with an AMD WX4150. Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-07drm/amd/display: Drop reusing drm connector for MSTJerry (Fangzhi) Zuo2-35/+7
[why] It is not safe to keep existing connector while entire topology has been removed. Could lead potential impact to uapi. Entirely unregister all the connectors on the topology, and use a new set of connectors when the topology is plugged back on. [How] Remove the drm connector entirely each time when the corresponding MST topology is gone. When hotunplug a connector (e.g., DP2) 1. Remove connector from userspace. 2. Drop it's reference. When hotplug back on: 1. Detect new topology, and create new connectors. 2. Notify userspace with sysfs hotplug event. 3. Reprobe new connectors, and reassign CRTC from old (e.g., DP2) to new (e.g., DP3) connector. Signed-off-by: Jerry (Fangzhi) Zuo <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-07drm/amd/display: Cleanup MST non-atomic code workaroundJerry (Fangzhi) Zuo3-46/+4
[why] It is not correct to touch aconnector within atomic_check. [How] It was added as workaround before, and no longer needed. Signed-off-by: Jerry (Fangzhi) Zuo <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-07drm/amdgpu: fix frame size of amdgpu_xgmi_add_devices excceed 1024 bytesHawking Zhang1-5/+8
Instead of stack-allocated psp_xgmi_topology_info in function amdgpu_xgmi_add_device, dynamically allocated this structure to avoid the frame size of this function excceed 1024 bytes Signed-off-by: Hawking Zhang <[email protected]> Reviewed-by: Xiaojie Yuan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-07drm: Fix htmldocs warnings in drm_fourcc.cSean Paul1-1/+1
Add a description for dev and remove the excess one for native. Fixes the following warnings: ../drivers/gpu/drm/drm_fourcc.c:112: warning: Function parameter or member 'dev' not described in 'drm_driver_legacy_fb_format' ../drivers/gpu/drm/drm_fourcc.c:112: warning: Excess function parameter 'native' description in 'drm_driver_legacy_fb_format' Fixes: 059b5eb5d955 ("drm: move native byte order quirk to new drm_driver_legacy_fb_format function") Cc: Gerd Hoffmann <[email protected]> Cc: Daniel Vetter <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-11-07leds: trigger: Fix sleeping function called from invalid contextBaolin Wang1-16/+4
We will meet below issue due to mutex_lock() is called in interrupt context. The mutex lock is used to protect the pattern trigger data, but before changing new pattern trigger data (pattern values or repeat value) by users, we always cancel the timer firstly to clear previous patterns' performance. That means there is no race in pattern_trig_timer_function(), so we can drop the mutex lock in pattern_trig_timer_function() to avoid this issue. Moreover we can move the timer cancelling into mutex protection, since there is no deadlock risk if we remove the mutex lock in pattern_trig_timer_function(). BUG: sleeping function called from invalid context at kernel/locking/mutex.c:254 in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/1 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.20.0-rc1-koelsch-00841-ga338c8181013c1a9 #171 Hardware name: Generic R-Car Gen2 (Flattened Device Tree) [<c020f19c>] (unwind_backtrace) from [<c020aecc>] (show_stack+0x10/0x14) [<c020aecc>] (show_stack) from [<c07affb8>] (dump_stack+0x7c/0x9c) [<c07affb8>] (dump_stack) from [<c02417d4>] (___might_sleep+0xf4/0x158) [<c02417d4>] (___might_sleep) from [<c07c92c4>] (mutex_lock+0x18/0x60) [<c07c92c4>] (mutex_lock) from [<c067b28c>] (pattern_trig_timer_function+0x1c/0x11c) [<c067b28c>] (pattern_trig_timer_function) from [<c027f6fc>] (call_timer_fn+0x1c/0x90) [<c027f6fc>] (call_timer_fn) from [<c027f944>] (expire_timers+0x94/0xa4) [<c027f944>] (expire_timers) from [<c027fc98>] (run_timer_softirq+0x108/0x15c) [<c027fc98>] (run_timer_softirq) from [<c02021cc>] (__do_softirq+0x1d4/0x258) [<c02021cc>] (__do_softirq) from [<c0224d24>] (irq_exit+0x64/0xc4) [<c0224d24>] (irq_exit) from [<c0268dd0>] (__handle_domain_irq+0x80/0xb4) [<c0268dd0>] (__handle_domain_irq) from [<c045e1b0>] (gic_handle_irq+0x58/0x90) [<c045e1b0>] (gic_handle_irq) from [<c02019f8>] (__irq_svc+0x58/0x74) Exception stack(0xeb483f60 to 0xeb483fa8) 3f60: 00000000 00000000 eb9afaa0 c0217e80 00000000 ffffe000 00000000 c0e06408 3f80: 00000002 c0e0647c c0c6a5f0 00000000 c0e04900 eb483fb0 c0207ea8 c0207e98 3fa0: 60020013 ffffffff [<c02019f8>] (__irq_svc) from [<c0207e98>] (arch_cpu_idle+0x1c/0x38) [<c0207e98>] (arch_cpu_idle) from [<c0247ca8>] (do_idle+0x138/0x268) [<c0247ca8>] (do_idle) from [<c0248050>] (cpu_startup_entry+0x18/0x1c) [<c0248050>] (cpu_startup_entry) from [<402022ec>] (0x402022ec) Fixes: 5fd752b6b3a2 ("leds: core: Introduce LED pattern trigger") Signed-off-by: Baolin Wang <[email protected]> Reported-by: Geert Uytterhoeven <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Jacek Anaszewski <[email protected]>
2018-11-07drm/i915/icl: Fix power well 2 wrt. DC-off toggling orderImre Deak1-6/+6
To enable DC5/6 power well 2 has to be disabled as for previous platforms, so fix things up. Bspec: 4234 Fixes: 67ca07e7ac10 ("drm/i915/icl: Add power well support") Cc: Animesh Manna <[email protected]> Cc: Paulo Zanoni <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-11-07drm/i915: Add short HPD IRQ storm detection for non-MST systemsLyude Paul4-21/+115
Unfortunately, it seems that the HPD IRQ storm problem from the early days of Intel GPUs was never entirely solved, only mostly. Within the last couple of days, I got a bug report from one of our customers who had been having issues with their machine suddenly booting up very slowly after having updated. The amount of time it took to boot went from around 30 seconds, to over 6 minutes consistently. After some investigation, I discovered that i915 was reporting massive amounts of short HPD IRQ spam on this system from the DisplayPort port, despite there not being anything actually connected. The symptoms would start with one "long" HPD IRQ being detected at boot: [ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0 [ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long [ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0 [ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long [ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0 [ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long [ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long … followed by constant short IRQs afterwards: [ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected [ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event. [ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3] [ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 [ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short [ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 [ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short [ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085 [ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 [ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short [ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 [ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short [ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 The customer's system in question has a GM45 GPU, which is apparently well known for hotplugging storms. So, workaround this impressively broken hardware by changing the default HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and short IRQs count for 1. This makes it so that 5 long IRQs will trigger an HPD storm, and on systems with short HPD storm detection 50 short IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of constant pulsing, which seems like a good middleground between being too sensitive and not being sensitive enough (which would cause visible stutters in userspace every time a storm occurs). And just to be extra safe: we don't enable this by default on systems with MST support. There's too high of a chance of MST support triggering storm detection, and systems that are new enough to support MST are a lot less likely to have issues with IRQ storms anyway. As a note: this patch was tested using a ThinkPad T450s and a Chamelium to simulate the short IRQ storms. Changes since v1: - Don't use two separate thresholds, just make long IRQs count for 10 each and short IRQs count for 1. This simplifies the code a bit - Ville Syrjälä Changes since v2: - Document @long_hpd in intel_hpd_irq_storm_detect, no functional changes Changes since v4: - Remove !! in long_hpd assignment - Ville Syrjälä - queue_hp = true - Ville Syrjälä Signed-off-by: Lyude Paul <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-11-07drm/i915: Clarify flow for disabling IRQs on stormsLyude Paul1-3/+8
This is rather confusing to look at as-is: dev_priv->display.hpd_irq_setup(dev_priv); in intel_hpd_irq_handler() handles disabling the actual HPD IRQ, while intel_hpd_irq_storm_disable() handles moving the HPD pin state over from MARK_DISABLED to DISABLED along with enabling polling for it. Changes since v3: - Rename i915_hpd_irq_storm_disable() to i915_hpd_irq_storm_switch_to_polling() - Rodrigo Vivi Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Cc: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-11-07drm/i915: Fix threshold check in intel_hpd_irq_storm_detect()Lyude Paul1-10/+13
Currently in intel_hpd_irq_storm_detect() when we detect that the last recorded hotplug wasn't within the period defined by HPD_STORM_DETECT_DELAY, we make the mistake of resetting the HPD count to 0 without incrementing it. This results in us only enabling storm detection when we go +2 above the threshold, e.g. an HPD threshold of 5 would not trigger a storm until we reach a total of 7 hotplugs. So: rework the code a bit so we reset the HPD count when HPD_STORM_DETECT_DELAY has passed, then increment the count afterwards. Also, clean things up a bit to make it easier to undertand. Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Cc: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-11-07drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MSTLyude Paul1-1/+3
Turns out that if you trigger an HPD storm on a system that has an MST topology connected to it, you'll end up causing the kernel to eventually hit a NULL deref: [ 332.339041] BUG: unable to handle kernel NULL pointer dereference at 00000000000000ec [ 332.340906] PGD 0 P4D 0 [ 332.342750] Oops: 0000 [#1] SMP PTI [ 332.344579] CPU: 2 PID: 25 Comm: kworker/2:0 Kdump: loaded Tainted: G O 4.18.0-rc3short-hpd-storm+ #2 [ 332.346453] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET71WW (1.35 ) 09/14/2018 [ 332.348361] Workqueue: events intel_hpd_irq_storm_reenable_work [i915] [ 332.350301] RIP: 0010:intel_hpd_irq_storm_reenable_work.cold.3+0x2f/0x86 [i915] [ 332.352213] Code: 00 00 ba e8 00 00 00 48 c7 c6 c0 aa 5f a0 48 c7 c7 d0 73 62 a0 4c 89 c1 4c 89 04 24 e8 7f f5 af e0 4c 8b 04 24 44 89 f8 29 e8 <41> 39 80 ec 00 00 00 0f 85 43 13 fc ff 41 0f b6 86 b8 04 00 00 41 [ 332.354286] RSP: 0018:ffffc90000147e48 EFLAGS: 00010006 [ 332.356344] RAX: 0000000000000005 RBX: ffff8802c226c9d4 RCX: 0000000000000006 [ 332.358404] RDX: 0000000000000000 RSI: 0000000000000082 RDI: ffff88032dc95570 [ 332.360466] RBP: 0000000000000005 R08: 0000000000000000 R09: ffff88031b3dc840 [ 332.362528] R10: 0000000000000000 R11: 000000031a069602 R12: ffff8802c226ca20 [ 332.364575] R13: ffff8802c2268000 R14: ffff880310661000 R15: 000000000000000a [ 332.366615] FS: 0000000000000000(0000) GS:ffff88032dc80000(0000) knlGS:0000000000000000 [ 332.368658] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 332.370690] CR2: 00000000000000ec CR3: 000000000200a003 CR4: 00000000003606e0 [ 332.372724] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 332.374773] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 332.376798] Call Trace: [ 332.378809] process_one_work+0x1a1/0x350 [ 332.380806] worker_thread+0x30/0x380 [ 332.382777] ? wq_update_unbound_numa+0x10/0x10 [ 332.384772] kthread+0x112/0x130 [ 332.386740] ? kthread_create_worker_on_cpu+0x70/0x70 [ 332.388706] ret_from_fork+0x35/0x40 [ 332.390651] Modules linked in: i915(O) vfat fat joydev btusb btrtl btbcm btintel bluetooth ecdh_generic iTCO_wdt wmi_bmof i2c_algo_bit drm_kms_helper intel_rapl syscopyarea sysfillrect x86_pkg_temp_thermal sysimgblt coretemp fb_sys_fops crc32_pclmul drm psmouse pcspkr mei_me mei i2c_i801 lpc_ich mfd_core i2c_core tpm_tis tpm_tis_core thinkpad_acpi wmi tpm rfkill video crc32c_intel serio_raw ehci_pci xhci_pci ehci_hcd xhci_hcd [last unloaded: i915] [ 332.394963] CR2: 00000000000000ec This appears to be due to the fact that with an MST topology, not all intel_connector structs will have ->encoder set. So, fix this by skipping connectors without encoders in intel_hpd_irq_storm_reenable_work(). For those wondering, this bug was found on accident while simulating HPD storms using a Chamelium connected to a ThinkPad T450s (Broadwell). Changes since v1: - Check intel_connector->mst_port instead of intel_connector->encoder Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Cc: [email protected] Cc: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-11-07drm/i915: Fix possible race in intel_dp_add_mst_connector()Lyude Paul1-4/+4
This hasn't caused any issues yet that I'm aware of, but as Ville Syrjälä pointed out - we need to make sure that intel_connector->mst_port is set before initializing MST connectors, since in theory we could potentially check intel_connector->mst_port in i915_hpd_poll_init_work() after registering the connector but before having written it's value. Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-11-07Merge tag 'hwmon-for-v4.20-rc2' of ↵Linus Torvalds2-8/+7
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - Remove bogus __init annotations in ibmpowernv driver - Fix double-free in error handling of __hwmon_device_register() * tag 'hwmon-for-v4.20-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (ibmpowernv) Remove bogus __init annotations hwmon: (core) Fix double-free in __hwmon_device_register()
2018-11-07i40e: enable NETIF_F_NTUPLE and NETIF_F_HW_TC at driver loadJacob Keller1-3/+3
The assignment of the feature flag NETIF_F_NTUPLE and NETIF_F_HW_TC occurs prior to the initial setup of the local hw_features variable. This means the features are set as user-changeable, but are not set in the currently active feature list. This results in the features being disabled at the driver's initial load. Move the assignment after the initial assignment of hw_features, and assign to the local variable. This ensures that NETIF_F_NTUPLE and NETIF_F_HW_TC are marked as user-changeable, and also enables them by default when the driver loads. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-11-07drm/i915: Clean up skl_program_scaler()Ville Syrjälä1-13/+5
Remove the "sizes are 0 based" stuff that is not even true for the scaler. v2: Rebase Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2018-11-07drm/i915: Nuke posting reads from plane update/disable funcsVille Syrjälä2-18/+0
No need for the posting reads in the plane update/disable hooks. If we need a posting read for something then a single one at the very end would be sufficient. We have that anyway in the form of eg. scanline/frame counter reads. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2018-11-07i40e: restore NETIF_F_GSO_IPXIP[46] to netdev featuresJacob Keller1-0/+2
Since commit bacd75cfac8a ("i40e/i40evf: Add capability exchange for outer checksum", 2017-04-06) the i40e driver has not reported support for IP-in-IP offloads. This likely occurred due to a bad rebase, as the commit extracts hw_enc_features into its own variable. As part of this change, it dropped the NETIF_F_FSO_IPXIP flags from the netdev->hw_enc_features. This was unfortunately not caught during code review. Fix this by adding back the missing feature flags. For reference, NETIF_F_GSO_IPXIP4 was added in commit 7e13318daa4a ("net: define gso types for IPx over IPv4 and IPv6", 2016-05-20), replacing NETIF_F_GSO_IPIP and NETIF_F_GSO_SIT. NETIF_F_GSO_IPXIP6 was added in commit bf2d1df39502 ("intel: Add support for IPv6 IP-in-IP offload", 2016-05-20). Signed-off-by: Jacob Keller <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-11-07ice: Change req_speeds to be u16Chinh T Cao1-1/+1
Since the req_speeds field in struct ice_link_status is a u8, req_speeds & ICE_AQ_LINK_SPEED_40GB always returns 0. This was caught by a coverity scan. Fix this by changing req_speeds to be u16. Reported-by: Bruce Allan <[email protected]> Signed-off-by: Chinh T Cao <[email protected]> Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-11-07drm/atomic: Use explicit old/new state in drm_atomic_plane_check()Ville Syrjälä1-39/+46
Convert drm_atomic_plane_check() over to using explicit old vs. new plane states. Avoids the confusion of "what does plane->state mean again?". v2: Stick to the multi-stage logic in plane_switching_crtc() (Daniel) Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-11-07drm/atomic: Use explicit old/new state in drm_atomic_crtc_check()Ville Syrjälä1-11/+15
Convert drm_atomic_crtc_check() over to using explicit old vs. new crtc states. Avoids the confusion of "what does crtc->state mean again?". Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]>
2018-11-07drm/atomic: Use explicit old crtc state in drm_atomic_add_affected_planes()Ville Syrjälä1-1/+3
Replace 'crtc->state' with the explicit old crtc state. Actually it shouldn't matter whether we use the old or the new crtc state here since any plane that has been removed from the crtc since the crtc state was duplicated will have been added to the atomic state already. That is, you can't call drm_atomic_set_crtc_for_plane() without having the new plane state already in hand. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]> Acked-by: Harry Wentland <[email protected]>
2018-11-07Merge branch 'for-linus' of ↵Linus Torvalds7-5/+65
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fixes from Jiri Kosina: - hid.git is moving towards group maintainership (where group is myself and Benjamin Tissoires), therefore this pull request updates MAINTAINERS accordingly - fix for hid-asus config dependency from Arnd Bergmann - two device-specific quirks for i2c-hid from Julian Sax and Kai-Heng Feng - other few small assorted fixes * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: fix up .raw_event() documentation HID: asus: fix build warning wiht CONFIG_ASUS_WMI disabled HID: i2c-hid: add Direkt-Tek DTLAPY133-1 to descriptor override HID: moving to group maintainership model HID: alps: allow incoming reports when only the trackstick is opened Revert "HID: add NOGET quirk for Eaton Ellipse MAX UPS" HID: i2c-hid: Add a small delay after sleep command for Raydium touchpanel HID: hiddev: fix potential Spectre v1
2018-11-07rtc: pcf2127: fix a kmemleak caused in pcf2127_i2c_gather_writeXulin Sun1-0/+3
pcf2127_i2c_gather_write() allocates memory as local variable for i2c_master_send(), after finishing the master transfer, the allocated memory should be freed. The kmemleak is reported: unreferenced object 0xffff80231e7dba80 (size 64): comm "hwclock", pid 27762, jiffies 4296880075 (age 356.944s) hex dump (first 32 bytes): 03 00 12 03 19 02 11 13 00 80 98 18 00 00 ff ff ................ 00 50 00 00 00 00 00 00 02 00 00 00 00 00 00 00 .P.............. backtrace: [<ffff000008221398>] create_object+0xf8/0x278 [<ffff000008a96264>] kmemleak_alloc+0x74/0xa0 [<ffff00000821070c>] __kmalloc+0x1ac/0x348 [<ffff0000087ed1dc>] pcf2127_i2c_gather_write+0x54/0xf8 [<ffff0000085fd9d4>] _regmap_raw_write+0x464/0x850 [<ffff0000085fe3f4>] regmap_bulk_write+0x1a4/0x348 [<ffff0000087ed32c>] pcf2127_rtc_set_time+0xac/0xe8 [<ffff0000087eaad8>] rtc_set_time+0x80/0x138 [<ffff0000087ebfb0>] rtc_dev_ioctl+0x398/0x610 [<ffff00000823f2c0>] do_vfs_ioctl+0xb0/0x848 [<ffff00000823fae4>] SyS_ioctl+0x8c/0xa8 [<ffff000008083ac0>] el0_svc_naked+0x34/0x38 [<ffffffffffffffff>] 0xffffffffffffffff Signed-off-by: Xulin Sun <[email protected]> Signed-off-by: Alexandre Belloni <[email protected]>
2018-11-07rtc: hctosys: Add missing range error reportingMaciej W. Rozycki1-1/+3
Fix an issue with the 32-bit range error path in `rtc_hctosys' where no error code is set and consequently the successful preceding call result from `rtc_read_time' is propagated to `rtc_hctosys_ret'. This in turn makes any subsequent call to `hctosys_show' incorrectly report in sysfs that the system time has been set from this RTC while it has not. Set the error to ERANGE then if we can't express the result due to an overflow. Signed-off-by: Maciej W. Rozycki <[email protected]> Fixes: b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow time_t") Cc: [email protected] # 4.17+ Signed-off-by: Alexandre Belloni <[email protected]>
2018-11-07rtc: cmos: Do not export alarm rtc_ops when we do not support alarmsHans de Goede1-4/+12
When there is no IRQ configured for the RTC, the rtc-cmos code does not support alarms, all alarm rtc_ops fail with -EIO / -EINVAL. The rtc-core expects a rtc driver which does not support rtc alarms to not have alarm ops at all. Otherwise the wakealarm sysfs attr will read as empty rather then returning an error, making it impossible for userspace to find out beforehand if alarms are supported. A system without an IRQ for the RTC before this patch: [root@localhost ~]# cat /sys/class/rtc/rtc0/wakealarm [root@localhost ~]# After this patch: [root@localhost ~]# cat /sys/class/rtc/rtc0/wakealarm cat: /sys/class/rtc/rtc0/wakealarm: No such file or directory [root@localhost ~]# This fixes gnome-session + systemd trying to use suspend-then-hibernate, which causes systemd to abort the suspend when writing the RTC alarm fails. BugLink: https://github.com/systemd/systemd/issues/9988 Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Alexandre Belloni <[email protected]>
2018-11-07drm/i915/csr: fix spelling mistake "firmare" -> "firmware"Colin Ian King1-1/+1
Trivial fix to spelling mistake in DRM_INFO message Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-11-07drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5Chris Wilson1-2/+36
Exercising the gpu reloc path strenuously revealed an issue where the updated relocations (from MI_STORE_DWORD_IMM) were not being observed upon execution. After some experiments with adding pipecontrols (a lot of pipecontrols (32) as gen4/5 do not have a bit to wait on earlier pipe controls or even the current on), it was discovered that we merely needed to delay the EMIT_INVALIDATE by several flushes. It is important to note that it is the EMIT_INVALIDATE as opposed to the EMIT_FLUSH that needs the delay as opposed to what one might first expect -- that the delay is required for the TLB invalidation to take effect (one presumes to purge any CS buffers) as opposed to a delay after flushing to ensure the writes have landed before triggering invalidation. Testcase: igt/gem_tiled_fence_blits Signed-off-by: Chris Wilson <[email protected]> Cc: [email protected] Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-11-07mm, drm/i915: mark pinned shmemfs pages as unevictableKuo-Hsin Yang1-4/+29
The i915 driver uses shmemfs to allocate backing storage for gem objects. These shmemfs pages can be pinned (increased ref count) by shmem_read_mapping_page_gfp(). When a lot of pages are pinned, vmscan wastes a lot of time scanning these pinned pages. In some extreme case, all pages in the inactive anon lru are pinned, and only the inactive anon lru is scanned due to inactive_ratio, the system cannot swap and invokes the oom-killer. Mark these pinned pages as unevictable to speed up vmscan. Export pagevec API check_move_unevictable_pages(). This patch was inspired by Chris Wilson's change [1]. [1]: https://patchwork.kernel.org/patch/9768741/ Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Dave Hansen <[email protected]> Signed-off-by: Kuo-Hsin Yang <[email protected]> Acked-by: Michal Hocko <[email protected]> # mm part Reviewed-by: Chris Wilson <[email protected]> Acked-by: Dave Hansen <[email protected]> Acked-by: Andrew Morton <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Chris Wilson <[email protected]>
2018-11-07Merge tag 'gvt-fixes-2018-11-07' of https://github.com/intel/gvt-linux into ↵Joonas Lahtinen4-64/+70
drm-intel-fixes gvt-fixes-2018-11-07 - Fix invalidate of old ggtt entry (Hang) - Fix partial ggtt entry update in any order (Hang) - Fix one mask setting for chicken reg (Xinyun) - Fix eDP warning in guest (Longhe) Signed-off-by: Joonas Lahtinen <[email protected]> From: Zhenyu Wang <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-11-07cpufreq: imx6q: add return value check for voltage scaleAnson Huang1-1/+6
Add return value check for voltage scale when ARM clock rate change fail. Signed-off-by: Anson Huang <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-11-06scsi: qla2xxx: Initialize port speed to avoid setting lower speedQuinn Tran1-0/+1
This patch initializes port speed so that firmware does not set lower operating speed. Setting lower speed in firmware impacts WRITE perfomance. Fixes: 726b85487067 ("qla2xxx: Add framework for async fabric discovery") Cc: <[email protected]> Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Himanshu Madhani <[email protected]> Tested-by: Laurence Oberman <[email protected]> Reviewed-by: Ewan D. Milne <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2018-11-06Revert "scsi: ufs: Disable blk-mq for now"Martin K. Petersen1-7/+0
This reverts commit d87161bea405e3260377026ca8a704a3f68bd67a. The issues that forced us to disable blk_mq for ufs have been resolved. Signed-off-by: Martin K. Petersen <[email protected]>
2018-11-07Merge tag 'exynos-drm-fixes-for-v4.20-rc2' of ↵Dave Airlie5-25/+12
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes Three regressions - Revert frame counter support . This patch fixes a issue which doesn't work extension and clone mode because some CRTC devices don't provide frame counter value properly. - Fix lack of fbdev on Rinato and trats boards. . This patch considers for connector to be registered by DSI after DRM device is registered, and also it makes fbdev initializaion to be done even if no connector at the moment. - Check for dsi->panel object correctly . This patch fixes checking for dsi->panel. of_drm_find_panel function returns panel object or error value so error value should be checked using IS_ERR macro. Signed-off-by: Dave Airlie <[email protected]> From: Inki Dae <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-11-07Merge branch 'etnaviv/fixes' of https://git.pengutronix.de/git/lst/linux ↵Dave Airlie1-1/+1
into drm-fixes Single etnaviv fence fix for GPU recovery. Signed-off-by: Dave Airlie <[email protected]> From: Lucas Stach <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-11-06drm/amdgpu/display/dce11: only enable FBC when selectedAlex Deucher1-1/+2
Causes a black screen on a Stoney laptop. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=108577 Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-06drm/amdgpu/display/dm: handle FBC dc feature parameterAlex Deucher1-0/+3
Set the dc_config properly when the option is enabled. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-06drm/amdgpu/display/dc: add FBC to dc_configAlex Deucher1-0/+1
Add FBC to the list of features that can be enabled from the DM. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-06drm/amdgpu: add DC feature mask module parameterAlex Deucher3-0/+16
Similar to ppfeaturemask. Allows you to selectively enable/disable DC features. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-11-06drm/amdgpu/display: check if fbc is available in set_static_screen_control (v2)Alex Deucher1-1/+6
The value is dependent on whether fbc is available. v2: only check if num_pipes is valid Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.