summaryrefslogtreecommitdiffstats
path: root/net/wireless/wext-priv.c (unfollow)
Commit message (Collapse)AuthorFilesLines
2023-02-15drm/i915/wm: add .get_hw_state to watermark funcsJani Nikula8-27/+40
Get rid of the if ladder in intel_modeset_setup_hw_state() and hide a number of functions by adding a .get_hw_state() hook to watermark functions. At least for now, combine the platform specific sanitization to the hw state readouts on the relevant platforms instead of adding a separate hook for that. There's a functional change on PCH split platforms: If i9xx_wm_init() fails to read plane latency and chooses the nop functions, ilk_wm_get_hw_state() won't get called for readout. Add the ilk_init_lp_watermarks() call on that path which now won't be called in .get_hw_state(), as it looks like the only thing that could make a difference. v2: - Add missing static (kernel test robot) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6da32831e40606cc8b90491b83196917f2ce36ab.1676317696.git.jani.nikula@intel.com
2023-02-15drm/i915/wm: move functions to call watermark hooks to intel_wm.[ch]Jani Nikula3-95/+119
Move the wrappers to call watermark hooks into intel_wm.[ch]. This declutters intel_display.c nicely. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2c8243c5c81b8cd8e34d51f55f3533373c305d0e.1676317696.git.jani.nikula@intel.com
2023-02-15drm/i915/wm: move remaining watermark code out of intel_pm.cJani Nikula12-3981/+4052
Add new files intel_wm.[ch] and i9xx_wm.[ch] under display/ to hold generic and pre-SKL watermark code, respectively. SKL+ watermark code has already been split out to skl_watermark.[ch]. Use the _wm.[ch] naming for brevity; we may want to rename skl_watermark.[ch] later accordingly. Add new intel_wm_init() to call either skl_wm_init() or i9xx_wm_init(i915) depending on the platform, the latter comprising of the remains of intel_init_pm(). Sprinkle in some minor checkpatch fixes while moving the code. v2: - Rebase - Fix copyright year Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ddf04a07a37f0368b3fef85d4ebb924082fec6cd.1676317696.git.jani.nikula@intel.com
2023-02-15drm/i915: move memory frequency detection to intel_dram.cJani Nikula3-130/+152
The memory frequency detection is a bit spread out here and there. Consolidate to intel_dram.c. v2: - Remove inaccurate comment (Ville) - Call detect_mem_freq() unconditionally (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8a862eeca8b42a98e04b3c52637851d33531abb6.1676317696.git.jani.nikula@intel.com
2023-02-15drm/i915: Sanitize the display fused-off check on GEN7/8Imre Deak1-2/+0
Detecting in intel_device_info_runtime_init() that the display is fused off or not present should only zero intel_runtime_info::pipe_mask, while the other related masks will be accordingly zeroed later in the function. Remove the redundant zeroing of the related fields on GEN7/8. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208114300.3123934-5-imre.deak@intel.com
2023-02-15drm/i915/dgfx, mtl+: Disable display functionality if the display is not presentImre Deak2-0/+11
DG1/DG2 and MTL+ has added a new display-present HW flag. Check this flag and if cleared, disable the driver's display functionality. So far the missing check resulted in running the display initialization sequence, and the WARNs below, due to the display register accesses timing out: [ 3.902843] ------------[ cut here ]------------ [ 3.902848] i915 0000:03:00.0: drm_WARN_ON(intel_de_wait_for_set(dev_priv, ((const i915_reg_t){ .reg = (0x42000) }), (1 << (27 - (pg))), 1)) [ 3.902879] WARNING: CPU: 6 PID: 462 at drivers/gpu/drm/i915/display/intel_display_power_well.c:326 gen9_wait_for_power_well_fuses+0x71/0x80 [i915] [ 3.903009] Modules linked in: hid_sensor_hub intel_ishtp_hid i915(+) rtsx_pci_sdmmc drm_buddy mmc_core drm_display_helper crct10dif_pclmul nvme cec crc32_pclmul intel_ish_ipc crc32c_intel ucsi_acpi hid_multitouch nvme_core ghash_clmulni_intel typec_ucsi rtsx_pci ttm sha512_ssse3 serio_raw intel_ishtp typec video i2c_hid_acpi i2c_hid wmi pinctrl_tigerlake ip6_tables ip_tables x_tables fuse [ 3.903021] CPU: 6 PID: 462 Comm: systemd-udevd Tainted: G U 6.2.0-rc6+ #50 [ 3.903023] Hardware name: LENOVO 82VB/LNVNB161216, BIOS KMCN09WW 04/26/2022 [ 3.903023] RIP: 0010:gen9_wait_for_power_well_fuses+0x71/0x80 [i915] [ 3.903105] Code: 48 8b 5f 50 48 85 db 75 03 48 8b 1f e8 98 bb 0d e9 48 c7 c1 00 65 a1 c0 48 89 da 48 c7 c7 4b c5 a3 c0 48 89 c6 e8 e3 df 53 e9 <0f> 0b 5b c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 [ 3.903106] RSP: 0018:ffffa7cec0b07a98 EFLAGS: 00010292 [ 3.903107] RAX: 0000000000000080 RBX: ffff9a05430eaaa0 RCX: 0000000000000000 [ 3.903108] RDX: 0000000000000001 RSI: ffffffffaa7ab69e RDI: 00000000ffffffff [ 3.903108] RBP: ffff9a0552ba2020 R08: ffffffffab062ce0 R09: 00000000abd3ffc2 [ 3.903109] R10: ffffffffffffffff R11: 0000000000000081 R12: 0000000000000000 [ 3.903109] R13: ffff9a05532a9cb0 R14: ffffffffc09e1670 R15: ffff9a0543132000 [ 3.903110] FS: 00007f24d0fe5b40(0000) GS:ffff9a0ccf780000(0000) knlGS:0000000000000000 [ 3.903110] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.903111] CR2: 00005643d7a31a28 CR3: 0000000111614002 CR4: 0000000000770ee0 [ 3.903112] PKRU: 55555554 [ 3.903112] Call Trace: [ 3.903113] <TASK> [ 3.903114] hsw_power_well_enable+0x12f/0x1a0 [i915] [ 3.903191] intel_power_well_enable+0x21/0x70 [i915] [ 3.903265] icl_display_core_init+0x92/0x6a0 [i915] [ 3.903346] intel_power_domains_init_hw+0x1da/0x5b0 [i915] [ 3.903422] intel_modeset_init_noirq+0x60/0x250 [i915] [ 3.903497] i915_driver_probe+0x562/0xe10 [i915] [ 3.903557] ? i915_pci_probe+0x87/0x180 [i915] [ 3.903617] local_pci_probe+0x3e/0x80 [ 3.903621] pci_device_probe+0xb3/0x210 [ 3.903622] really_probe+0xdb/0x380 [ 3.903624] ? pm_runtime_barrier+0x50/0x90 [ 3.903626] __driver_probe_device+0x78/0x170 [ 3.903627] driver_probe_device+0x1f/0x90 [ 3.903628] __driver_attach+0xce/0x1c0 [ 3.903629] ? __pfx___driver_attach+0x10/0x10 [ 3.903630] bus_for_each_dev+0x5f/0x90 [ 3.903631] bus_add_driver+0x1ae/0x200 [ 3.903632] driver_register+0x89/0xe0 [ 3.903634] i915_init+0x1f/0x7f [i915] [ 3.903695] ? __pfx_init_module+0x10/0x10 [i915] [ 3.903751] do_one_initcall+0x43/0x220 [ 3.903753] ? kmalloc_trace+0x26/0x90 [ 3.903756] do_init_module+0x4a/0x200 [ 3.903758] __do_sys_init_module+0x157/0x180 [ 3.903760] do_syscall_64+0x58/0xc0 [ 3.903762] ? do_syscall_64+0x67/0xc0 [ 3.903762] ? exc_page_fault+0x70/0x170 [ 3.903764] entry_SYSCALL_64_after_hwframe+0x72/0xdc Bspec: 49189, 53112 v2: (Jani) - Change "Display fused off" dmesg info to "Display not present". - Zero only runtime->pipe_mask, other fields being zeroed based on this later. - Detect display presence already before the fused-off checks and only for HAS_DISPLAY(). v3: Fix "preset" vs "present" typo. Reported-and-tested-by: iczero <iczero@hellomouse.net> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8015 Cc: iczero <iczero@hellomouse.net> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208114300.3123934-4-imre.deak@intel.com
2023-02-15drm/i915: Move display power initialization during driver probing laterImre Deak2-7/+5
Determining whether the display engine is present on a platform happens only in intel_device_info_runtime_init(). Initializing the display power functionality depends on this condition, so move intel_power_domains_init() later after the runtime init function has been called. The next patch fixing platforms without display, depends on this patch. Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208114300.3123934-3-imre.deak@intel.com
2023-02-15drm/i915: Fix system suspend without fbdev being initializedImre Deak1-1/+7
If fbdev is not initialized for some reason - in practice on platforms without display - suspending fbdev should be skipped during system suspend, fix this up. While at it add an assert that suspending fbdev only happens with the display present. This fixes the following: [ 91.227923] PM: suspend entry (s2idle) [ 91.254598] Filesystems sync: 0.025 seconds [ 91.270518] Freezing user space processes [ 91.272266] Freezing user space processes completed (elapsed 0.001 seconds) [ 91.272686] OOM killer disabled. [ 91.272872] Freezing remaining freezable tasks [ 91.274295] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 91.659622] BUG: kernel NULL pointer dereference, address: 00000000000001c8 [ 91.659981] #PF: supervisor write access in kernel mode [ 91.660252] #PF: error_code(0x0002) - not-present page [ 91.660511] PGD 0 P4D 0 [ 91.660647] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 91.660875] CPU: 4 PID: 917 Comm: bash Not tainted 6.2.0-rc7+ #54 [ 91.661185] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20221117gitfff6d81270b5-9.fc37 unknown [ 91.661680] RIP: 0010:mutex_lock+0x19/0x30 [ 91.661914] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 53 48 89 fb e8 62 d3 ff ff 31 c0 65 48 8b 14 25 00 15 03 00 <f0> 48 0f b1 13 75 06 5b c3 cc cc cc cc 48 89 df 5b eb b4 0f 1f 40 [ 91.662840] RSP: 0018:ffffa1e8011ffc08 EFLAGS: 00010246 [ 91.663087] RAX: 0000000000000000 RBX: 00000000000001c8 RCX: 0000000000000000 [ 91.663440] RDX: ffff8be455eb0000 RSI: 0000000000000001 RDI: 00000000000001c8 [ 91.663802] RBP: ffff8be459440000 R08: ffff8be459441f08 R09: ffffffff8e1432c0 [ 91.664167] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [ 91.664532] R13: 00000000000001c8 R14: 0000000000000000 R15: ffff8be442f4fb20 [ 91.664905] FS: 00007f28ffc16740(0000) GS:ffff8be4bb900000(0000) knlGS:0000000000000000 [ 91.665334] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 91.665626] CR2: 00000000000001c8 CR3: 0000000114926006 CR4: 0000000000770ee0 [ 91.665988] PKRU: 55555554 [ 91.666131] Call Trace: [ 91.666265] <TASK> [ 91.666381] intel_fbdev_set_suspend+0x97/0x1b0 [i915] [ 91.666738] i915_drm_suspend+0xb9/0x100 [i915] [ 91.667029] pci_pm_suspend+0x78/0x170 [ 91.667234] ? __pfx_pci_pm_suspend+0x10/0x10 [ 91.667461] dpm_run_callback+0x47/0x150 [ 91.667673] __device_suspend+0x10a/0x4e0 [ 91.667880] dpm_suspend+0x134/0x270 [ 91.668069] dpm_suspend_start+0x79/0x80 [ 91.668272] suspend_devices_and_enter+0x11b/0x890 [ 91.668526] pm_suspend.cold+0x270/0x2fc [ 91.668737] state_store+0x46/0x90 [ 91.668916] kernfs_fop_write_iter+0x11b/0x200 [ 91.669153] vfs_write+0x1e1/0x3a0 [ 91.669336] ksys_write+0x53/0xd0 [ 91.669510] do_syscall_64+0x58/0xc0 [ 91.669699] ? syscall_exit_to_user_mode_prepare+0x18e/0x1c0 [ 91.669980] ? syscall_exit_to_user_mode_prepare+0x18e/0x1c0 [ 91.670278] ? syscall_exit_to_user_mode+0x17/0x40 [ 91.670524] ? do_syscall_64+0x67/0xc0 [ 91.670717] ? __irq_exit_rcu+0x3d/0x140 [ 91.670931] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 91.671202] RIP: 0033:0x7f28ffd14284 v2: CC stable. (Jani) Fixes: f8cc091e0530 ("drm/i915/fbdev: suspend HPD before fbdev unregistration") References: https://gitlab.freedesktop.org/drm/intel/-/issues/8015 Reported-and-tested-by: iczero <iczero@hellomouse.net> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: iczero <iczero@hellomouse.net> Cc: <stable@vger.kernel.org> # v6.1+ Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208114300.3123934-2-imre.deak@intel.com
2023-02-14drm/i915: Use encoder->devdata in eDP initVille Syrjälä3-20/+15
Since we now populate encoder->devdata for all DP capable platforms we can consult it directly during the eDP connector init instead of taking a detour via some global list/array. Unfortunately we can't quite get rid of intel_dp_is_port_edp() since it's still used by the higher level ilk/vlv/chv output setup code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-11-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-14drm/i915: Iterate all child devs in intel_bios_is_port_present()Ville Syrjälä1-1/+13
Instead of consulting vbt.ports[] lets just go through the whole child device list to check whether a specific port was declared by the VBT or not. Note that this doesn't change anything wrt. detecting duplicate child devices with the same port as vbt.ports[] would also always contain exactly one of the duplicates. v2: Include a is_port_valid() check to deal with some broken VBTs Mention something about duplicate port detection (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230214073818.20231-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-14drm/i915: Pass devdata to intel_bios_port_aux_ch()Ville Syrjälä5-5/+7
Currently intel_bios_port_aux_ch() digs out the devdata (VBT child device info) from the vbt.ports[] array. We need to get rid of that, so just pass in the correct encoder->devdata (now that we have it also for g4x+ ports) directly. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-14drm/i915: Populate encoder->devdata for g4x+ DP/HDMI portsVille Syrjälä2-0/+20
Let's make encoder->devdata (the VBT information for the port) available on g4x+ platforms as well. Much easier when you can just grab it there instead of trying to find it from some global list array based on the port. Note that (unlike DDI platforms) we don't currently require that each DP/HDMI port is actually declared in VBT. Perhaps in the future we may want to rethink that, but for now just stick in a debug+FIXME as a reminder. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-14drm/i915: Consult the registered encoders for the ICL combo PHY w/aVille Syrjälä1-1/+14
Display WA #1178 calls us to tweak some magic bits when doing AUX to an external combo PHY port. Instead of looking to see if the VBT has declared such a port (which could in theory even alias with a declared eDP port on the same PHY) just check the real situation based on the registered encoders. The only slight chicken vs. egg situation here is during output probing. But typically we'd register the eDP ports first and so once we get to probe anything external on the combo PHY we have already determined if it's eDP or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-14drm/i915: Replace intel_bios_is_port_hpd_inverted() with ↵Ville Syrjälä3-26/+9
intel_bios_encoder_hpd_invert() intel_bios_is_port_hpd_inverted() is only used on bxt/glk on which we always have encoder->devdata available. So consult that instead of digging around in vbt.ports[]. And rename the function to match the common pattern. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-14drm/i915: Replace intel_bios_is_lane_reversal_needed() with ↵Ville Syrjälä3-19/+7
intel_bios_encoder_lane_reversal() The sole user of intel_bios_is_lane_reversal_needed() has the devdata already located, so pass it in directly instead of digging it again from vbt.ports[]. And rename the function to follow the common pattern for these things. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-14drm/i915: Replace intel_bios_is_lspcon_present() with ↵Ville Syrjälä6-27/+19
intel_bios_encoder_is_lspcon() We always have encoder->devdata available on the platforms that can have LSPCON. So let's start looking there instead of digging it out from vbt.ports[]. And let's rename the function to fit the common pattern for these things. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-14drm/i915: Move variables to loop contextVille Syrjälä1-20/+12
Lot of the loops over VBT child devices have variables declared outside the loop but only used inside the loop. Move the variables to a tighter scope. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-14drm/i915: Pass the whole encoder to hotplug_enables()Ville Syrjälä1-30/+24
bxt_hotplug_enables() needs to dig out not only the hpd_pin but also the VBT child device info, so let's just pass in the whole encoder to avoid having to look things up multiple times. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-14drm/i915/dp: Increase slice_height for DPSuraj Kandpal1-11/+23
According VDSC spec 1.2a Section 3.8 Options for Slice implies that 108 lines is an optimal slice height, but any size can be used as long as vertical active integer multiple and maximum vertical slice count requirements are met. Bspec: 49259 --v3 -remove previous fallback code and return slice_height as 2 [Jani] Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230214052017.3312044-1-suraj.kandpal@intel.com
2023-02-10drm/i915: Prefix hex numbers with 0xVille Syrjälä1-3/+3
It's hard to figure out whether the number is hex or decimal if doesn't have the 0x to indicate hex. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130181701.29977-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-10drm/i915: Include stepping information in device info dumpVille Syrjälä1-0/+5
Dump the stepping information alongside all the other device info. Might avoid some guesswork when reading logs. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130181701.29977-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-10drm/i915/display: Pass drm_i915_private as param to i915 funcsNirmoy Das4-10/+10
For i915 functions pass struct drm_i915_private directly instead of struct drm_device. v2: Use to_i915(dev) directly without alias(Andrzej). Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125095603.17845-1-nirmoy.das@intel.com
2023-02-10drm/i915: Replace wm.max_levels with wm.num_levels and use it everywhereVille Syrjälä5-93/+70
Replaces wm.max_level with wm.num_levels, since that generally results in nicer looking code (for-loops can be in standard form etc.). Also get rid of the two different wrappers we have for this (ilk_wm_max_level() and intel_wm_num_levels()). They don't really do anything for us other than potentially slow things down if the compiler actually emits the function calls every time (num_planes*num_wm_levels*higher_level_wm_function_calls could be a big number). The watermark code already shows up far too prominently in cpu profiles. Though I must admit that I didn't look at the generated code this time. v2: Fix the ilk_wm_merge() off-by-one (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230209222504.31478-1-ville.syrjala@linux.intel.com
2023-02-10drm/i915: Populate wm.max_level for everyoneVille Syrjälä3-27/+14
Switch ilk+ and skl+ platforms to also setting up wm.max_level and remove a bunch of if ladders as a result. There will be a tiny change in the debugfs on CHV machines that have DVFS disabled in the BIOS. Presviously debugfs would show the latency for the DVFS level as well, but that will no longer be the case. Which is arguably better as that number is absolutely meaningless when DVFS can't be enabled anyway. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230209003251.32021-1-ville.syrjala@linux.intel.com
2023-02-09drm/i915/mtl: Initialize empty clockgating hooks for MTLRadhakrishna Sripada1-1/+3
Clock gating hooks to be initialized for MTL are yet to be implemented. Use a nop till we identify relevant WA's here. Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230111235531.3353815-3-radhakrishna.sripada@intel.com
2023-02-09drm/i915/dg2: Drop one PCI IDMatt Roper1-1/+0
The bspec was recently updated to remove PCI ID 0x5698; this ID is actually reserved for future use and should not be treated as DG2-G11. Bspec: 44477 Fixes: 8618b8489ba6 ("drm/i915: DG2 and ATS-M device ID updates") Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208200905.680865-1-matthew.d.roper@intel.com
2023-02-08Revert "drm/i915/hwmon: Enable PL1 power limit"Ashutosh Dixit1-5/+0
This reverts commit 0349c41b05968befaffa5fbb7e73d0ee6004f610. 0349c41b0596 ("drm/i915/hwmon: Enable PL1 power limit") is incorrect and caused a major regression on ATSM. The change enabled the PL1 power limit but FW sets the default value of the PL1 limit to 0 which implies HW now works at minimum power and therefore the lowest effective frequency. This means all workloads now run slower resulting in even GuC FW load operations timing out, rendering ATSM unusable. A different solution to the original issue of the PL1 limit being disabled on ATSM is needed but till that is developed, revert 0349c41b0596. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8062 Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208190312.1611335-1-ashutosh.dixit@intel.com
2023-02-08drm/i915/bios: set default backlight controller indexJani Nikula1-0/+1
With backlight controller set to -1 in intel_panel_init_alloc() to distinguish uninitialized values, and controller later being set only if it's present in VBT, we can end up with -1 for the controller: [drm:intel_bios_init_panel [i915]] VBT backlight PWM modulation frequency 200 Hz, active high, min brightness 0, level 255, controller 4294967295 There's no harm if it happens on platforms that ignore controller due to only one backlight controller being present, like on VLV above, but play it safe. Fixes: bf38bba3e7d6 ("drm/i915: Try to use the correct power sequencer intiially on bxt/glk") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207111626.1839645-1-jani.nikula@intel.com
2023-02-08drm/i915/uncore: cast iomem to avoid sparse warningJani Nikula1-2/+3
drmm_add_action_or_reset() is unaware of __iomem and the pointer needs to be a plain void *. Cast __iomem away and back while the pointer goes through drmm. drivers/gpu/drm/i915/intel_uncore.c:2463:17: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915/intel_uncore.c:2463:17: expected void volatile [noderef] __iomem *addr drivers/gpu/drm/i915/intel_uncore.c:2463:17: got void *regs drivers/gpu/drm/i915/intel_uncore.c:2494:16: warning: incorrect type in argument 3 (different address spaces) drivers/gpu/drm/i915/intel_uncore.c:2494:16: expected void *data drivers/gpu/drm/i915/intel_uncore.c:2494:16: got void [noderef] __iomem *regs Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207124026.2105442-2-jani.nikula@intel.com
2023-02-08drm/i915/dmc: drop "ucode" from function namesJani Nikula4-20/+20
The ucode part in the init, fini, suspend and resume function names is just unnecessary. Drop it. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207110619.1821992-1-jani.nikula@intel.com
2023-02-08drm/i915: Pick the backlight controller based on VBT on ICP+Ville Syrjälä1-3/+31
Use the second backlight controller on ICP+ if the VBT asks us to do so. On pre-MTP we also check the chicken bit to make sure the pins have been correctly muxed by the firmware. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-08drm/i915: Populate encoder->devdata for DSI on icl+Ville Syrjälä2-4/+14
We now have some eDP+DSI dual panel systems floating around where the DSI panel is the secondary LFP and thus needs to consult "panel type 2" in VBT in order to locate all the other panel type dependant stuff correctly. To that end we need to pass in the devdata to intel_bios_init_panel_late(), otherwise it'll just assume we want the primary panel type. So let's try to just populate the vbt.ports[] stuff and encoder->devdata for icl+ DSI panels as well. We can't do this on older platforms as there we risk a DSI port aliasing with a HDMI/DP port, which is a totally legal thing as the DSI ports live in their own little parallel universe. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-08drm/i915: Fix VBT DSI DVO port handlingVille Syrjälä1-10/+23
Turns out modern (icl+) VBTs still declare their DSI ports as MIPI-A and MIPI-C despite the PHYs now being A and B. Remap appropriately to allow the panels declared as MIPI-C to work. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-06drm/i915: Fix memory leaks in scatterlistMatt Atwood1-2/+6
This patch fixes memory leaks on error escapes in i915_scatterlist.c Fixes: c3bfba9a2225 ("drm/i915: Check for integer truncation on scatterlist creation") Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230201232801.123684-1-matthew.s.atwood@intel.com
2023-02-06drm/i915: Add another EHL pci idJonathan Gray1-0/+1
described as "32 Execution Unit (EU) Super SKU" in: Intel Atom x6000E Series, and Intel Pentium and Celeron N and J Series Processors for IoT Applications Datasheet, Volume 1 Document Number: 636112-1.6 Signed-off-by: Jonathan Gray <jsg@jsg.id.au> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230206043727.46069-1-jsg@jsg.id.au
2023-02-06drm/i915/hwmon: Enable PL1 power limitAshutosh Dixit1-0/+5
Previous documentation suggested that PL1 power limit is always enabled. However we now find this not to be the case on some platforms (such as ATSM). Therefore enable PL1 power limit during hwmon initialization. Bspec: 51864 v2: Add Bspec reference (Gwan-gyeong) v3: Add Fixes tag Fixes: 99f55efb79114 ("drm/i915/hwmon: Power PL1 limit and TDP setting") Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230203155309.1042297-1-ashutosh.dixit@intel.com
2023-02-03drm/i915/dsb: Introduce intel_dsb_finish()Ville Syrjälä3-4/+9
Introduce a function to emits whatever commands we need at the end of the DSB command buffer. For the moment we only do the tail cacheline alignment there, but eventually we might want to eg. emit an interrupt. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230118163040.29808-5-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2023-02-03drm/i915/dsb: Split intel_dsb_wait() from intel_dsb_commit()Ville Syrjälä3-3/+13
Starting the DSB execution vs. waiting for it stop are two totally different things. Split intel_dsb_wait() from intel_dsb_commit() so that we can eventually allow the DSB to execute asynchronously. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230118163040.29808-4-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2023-02-03drm/i915/dsb: Pimp debug/error printsVille Syrjälä1-4/+8
Print the crtc/DSB id information to make it clear which DSB engine we're talking about. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230118163040.29808-3-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2023-02-03drm/i915/fbdev: Implement fb_dirty for intel custom fb helperJouni Högander1-0/+12
After disconnecting damage worker from update logic it's left to fbdev emulation implementation to have fb_dirty function. Currently intel fbdev doesn't have it. This is causing problems to features (PSR, FBC, DRRS) relying on dirty callback. Implement simple fb_dirty callback to deliver notifications about updates in fb console. v4: Add proper Fixes tag and modify commit message v3: Check damage clip v2: Improved commit message and added Fixes tag Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker from update logic") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230123074437.475103-1-jouni.hogander@intel.com
2023-02-02drm/i915/dmc: check incoming dmc id validityJani Nikula1-2/+6
Add validity checks for the dmc ids computed from pipe parameters in intel_dmc_enable_pipe() and intel_dmc_disable_pipe(). It's slightly difficult for humans and static analyzers alike to ensure the resulting dmc ids are within bounds. Just check them and reject invalid ones. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6a349c3a2b2def5fc31a48c9844ebd72ee55a22b.1675339447.git.jani.nikula@intel.com
2023-02-02drm/i915/dmc: add is_valid_dmc_id() and use itJani Nikula1-1/+6
Add a name to the dmc id validity check. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/311213ce328575a95d793a219d4dac7d947086cc.1675339447.git.jani.nikula@intel.com
2023-02-02drm/i915/dmc: remove unnecessary dmc_id validity checkJani Nikula1-5/+0
The dmc_id comes from for_each_dmc_id() in parse_dmc_fw() -> parse_dmc_fw_header() -> dmc_mmio_addr_sanity_check(). It's valid by definition. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b4e1c862687f79861a5fa4bfa6797ecda2136fab.1675339447.git.jani.nikula@intel.com
2023-02-02drm/i915/dmc: add for_each_dmc_id() and use itJani Nikula1-6/+9
The loop is duplicated many times, with slightly different ways. Unify. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8dcaa716093e6fbe75bb69ee7ac715a3f007a523.1675339447.git.jani.nikula@intel.com
2023-02-02drm/i915/dmc: add proper name to dmc id enum and use itJani Nikula2-40/+39
Clarify DMC ID usage by adding enum intel_dmc_id name to the enum, and use dmc_id as the variable name for it throughout. Convert a switch-case to if-ladder to avoid warnings about not handling DMC_FW_MAX enumeration constant in the switch-case. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6912ccb411bb957c68c108b774745dbc7e0cbdc2.1675339447.git.jani.nikula@intel.com
2023-02-01drm/i915: Expose SAGV state via debugfsVille Syrjälä3-7/+28
Since SAGV is controlled via unidirectional pcode commands we have no way to query the current state. So instead let's expose the last programmed state via debugfs. This way we can at least know whether SAGV should be enabled or not (which can be important to know when dealing with underruns/etc.). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230131002127.29305-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-01drm/i915: Keep sagv status updated on icl+Ville Syrjälä1-20/+29
On icl+ SAGV is controlled by masking of the QGV points. Reduce the QGV point mask to the same kind of enabled vs. disable information that we had on previous platforms. Will be useful in answering the question whether SAGV is actually enabled or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230131002127.29305-3-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2023-02-01drm/i915: Introduce HAS_SAGV()Ville Syrjälä2-4/+5
Introuce a HAS_SAGV() macro to answer the question whether the platform in general supports SAGV. intel_has_sagv() will keep on giving us the more specific answer whether the current device supports SAGV or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230131002127.29305-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-01drm/i915: Don't do the WM0->WM1 copy w/a if WM1 is already enabledVille Syrjälä1-1/+2
Due to a workaround we have to make sure the WM1 watermarks block/lines values are sensible even when WM1 is disabled. To that end we copy those values from WM0. However since we now keep each wm level enabled on a per-plane basis it doesn't seem necessary to do that copy when we already have an enabled WM1 on the current plane. That is, we might be in a situation where another plane can only do WM0 (and thus needs the copy) but the current plane's WM1 is still perfectly valid (ie. fits into the current DDB allocation). Skipping the copy could avoid reprogramming the plane's registers needlessly in some cases. Fixes: a301cb0fca2d ("drm/i915: Keep plane watermarks enabled more aggressively") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230131002127.29305-1-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2023-01-31drm/i915/lvds: s/pipe_config/crtc_state/Ville Syrjälä1-23/+23
Call the crtc state 'crtc_state' rather than 'pipe_config', as is the modern style. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-20 15:02:17 +0100