aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/exported-sql-viewer.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2021-05-26drm/i915: Drop redundant has_hdmi_sink checkVille Syrjälä1-13/+11
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511160532.21446-7-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-05-26drm/i915: Move the TMDS clock division into intel_hdmi_mode_clock_valid()Ville Syrjälä1-3/+3
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511160532.21446-6-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-05-26drm/i915: Check sink deep color capabilitis during HDMI .mode_valid()Ville Syrjälä1-7/+9
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511160532.21446-5-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-05-26drm/i915: Move platform checks into intel_hdmi_bpc_possible()Ville Syrjälä1-6/+7
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511160532.21446-4-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-05-26drm/i915: Move has_hdmi_sink check into intel_hdmi_bpc_possible()Ville Syrjälä1-3/+6
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511160532.21446-3-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-05-26drm/i915: Extract intel_hdmi_bpc_possible()Ville Syrjälä1-19/+27
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511160532.21446-2-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-05-26drm/i915/display: Remove a redundant function argument from intel_psr_enable_source()Gwan-gyeong Mun1-4/+3
It removes intel_crtc_state from function argument of intel_psr_enable_source() in order to use intel_psr_enable_source() without intel_crtc_state on other psr internal functions. And we can get cpu_trancoder from intel_psr, therefore we don't need to pass intel_crtc_state to this function. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210526000656.3060314-4-matthew.d.roper@intel.com
2021-05-26drm/i915/xelpd: Add VRR guardband for VRR CTLManasi Navare5-20/+53
On XE_LPD, VRR CTL register adds a new VRR Guardband bitfield replacing the pipeline full and deprecating the pipeline override bit. This patch adds this corresponding bitfield in the register defs, crtc state vrr structure and populates this in vrr compute config and vrr enable functions. It also adds the corresponding HW state readout for this field. Bspec: 50508 Cc: Aditya Swarup <aditya.swarup@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Aditya Swarup <aditya.swarup@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210526000656.3060314-3-matthew.d.roper@intel.com
2021-05-26drm/i915/xelpd: Enhanced pipe underrun reportingMatt Roper4-9/+77
XE_LPD brings enhanced underrun recovery: the hardware can somewhat mitigate underruns by using an interpolated replacement pixel (soft underrun) or the previous pixel (hard underrun). Furthermore, underruns can now be caused downstream by the port, even if the pipe itself is operating properly. The interrupt register and PIPE_STATUS register give us extra bits to recognize hard/soft underruns and determine whether the underrun was caused by the port, so we'll use that information to print some more descriptive errors when underruns occur. v2: - Keep ICL's PIPE_STATUS defined separately from the old GMCH pipe status register. (Ville) - Only read/clear the PIPE_STATUS register on platforms with display ver >= 11. (Lucas) v3: - Actually enable+unmask all the new underrun interrupts, clear stale bits out from PIPE_STATUS before enabling the interrupts, report all FIFO underruns errors at once, rename a bunch of stuff to unconfuse vs. PIPESTAT. (Ville) Bspec: 50335 Bspec: 50366 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210526000656.3060314-2-matthew.d.roper@intel.com
2021-05-26drm/i915/adl_p: enable MSO on pipe BJani Nikula1-2/+5
On ADL-P, it's possible to enable the stream splitter on pipe B in addition to pipe A. Bspec: 50174 Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.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/20210526082903.26395-1-jani.nikula@intel.com
2021-05-26drm/i915: Remove the repeated declarationShaokun Zhang1-2/+0
Function 'intel_dbuf_init' is declared twice, remove the repeated declaration. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1621927793-44545-1-git-send-email-zhangshaokun@hisilicon.com
2021-05-25drm/i915/display/adl_p: Disable PSR2José Roberto de Souza1-0/+9
We are missing the implementation of some workarounds to enabled PSR2 in Alderlake P, so to avoid any CI report of issues around PSR2 disabling it until all PSR2 workarounds are implemented. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210524214805.259692-5-jose.souza@intel.com
2021-05-25drm/i915/display/adl_p: Allow DC3CO in pipe and port BJosé Roberto de Souza1-4/+16
DC3CO is allowed in all the combinations between pipe and port A and B on alderlake-P. BSpec: 49196 Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210524214805.259692-4-jose.souza@intel.com
2021-05-25drm/i915: WA for zero memory channelJosé Roberto de Souza1-1/+1
Commit c457d9cf256e ("drm/i915: Make sure we have enough memory bandwidth on ICL") assumes that we always have a non-zero dram_info->channels and uses it as a divisor. We need num memory channels to be at least 1 for sane bw limits checking, even when PCode returns 0 or there is a error reading it, so lets force it to 1 in this case. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210524214805.259692-3-jose.souza@intel.com
2021-05-25drm/i915/adl_p: Handle TC coldJosé Roberto de Souza3-8/+14
On ADL-P TC cold is exited and blocked when legacy aux is powered, that is exacly the same of what ICL need for static TC ports. TODO: When a TBT hub or monitor is connected it will cause TBT and legacy aux to be powered at the same time, hopefully this will not cause any issues but if it do, some rework will be needed. v2: - skip icl_tc_port_assert_ref_held() warn on, adl-p uses aux to block TC cold v3: - Drop icl_tc_port_assert_ref_held() earlier return for adl_p, not needed anymore - Set timeout_expected when enabling aux power well as port could be disconnected when tc_cold_block() is called BSpec: 55480 Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210524214805.259692-2-jose.souza@intel.com
2021-05-25drm/i915/display/adl_p: Drop earlier return in tc_has_modular_fia()José Roberto de Souza1-4/+2
MODULAR_FIA_MASK is set in adl_p so we can drop this ealier return and read registers. Also to avoid warnings from icl_tc_port_assert_ref_held() when calling tc_cold_block() in this functions it is necessary to held the lock. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210524214805.259692-1-jose.souza@intel.com
2021-05-25drm/i915/debugfs: Print remap info for DPT VMAs as wellImre Deak2-3/+19
Similarly to GGTT VMAs, DPT VMAs can be also a remapped or rotated view of the mapped object, so make sure we debug print the details for these views as well besides the normal view. While at it also fix the debug print for the VMA type of DPT VMAs. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210524172703.2113058-3-imre.deak@intel.com
2021-05-25drm/i915/adlp: Fix GEM VM asserts for DPT VMsImre Deak3-3/+4
An object mapped via DPT can have remapped and rotated VMA instances besides the normal VMA instance, similarly to GGTT VMA instances. Adjust the corresponding VMA lookup asserts. While at it also check if a DPT VM is passed incorrectly to i915_vm_to_ppgtt(). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210524172703.2113058-2-imre.deak@intel.com
2021-05-25drm/i915/adlp: Require DPT FB CCS color planes to be 2MB alignedImre Deak1-2/+11
All DPT FB color plane surface base addresses must be 2MB aligned. On ADL_P this means that the offsets in CCS FB object must be also 2MB aligned. Adjusting unaligned offsets for these FBs during commit time (compensating with the x/y offsets) doesn't work, since the big alignment would most probably lead to an x/y offset mismatch error between the main and CCS planes. We can overcome this limitation by remapping CCS FBs, so that each color plane is at an aligned offset, leaving x/y for each plane unadjusted during commit and so not causing an x/y mismatch error. However remapping for CCS FBs will be done as a follow-up, so for now require that user space allocates the FB obj with properly aligned planes. v2: s/SZ_2M/512*4k/ for clarity. (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210524172703.2113058-1-imre.deak@intel.com
2021-05-24drm/i915/display: fix typo when returning tableLucas De Marchi1-1/+1
Fix table returned when port_clock > 270000: drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c:752:47: error: variable 'adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration] Initial version of the patch had it in a single table, but on second version the table got split, but we continued to reference just one of them. Fixes: ca962882268a ("drm/i915/adl_p: Define and use ADL-P specific DP translation tables") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210521005209.4058702-1-lucas.demarchi@intel.com
2021-05-24drm/i915/gvt: Add missing macro name changesAnusha Srivatsa1-4/+4
Propogate changes to macros name containing CSR_* to DMC_* from display side. Fixes: 0633cdcbaa77 ("drm/i915/dmc: Rename macro names containing csr") Cc: intel-gvt-dev@lists.freedesktop.org Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210521174047.3861-1-anusha.srivatsa@intel.com
2021-05-21drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4Imre Deak1-38/+33
The driver currently disables the LTTPR non-transparent link training mode for sinks with a DPCD_REV<1.4, based on the following description of the LTTPR DPCD register range in DP standard 2.0 (at the 0xF0000 register description): "" LTTPR-related registers at DPCD Addresses F0000h through F02FFh are valid only for DPCD r1.4 (or higher). """ The transparent link training mode should still work fine, however the implementation for this in some retimer FWs seems to be broken, see the References: link below. After discussions with DP standard authors the above "DPCD r1.4" does not refer to the DPCD revision (stored in the DPCD_REV reg at 0x00000), rather to the "LTTPR field data structure revision" stored in the 0xF0000 reg. An update request has been filed at vesa.org (see wg/Link/documentComment/3746) for the upcoming v2.1 specification to clarify the above description along the following lines: """ LTTPR-related registers at DPCD Addresses F0000h through F02FFh are valid only for LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV 1.4 (or higher) """ Based on my tests Windows uses the non-transparent link training mode for DPCD_REV==1.2 sinks as well (so presumably for all DPCD_REVs), and forcing it to use transparent mode on ICL/TGL platforms leads to the same LT failure as reported at the References: link. Based on the above let's assume that the transparent link training mode is not well tested/supported and align the code to the correct interpretation of what the r1.4 version refers to. Reported-and-tested-by: Casey Harkins <caseyharkins@gmail.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3415 Fixes: 264613b406eb ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4") Cc: <stable@vger.kernel.org> # v5.11+ Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210512212809.1234701-1-imre.deak@intel.com
2021-05-19drm/i915/adl_p: Update memory bandwidth parametersAnusha Srivatsa1-1/+1
ADL_P has same memory characteristics as ADL_S platform. Bspec: 64631 Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-18-lucas.demarchi@intel.com
2021-05-19drm/i915/adlp: Add PIPE_MISC2 programmingAnusha Srivatsa2-0/+28
When scalers are enabled, we need to program underrun bubble counter to 0x50 to avoid Soft Pipe A underruns. Make sure other bits dont get overwritten. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-17-lucas.demarchi@intel.com
2021-05-19drm/i915/adl_p: Program DP/HDMI link rate to DDI_BUF_CTLImre Deak2-3/+34
On ADL_P besides programming the PLL accordingly the DP/HDMI link rate should be also programmed to the DDI_BUF_CTL register, do that. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-16-lucas.demarchi@intel.com
2021-05-19drm/i915/adl_p: Add PLL SupportAnusha Srivatsa2-17/+60
The clocks in ALD_P is similar to that of TGL. The combo PLLs use the same DPLL0, DPLL1 and TBT_PLL. This patch adds the helper function intel_mg_pll_enable_reg() which is similar to intel_combo_pll_enable_reg() for being lookup place for PLL_ENABLE register in combo phy cases. Bspec: 55409,55316 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-15-lucas.demarchi@intel.com
2021-05-19drm/i915/adl_p: Define and use ADL-P specific DP translation tablesMika Kahola3-1/+63
Define and use DP voltage swing and pre-emphasis translation tables for ADL-P. v2: - Update according to recent bspec updates; there are now separate tables for RBR/HBR and HBR2/HBR3. (Anusha) BSpec: 54956 Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-14-lucas.demarchi@intel.com
2021-05-19drm/i915/display: Add PSR interrupt error check functionGwan-gyeong Mun1-18/+29
In order to reuse code of PSR interrupt error check on other PSR functions, it adds psr_interrupt_error_check() function. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-13-lucas.demarchi@intel.com
2021-05-19drm/i915/display: Replace dc3co_enabled with dc3co_exitline on intel_psr structGwan-gyeong Mun2-6/+6
It replaces dc3co_enabled with dc3co_exitline on intel_psr struct. And it saves dc3co_exitline, not dc3co_enabled, so we can use dc3co_exitline without intel_crtc_state on other psr internal function like as intel_psr_enable_source(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-12-lucas.demarchi@intel.com
2021-05-19drm/i915/adl_p: Tx escape clock with DSIMika Kahola2-2/+25
Today when the DSI controller is paired with the Combo-PHY it uses the high-speed (HS) Word clock for its low power (LP) transmit PPI communication to the DPHY. The interface signaling only changes state at an Escape clock frequency (i.e. its effectively running on a virtual Tx Escape clock that is controlled by counters w/in the controller), but all the interface flops are running off the HS clock. This has the following drawbacks: * It is a deviation from the PPI spec which assumes signaling is running on a physical Escape clock * The PV timings are over constrained (HS timed to 312.5MHz vs. an Escape clock of 20MHz max) This feature is proposing to change the LP Tx communication between the controller and the DPHY from a virtual Tx Escape clock to a physical clock. To do this we need to program two "M" divisors. One for the usual DSI_ESC_CLK_DIV and DPHY_ESC_CLK_DIV register and one for MIPIO_DWORD8. For DSI_ESC_CLK_DIV and DPHY_ESC_CLK_DIV registers the "M" is calculated as following Nt = ceil(f_link/160) (theoretical word clock) Nact = max[3, Nt + (Nt + 1)%2] (actual word clock) M = Nact * 8 For MIPIO_DWORD8 register, the divisor "M" is calculated as following M = (Nact - 1)/2 BSpec: 55171 Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-11-lucas.demarchi@intel.com
2021-05-19drm/i915/adl_p: MBUS programmingVandita Kulkarni6-9/+120
Update MBUS_CTL register if the 2 mbus can be joined as per the current DDB allocation and active pipes, also update hashing mode and pipe select bits as per the sequence mentioned in the bspec. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-10-lucas.demarchi@intel.com
2021-05-19drm/i915: Introduce MBUS relative dbuf offsetsVille Syrjälä1-6/+34
The dbuf slices are going to be split across several MBUS units. The actual dbuf programming will use offsets relative to the MBUS unit. To accommodate that we shall store the MBUS relative offsets into the dbuf_state->ddb[] and crtc_state->plane_ddb*[]. For crtc_state->wm.skl.ddb however we want to stick to global offsets as we use this to sanity check that the ddb allocations don't overlap between pipes. Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-9-lucas.demarchi@intel.com
2021-05-19drm/i915/adl_p: Add ddb allocation supportVandita Kulkarni2-5/+138
On adlp the two mbuses have two display pipes and two DBUFS, Pipe A and D on Mbus1 and Pipe B and C on Mbus2. The Mbus can be joined and all the DBUFS can be used on Pipe A or B. Bspec: 49255 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-8-lucas.demarchi@intel.com
2021-05-19drm/i915/adl_p: Don't config MBUS and DBUF during display initializationJosé Roberto de Souza1-0/+6
Alderlake-P don't have programing sequences for MBUS or DBUF during display initializaiton, instead it requires programing to those registers during modeset because it to depend on the pipes left enabled. Bspec: 49213 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-7-lucas.demarchi@intel.com
2021-05-19drm/i915/adl_p: Implement TC sequencesJosé Roberto de Souza3-11/+137
ADL-P have basically the same TC connection and disconnection sequences as ICL and TGL, the major difference is the new registers. So here adding functions without the icl prefix in the name and making the new functions call the platform specific function to access the correct register. v2: - Retain DDI TC PHY ownership flag during modesetting. BSpec: 55480 Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-6-lucas.demarchi@intel.com
2021-05-19drm/i915/adl_p: Setup ports/physAnusha Srivatsa1-2/+11
The SoC has 6 DDI ports(DDI A,DDI B and DDI TC1-4. The first two are connected to combo phys while the rest are connected to TC phys. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-5-lucas.demarchi@intel.com
2021-05-19drm/i915/adl_p: Add dedicated SAGV watermarksMatt Roper4-21/+126
XE_LPD reduces the number of regular watermark latency levels from 8 to 6 on non-dgfx platforms. However the hardware also adds a special purpose SAGV wateramrk (and an accompanying transition watermark) that will be used by the hardware in place of the level 0 values during SAGV transitions. Bspec: 49325, 49326, 50419 Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-4-lucas.demarchi@intel.com
2021-05-19drm/i915/xelpd: Add rc_qp_table for rcparams calculationVandita Kulkarni4-1/+333
Add the qp table for 444 formats, for 8bpc, 10bpc and 12bpc, as given by the VESA C model for DSC 1.1 v2: - Add include guard to header (Jani) - Move the big tables to a .c file (Chris, Jani, Lucas) v3: - Make tables 'static const' and add lookup functions to index into them. (Jani) v3.1: - Include missing .h file. Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-3-lucas.demarchi@intel.com
2021-05-19drm/i915/xelpd: Calculate VDSC RC parametersVandita Kulkarni1-10/+87
Add methods to calculate rc parameters for all bpps, against the fixed arrays that we already have for 8,10,12 valid o/p bpps, to cover RGB 444 formats. Our hw doesn't support YUV compression yet. The calculations used here are from VESA C model for DSC 1.1 v2: - Checkpatch fixes Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Juha-Pekka Heikkil <juha-pekka.heikkila@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Mohammed Khajapasha <mohammed.khajapasha@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519000625.3184321-2-lucas.demarchi@intel.com
2021-05-19drm/amdgpu: stop touching sched.ready in the backendChristian König4-16/+1
This unfortunately comes up in regular intervals and breaks GPU reset for the engine in question. The sched.ready flag controls if an engine can't get working during hw_init, but should never be set to false during hw_fini. v2: squash in unused variable fix (Alex) Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-19drm/amd/amdgpu: fix a potential deadlock in gpu resetLang Yu1-1/+0
When amdgpu_ib_ring_tests failed, the reset logic called amdgpu_device_ip_suspend twice, then deadlock occurred. Deadlock log: [ 805.655192] amdgpu 0000:04:00.0: amdgpu: ib ring test failed (-110). [ 806.290952] [drm] free PSP TMR buffer [ 806.319406] ============================================ [ 806.320315] WARNING: possible recursive locking detected [ 806.321225] 5.11.0-custom #1 Tainted: G W OEL [ 806.322135] -------------------------------------------- [ 806.323043] cat/2593 is trying to acquire lock: [ 806.323825] ffff888136b1cdc8 (&adev->dm.dc_lock){+.+.}-{3:3}, at: dm_suspend+0xb8/0x1d0 [amdgpu] [ 806.325668] but task is already holding lock: [ 806.326664] ffff888136b1cdc8 (&adev->dm.dc_lock){+.+.}-{3:3}, at: dm_suspend+0xb8/0x1d0 [amdgpu] [ 806.328430] other info that might help us debug this: [ 806.329539] Possible unsafe locking scenario: [ 806.330549] CPU0 [ 806.330983] ---- [ 806.331416] lock(&adev->dm.dc_lock); [ 806.332086] lock(&adev->dm.dc_lock); [ 806.332738] *** DEADLOCK *** [ 806.333747] May be due to missing lock nesting notation [ 806.334899] 3 locks held by cat/2593: [ 806.335537] #0: ffff888100d3f1b8 (&attr->mutex){+.+.}-{3:3}, at: simple_attr_read+0x4e/0x110 [ 806.337009] #1: ffff888136b1fd78 (&adev->reset_sem){++++}-{3:3}, at: amdgpu_device_lock_adev+0x42/0x94 [amdgpu] [ 806.339018] #2: ffff888136b1cdc8 (&adev->dm.dc_lock){+.+.}-{3:3}, at: dm_suspend+0xb8/0x1d0 [amdgpu] [ 806.340869] stack backtrace: [ 806.341621] CPU: 6 PID: 2593 Comm: cat Tainted: G W OEL 5.11.0-custom #1 [ 806.342921] Hardware name: AMD Celadon-CZN/Celadon-CZN, BIOS WLD0C23N_Weekly_20_12_2 12/23/2020 [ 806.344413] Call Trace: [ 806.344849] dump_stack+0x93/0xbd [ 806.345435] __lock_acquire.cold+0x18a/0x2cf [ 806.346179] lock_acquire+0xca/0x390 [ 806.346807] ? dm_suspend+0xb8/0x1d0 [amdgpu] [ 806.347813] __mutex_lock+0x9b/0x930 [ 806.348454] ? dm_suspend+0xb8/0x1d0 [amdgpu] [ 806.349434] ? amdgpu_device_indirect_rreg+0x58/0x70 [amdgpu] [ 806.350581] ? _raw_spin_unlock_irqrestore+0x47/0x50 [ 806.351437] ? dm_suspend+0xb8/0x1d0 [amdgpu] [ 806.352437] ? rcu_read_lock_sched_held+0x4f/0x80 [ 806.353252] ? rcu_read_lock_sched_held+0x4f/0x80 [ 806.354064] mutex_lock_nested+0x1b/0x20 [ 806.354747] ? mutex_lock_nested+0x1b/0x20 [ 806.355457] dm_suspend+0xb8/0x1d0 [amdgpu] [ 806.356427] ? soc15_common_set_clockgating_state+0x17d/0x19 [amdgpu] [ 806.357736] amdgpu_device_ip_suspend_phase1+0x78/0xd0 [amdgpu] [ 806.360394] amdgpu_device_ip_suspend+0x21/0x70 [amdgpu] [ 806.362926] amdgpu_device_pre_asic_reset+0xb3/0x270 [amdgpu] [ 806.365560] amdgpu_device_gpu_recover.cold+0x679/0x8eb [amdgpu] Signed-off-by: Lang Yu <Lang.Yu@amd.com> Acked-by: Christian KÃnig <christian.koenig@amd.com> Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-19drm/amdgpu: modify system reference clock source for navi+ (V2)Aaron Liu1-0/+15
Starting from Navi+, the rlc reference clock is used for system clock from vbios gfx_info table. It is incorrect to use core_refclk_10khz of vbios smu_info table as system clock. Signed-off-by: Aaron Liu <aaron.liu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-19drm/amdgpu: update sdma golden setting for Navi12Guchun Chen1-0/+4
Current golden setting is out of date. Signed-off-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-19drm/amdgpu: update gc golden setting for Navi12Guchun Chen1-2/+4
Current golden setting is out of date. Signed-off-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-19drm/amdgpu: Fix a use-after-freexinhui pan1-0/+1
looks like we forget to set ttm->sg to NULL. Hit panic below [ 1235.844104] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 1235.989074] Call Trace: [ 1235.991751] sg_free_table+0x17/0x20 [ 1235.995667] amdgpu_ttm_backend_unbind.cold+0x4d/0xf7 [amdgpu] [ 1236.002288] amdgpu_ttm_backend_destroy+0x29/0x130 [amdgpu] [ 1236.008464] ttm_tt_destroy+0x1e/0x30 [ttm] [ 1236.013066] ttm_bo_cleanup_memtype_use+0x51/0xa0 [ttm] [ 1236.018783] ttm_bo_release+0x262/0xa50 [ttm] [ 1236.023547] ttm_bo_put+0x82/0xd0 [ttm] [ 1236.027766] amdgpu_bo_unref+0x26/0x50 [amdgpu] [ 1236.032809] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7aa/0xd90 [amdgpu] [ 1236.040400] kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu] [ 1236.046912] kfd_ioctl+0x463/0x690 [amdgpu] Signed-off-by: xinhui pan <xinhui.pan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-19drm/amdgpu/display: restore the backlight on modeset (v2)Alex Deucher1-0/+6
To stay consistent with the user's setting. v2: rebase on multi-eDP support Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1337 Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-19drm/amdgpu/display: add helper functions to get/set backlight (v2)Alex Deucher2-11/+38
And cache the value. These can be used by the backlight callbacks and modesetting functions. v2: rebase on latest backlight changes. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1337 Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-19drm/amdgpu: Query correct register for DF hashing on AldebaranMukul Joshi2-4/+8
For Aldebaran, driver needs to query DramMegaBaseAddress to check if DF hashing is enabled. Signed-off-by: Mukul Joshi <mukul.joshi@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-19drm/amdgpu: add video_codecs query support for aldebaranJames Zhu1-0/+1
Add video_codecs query support for aldebaran. Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-19drm/amdkfd: fix a resource leakage issueDennis Li1-0/+2
The function kfd_lookup_process_by_pasid will increase the reference count of kfd_process object, its caller should call kfd_unref_process to decrease the reference count. Otherwise resource leakage will happen. Signed-off-by: Dennis Li <Dennis.Li@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>