summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
3 daysdrm/{i915, xe}: Implement fbdev emulation as in-kernel clientdrm-intel-next-2024-04-26for-linux-nextdrm-intel-nextThomas Zimmermann5-140/+80
Replace all code that initializes or releases fbdev emulation throughout the driver. Instead initialize the fbdev client by a single call to intel_fbdev_setup() after i915 has registered its DRM device. Just like similar code in other drivers, i915 fbdev emulation now acts like a regular DRM client. Do the same for xe. The fbdev client setup consists of the initial preparation and the hot-plugging of the display. The latter creates the fbdev device and sets up the fbdev framebuffer. The setup performs display hot-plugging once. If no display can be detected, DRM probe helpers re-run the detection on each hotplug event. A call to drm_client_dev_unregister() releases all in-kernel clients automatically. No further action is required within i915. If the fbdev framebuffer has been fully set up, struct fb_ops.fb_destroy implements the release. For partially initialized emulation, the fbdev client reverts the initial setup. Do the same for xe and remove its call to intel_fbdev_fini(). v8: - setup client in intel_display_driver_register (Jouni) - mention xe in commit message v7: - update xe driver - reword commit message v6: - use 'i915' for i915 device (Jouni) - remove unnecessary code for non-atomic mode setting (Jouni, Ville) - fix function name in commit message (Jouni) v3: - as before, silently ignore devices without displays v2: - let drm_client_register() handle initial hotplug - fix driver name in error message (Jani) - fix non-fbdev build (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-7-tzimmermann@suse.de Signed-off-by: Jani Nikula <jani.nikula@intel.com>
3 daysdrm/{i915,xe}: Implement fbdev client callbacksThomas Zimmermann5-49/+25
Move code from ad-hoc fbdev callbacks into DRM client functions and remove the old callbacks. The functions instruct the client to poll for changed output or restore the display. The DRM core calls both, the old callbacks and the new client helpers, from the same places. The new functions perform the same operation as before, so there's no change in functionality. Fox xe, remove xe_display_last_close(), which restored the fbdev display. As with i915, the DRM core's drm_lastclose() performs this operation automatically. v8: - mention xe in commit message v7: - update xe driver v6: - return errors from client callbacks (Jouni) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-6-tzimmermann@suse.de Signed-off-by: Jani Nikula <jani.nikula@intel.com>
3 daysdrm/{i915,xe}: Unregister in-kernel clientsThomas Zimmermann2-0/+4
Unregister all in-kernel clients before unloading the i915 driver. For other drivers, drm_dev_unregister() does this automatically. As i915 and xe do not use this helper, they have to perform the call by themselves. Note that there are currently no in-kernel clients in i915 or xe. The patch prepares the drivers for a related update of their fbdev support. v8: - unregister clients in intel_display_driver_unregister() (Jani) - mention xe in commit message (Rodrigo, Jani) v7: - update xe driver Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-5-tzimmermann@suse.de Signed-off-by: Jani Nikula <jani.nikula@intel.com>
3 daysdrm/i915: Initialize fbdev DRM client with callback functionsThomas Zimmermann1-4/+39
Initialize i915's fbdev client by giving an instance of struct drm_client_funcs to drm_client_init(). Also clean up with drm_client_release(). Doing this in i915 prevents fbdev helpers from initializing and releasing the client internally (see drm_fb_helper_init()). No functional change yet; the client callbacks will be filled later. v6: - rename client to "intel-fbdev" (Jouni) v2: - call drm_fb_helper_unprepare() in error handling (Jani) - fix typo in commit message (Sam) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-4-tzimmermann@suse.de Signed-off-by: Jani Nikula <jani.nikula@intel.com>
3 daysdrm/i915: Move fbdev functionsThomas Zimmermann1-77/+77
Move functions within intel_fbdev.c to simplify later updates. Minor style fixes to make checkpatch happy, but no functional changes. v5: - style fixes (checkpatch) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-3-tzimmermann@suse.de Signed-off-by: Jani Nikula <jani.nikula@intel.com>
3 daysdrm/client: Export drm_client_dev_unregister()Thomas Zimmermann1-0/+13
Export drm_client_dev_unregister() for use by the i915 driver. The driver does not use drm_dev_unregister(), so it has to clean up the in-kernel DRM clients by itself. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-2-tzimmermann@suse.de Signed-off-by: Jani Nikula <jani.nikula@intel.com>
3 daysdrm/i915: pass dev_priv to _MMIO_PIPE2, _MMIO_TRANS2, _MMIO_CURSOR2Jani Nikula4-128/+128
Pass the dev_priv parameter to the low-level helpers, and move the implicit dev_priv usage one level higher. sed -i "s/\(_MMIO_PIPE2(\|_MMIO_TRANS2(\|_MMIO_CURSOR2(\)/\1dev_priv, /" \ $(git ls-files drivers/gpu/drm/i915) Name the parameter "display", as the generics allow it to be display already. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3a865664898586ff6cb8e74eab3d1f36eafc0557.1713890614.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
3 daysdrm/i915: convert _MMIO_PIPE3()/_MMIO_PORT3() to accept baseJani Nikula2-40/+44
Most users of _MMIO_PIPE3() and _MMIO_PORT3() need to add the MMIO base to the registers. Convert the macros to _MMIO_BASE_PIPE3() and _MMIO_BASE_PORT3() to move the base addition until after the register selection. If the register address depends on DISPLAY_MMIO_BASE(), this removes the need to figure the base out for each register, and it only needs to be added once. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4b95f125f5021abc00b5fc661b2728f1b583c01e.1713890614.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
5 daysdrm/i915/dsi: pass display to register macros instead of implicit variabledrm-intel-next-2024-04-24Jani Nikula4-342/+349
Stop relying on the dev_priv local variable in the DSI register macros. Pass struct intel_display pointer to the macros. Move the MIPI DSI MMIO base selection to a different level, passing it to _MMIO_MIPI() and doing the addition there. Start using the local display variable for all intel_de_* usage, and opportunistically use it for other things than display registers as well. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6dd52f3fce3527242479aadc276d05de74ceae5d.1713520813.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
5 daysdrm/i915/dsi: unify connector/encoder type and name usageJani Nikula1-74/+60
Stop using struct drm_* local variables and parameters where possible. Drop the intel_ prefix from struct intel_encoder and intel_connector local variable and parameter names. Drop useless intermediate variables. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7aa8fbaa2ecbe2400255964d49aba40cfe0479c5.1713520813.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
5 daysdrm/i915/dsi: add VLV_ prefix to VLV only register macrosJani Nikula2-5/+5
All the BXT specific macros have BXT_ prefix, do the same for VLV for consistency. This is helpful because the platform specific macros can use the static MIPI MMIO base rather than dynamic. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7e101167c52746748dbff739bc9247a664ca2840.1713520813.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
5 daysdrm/i915/dsi: remove unused _MIPIA_AUTOPWG register definitionJani Nikula1-3/+0
There are other unused registers, but this is also unusable and inadequate. Remove. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/57afda02856a68f78fe4d30384d4f7b352b9a812.1713520813.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
6 daysdrm/i915/display: move dmc_firmware_path to display paramsJani Nikula6-9/+6
The dmc_firmware_path parameter is clearly a display parameter. Move it there so it's available to both i915 and xe modules. This also cleans up the ugly member in struct xe_device. v2: - New try with the NULL/"" param value issue resolved Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7c8223b68fdafbc72bee0bf5afdb2ab15261cf00.1713519628.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
6 daysdrm/i915/dmc: change how to disable DMC firmware using module paramJani Nikula2-10/+24
The distinction between the dmc_firmware_path module param being NULL and the empty string "" is problematic. It's not possible to set the parameter back to NULL via sysfs or debugfs. Remove the distinction, and consider NULL and the empty string to be the same thing, and use the platform default for them. This removes the possibility to disable DMC (and runtime PM) via i915.dmc_firmware_path="". Instead, use "/dev/null" as the magic firmware path to skip DMC firmware loading and disable runtime PM. v2: Add support for i915.dmc_firmware_path="/dev/null" (Gustavo) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8695aca8a6643e36bb680bc2dcab97c637e70b00.1713519628.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
6 daysdrm/i915/dmc: split out per-platform firmware path selectionJani Nikula1-42/+54
The big if ladder clutters intel_dmc_init(). Split it out to a separate function. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/fe3d7b2b18c317a2f924f2023271d38afee3b18a.1713519628.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
6 daysdrm/i915/dmc: improve firmware parse failure propagationJani Nikula1-17/+24
Return failures from parse_dmc_fw() instead of relying on intel_dmc_has_payload(). Handle and error report them slightly better, including a new error message for when the firmware does not contain the main program. v2: Print specific error message for payload not found (Gustavo) Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/18833681978ec3ac779cce943221cc5b532c7c45.1713519628.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
6 daysdrm/i915/dmc: handle request_firmware() errors separatelyJani Nikula1-2/+9
Clarify request_firmware() error handling. Don't proceed to trying to parse non-existent firmware or check for payload when request_firmware() failed to begin with. There's no reason to release_firmware() either when request_firmware() failed. Also move the message about DMC firmware homepage here, as in other cases the user probably has some firmware, although its parsing fails for some reason. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0654bb3480f8d2103225d26f665badead5495532.1713519628.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
8 daysdrm/i915: Enable per-lane DP drive settings for bxt/glkVille Syrjälä1-1/+1
Now the bxt/glk PHY code is ready for per-lane drive settings so enable it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
8 daysdrm/i915/dpio: Program bxt/glk PHY TX registers per-laneVille Syrjälä1-13/+22
Program each bxt/glk PHY TX lane with its own settings instead of blasting them all with the same stuff via group access. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
8 daysdrm/i915/dpio: s/ddi/dpio/ for bxt/glk PHY stuffVille Syrjälä5-102/+102
Since all of this lives in intel_dpio_phy.c let's rename the bxt/glk functions to have bxt_dpio_phy_ namespace. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
8 daysdrm/i915/dpio: Use intel_de_rmw() for BXT DPIO latency optim setupVille Syrjälä1-9/+3
Replace the hand rolled intel_de_rmw() with the real thing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
8 daysdrm/i915/dpio: Introdude bxt_ddi_phy_rmw_grp()Ville Syrjälä1-22/+39
Add a helper to do the "read from one per-lane register and write to the group register" rmw cycle. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
8 daysdrm/i915/dpio: Extract bxt_dpio_phy_regs.hVille Syrjälä8-262/+279
Extract the BXT/GLK DPIO PHY register definitions into their own file. v2: Adjust gvt accordingly Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417151232.32175-1-ville.syrjala@linux.intel.com
8 daysdrm/i915/dpio: Add per-lane PHY TX register definitons for bxt/glkVille Syrjälä5-35/+35
Add consistent definitions for the per-lane PHY TX registers on bxt/glk. The current situation is a slight mess with some registers having a LN0 define, while others have a parametrized per-lane definition. v2: Adjust gvt accordingly Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417151211.32135-1-ville.syrjala@linux.intel.com
8 daysdrm/i915/dpio: Clean up bxt/glk PHY registersVille Syrjälä2-59/+59
Use REG_BIT() & co. for the bxt/glk PHY register definitons. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
9 daysdrm/i915/dp_mst: Enable HBLANK expansion quirk for UHBR ratesImre Deak2-4/+20
Enabling the 5k@60Hz uncompressed mode on the MediaTek/Dell U3224KBA monitor results in a blank screen, at least on MTL platforms on UHBR link rates with some (<30) uncompressed bpp values. Enabling compression fixes the problem, so do that for now. Windows enables DSC always if the sink supports it and forcing it to enable the mode without compression leads to the same problem above (which suggests a panel issue with uncompressed mode). The same 5k mode on non-UHBR link rates is not affected and lower resolution modes are not affected either. The problem is similar to the one fixed by the HBLANK expansion quirk on Synaptics hubs, with the difference that the problematic mode has a longer HBLANK duration. Also the monitor doesn't report supporting HBLANK expansion; either its internal MST hub does the expansion internally - similarly to the Synaptics hub - or the issue has another root cause, but still related to the mode's short HBLANK duration. Enable the quirk for the monitor adjusting the detection for the above differences. v2: Rebase on drm_dp_128132b_supported() change. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417142217.457902-1-imre.deak@intel.com
9 daysdrm/i915/dp_mst: Make HBLANK expansion quirk work for logical portsImre Deak1-6/+16
The DPCD OUI of the logical port on a Dell UHBR monitor - on which the AUX device is used to enable DSC - is all 0. To detect if the HBLANK expansion quirk is required for this monitor use the OUI of the port's parent instead. Since in the above case the DPCD of both the logical port and the parent port reports being a sink device (vs. branch device) type, read the proper sink/branch OUI based on the DPCD device type. This is required by a follow-up patch enabling the quirk for the above Dell monitor. Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-11-imre.deak@intel.com
9 daysdrm/dp_mst: Add drm_dp_mst_aux_for_parent()Imre Deak2-0/+17
Add a function to get the AUX device of the parent of an MST port, used by a follow-up i915 patch in the patchset. v2: Move drm_dp_mst_aux_for_parent() forward declaration to this patch (Ankit) Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-10-imre.deak@intel.com
9 daysdrm/dp_mst: Factor out drm_dp_mst_port_is_logical()Imre Deak2-3/+9
Factor out a function to check if an MST port is logical, used by a follow-up i915 patch in the patchset. v2: Move drm_dp_mst_aux_for_parent() forward declaration to the next patch. (Ankit) Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-9-imre.deak@intel.com
9 daysdrm/dp: Add drm_dp_128b132b_supported()Imre Deak2-1/+7
Factor out a function to check for 128b/132b channel coding support used by a follow-up patch in the patchset. v2: s/drm_dp_uhbr_channel_coding_supported()/drm_dp128b132b_supported() (Jani) Cc: dri-devel@lists.freedesktop.org Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417141936.457796-1-imre.deak@intel.com
9 daysdrm/i915/dp_mst: Sanitize calculating the DSC DPT bpp limitImre Deak1-39/+39
Instead of checking each compressed bpp value against the maximum DSC/DPT bpp, simplify things by calculating the maximum bpp upfront and limiting the range of bpps looped over using this maximum. While at it add a comment about the origin of the DSC/DPT bpp limit. Bspec: 49259, 68912 Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-7-imre.deak@intel.com
9 daysdrm/i915/dp_mst: Account with the DSC DPT bpp limit on MTLImre Deak1-1/+1
The DPT/DSC bpp limit should be accounted for on MTL platforms as well, do so. Bspec: 49259 Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-6-imre.deak@intel.com
9 daysdrm/i915/dp_mst: Account for channel coding efficiency in the DSC DPT bpp limitImre Deak1-2/+21
The DSC DPT interface BW limit check should take into account the link clock's (aka DDI clock in bspec) channel coding efficiency overhead. Bspec suggests that the FEC overhead needs to be applied, however HW people claim this isn't the case, nor is any overhead applicable. However based on testing various 5k/6k modes both on the DELL U3224KBA monitor and the Unigraf UCD-500 CTS test device, both the channel coding efficiency (which includes the FEC overhead) and an additional 3% overhead must be accounted for to get these modes working. Bspec: 49259 v2: - Apply an additional 3% overhead, add a commit log and code comment about these overheads and the relation to the Bspec BW limit formula. Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-5-imre.deak@intel.com
9 daysdrm/i915/dp_mst: Fix BW limit check when calculating DSC DPT bppImre Deak1-1/+1
The DSC DPT bpp limit check should only fail if the available DPT BW is less than the required BW, fix the check accordingly. Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-4-imre.deak@intel.com
9 daysdrm/i915/dp_mst: Fix symbol clock when calculating the DSC DPT bpp limitImre Deak1-2/+1
The expected link symbol clock unit when calculating the DSC DPT bpp limit is kSymbols/sec, aligning with the dotclock's kPixels/sec unit based on the crtc clock. As opposed to this port_clock is used - which has a 10 kbits/sec unit - with the resulting symbol clock in 10 kSymbols/sec units (disregarding the rounding error for the 13.5Gbps rate). Fix the calculation using the expected 10x factor. Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-3-imre.deak@intel.com
9 daysdrm/i915/dp: Fix DSC line buffer depth programmingImre Deak2-13/+6
Fix the calculation of the DSC line buffer depth. This is limited both by the source's and sink's maximum line buffer depth, but the former one was not taken into account. On all Intel platform's the source's maximum buffer depth is 13, so the overall limit is simply the minimum of the source/sink's limit, regardless of the DSC version. This leaves the DSI DSC line buffer depth calculation as-is, trusting VBT. On DSC version 1.2 for sinks reporting a maximum line buffer depth of 16 the line buffer depth was incorrectly programmed as 0, leading to a corruption in color gradients / lines on the decompressed screen image. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-2-imre.deak@intel.com
9 daysdrm/i915/display: force qgv check after the hw state readoutVinod Govindapillai2-2/+12
The current intel_bw_atomic_check do not check the possbility of a sagv configuration change after the hw state readout. Hence cannot update the sagv configuration until some other relevant changes like data rates, number of planes etc. happen. Introduce a flag to force qgv check in such cases. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-7-vinod.govindapillai@intel.com
9 daysdrm/i915/display: handle systems with duplicate psf gv pointsStanislav Lisovskiy1-0/+2
There could be multiple qgv and psf gv points with similar values. Apparently pcode's handling of psf and qgv points are different. For qgv case, pcode sets whatever is asked by the driver. But in case of psf gv points, it compares the bw from points before setting the mask. This can cause problems in scenarios where we have to disable sagv by setting the highest bw point and there could be multiple points with highest bw. So to set the maximum psf gv point, find out all the points with the highest bw and set all together. v1: - use the same treatment to qgv points as well (Vinod) v2: - pcode confirms that for qgv points, it sets whatever the driver sets (Vinod) Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-6-vinod.govindapillai@intel.com
9 daysdrm/i915/display: Disable SAGV on bw init, to force QGV point recalculationStanislav Lisovskiy3-4/+49
Problem is that on some platforms, we do get QGV point mask in wrong state on boot. However driver assumes it is set to 0 (i.e all points allowed), however in reality we might get them all restricted, causing issues. Lets disable SAGV initially to force proper QGV point state. If more QGV points are available, driver will recalculate and update those then after next commit. v2: - Added trace to see which QGV/PSF GV point is used when SAGV is disabled. v3: - Move force disable function to intel_bw_init in order to initialize bw state as well, so that hw/sw are immediately in sync after init. v4: - Don't try sending PCode request, seems like it is not possible at intel_bw_init, however assigning bw->state to be restricted as if SAGV is off, still forces driveer to send PCode request anyway on next modeset, so the solution still works. However we still need to address the case, when no display is connected, which anyway requires much more changes. v5: - Put PCode request back and apply temporary hack to make the request succeed(in case if there 2 PSF GV points with same BW, PCode accepts only if both points are restricted/unrestricted same time) - Fix argument sequence for adl_qgv_bw(Ville Syrjälä) v6: - Fix wrong platform checks, not to break everything else. v7: - Split the handling of quplicate QGV/PSF GV points (Vinod) Restrict force disable to display version below 14 (Vinod) v8: - Simplify icl_force_disable_sagv (Vinod) Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-5-vinod.govindapillai@intel.com
9 daysdrm/i915/display: extract code to prepare qgv points maskVinod Govindapillai1-5/+11
Extract the code to prepare the QGV points mask as per the format expected by the pcode as this could be utlized from multiple points. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-4-vinod.govindapillai@intel.com
9 daysdrm/i915/display: Extract code required to calculate max qgv/psf gv pointStanislav Lisovskiy1-30/+50
We need that in order to force disable SAGV in next patch. Also it is beneficial to separate that code, as in majority cases, when SAGV is enabled, we don't even need those calculations. Also we probably need to determine max PSF GV point as well, however currently we don't do that when we disable SAGV, which might be actually causing some issues in that case. v2: - Introduce helper adl_qgv_bw(counterpart to adl_psf_bw) (Ville Syrjälä) - Don't restrict psf gv points for SAGV disable case (Ville Syrjälä) v3: - Update icl_max_bw_qgv_point_mask to return max qgv point mask (Vinod) v4: - Minor changes in icl_find_qgv_points (Vinod) v5: - use max_bw_point instead of max_bw_point_mask (stan) Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-3-vinod.govindapillai@intel.com
9 daysdrm/i915/display: Add meaningful traces for QGV point info error handlingStanislav Lisovskiy2-1/+5
For debug purposes we need those - error path won't flood the log, however there has been already numerous cases, when due to lack of debugs, we couldn't immediately tell what was the problem on customer machine, which slowed down the investigation, requiring to get access to target device and adding those traces manually. v2: - Make the debug more generic and move it to intel_dram_detect (Gustavo Sousa) v3: - Use %u for unsigned variable in debug prints (Gustavo) Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-2-vinod.govindapillai@intel.com
9 daysdrm/i915/dmc: use struct intel_display moreJani Nikula1-14/+10
Now that the intel_de_ functions and DISPLAY_VER() accept struct intel_display *, use it more. Cc: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/06bc9fd9d0472e899bd9d50f3b10a6066c1a0238.1713358679.git.jani.nikula@intel.com
9 daysdrm/i915/de: allow intel_display and drm_i915_private for de functionsJani Nikula1-64/+93
It would be too much noise to convert the intel_de_* functions from using struct drm_i915_private to struct intel_display all at once. Add generic wrappers using __to_intel_display() to accept both. v2: Take the intel_dmc_wl_* changes into account Cc: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1b0e8e7c732535e18c8498a2e18fe1e4c123e2f5.1713358679.git.jani.nikula@intel.com
9 daysdrm/i915/dmc: convert dmc wakelock interface to struct intel_displayJani Nikula6-53/+59
Convert the dmc wakelock interface to struct intel_display instead of struct drm_i915_private. We'll want to convert the intel_de interfaces, and there's a bit of coupling between the two, so start here. Cc: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3c260bbbce0af8714b07157dc032b038efa3bf1c.1713358679.git.jani.nikula@intel.com
9 daysdrm/i915/display: rename __intel_wait_for_register_nowl() to indicate intel_de_Jani Nikula2-10/+10
Rename __intel_wait_for_register_nowl() to __intel_de_wait_for_register_nowl() to be in line with the rest of intel_de.h. Cc: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/967d3fc67a9053f7d5f9c03010fd5f94dc8d547d.1713358679.git.jani.nikula@intel.com
9 daysdrm/i915/quirks: convert struct drm_i915_private to struct intel_displayJani Nikula7-62/+65
Use struct intel_display instead of struct drm_i915_private for quirks. Also do drive-by conversions in call sites of intel_has_quirk(). Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d90e9d8e91e59d04d38f2743c02c74a8f0e13133.1713358679.git.jani.nikula@intel.com
9 daysdrm/i915/display: accept either i915 or display for feature testsJani Nikula1-2/+3
Use the generic __to_intel_display() to allow passing either struct drm_i915_private * or struct intel_display * to the feature test macros. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/bed78da39e6bd1587db4dab820602c55c63cdd6a.1713358679.git.jani.nikula@intel.com
9 daysdrm/i915: add generic __to_intel_display()Jani Nikula1-0/+22
Add generic __to_intel_display() macro that accepts either struct drm_i915_private * or struct intel_display *. This is to be used for transitional stuff that eventually needs to be converted to use struct intel_display *, and therefore is not part of to_intel_display(). Add new intel_display_conversion.h to host the helper to avoid duplication between xe and i915 drivers. v2: put it in the new header (Rodrigo) Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a999ff8183659a4df68d439ebd31c19b5c56852a.1713358679.git.jani.nikula@intel.com
9 daysdrm/i915/display: add generic to_intel_display() macroJani Nikula1-0/+37
Convert various pointers to struct intel_display * using _Generic(). Add some macro magic to make adding new conversions easier, and somewhat abstract the need to cast each generic association. The cast is required because all associations needs to compile, regardless of the type and the generic selection. The use of *p in the generic selection assignment expression removes the need to add separate associations for const pointers. Note: This intentionally does *not* cover struct drm_i915_private or struct xe_device. They are not to be used in the long run, so avoid using this macro for them. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/02cf407961200db4379370856c779ea62b3eaa90.1713358679.git.jani.nikula@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-28 03:51:46 +0000