The allocated pages need to be invalidated in CPU caches. On ARM32 the
DMA_BIDIRECTIONAL flag only ensures that data is written-back to DRAM and
the data stays in CPU cache lines. While the DMA_FROM_DEVICE flag ensures
that the corresponding CPU cache lines are getting invalidated and nothing
more, that's exactly what is needed for a newly allocated pages.
This fixes randomly failing rendercheck tests on Tegra30 using the
Opentegra driver for tests that use small-sized pixmaps (10x10 and less,
i.e. 1-2 memory pages) because apparently CPU reads out stale data from
caches and/or that data is getting evicted to DRAM at the time of HW job
execution.
Fixes: bd43c9f0fa ("drm/tegra: gem: Map pages via the DMA API")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add ACX467AKM-7 4.95" 1080×1920 LCD panel that is found on the LG Nexus
5 (hammerhead) phone.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
[masneyb@onstation.org: checkpatch fixes; rename jdi,1080p-hammerhead
binding to lg,acx467akm-7.]
Signed-off-by: Brian Masney <masneyb@onstation.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181124200628.24393-2-masneyb@onstation.org
Add binding for the LG ACX467AKM-7 4.95" 1080×1920 LCD panel that is
found on the LG Nexus 5 (hammerhead) phone. This appears to be a JDI
panel based on some Internet searches, however a specific model number
could not be found. I disassembled an old Nexus 5 with a broken
screen and the LG part number is the only model number present on the
back of the panel, so I think that is probably the best ID to use.
Signed-off-by: Brian Masney <masneyb@onstation.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181124200628.24393-1-masneyb@onstation.org
This reverts commit 8059add047.
This commit while seemingly a good idea, breaks a radv check,
for a node being master because something succeeds where it failed
before now.
Apply the Linus rule, revert early and try again, we don't break
userspace.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit f06ddb5309 ("BackMerge v5.1-rc5 into drm-next") incorrectly
resolved a merge conflict related to a patch having been merged twice:
- commit 3f04e0a6cf ("drm: Fix drm_release() and device unplug")
introduced as a standalone fix via drm-fixes branch,
- commit 1ee57d4d75 ("drm: Fix drm_release() and device unplug")
applied as patch 1/2 of a series on drm-next branch.
That incorrect resolution of the conflict effectively reverted a change
introduced to drivers/gpu/drm/drm_drv.c by patch 2/2 of that series -
commit ba3bf37e15 ("drm/drv: drm_dev_unplug(): Move out drm_dev_put()
call"). Fix it.
Fixes: f06ddb5309 ("BackMerge v5.1-rc5 into drm-next")
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190417133232.16232-1-janusz.krzysztofik@linux.intel.com
The Amlogic SoCs Canvas buffers stride must be aligned on 64bytes
and overall size should be aligned on PAGE width.
Adds a custom dumb_create op to adds these requirements.
Fixes: bbbe775ec5 ("drm: Add support for Amlogic Meson Graphic Controller")
Suggested-by: Sky Zhou <sky.zhou@amlogic.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Sky Zhou <sky.zhou@amlogic.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190408090137.2402-1-narmstrong@baylibre.com
Fix sparse warnings:
drivers/gpu/drm/meson/meson_viu.c:93:6: warning: symbol 'meson_viu_set_g12a_osd1_matrix' was not declared. Should it be static?
drivers/gpu/drm/meson/meson_viu.c:121:6: warning: symbol 'meson_viu_set_osd_matrix' was not declared. Should it be static?
drivers/gpu/drm/meson/meson_viu.c:190:6: warning: symbol 'meson_viu_set_osd_lut' was not declared. Should it be static?
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190413141455.34020-1-yuehaibing@huawei.com
Fix sparse warnings:
drivers/gpu/drm/sun4i/sun8i_tcon_top.c:271:36: warning: symbol 'sun8i_r40_tcon_top_quirks' was not declared. Should it be static?
drivers/gpu/drm/sun4i/sun8i_tcon_top.c:276:36: warning: symbol 'sun50i_h6_tcon_top_quirks' was not declared. Should it be static?
drivers/gpu/drm/sun4i/sun4i_tcon.c:239:6: warning: symbol 'sun4i_tcon_set_mux' was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416145855.20852-1-yuehaibing@huawei.com
Fix sparse warning:
drivers/gpu/drm/lima/lima_sched.c:356:36: warning:
symbol 'lima_sched_ops' was not declared. Should it be static?
Fixes: a1d2a63399 ("drm/lima: driver for ARM Mali4xx GPUs")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416144353.34024-1-yuehaibing@huawei.com
The cdclk init/uninit code was changed by commit 93a643f29b
("drm/i915/cdclk: have only one init/uninit function") between the
versions of commit 39564ae86d ("drm/i915/ehl: Inherit Ice Lake
conditional code"). What got merged fails to do cdclk init/uninit on
ehl.
Fixes: 39564ae86d ("drm/i915/ehl: Inherit Ice Lake conditional code")
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416082852.18141-1-jani.nikula@intel.com
SSEU reprogramming of the context introduced the notion of engine class
and instance for a forwards compatible method of describing any engine
beyond the old execbuf interface. We wish to adopt this class:instance
description for more interfaces, so pull it out into a separate type for
userspace convenience.
Fixes: e46c2e99f6 ("drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Cc: Andi Shyti <andi@etezian.org>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Tony Ye <tony.ye@intel.com>
Reviewed-by: Andi Shyti <andi@etezian.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190412071416.30097-1-chris@chris-wilson.co.uk
I needed to add implicit dependency support for v3d, and Rob Herring
has been working on it for panfrost, and I had recently looked at the
lima implementation so I think this will be a good intersection of
what we all want and simplify our scheduler implementations.
v2: Rebase on xa_limit_32b API change, and tiny checkpatch cleanups on
the way in (unsigned int vs unsigned, extra return before
EXPORT_SYMBOL_GPL)
Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190401222635.25013-6-eric@anholt.net
Reviewed-and-tested-by: Qiang Yu <yuq825@gmail.com> (v1)
Plane property "FB_DAMAGE_CLIPS" can only be used by atomic aware
user-space, so no point exposing it otherwise.
Cc: <stable@vger.kernel.org>
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes: d3b2176782 ("drm: Add a new plane property to send damage during plane update")
Link: https://patchwork.freedesktop.org/patch/msgid/20190415172814.9840-1-drawat@vmware.com
Make them take the uncore argument from the caller instead of passing
the implicit &dev_priv->uncore directly. This will allow us to finally
pass something that's not dev_priv->uncore in the future, and gets rid
of the implicit variables in register macros.
v2: Rebase on top of the newer patches.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-6-paulo.r.zanoni@intel.com
The IRQ initialization helpers are simple and self-contained. Continue
the transition started in the recent uncore rework to get us rid of
I915_READ/WRITE and the implicit dev_priv variables.
While the implicit dev_priv is removed from the IRQ initialization
helpers, we didn't get rid of them in the macro callers. Doing that
should be very simple now.
v2: Rebase on top of the new patches.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-5-paulo.r.zanoni@intel.com
This discussion started because we use token pasting in the
GEN{2,3}_IRQ_INIT and GEN{2,3}_IRQ_RESET macros, so gen2-4 passes an
empty argument to those macros, making the code a little weird. The
original proposal was to just add a comment as the empty argument, but
Ville suggested we just add a prefix to the registers, and that indeed
sounds like a more elegant solution.
Now doing this is kinda against our rules for register naming since we
only add gens or platform names as register prefixes when the given
gen/platform changes a register that already existed before. On the
other hand, we have so many instances of IIR/IMR in comments that
adding a prefix would make the users of these register more easily
findable, in addition to make our token pasting macros actually
readable. So IMHO opening an exception here is worth it.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-4-paulo.r.zanoni@intel.com
Like the gen3+ macros, the gen2 versions of the IRQ initialization
macros take the register name in the 'type' argument. But gen2 only
has one set of registers, so there's really no need to specify the
type. This commit removes the type argument and uses the registers
directly instead of passing them through variables.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-3-paulo.r.zanoni@intel.com
The whole point of having macros here is for the token pasting
necessary to automatically have IMR, IIR and IER selected. We don't
really need or want all the inlining that happens as a consequence.
The good thing about the current code is that it works regardless of
the relative offsets between these registers (they change after gen4,
with the usual VLV/CHV exceptions).
One thing which we can do is to split the logic of what we do with
imr/ier/iir to functions separate from the macros that pick them.
That's what we do in this commit. This allows us to get rid of the
gen8 duplicates and also all the inlining:
add/remove: 2/0 grow/shrink: 0/21 up/down: 384/-5949 (-5565)
Function old new delta
gen3_irq_reset - 233 +233
gen3_irq_init - 151 +151
i8xx_irq_postinstall 459 442 -17
gen11_irq_postinstall 804 744 -60
ironlake_irq_postinstall 450 353 -97
vlv_display_irq_postinstall 348 245 -103
i965_irq_postinstall 378 272 -106
i915_irq_postinstall 333 227 -106
gen8_irq_power_well_post_enable 374 240 -134
ironlake_irq_reset 397 218 -179
vlv_display_irq_reset 616 433 -183
i965_irq_reset 374 180 -194
cherryview_irq_reset 379 185 -194
i915_irq_reset 407 209 -198
ibx_irq_reset 332 133 -199
gen5_gt_irq_postinstall 533 332 -201
gen8_irq_power_well_pre_disable 434 204 -230
gen8_gt_irq_postinstall 469 196 -273
gen8_de_irq_postinstall 1200 836 -364
gen5_gt_irq_reset 471 76 -395
gen8_gt_irq_reset 775 99 -676
gen8_irq_reset 1100 333 -767
gen11_irq_reset 1959 686 -1273
Total: Before=2259222, After=2253657, chg -0.25%
v2:
- Make checkpatch happy with a temporary which_ (Checkpatch).
- Reorder the arguments for the INIT macros (Ville).
- Correctly explain when the register offsets change in the commit
message (Ville).
- Use more line breaks in the macro calls to make the arguments look
a little more organized/readable.
- Update the bloat-o-meter output (minor change only).
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-2-paulo.r.zanoni@intel.com
The GFX IP is inside of the ASPEED BMC SoC so there is little use
enabling it on a kernel that does not support ASPEED.
When building with COMPILE_TEST the architecture many not have CMA
support, so to avoid breaking the build we only select these options if
the architecture supports the contiguous allocator.
I suspect the DRM_PANEL came from a cut/paste error.
Fixes: 4f2a8f5898 ("drm: Add ASPEED GFX driver")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190405081117.27339-1-joel@jms.id.au
Instead of checking the upper values of the sequence number use an explicit
field in the dma_fence_ops structure to note if a sequence should be 32bit
or 64bit.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/299655/
Since removal of the "missed interrupt detection" nobody used the result
of whether or not we signaled anybody during that invocation, so now
remove the return value.
References: 789659f430 ("drm/i915: Drop fake breadcrumb irq")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416085218.431-1-chris@chris-wilson.co.uk
According to GFX PRM on 01.org, bit 31:16 of mmio 0x22028 should be masks.
Fixes: 1786571393 ("drm/i915/gvt: vGPU context switch")
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Colin Xu <colin.xu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
with the introduce of "switch to use HWS indices rather than address",
guest GPU hang observed when running workloads which will update the
seqno to the real HW HWSP, not vitural GPU HWSP and then cause GPU hang.
this patch is to revoke index mode in PIPE_CTRL and MI_FLUSH_DW and
patch guest GPU HWSP address value to these commands.
Fixes: 54939ea0bd ("drm/i915: Switch to use HWS indices rather than addresses")
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Xiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Merge back drm-intel-next for engine name definition refinement
and 54939ea0bd ("drm/i915: Switch to use HWS indices rather than addresses")
that would need gvt fixes to depend on.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
This is one of the patches to start replacing drm pointers
and use the intel_atomic_state and intel_crtc to derive
the necessary intel state variables required for the intel
modeset functions.
v3:
* Remove the unwanted newline (Ville)
v2:
* Flip the function arguments (Ville)
* Remove some remaining instances of drm pointers (Ville)
* Use old_crtc_state and new_crtc_state (Ville)
Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190415182210.13347-1-manasi.d.navare@intel.com
If the driver is wedged, we can not issue the requests to exercise the
timelines or the system across suspend, so skip the tests. live_hangcheck
is there to fail if we cannot recover.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190413125820.14112-4-chris@chris-wilson.co.uk
[Why]
We used this change to investigate the performance of bandwidth validation,
it will be useful to have if we need to investigate further.
[How]
We use performance counter tick numbers to profile performance, they live
at dc->debug.bw_val_profile (set .enable in debugger to turn on measuring).
Signed-off-by: Joshua Aberback <joshua.aberback@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add a fast_validate parameter in dc_validate_global_state for future use
Signed-off-by: Joshua Aberback <joshua.aberback@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
As long as we have at least one non-cursor plane enabled on a CRTC then
the CRTC itself can remain enabled.
This will allow for commits where there's an overlay plane enabled but
no primary plane enabled.
[How]
Remove existing primary plane fb != NULL checks and replace them with
the new does_crtc_have_active_plane helper.
This will be called from atomic check when validating the CRTC.
Since the primary plane state can now potentially be NULL we'll need
to guard for that when accessing it in some of the cursor logic.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Surface scaling info updates can affect bandwidth and blocks. We need
to be checking these with global validation to avoid underflow or
corruption.
[How]
Drop the state->allow_modeset early exit in
dm_determine_update_type_for_commit. Most of those should be considered
fast now anyway.
Fill in scaling info and it to the surface update in atomic
check.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
DM thinks that the update type should be full whenever a stream or
plane is added or removed (including recreations).
This won't match in the case where DC thinks what looks like a fast
update to DM is actually a medium or full - like scaling changes that
affect bandwidth and clocks.
[How]
Drop this warning. DC knows better than the DM does for determining
cases like this.
The other warning can be kept for now since it would warn on a pretty
serious DC or DM bug.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
DC expects the surface memory address to identify the surface.
This doesn't work with what we're doing with the temporary surfaces,
it will always assume this is a full update because the surface
isn't in the current context.
[How]
Use the surface directly. This doesn't give us much improvement yet,
since we always create a new dc_plane_state when state->allow_modeset
is true.
The call into dc_check_update_surfaces_for_stream also needs to be
locked, for two reasons:
1. It checks the current DC state
2. It modifies the surface update flags
Both of which could be currently in the middle of commit work from
commit tail.
A TODO here is to pass the context explicitly into this function and
find a way to get the surface update flags out of it without modifying
the surface in place.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Planes have downscaling limits and upscaling limits per format and DM
is expected to validate these using DC caps. We should fail atomic
check validation if we aren't capable of doing the scaling.
[How]
We don't currently create store which DC plane maps to which DRM plane
so we can't easily check the caps directly. For now add basic
constraints that cover the absolute min and max downscale / upscale
limits for most RGB and YUV formats across ASICs.
Leave a TODO indicating that these should really be done with DC caps.
We'll probably need to subclass DRM planes again in order to correctly
identify which DC plane maps to it.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
DM doesn't need to know which link cap is being retrieved ( verified
or preferred ). Let DC figure it out.
[How]
Change name.
Signed-off-by: Samson Tam <Samson.Tam@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
We currently don't do DC validation for medium or full updates where
the plane state isn't created. There are some medium and full updates
that can cause bandwidth or clock changes to occur resulting in
underflow or corruption.
We need to be able to fill surface and plane info updates during
atomic commit for dm_determine_update_type for commit. Since we already
do this during atomic commit tail it would be good if we had the same
logic in both places for creating these structures.
[How]
Introduce fill_dc_scaling_info and fill_dc_plane_info_and_addr.
These two functions cover the following three update structures:
- struct dc_scaling_info
- struct dc_plane_info
- struct dc_plane_address
Cleanup and adapter the existing fill_plane_* helpers to work with
these functions.
Update call sites that used most of these sub helpers directly to work
with the new functions. The exception being prepare_fb - we just want
the new buffer attributes specifically in the case where we're
creating the plane. This is needed for dc_commit_state in the case
where the FB hasn't been previously been used.
This isn't quite a refactor, but functionally driver behavior should
be mostly the smae as before. The one exception is that we now check
the return code for fill_plane_buffer_attributes which means that
commits will be rejected that try to enable DCC with erroneous
parameters.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Pitch was only calculated based on format whenever the plane state
was recreated. This could result in surface corruption due to the
incorrect pitch being programmed when the surface pitch changed during
commits where state->allow_modeset = false.
[How]
Recalculate pitch at the same time we update the buffer address and
other buffer attributes. This function was previously called
fill_plane_tiling_attributes but I've also renamed it to
fill_plane_buffer_attributes to clarify the actual intent of the
function now that it's handling most buffer related attributes.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
The overlay will be incorrectly placed *below* the primary plane for
commits with state->allow_modeset = true because the primary plane
won't be removed and recreated in the same commit.
[How]
Add the should_reset_plane helper to determine if the plane should be
reset or not. If we need to add or force reset any plane in the context
then we'll need to do the same for every plane on the stream.
Unfortunately we need to do the remove / recreate routine for removing
planes as well since DC currently isn't well equipped to handle the
plane with the top pipe being removed with other planes still active.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Plane scaling parameters are not correctly filled or updated when
performing fast updates.
They're filled when creating the dc plane state and during atomic check.
While the atomic check code path happens for the plane even during fast
updates, the issue is that they're done in place on the dc_plane_state
directly. This dc_plane_state may be the current state plane state
being used by the hardware, so these parameters won't be correctly
programmed.
The new scaling parameters should instead be passed as an update
to the plane.
[How]
Update fill_rects_from_plane_state to not modify dc_plane_state
directly. Update the call sites that use this to fill in the appropriate
values.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Unlike external DP panels, internal eDP does not perform
verify link caps because the panel connection is fixed.
So if GOP enabled the eDP at boot, we can retain its
trained link settings to optimize.
[How]
Read the lane count and link rate by reading this
information from DPCD 100h, 101h, 115h
Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
dc_stream_get_crtc_position can return false.
This was unhandled in delay_cursor_until_vupdate
[How]
If dc_stream_get_crtc_position returns false, something
is weird. Don't delay.
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
there are some scaling capabilities such as fp16 which are known to be unsupported
on a given ASIC. exposing these static capabilities allows much simpler implementation
for OS interfaces which require to report such static capabilities to reduce the
number of dynamic validation calls
[how]
refactor the existing plane caps to be more extensible, and add fp16 and scaling
capabilities
Signed-off-by: Jun Lei <Jun.Lei@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Acked-by: Harry Wentland <Harry.Wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dmitry Osipenko