summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display/intel_crt.c
AgeCommit message (Collapse)Author
2023-06-02drm/i915/display: switch the rest of the connectors to struct drm_edidJani Nikula
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 <ankit.k.nautiyal@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b1b53bb9004adaa402e061f7df2caf0eb4723a43.1685437501.git.jani.nikula@intel.com
2023-05-16drm/i915/irq: split out hotplug irq handlingJani Nikula
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 <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/20230515101738.2399816-2-jani.nikula@intel.com
2023-05-05drm/i915/display: Add new member to configure PCON color conversionAnkit Nautiyal
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 <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v3) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230427125605.487769-2-ankit.k.nautiyal@intel.com
2023-04-20drm/i915/display: throw out struct intel_load_detect_pipeJani Nikula
An error-valued pointer can handle all in one without the wrapper struct. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417153741.1074692-2-jani.nikula@intel.com
2023-04-20drm/i915/display: split out load detect to a separate fileJani Nikula
Load detect is shared between tv and crt but otherwise isolated in intel_display.c. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417153741.1074692-1-jani.nikula@intel.com
2023-03-30drm/i915/fdi: split out FDI regs to a separate fileJani Nikula
Clean up i915_reg.h by splitting out FDI regs to display/intel_fdi_regs.h. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> 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ä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-17drm/i915: s/PIPECONF/TRANSCONF/Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-17drm/i915: Give CPU transcoder timing registers TRANS_ prefixVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-17drm/i915: Rename intel_ddi_{enable,disable}_pipe_clock()Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-12-08drm/i915/crt: switch to intel_de_* register accessors in display codeJani Nikula
Avoid direct uncore use in display code. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> 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 Nikula
There's no need to save the register offsets. Drop the variables. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> 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 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-09-26drm/i915: Clean up connector->*_allowed setupVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220912111814.17466-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-09-26drm/i915: Use BIT() when dealing with output typesVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220912111814.17466-5-ville.syrjala@linux.intel.com Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-09-08drm/i915: Feed the DPLL output freq back into crtc_stateVille Syrjälä
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 <jani.nikula@intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220907091057.11572-8-ville.syrjala@linux.intel.com
2022-08-31drm/i915/crt: remove BUG_ON()Jani Nikula
Avoid BUG_ON(). We don't have such checks on output type anywhere else either, so just remove. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220830093411.1511040-1-jani.nikula@intel.com
2022-08-31drm/i915: move and group fdi members under display.fdiJani Nikula
Move display fdi related members under drm_i915_private display sub-struct. 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/b66fe7cf2c6f9e5b7bbfcaff40400492ac706721.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
2021-12-02drm/i915/display: remove intel_wait_for_vblank()Jani Nikula
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 <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> 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 Nikula
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 <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> 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ä
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 (lkp@intel.com) Cc: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-10-ville.syrjala@linux.intel.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-10-19drm/i915: Move intel_ddi_fdi_post_disable() to fdi codeVille Syrjälä
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 <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-9-ville.syrjala@linux.intel.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-10-19drm/i915: Move iCLKIP readout to the pch codeVille Syrjälä
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 <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-7-ville.syrjala@linux.intel.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-10-19drm/i915: Move LPT PCH readout codeVille Syrjälä
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 <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018153525.21597-1-ville.syrjala@linux.intel.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-10-19drm/i915: Clean up the {ilk,lpt}_pch_enable() calling conventionVille Syrjälä
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 <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-4-ville.syrjala@linux.intel.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-10-19drm/i915: Move PCH modeset code to its own fileVille Syrjälä
Start moving the code for PCH modeset sequence/etc. to its own file. Still not sure about the file name though... Cc: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-3-ville.syrjala@linux.intel.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-10-19drm/i915: Move PCH refclock stuff into its own fileVille Syrjälä
Move the PCH refclk stuff (including all the LPT/WPT iCLKIP/CLKOUT_DP things) to its own file. We also suck in the mPHY programming from intel_fdi.c since we're the only caller. Cc: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-2-ville.syrjala@linux.intel.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-09-15drm/i915: s/pipe/transcoder/ when dealing with PIPECONF/TRANSCONFVille Syrjälä
PIPECONF becamse TRANSCONF when HSW introduced the EDP transcoder. Bigjoiner is making life even more confusing by introducing a N:1 relationship between pipes and transcoders. In that case we only enable/configure the transcoder corresponding to the master pipe. Let's do some renames to make it clear we're dealing with the transcoder rather than pipe when it comes to PIPECONF/TRANSCONF. I decided to leave the _cpu_ part out from the function/macro names since the PCH transcoder related stuff already has a _pch_ in their name. So shouldn't be possible to confuse them. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210913144440.23008-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-06-23drm/i915: Introduce encoder->get_buf_trans()Ville Syrjälä
Convert the get_buf_trans() functions into an encoder vfunc. Allows us to get rid of bunch of platform if-ladders. v2: Handle adl-p 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/20210608073603.2408-10-ville.syrjala@linux.intel.com
2021-05-05drm/i915: Don't include intel_de.h from intel_display_types.hVille Syrjälä
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 <cooper.chiou@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@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/20210430143945.6776-1-ville.syrjala@linux.intel.com
2021-04-28drm/i915/display: move crtc and dpll declarations where they belongJani Nikula
The definitions are in the crtc and dpll files; move the declarations to the corresponding headers. 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/20210427120315.12342-1-jani.nikula@intel.com
2021-04-14drm/i915/display: rename display version macrosLucas De Marchi
While converting the rest of the driver to use GRAPHICS_VER() and MEDIA_VER(), following what was done for display, some discussions went back on what we did for display: 1) Why is the == comparison special that deserves a separate macro instead of just getting the version and comparing directly like is done for >, >=, <=? 2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for brevity. If we remove the current users of IS_DISPLAY_VER(), we could actually repurpose it for a range check With (1) there could be an advantage if we used gen_mask since multiple conditionals be combined by the compiler in a single and instruction and check the result. However a) INTEL_GEN() doesn't use the mask since it would make the code bigger everywhere else and b) in the cases it made sense, it also made sense to convert to the _RANGE() variant. So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER() users to use == and != operators. Aside from the definition changes, this was done by the following semantic patch: @@ expression dev_priv, E1; @@ - !IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) != E1 @@ expression dev_priv, E1; @@ - IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) == E1 @@ expression dev_priv, from, until; @@ - IS_DISPLAY_RANGE(dev_priv, from, until) + IS_DISPLAY_VER(dev_priv, from, until) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> [Jani: Minor conflict resolve while applying.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com
2021-03-23drm/i915/display: Eliminate most usage of INTEL_GEN()Matt Roper
Use Coccinelle to convert most of the usage of INTEL_GEN() and IS_GEN() in the display code to use DISPLAY_VER() comparisons instead. The following semantic patch was used: @@ expression dev_priv, E; @@ - INTEL_GEN(dev_priv) == E + IS_DISPLAY_VER(dev_priv, E) @@ expression dev_priv; @@ - INTEL_GEN(dev_priv) + DISPLAY_VER(dev_priv) @@ expression dev_priv; expression E; @@ - IS_GEN(dev_priv, E) + IS_DISPLAY_VER(dev_priv, E) @@ expression dev_priv; expression from, until; @@ - IS_GEN_RANGE(dev_priv, from, until) + IS_DISPLAY_RANGE(dev_priv, from, until) There are still some display-related uses of INTEL_GEN() in intel_pm.c (watermark code) and i915_irq.c. Those will be updated separately. v2: - Use new IS_DISPLAY_RANGE and IS_DISPLAY_VER helpers. (Jani) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-4-matthew.d.roper@intel.com
2021-03-08drm/i915: Add encoder->is_clock_enabled()Ville Syrjälä
Support reading out the current state of the DDI clock. Not sure we really want this. Seems a bit excessive just to restore the debug print to icl_sanitize_encoder_pll_mapping()? But maybe there's more use for it? Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210224144214.24803-6-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-03-08drm/i915: Move DDI clock readout to encoder->get_config()Ville Syrjälä
Move the *_get_ddi_pll() stuff into the encodet->get_config() hook. There it neatly sits next to the matching .{enable,disable}_clock() functions. In order to avoid excessive boilerplate I changed the behaviour such that all platforms now do the readout via crtc_state->port_dpll[]. ICL+ TC is still a bit special due to TBTPLL not having a functional .get_freq(). Should probably change that by adopting the LCPLL approach, but that would require a fairly substantial rework of the DPLL ID handling. So leave it for later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210224144214.24803-5-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-02-16drm/i915: Extract hsw_ddi_{enable,disable}_clock()Ville Syrjälä
Yank out the HSW/BDW code from intel_ddi_clk_{select,disable}() and put it into the new encoder .{enable,disable}_clock() vfuncs. v2: s/dev_priv/i915/ (Lucas) v3: Deal with FDI Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> #v2 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-4-ville.syrjala@linux.intel.com
2021-02-05drm/i915: migrate hsw fdi code to new file.Dave Airlie
Daniel asked for this, but it's a bit messy and I'm not sure how best to clean it up yet. Signed-off-by: Dave Airlie <airlied@redhat.com> [Jani: also moved fdi buf trans to intel_fdi.c.] 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/44491f2465549ea5c2e48cde5437fa232f77ab96.1612467466.git.jani.nikula@intel.com
2020-09-15drm/i915: Reduce INTEL_DISPLAY_ENABLED to just treat outputs as disconnectedVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200910164256.25983-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-06-22drm/i915/params: switch to device specific parametersJani Nikula
Start using device specific parameters instead of module parameters for most things. The module parameters become the immutable initial values for i915 parameters. The device specific parameters in i915->params start life as a copy of i915_modparams. Any later changes are only reflected in the debugfs. The stragglers are: * i915.force_probe and i915.modeset. Needed before dev_priv is available. This is fine because the parameters are read-only and never modified. * i915.verbose_state_checks. Passing dev_priv to I915_STATE_WARN and I915_STATE_WARN_ON would result in massive and ugly churn. This is handled by not exposing the parameter via debugfs, and leaving the parameter writable in sysfs. This may be fixed up in follow-up work. * i915.inject_probe_failure. Only makes sense in terms of the module, not the device. This is handled by not exposing the parameter via debugfs. v2: Fix uc i915 lookup code (Michał Winiarski) Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200618150402.14022-1-jani.nikula@intel.com
2020-04-20drm/i915: Pass encoder all the way to intel_ddi_transcoder_func_reg_val_get()Ville Syrjälä
Pass the encoder all the way down to intel_ddi_transcoder_func_reg_val_get(). Allows us eliminate the intel_ddi_get_crtc_encoder() eyesore. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200417134720.16654-4-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jani Nikula <jani.nikula@intel.com>
2020-04-20drm/i915: Push TRANS_DDI_FUNC_CTL into the encoder->enable() hookVille Syrjälä
Push the TRANS_DDI_FUNC_CTL into the encoder enable hook. The disable is already there, and as a followup will enable us to pass the encoder all the way down. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200417134720.16654-3-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jani Nikula <jani.nikula@intel.com>
2020-04-20drm/i915: Pass encoder to intel_ddi_enable_pipe_clock()Ville Syrjälä
Since intel_ddi_enable_pipe_clock() was pushed down into the encoder hooks we can pass on the encoder instead of having to use intel_ddi_get_crtc_encoder(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200417134720.16654-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jani Nikula <jani.nikula@intel.com>
2020-04-08drm/i915/crt: use struct drm_device based loggingJani Nikula
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200402114819.17232-5-jani.nikula@intel.com
2020-04-03drm/i915: Pass atomic state to encoder hooksVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200313164831.5980-13-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-02-27drm/i915: significantly reduce the use of <drm/i915_drm.h>Jani Nikula
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 <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225133131.3301-1-jani.nikula@intel.com
2020-02-20drm/i915: Mark all HPD capabled connectors as suchVille Syrjälä
Currently we only set the DRM_CONNECTOR_POLL_{DISCONNECT,CONNECT} bits in intel_connector->polled (the base setting), leading to some confusing looking code to reset drm_connector->polled (the actual setting) to DRM_CONNECTOR_POLL_HPD. Let's set intel_connector->polled = DRM_CONNECTOR_POLL_HPD for all hpd capable connectors, and then we don't need so many special cases in the hotplug code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200205183546.9291-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-02-11drm/i915/crt: automatic conversion to drm_device based logging macros.Wambui Karuga
Replaces various instances of the printk based logging macros with the struct drm_device based logging macros in i915/display/intel_crt.c using the following coccinelle script that matches based on the existence of a drm_i915_private device pointer: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Checkpatch warnings were addressed manually. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200206080014.13759-6-wambui.karugax@gmail.com
2020-02-04drm/i915/crt: Configure connector->polled and encoder->hpd_pin consistentlyVille Syrjälä
Let's make sure encoder->hpd_pin and connector->polled are mirror images of each other (when we want to use polling). The other potentially polled connectors (sdvo and tv) already get this right. Also nuke the redundant force_hotplug_required initialization (the thing is kzalloc()ed). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121171100.4370-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-02-02drm/i915/display/crt: Make WARN* drm specific where drm_priv ptr is availablePankaj Bharadiya
drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. @rule1@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule2@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128181603.27767-5-pankaj.laxminarayan.bharadiya@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-30 07:19:40 +0000