aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display/intel_dvo.c
AgeCommit message (Collapse)AuthorFilesLines
2024-07-22drm/i915: Make I2C terminology more inclusiveEaswar Hariharan1-7/+7
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/, fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists in the specification. Reviewed-by: Rodrigo Vivi <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> Acked-by: Zhi Wang <[email protected]> Signed-off-by: Easwar Hariharan <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-07drm/i915: pass dev_priv explicitly to DPLLJani Nikula1-2/+3
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the DPLL register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/7deea1d86c2706994450ec938f8f174a2ac54d27.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/+5
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/+6
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-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-15drm/i915/dvo: Populate connector->ddcVille Syrjälä1-6/+5
Populate connector->ddc, and thus create the "ddc" symlink in sysfs for DVO connectors. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[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-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-02-16drm/i915/display/misc: use intel_de_rmw if possibleAndrzej Hajda1-5/+2
The helper makes the code more compact and readable. Signed-off-by: Andrzej Hajda <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-26drm/i915/panel: move panel fixed EDID to struct intel_panelJani Nikula1-1/+1
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ä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/328350ef918638928a8286cdbab3107c8258332d.1674643465.git.jani.nikula@intel.com
2022-11-23drm/i915/dvo: Log about what was detected on which DVO portVille Syrjälä1-0/+4
Currently it's not 100% obvious which DVO encoder chip was found on which port. Leave a slightly better trace in log. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-11-23drm/i915/dvo: Extract intel_dvo_regs.hVille Syrjälä1-0/+1
Pull the DVO port register definitons into their own header to declutter i915_reg.h a bit. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-11-23drm/i915/dvo: Use intel_de_rmw() for DVO enable/disableVille Syrjälä1-6/+5
Replace the hand rolled RMW with intel_de_rmw() in the DVO port enable/disable functions. Also switch to intel_de_posting_read() for the posting read (though maybe it should be just be nuked...). Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-11-23drm/i915/dvo: Use REG_BIT() & co. for DVO registersVille Syrjälä1-3/+4
Polish the DVO port registers with REG_BIT()/etc. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-11-23drm/i915/dvo: Rename the "active data order" bitsVille Syrjälä1-2/+2
We have two sets of bits for DVO "data order" stuff. Rename one set to ACT_DATA_ORDER to make it clear they are separate bitfields. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-11-23drm/i915/dvo: Define a few more DVO register bitsVille Syrjälä1-1/+2
Define a few extra interrupt related bits on the DVO register. One of these we included in the DVO_PRESERVE_MASK already. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]>
2022-11-23drm/i915/dvo: Parametrize DVO/DVO_SRCDIM registersVille Syrjälä1-45/+28
Get rid of the dvo_reg/dvo_srcdim_reg stuff by parametrizing the DVO port registers. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-11-19drm/i915/dvo: Use per device debugsVille Syrjälä1-2/+2
Convert the lonely DRM_DEBUG_KMS() to the per-device variant. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-11-19drm/i915/dvo: s/dev_priv/i915/Ville Syrjälä1-27/+26
Follow the modern style and rename most 'dev_priv' variables to 'i915'. intel_dvo_init_dev() is the sole exception since it needs the magic 'dev_priv' variable for the DPLL register macros. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-11-19drm/i915/dvo: s/intel_encoder/encoder/ etc.Ville Syrjälä1-46/+45
Remove the pointless intel_ namespace from our encoder/connector variables. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-11-19drm/i915/dvo: Flatten intel_dvo_init()Ville Syrjälä1-100/+117
The loop over intel_dvo_devices[] makes intel_dvo_init() an ugly mess. Pull the i2c device probe out to a separate function so that we can get rid of the loop and flatten the code. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-11-19drm/i915/dvo: Eliminate useless 'port' variableVille Syrjälä1-8/+6
Reorder the drm_encoder_init() vs. encoder->port assignment so that we don't need the extra 'port' variable. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-11-19drm/i915/dvo: Introduce intel_dvo_connector_type()Ville Syrjälä1-13/+19
Introduce intel_dvo_connector_type() as a counterpart to intel_dvo_encoder_type(), mainly to declutter intel_dvo_init() a bit. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-11-19drm/i915/dvo: Actually initialize the DVO encoder typeVille Syrjälä1-4/+16
We call drm_encoder_init() before determining the correct encoder type, thus we always end up with DRM_MODE_ENCODER_NONE. Determine the correct encoder type earlier. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-11-19drm/i915/dvo: Don't leak connector state on DVO init failureVille Syrjälä1-1/+1
If we can't initialize the DVO encoder also free the connector state allocated by intel_connector_alloc(). Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-11-19drm/i915/dvo: Remove unused panel_wants_ditherVille Syrjälä1-4/+0
intel_dvo.panel_wants_dither is only set but never used. We can't do dithering on the gmch side anyway since the dithering logic is part of the integrated LVDS port and not available for other output types. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-11-11drm/i915: stop including i915_irq.h from i915_trace.hJani Nikula1-0/+1
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-2/+0
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-2/+2
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-03-31drm/i915: Put fixed modes directly onto the panel's fixed_modes listVille Syrjälä1-5/+4
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ä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-03-29drm/i915: Extract intel_panel_encoder_fixed_mode()Ville Syrjälä1-24/+6
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ä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-03-29drm/i915: Use DRM_MODE_FMT+DRM_MODE_ARG()Ville Syrjälä1-2/+2
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ä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-03-29drm/i915: Pass intel_connector to intel_panel_{init,fini}()Ville Syrjälä1-1/+1
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ä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-03-15drm/i915: Introduce intel_panel_get_modes()Ville Syrjälä1-13/+1
Several connectors want to return the fixed_mode from .get_modes(), add a helper to do that (and hide the details inside intel_panel.c). Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-03-15drm/i915: Introduce intel_panel_{fixed,downclock}_mode()Ville Syrjälä1-3/+3
Abstract away the details on where we store the fixed/downclock modes, and also how we select them. Will be useful for static DRRS (aka. allowing the user to select the refresh rate for the panel). We pass in the user requested mode to intel_panel_fixed_mode() so that in the future it may try to match the refresh rate. And intel_panel_downclock_mode() gets passed the adjusted_mode we actually chose to use so that it may find a suitable lower resresh rate variant. v2: Hook it up for all encoders s/fixed_mode/adjusted_mode/ in intel_panel_downclock_mode() (Jani) Elaborate on the choice or arguments for the functions (Jani) Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2021-09-30drm/i915: Introduce intel_panel_compute_config()Ville Syrjälä1-2/+8
Let's introduce a compute_config() helper for fixed mode panels. For now all it does is the fixed_mode->adjusted_mode copy. Note that with sDVO we have to ask the external encoder chip to spit out our actual display timings for us, so the fixed_mode to adjusted_mode copy done by intel_panel_compute_config() is redundant, but we still want to use it to do other checks for us later. We'll be fine so long as we only call it before intel_sdvo_get_preferred_input_mode() overwrites adjusted_mode with the timings from the encoder. v2: Use intel_panel_compute_config() with sDVO Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2021-09-30drm/i915: Use intel_panel_mode_valid() for DSI/LVDS/(s)DVOVille Syrjälä1-6/+8
All fixed mode panels should behave the same way when it comes to mode filtering. Reuse the intel_panel_mode_valid() for all of them. This changes the behaviour to match what we do for eDP, ie. reject anything that doesn't exactly match the fixed mode dimensions. Users can still manually provide different sized modes which will be handled by the panel fitter just as before. The difference is that we can no longer report funny modes in the connector's mode list. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2021-08-26drm/i915/panel: mass rename functions to have intel_panel_ prefixJani Nikula1-1/+1
Follow the usual naming conventions. Also pull HAS_GMCH() check to intel_panel_fitting(). No functional changes. Cc: Lyude Paul <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/9ff6e42e377bdb0c9349f50d9ea79671059633c7.1629888677.git.jani.nikula@intel.com
2021-05-05drm/i915: Don't include intel_de.h from intel_display_types.hVille Syrjälä1-0/+1
Hoist the intel_de.h include from intel_display_types.h one level up. I need this in order to untangle the include order so that I can add tracepoints into intel_de.h. This little cocci script did most of the work for me: @find@ @@ ( intel_de_read(...) | intel_de_read_fw(...) | intel_de_write(...) | intel_de_write_fw(...) ) @has_include@ @@ ( #include "intel_de.h" | #include "display/intel_de.h" ) @depends on find && !has_include@ @@ + #include "intel_de.h" #include "intel_display_types.h" @depends on find && !has_include@ @@ + #include "display/intel_de.h" #include "display/intel_display_types.h" Cc: Cooper Chiou <[email protected]> Reviewed-by: Anshuman Gupta <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-02drm/i915: remove last traces of I915_READ(), I915_WRITE() and POSTING_READ()Jani Nikula1-4/+0
Good riddance! Remove the macros and their remaining references in comments. The following functions should be used instead, depending on the use case: - intel_uncore_read(), intel_uncore_write(), intel_uncore_posting_read() - intel_de_read(), intel_de_write(), intel_de_posting_read() Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-15drm/i915: Reduce INTEL_DISPLAY_ENABLED to just treat outputs as disconnectedVille Syrjälä1-0/+6
Since the display hardware is all there even when INTEL_DISPLAY_ENABLED return false we have to be capable of shutting it down cleanly so as to not anger the hw. To that end let's reduce the effect of !INTEL_DISPLAY_ENABLE to just treating all outputs as disconnected. Should prevent anyone from automagically enabling any of them, while still allowing us to cleanly shut them down. v2: Put the check into the right place for CRT Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2020-07-09drm/i915/dvo: Make .get_modes() return the number of modesVille Syrjälä1-6/+8
.get_modes() is supposed to return the number of modes added to the probed_modes list (not that anyone actually checks for anything except zero vs. not zero). Let's do that. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]>
2020-04-03drm/i915: Pass atomic state to encoder hooksVille Syrjälä1-3/+6
We're going to want access to the atomic state for iterating the slave crtcs when enabling the port sync master crtc. Pass the atomic state all the way down. The alternative would be yet another encoder hook which we'll have to call after all the normal modeset stuff is done. Not really a fan of yet another hook just for this. Note that during readout state sanitation we are now going to pass NULL as the atomic state since we don't have one. We need to change that and then we can also s/crtc_state/crtc/ and s/conn_state/conn/ for the encoder hooks as well. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2020-02-27drm/i915: significantly reduce the use of <drm/i915_drm.h>Jani Nikula1-1/+0
The #include has been splattered all over the place, but there are precious few places, all .c files, that actually need it. v2: remove leftover double newlines Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-04drm/i915/dvo: Mark TMDS DVO connectors as polledVille Syrjälä1-0/+2
All the TMDS DVO chips have a sensible looking .detect(). Let's poll them. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]>
2020-02-04drm/i915: Mark ns2501 as LVDS without a fixed modeVille Syrjälä1-5/+8
ns2501 has a builtin scaler so it doesn't need a fixed mode, but let's still mark it as LVDS instead of TMDS/DVI to make life less confusing. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.