- 15 Nov, 2021 1 commit
-
-
Vandita Kulkarni authored
v2: Fix the typo, move out the hardcoding from macro(Jani, Ville) Fixes: f87c46c4 ("drm/i915/dsi/xelpd: Add WA to program LP to HS wakeup guardband") Signed-off-by:Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211019151435.20477-2-vandita.kulkarni@intel.com
-
- 12 Nov, 2021 1 commit
-
-
Colin Ian King authored
Don't populate the read-only array states on the stack but instead it static. Also makes the object code smaller. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
- 11 Nov, 2021 21 commits
-
-
José Roberto de Souza authored
When a plane with a multiplanar format is added to the state by drm_atomic_add_affected_planes(), only the UV plane is added, so a intel_atomic_get_new_plane_state() call to get the Y plane state can return a null pointer. To fix this, intel_atomic_get_plane_state() should be called and the return needs to be checked for errors, as it could return a EAGAIN as other atomic state could be holding the lock for the Y plane. Other issue with the patch being fixed is that the Y plane is not being committed to hardware because the corresponded plane bit is not set in update_planes when UV and Y planes are added to the state by drm_atomic_add_affected_planes(). Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Fixes: 3809991f ("drm/i915/display: Add initial selective fetch support for biplanar formats") Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211108213807.39865-1-jose.souza@intel.com
-
Ville Syrjälä authored
With multiple fbc instances we need to find the right one for each plane. Rather than going looking for the right instance every time let's just replace the has_fbc boolean with a pointer that gets us there straight away. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-18-ville.syrjala@linux.intel.comAcked-by:
Mika Kahola <mika.kahola@intel.com>
-
Ville Syrjälä authored
In preparation for multiple FBC instances start passing around intel_fbc pointers rather than i915 pointers. And once there are multiple of these we can't rely on container_of() to get back to the i915, so we toss in a fbc->i915 pointer already. Signed-off-by:
-
Ville Syrjälä authored
Rename 'dev_priv' to 'i915' to match modern style. Signed-off-by:
-
Ville Syrjälä authored
In the case of FBC_LLC_READ_CTRL the "FBC" stands for frame buffer _caching_, not frame buffer compression. Move the register definition out from the middle of the frame buffer compression register definitions. Let's just stick it somewhere with similar looking register offsets. And while at it switch it over to REG_BIT(). Signed-off-by:
-
Ville Syrjälä authored
Switch all the FBC1 registers over to REG_BTT()/etc. And while at it add a few more registers/bits that escaped the net previously. Signed-off-by:
-
Ville Syrjälä authored
The FBC register defines are a mess: - namespace changes between DPFC_, FBC_, and some platform specific prefix at a whim - ilk+ reuses most g4x bits but still has some separate bit defines elsewhere - it's not clear from the defines that the bit defines are shared So let's clean it up: - both g4x and ilk register share the same defines now - only defines which conflict have a _PLATFORM suffix, everyone else just gets comments to indicate which platforms do what - namespace is consistent DPFC_ now - SNB system agent fence registers also get a consistent namespace - REG_BIT() & co. for everything Signed-off-by:
-
Ville Syrjälä authored
Just use a same mask for ivb/hsw as for bdw+. The extra bit in the bdw mask is mbz on ivb/hsw anyway so this is just pointless complexity. Signed-off-by:
-
Ville Syrjälä authored
Pull the direct FBC register frobbing out from the debugfs code into the fbc code. Also add a vfunc for this so we don't need extra platforms checks. Signed-off-by:
-
Ville Syrjälä authored
Eliminate the last if-ladder by pulling the CFB/LLB programming into a vfunc as well. Signed-off-by:
-
Ville Syrjälä authored
"gen7" in display code is not really sensible. We shall call these things "ivb". Signed-off-by:
-
Ville Syrjälä authored
Eliminate yet another if-ladder by adding .nuke() vfunc. We also rename all *_recompress() stuff to *_nuke() since that's the terminology the spec uses. Also "recompress" is a bit confusing by perhaps implying that this triggers an immediate recompression. Depending on the hardware that may definitely not be the case, and in general we don't specifically know when the hardware decides to compress. So all we do is "nuke" the current compressed framebuffer and leave it up to the hardware to recompress later if it so chooses. Signed-off-by:
-
Ville Syrjälä authored
Replace the "if-ladders everywhere" approach with vfuncs. Signed-off-by:
-
Ville Syrjälä authored
Declutter the *_fbc_activate() functions by pulling all the control register value computations into helpers. I left the enable bit in *_fbc_activate() in the hopes of maybe using the helpers in the *_fbc_deactivate() paths as well instead of the current rmw approach. That won't be possible at least quite yet since we clobber the fbc->params before deactivating FBC so we could end up changing some of the values live, which given FBC's lack of/poor double buffering would likely not go so well. Signed-off-by:
-
Ville Syrjälä authored
Move the direct FBC status register reads from the debugfs code behind an abstract api. Signed-off-by:
-
Ville Syrjälä authored
No need to tiptoe around programming DPFC_FENCE_YOFF with params->fence_y_offset vs. 0. If the fence is not enabled it doesn't even matter what we program here. Signed-off-by:
-
Ville Syrjälä authored
Declutter gen7_fbc_activate() by sucking the override stride programming stuff into helpers. Signed-off-by:
-
Ville Syrjälä authored
We have two identical copies of the snb+ system agent CPU fence programming code. Extract into a helper. Also there's no real point in insisting that we program 0 into DPFC_CPU_FENCE_OFFSET when the fence is disabled. So just always stick the computed Y offset there whether or not the fence is actually used or not. Signed-off-by:
-
William Tseng authored
In Video Mode, if DSI transcoder is set to transmit packets in LP Escape mode, screen flickering would be obseved when brightness commands are continuously and quickly transmitted to a panel. The problem may be resolved by changing the mode to transmit packets from Low Power to HS. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Lee Shawn C <shawn.c.lee@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Signed-off-by:
William Tseng <william.tseng@intel.com> Signed-off-by:
-
Ankit Nautiyal authored
Currently we reset the whole PCON linkConfig DPCD to set the TMDS mode. This also resets the Source control bit and HDMI link enable bit and goes to autonomous mode of operation, which is seen to spoil the PCONs internal state. This patch avoids resetting the PCON link config register and sets only the source control bit, with FRL Enable bit set to 0 (TMDS mode) in the configuration DPCD. It then enables the HDMI Link Enable bit. v2: Removed the redundant resetting of the bits as the buffer is already initialized to 0. (Uma) Updated comments and commit message. v3: Rebase Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Ankit Nautiyal authored
Currently the HDMI2.1 PCON's frl link config DPCD registers are reset and configured even if they are already configured. Also the HDMI Link Mode does not settle to FRL MODE immediately after HDMI Link Status is active. This patch: -Checks if the PCON is already configured for FRL. -Include HDMI Link Mode in wait for loop along with HDMI Link status DPCD. v2: Rebase Signed-off-by:
-
- 10 Nov, 2021 1 commit
-
-
Vandita Kulkarni authored
This reverts commit 991d9557 ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping"). The Bspec was updated recently with the pll ungate sequence similar to that of icl dsi enable sequence. Hence reverting. Bspec: 49187 Fixes: 991d9557 ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping") Cc: <stable@vger.kernel.org> # v5.4+ Signed-off-by:
-
- 09 Nov, 2021 6 commits
-
-
Dan Carpenter authored
The "ret" variable is checked on the previous line so we know it's zero. No need to check again. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Currently we're only calling intel_update_active_dpll() for the bigjoiner master pipe but not for the slave. With TC ports this leads to the two pipes end up trying to use different PLLs (TC vs. TBT). What's worse we're enabling the PLL that didn't get intel_update_active_dpll() called on it at the spot where we need the clocks turned on. So we turn on the wrong PLL and the DDI is now trying to source its clock from the other PLL which is still disabled. Naturally that doesn't end so well and the DDI fails to start up. The state checker also gets a bit unhappy (which is a good thing) when it notices that one of the pipes was using the wrong PLL. Let's fix this by remembering to call intel_update_active_dpll() for both pipes. That should get the correct PLL turned on when we need it, and the state checker should also be happy. Cc: Imre Deak <imre.deak@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4434 Fixes: e12d6218 ("drm/i915: Reduce bigjoiner special casing") Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
We have to bash in a lot of registers to load the higher precision LUT modes. The locking overhead is significant, especially as we have to get this done as quickly as possible during vblank. So let's switch to unlocked accesses for these. Fortunately the LUT registers are mostly spread around such that two pipes do not have any registers on the same cacheline. So as long as commits on the same pipe are serialized (which they are) we should get away with this without angering the hardware. The only exceptions are the PREC_PIPEGCMAX registers on ilk/snb which we don't use atm as they are only used in the 12bit gamma mode. If/when we add support for that we may need to remember to still serialize those registers, though I'm not sure ilk/snb are actually affected by the same cacheline issue. I think ivb/hsw at least were, but they use a different set of registers for the precision LUT. I have a test case which is updating the LUTs on two pipes from a single atomic commit. Running that in a loop for a minute I get the following worst case with the locks in place: intel_crtc_vblank_work_start: pipe B, frame=10037, scanline=1081 intel_crtc_vblank_work_start: pipe A, frame=12274, scanline=769 intel_crtc_vblank_work_end: pipe A, frame=12274, scanline=58 intel_crtc_vblank_work_end: pipe B, frame=10037, scanline=74 And here's the worst case with the locks removed: intel_crtc_vblank_work_start: pipe B, frame=5869, scanline=1081 intel_crtc_vblank_work_start: pipe A, frame=7616, scanline=769 intel_crtc_vblank_work_end: pipe B, frame=5869, scanline=1096 intel_crtc_vblank_work_end: pipe A, frame=7616, scanline=777 The test was done on a snb using the 10bit 1024 entry LUT mode. The vtotals for the two displays are 793 and 1125. So we can see that with the locks ripped out the LUT updates are pretty nicely confined within the vblank, whereas with the locks in place we're routinely blasting past the vblank end which causes visual artifacts near the top of the screen. Signed-off-by:
-
Ville Syrjälä authored
The pipe gamma registers are single buffered so they should only be updated during the vblank to avoid screen tearing. In fact they really should only be updated between start of vblank and frame start because that is the only time the pipe is guaranteed to be empty. Already at frame start the pipe begins to fill up with data for the next frame. Unfortunately frame start happens ~1 scanline after the start of vblank which in practice doesn't always leave us enough time to finish the gamma update in time (gamma LUTs can be several KiB of data we have to bash into the registers). However we must try our best and so we'll add a vblank work for each pipe from where we can do the gamma update. Additionally we could consider pushing frame start forward to the max of ~4 scanlines after start of vblank. But not sure that's exactly a validated configuration. As it stands the ~100 first pixels tend to make it through with the old gamma values. Even though the vblank worker is running on a high prority thread we still have to contend with C-states. If the CPU happens be in a deep C-state when the vblank interrupt arrives even the irq handler gets delayed massively (I've observed dozens of scanlines worth of latency). To avoid that problem we'll use the qos mechanism to keep the CPU awake while the vblank work is scheduled. With all this hooked up we can finally enjoy near atomic gamma updates. It even works across several pipes from the same atomic commit which previously was a total fail because we did the gamma updates for each pipe serially after waiting for all pipes to have latched the double buffered registers. In the future the DSB should take over this responsibility which will hopefully avoid some of these issues. Kudos to Lyude for finishing the actual vblank workers. Works like the proverbial train toilet. v2: Add missing intel_atomic_state fwd declaration v3: Clean up properly when not scheduling the worker v4: Clean up the rest and add tracepoints v5: s/intel_wait_for_vblank_works/intel_wait_for_vblank_workers/ (Jani,Uma) CC: Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Ville Syrjälä authored
Do the vrr push before we sample the frame counter to know when the commit has been latched. Doing these in the wrong order could lead us to complete the flip before it has actually happened. Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
William Tseng authored
Avoid setting LP_DATA_TRANSFER when enable_lpdt is false Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Lee Shawn C <shawn.c.lee@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Signed-off-by:
-
- 08 Nov, 2021 1 commit
-
-
Radhakrishna Sripada authored
The earlier update to BW formulae broke ADL-P. Include display 13 to use TGL path for BW parameters. Fixes: c64a9a7c ("drm/i915: Update memory bandwidth formulae") Cc: Matt Roper <matthew.d.roper@intel.com> Reported-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by:
Caz Yokoyama <caz.yokoyama@intel.com> Reviewed-by:
-
- 05 Nov, 2021 6 commits
-
-
José Roberto de Souza authored
It was also defeatured for ADL-P and other platforms. BSpec: 55424 Signed-off-by:
-
Jani Nikula authored
Follow the filename based prefix naming. Reviewed-by:
-
Jani Nikula authored
It's all internal to intel_audio.c. Cc: Dave Airlie <airlied@redhat.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Jani Nikula authored
Add a standalone definition of struct intel_audio_private, and note that all of it is private to intel_audio.c. v2: Rebase Cc: Dave Airlie <airlied@redhat.com> Reviewed-by:
-
Jani Nikula authored
Add name to the audio sub-struct in drm_i915_private, and remove the tautologies and other inconsistencies in the member names. v2: Call the mutex member mutex, not lock. (Ville) Cc: Dave Airlie <airlied@redhat.com> Reviewed-by:
-
Jani Nikula authored
With an anonymous struct, this can be pure hierarchical organization without code changes. We'll follow up with adding a name to the sub-struct separately. Cc: Dave Airlie <airlied@redhat.com> Reviewed-by:
-
- 04 Nov, 2021 3 commits
-
-
Radhakrishna Sripada authored
The formulae has been updated to include more variables. Make sure the code carries the same. Bspec: 64631, 54023 v2: Make GEN11 follow the default route and fix calculation of maxdebw(RK) v3: Fix div by zero on default case Correct indent for fallthrough(Jani) v4: Fix div by zero on gen11. v5: Fix 0 max_numchannels case v6: - Split gen11/gen12 algorithms - Fix RKL deburst value - Fix difference b/ween ICL and TGL algorithms - Protect deinterleave from being 0 - Warn when numchannels exceeds max_numchannels - Fix scaling of clk_max from different units - s/deinterleave/channelwidth/ in calculating peakbw - Fix off by one for num_planes TGL+ - Fix SAGV check v7: Fix div by zero error on gen11 v8: Even though the algorithm for gen11 says that we need to return derated bw for a qgv point whose planes are less than no of active planes, we return 0 for deratedbw when only one plane is allowed. We modify the algorithm to accommodate the case where no of active planes are same as the min no of planes supported by a qgv point. v9: Fix dclk scaling for dg1 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by:Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Chop vlv_sprite_update() into two halves. Fist half becomes the _noarm() variant, second part the _arm() variant. Fortunately I have already previously grouped the register writes into roughtly the correct order, so the split looks surprisingly clean. Looks like most of the hardware logic was copied from the pre-ctg sprite C, so SPSTRIDE/POS/SIZE are armed by SPSURF, while the rest are self arming. SPCONSTALPHA is the one entirely new register that didn't exist in the old sprite C, and looks like that one is self arming. The CHV pipe B CSC is also self arming, like the rest of the CHV pipe B additions. I didn't have time to capture i915_update_info numbers for these, but since all the other platforms generally showed improvements, and crucially no regression, I am fairly confident this should behave similarly. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
Chop ivb_sprite_update() into two halves. Fist half becomes the _noarm() variant, second part the _arm() variant. Fortunately I have already previously grouped the register writes into roughtly the correct order, so the split looks surprisingly clean. Didn't bother with i915_update_info numbers for this one. I expect the results to be pretty much identical to the snb numbers from the corresponding g4x+ sprite modification. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
