summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display/intel_panel.c
AgeCommit message (Collapse)Author
2024-12-18drm/i915/display: drop unnecessary i915_drv.h includesJani Nikula
Now that we don't include i915_drv.h via any headers from display, we can reliably remove unnecessary i915_drv.h includes and be sure they're not indirectly included. Add other includes where needed. v2: Fix 32-bit build Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241217132147.2008057-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-09drm/i915/display: convert intel_display_driver.[ch] to struct intel_displayJani Nikula
Going forward, struct intel_display will be the main display driver structure. Convert the main display entry points to struct intel_display. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241204102150.2223455-1-jani.nikula@intel.com
2024-11-12drm/i915/display: convert display device identification to struct intel_displayJani Nikula
Convert intel_display_device.[ch] to struct intel_display, including callers, but excluding intel_display_device_probe() which will be handled in follow-up. v2: fix display->drm = display->drm goof-up Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/865b27b66f599e707081d46fca9f679e19a4e8aa.1731321183.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/pfit: Extract intel_pfit.cVille Syrjälä
The panel fitter code doesn't really have much to do with the rest of intel_panel.c, so extract it all into its own file. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/panel: Convert panel code to intel_displayVille Syrjälä
struct intel_display will replace struct drm_i915_private as the main thing for display code. Convert the panel code to use it (as much as possible at this stage). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/pfit: Check pfit destination window on ILK-BDWVille Syrjälä
The ILK-BDW panel fitter has several restrictions on the destination window size. Check for those and reject the configuration if things aren't entirely proper. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-7-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/pfit: Reject cloning when using pfit on ILK-BDWVille Syrjälä
The panel fitter lives inside the pipe and so would affect all cloned outputs. However the relevant properties (scaling mode, TV margins) are per-connector so we could end up with a situation where each cloned output wants a different pfit configuration. Let's just reject pfit usage with cloning entirely. Currently not an issue as we don't yet expose the TV margin properties, but if/when we add those to HDMI we could end up in this situation. For eDP/DP we don't support cloning anyyway. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-6-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/pfit: Check pfit minimum timings in pre-SKLVille Syrjälä
Transcoder hdisplay/vdisplay have documented minimum limits when using the panel fitter. Enforce those limits for all pre-SKL platforms. SKL+ handles everything in the unified scaler code instead. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-5-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/pfit: Reject pfit downscaling for GMCH platformsVille Syrjälä
Gen2/3 pfit doesn't support downscaling at all, so reject it. On i965+ downscaling is supported by the hardware (max scale factor < 2.0), but as downscaling increases the effective pixel rate we can't safely allow it unless intel_crtc_compute_pixel_rate() gets fixed. Probably the best solution would be to calculate (at least an apporiximate) pfit destination window and use ilk_pipe_pixel_rate() for all platforms. For now reject downscaling on all gmch platforms. The intel ddx has a similar check for this in userspace, modesetting ddx does not. And presumably wayland compositors also do not make such assumptions in userspace. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-4-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/pfit: Check pfit scaling factors on ILK-BDWVille Syrjälä
Make sure we're not exceeding the max scaling factors for the panel fitter on ILK-BDW. SKL+ is skipped here since this is all supposed to be handled by the unified scaler code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-3-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/pfit: Check pipe source size against pfit limits on ILK-BDWVille Syrjälä
The ILK-BDW panel fitter imposes extra limits on the maximum pipe source size we can use. Check for that. Only HSW/BDW are really affected by this since on older platforms the max hdisplay/vdisplay matches the max PIPESRC. But we'll put in the limits for all the platforms just to keep things clear. Note that pch_panel_fitting() is also used on SKL+, but we'll skip the checks for those as it's all supposed to be handled in the unified scaler code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-2-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915/bios: Get rid of "LVDS" from all LFP data stuffVille Syrjälä
The LFP data applies to all kinds of display interfaces, so stop calling things by the "LVDS" name. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-18drm/i915/quirks: convert struct drm_i915_private to struct intel_displayJani Nikula
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
2024-01-08drm/i915: Disable hotplug detection handlers during driver init/shutdownImre Deak
As described in the previous two patches an unexpected connector detection can happen during the init/shutdown sequences. Prevent these by returning the connector's current status from the detection handlers. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-10-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
2023-10-26drm/i915/display: Move panel_use_ssc module parameter under displayJouni Högander
Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231024124109.384973-8-jouni.hogander@intel.com
2023-10-04drm/i915: convert INTEL_DISPLAY_ENABLED() into a functionJani Nikula
There's no need for this to be a macro. Add some documentation too. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/480b9b697b2ffa0c8677115bd443ba633801c6c1.1696336887.git.jani.nikula@intel.com
2023-09-20drm/i915: Relocate is_in_vrr_range()Ville Syrjälä
Move is_in_vrr_range() into intel_vrr.c in anticipation of more users, and rename it accordingly. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-8-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
2023-04-20drm/i915: Namespace pfit registers properlyVille Syrjälä
Give the PFIT_CONTROL bits a consistent namespace. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-04-20drm/i915: Use REG_BIT() & co for the pre-ilk pfit registersVille Syrjälä
Modernize the gmch pfit register definitions using REG_BIT/etc. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-04-13drm/i915: Allow arbitrary refresh rates with VRR eDP panelsVille Syrjälä
If the panel supports VRR it must be capable of accepting timings with arbitrary vblank length, within the valid VRR range. Use that fact to allow the user to request any refresh rate they like. We simply pick the next highest fixed mode from our list, and adjust the vblank to get the desired refresh rate in the end. Of course currently everything to do with the vrefresh is using 1Hz precision, so might not be exact. But we can improve that in the future by just upping our vrefresh precision. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230404175431.23064-1-ville.syrjala@linux.intel.com Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
2023-01-31drm/i915/lvds: Extract intel_lvds_regs.hVille Syrjälä
Extract the integrated LVDS port register definitions into their own header file. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-01-26drm/i915/panel: move panel fixed EDID to struct intel_panelJani Nikula
It's a bit confusing to have two cached EDIDs in struct intel_connector with slightly different purposes. Make the distinction a bit clearer by moving the EDID cached for eDP and LVDS panels at connector init time to struct intel_panel, and name it fixed_edid. That's what it is, a fixed EDID for the panels. Cc: Ville Syrjälä <ville.syrjala@linux.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/328350ef918638928a8286cdbab3107c8258332d.1674643465.git.jani.nikula@intel.com
2022-12-09drm/i915: Try to use the correct power sequencer intiially on bxt/glkVille Syrjälä
Currently on bxt/glk we just grab the power sequencer index from the VBT data even though it may not have been parsed yet. That could lead us to using the incorrect power sequencer during the initial panel probe. To avoid that let's try to read out the current state of the power sequencer from the hardware. Unfortunately the power sequencer no longer has anything in its registers to associate it with the port, so the best we can do is just iterate through the power sequencers and pick the first one. This should be sufficient for single panel cases. For the dual panel cases we probably need to go back to parsing the VBT before the panel probe (and hope that panel_type=0xff is never a thing in those cases). To that end the code always prefers the VBT panel sequencer, if available. v2: Restructure a bit for upcoming icp+ dual PPS support Cc: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-5-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2022-12-09drm/i915: Do panel VBT init early if the VBT declares an explicit panel typeVille Syrjälä
Lots of ADL machines out there with bogus VBTs that declare two eDP child devices. In order for those to work we need to figure out which power sequencer to use before we try the EDID read. So let's do the panel VBT init early if we can, falling back to the post-EDID init otherwise. The post-EDID init panel_type=0xff approach of assuming the power sequencer should already be enabled doesn't really work with multiple eDP panels, and currently we just end up using the same power sequencer for both eDP ports, which at least confuses the wakeref tracking, and potentially also causes us to toggle the VDD for the panel when we should not. Cc: Animesh Manna <animesh.manna@intel.com> 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/20221125173156.31689-3-ville.syrjala@linux.intel.com
2022-12-09drm/i915: Introduce intel_panel_init_alloc()Ville Syrjälä
Introduce a place where we can initialize connector->panel after it's been allocated. We already have a intel_panel_init() so had to get creative with the name and came up with intel_panel_init_alloc(). Cc: Animesh Manna <animesh.manna@intel.com> 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/20221125173156.31689-2-ville.syrjala@linux.intel.com
2022-11-11drm/i915: stop including i915_irq.h from i915_trace.hJani Nikula
Turns out many of the files that need i915_reg.h get it implicitly via {display/intel_de.h, gt/intel_context.h} -> i915_trace.h -> i915_irq.h -> i915_reg.h. Since i915_trace.h doesn't actually need i915_irq.h, makes sense to drop it, but that requires adding quite a few new includes all over the place. Prefer including i915_reg.h where needed instead of adding another implicit include, because eventually we'll want to split up i915_reg.h and only include the specific registers at each place. Also some places actually needed i915_irq.h too. 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/6e78a2e0ac1bffaf5af3b5ccc21dff05e6518cef.1668008071.git.jani.nikula@intel.com
2022-10-21drm/i915: Allow panel fixed modes to have differing sync polaritiesVille Syrjälä
Apparently some panels declare multiple modes with random sync polarities. Seems a bit weird, but looks like Windows/GOP doesn't care, so let follow suit and accept alternate fixed modes regardless of their sync polarities. v2: Don't pollute the DRM_ namespace with a define (Jani) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6968 Acked-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/20221020093938.27200-1-ville.syrjala@linux.intel.com
2022-10-04drm/i915: Setup final panel drrs_type already during initVille Syrjälä
Now that we track the VBT drrs type per-panel we can move the has_drrs_modes() check to the panel init rather than doing it for every intel_panel_drrs_type() call. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221003113249.16213-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-10-04drm/i915: Tighten DRRS capability reportingVille Syrjälä
Only report DRRS capability for the connector if its fixed_modes list contains at least two modes capable of seamless DRRS switch between them. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221003113249.16213-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-09-28drm/i915: Simplify intel_panel_add_edid_alt_fixed_modes()Ville Syrjälä
Since commit a5810f551d0a ("drm/i915: Allow more varied alternate fixed modes for panels") intel_panel_add_edid_alt_fixed_modes() no longer considers vrr vs. drrs separately. So no reason to pass them as separate parameters either. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220927180615.25476-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-09-08drm/i915: Add intel_panel_highest_mode()Ville Syrjälä
Add a function to get the fixed_mode with the highest clock. The plan is to use this for the link bw calculation on seamless DRRS panels so that we alwasy end up with the same link params regardless of the requested refresh rate. This will allow fastset to do seamless refresh rate changes based on userspace request instead of having to go for a full modeset. TODO: the function name isn't great 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/20220907091057.11572-15-ville.syrjala@linux.intel.com
2022-08-31drm/i915: Allow more varied alternate fixed modes for panelsVille Syrjälä
On some systems the panel reports alternate modes with different blanking periods. If the EDID reports them and VBT doesn't tell us otherwise then I can't really see why they should be rejected. So allow their use for the purposes of static DRRS. For seamless DRRS we still require a much more exact match of course. But that logic only kicks in when selecting the downclock mode (or in the future when determining whether we can do a seamless refresh rate change due to a user modeset). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6374 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220830212436.2021-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-08-31drm/i915/quirks: abstract checking for display quirksJani Nikula
Add intel_has_quirk() for checking if a display quirk is present. Avoid accessing i915->quirks all over the place. v2: Rebase Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/74f954ca81a8068033141a15686dffd01ad9b0f9.1661779055.git.jani.nikula@intel.com
2022-08-31drm/i915: move vbt to display.vbtJani Nikula
Move display VBT related members under drm_i915_private display sub-struct. v2: Rebase Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/db4b648b201ea0b79654fec2028120999a735db0.1661779055.git.jani.nikula@intel.com
2022-06-01drm/i915: Accept more fixed modes with VRR panelsVille Syrjälä
It seem that when dealing with VRR capable eDP panels we need to accept fixed modes with variable vblank length (which is what VRR varies dynamically). Typically the preferred mode seems to be a non-VRR more (lowish dotclock/refresh rate + short vblank). We also have examples where it looks like even the hblank length is a bit different between the preferred mode vs. VRR mode(s). So let's just accept anything that has matching hdisp+vdisp+flags. v2: Document that is_alt_drrs_mode() is a subset of is_alt_vrr_mode() (Jani) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/125 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/20220531191844.11313-4-ville.syrjala@linux.intel.com
2022-06-01drm/i915: Print out rejected fixed modesVille Syrjälä
To help with debugging DRRS/VRR panel init let's dump out all the fixed modes we rejected for whatever reason. 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/20220531191844.11313-3-ville.syrjala@linux.intel.com
2022-05-27drm/i915/bios: Split VBT data into per-panel vs. global partsVille Syrjälä
Move the panel specific VBT parsing to happen during the output probing stage. Needs to be done because the VBT parsing will need to look at the EDID to determine the correct panel_type on some machines. We split the parsed VBT data (i915->vbt) along the same boundary. For the moment we just hoist all the panel specific stuff into connector->panel.vbt since that seems like the most convenient place for eg. the backlight code. Note that we simply drop the drrs type check from intel_drrs_frontbuffer_update() since that operates on the whole device rather than a specific connector/encoder. But the check was just a micro optimization so removing it doesn't actually mattter for correctness. TODO: Lot's of cleanup to be done in the future. Eg. most of the DSI stuff could probably be eliminated entirely and just parsed on demand during DSI init. v2: Note the intel_drrs_frontbuffer_update() change Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-05-05drm/i915: Respect VBT seamless DRRS min refresh rateVille Syrjälä
Make sure our choice of downclock mode respects the VBT seameless DRRS min refresh rate limit. v2: s/vrefesh/vrefresh/ (Jani) 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/20220504150440.13748-10-ville.syrjala@linux.intel.com
2022-03-31drm/i915: Allow higher refresh rate alternate fixed modesVille Syrjälä
We shouldn't restrict ourselves to just downclock modes with lower refresh rate than the preferred mode. Laptops these days can offer higher refresh rate modes as well. Remove the arbitrary limit and allow all modes that, apart from the clock, match the preferred mode. v2: s/add_edid_downclock_modes/add_edid_alt_fixed_modes/ (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Allow an arbitrary number of downclock modesVille Syrjälä
Remove the "two fixed modes only" limit and grab as many downclock modes from the EDID as we can find. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Stop duplicating the EDID fixed/downclock modesVille Syrjälä
Instead of duplicating the fixed/downclock modes we can just grab the originals straight from the probed_modes list and keep them. The next .get_modes() is going to repopulate the probed_modes list anyway so whatever we leave there is just going to sit around until that time wasting memory. In fact let's clear out the probed modes list entirely to make sure we get 100% consistent behaviour starting already from the very first real .get_modes(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Combine the EDID fixed_mode+downclock_mode lookup into oneVille Syrjälä
The intel_panel_add_edid_fixed_mode() vs. intel_panel_add_edid_downclock_mode() split is not really helpful. Let's just roll those into a single function so that the connector init code doesn't have to care too much about this. All we need to know is whether DRRS should be allowed or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Nuke intel_drrs_init()Ville Syrjälä
intel_drrs_init() is a mostly pointless wrapper around intel_panel_add_edid_downclock_mode(), get rid of it. The only really useful thing left in there is the debug print regarding the DRRS type supported by the connector. Let's just move that into intel_panel_init(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Refactor non-EDID fixed mode duplicationVille Syrjälä
All the non-EDID fixed mode functions basically do the exact same thing. Let's refactor the common bits into a shared function. There are minor differences on how the mode types are populated, whether the display info physical size is updated, and the debug print. The differences are purely accidental, so unifying them is actually a good thing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Put fixed modes directly onto the panel's fixed_modes listVille Syrjälä
Rather than having the connector init get the fixed mode back from intel_panel and then feed it straight back into intel_panel_init() let's just make the fixed mode lookup put the mode directly onto the panel's fixed_modes list. Avoids the pointless round trip and opens the door for further enhancements to the fixed mode handling. v2: Make the debug message correct by using intel_panel_drrs_type() (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-29drm/i915: Extract intel_panel_encoder_fixed_mode()Ville Syrjälä
Apart from the EDID and VBT based mechanism we also sometimes use the encoder's current mode as the panel fixed mode. We currently have the same code for that duplicated in two places. Let's unify. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-29drm/i915: Extract intel_panel_vbt_sdvo_fixed_mode()Ville Syrjälä
We have a function for duplicating the VBT LFP mode. Add the same for the VBT SDVO mode. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-29drm/i915: Rename intel_panel_vbt_fixed_mode()Ville Syrjälä
Rename intel_panel_vbt_fixed_mode() to intel_panel_vbt_lfp_fixed_mode() to be more descriptive. We'll have another VBT fixed mode function soon and we don't want to confuse the two. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-29drm/i915: Use DRM_MODE_FMT+DRM_MODE_ARG()Ville Syrjälä
Replace all drm_mode_debug_printmodeline() calls with DRM_MODE_FMT+DRM_MODE_ARG(). Makes the debug output a bit more terse in places where we previously had a newline in the precedeing drm_dbg_kms(), and avoids anything else sneaking in between the two printk()s in all cases. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-29drm/i915: Pass intel_connector to intel_panel_{init,fini}()Ville Syrjälä
All the other intel_panel functions take struct intel_connector, so might as well make init()/fini() take one as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>