- 03 May, 2024 3 commits
-
-
Ville Syrjälä authored
With Xorg+modesetting on skl+ we see the following behaviour: 1. root pixmap is X-tiled 2. client submitted buffers can be Y-tiled (w/ 'Option "dmabuf_capable"') 3. we try to switch from the X-tiled buffer to the Y-tiled buffer using an async flip (when vsync is disabled). 4. the async flip will be rejected by i915 due to the modifier change Relax the rules a bit by turning the first async flip into a sync flip so that we can change the modifier if necessary. Note that we already convert the first async flip into a sync flip on adl+ in order to reprogram the watermarks. Reviewed-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430095639.26390-4-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
DDB/watermarks are always double buffered on the vblank, so we can't safely change them during async flips. Currently this never happens, but we'll be making changing between sync and async flips a bit more flexible, in which case we can actually end up here. Reviewed-by:
Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
On ADL async flips apparently generate DMAR and GGTT faults (with accompanying visual glitches) unless PLANE_SURF is aligned to at least 16k. Bump up the alignment to 16k. TODO: analyze things better to figure out what is really going on here Reviewed-by:
-
- 02 May, 2024 1 commit
-
-
Chaitanya Kumar Borah authored
Intel hardware is capable of programming the Maud/Naud SDPs on its own based on real-time clocks. While doing so, it takes care of any deviations from the theoretical values. Programming the registers explicitly with static values can interfere with this logic. Therefore, let the HW decide the Maud and Naud SDPs on it's own. Cc: stable@vger.kernel.org # v5.17 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8097Co-developed-by:
Kai Vehmanen <kai.vehmanen@intel.com> Signed-off-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430091825.733499-1-chaitanya.kumar.borah@intel.com
-
- 30 Apr, 2024 21 commits
-
-
Ville Syrjälä authored
Pull the VLV/CHV DPIO PHY sideband registers to their own file. v2: drop stray tabs (Jani) Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Use REG_BIT() & co. for the vlv/chv DPIO PHY registers. Note that DPIO_BIAS_CURRENT_CTL_SHIFT was incorrectly defined to be 21 wheres 20 is the correct value. It is not used in the code though so didn't bother splitting to a separate patch. v2: drop stray tabs (Jani) Signed-off-by:
-
Ville Syrjälä authored
The DPIO PHY registers follow clear numbering rules. Express those in a few macros to get rid of the hand calculated final offsets. Signed-off-by:
-
Ville Syrjälä authored
Drop the leading underscore from the CHV PHY common lane register definitions. We use these directly from actual code so the underscore here is misleading as usually it indicates an intermediate define that shouldn't be used directly. Signed-off-by:
-
Ville Syrjälä authored
Include _GRP in VLV DPIO PHY group access register define names. Makes it more obvious where the accesses will land. Also matches the naming used by BXT already. Signed-off-by:
-
Ville Syrjälä authored
In the encoder hooks we are dealing primarily with the encoder, so derive the DPIO PHY from the encoder rather than the pipe. Technically this doesn't matter as we can't cross connect pipes<->port across PHY boundaries, but it does conveny the intention more accurately. Signed-off-by:
-
Ville Syrjälä authored
Stop using 'pipe' directly as the DPIO PHY channel. This does happen to work on VLV since it just has the one PHY with CH0==pipe A and CH1==pipe B. But explicitly converting the thing to the right enum makes the whole thing less confusing. Signed-off-by:
-
Ville Syrjälä authored
Stop calling the DPIO PHY channel "port". Just say "ch", which is already used in a bunch of places. Signed-off-by:
-
Ville Syrjälä authored
Use a consistent 'tmp' as the variable name for the register values during rmw when we don't deal with multiple registers in parallel. Signed-off-by:
-
Ville Syrjälä authored
Drop all the local variables for the DPLL dividers for vlv/chv and just consult the state directly. Signed-off-by:
-
Ville Syrjälä authored
The spreadsheet defines the PLL register block as having the dwords in the following order: block dwords offsets PLL1 0x0-0x7 0x00-0x1f PLL2 0x0-0x7 0x20-0x3f PLL1ext 0x10-0x1f 0x40-0x5f PLL2ext 0x10-0x1f 0x60-0x7f So dword indexes 0x8-0xf don't even exist. Renumber our register defines to match. Note that the spreadsheet used hex numbering whereas our defiens are in decimal. Perhaps we should change that? Signed-off-by:
-
Ville Syrjälä authored
VLV_PLL_DW9_BCAST is actually VLV_PCS_DW17_BCAST. The address does kinda look like it goes to the PLL block on a first glance, but broadcast is special and doesn't even exist for the PLL (only PCS and TX have it). The fact that we use a broadcast write here is a bit sketchy IMO since we're now blasting the register to all PCS splines across the whole PHY. So the PCS registers in the other channel (ie. other pipe/port) will also be written. But I guess the fact that we always write the same value should make this a nop even if the other channel is already enabled (assuming the VBIOS/GOP didn't screw up and use some other value...). Signed-off-by:
-
Ville Syrjälä authored
Our VLV_REF_DW13 is actually VLV_REF_DW11. Rename it. Signed-off-by:
-
Ville Syrjälä authored
We don't use the result of the VLV_PCS01_DW8 read at all, so don't read. Signed-off-by:
-
Jani Nikula authored
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C22 register macro. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0a07f615c574040094b37c861078e41daf53c706.1714399071.git.jani.nikula@intel.comSigned-off-by:
-
Jani Nikula authored
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C21_C20 register macro. Reviewed-by:
-
Jani Nikula authored
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C12 register macro. Reviewed-by:
-
Jani Nikula authored
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C11_C10 register macro. Reviewed-by:
-
Jani Nikula authored
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C02 register macro. Reviewed-by:
-
Jani Nikula authored
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C01_C00 register macro. Reviewed-by:
-
Jani Nikula authored
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PALETTE register macro. Reviewed-by:
-
- 29 Apr, 2024 4 commits
-
-
Jani Nikula authored
Clean up i915_reg.h. v2: Drop a redundant comment (Ville) Reviewed-by:
-
Jani Nikula authored
Clean up i915_reg.h. v2: Drop chicken regs and comments (Ville) Reviewed-by:
-
Jani Nikula authored
For some reason the paletter registers were missed when adding intel_color_regs.h. Finish the job. Adjust some comments while at it. v2: Fix comments (Ville) Reviewed-by:
-
Jani Nikula authored
There are too few registers to warrant a dedicated file for LPE audio regs, but the audio reg file is better than i915_reg.h. v2: Rebase Reviewed-by:
-
- 25 Apr, 2024 8 commits
-
-
Thomas Zimmermann authored
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.deSigned-off-by:
-
Thomas Zimmermann authored
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 authored
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 authored
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 authored
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 authored
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:
-
Jani Nikula authored
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:
-
Jani Nikula authored
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:
-
- 23 Apr, 2024 3 commits
-
-
Jani Nikula authored
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:
-
Jani Nikula authored
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:
-
Jani Nikula authored
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:
-
