- 01 10月, 2021 2 次提交
-
-
由 Jani Nikula 提交于
Prefer i915 over drm pointer. Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921110244.8666-1-jani.nikula@intel.com
-
由 Jani Nikula 提交于
Avoid using the incidental -EPERM. Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8acf7ffe9222d23c7f47dbd95ff1f737221ff72c.1633000838.git.jani.nikula@intel.com
-
- 26 8月, 2021 1 次提交
-
-
由 Jani Nikula 提交于
Follow the usual naming conventions. Also pull HAS_GMCH() check to intel_panel_fitting(). No functional changes. Cc: Lyude Paul <lyude@redhat.com> Reviewed-by: NLyude Paul <lyude@redhat.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9ff6e42e377bdb0c9349f50d9ea79671059633c7.1629888677.git.jani.nikula@intel.com
-
- 30 7月, 2021 1 次提交
-
-
由 Matt Roper 提交于
At the moment we don't have a proper algorithm that can be used to calculate PHY settings for arbitrary HDMI link rates. The PHY tables here should support the regular modes of real-world HDMI monitors. Bspec: 54032 Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NVandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: NMatt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210723174239.1551352-25-matthew.d.roper@intel.com
-
- 25 6月, 2021 1 次提交
-
-
由 Ville Syrjälä 提交于
Clear out the straggler 'intel_crtc' variables. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210609085632.22026-7-ville.syrjala@linux.intel.comReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
- 26 5月, 2021 6 次提交
-
-
由 Ville Syrjälä 提交于
intel_hdmi_bpc_possible() will check has_hdmi_sink for us, so no need to check it in intel_hdmi_mode_clock_valid() anymore. Cc: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511160532.21446-7-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
由 Ville Syrjälä 提交于
Now that we have to tell intel_hdmi_mode_clock_valid() whether we're asking about 4:4:4 or 4:2:0 output it can take care of the dotclock->TMDS clock conversion. Cc: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511160532.21446-6-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
由 Ville Syrjälä 提交于
Currently HDMI .mode_valid() only checks whether the source can do deep color. Let's check whether the sink can do it as well. Cc: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511160532.21446-5-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
由 Ville Syrjälä 提交于
Let's put the platform checks into intel_hdmi_bpc_possible() so that it'll confirm both the source and sink capabilities. Cc: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511160532.21446-4-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
由 Ville Syrjälä 提交于
We wish intel_hdmi_bpc_possible() to consider whether the sink supports HDMI or just DVI when checking whether it'll support HDMI deep color or not. This also takes care of the "force DVI" property. Cc: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511160532.21446-3-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
由 Ville Syrjälä 提交于
Extract intel_hdmi_bpc_possible() from intel_hdmi_deep_color_possible() so that we can reuse it for mode validation. Cc: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511160532.21446-2-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
- 13 5月, 2021 1 次提交
-
-
由 Clinton Taylor 提交于
Add ADP-P PCH device ID and assign as ADL PCH if found. Previously we would assign the DDC pin map based on the PCH, but it can also change based on the CPU. From Bspec 20124: "The physical port to pin pair mapping are defined in the Bspec per PCH. Mapping can further change based on CPU Si used as CPU and PCH can be mixed and matched". Bspec: 20124 Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: NClinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210512042144.2089071-7-matthew.d.roper@intel.com
-
- 12 5月, 2021 2 次提交
-
-
由 José Roberto de Souza 提交于
This workaround requires that VIDEO_DIP_ENABLE_VSC_HSW is never set with PSR. BSpec: 54369 BSpec: 54077 Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Reviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210418002126.87882-5-jose.souza@intel.com
-
由 José Roberto de Souza 提交于
HSW_TVIDEO_DIP_CTL is read but not used. Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Reviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210418002126.87882-4-jose.souza@intel.com
-
- 11 5月, 2021 3 次提交
-
-
由 Werner Sembach 提交于
When encoder validation of a display mode fails, retry with less bandwidth heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups to support 4k60Hz output, which previously failed silently. AMDGPU had nearly the exact same issue. This problem description is therefore copied from my commit message of the AMDGPU patch. On some setups, while the monitor and the gpu support display modes with pixel clocks of up to 600MHz, the link encoder might not. This prevents YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be possible. However, which color mode is used is decided before the link encoder capabilities are checked. This patch fixes the problem by retrying to find a display mode with YCbCr420 enforced and using it, if it is valid. Signed-off-by: NWerner Sembach <wse@tuxedocomputers.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210510133349.14491-4-wse@tuxedocomputers.com
-
由 Werner Sembach 提交于
Couples the decission between RGB and YCbCr420 mode and the check if the port clock can archive the required frequency. Other checks and configuration steps that where previously done in between can also be done before or after. This allows for are cleaner implementation of retrying different color encodings. A slight change in behaviour occurs with this patch: If YCbCr420 is not allowed but display is YCbCr420 only it no longer fails, but just prints an error and tries to fallback on RGB. Signed-off-by: NWerner Sembach <wse@tuxedocomputers.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210510133349.14491-3-wse@tuxedocomputers.com
-
由 Werner Sembach 提交于
Moves some checks that later will be performed 2 times to an own function. This avoids duplicate code later on. Signed-off-by: NWerner Sembach <wse@tuxedocomputers.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210510133349.14491-2-wse@tuxedocomputers.com
-
- 07 5月, 2021 1 次提交
-
-
由 Maxime Ripard 提交于
All the drivers that implement HDR output call pretty much the same function to initialise the hdr_output_metadata property, and while the creation of that property is in a helper, every driver uses the same code to attach it. Provide a helper for it as well Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Reviewed-by: NJernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210430094451.2145002-1-maxime@cerno.tech
-
- 06 5月, 2021 1 次提交
-
-
由 Ville 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: NAnshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210430143945.6776-1-ville.syrjala@linux.intel.com
-
- 28 4月, 2021 3 次提交
-
-
由 Lyude Paul 提交于
Another function we need to pass drm_device down to in order to start using drm_dbg_*(). Signed-off-by: NLyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210423184309.207645-11-lyude@redhat.comReviewed-by: NDave Airlie <airlied@redhat.com>
-
由 Lyude Paul 提交于
Another function that we'll need to pass a drm_device (and not drm_dp_aux) down to so that we can move over to using drm_dbg_*(). Signed-off-by: NLyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210423184309.207645-10-lyude@redhat.comReviewed-by: NDave Airlie <airlied@redhat.com>
-
由 Lyude Paul 提交于
Since we're about to be using drm_dbg_*() throughout the DP helpers, we'll need to be able to access the DRM device in the dual mode DP helpers as well. Note however that since drm_dp_dual_mode_detect() can be called with DDC adapters that aren't part of a drm_dp_aux struct, we need to pass down the drm_device to these functions instead of using drm_dp_aux. Signed-off-by: NLyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210423184309.207645-9-lyude@redhat.comReviewed-by: NDave Airlie <airlied@redhat.com>
-
- 14 4月, 2021 2 次提交
-
-
由 Lucas 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: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> [Jani: Minor conflict resolve while applying.] Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com
-
由 Matt Roper 提交于
Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the display code, we should also kill off our use of the IS_GEN9_* macros too. We'll do the conversion manually this time instead of using Coccinelle since the most logical substitution can depend heavily on the code context, and sometimes we can keep the code simpler if we make additional adjustments such as swapping the order of if/else arms. v2: - Restore a lost negation in intel_pll_is_valid(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com (cherry picked from commit 70bfb307) [Jani: cherry picked to topic branch to reduce conflicts] Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 08 4月, 2021 1 次提交
-
-
由 Matt Roper 提交于
Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the display code, we should also kill off our use of the IS_GEN9_* macros too. We'll do the conversion manually this time instead of using Coccinelle since the most logical substitution can depend heavily on the code context, and sometimes we can keep the code simpler if we make additional adjustments such as swapping the order of if/else arms. v2: - Restore a lost negation in intel_pll_is_valid(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com
-
- 24 3月, 2021 2 次提交
-
-
由 Matt Roper 提交于
GLK has always been a bit of a special case since it reports INTEL_GEN() as 9, but has version 10 display IP. Now we can properly represent the display version as 10 and simplify the display generation tests throughout the display code. Aside from manually adding the version to the glk_info structure, the rest of this patch is generated with a Coccinelle semantic patch. Note that we also need to switch any code that matches gen10 today but *not* GLK to be CNL-specific: @@ expression dev_priv; @@ - DISPLAY_VER(dev_priv) > 9 + DISPLAY_VER(dev_priv) >= 10 @@ expression dev_priv, E; @@ ( - DISPLAY_VER(dev_priv) >= 10 && E + (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E | - DISPLAY_VER(dev_priv) >= 10 + DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) | - IS_DISPLAY_RANGE(dev_priv, 10, E) + IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv) ) @@ expression dev_priv, E, E2; @@ ( - (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 10) | - E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv) + E || IS_DISPLAY_VER(dev_priv, 10) | - (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 10) | - IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv) + E || IS_DISPLAY_VER(dev_priv, 10) | - E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv) + E || E2 || IS_DISPLAY_VER(dev_priv, 10) | - (IS_DISPLAY_VER(dev_priv, 10) || IS_GEMINILAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 10) | - (IS_GEMINILAKE(dev_priv) || IS_DISPLAY_VER(dev_priv, 10)) + IS_DISPLAY_VER(dev_priv, 10) ) @@ expression dev_priv; @@ - (IS_DISPLAY_VER(dev_priv, 9) && !IS_GEMINILAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 9) @@ expression dev_priv; @@ ( - !(DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) + DISPLAY_VER(dev_priv) < 10 | - (DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) + DISPLAY_VER(dev_priv) >= 10 ) @@ expression dev_priv, E; @@ - E || DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10) + E || DISPLAY_VER(dev_priv) >= 10 @@ expression dev_priv, E; @@ - (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, 10)) + IS_DISPLAY_RANGE(dev_priv, 10, E) @@ expression dev_priv; @@ ( - DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) || IS_GEN9_LP(dev_priv) + DISPLAY_VER(dev_priv) >= 10 || IS_GEN9_LP(dev_priv) | - IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) + IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 10 ) @@ expression dev_priv, E; @@ - !(DISPLAY_VER(dev_priv) >= E) + DISPLAY_VER(dev_priv) < E v2: - Convert gen10 conditions that don't include GLK into CNL conditions. (Ville) v3: - Rework coccinelle rules so that "ver>=10" turns into "ver>=11||is_cnl." (Ville) v3.1: - Manually re-add the ".display.version = 10" to glk_info after regenerating patch via Coccinelle. v4: - Also apply cocci rules to intel_pm.c and i915_irq.c! (CI) Cc: Ville Syrjälä <ville.syrjala@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210322233840.4056851-1-matthew.d.roper@intel.com
-
由 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: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-4-matthew.d.roper@intel.com
-
- 20 3月, 2021 1 次提交
-
-
由 Ville Syrjälä 提交于
Extract the g4x+ HDMI low level code to its own file, leaving intel_hdmi.c to deal with higher level issues. The infoframe support I decided to leave in intel_hdmi.c since I think we need to move that as a whole to its own file. It is after all used also for DP SDPs, so no longer HDMI specific. Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210318161015.22070-7-ville.syrjala@linux.intel.com
-
- 12 2月, 2021 1 次提交
-
-
由 Lyude Paul 提交于
With the introduction of gen9_bc, where Intel combines Cometlake CPUs with a Tigerpoint PCH, we'll need to introduce new DDC pin mappings for this platform in order to make all of the display connectors work. So, let's do that. Changes since v4: * Split this into it's own patch - vsyrjala Changes since v5: * Rename gen9bc_port_to_ddc_pin() to gen9bc_tgp_port_to_ddc_pin() Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> [originally from Tejas's work] Signed-off-by: NTejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by: NLyude Paul <lyude@redhat.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209212832.1401815-3-lyude@redhat.com
-
- 09 2月, 2021 1 次提交
-
-
由 Ville Syrjälä 提交于
The BXT/GLK DPLL can't generate certain frequencies. We already reject the 233-240MHz range on both. But on GLK the DPLL max frequency was bumped from 300MHz to 594MHz, so now we get to also worry about the 446-480MHz range (double the original problem range). Reject any frequency within the higher problematic range as well. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3000Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210203093044.30532-1-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com> (cherry picked from commit 41751b3e) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
- 05 2月, 2021 2 次提交
-
-
由 Ville Syrjälä 提交于
Replace the hand rolled intel_hdmi_port_clock() stuff with the real thing. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210204020846.2094-2-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>
-
由 Ville Syrjälä 提交于
The BXT/GLK DPLL can't generate certain frequencies. We already reject the 233-240MHz range on both. But on GLK the DPLL max frequency was bumped from 300MHz to 594MHz, so now we get to also worry about the 446-480MHz range (double the original problem range). Reject any frequency within the higher problematic range as well. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3000Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210203093044.30532-1-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>
-
- 26 1月, 2021 1 次提交
-
-
由 Aditya Swarup 提交于
ADL-S requires TC pins to set up ddc for Combo PHY B, C, D and E. Combo PHY A still uses the old ddc pin mapping. From VBT, ddc pin info suggests the following mapping: VBT DRIVER DDI B->ddc_pin=2 should translate to PORT_D->0x9 DDI C->ddc_pin=3 should translate to PORT_E->0xa DDI D->ddc_pin=4 should translate to PORT_F->0xb DDI E->ddc_pin=5 should translate to PORT_G->0xc Adding pin map to facilitate this translation as we cannot use existing icl ddc pin map due to conflict with DDI B and DDI C info. Bspec:20124 v2: Replace IS_ALDERLAKE_S() with HAS_PCH_ADP() as the pin map pairing depends on the PCH being used rather than the platform.(mdroper) v3: - Modify adls_port_to_ddc_pin() to make PHY_A the special case for check, else return pin mapping based on correct arithmetic with phy offset. Remove redundant platform checks and use HAS_PCH_ADP() instead of IS_ALDERLAKE_S() in intel_hdmi_ddc_pin().(mdroper) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: NAditya Swarup <aditya.swarup@intel.com> Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210125140753.347998-9-aditya.swarup@intel.com
-
- 13 1月, 2021 3 次提交
-
-
由 Anshuman Gupta 提交于
This requires for HDCP 2.2 MST check link. As for DP/HDMI shims check_2_2_link retrieves the connector from dig_port, this is not sufficient or DP MST connector, there can be multiple DP MST topology connector associated with same dig_port. Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: NUma Shankar <uma.shankar@intel.com> Reviewed-by: NRamalingam C <ramalingam.c@intel.com> Tested-by: NKarthik B S <karthik.b.s@intel.com> Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-16-anshuman.gupta@intel.com
-
由 Anshuman Gupta 提交于
Pass dig_port as an argument to intel_hdcp_init() and intel_hdcp2_init(). This will be required for HDCP 2.2 stream encryption. Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: NUma Shankar <uma.shankar@intel.com> Reviewed-by: NRamalingam C <ramalingam.c@intel.com> Tested-by: NKarthik B S <karthik.b.s@intel.com> Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-11-anshuman.gupta@intel.com
-
由 Anshuman Gupta 提交于
Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP encryption over DP MST Transport Link. HDCP 1.4 stream encryption requires to validate the stream encryption status in HDCP_STATUS_{TRANSCODER,PORT} register driving that link in order to enable/disable the stream encryption. Both of above requirement are same for all Gen with respect to B.Spec Documentation. v2: - Cosmetic changes function name, error msg print and stream typo fixes. [Uma] v3: - uniformity for connector detail in DMESG. [Ram] Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: NUma Shankar <uma.shankar@intel.com> Reviewed-by: NRamalingam C <ramalingam.c@intel.com> Tested-by: NKarthik B S <karthik.b.s@intel.com> Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-8-anshuman.gupta@intel.com
-
- 22 12月, 2020 1 次提交
-
-
由 Ankit Nautiyal 提交于
The DP-HDMI2.1 PCON spec provides way for a source to set PPS parameters: slice height, slice width and bits_per_pixel, based on the HDMI2.1 sink capabilities. The DSC encoder of the PCON will respect these parameters, while preparing the 128 byte PPS. This patch adds helper functions to calculate these PPS paremeters as per the HDMI2.1 specification. v2: Addressed review comments given by Uma Shankar: -added documentation for functions -fixed typos and errors Signed-off-by: NAnkit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: NUma Shankar <uma.shankar@intel.com> [Jani: Fixed checkpatch SUSPECT_CODE_INDENT, TYPO_SPELLING] Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-14-ankit.k.nautiyal@intel.com
-
- 02 12月, 2020 3 次提交
-
-
由 Uma Shankar 提交于
Implement Read back of HDR metadata infoframes i.e Dynamic Range and Mastering Infoframe for LSPCON devices. v2: Added proper bitmask of enabled infoframes as per Ville's recommendation. v3: Dropped a redundant wrapper as per Ville's comment. v4: Dropped a redundant print, added Ville's RB. Signed-off-by: NUma Shankar <uma.shankar@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-14-uma.shankar@intel.com
-
由 Uma Shankar 提交于
Dropped a irrelevant lspcon check from intel_hdmi_add_properties function. Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NUma Shankar <uma.shankar@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-10-uma.shankar@intel.com
-
由 Ville Syrjälä 提交于
With LSPCON we use the AVI infoframe to convey the colorimetry information (as opposed to DP MSA/SDP), so the property we expose should match the values we can stuff into the infoframe. Ie. we must use the HDMI variant of the property, even though we drive LSPCON in PCON mode. To that end just split intel_attach_colorspace_property() into HDMI and DP variants and let the caller worry about which one it wants to use. Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NUma Shankar <uma.shankar@intel.com> Signed-off-by: NUma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-8-uma.shankar@intel.com
-