Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 3月, 2021 1 次提交
  3. 20 1月, 2021 1 次提交
  5. 05 12月, 2020 1 次提交
  7. 19 11月, 2020 3 次提交
  9. 21 10月, 2020 1 次提交
  11. 28 9月, 2020 1 次提交
  13. 21 4月, 2020 1 次提交
  15. 20 3月, 2020 1 次提交
    • V
      drm/i915: Fix crtc nv12 etc. plane bitmasks for DPMS off · cb1824bb
      由 Ville Syrjälä 提交于 
      We only consider crtc_state->enable when initially calculating plane
visibility. Later on we try to override the plane's state to invisible
if the crtc is in DPMS off state (crtc_state->active==false).
Unfortunately the code doing that only updates the plane_state.visible
flag and the crtc_state.active_planes bimask, but forgets to update
some of the other plane bitmasks stored in the crtc_state. Namely
crtc_state.nv12_planes is left set up based on the original visibility
check which makes icl_check_nv12_planes() pick a slave plane for the
flagged plane in the bitmask. Later on we hit the watermark code
which sees a plane with a slave assigned and it then makes the
logical assumption that the master plane must itself be visible.
Since the master's plane_state.visible flag was already cleared
we get a WARN.

Fix the problem by clearing all the plane bitmasks for DPMS off.
This is more or less the wrong approach and instead we should
calculate all the plane related state purely based crtc_state->enable
(to guarantee that the subsequent DPMS on can't fail). However in
the past we definitely had some roadblocks to making that happen.
Not sure how many are left these days, but let's stick to the current
approach since it's a much simpler fix to the immediate problem
(the WARN).

v2: Keep the visible=false, it's important (Rodrigo)

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200318174515.31637-1-ville.syrjala@linux.intel.comReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      cb1824bb
  17. 03 3月, 2020 1 次提交
    • S
      drm/i915: Use intel_plane_data_rate for min_cdclk calculation · 7a9ccdd1
      由 Stanislav Lisovskiy 提交于 
      There seems to be a bit of confusing redundancy in a way, how
plane data rate/min cdclk are calculated.
In fact both min cdclk, pixel rate and plane data rate are all
part of the same formula as per BSpec.

However currently we have intel_plane_data_rate, which is used
to calculate plane data rate and which is also used in bandwidth
calculations. However for calculating min_cdclk we have another
piece of code, doing almost same calculation, but a bit differently
and in a different place. However as both are actually part of same
formula, probably would be wise to use plane data rate calculations
as a basis anyway, thus avoiding code duplication and possible bugs
related to this.

Another thing is that I've noticed that during min_cdclk calculations
we account for plane scaling, while for plane data rate, we don't.
crtc->pixel_rate seems to account only for pipe ratio, however it is
clearly stated in BSpec that plane data rate also need to account
plane ratio as well.

So what this commit does is:
- Adds a plane ratio calculation to intel_plane_data_rate
- Removes redundant calculations from skl_plane_min_cdclk which is
  used for gen9+ and now uses intel_plane_data_rate as a basis from
  there as well.

v2: - Don't use 64 division if not needed(Ville Syrjälä)
    - Now use intel_plane_pixel_rate as a basis for calculations both
      at intel_plane_data_rate and skl_plane_min_cdclk(Ville Syrjälä)

v3: - Again fix the division macro
    - Fix plane_pixel_rate to pixel_rate at intel_plane_pixel_rate
      callsites

v4: - Renamed skl_plane_ratio function back(Ville Syrjälä)

v5: - Don't precalculate plane pixel rate for invisible plane,
      check for visibility first, as in invisible case it will
      have dst_w and dst_h equal to zero, causing divide error.

v6: - Removed useless warn in intel_plane_pixel_rate(Ville Syrjälä)
    - Fixed alignment in intel_plane_data_rate(Ville Syrjälä)
    - Changed pixel_rate type to be unsigned int in
      skl_plane_min_cdclk(Ville Syrjälä)
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227150935.2107-1-stanislav.lisovskiy@intel.com
      7a9ccdd1
  19. 04 2月, 2020 1 次提交
    • C
      drm/i915/display: Fix NULL-crtc deref in calc_min_cdclk() · def85091
      由 Chris Wilson 提交于 
      [   23.419442] BUG: KASAN: null-ptr-deref in intel_plane_calc_min_cdclk+0x82/0x440 [i915]
[   23.419527] Read of size 4 at addr 00000000000000f8 by task insmod/735
[   23.419578]
[   23.419644] CPU: 2 PID: 735 Comm: insmod Not tainted 5.5.0+ #114
[   23.419716] Hardware name: ��������������������������������� ���������������������������������/���������������������������������, BIOS RYBDWi35.86A.0246.2
[   23.419793] Call Trace:
[   23.419864]  dump_stack+0xef/0x16e
[   23.419927]  __kasan_report.cold+0x60/0x90
[   23.420157]  ? intel_plane_calc_min_cdclk+0x82/0x440 [i915]
[   23.420397]  intel_plane_calc_min_cdclk+0x82/0x440 [i915]
[   23.420630]  intel_atomic_check+0x455f/0x65a0 [i915]
[   23.420708]  ? mark_held_locks+0x90/0x90
[   23.420929]  ? intel_crtc_duplicate_state+0x2e/0x1b0 [i915]
[   23.421172]  ? intel_plane_duplicate_state+0x2d/0xc0 [i915]
[   23.421239]  ? __drm_dbg+0xa4/0x120
[   23.421303]  ? __kasan_kmalloc.constprop.0+0xc2/0xd0
[   23.421355]  ? __kmalloc_track_caller+0x23a/0x320
[   23.421602]  ? intel_calc_active_pipes+0x1c0/0x1c0 [i915]
[   23.421852]  sanitize_watermarks+0x220/0x510 [i915]
[   23.422092]  ? intel_atomic_check+0x65a0/0x65a0 [i915]
[   23.422164]  ? drm_modeset_unlock_all+0x88/0x130
[   23.422402]  intel_modeset_init+0x1b76/0x3c90 [i915]
[   23.422647]  ? intel_finish_reset+0x2d0/0x2d0 [i915]
[   23.422851]  ? intel_irq_install+0x12c/0x210 [i915]
[   23.423076]  i915_driver_probe+0x13e7/0x2930 [i915]

v2: No crtc is implied by an invisible plane, so the extra !crtc check
is redundant.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200203133824.198872-1-chris@chris-wilson.co.uk
      def85091
  21. 31 1月, 2020 2 次提交
  23. 23 1月, 2020 2 次提交
  25. 23 12月, 2019 1 次提交
  27. 18 12月, 2019 1 次提交
  29. 01 11月, 2019 7 次提交
  31. 25 10月, 2019 1 次提交
    • V
      drm/i915: Allow planes to declare their minimum acceptable cdclk · bb6ae9e6
      由 Ville Syrjälä 提交于 
      Various pixel formats and plane scaling impose additional constraints
on the cdclk frequency. Provide a new plane->min_cdclk() hook that
will be used to compute the minimum acceptable cdclk frequency for
each plane.

Annoyingly on some platforms the numer of active planes affects
this calculation so we must also toss in more planes into the
state when the number of active planes changes.

The sequence of state computation must also be changed:
1. check_plane() (updates plane's visibility etc.)
2. figure out if more planes now require update min_cdclk
   computaion
3. calculate the new min cdclk for each plane in the state
4. if the minimum of any plane now exceeds the current
   logical cdclk we recompute the cdclk
4. during cdclk computation take the planes' min_cdclk into
   accoutn
5. follow the normal cdclk programming to change the
   cdclk frequency. This may now require a modeset (except
   on bxt/glk in some cases), which either succeeds or
   fails depending on whether userspace has given
   us permission to perform a modeset or not.

v2: Fix plane id check in intel_crtc_add_planes_to_state()
    Only print the debug message when cdclk needs bumping
    Use dev_priv->cdclk... as the old state explicitly
Reviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191015193035.25982-5-ville.syrjala@linux.intel.com
      bb6ae9e6
  33. 15 10月, 2019 1 次提交
  35. 25 9月, 2019 1 次提交
  37. 16 9月, 2019 1 次提交
  39. 07 8月, 2019 2 次提交
  41. 01 7月, 2019 1 次提交
  43. 17 6月, 2019 2 次提交
  45. 28 5月, 2019 1 次提交
    • V
      drm/i915: Make sure we have enough memory bandwidth on ICL · c457d9cf
      由 Ville Syrjälä 提交于 
      ICL has so many planes that it can easily exceed the maximum
effective memory bandwidth of the system. We must therefore check
that we don't exceed that limit.

The algorithm is very magic number heavy and lacks sufficient
explanation for now. We also have no sane way to query the
memory clock and timings, so we must rely on a combination of
raw readout from the memory controller and hardcoded assumptions.
The memory controller values obviously change as the system
jumps between the different SAGV points, so we try to stabilize
it first by disabling SAGV for the duration of the readout.

The utilized bandwidth is tracked via a device wide atomic
private object. That is actually not robust because we can't
afford to enforce strict global ordering between the pipes.
Thus I think I'll need to change this to simply chop up the
available bandwidth between all the active pipes. Each pipe
can then do whatever it wants as long as it doesn't exceed
its budget. That scheme will also require that we assume that
any number of planes could be active at any time.

TODO: make it robust and deal with all the open questions

v2: Sleep longer after disabling SAGV
v3: Poll for the dclk to get raised (seen it take 250ms!)
    If the system has 2133MT/s memory then we pointlessly
    wait one full second :(
v4: Use the new pcode interface to get the qgv points rather
    that using hardcoded numbers
v5: Move the pcode stuff into intel_bw.c (Matt)
    s/intel_sagv_info/intel_qgv_info/
    Do the NV12/P010 as per spec for now (Matt)
    s/IS_ICELAKE/IS_GEN11/
v6: Ignore bandwidth limits if the pcode query fails
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Acked-by: NClint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190524153614.32410-1-ville.syrjala@linux.intel.com
      c457d9cf
  47. 08 4月, 2019 3 次提交
  49. 05 3月, 2019 1 次提交
  51. 16 2月, 2019 1 次提交