- 05 Jun, 2024 12 commits
-
-
Jani Nikula authored
Since commit a61ddb43 ("drm: enable (most) W=1 warnings by default across the subsystem"), most of the extra warnings in the driver Makefile are redundant. Remove them. Note that -Wmissing-declarations and -Wmissing-prototypes are always enabled by default in scripts/Makefile.extrawarn. Acked-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/490931748fa9a1dbac2bceda0c4b778240b10b58.1716471145.git.jani.nikula@intel.com
-
Ville Syrjälä authored
It's probably a good idea to start protecting all macro arguments to avoid any cargo-cult mistakes when people go looking for examples of how to define these things. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240531115342.2763-8-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
I need a scratch register which fill the following requirements: - can be accessed via DSB - all the bits can be read/written - no serious side effects So far the only thing I could think of is the "expected CRC" register. Add the definition so I can use it. While I only need the hsw+ variant currently, let's define the older variants as well for completeness. Signed-off-by:
-
Ville Syrjälä authored
Sprinkle some comments around to indicate which CRC registers are valid for which platforms. Signed-off-by:
-
Ville Syrjälä authored
On hsw+ we only have one CRC result register, instead of the five we have on ivb, and some of the others have been repurposed to serve other CRC related purposes. Since the hsw+ vs. pre-hsw register operate quite differently let's add a separate definition for the hsw+ variant to make the situation a bit more clear. Also since we only use this from a hsw+ codepath there is no real benefit to be had with reusing the ivb register definition. Signed-off-by:
-
Ville Syrjälä authored
Put all the definitions related to a single pipe CRC register in one place, instead of the current approach where things are spread all over the place. Signed-off-by:
-
Ville Syrjälä authored
PIPE_CRC_RES_*_IVB are proper pipe registers, and only valid for IVB+ where pipe register blocks are equally spaced, so we can switch from _MMIO_TRANS2() to the simpler _MMIO_PIPE() for these. Signed-off-by:
-
Ville Syrjälä authored
The CRC registers are a pretty self contained bunch. Extract them to a separate header to declutter i915_reg.h. Signed-off-by:
-
Ville Syrjälä authored
Use intel_color_uses_dsb() instead of open coding it in intel_vblank_evade_init(). Make the logic around DSB a bit more isolated from the rest of the code. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ville Syrjälä authored
Allow the caller of intel_dsb_prepare() to determine which DSB engine (out of the three possible per pipe) to use. This will let us utilize multiple DSB engines during the same commit. Signed-off-by:
-
Ville Syrjälä authored
We're going to need to make the DSB ID visible outside the DSB code, so that we eg. can use multiple DSB engines in parallel. to that end move the definition to intel_dsb.h. Signed-off-by:
-
Ville Syrjälä authored
Namespace the DSB ID enum properly, and make the naming match other such enums in general. Also make the names 0 based as that's what Bspec uses for DSB (unlike eg. planes where it uses 1 based indexing). We'll throw out INVALID_DSB while at it since we have no use for it at the moment. Signed-off-by:
-
- 04 Jun, 2024 1 commit
-
-
Imre Deak authored
Commit dd839aa8 ("drm/i915: Fix incorrect assert about pending power domain async-put work") fixed the assert about a pending work dropping a display power reference asynchronously, leading to the drm_WARN_ON(!queue_delayed_work(&power_domains->async_put_work)); warn next time around a power reference was put asynchronously, due to a stale instance of the work still being pending. However the fix didn't consider the case where multiple power reference was acquired and put, requiring the work to requeue itself. Extend the fix for this case as well canceling the pending instance of the work before it requeues itself. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10915Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240530105312.1016485-1-imre.deak@intel.com
-
- 03 Jun, 2024 6 commits
-
-
Jouni Högander authored
We want to have sink Early Transport capability and usage in our psr debugfs status interface. v4: use su_region_et_enabled instead of psr2_su_region_et_valid v3: remove extra space from "PSR mode: disabled" v2: printout "Selective Update enabled (Early Transport)" instead of "Selective Update Early Transport enabled" Reviewed-by:Animesh Manna <animesh.manna@intel.com> Signed-off-by:
-
Jouni Högander authored
Currently setting I915_PSR_DEBUG_SU_REGION_ET_DISABLE (0x20) via psr_debug debugfs interface is not allowed. This patch allows it. v3: - ensure psr is disabled/enabled if enable_psr2_su_region_et changes - remove extra space v2: ensure that fastset is performed when the bit changes Reviewed-by:
-
Jouni Högander authored
Selective fetch Y position differs when Region Early Transport is used. Use formula from Bspec for this. Bspec: 68927 Reviewed-by:
-
Jouni Högander authored
When enabling Early Transport use intel_crtc_state->enable_psr2_su_region_et instead of psr2_su_region_et_valid. Reviewed-by:
-
Jouni Högander authored
We are currently not getting Early Transport status information in intel_psr_pipe_get_config. Fix this. Reviewed-by:
-
Jouni Högander authored
Currently we are purely relying on psr2_su_region_et_valid. Add new boolean value into intel_psr struct indicating whether Early Transport is enabled or not and use it instead of psr2_su_region_et_valid for getting Early Transport status information. Reviewed-by:
-
- 31 May, 2024 21 commits
-
-
Jani Nikula authored
With all the Intel specific drm files under include/drm/intel, update the i915, xe, and the shared display entries. Do not discriminate based on file name pattern, just add the entire directory for all three entries. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Oded Gabbay <ogabbay@kernel.org> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Acked-by:
-
Jani Nikula authored
Clean up the top level include/drm directory by grouping all the Intel specific files under a common subdirectory. Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Tomas Winkler <tomas.winkler@intel.com> Acked-by:
-
Jani Nikula authored
Clean up the top level include/drm directory by grouping all the Intel specific files under a common subdirectory. Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by:
-
Jani Nikula authored
Clean up the top level include/drm directory by grouping all the Intel specific files under a common subdirectory. Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Acked-by:
-
Jani Nikula authored
Clean up the top level include/drm directory by grouping all the Intel specific files under a common subdirectory. Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Tomas Winkler <tomas.winkler@intel.com> Acked-by:
-
Jani Nikula authored
Clean up the top level include/drm directory by grouping all the Intel specific files under a common subdirectory. v2: Also fix comment in intel_pci_config.h (Ilpo) Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Acked-by:
-
Jani Nikula authored
Clean up the top level include/drm directory by grouping all the Intel specific files under a common subdirectory. Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Reviewed-by:
-
Jani Nikula authored
Clean up the top level include/drm directory by grouping all the Intel specific files under a common subdirectory. v2: Also change Documentation/gpu/i915.rst (Andi) Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Tomas Winkler <tomas.winkler@intel.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Acked-by:
-
Jani Nikula authored
Clean up the top level include/drm directory by grouping all the Intel specific files under a common subdirectory. Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Tomas Winkler <tomas.winkler@intel.com> Reviewed-by:
-
Jani Nikula authored
Clean up the top level include/drm directory by grouping all the Intel specific files under a common subdirectory. Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Jani Nikula authored
With the refactoring in the file, some excessive includes were left behind and are now unnecessary. Remove. Reviewed-by:
-
Jani Nikula authored
With the register header refactoring, some of the includes of i915_reg.h have become unnecessary. Remove. Reviewed-by:
-
Jani Nikula authored
The intermediate macros are unused. Remove them. Reviewed-by:
-
Jani Nikula authored
Move the macros where they belong. Reviewed-by:
-
Jani Nikula authored
Follow the recommended style for grouping register macros. Reviewed-by:
-
Jani Nikula authored
The intermediate macros are no longer needed. Reviewed-by:
-
Jani Nikula authored
Use the proper helpers for DP AUX CH CTL registers, instead of reinventing the wheels. Reviewed-by:
-
Ville Syrjälä authored
Dotclocks can reach ~1GHz these days, so intel_usecs_to_scanlines(), with its 32bit maths, is currently limited to a few milliseconds. I want bigger numbers in DSB selftests, so switch over to 64bit maths. Signed-off-by:
-
Ville Syrjälä authored
I want to use intel_crtc_scanline_offset() in intel_crtc_scanline_to_hw(). Relocate intel_crtc_scanline_offset() a bit to avoid a forward declaration. Signed-off-by:
-
Ville Syrjälä authored
Currently intel_crtc_scanline_offset() is careful to always return a positive offset. That is not actually necessary as long as we take care of negative values when applying the offset in __intel_get_crtc_scanline(). This simplifies intel_crtc_scanline_offset(), and makes the scanline_offfset arithmetic more symmetric between the forward (__intel_get_crtc_scanline()) and reverse (intel_crtc_scanline_to_hw()) directions. Signed-off-by:
-
Ville Syrjälä authored
We have several copies of code calculating the hardware's idea of vtotal. Pull that to a helper, similar to intel_mode_vblank_{start,end}(). Signed-off-by:
-
