History log of /linux-master/drivers/gpu/drm/i915/display/intel_bw.h
Revision Date Author Comments
# a5819e51 05-Jun-2023 Vinod Govindapillai <vinod.govindapillai@intel.com>

drm/i915/mtl: find the best QGV point for the SAGV configuration

From MTL onwards, we need to find the best QGV point based on
the required data rate and pass the peak BW of that point to
the punit to lock the corresponding QGV point.

v1: Fix for warning from kernel test robot

v2: No need to serialize for the peakbw change as pmdemand code
will do that (Imre)

Bspec: 64636

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/r/202305280253.Ab8bRV2w-lkp@intel.com/
Reported-by: Dan Carpenter <error27@gmail.com>
Closes: https://lore.kernel.org/r/202305280253.Ab8bRV2w-lkp@intel.com/
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230606093509.221709-7-vinod.govindapillai@intel.com


# acc855d3 16-Jan-2023 Jani Nikula <jani.nikula@intel.com>

drm/i915/display: add intel_display_limits.h for key enums

Move a handful of key enums to a new file intel_display_limits.h. These
are the enum types, and the MAX/NUM enumerations within them, that are
used in other headers. Otherwise, there's no common theme between them.

Replace intel_display.h include with intel_display_limit.h where
relevant, and add the intel_display.h include directly in the .c files
where needed.

Since intel_display.h is used almost everywhere in display/, include it
from intel_display_types.h to avoid massive changes across the
board. There are very few files that would need intel_display_types.h
but not intel_display.h so this is neglible, and further cleanup between
these headers can be left for the future.

Overall this change drops the direct and indirect dependencies on
intel_display.h from about 300 to about 100 compilation units, because
we can drop the include from i915_drv.h.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230116164644.1752009-1-jani.nikula@intel.com


# ea083969 03-Mar-2022 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Add "maximum pipe read bandwidth" checks

Make sure the CDCLK is high enough to support the so called
"maximum pipe read bandwidth" limitation. Specified as
51.2 x CDCLK.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303191207.27931-10-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>


# 5ac860cc 03-Mar-2022 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Fix DBUF bandwidth vs. cdclk handling

Make the dbuf bandwidth min cdclk calculations match the spec
more closely. Supposedly the arbiter can only guarantee an equal
share of the total bandwidth of the slice to each active plane
on that slice. So we take the max bandwidth of any of the planes
on each slice and multiply that by the number of active planes
on the slice to get a worst case estimate on how much bandwidth
we require.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303191207.27931-9-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>


# 7243867c 03-Mar-2022 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Nuke intel_bw_calc_min_cdclk()

intel_bw_calc_min_cdclk() is entirely pointless. All it manages to do is
somehow conflate the per-pipe min cdclk with dbuf min cdclk. There is no
(at least documented) dbuf min cdclk limit on pre-skl so let's just get
rid of all this confusion.

Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303191207.27931-6-ville.syrjala@linux.intel.com


# c0299cc9 14-Feb-2022 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Widen the QGV point mask

adlp+ adds some extra bits to the QGV point mask. The code attempts
to handle that but forgot to actually make sure we can store those
bits in the bw state. Fix it.

Cc: stable@vger.kernel.org
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: 192fbfb76744 ("drm/i915: Implement PSF GV point support")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220214091811.13725-4-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>


# 3f333648 14-Feb-2022 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Widen the QGV point mask

adlp+ adds some extra bits to the QGV point mask. The code attempts
to handle that but forgot to actually make sure we can store those
bits in the bw state. Fix it.

Cc: stable@vger.kernel.org
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: 192fbfb76744 ("drm/i915: Implement PSF GV point support")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220214091811.13725-4-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
(cherry picked from commit c0299cc9840b3805205173cc77782f317b78ea0e)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>


# cac91e67 22-May-2020 Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

drm/i915: Fix includes and local vars order

Removed duplicate include and fixed comment > 80 chars.

v2: Added newline after system include and between functions

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200522131843.20477-1-stanislav.lisovskiy@intel.com


# cd191546 20-May-2020 Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

drm/i915: Adjust CDCLK accordingly to our DBuf bw needs

According to BSpec max BW per slice is calculated using formula
Max BW = CDCLK * 64. Currently when calculating min CDCLK we
account only per plane requirements, however in order to avoid
FIFO underruns we need to estimate accumulated BW consumed by
all planes(ddb entries basically) residing on that particular
DBuf slice. This will allow us to put CDCLK lower and save power
when we don't need that much bandwidth or gain additional
performance once plane consumption grows.

v2: - Fix long line warning
- Limited new DBuf bw checks to only gens >= 11

v3: - Lets track used Dbuf bw per slice and per crtc in bw state
(or may be in DBuf state in future), that way we don't need
to have all crtcs in state and those only if we detect if
are actually going to change cdclk, just same way as we
do with other stuff, i.e intel_atomic_serialize_global_state
and co. Just as per Ville's paradigm.
- Made dbuf bw calculation procedure look nicer by introducing
for_each_dbuf_slice_in_mask - we often will now need to iterate
slices using mask.
- According to experimental results CDCLK * 64 accounts for
overall bandwidth across all dbufs, not per dbuf.

v4: - Fixed missing const(Ville)
- Removed spurious whitespaces(Ville)
- Fixed local variable init(reduced scope where not needed)
- Added some comments about data rate for planar formats
- Changed struct intel_crtc_bw to intel_dbuf_bw
- Moved dbuf bw calculation to intel_compute_min_cdclk(Ville)

v5: - Removed unneeded macro

v6: - Prevent too frequent CDCLK switching back and forth:
Always switch to higher CDCLK when needed to prevent bandwidth
issues, however don't switch to lower CDCLK earlier than once
in 30 minutes in order to prevent constant modeset blinking.
We could of course not switch back at all, however this is
bad from power consumption point of view.

v7: - Fixed to track cdclk using bw_state, modeset will be now
triggered only when CDCLK change is really needed.

v8: - Lock global state if bw_state->min_cdclk is changed.
- Try getting bw_state only if there are crtcs in the commit
(need to have read-locked global state)

v9: - Do not do Dbuf bw check for gens < 9 - triggers WARN
as ddb_size is 0.

v10: - Lock global state for older gens as well.

v11: - Define new bw_calc_min_cdclk hook, instead of using
a condition(Manasi Navare)

v12: - Fixed rebase conflict

v13: - Added spaces after declarations to make checkpatch happy.

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200520150058.16123-1-stanislav.lisovskiy@intel.com


# 20f505f2 14-May-2020 Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

drm/i915: Restrict qgv points which don't have enough bandwidth.

According to BSpec 53998, we should try to
restrict qgv points, which can't provide
enough bandwidth for desired display configuration.

Currently we are just comparing against all of
those and take minimum(worst case).

v2: Fixed wrong PCode reply mask, removed hardcoded
values.

v3: Forbid simultaneous legacy SAGV PCode requests and
restricting qgv points. Put the actual restriction
to commit function, added serialization(thanks to Ville)
to prevent commit being applied out of order in case of
nonblocking and/or nomodeset commits.

v4:
- Minor code refactoring, fixed few typos(thanks to James Ausmus)
- Change the naming of qgv point
masking/unmasking functions(James Ausmus).
- Simplify the masking/unmasking operation itself,
as we don't need to mask only single point per request(James Ausmus)
- Reject and stick to highest bandwidth point if SAGV
can't be enabled(BSpec)

v5:
- Add new mailbox reply codes, which seems to happen during boot
time for TGL and indicate that QGV setting is not yet available.

v6:
- Increase number of supported QGV points to be in sync with BSpec.

v7: - Rebased and resolved conflict to fix build failure.
- Fix NUM_QGV_POINTS to 8 and moved that to header file(James Ausmus)

v8: - Don't report an error if we can't restrict qgv points, as SAGV
can be disabled by BIOS, which is completely legal. So don't
make CI panic. Instead if we detect that there is only 1 QGV
point accessible just analyze if we can fit the required bandwidth
requirements, but no need in restricting.

v9: - Fix wrong QGV transition if we have 0 planes and no SAGV
simultaneously.

v10: - Fix CDCLK corruption, because of global state getting serialized
without modeset, which caused copying of non-calculated cdclk
to be copied to dev_priv(thanks to Ville for the hint).

v11: - Remove unneeded headers and spaces(Matthew Roper)
- Remove unneeded intel_qgv_info qi struct from bw check and zero
out the needed one(Matthew Roper)
- Changed QGV error message to have more clear meaning(Matthew Roper)
- Use state->modeset_set instead of any_ms(Matthew Roper)
- Moved NUM_SAGV_POINTS from i915_reg.h to i915_drv.h where it's used
- Keep using crtc_state->hw.active instead of .enable(Matthew Roper)
- Moved unrelated changes to other patch(using latency as parameter
for plane wm calculation, moved to SAGV refactoring patch)

v12: - Fix rebase conflict with own temporary SAGV/QGV fix.
- Remove unnecessary mask being zero check when unmasking
qgv points as this is completely legal(Matt Roper)
- Check if we are setting the same mask as already being set
in hardware to prevent error from PCode.
- Fix error message when restricting/unrestricting qgv points
to "mask/unmask" which sounds more accurate(Matt Roper)
- Move sagv status setting to icl_get_bw_info from atomic check
as this should be calculated only once.(Matt Roper)
- Edited comments for the case when we can't enable SAGV and
use only 1 QGV point with highest bandwidth to be more
understandable.(Matt Roper)

v13: - Moved max_data_rate in bw check to closer scope(Ville Syrjälä)
- Changed comment for zero new_mask in qgv points masking function
to better reflect reality(Ville Syrjälä)
- Simplified bit mask operation in qgv points masking function
(Ville Syrjälä)
- Moved intel_qgv_points_mask closer to gen11 SAGV disabling,
however this still can't be under modeset condition(Ville Syrjälä)
- Packed qgv_points_mask as u8 and moved closer to pipe_sagv_mask
(Ville Syrjälä)
- Extracted PCode changes to separate patch.(Ville Syrjälä)
- Now treat num_planes 0 same as 1 to avoid confusion and
returning max_bw as 0, which would prevent choosing QGV
point having max bandwidth in case if SAGV is not allowed,
as per BSpec(Ville Syrjälä)
- Do the actual qgv_points_mask swap in the same place as
all other global state parts like cdclk are swapped.
In the next patch, this all will be moved to bw state as
global state, once new global state patch series from Ville
lands

v14: - Now using global state to serialize access to qgv points
- Added global state locking back, otherwise we seem to read
bw state in a wrong way.

v15: - Added TODO comment for near atomic global state locking in
bw code.

v16: - Fixed intel_atomic_bw_* functions to be intel_bw_* as discussed
with Jani Nikula.
- Take bw_state_changed flag into use.

v17: - Moved qgv point related manipulations next to SAGV code, as
those are semantically related(Ville Syrjälä)
- Renamed those into intel_sagv_(pre)|(post)_plane_update
(Ville Syrjälä)

v18: - Move sagv related calls from commit tail into
intel_sagv_(pre)|(post)_plane_update(Ville Syrjälä)

v19: - Use intel_atomic_get_bw_(old)|(new)_state which is intended
for commit tail stage.

v20: - Return max bandwidth for 0 planes(Ville)
- Constify old_bw_state in bw_atomic_check(Ville)
- Removed some debugs(Ville)
- Added data rate to debug print when no QGV points(Ville)
- Removed some comments(Ville)

v21, v22, v23: - Fixed rebase conflict

v24: - Changed PCode mask to use ICL_ prefix
v25: - Resolved rebase conflict

v26: - Removed redundant NULL checks(Ville)
- Removed redundant error prints(Ville)

v27: - Use device specific drm_err(Ville)
- Fixed parenthesis ident reported by checkpatch
Line over 100 warns to be fixed together with
existing code style.

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Ville Syrjälä <ville.syrjala@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
[vsyrjala: Drop duplicate intel_sagv_{pre,post}_plane_update() prototypes
and drop unused NUM_SAGV_POINTS define]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514074853.9508-3-stanislav.lisovskiy@intel.com


# ecab0f3d 30-Apr-2020 Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

drm/i915: Track active_pipes in bw_state

We need to calculate SAGV mask also in a non-modeset
commit, however currently active_pipes are only calculated
for modesets in global atomic state, thus now we will be
tracking those also in bw_state in order to be able to
properly access global data.

v2: - Removed pre/post plane SAGV updates from modeset(Ville)
- Now tracking active pipes in intel_can_enable_sagv(Ville)

v3: - lock global state if active_pipes change as well(Ville)

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200430195634.7666-1-stanislav.lisovskiy@intel.com


# 9728889f 30-Apr-2020 Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

drm/i915: Use bw state for per crtc SAGV evaluation

Future platforms require per-crtc SAGV evaluation
and serializing global state when those are changed
from different commits.

v2: - Add has_sagv check to intel_crtc_can_enable_sagv
so that it sets bit in reject mask.
- Use bw_state in intel_pre/post_plane_enable_sagv
instead of atomic state

v3: - Fixed rebase conflict, now using
intel_atomic_crtc_state_for_each_plane_state in
order to call it from atomic check
v4: - Use fb modifier from plane state

v5: - Make intel_has_sagv static again(Ville)
- Removed unnecessary NULL assignments(Ville)
- Removed unnecessary SAGV debug(Ville)
- Call intel_compute_sagv_mask only for modesets(Ville)
- Serialize global state only if sagv results change, but
not mask itself(Ville)

v6: - use lock global state instead of serialize(Ville)
v7: - use both global state lock and serialize depending on
if we need to change only global state or access hw
(Ville)

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Ville Syrjälä <ville.syrjala@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200430191757.18206-1-stanislav.lisovskiy@intel.com


# 442e7ee8 15-Apr-2020 Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

drm/i915: Add intel_atomic_get_bw_*_state helpers

Add correspondent helpers to be able to get old/new bandwidth
global state object.

v2: - Fixed typo in function call
v3: - Changed new functions naming to use convention proposed
by Jani Nikula, i.e intel_bw_* in intel_bw.c file.
v4: - Change function naming back to intel_atomic* pattern,
was decided to rename in a separate patch series.
v5: - Fix function naming to match existing practices(Ville)
v6: - Removed spurious whitespace
v7: - Removed bw_state NULL checks(Ville)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200415143911.10244-3-stanislav.lisovskiy@intel.com


# fd1a9bba 20-Jan-2020 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Convert bandwidth state to global state

Now that we have the more formal global state thing let's
use if for memory bandwidth tracking. No real difference
to the current private object usage since we already
tried to avoid taking the single serializing lock needlessly.
But since we're going to roll the global state out to more
things probably a good idea to unify the approaches a bit.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-16-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>


# b42d3b15 09-Dec-2019 Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>

drm/i915/display: cleanup intel_bw_state on i915 module removal

intel_bw_state allocated memory is not getting freed even after
module removal.

kmemleak reported backtrace:

[<0000000079019739>] kmemdup+0x17/0x40
[<00000000d58c1b9d>] intel_bw_duplicate_state+0x1b/0x40 [i915]
[<000000007423ed0c>] drm_atomic_get_private_obj_state+0xca/0x140
[<00000000100e3533>] intel_bw_atomic_check+0x133/0x350 [i915]
[<00000000126d0e0c>] intel_atomic_check+0x1ab7/0x20d0 [i915]
[<00000000d5dfc004>] drm_atomic_check_only+0x563/0x810
[<00000000c9379611>] drm_atomic_commit+0xe/0x50
[<00000000ec82b765>] drm_atomic_helper_disable_all+0x133/0x160
[<000000003c44760c>] drm_atomic_helper_shutdown+0x65/0xc0
[<00000000414e3e5c>] i915_driver_remove+0xcb/0x130 [i915]
[<00000000f8544c2a>] i915_pci_remove+0x19/0x40 [i915]
[<000000002dcbd148>] pci_device_remove+0x36/0xb0
[<000000003c8c6b0a>] device_release_driver_internal+0xe0/0x1c0
[<00000000580e9566>] unbind_store+0xc3/0x120
[<00000000869d0df5>] kernfs_fop_write+0x104/0x190
[<000000004dc1a355>] vfs_write+0xb9/0x1d0

Call the drm_atomic_private_obj_fini(), which inturn calls the
intel_bw_destroy_state() to make sure the intel_bw_state memory is
freed properly.

Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191209143921.9240-1-pankaj.laxminarayan.bharadiya@intel.com


# 366b6200 06-Aug-2019 Jani Nikula <jani.nikula@intel.com>

drm/i915/bw: make intel_atomic_get_bw_state() static

No need for this function to be accessible outside of intel_bw.c. Avoid
including the i915_drv.h mega header from other header files to make
further header cleanup easier.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6c898ec6511af47c1c5b679e516dc757cd207146.1565085691.git.jani.nikula@intel.com


# df0566a6 13-Jun-2019 Jani Nikula <jani.nikula@intel.com>

drm/i915: move modesetting core code under display/

Now that we have a new subdirectory for display code, continue by moving
modesetting core code.

display/intel_frontbuffer.h sticks out like a sore thumb, otherwise this
is, again, a surprisingly clean operation.

v2:
- don't move intel_sideband.[ch] (Ville)
- use tabs for Makefile file lists and sort them

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-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/20190613084416.6794-3-jani.nikula@intel.com