Each gt contains an independent instance of pcode. Extend pcode functions
to interface with pcode on different gt's. To avoid creating dependency of
display functionality on intel_gt, pcode function interfaces are exposed in
terms of uncore rather than intel_gt. Callers have been converted to pass
in the appropritate (i915 or intel_gt) uncore to the pcode functions.

v2: Expose pcode functions in terms of uncore rather than gt (Jani/Rodrigo)
v3: Retain previous function names to eliminate needless #defines (Rodrigo)
v4: Move out i915_pcode_init() to a separate patch (Tvrtko)
    Remove duplicated drm_err/drm_dbg from intel_pcode_init() (Tvrtko)

Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NAshutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NAndi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220519085732.1276255-2-tvrtko.ursulin@linux.intel.com
[tursulin: fixup merge conflict]

In configurations with single DRAM channel, for usecases like
4K 60 Hz, FIFO underruns are observed quite frequently. Looks
like the wm0 watermark values need to bumped up because the wm0
memory latency calculations are probably not taking the DRAM
channel's impact into account.

As per the Bspec 49325, if the ddb allocation can hold at least
one plane_blocks_per_line we should have selected method2.
Assuming that modern HW versions have enough dbuf to hold
at least one line, set the wm blocks to equivalent to blocks
per line.

v2: styling and comments changes (Ville)
v3: Updated the reviewed-by tag
v4: max_t to max and patch styling (Ville)

References: https://gitlab.freedesktop.org/drm/intel/-/issues/4321
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NVinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-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/20220417093105.729014-1-vinod.govindapillai@intel.com

Accessing the DDI_BUF_CTL register without the port's DDI clock being
enabled (to set/clear the TypeC PHY ownership for the port) can lead to
a corrupted value read during any i915 register access right after the
DDI clock is enabled.

The root cause is the way clock synchronization works for this register,
controlled by the CHICKEN_DCPR_1 DDI_CLOCK_REG_ACCESS flag. Correctly
this flag should be cleared on ADLP (see the Bspec link below), however
after bootup the flag is set.

One easily reproducible issue is an unclaimed register access of the
PWR_WELL_CTL_DDI2 register, programmed right after DDI clock enabling to
enable the port's DDI_IO power well (see the HSDES, VLK links below).
With the correct setting above this problem can't be reproduced.

Bspec: 49189
HSDES: 18019028154
VLK: 28328, 28655

Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Arthur J Runyan <arthur.j.runyan@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Acked-by: NArthur J Runyan <arthur.j.runyan@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323201749.288566-1-imre.deak@intel.com

This will make easy to extend MBUS joining support to future platforms
that also supports this feature.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220331184152.1086943-1-jose.souza@intel.com

PIPE_MBUS_DBOX_CTL was only being programmed when a pipe is being
enabled but that could potentially cause issues as it could have
mismatching values while pipes are being enabled.

So here moving the PIPE_MBUS_DBOX_CTL programming of all pipes to be
executed before the function that enables all pipes, leaving all pipes
with a matching A_CREDIT value.

While at it, also moving it to intel_pm.c as we are trying to reduce
the gigantic size of intel_display.c and intel_pm.c have other MBUS
programing sequences.

v2:
- do not program PIPE_MBUS_DBOX_CTL if pipe will not be active or
when it do not needs modeset
- remove the checks to wait a vblank

v3:
- checking if dbuf state is present in state before using it

v4:
- removing redundant checks
- calling intel_atomic_get_new_dbuf_state instead of
intel_atomic_get_dbuf_state

BSpec: 49213
BSpec: 50343
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220330155724.255226-3-jose.souza@intel.com

There's really no need to maintain these total[] arrays to
track the size of each plane's ddb allocation. We just stick
the results straight into the crtc_state ddb tracking structures.

The main annoyance with all this is the mismatch between
wm_uv vs. ddb_y on pre-icl. If only the hw was consistent in
what it considers the primary source of information we could
avoid some of the uglyness. But since that is not the case
we need a bit of special casing for planar formats.

v2: Keep the ddb entry zeroed when the plane is disabled
Reviewed-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/20220303191207.27931-5-ville.syrjala@linux.intel.com

Handle the plane relative data rate in exactly the same
way as we already handle the real data rate. Ie. pre-calculate
it during intel_plane_atomic_check_with_state(), and assign/clear
it for the Y plane as needed. This should guarantee that the
tracking is 100% consistent, and makes me have to think less
when the same apporach is used by both types of data rate.

We might even want to consider replacing the relative
data rate with the real data rate entirely, but it's not
clear if that will produce less optimal plane ddb
allocations. So for now lets keep using the current approach.

v2: Rebase due to async flip wm optimization
Reviewed-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/20220303191207.27931-4-ville.syrjala@linux.intel.com

Let's store the plane allocation in a manner which more closely
matches how the hw operates. That is, we store the packed/CbCr
ddb in one struct, and the Y ddb in another. Currently we're
storing packed/Y in one struct, CbCr in the other.

This also works pretty well for icl+ where the UV plane is
the main plane and the Y plane is subservient to it. Although
in this case we do not even use ddb_y as we do the ddb allocation
in terms of hw planes.

v2: Rebase
Reviewed-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/20220303191207.27931-2-ville.syrjala@linux.intel.com

For modern platforms the spec explicitly states that a
SAGV block time of zero means that SAGV is not supported.
Let's extend that to all platforms. Supposedly there should
be no systems where this isn't true, and it'll allow us to:
- use the same code regardless of older vs. newer platform
- wm latencies already treat 0 as disabled, so this fits well
  with other related code
- make it a bit more clear when SAGV is used vs. not
- avoid overflows from adding U32_MAX with a u16 wm0 latency value
  which could cause us to miscalculate the SAGV watermarks on tgl+

Cc: stable@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-2-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
(cherry picked from commit d8f5855b)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

Give the pre-icl SAGV control functions a skl_ prefix instead
of the intel_ prefix to make it a bit more clear that they
are not some kind of universal things that can be called on
any platform. Also make the functions void since we never
use the return value anyway.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-6-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

If the mailbox returns an exceesively large SAGV block time let's just
reject it. This avoids having to worry about overflows when we add the
SAGV block time to the wm0 latency.

We shall put the limit arbitrarily at U16_MAX. >65msec latency
doesn't really make sense to me in any case.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-5-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

Instead of leaving the SAGV enable/disable to the first commit
let's try to disable it first thing to see if we can do it or
not (disabling SAGV is a safe thing to at any time). This avoids
running the code in this funny intermediate state where we don't
know if SAGV is available or not.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-4-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

I'd like to see the SAGV block time we got from the mailbox
in the logs regardless of whether other factors prevent the
use of SAGV.

So let's adjust the code to always query the SAGV block time,
log it, and then reset it if SAGV is not actually supported.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-3-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

For modern platforms the spec explicitly states that a
SAGV block time of zero means that SAGV is not supported.
Let's extend that to all platforms. Supposedly there should
be no systems where this isn't true, and it'll allow us to:
- use the same code regardless of older vs. newer platform
- wm latencies already treat 0 as disabled, so this fits well
  with other related code
- make it a bit more clear when SAGV is used vs. not
- avoid overflows from adding U32_MAX with a u16 wm0 latency value
  which could cause us to miscalculate the SAGV watermarks on tgl+

Cc: stable@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-2-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

GLK doesn't support SAGV, so with CNL gone there is no
use for having a DISPLAY_VER==10 SAGV block time in the code.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220308173230.4182-2-ville.syrjala@linux.intel.comReviewed-by: NVinod Govindapillai <vinod.govindapillai@intel.com>

data_rate==0 no longer means a plane is disabled, it could
also mean we want to use the minimum ddb allocation for it.
Hence we can't bail out early during ddb allocation or
else we'll simply forget to allocate any ddb for such planes.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: 6a4d8cc6 ("drm/i915: Don't allocate extra ddb during async flip for DG2")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220214105532.13049-2-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
(cherry picked from commit 6475e106)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

data_rate==0 no longer means a plane is disabled, it could
also mean we want to use the minimum ddb allocation for it.
Hence we can't bail out early during ddb allocation or
else we'll simply forget to allocate any ddb for such planes.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: 6a4d8cc6 ("drm/i915: Don't allocate extra ddb during async flip for DG2")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220214105532.13049-2-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

Remove the local enableddisabled() implementation and adopt the
str_enabled_disabled() from linux/string_helpers.h.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220225234631.3725943-3-lucas.demarchi@intel.com

Remove the local yesno() implementation and adopt the str_yes_no() from
linux/string_helpers.h.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220225234631.3725943-1-lucas.demarchi@intel.com

Use REG_FIELD_{PREP,GET} for completeness, and to avoid bitwise
operations with different sizes.

v2: Also use REG_FIELD_GET in skl_wm_level_from_reg_val() (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223103517.634229-1-jani.nikula@intel.com

Tile4 in bspec format is 4K tile organized into
64B subtiles with same basic shape as for legacy TileY
which will be supported by Display13.

v2: - Moved Tile4 associating struct for modifier/display to
      the beginning(Imre Deak)
    - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
      checks(Imre Deak)
    - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
      (Imre Deak)

v3: - Rebased patch on top of new changes related to plane_caps.
    - Added static assert to check that PLANE_CTL_TILING_YF
      matches PLANE_CTL_TILING_4(Nanley Chery)
    - Fixed naming and layout description for Tile 4 in drm uapi
      header(Nanley Chery)

v4: - Extracted drm_fourcc changes to separate patch(Nanley Chery)
Reviewed-by: NImre Deak <imre.deak@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJuha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220118115544.15116-3-stanislav.lisovskiy@intel.com

When changing between SAGV vs. no SAGV on tgl+ we have to
update the use_sagv_wm flag for all the crtcs or else
an active pipe not already in the state will end up using
the wrong watermarks. That is especially bad when we end up
with the tighter non-SAGV watermarks with SAGV enabled.
Usually ends up in underruns.

Cc: stable@vger.kernel.org
Reviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: 7241c57d ("drm/i915: Add TGL+ SAGV support")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-2-ville.syrjala@linux.intel.com
(cherry picked from commit 8dd8ffb8)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

Add some debugs on what exactly we're doing to the QGV point mask
in the icl+ sagv pre/post plane update hooks. Currently we're just
guessing.

v2: s/u32/u16/ for consistency with the mask sizes (Stan)
Reviewed-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/20220218064039.12834-5-ville.syrjala@linux.intel.com

To further reduce the confusion between the pre-icl vs. icl+
SAGV codepaths let's do a full split.
Reviewed-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/20220218064039.12834-4-ville.syrjala@linux.intel.com

When changing between SAGV vs. no SAGV on tgl+ we have to
update the use_sagv_wm flag for all the crtcs or else
an active pipe not already in the state will end up using
the wrong watermarks. That is especially bad when we end up
with the tighter non-SAGV watermarks with SAGV enabled.
Usually ends up in underruns.

Cc: stable@vger.kernel.org
Reviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: 7241c57d ("drm/i915: Add TGL+ SAGV support")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-2-ville.syrjala@linux.intel.com

Use REG_GENMASK() & co. for ilk+ watermark registers.

v2: Stick to the current bitmask sizes (Jani)
    Fix "watermarm" typo (Jani)
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220216232806.6194-4-ville.syrjala@linux.intel.com

Give names to the SSKPD/MLTR fields, and use the
REG_GENMASK* and REG_FIELD_GET*.

Also drop the bogus non-mirrored SSKP register define.

v2: Rebase due to intel_mchbar_regs.h
    Leave gen6_check_mch_setup() in place for the moment
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220216232806.6194-3-ville.syrjala@linux.intel.com

Registers that exist within the MCH BAR and are mirrored into the GPU's
MMIO space are a good candidate to separate out into their own header.

For reference, the mirror of the MCH BAR starts at the following
locations in the graphics MMIO space (the end of the MCHBAR range
differs slightly on each platform):

 * Pre-gen6:           0x10000
 * Gen6-Gen11 + RKL:  0x140000

v2:
 - Create separate patch to swtich a few register definitions to be
   relative to the MCHBAR mirror base.
 - Drop upper bound of MCHBAR mirror from commit message; there are too
   many different combinations between various platforms to list out,
   and the documentation is spotty for the older pre-gen6 platforms
   anyway.

Bspec: 134, 51771
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220215061342.2055952-2-matthew.d.roper@intel.com

intel_sagv_{pre,post}_plane_update() can accidentally forget
to bail out early on pre-icl and proceed down the icl+ codepath
at the end of the function. Fortunately it'll bail out before
it gets too far due to old_qgv_mask==new_qgv_mask==0 so no real
bug here. But lets make the code less confusing anyway.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220214091811.13725-5-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

Use the {active,scaled}_planes bitmasks from the crtc state
rather than poking at the plane state directly. One step
towards eliminating the last use of the somewhat questionble
intel_atomic_crtc_state_for_each_plane_state() macro which
peeks into the plane state without actually holding the plane
mutex.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220211090629.15555-5-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

The bogus loop from compute_dbuf_slices() was copied into
check_mbus_joined() as well. So this lookup is wrong as well.
Fix it.

Cc: stable@vger.kernel.org
Fixes: f4dc0086 ("drm/i915/adl_p: MBUS programming")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220207132700.481-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
(cherry picked from commit 053f2b85)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

Apparently I totally fumbled the loop condition when I
removed the ARRAY_SIZE() stuff from the dbuf slice config
lookup. Comparing the loop index with the active_pipes bitmask
is utter nonsense, what we want to do is check to see if the
mask is zero or not.

Note that the code actually ended up working correctly despite
the fumble, up until commit eef17395 ("drm/i915: Allow
!join_mbus cases for adlp+ dbuf configuration") when things
broke for real.

Cc: stable@vger.kernel.org
Fixes: 05e8155a ("drm/i915: Use a sentinel to terminate the dbuf slice arrays")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220207132700.481-1-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
(cherry picked from commit a28fde30)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

Replace some copy-pasta with a function.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220118092354.11631-6-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

Collect a bit of the stuff used during the plane ddb
allocation into a struct we can pass around.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220118092354.11631-5-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

We are currently computing the relative data rates as
src_size * scale_factor where scale_factor is src_size / dst_size.
Thus relative data rate is src_size * src_size / dst_size,
which is just utter nonsense. What we really seem to want is
just a reasonable estimate on how much data will be fetched
which is just src_size. So let's do that instead.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220118092354.11631-4-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

Extract a small helper to populate a ddb entry.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220118092354.11631-3-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

skl_ddb_entry_init_from_hw() has no need for dev_priv.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220118092354.11631-2-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

The struct is only needed in intel_pm.c, move it there.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/63779ac0472895803113180818ecadc22c10369e.1643896905.git.jani.nikula@intel.com

The bogus loop from compute_dbuf_slices() was copied into
check_mbus_joined() as well. So this lookup is wrong as well.
Fix it.

Cc: stable@vger.kernel.org
Fixes: f4dc0086 ("drm/i915/adl_p: MBUS programming")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220207132700.481-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Apparently I totally fumbled the loop condition when I
removed the ARRAY_SIZE() stuff from the dbuf slice config
lookup. Comparing the loop index with the active_pipes bitmask
is utter nonsense, what we want to do is check to see if the
mask is zero or not.

Note that the code actually ended up working correctly despite
the fumble, up until commit eef17395 ("drm/i915: Allow
!join_mbus cases for adlp+ dbuf configuration") when things
broke for real.

Cc: stable@vger.kernel.org
Fixes: 05e8155a ("drm/i915: Use a sentinel to terminate the dbuf slice arrays")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220207132700.481-1-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>