- 29 Sep, 2021 34 commits
-
-
Imre Deak authored
For the ADL-P TBT mode the spec doesn't require blocking TC-cold by using the legacy AUX power domain. To avoid the timeouts that this would cause during PHY disconnect/reconnect sequences (which will be more frequent after a follow-up change) use the TC_COLD_OFF power domain in TBT mode on all platforms. On TGL this power domain blocks TC-cold via a PUNIT command, while on other platforms the domain just takes a runtime PM reference. If the HPD live status indicates that the port mode needs to be reset - for instance after switching from TBT to a DP-alt sink - still take the AUX domain, since the IOM firmware handshake requires this. v2: Rebased on v2 of the previous patch. Cc: José Roberto de Souza <jose.souza@intel.com> 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/20210929132833.2253961-5-imre.deak@intel.com
-
Imre Deak authored
A follow-up change will select the TC-cold blocking power domain based on the TypeC mode, prepare for that here. Also bring intel_tc_cold_requires_aux_pw() earlier to its logical place for readability. No functional change. v2: Add code comment about IOM reg accesses in TCCOLD. (Jose) Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
A follow-up change will start to disconnect/re-connect PHYs around AUX transfers and modeset enable/disables. To prepare for that add a new TypeC PHY disconnected mode, to help tracking the TC-cold blocking power domain status (no power domain in disconnected state, mode dependent power domain in connected state). v2: Move the !disconnected mode and phy-owned asserts in __intel_tc_port_lock() later in the patchset, when the asserts will hold. (Jose) Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: -
Imre Deak authored
A follow-up patch will disconnect/reconnect PHYs around AUX transfers and modeset enable/disables. To prepare for that and make things consistent for all TypeC modes stop connecting the PHY in legacy mode without a sink being connected. This was done before since in legacy mode the PHY is dedicated to display usage, so there was no point in disconnecting it. However after the follow-up changes the TC-cold blocking power domains will be held as long as the PHY is in the connected state, so we'll need to disconnect/re-connect the PHY in all TypeC modes to allow for power saving. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
Instead of directly accessing the TypeC port internal struct members, add/use helpers to retrieve the corresponding properties. No functional change. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
On ADL-P the PHY ready/complete flag is always set even in TBT-alt mode. To avoid taking the PHY ownership and the following spurious "PHY sudden disconnect" messages on this platform when connecting the PHY in TBT mode, check if there is any DP-alt or legacy sink connected before taking the ownership. v2: (Jose) - Fix debug message clarifying that a TBT sink can be connected. - Add comments describing the PHY complete HW flag semantic differences between adl-p and other platforms. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
Waiting for the PHY complete flag to clear when releasing the PHY ownership was add in commit ddec3627 ("drm/i915: Wait for TypeC PHY complete flag to clear in safe mode") This isn't required by the spec, the vague idea was to make the handshake with the firmware more robust, without actual evidence for when it would be needed. Checking this again, the flag doesn't clear on ICL until after the PHY's PLL is disabled and the flag is permanently set on ADL-P. To avoid the spurious timeout messages in dmesg, just remove this wait. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
On ADL-P the PHY ready (aka status complete on other platforms) flag is always set, besides when a DP-alt, legacy sink is connected also when a TBT sink is connected or nothing is connected. So assume the PHY to be connected when both the TBT live status and PHY ready flags are set. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
Atm during driver loading and system resume TypeC ports are accessed before their HW/SW state is synced. Move the TypeC port sanitization to the encoder's sync_state hook to fix this. v2: Handle the encoder disabled case in gen11_dsi_sync_state() as well (Jose, Jani) Fixes: f9e76a6e ("drm/i915: Add an encoder hook to sanitize its state during init/resume") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: -
Tejas Upadhyay authored
Display underrun in HDR mode when cursor is enabled. RTL fix will be implemented CLKGATE_DIS_PSL_A bit 28-46520h. As per W/A 1604331009, Disable cursor clock gating in HDR mode. Bspec : 33451 Changes since V6: - Address checkpatch warnings - Bit ordering Changes since V5: - replace intel_de_read with intel_de_rmw - Jani Changes since V4: - Added WA needed check - Ville - Replace BIT with REG_BIT - Ville - Add WA enable/disable support back which was added in V1 - Ville Changes since V3: - Disable WA when not in HDR mode or cursor plane not active - Ville - Extract required args from crtc_state - Ville - Create HDR mode API using bdw_set_pipemisc ref - Ville - Tested with HDR video as well full setmode, WA applies and disables Changes since V2: - Made it general gen11 WA - Removed WA needed check - Added cursor plane active check - Once WA enable, software will not disable Changes since V1: - Modified way CLKGATE_DIS_PSL bit 28 was modified Reviewed-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210929052442.2543054-1-tejaskumarx.surendrakumar.upadhyay@intel.com
-
Dave Airlie authored
Use a nop table for the cases where CxSR doesn't init properly. v2: use a nop table (Jani) Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Dave Airlie authored
I used a macro to avoid making any really silly mistakes here. Reviewed-by:
-
Dave Airlie authored
Make nice clear tables instead of having things in two places. Reviewed-by:
-
Dave Airlie authored
There was some excess comments and an unused vtbl ptr. Reviewed-by:
-
Dave Airlie authored
This is a bit of a twisty one since each platform is slightly different, so might take some more review care. Reviewed-by:
-
Dave Airlie authored
Most the dpll vtable into read-only memory. Reviewed-by:
-
Dave Airlie authored
Move the functions into read-only tables. Reviewed-by:
-
Dave Airlie authored
This clarifies quite well what functions get used on what platforms instead of having to decipher the old tree. v2: fixed IVB mistake (Jani) Reviewed-by:
-
Dave Airlie authored
Use a macro to avoid mistakes, this type of macro is only used in a couple of places. Reviewed-by:
-
Dave Airlie authored
Put the vtable into ro memory. Reviewed-by:
-
Dave Airlie authored
this single function might be possible to merge later, but for now it's simple to just split it out. Reviewed-by:
-
Dave Airlie authored
It may make sense to merge this with display again later, however the fdi use of the vtable is limited to only a few generations. Reviewed-by:
-
Dave Airlie authored
This provide a service from irq to display, so make it separate Reviewed-by:
-
Dave Airlie authored
This moves all the cdclk related functions into their own vtable. Reviewed-by:
-
Dave Airlie authored
These are only used internally in the audio code Reviewed-by:
-
Dave Airlie authored
These are only used internally in the color module Reviewed-by:
-
Dave Airlie authored
These are the watermark api between display and pm. Reviewed-by:
-
Dave Airlie authored
This function is only used inside intel_pm.c Reviewed-by:
-
Dave Airlie authored
This wraps the fdi link training vfunc to make it clearer. Suggested by Jani. Reviewed-by:
-
Dave Airlie authored
This adds wrappers around all the vtable callers so they are in one place. Suggested by Jani. Reviewed-by:
-
Dave Airlie authored
This moves one wrapper from the pm->display side, and creates wrappers for all the others, this should simplify things later. One thing to note is that the code checks the existence of some of these ptrs, so the wrappers are a bit complicated by that. Suggested by Jani. v2: fixup warnings in wrong place error. v3 by Jani: fix intel_compute_global_watermarks() return value check Reviewed-by:
-
Dave Airlie authored
The crtc was never being used here. Reviewed-by:
-
Dave Airlie authored
The i845_update_wm code was always calling the i845 variant, and the i9xx_update_wm had only a choice between i830 and i9xx paths, hardly worth the vfunc overhead. Reviewed-by:
-
Dave Airlie authored
constify it while here. drop the put function since it was never overloaded and always has done the same thing, no point in indirecting it for show. Reviewed-by:
-
- 28 Sep, 2021 1 commit
-
-
Vandita Kulkarni authored
The right parameter that selects second dsc engine is dsc_split. Hence use dsc_split instead of slice_count while selecting the cdclk in order to accommodate 1ppc limitaion of vdsc. Fixes: fe01883f ("drm/i915: Get proper min cdclk if vDSC enabled") Suggested-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210915054338.29869-1-vandita.kulkarni@intel.com
-
- 27 Sep, 2021 1 commit
-
-
Kai-Heng Feng authored
Commit 989634fb ("drm/i915/audio: set HDA link parameters in driver") makes HDMI audio on Lenovo P350 disappear. So in addition to TGL, extend the logic to RKL to use BIOS provided value to fix the regression. Fixes: 989634fb ("drm/i915/audio: set HDA link parameters in driver") Reviewed-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
- 24 Sep, 2021 4 commits
-
-
Ville Syrjälä authored
On FBC1 we can specify an arbitrary cfb stride. The hw will simply throw away any compressed line that would exceed the specified limit and keep using the uncompressed data instead. Thus we can allow arbitrary compression limits. The one thing we have to keep in mind though is that the cfb stride is specified in units of 32B (gen2) or 64B (gen3+). Fortunately X-tile is already 128B (gen2) or 512B (gen3+) wide so as long as we limit outselves to the same 4x compression limit that FBC2 has we are guaranteed to have a sufficiently aligned cfb stride. Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
There's some kind of weird corner cases in FBC which requires FBC segments to be separated by at least one extra cacheline. Make sure that is present. v2: Respin to fit in with skl_fbc_min_cfb_stride() v3: Make it build Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> #v1 Signed-off-by:
-
Ville Syrjälä authored
Apply the same 512 byte FBC segment alignment to glk+ as we use on skl+. The only real difference is that we now have a dedicated register for the FBC override stride. Not 100% sure which platforms really need the 512B alignment, but it's easiest to just do it on everything. Also the hardware no longer seems to misclaculate the CFB stride for linear, so we can omit the use of the override stride for linear unless the stride is misaligned. Reviewed-by:
-
Ville Syrjälä authored
The code to calculate the cfb stride/size is a bit of mess. The cfb size is getting calculated based purely on the plane stride and plane height. That doesn't account for extra alignment we want for the cfb stride. The gen9 override stride OTOH is just calculated based on the plane width, and it does try to make things more aligned but any extra alignment added there is not considered in the cfb size calculations. So not at all convinced this is working as intended. Additionally the compression limit handling is split between the cfb allocation code and g4x_dpfc_ctl_limit() (for the 16bpp case), which is just confusing. Let's streamline the whole thing: - Start with the plane stride, convert that into cfb stride (cfb is always 4 bytes per pixel). All the calculations will assume 1:1 compression limit since that will give us the max values, and we don't yet know how much stolen memory we will be able to allocate - Align the cfb stride to 512 bytes on modern platforms. This guarantees the 4 line segment will be 512 byte aligned regardles of the final compression limit we choose later. The 512 byte alignment for the segment is required by at least some of the platforms, and just doing it always seems like the easiest option - Figure out if we need to use the override stride or not. For X-tiled it's never needed since the plane stride is already 512 byte aligned, for Y-tiled it will be needed if the plane stride is not a multiple of 512 bytes, and for linear it's apparently always needed because the hardware miscalculates the cfb stride as PLANE_STRIDE*512 instead of the PLANE_STRIDE*64 that it use with linear. - The cfb size will be calculated based on the aligned cfb stride to guarantee we actually reserved enough stolen memory and the FBC hw won't end up scribbling over whatever else is allocated in stolen - The compression limit handling we just do fully in the cfb allocation code to make things less confusing v2: Write the min cfb segment stride calculation in a more explicit way to make it clear what is going on v3: Remeber to update fbc->limit when changing to 16bpp Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v2 Signed-off-by:
-
