aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display/intel_crt.c
AgeCommit message (Collapse)AuthorFilesLines
2024-06-07drm/i915: pass dev_priv explicitly to PIPEDSLJani Nikula1-3/+3
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPEDSL register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/53b751f5a883318d44b690284d2e9d5a43fba860.1717514638.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-06-07drm/i915: pass dev_priv explicitly to TRANSCONFJani Nikula1-4/+7
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the TRANSCONF register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/9afc96be1cbe4514cdca701ab434b4c7aa3a55ba.1717514638.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-06-07drm/i915: pass dev_priv explicitly to PORT_HOTPLUG_STATJani Nikula1-2/+3
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PORT_HOTPLUG_STAT register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/9a47bba4ab8fa4b1a8e8ceea2ba5301bed54805d.1717514638.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-06-07drm/i915: pass dev_priv explicitly to PORT_HOTPLUG_ENJani Nikula1-1/+1
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PORT_HOTPLUG_EN register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/3f4c3fb108f62db5d9b6bdabd0fbeb6650e14e82.1717514638.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-06-07drm/i915: pass dev_priv explicitly to BCLRPATJani Nikula1-4/+6
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the BCLRPAT register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/f04d0313032d5820a14cc504af390b4b1006fae6.1717514638.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-06-07drm/i915: pass dev_priv explicitly to TRANS_VSYNCJani Nikula1-1/+2
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the TRANS_VSYNC register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/eed30cb59cc45955a88cdf951023b0e695095760.1717514638.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-06-07drm/i915: pass dev_priv explicitly to TRANS_VBLANKJani Nikula1-3/+7
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the TRANS_VBLANK register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/c33739ac6f26105fd1ad79b0027b6626e241c7bc.1717514638.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-06-07drm/i915: pass dev_priv explicitly to TRANS_VTOTALJani Nikula1-1/+2
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the TRANS_VTOTAL register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/751bc7046f5e2c5fc6a4fe5ade2e836c641abdb7.1717514638.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-09drm/i915: move max_dotclk_freq to display substructJani Nikula1-1/+1
The info is related to display, and should be placed under i915->display. Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ea012aa72c93f3d436ccacf8f75683757d144b82.1712599670.git.jani.nikula@intel.com
2024-04-03drm/i915: Remove DRM_MODE_FLAG_DBLSCAN checks from .mode_valid() hooksVille Syrjälä1-3/+0
We never set connector->doublescan_allowed, so the probe helper already filters out all doublescan modes for us. Sadly we still need to keep the explicit doublescan checks in .compute_config as outlined in commit e4dd27aadd20 ("drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI") Reviewed-by: Vandita Kulkarni <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-13drm/i915: Prevent HW access during init from connector get_modes hooksImre Deak1-0/+3
Prevent accessing the HW from the get_modes hooks of connectors deriving the mode list from the display's EDID. drm_edid_connector_add_modes() will return the mode list based on the EDID which was cached during a previous detection/get_modes call. This also fixes the NULL deref problem (10085) which was introduced/revealed by commit bab87ef4db9a ("drm/i915: Disable hotplug detection handlers during driver init/shutdown") After the above change MST connectors will not change state during driver init/shutdown; thus some of these connectors with no I2C/DDC adapter registered for them (since the given MST port has no sink connected) may stay then in the 'unknown' connector status. The get_modes() hook should not try to use the I2C/DDC adapter in this state (which would lead to the above NULL deref) which this patch ensures. v2: - Remove the redundant check from intel_crt_ddc_get_modes(). - Rebase on latest drm-tip. - Add Fixes: line / related commit notes. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10085 Fixes: bab87ef4db9a ("drm/i915: Disable hotplug detection handlers during driver init/shutdown") Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-01-08drm/i915: Disable hotplug detection handlers during driver init/shutdownImre Deak1-0/+4
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/[email protected] Reviewed-by: Jouni Högander <[email protected]> Signed-off-by: Imre Deak <[email protected]>
2024-01-08drm/i915: Init DRM connector polled field earlyImre Deak1-0/+1
After an HPD IRQ storm on a connector intel_hpd_irq_storm_detect() will set the connector's HPD pin state to HPD_MARK_DISABLED and the IRQ gets disabled. Subsequently intel_hpd_irq_storm_switch_to_polling() will enable polling for these connectors, setting the pin state to HPD_DISABLED, but only if the connector's base.polled field is set to DRM_CONNECTOR_POLL_HPD. intel_hpd_irq_storm_reenable_work() will reenable the IRQ - after 2 minutes - if the pin state is HPD_DISABLED. The connectors will be created with their base.polled field set to 0, which gets initialized only later in i915_hpd_poll_init_work() (using intel_connector::polled). If a storm is detected on a connector after it's created and IRQs are enabled on it - by intel_hpd_init() - and before its bease.polled field is initialized in the above work, the connector's HPD pin will stay in the HPD_MARK_DISABLED state - leaving the IRQ disabled indefinitely - and polling will not get enabled on it as intended. I can't see a reason for initializing base.polled in a delayed manner, so do this already when creating the connector, to prevent the above race condition. Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jouni Högander <[email protected]> Signed-off-by: Imre Deak <[email protected]>
2023-11-29drm/i915: Skip some timing checks on BXT/GLK DSI transcodersVille Syrjälä1-0/+5
Apparently some BXT/GLK systems have DSI panels whose timings don't agree with the normal cpu transcoder hblank>=32 limitation. This is perhaps fine as there are no specific hblank/etc. limits listed for the BXT/GLK DSI transcoders. Move those checks out from the global intel_mode_valid() into into connector specific .mode_valid() hooks, skipping BXT/GLK DSI connectors. We'll leave the basic [hv]display/[hv]total checks in intel_mode_valid() as those seem like sensible upper limits regardless of the transcoder used. Cc: [email protected] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9720 Fixes: 8f4b1068e7fc ("drm/i915: Check some transcoder timing minimum limits") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2023-10-26drm/i915/display: Move load_detect_test parameter under displayJouni Högander1-2/+2
Signed-off-by: Jouni Högander <[email protected]> Acked-by: Jani Nikula <[email protected]> Reviewed-by: Luca Coelho <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-04drm/i915: convert INTEL_DISPLAY_ENABLED() into a functionJani Nikula1-1/+1
There's no need for this to be a macro. Add some documentation too. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/480b9b697b2ffa0c8677115bd443ba633801c6c1.1696336887.git.jani.nikula@intel.com
2023-09-28drm/i915/fdi: Improve FDI BW sharing between pipe B and CImre Deak1-0/+7
At the moment modesetting pipe C on IVB will fail if pipe B uses 4 FDI lanes. Make the BW sharing more dynamic by trying to reduce pipe B's link bpp in this case, until pipe B uses only up to 2 FDI lanes. For this instead of the encoder compute config retry loop - which reduced link bpp only for the encoder's pipe - reduce the maximum link bpp for pipe B/C as required after all CRTC states are computed and recompute the CRTC states with the new bpp limit. Atm, all FDI encoder's compute config function returns an error if a BW constrain prevents increasing the pipe bpp value. The corresponding crtc_state->bw_constrained check can be replaced with checking crtc_state->max_link_bpp_x16, add TODO comments for this. SDVO is an exception where this case is only handled in the outer config retry loop, failing the modeset with a WARN, add a FIXME comment to handle this in the encoder code similarly to other encoders. v2: - Don't assume that a CRTC is already in the atomic state, while reducing its link bpp. - Add DocBook description to intel_fdi_atomic_check_link(). v3: - Enable BW management for FDI links in a separate patch. (Ville) v4: (Ville) - Fail the SDVO encoder config computation if it doesn't support the link bpp limit. - Add TODO: comments about checking link_bpp_x16 instead of bw_constrained. v5: - Replace link bpp limit check with a FIXME: comment in intel_sdvo_compute_config(). (Ville) Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> [Amended commit message wrt. changes in v5] Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-15drm/i915/crt: Populate connector->ddcVille Syrjälä1-7/+9
Populate connector->ddc, and thus create the "ddc" symlink in sysfs for analog VGA connectors. As a bonus we can replace a bunch of intel_gmbus_get_adapter() lookups with just the connector->ddc pointer. Sadly one extra lookup still remains due to the g4x DVI-I shenanigans. We could perhaps consider borrowing the ddc proxy idea from SDVO to deal with that in a perhaps nicer way, but can't really be bothered right now at least. Also not sure exposing such a dual ddc bus to userspace would be quite wise. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2023-09-15drm/i915: Call the DDC bus i2c adapter "ddc"Ville Syrjälä1-16/+16
Rename the various names we've used for the DDC bus i2c adapter ("i2c", "adapter", etc.) to just "ddc". This differentiates it from the various other i2c busses we might have (DSI panel stuff, DVO control bus, etc.). v2: Don't add a bogus drm_get_edid() call (Jani) Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-13drm/i915: Introduce crtc_state->enhanced_framingVille Syrjälä1-0/+2
Track DP enhanced framing properly in the crtc state instead of relying just on the cached DPCD everywhere, and hook it up into the state check and dump. v2: Actually set enhanced_framing in .compute_config() Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Luca Coelho <[email protected]>
2023-09-01drm/i915/display: use drm_edid_is_digital()Jani Nikula1-7/+4
Reduce the use of struct edid and drm_edid_raw(). Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/dbc0269d34f3140aff410eefae8a2711c59299b3.1692884619.git.jani.nikula@intel.com
2023-08-11drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resumeImre Deak1-6/+0
The issue fixed in commit a8ddac7c9f06 ("drm/i915: Avoid HPD poll detect triggering a new detect cycle") on VLV, CHV is still present on platforms where the display hotplug detection functionality is available whenever the device is in D0 state (hence these platforms switch to HPD polling only when the device is runtime suspended). The above commit avoids an endless i915_hpd_poll_init_work() -> connector detect loop by making sure that by the end of i915_hpd_poll_init_work() all display power references acquired by the connector detect functions which can trigger a new cycle (display core power domain) are dropped. However on platforms where HPD polling is enabled/disabled only from the runtime suspend/resume handlers, this is not ensured: for instance eDP VDD, TypeC port PHYs and the runtime autosuspend delay may still keep the device runtime resumed (via a power reference acquired during connector detection and hence result in an endless loop like the above). Solve the problem described in the above commit on all platforms, by making sure that a i915_hpd_poll_init_work() -> connector detect sequence can't take any power reference in the first place which would trigger a new cycle, instead of relying on these power references to be dropped by the end of the sequence. With the default runtime autosuspend delay (10 sec) this issue didn't happen in practice, since the device remained runtime resumed for the whole duration of the above sequence. CI/IGT tests however set the autosuspend delay to 0, which makes the problem visible, see References: below. Tested on GLK, CHV. v2: Don't warn about a requeued work, to account for disabling polling directly during driver loading, reset and system resume. References: https://gitlab.freedesktop.org/drm/intel/-/issues/7940#note_1997403 Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-20drm/i915: Assert that the port being initialized is validVille Syrjälä1-0/+2
Sprinkle some asserts to catch any mishaps in the port_mask vs. output init. For DDI/DP/HDMI/SDVO I decided that we want to bail out for an invalid port since those are the encoder types where we might want consider driving the whole thing from the VBT child device list, and bogus VBTs could be a real issue (if for no other reason than the i915.vbt_firmware). For DVO and HSW/BDW CRT port I just threw the assert in there for good measure. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-02drm/i915/display: switch the rest of the connectors to struct drm_edidJani Nikula1-16/+18
Convert the remaining uses of struct edid based drm_get_edid(), drm_connector_update_edid_property() and drm_add_edid_modes() calls to the struct drm_edid based drm_edid_read_ddc(), drm_edid_connector_update() and drm_edid_connector_add_modes(). Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/b1b53bb9004adaa402e061f7df2caf0eb4723a43.1685437501.git.jani.nikula@intel.com
2023-05-16drm/i915/irq: split out hotplug irq handlingJani Nikula1-0/+1
Split hotplug irq handling out of i915_irq.[ch] into display/intel_hotplug_irq.[ch]. The line between the new intel_hotplug_irq.[ch] and the existing intel_hotplug.[ch] needs further clarification, but the first step is to move the stuff out of i915_irq.[ch]. Reviewed-by: Rodrigo Vivi <[email protected]> Reviewed-by: Gustavo Sousa <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-05drm/i915/display: Add new member to configure PCON color conversionAnkit Nautiyal1-0/+1
The decision to use DFP output format conversion capabilities should be during compute_config phase. This patch adds new member to crtc_state to represent the final output_format to the sink. In case of a DFP this can be different than the output_format, as per the format conversion done via the PCON. This will help to store only the format conversion capabilities of the DP device in intel_dp->dfp, and use crtc_state to compute and store the configuration for color/format conversion for a given mode. v2: modified the new member to crtc_state to represent the final output_format that eaches the sink, after possible conversion by PCON kind of devices. (Ville) v3: Addressed comments from Ville: -Added comments to clarify difference between sink_format and output_format. -Corrected the order of setting sink_format and output_format. -Added readout for sink_format in get_pipe_config hooks. v4: Set sink_format for intel_sdvo too. (Ville) v5: Rebased. v6: Fixed condition to go for YCbCr420 format for dp and hdmi. (Ville) v7: Fix the condition to set sink_format for HDMI. Set hdmi output_format simply as sink_format. (Ville) Signed-off-by: Ankit Nautiyal <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> (v3) Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-04-20drm/i915/display: throw out struct intel_load_detect_pipeJani Nikula1-9/+9
An error-valued pointer can handle all in one without the wrapper struct. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-04-20drm/i915/display: split out load detect to a separate fileJani Nikula1-2/+3
Load detect is shared between tv and crt but otherwise isolated in intel_display.c. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-30drm/i915/fdi: split out FDI regs to a separate fileJani Nikula1-0/+1
Clean up i915_reg.h by splitting out FDI regs to display/intel_fdi_regs.h. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/bba37e46d767e2193d49d1d2e289040c6bf8229b.1678973282.git.jani.nikula@intel.com
2023-02-17drm/i915: Define transcoder timing register bitmasksVille Syrjälä1-6/+7
Define the contents of the transcoder timing registers using REG_GENMASK() & co. For ease of maintenance let's just define the bitmasks with the full 16bit width (also used by the current hand rolled stuff) even though not all bits are actually used. None of the unsued bits have ever contained anything. Jani spotted that the CRT load detection code did use narrower bitmasks, so that is now going to change. But that is fine since any garbage in the high bits would have been caught by the state checker that always used the full 16bit masks. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2023-02-17drm/i915: s/PIPECONF/TRANSCONF/Ville Syrjälä1-5/+5
Rename PIPECONF to TRANSCONF to make it clear what it actually applies to. While the usual convention is to pick the earliers name I think in this case it's more clear to use the later name. Especially as even the register offset is in the wrong range (0x70000 vs. 0x60000) and thus makes it look like this is per-pipe. There is one place in gvt that's doing something with TRANSCONF while iterating with for_each_pipe(). So that might not be doing the right thing for TRANSCODER_EDP, dunno. Not knowing what it does I left it as is to avoid breakage. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2023-02-17drm/i915: Give CPU transcoder timing registers TRANS_ prefixVille Syrjälä1-9/+10
Name the CPU transcoder timing registers TRANS_FOO rather than just FOO. This is the modern name, after the pipe/transcoder split happened. Makes it a bit more obvious whether you pass in a pipe or a transcoder. PIPESRC is a bit special as it's a pipe register, even though it lives in the transcoder registers range (0x60000 instead of 0x70000). And BCLRPAT I suppose is a transcoder register (since it has something to do with the timing generator), but it doesn't even exist after gen4 so I left it to use the only name it ever had in bspec. And while at it let's pass in the correct enum in few more places why don't we. Although in all those places the distinction doesn't matter. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2023-02-17drm/i915: Rename intel_ddi_{enable,disable}_pipe_clock()Ville Syrjälä1-2/+2
What intel_ddi_{enable,disable}_pipe_clock() actually do is enable the clock to the transcoder, not the pipe. Rename accordingly. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-12-08drm/i915/crt: switch to intel_de_* register accessors in display codeJani Nikula1-23/+19
Avoid direct uncore use in display code. Cc: Maarten Lankhorst <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/39c198439be580052d1f78a44c96df7ba8ffd56d.1670433372.git.jani.nikula@intel.com
2022-12-08drm/i915/crt: drop a bunch of unnecessary register variablesJani Nikula1-24/+15
There's no need to save the register offsets. Drop the variables. Cc: Maarten Lankhorst <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/3493286ecd1ae166e1e15235d31115f766f7c878.1670433372.git.jani.nikula@intel.com
2022-11-11drm/i915: stop including i915_irq.h from i915_trace.hJani Nikula1-0/+2
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 <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/6e78a2e0ac1bffaf5af3b5ccc21dff05e6518cef.1668008071.git.jani.nikula@intel.com
2022-09-26drm/i915: Clean up connector->*_allowed setupVille Syrjälä1-5/+2
All the connectors are zero initialized so no need to clear the *_allowed flags we don't support. Only leave the ones we want to set. And while at it switch to booleans instead of ints. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-09-26drm/i915: Use BIT() when dealing with output typesVille Syrjälä1-1/+1
Most places that deal with output types already use BIT() but a few places still use manual shifts. Convert the stragglers over to BIT(). Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Luca Coelho <[email protected]> Reviewed-by: Jani Nikula <[email protected]>
2022-09-08drm/i915: Feed the DPLL output freq back into crtc_stateVille Syrjälä1-0/+3
Fill port_clock and hw.adjusted_mode.crtc_clock with the actual frequency we're going to be getting from the hardware. This will let us accurately compute all derived state that depends on those. v2: Reintroduce iCLKIP WARN v3: Try to deal with VLV/BXT DSI PLL as well Reviewed-by: Jani Nikula <[email protected]> #v1 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-08-31drm/i915/crt: remove BUG_ON()Jani Nikula1-2/+0
Avoid BUG_ON(). We don't have such checks on output type anywhere else either, so just remove. Suggested-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-08-31drm/i915: move and group fdi members under display.fdiJani Nikula1-2/+2
Move display fdi related members under drm_i915_private display sub-struct. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/b66fe7cf2c6f9e5b7bbfcaff40400492ac706721.1661779055.git.jani.nikula@intel.com
2022-08-31drm/i915: move vbt to display.vbtJani Nikula1-2/+2
Move display VBT related members under drm_i915_private display sub-struct. v2: Rebase Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/db4b648b201ea0b79654fec2028120999a735db0.1661779055.git.jani.nikula@intel.com
2021-12-02drm/i915/display: remove intel_wait_for_vblank()Jani Nikula1-1/+1
There are only three call sites remaining for intel_wait_for_vblank(). Remove the function, and open code it to avoid new users from showing up. v2: - Use intel_crtc_wait_for_next_vblank() (Ville) Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/aabcda1208072a732d7796e6dacce37dca9bb843.1638366969.git.jani.nikula@intel.com
2021-12-02drm/i915/display: add intel_crtc_wait_for_next_vblank() and use itJani Nikula1-2/+2
intel_wait_for_vblank() goes through a pipe to crtc lookup, while in most cases we already have the crtc available. Avoid the extra lookups by adding an intel_crtc based helper. v2: - Add intel_crtc_wait_for_next_vblank() helper (Ville) Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/90cfbd8c3e79a742b0ee9e3ae75493acb0785dbb.1638366969.git.jani.nikula@intel.com
2021-10-19drm/i915: Introduce lpt_pch_disable()Ville Syrjälä1-3/+2
Let's add lpt_pch_disable() as the counterpart to lpt_pch_enable(). Note that unlike the ilk+ code the fdi_link_train() and fdi_disable() calls are still left directly in intel_crt.c. If we wanted to move those we'd need to add lpt_pch_pre_enable(). But the two fdi direct fdi calls are pretry symmetric so it doesn't seem too bad to just keep them as is. v2: Make lpt_disable_pch_transcoder() static ([email protected]) Cc: Dave Airlie <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Dave Airlie <[email protected]>
2021-10-19drm/i915: Move intel_ddi_fdi_post_disable() to fdi codeVille Syrjälä1-1/+1
Reanme intel_ddi_fdi_post_disable() to hsw_fdi_disable() and relocate it next to all the other code dealing with FDI_RX. intel_ddi.c has now been cleansed of FDI_RX. In order to avoid exposing intel_disable_ddi_buf() outside intel_ddi.c we can just open code the DDI_BUF_CTL write. The enable side already has all that stuff open coded so this actually is more symmetric. But we do need to remeber to bring the intel_wait_ddi_buf_idle() call over from inside intel_disable_ddi_buf(). Cc: Dave Airlie <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Dave Airlie <[email protected]>
2021-10-19drm/i915: Move iCLKIP readout to the pch codeVille Syrjälä1-4/+0
Move the lpt_get_iclkip() call from hsw_crt_get_config() since that's where we have the lpt_program_iclkip() call as well. Tehcnically this isn't perhaps quite right since iCLKIP is providing the CRT dotclock. So one can argue all of it should be directly in intel_crt.c. But since the CRT port is the only one on the PCH sticking it all into the PCH code seems OK. Cc: Dave Airlie <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Dave Airlie <[email protected]>
2021-10-19drm/i915: Move LPT PCH readout codeVille Syrjälä1-0/+2
Nuke the hsw_get_ddi_port_state() eyesore by putting the readout code into intel_pch_display.c, and calling it directly from hsw_crt_get_config(). Note that the nuked TRANS_DDI_FUNC_CTL readout from hsw_get_ddi_port_state() is now etirely redundant since we get called from the encoder->get_config() so we already know we're dealing with the correct DDI port. Previously the code was called from a place where that wasn't known so it had to checked manually. v2: Clarify the TRANS_DDI_FUNC_CTL change (Dave) Nuke the now unused *TRANS_DDI_FUNC_CTL_VAL_TO_PORT() (Dave) Cc: Dave Airlie <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Dave Airlie <[email protected]>
2021-10-19drm/i915: Clean up the {ilk,lpt}_pch_enable() calling conventionVille Syrjälä1-1/+1
Use the clean "atomic_state+crtc" approach of passing arguments to the top level PCH modeset code. And while at it we can also just pass the whole crtc to ilk_disable_pch_transcoder(). v2: Elimiate double space between function args (Dave) Cc: Dave Airlie <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Dave Airlie <[email protected]>
2021-10-19drm/i915: Move PCH modeset code to its own fileVille Syrjälä1-0/+1
Start moving the code for PCH modeset sequence/etc. to its own file. Still not sure about the file name though... Cc: Dave Airlie <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Dave Airlie <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.