- 11 Nov, 2022 3 commits
-
-
Jani Nikula authored
Split out the display register helper macros to a separate file. For now, include it from i915_reg.h, but note that there are already files that don't need i915_reg.h, such as intel_audio.c. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3af47193ff5219b6d2cfe353b752ec4bb44de4f1.1668008071.git.jani.nikula@intel.com
-
Jani Nikula authored
This is a more logical place for generic helpers. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Jani Nikula authored
This is a more logical place for generic helpers. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
- 10 Nov, 2022 1 commit
-
-
Ville Syrjälä authored
Currently when opeating in split gamma mode we do the "skip ever other sw LUT entry" trick in the low level LUT programming/readout functions. That is very annoying and a big hinderance to revamping the color management uapi. Let's get rid of that problem by making half sized copies of the software LUTs and plugging those into the internal {pre,post}_csc_lut attachment points (instead of the sticking the uapi provide sw LUTs there directly). With this the low level stuff will operate purely in terms the hardware LUT sizes, and all uapi nonsense is contained to the atomic check phase. The one thing we do lose is intel_color_assert_luts() since we no longer have a way to check that the uapi LUTs were correctly used when generating the internal copies. But that seems like a price worth paying. Signed-off-by:Ankit Nautiyal <ankit.k.nautiyal@intel.com>
-
- 09 Nov, 2022 1 commit
-
-
Jani Nikula authored
struct intel_crtc_state in intel_display_types.h actually needs the struct intel_link_m_n definition, while intel_display.h only needs the forward declaration. Signed-off-by:
-
- 03 Nov, 2022 25 commits
-
-
Ville Syrjälä authored
Prefer our own intel_crtc_needs_modeset() wrapper to drm_atomic_crtc_needs_modeset() whenever we are dealing with the intel_ types instead of drm_ types. Makes things a bit neater in general. Signed-off-by:
-
Ville Syrjälä authored
ilk/snb vs. ivb+ hardware is mostly identical except for the addition of the split gamma mode on ivb. Thus we can share the csc_enable and gamma_enable calculation for both variants. Pull that stuff into a few helpers. Note that this also fills in the missing ctm/degamma stuff into ilk_color_check() pretty much, so for good measure let's also add a few extra checks relating to that, although we still don't expose ctm/degamma to userspace. But now it'll be trivial to do so if we wish. Signed-off-by:
-
Ville Syrjälä authored
Since the pipe CSC sits between the degamma and gamma LUTs there is no way to make us it for RGB->YCbCr conversion when both LUTs are also active. Simply reject such combos. Signed-off-by:
-
Ville Syrjälä authored
Apart from the split gamma mode ivb+ LUTs work just like ilk+ LUTs. So let's handle the special case, and then just fall back to ilk_gamma_mode() to avoid having to duplicate the same logic. Signed-off-by:
-
Ville Syrjälä authored
Since pre-icl vs. icl+ handle the limited range output stuff a bit differently it's probably less confusing if we just pass that information explicitly into ilk_csc_convert_ctm(). Signed-off-by:
-
Ville Syrjälä authored
s/icl_lut_multi_seg_pack/ilk_lut_12p4_pack/ since that's what it is and group the corresponding "unpack" functions next to it. Signed-off-by:
-
Ville Syrjälä authored
Split the EXT2_MAX register programming into its own function. More in line with the whole "cobble together stuff from small pieces" approach used in this code. The EXT(2)_MAX registers are also not really part of the multi-segment section of the LUT, so hoist the calls to a higher level, just like we do in other gamma modes as well. Signed-off-by:
-
Ville Syrjälä authored
Unify icl_load_gcmax() with the rest of the function naming scheme by calling it ivb_load_lut_max() instead. Signed-off-by:
-
Ville Syrjälä authored
Switch intel_color.c over to the modern 'i915' variable naming scehme. The only exceptions are the i9xx LUT access functions which still need the magic 'dev_priv' for the register macros. Signed-off-by:
-
Ville Syrjälä authored
No need to use _MMIO_PIPE2() for SKL_BOTTOM_COLOR since all pipe registers are evenly spread on skl+. Switch to _MMIO_PIPE() and thus avoid the hidden dev_priv. Signed-off-by:
-
Ville Syrjälä authored
Use sizeof(variable) instead of sizeof(type) in the hopes of less chance of screwing things up. Signed-off-by:
-
Jani Nikula authored
The gen2 irq functions aren't used outside of i915_irq.h. Make them static, and remove the useless macro wrappers. Signed-off-by:
-
Jani Nikula authored
Only include what's needed. Signed-off-by:
-
Jani Nikula authored
Only include what's needed. Signed-off-by:
-
Jani Nikula authored
Only include what's needed. Signed-off-by:
-
Jani Nikula authored
Only include what's needed. Signed-off-by:
-
Jani Nikula authored
Reduce the size of intel_display.h by moving out the dpio_channel and dpio_phy enums. Signed-off-by:
-
Jani Nikula authored
Simplify the heavy intel_display_types.h header. Signed-off-by:
-
Jani Nikula authored
This lets us drop the heavy intel_display.h include from intel_sprite.h. Signed-off-by:
-
Jani Nikula authored
Only include what's needed. Signed-off-by:
-
Jani Nikula authored
Only include what's needed. Signed-off-by:
-
Jani Nikula authored
The GPIO enum is only used in intel_gmbus.c, hide it there. Signed-off-by:
-
Jouni Högander authored
Selective update area is now aligned with DSC slice height when DSC is enabled. Remove inappropriate warning about missing DSC alignment. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Fixes: 47d4ae21 ("drm/i915/mtl: Extend PSR support") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7212Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Jouni Högander authored
Do not enable psr2 if panel ganularity is not aligned with DSC slice height when DSC is enabled Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Vinod Govindapillai authored
DSC feature information is no longer part of the DFSM register in some display generations. Bspec:50075 Signed-off-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
- 01 Nov, 2022 2 commits
-
-
Jouni Högander authored
MTL shares PSR2_MAN_TRK_CTL bits with ADL. Currently some bit getter functions are incorrect for MTL. This patch fixes those. Bspec: 49274 Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Fixes: 47d4ae21 ("drm/i915/mtl: Extend PSR support") Signed-off-by:
-
Jouni Högander authored
Currently we are observing mouse cursor stuttering when using xrandr --scaling=1.2x1.2. X scaling/transformation seems to be doing fronbuffer rendering. When moving mouse cursor X seems to perform several invalidates and only one DirtyFB. I.e. it seems to be assuming updates are sent to panel while drawing is done. Earlier we were disabling PSR in frontbuffer invalidate call back (when drawing in X started). PSR was re-enabled in frontbuffer flush callback (dirtyfb ioctl). This was working fine with X scaling/transformation. Now we are just enabling continuous full frame (cff) in PSR invalidate callback. Enabling cff doesn't trigger any updates. It just configures PSR to send full frame when updates are sent. I.e. there are no updates on screen before PSR flush callback is made. X seems to be doing several updates in frontbuffer before doing dirtyfb ioctl. Fix this by sending single update on every invalidate callback. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Fixes: 805f04d4 ("drm/i915/display/psr: Use continuos full frame to handle frontbuffer invalidations") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6679Signed-off-by:
Brian J. Tarricone <brian@tarricone.org> Tested-by:
-
- 28 Oct, 2022 8 commits
-
-
Ville Syrjälä authored
Correctly indicate which outputs we support in the debug print. Signed-off-by:
-
Ville Syrjälä authored
Avoid having to call the output init function for each output type separately. We can just call the right one based on the "class" of the output. Technically we could just walk the bits of the bitmask but that could change the order in which we initialize the outputs. To avoid any behavioural changes keep to the same explicit probe order as before. Signed-off-by:
-
Ville Syrjälä authored
Get rid of this silly output type<->device index back and forth and just pass the output type directly to the corresponding output init function. This was already being done for TV outputs anyway. Signed-off-by:
-
Ville Syrjälä authored
Stop enumerating the DDC modes for SDVO LVDS outputs (outside the initial fixed mode setup). intel_panel_mode_valid() will just reject most of them anyway, and any left over are entirely pointless as they'll match the fixed mode hdisp+vdisp+vrefresh so no user visible effect from using them instead of the fixed mode. Signed-off-by:
-
Ville Syrjälä authored
Get rid of this funny byte based dumping of invalid output flags and just dump it as a single hex numbers. Also do that early since all the rest is going to get skipped anyway of the thing is zero. Signed-off-by:
-
Ville Syrjälä authored
drm_mode_probed_add() is unhappy about being called w/o mode_config.mutex. Grab it during LVDS fixed mode setup to silence the WARNs. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301 Fixes: aa2b8807 ("drm/i915/sdvo: Fix multi function encoder stuff") Signed-off-by:
-
Ville Syrjälä authored
Call intel_sdvo_select_ddc_bus() before initializing any of the outputs. And before that is functional (assuming no VBT) we have to set up the controlled_outputs thing. Otherwise DDC won't be functional during the output init but LVDS really needs it for the fixed mode setup. Note that the whole multi output support still looks very bogus, and more work will be needed to make it correct. But for now this should at least fix the LVDS EDID fixed mode setup. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301 Fixes: aa2b8807 ("drm/i915/sdvo: Fix multi function encoder stuff") Signed-off-by:
-
Ville Syrjälä authored
We try to filter out the corresponding xxx1 output if the xxx0 output is not present. But the way that is being done is pretty awkward. Make it less so. Cc: stable@vger.kernel.org Signed-off-by:
-
