Missing support for module parameters
At least display module parameters like: enable_fbc, modeset, enable_psr... should also be available in Xe.
Activity
assigned to @demarchi
I was taking a look in this since I'm cleaning up some areas nearby, however I noticed this comment today:
"Module parameters that can be adjusted at runtime are used for historic reasons, and we need to come up with a better uapi for them. We should talk with @airlied to determine whether to move them to atomic properties, debugfs or configfs (sysfs?)."
So, I'm not sure we want to keep using module params or part ways with it and just initialize the values to please the display side in some other ways. I think @mattrope was investigating the use of configfs for that, so adding him here. Also @mlankhorst FYI if you have already a plan for that.
atomic properties is a bad idea, users uses it to disable certain features that are causing issues(fbc, psr, mst...). debugfs would only disable features after driver load, what could be too late for some features.
But I agree that current solution don't scale for multiple GPUs, maybe a combination of module parameters + debugfs per device?
@zehortigoza , I was looking at configfs as a possibility for the developer/debug-specific knobs since that will let us adjust settings on a per-device (rather than per-driver) basis, before the device is probed. The general flow is a bit more complicated than just setting a module parameter, but if we're only using this for the kernel-tainting items intended specifically for kernel devs, the extra complexity is probably okay (and maybe even beneficial if it discourages end users from just copy/pasting dangerous settings they don't really understand):
mount -t configfs none /config echo 0 > /sys/bus/pci/drivers_autoprobe modprobe xe mkdir /config/0000:00:02.0 echo 0 > /config/0000:00:02.0/enable_foo echo 0000:02:00.0 > /sys/bus/pci/drivers/xe/bindI don't have a POC ready yet since I've been busy with other work, but when I get a chance I'll try to float something and see what people think.
enable_psr, enable_fbc, invert_brightness, enable_dpcd_backlight, enable_dp_mst...
All of those are in some Arch Linux wiki page as recommendation as workaround for issues.
- https://wiki.archlinux.org/title/intel_graphics
- https://wiki.archlinux.org/title/backlight
- https://wiki.archlinux.org/title/Dell_XPS_13_2-in-1_(7390)
Not only Arch Linux users uses Arch Linux wiki.
@zehortigoza, I think guidance like those wiki pages are providing is part of what we're trying to block. If disabling those features is truly correct/beneficial, then it's a driver bug that that it isn't happening automatically and we need to fix that asap. It's never correct for end users to be touching those knobs just to get their system to work properly.
If a user has an issue that is fixed by one of these parameters, what should they do without it?
Wait for us to fix it, then wait for the fix to land in their Linux kernel version so they can use their device with GPU acceleration again? They could roll back to an older kernel version, but what if that doesn't fix it for their new hardware?
I agree that we have too many i915 parameters, but some are necessary to work around issues.
unassigned @demarchi
added Improvement label
commit 8015bee0bfec6920f2441e5adc77e6ac2b65be8b Author: Jouni Högander <jouni.hogander@intel.com> Date: Tue Oct 24 15:40:47 2023 +0300 drm/i915/display: Add framework to add parameters specific to display Currently all module parameters are handled by i915_param.c/h. This is a problem for display parameters when Xe driver is used. Add a mechanism to add parameters specific to the display. This is mainly copied from i915_[debugfs]_params.[ch]. Parameters are not yet moved. This is done by subsequent patches.
