- 06 9月, 2022 5 次提交
-
-
由 Jani Nikula 提交于
This reverts commit 7ae5ab44. Part of a series where patches were modified while applying to resolve conflicts, leading to further conflicts between drm-misc-next and drm-intel-next, resulting in build failures in drm-tip. To be applied again on a baseline with drm-misc-next and drm-intel-next in sync. Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jani Nikula 提交于
This reverts commit e1a84ba8. Part of a series where patches were modified while applying to resolve conflicts, leading to further conflicts between drm-misc-next and drm-intel-next, resulting in build failures in drm-tip. To be applied again on a baseline with drm-misc-next and drm-intel-next in sync. Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Stanislav Lisovskiy 提交于
Whenever we are not able to get enough timeslots for required PBN, let's try to allocate those using DSC, just same way as we do for SST. v2: Removed intel_dp_mst_dsc_compute_config and refactored intel_dp_dsc_compute_config to support timeslots as a parameter(Ville Syrjälä) v3: - Rebased - Added a debug to see that we at least try reserving VCPI slots using DSC, because currently its not visible from the logs, thus making debugging more tricky. - Moved timeslots to numerator, where it should be. v4: - Call drm_dp_mst_atomic_check already during link config computation, because we need to know already by this moment if uncompressed amount of VCPI slots needed can fit, otherwise we need to use DSC. (thanks to Vinod Govindapillai for pointing this out) v5: - Put pipe_config->bigjoiner_pipes back to original condition in intel_dp_dsc_compute_config (don't remember when I lost it) v6: - Removed unnecessary drm_dp_mst_atomic_check as it is now always called in a newly introduced intel_dp_mst_find_vcpi_slots_for_bpp function (Vinod Govindapillai) Reviewed-by: NVinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220905085744.29637-5-stanislav.lisovskiy@intel.com -
由 Stanislav Lisovskiy 提交于
We would be using almost same code to loop through bpps while calling drm_dp_atomic_find_vcpi_slots - lets remove this duplication by introducing a new function intel_dp_mst_find_vcpi_slots_for_bpp v2: Fix pbn_div calculation - shouldn't matter if its DSC or not. Reviewed-by: NVinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220905085744.29637-4-stanislav.lisovskiy@intel.com
-
由 Stanislav Lisovskiy 提交于
We currently always exit that bpp loop because drm_dp_atomic_find_vcpi_slots doesn't care if we actually can fit those or not. I think that wasn't the initial intention here, especially when we keep trying with lower bpps, we are supposed to keep trying until we actually find some _working_ configuration, which isn't the case here. So added that drm_dp_mst_check here, so that we can make sure that try all the bpps before we fail. Reviewed-by: NVinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220905085744.29637-3-stanislav.lisovskiy@intel.com
-
- 13 7月, 2022 1 次提交
-
-
由 Hangyu Hua 提交于
If drm_connector_init fails, intel_connector_free will be called to take care of proper free. So it is necessary to drop the refcount of port before intel_connector_free. Fixes: 091a4f91 ("drm/i915: Handle drm-layer errors in intel_dp_add_mst_connector") Signed-off-by: NHangyu Hua <hbh25y@gmail.com> Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220624130406.17996-1-jose.souza@intel.comSigned-off-by: NJosé Roberto de Souza <jose.souza@intel.com> (cherry picked from commit cea9ed61) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
- 07 7月, 2022 1 次提交
-
-
由 Hangyu Hua 提交于
If drm_connector_init fails, intel_connector_free will be called to take care of proper free. So it is necessary to drop the refcount of port before intel_connector_free. Fixes: 091a4f91 ("drm/i915: Handle drm-layer errors in intel_dp_add_mst_connector") Signed-off-by: NHangyu Hua <hbh25y@gmail.com> Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220624130406.17996-1-jose.souza@intel.comSigned-off-by: NJosé Roberto de Souza <jose.souza@intel.com> (cherry picked from commit cea9ed61) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
- 28 6月, 2022 1 次提交
-
-
由 Hangyu Hua 提交于
If drm_connector_init fails, intel_connector_free will be called to take care of proper free. So it is necessary to drop the refcount of port before intel_connector_free. Fixes: 091a4f91 ("drm/i915: Handle drm-layer errors in intel_dp_add_mst_connector") Signed-off-by: NHangyu Hua <hbh25y@gmail.com> Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220624130406.17996-1-jose.souza@intel.comSigned-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
- 30 3月, 2022 1 次提交
-
-
由 Jani Nikula 提交于
Reduce duplication. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220330094109.4164326-2-jani.nikula@intel.com
-
- 11 2月, 2022 1 次提交
-
-
由 Jani Nikula 提交于
128b/132b supports using 64 slots starting from 0, while 8b/10b reserves slot 0 for metadata. Commit d6c6a76f ("drm: Update MST First Link Slot Information Based on Encoding Format") added support for updating the topology state accordingly, and commit 41724ea2 ("drm/amd/display: Add DP 2.0 MST DM Support") started using it in the amd driver. This feels more than a little cumbersome, especially updating the information in atomic check. For i915, add the update to MST connector .compute_config hook rather than iterating over all MST managers and connectors in global mode config .atomic_check. Fingers crossed. v3: - Propagate errors from intel_dp_mst_update_slots() (Ville) v2: - Update in .compute_config() not .atomic_check (Ville) Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: NLyude Paul <lyude@redhat.com> 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/20220208152317.3019070-1-jani.nikula@intel.com
-
- 01 2月, 2022 4 次提交
-
-
由 Ville Syrjälä 提交于
Let's do the cpu transcoder M/N setup next to where we program most other cpu transcoder timings/etc. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-9-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
Instead of passing in the whole crtc state let's pass in just the bits of state we need. This will help with the DRRS code which shouldn't really be accessing the atomic state stuff directly as it gets called outside the normal atomic flows. v2: Fix set_m1_n1 vs. set_m2_n2 fumble for i9xx (Jani) Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-7-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
Make things a bit more explicit by splitting intel_cpu_transcoder_set_m_n() into separate variants for M1/N1 vs. M2/N2. Makes the DRRS M/N programming at least more obvious. Note that for the MST and DRRS cases we don't need to call the M2/N2 variant at all since the transcoders that support those do not have the M2/N2 registers. Same could be said for i9xx_crtc_enable() but I want to do a higher level code sharing between that valleyview_crtc_enable() later in which case we do need the M2/N2 variant. This is also why I keep the transcoder_has_m2_n2() in intel_cpu_transcoder_set_m2_n2() so the caller doesn't have necessarily care what the chosen transcoder supports. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-5-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
I want to make a clean split betwen the CPU vs. PCH transcoder programming. To that end eliminate intel_dp_set_m_n() and just call the individual CPU/PCH transcoder functions directly. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
-
- 27 10月, 2021 1 次提交
-
-
由 Ville Syrjälä 提交于
Disabling planes in the middle of the modeset seuqnece does not make sense since userspace can anyway disable planes before the modeset even starts. So when the modeset seuqence starts the set of enabled planes is entirely arbitrary. Trying to sprinkle the plane disabling into the modeset sequence just means more randomness and potential for hard to reproduce bugs. So it makes most sense to just disable all planes first so that the rest of the modeset sequence remains identical regardless of which planes happen to be enabled by userspace at the time. This reverts commit 84030adb. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-3-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
- 26 10月, 2021 1 次提交
-
-
由 Bhawanpreet Lakha 提交于
8b/10b encoding format requires to reserve the first slot for recording metadata. Real data transmission starts from the second slot, with a total of available 63 slots available. In 128b/132b encoding format, metadata is transmitted separately in LLCP packet before MTP. Real data transmission starts from the first slot, with a total of 64 slots available. v2: * Move total/start slots to mst_state, and copy it to mst_mgr in atomic_check v3: * Only keep the slot info on the mst_state * add a start_slot parameter to the payload function, to facilitate non atomic drivers (this is a temporary workaround and should be removed when we are moving out the non atomic driver helpers) v4: *fixed typo and formatting v5: (no functional changes) * Fixed formatting in drm_dp_mst_update_slots() * Reference mst_state instead of mst_state->mgr for debugging info Signed-off-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: NFangzhi Zuo <Jerry.Zuo@amd.com> [v5 nitpicks] Reviewed-by: NLyude Paul <lyude@redhat.com> Signed-off-by: NLyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211025223825.301703-3-lyude@redhat.com
-
- 25 10月, 2021 1 次提交
-
-
由 He Ying 提交于
If we want to return from for_each_intel_connector_iter(), one way is calling drm_connector_list_iter_end() before returning to avoid memleak. The other way is just breaking from the bracket and then returning after the outside drm_connector_list_iter_end(). Obviously, the second way makes code smaller and more clear. Apply it to the function intel_dp_mst_atomic_master_trans_check(). Signed-off-by: NHe Ying <heying24@huawei.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211022022243.138860-1-heying24@huawei.com
-
- 08 10月, 2021 1 次提交
-
-
由 Jani Nikula 提交于
Add a function for checking source MST support. Drop intel_dp->can_mst and use intel_dp->mst_mgr.cbs to indicate the same. It's the single point of truth without additional state variables. In code, "source support" is also self-documenting as opposed to the vague "can mst". 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/20211006101618.22066-1-jani.nikula@intel.com
-
- 20 9月, 2021 1 次提交
-
-
由 Jani Nikula 提交于
There's a new register pair for 128b/132b mode where you need to set the pixel clock in Hz. v2: Fix UHBR rate check, use intel_dp_is_uhbr() helper Bspec: 54128 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/a2902cc188973f022f282f2a77e693afdecefb5a.1631191763.git.jani.nikula@intel.com
-
- 15 9月, 2021 1 次提交
-
-
由 Ville 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: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210913144440.23008-6-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
-
- 24 8月, 2021 1 次提交
-
-
由 Jani Nikula 提交于
The MST code uses actual link rates in the limits struct, while the DP code in general uses indexes to the ->common_rates[] array. Fix the confusion by using actual link rate values everywhere. This is a better abstraction than some obscure index. Rename the struct members while at it to ensure all the places are covered. 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/d70ab7261abacd367d3a6a47102575eb88a55cd4.1629735412.git.jani.nikula@intel.com
-
- 14 8月, 2021 1 次提交
-
-
由 Jani Nikula 提交于
Less is more, fewer lines to wonder about. Cc: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210813115610.20010-1-jani.nikula@intel.com
-
- 28 7月, 2021 1 次提交
-
-
由 José Roberto de Souza 提交于
HDMI and DisplayPort sequences states that audio and PSR should be disabled before planes are disabled. Not following it did not caused any problems up to Alderlake-P but for this platform it causes underruns during the PSR2 disable sequence. Specification don't mention that DRRS should be disabled before planes but it looks safer to switch back to the default refresh rate before following with the rest of the pipe disable sequence. BSpec: 49191 BSpec: 49190 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Reviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210726181559.80855-1-jose.souza@intel.com
-
- 24 7月, 2021 1 次提交
-
-
由 Matt Roper 提交于
A new step has been added to the DP modeset sequences for all platforms with display version 12 and beyond: if enabling DP MST with FEC, we need to set a chicken bit before enabling the transcoder. The chicken bit should be disabled again before disabling the transcoder (which we can do unconditionally since it shouldn't be set anyway in non-MST cases). Bspec: 49190, 54128, 55424 Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210723170618.1477415-1-matthew.d.roper@intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
- 07 7月, 2021 1 次提交
-
-
由 Anshuman Gupta 提交于
Earlier HDCP over MST support was added for TGL Platform. Extending it to all future platfroms. v2: - Remove the platform check and commit log changes. [Jani] Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210705122208.25618-1-anshuman.gupta@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>
-
- 28 5月, 2021 1 次提交
-
-
由 Nikola Cornij 提交于
[why] Link rate in kHz is what is eventually required to calculate the link bandwidth, which makes kHz a more generic unit. This should also make forward-compatibility with new DP standards easier. [how] - Replace 'link rate DPCD code' with 'link rate in kHz' when used with drm_dp_mst_topology_mgr_init() - Add/remove related DPCD code conversion from/to kHz where applicable Signed-off-by: NNikola Cornij <nikola.cornij@amd.com> Acked-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NLyude Paul <lyude@redhat.com> Signed-off-by: NLyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210512210011.8425-2-nikola.cornij@amd.com
-
- 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
-
- 01 5月, 2021 1 次提交
-
-
由 Nikola Cornij 提交于
[why] Previously used value was not safe to provide the correct value, i.e. it could be 0 if not not configured, leading to no MST on this platform. [how] Do not use the value from BIOS, but from the structure populated at encoder initialization time. Fixes: 98025a62 ("drm/dp_mst: Use Extended Base Receiver Capability DPCD space") Signed-off-by: NNikola Cornij <nikola.cornij@amd.com> Reviewed-by: NLyude Paul <lyude@redhat.com> Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com> [fixed open coded drm_dp_link_rate_to_bw_code()] Signed-off-by: NLyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210430214531.24565-2-nikola.cornij@amd.com
-
- 30 4月, 2021 1 次提交
-
-
由 Nikola Cornij 提交于
[why] DP 1.4a spec mandates that if DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is set, Extended Base Receiver Capability DPCD space must be used. Without doing that, the three DPCD values that differ will be wrong, leading to incorrect or limited functionality. MST link rate, for example, could have a lower value. Also, Synaptics quirk wouldn't work out well when Extended DPCD was not read, resulting in no DSC for such hubs. [how] Modify MST topology manager to use the values from Extended DPCD where applicable. To prevent regression on the sources that have a lower maximum link rate capability than MAX_LINK_RATE from Extended DPCD, have the drivers supply maximum lane count and rate at initialization time. This also reverts commit 2dcab875 ("Revert drm/dp_mst: Retrieve extended DPCD caps for topology manager"), brining the change back to the original commit ad44c032 ("drm/dp_mst: Retrieve extended DPCD caps for topology manager"). Signed-off-by: NNikola Cornij <nikola.cornij@amd.com> Reviewed-by: NLyude Paul <lyude@redhat.com> Signed-off-by: NLyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210429221151.22020-2-nikola.cornij@amd.com
-
- 28 4月, 2021 3 次提交
-
-
由 Jani Nikula 提交于
The definitions are in the crtc and dpll files; move the declarations to the corresponding headers. 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/20210427120315.12342-1-jani.nikula@intel.com
-
由 Jani Nikula 提交于
Add separate intel_dp_hdcp.h to go with intel_dp_hdcp.c, and rename the init function intel_dp_hdcp_init() to follow naming where function prefix matches the file name. Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210427114520.4740-1-jani.nikula@intel.com
-
由 Lyude Paul 提交于
Since this is one of the few functions in drm_dp_mst_topology.c that doesn't have any way of getting access to a drm_device, let's pass the drm_dp_mst_topology_mgr down to this function so that it can use drm_dbg_kms(). Signed-off-by: NLyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210423184309.207645-14-lyude@redhat.comReviewed-by: NDave Airlie <airlied@redhat.com>
-
- 14 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 (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 1 次提交
-
-
由 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
-
- 09 3月, 2021 1 次提交
-
-
由 Ville Syrjälä 提交于
Stop assuming intel_ddi_get_config() is all we need from the primary encoder, and instead call it via the .get_config() vfunc. This will allow customized .get_config() for the primary, which I plan to use to handle the differences in the clock readout between various platforms. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210224144214.24803-2-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>
-
- 08 2月, 2021 1 次提交
-
-
由 Dave Airlie 提交于
This moves the code from various places and consolidates it into one new file. v2: - rename skl_program_plane -> skl_program_plane_scaler (Ville) - also move skl_pfit_enable, and consequently make some skl_scaler_* functions static to skl_scaler.c (Ville) Signed-off-by: NDave Airlie <airlied@redhat.com> 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/2fa703ffc7b96a41c392fd5ebbd2e6e4ffb6fb05.1612536383.git.jani.nikula@intel.com
-
- 02 2月, 2021 1 次提交
-
-
由 Imre Deak 提交于
Atm the driver will calculate a wrong MST timeslots/MTP (aka time unit) value for MST streams if the link parameters (link rate or lane count) are limited in a way independent of the sink capabilities (reported by DPCD). One example of such a limitation is when a MUX between the sink and source connects only a limited number of lanes to the display and connects the rest of the lanes to other peripherals (USB). Another issue is that atm MST core calculates the divider based on the backwards compatible DPCD (at address 0x0000) vs. the extended capability info (at address 0x2200). This can result in leaving some part of the MST BW unused (For instance in case of the WD19TB dock). Fix the above two issues by calculating the PBN divider value based on the rate and lane count link parameters that the driver uses for all other computation. Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/2977 Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjala <ville.syrjala@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjala <ville.syrjala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210125173636.1733812-2-imre.deak@intel.com (cherry picked from commit b59c27ca) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 29 1月, 2021 1 次提交
-
-
由 Imre Deak 提交于
Atm the driver will calculate a wrong MST timeslots/MTP (aka time unit) value for MST streams if the link parameters (link rate or lane count) are limited in a way independent of the sink capabilities (reported by DPCD). One example of such a limitation is when a MUX between the sink and source connects only a limited number of lanes to the display and connects the rest of the lanes to other peripherals (USB). Another issue is that atm MST core calculates the divider based on the backwards compatible DPCD (at address 0x0000) vs. the extended capability info (at address 0x2200). This can result in leaving some part of the MST BW unused (For instance in case of the WD19TB dock). Fix the above two issues by calculating the PBN divider value based on the rate and lane count link parameters that the driver uses for all other computation. Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/2977 Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjala <ville.syrjala@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjala <ville.syrjala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210125173636.1733812-2-imre.deak@intel.com
-