Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 16 11月, 2021 1 次提交
  3. 15 11月, 2021 3 次提交
  5. 12 11月, 2021 2 次提交
  7. 11 11月, 2021 20 次提交
  9. 10 11月, 2021 6 次提交
    • V
      Revert "drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping" · 4579509e
      由 Vandita Kulkarni 提交于 
      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: NVandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211109120428.15211-1-vandita.kulkarni@intel.com
      4579509e
    • D
      drm/i915: pin: delete duplicate check in intel_pin_and_fence_fb_obj() · 6cff894e
      由 Dan Carpenter 提交于 
      The "ret" variable is checked on the previous line so we know it's
zero.  No need to check again.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211109114850.GB16587@kili
      6cff894e
    • V
      drm/i915: Call intel_update_active_dpll() for both bigjoiner pipes · c68dac96
      由 Ville Syrjälä 提交于 
      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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211105212156.5697-1-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>
      c68dac96
    • V
      drm/i915: Use unlocked register accesses for LUT loads · 115e0f68
      由 Ville Syrjälä 提交于 
      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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211020223339.669-5-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>
      115e0f68
    • V
      drm/i915: Use vblank workers for gamma updates · 2bbc6fca
      由 Ville Syrjälä 提交于 
      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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211020223339.669-4-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>
      2bbc6fca
    • V
      drm/i915: Do vrr push before sampling the frame counter · 6f9976bd
      由 Ville Syrjälä 提交于 
      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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211020223339.669-3-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>
      6f9976bd
  11. 09 11月, 2021 2 次提交
  13. 06 11月, 2021 1 次提交
  15. 05 11月, 2021 5 次提交