pm_resume and pm_suspend might be conflict with the ones defined in
include/linux/suspend.h. Rename all pm_* to igt_pm_* in selftests since
they are only used here.
v2 by Jani:
- Use igt_ prefix instead of i915_ to avoid colliding with existing
i915_pm_* functions
- Rename all pm_ prefixed functions in the file
Chris Wilson [Mon, 12 Apr 2021 09:05:09 +0000 (10:05 +0100)]
drm/i915/selftests: Only query RAPL for integrated power measurements
RAPL provides an on-package power measurements which does not encompass
discrete graphics, so let's avoid using the igfx masurements when testing
dgfx. Later we will abstract the simple librapl interface over hwmon so
that we can verify basic power consumption scenarios.
Merge tag 'topic/intel-gen-to-ver-2021-04-19' of git://anongit.freedesktop.org/drm/drm-intel into drm-intel-gt-next
Gen to ver conversions across the driver
The main change is Lucas' series [1], with Ville's GLK fixes [2] and a
cherry-pick of Matt's commit [3] from drm-intel-next as a base to avoid
conflicts.
Matthew Auld [Mon, 19 Apr 2021 10:57:41 +0000 (11:57 +0100)]
drm/i915/uapi: convert i915_query and friend to kernel doc
Add a note about the two-step process.
v2(Tvrtko):
- Also document the other method of just passing in a buffer which is
large enough, which avoids two ioctl calls. Can make sense for
smaller query items.
v3: prefer kernel-doc references for structs and members
Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Dave Airlie <airlied@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: mesa-dev@lists.freedesktop.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Link: https://patchwork.freedesktop.org/patch/msgid/20210419105741.27844-4-matthew.auld@intel.com
Matthew Auld [Mon, 19 Apr 2021 10:57:40 +0000 (11:57 +0100)]
drm/i915/uapi: convert i915_user_extension to kernel doc
Add some example usage for the extension chaining also, which is quite
nifty.
v2: (Daniel)
- clarify that the name is just some integer, also document that the
name space is not global
v3: prefer kernel-doc references for structs
Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Dave Airlie <airlied@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: mesa-dev@lists.freedesktop.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Link: https://patchwork.freedesktop.org/patch/msgid/20210419105741.27844-3-matthew.auld@intel.com
Lucas De Marchi [Tue, 13 Apr 2021 05:10:02 +0000 (22:10 -0700)]
drm/i915: split dgfx features from gen 12
Make them independent so we can use DGFX_FEATURES more generically.
For future platforms that do not use the GEN nomenclature we will define
graphics, media and display separately, so we avoid setting graphics_ver
with the GEN() macro.
Lucas De Marchi [Tue, 13 Apr 2021 05:09:58 +0000 (22:09 -0700)]
drm/i915: finish removal of gen_mask
Now that it's not used anywhere, remove it from struct
intel_device_info. To allow a period in which code will be converted to
the new macro, keep IS_GEN_RANGE() around, just redefining it to use
the new fields. The size advantage from IS_GEN_RANGE() using a mask is
not that big as it has pretty limited use througout the driver:
text data bss dec hex filename 2758497 95965 6496 2860958 2ba79e drivers/gpu/drm/i915/i915.ko.old 2758586 95953 6496 2861035 2ba7eb drivers/gpu/drm/i915/i915.ko.new
Lucas De Marchi [Tue, 13 Apr 2021 05:09:57 +0000 (22:09 -0700)]
drm/i915/selftests: eliminate use of gen_mask
Remove the remaining uses of INTEL_GEN_MASK() and the correspondent
gen_mask in struct intel_device_info. This will allow the removal of
gen_mask later since it's incompatible with the new per-IP versioning
scheme.
Lucas De Marchi [Tue, 13 Apr 2021 05:09:56 +0000 (22:09 -0700)]
drm/i915/selftests: replace unused mask with simple version
Since its introduction 2 years ago, we never used the mask to span more
than one gen. Replace gen_mask a single number and start using the new
GRAPHICS_VER().
Lucas De Marchi [Tue, 13 Apr 2021 05:09:55 +0000 (22:09 -0700)]
drm/i915/gt: replace gen use in intel_engine_cs
Start using the new fields graphics_version for the previous gen checks.
Here we rename the "gen" field and replace the comparisons using it to
start using the new GRAPHICS_VER(). Other uses of INTEL_GEN() were left
as is for automatic conversion later.
Lucas De Marchi [Tue, 13 Apr 2021 05:09:54 +0000 (22:09 -0700)]
drm/i915: add macros for graphics and media versions
Like it was done in
commit 01eb15c9165e ("drm/i915: Add DISPLAY_VER() and related macros")
add the correspondent macros for graphics and media. Going forward we
will prefer checking the versions for the specific IPs (graphics, media
and display) rather than grouping everything under a "gen" version.
For consistency and to make the maintenance easier, it'd be preferred
not to mix the *GEN* macros with the new ones. For older platforms we
can simply consider that the previous "gen" number will extend to all
3 IPs. Then we can start replacing its use in the driver. Right now this
replacement is not done and only the infrastructure is put in place.
We also leave gen and gen_mask inside struct intel_device_info while
it's still being used throughout the code.
v2: Repurpose IS_{GRAPHICS,MEDIA}_VER() macros to work with a range
Lucas De Marchi [Tue, 13 Apr 2021 05:09:53 +0000 (22:09 -0700)]
drm/i915/display: rename display version macros
While converting the rest of the driver to use GRAPHICS_VER() and
MEDIA_VER(), following what was done for display, some discussions went
back on what we did for display:
1) Why is the == comparison special that deserves a separate
macro instead of just getting the version and comparing directly
like is done for >, >=, <=?
2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for
brevity. If we remove the current users of IS_DISPLAY_VER(), we
could actually repurpose it for a range check
With (1) there could be an advantage if we used gen_mask since multiple
conditionals be combined by the compiler in a single and instruction and
check the result. However a) INTEL_GEN() doesn't use the mask since it
would make the code bigger everywhere else and b) in the cases it made
sense, it also made sense to convert to the _RANGE() variant.
So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range
like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER()
users to use == and != operators. Aside from the definition changes,
this was done by the following semantic patch:
Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
[Jani: Minor conflict resolve while applying.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com
Lucas De Marchi [Tue, 13 Apr 2021 05:09:52 +0000 (22:09 -0700)]
drm/i915: rename display.version to display.ver
The macro we use to check is called DISPLAY_VER(). While using this
macro and the new ones being added in following changes I made the
mistake multiple times when mixing both "ver" and "version". Although
it's usually better to prefer the complete name, the shorhand
DISPLAY_VER() / GRAPHICS_VER / MEDIA_VER are clear and cause less
visual polution.
Another issue is when copying the variable to other places.
"display.version" would be copied to a "display_version" variable which
is long and would make people abbreviate as "version", or "display_ver".
In the first case it's not always clear what version refers to, and in
the second case it just hints it should be the name in the first place.
So, in the same way use used "gen" rather than "generation", use "ver"
instead of "version".
Lucas De Marchi [Tue, 13 Apr 2021 05:09:51 +0000 (22:09 -0700)]
drm/i915/display: use DISPLAY_VER() on remaining users
Commit 989634fb49ad ("drm/i915/audio: set HDA link parameters in driver")
added INTEL_GEN() in the display code, where it should actually be using
DISPLAY_VER(). Switch to the new macro.
Ville Syrjälä [Mon, 12 Apr 2021 05:46:06 +0000 (08:46 +0300)]
drm/i915: Don't use {skl, cnl}_hpd_pin() for bxt/glk
Just let bxt/glk fall back to intel_hpd_pin_default() instead
of using skl_hpd_pin() or cnl_hpd_pin(). Doesn't really matter
since both functions will end up returning the correct hpd pin
anyway, but I find it a bit less confusing when bxt/glk are
fully separated from the logic for the other platforms.
Ville Syrjälä [Mon, 12 Apr 2021 05:46:05 +0000 (08:46 +0300)]
drm/i915: Disable LTTPR detection on GLK once again
The glk display version change is causing us to again attempt
LTTPR detection on glk. We must not do tha since glk doesn't
have a long enough AUX timeout. Restore the correct logic to
skip the detection.
Ville Syrjälä [Mon, 12 Apr 2021 05:46:03 +0000 (08:46 +0300)]
drm/i915: Restore lost glk FBC 16bpp w/a
We lost the FBC 16bpp 512byte stride requirement on glk when
we switched from display version 9 to 10. Restore the w/a to
avoid enabling FBC with a bad stride and thus display garbage.
Matt Roper [Wed, 7 Apr 2021 20:39:45 +0000 (13:39 -0700)]
drm/i915/display: Eliminate IS_GEN9_{BC,LP}
Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the
display code, we should also kill off our use of the IS_GEN9_* macros
too. We'll do the conversion manually this time instead of using
Coccinelle since the most logical substitution can depend heavily on the
code context, and sometimes we can keep the code simpler if we make
additional adjustments such as swapping the order of if/else arms.
v2:
- Restore a lost negation in intel_pll_is_valid().
Tvrtko Ursulin [Wed, 31 Mar 2021 10:18:50 +0000 (11:18 +0100)]
drm/i915/pmu: Check actual RC6 status
RC6 support cannot be simply established by looking at the static device
HAS_RC6() flag. There are cases which disable RC6 at driver load time so
use the status of those check when deciding whether to enumerate the rc6
counter.
Tvrtko Ursulin [Fri, 26 Mar 2021 10:57:59 +0000 (10:57 +0000)]
drm/i915: Take request reference before arming the watchdog timer
Reference needs to be taken before arming the timer. Luckily, given the
default timer period of 20s, the potential to hit the race is extremely
unlikely.
drm/i915: Move Wa_16011163337 to gen12_ctx_workarounds_init()
This WA is needed in all gen12 platforms, moving it to
gen12_ctx_workarounds_init() allow us to remove the duplicated
implementation.
Also allow us to remove the tgl_ctx_workarounds_init() that after the
WA move above was empty.
Caz Yokoyama [Wed, 24 Mar 2021 20:05:00 +0000 (13:05 -0700)]
drm/i915/icl: add Wa_22010271021 for all gen11
Wa_22010271021 does not apply only to EHL, but to all gen11 and other
gen12 platforms. Gen12 is already covered in another code path, but we
need to stop checking for EHL when handling gen11.
Bspec: 33450, 52887
v2: Remove "gen11" suffix as it also applies to gen12 platforms
Caz Yokoyama [Wed, 24 Mar 2021 20:04:59 +0000 (13:04 -0700)]
drm/i915/gen12: Add recommended hardware tuning value
Follow Bspec 31870 to set recommended tuning values for certain GT
register. These values aren't workarounds per-se, but it's best to
handle them in the same general area of the driver, especially since
there may be real workarounds that update other bits of the same
registers.
At the moment the only value we need to worry about is the
TDS_TIMER setting in FF_MODE2. This setting was previously
described as "Wa_1604555607" on some platforms, but the spec
tells us that we should continue to program this on all current
gen12 platforms, even those that do not have that WA.
Bspec: 31870
v2: Rephrase some comments to make them clearer (Matt)
Dave Airlie [Thu, 8 Apr 2021 04:02:14 +0000 (14:02 +1000)]
Merge tag 'drm-intel-next-2021-04-01' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
Features:
- Add support for FBs requiring a power-of-two stride padding (Imre)
Refactoring:
- Disassociate display version from gen (Matt)
- Refactor legacy DP and HDMI code to separate files (Ville)
- Refactor FB plane code to a separate file (Imre)
- Refactor VBT child device info parsing and usage (Jani)
- Refactor KBL/TGL/ADL-S display and gt stepping schemes (Jani)
Fixes:
- DP Link-Training Tunable PHY Repeaters (LTTPR) fixes (Imre)
- HDCP fixes (Anshuman)
- DP 2.0 HDMI 2.1 PCON Fixed Rate Link (FRL) fixes (Ankit)
- Set HDA link parameters in driver (Kai)
- Fix enabled_planes bitmask (Ville)
- Fix transposed arguments to skl_plane_wm_level() (Ville)
- Stop adding planes to the commit needlessly (Ville)
Dave Airlie [Thu, 8 Apr 2021 02:42:46 +0000 (12:42 +1000)]
Merge tag 'drm-intel-gt-next-2021-04-06' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
Driver Changes:
- Prepare for local/device memory support on DG1 by starting
to use it for kernel internal allocations: context, ring
and engine scratch (Matt A, CQ, Abdiel, Imre)
- Sandybridge fix to avoid hard hang on ring resume (Chris)
- Limit imported dma-buf size to int32 (Matt A)
- Double check heartbeat timeout before resetting (Chris)
- Use new tasklet API for execution list (Emil)
- Fix SPDX checkpats warnings (Chris)
- Fixes for various checkpatch warnings (Chris)
- Selftest improvements (Chris)
- Move the defer_request waiter active assertion to correct spot (Chris)
- Make local-memory probing a GT operation (Matt, Tvrtko)
- Protect against request freeing during cancellation on wedging (Chris)
- Retire unexpected starting state error dumping (Chris)
- Distinction of memory regions in debugging (Zbigniew)
- Always flush the submission queue on checking for idle (Chris)
- Consolidate 2big error check to helper (Matt)
- Decrease number of subplatform bits (Tvrtko)
- Remove unused internal request priority levels (Chris)
- Document the unused internal header bits in buddy allocator (Matt)
- Cleanup the region class/instance encoding (Matt)
Dafna Hirschfeld [Tue, 30 Mar 2021 11:09:02 +0000 (13:09 +0200)]
drm/mediatek: Don't support hdmi connector creation
commit f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges")
broke the display support for elm device since mtk_dpi calls
drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
while mtk_hdmi does not yet support this flag.
Fix this by accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in bridge attachment.
Implement the drm_bridge_funcs .detect() and .get_edid() operations, and
call drm_bridge_hpd_notify() to report HPD. This provides the
necessary API to support disabling connector creation.
In addition, the field 'conn' is removed from the mtk_hdmi struct since
mtk_hdmi don't create a connector. It is replaced with a pointer
'curr_conn' that points to the current connector which can be access
through the global state.
This patch is inspired by a similar patch for bridge/synopsys/dw-hdmi.c:
commit ec971aaa6775
("drm: bridge: dw-hdmi: Make connector creation optional")
But with the difference that in mtk-hdmi only the option of not creating
a connector is supported.
Fixes: f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges") Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Dafna Hirschfeld [Tue, 30 Mar 2021 11:09:01 +0000 (13:09 +0200)]
drm/mediatek: Switch the hdmi bridge ops to the atomic versions
The bridge operation '.enable' and the audio cb '.get_eld'
access hdmi->conn. In the future we will want to support
the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR and then we will
not have direct access to the connector.
The atomic version '.atomic_enable' allows accessing the
current connector from the state.
This patch switches the bridge to the atomic version to
prepare access to the connector in later patches.
Hsin-Yi Wang [Thu, 1 Apr 2021 05:32:02 +0000 (13:32 +0800)]
drm/bridge: anx7625: disable regulators when power off
When suspending the driver, anx7625_power_standby() will be called to
turn off reset-gpios and enable-gpios. However, power supplies are not
disabled. To save power, the driver can get the power supply regulators
and turn off them in anx7625_power_standby().
Dave Airlie [Wed, 31 Mar 2021 20:24:05 +0000 (06:24 +1000)]
Merge tag 'topic/i915-gem-next-2021-03-26' of ssh://git.freedesktop.org/git/drm/drm into drm-next
special i915-gem-next pull as requested
- Conversion to dma_resv_locking, obj->mm.lock is gone (Maarten, with
help from Thomas Hellström)
- watchdog (Tvrtko, one patch to cancel individual request from Chris)
- legacy ioctl cleanup (Jason+Ashutosh)
- i915-gem TODO and RFC process doc (me)
- i915_ prefix for vma_lookup (Liam Howlett) just because I spotted it
and put it in here too
Imre Deak [Tue, 30 Mar 2021 15:01:18 +0000 (18:01 +0300)]
drm/i915: Fix docbook header for __intel_runtime_pm_get_if_active()
Fix the
Documentation/gpu/i915:22: /drivers/gpu/drm/i915/intel_runtime_pm.c:423: WARNING: Inline strong start-string without end-string.
warning from the htmldocs build.
Fixes: 9d58aa46291d ("drm/i915: Fix the GT fence revocation runtime PM logic") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20210330150118.1105079-1-imre.deak@intel.com
Jani Nikula [Mon, 29 Mar 2021 13:37:21 +0000 (16:37 +0300)]
drm/displayid: allow data blocks with 0 payload length
The DisplayID specifications explicitly call out 0 as a valid payload
length for data blocks. The mere presence of a data block, or the
information coded in the block specific data (bits 7:3 in offset 1), may
be enough to convey the necessary information.
Jani Nikula [Mon, 29 Mar 2021 13:37:17 +0000 (16:37 +0300)]
drm/displayid: add new displayid section/block iterators
Iterating DisplayID blocks across sections (in EDID extensions) is
unnecessarily complicated for the caller. Implement DisplayID iterators
to go through all blocks in all sections.
When DisplayID is stored in EDID extensions, the DisplayID sections map
to extensions as described in VESA DisplayID v1.3 Appendix B: DisplayID
as an EDID Extension. This is implemented here.
When DisplayID is stored in its dedicated DDC device 0xA4, according to
VESA E-DDC v1.3, different rules apply for the structure. This is not
implemented here, as we don't currently use it, but the idea is you'd
have a different call for beginning the iteration, for example simply:
displayid_iter_begin(displayid, &iter);
instead of displayid_iter_edid_begin(), and everything else would be
hidden away in the iterator functions.
Jani Nikula [Mon, 29 Mar 2021 13:37:15 +0000 (16:37 +0300)]
drm/edid: make a number of functions, parameters and variables const
If there's no need to change it, it should be const. There's more to be
done, but start off with changes that make follow-up work easier. No
functional changes.
Boris Brezillon [Wed, 3 Feb 2021 11:07:17 +0000 (12:07 +0100)]
drm/mediatek: Add missing MODULE_DEVICE_TABLE()
This patch adds the missing MODULE_DEVICE_TABLE definitions on different
Mediatek drivers which generates correct modalias for automatic loading
when these drivers are compiled as an external module.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Anshuman Gupta [Wed, 24 Mar 2021 11:30:11 +0000 (17:00 +0530)]
drm/i915/hdcp: Add DP HDCP2.2 timeout to read entire msg
As documented in HDCP 2.2 DP Errata spec transmitter should abort the
authentication protocol in case transmitter has not received the
entire {AKE_Send_Cert, AKE_Send_H_prime, AKE_Send_Paring_Info} msg
within {110,7,5} miliseconds.
Adding above msg timeout values and aborting the HDCP authentication
in case it timedout to read entire msg.
Ankit Nautiyal [Tue, 23 Mar 2021 11:24:22 +0000 (16:54 +0530)]
drm/i915/display: Configure HDMI2.1 Pcon for FRL only if Src-Ctl mode is available
Add the check if source control mode is supported by the
PCON, before starting configuring PCON for FRL training,
as per spec VESA DP2.0-HDMI2.1 PCON Draft-1 Sec-7.
Ankit Nautiyal [Tue, 23 Mar 2021 11:24:21 +0000 (16:54 +0530)]
drm/dp_helper: Define options for FRL training for HDMI2.1 PCON
Currently the FRL training mode (Concurrent, Sequential) and
training type (Normal, Extended) are not defined properly and
are passed as bool values in drm_helpers for pcon
configuration for FRL training.
This patch:
-Add register masks for Sequential and Normal FRL training options.
-Fixes the drm_helpers for FRL Training configuration to use the
appropriate masks.
-Modifies the calls to the above drm_helpers in i915/intel_dp as per
the above change.
v2: Re-used the register masks for these options, instead of enum. (Ville)
Imre Deak [Thu, 25 Mar 2021 21:48:06 +0000 (23:48 +0200)]
drm/i915: Add support for FBs requiring a POT stride alignment
An upcoming platform has a restriction that the FB stride must be
power-of-two aligned. To support framebuffer layouts that are not in
this layout add a logic that pads the tile rows to the POT aligned size.
The HW won't read the padding PTEs, so these don't have to point to an
allocated address, or even have their valid flag set. So use a NULL PTE
instead for instance the scratch page, which is simple and keeps the SG
table compact.
v2:
- Simplify plane_view_dst_stride(). (Ville)
- Pass pitch_tiles as unsigned int.
v3:
- Drop unintentional s/plane_state->rotation/plane_config->rotation/
change.
Imre Deak [Thu, 25 Mar 2021 21:48:04 +0000 (23:48 +0200)]
drm/i915/selftest: Unify use of intel_remapped_plane_info in igt_vma_rotate_remap()
Always use the modified copy of the intel_remapped_plane_info variables.
An upcoming patch updates the dst_stride field in these copies after
which we can't use the original versions.
v2: Init view in igt_vma_rotate_remap() when declaring it. (Ville)
Imre Deak [Thu, 25 Mar 2021 21:48:03 +0000 (23:48 +0200)]
drm/i915: Shrink the size of intel_remapped_plane_info struct
Save some place in the GTT VMAs by using a u16 instead of unsigned int
to store the view dimensions. The maximum FB stride is 256kB which is
4096 tiles in the worst case (yf-tiles), the maximum FB height is 16k
pixels, which is 16384 tiles in the worst case (linear 4x1 tiled FB).
v2:
- Fix worst case tile height formula in commit log. (Ville)
- Add an assign_chk_ovf helper to simplify the related assignments.
v3:
- Enclose params of the assign_chk_ovf macro in parentheses.
Imre Deak [Thu, 25 Mar 2021 21:48:02 +0000 (23:48 +0200)]
drm/i915/intel_fb: Factor out calc_plane_remap_info()
Factor out to a new function the logic to calculate the FB remapping
parameters both during creating the FB and when flipping to it.
v2:
- Keep stride next to offset calculation. (Ville)
- Enclose check_array_bounds macro arguments in parentheses.
v3:
- Rebase on top of the struct intel_fb_view refactoring.
Imre Deak [Thu, 25 Mar 2021 21:48:01 +0000 (23:48 +0200)]
drm/i915: Simplify copying the FB view state to the plane state
Instead of copying separately the GTT remapped and color plane view info
from the FB to the plane state, do this by copying the whole
intel_fb_view struct. For this we make sure the FB view state is fully
inited (that is also including the view type) already during FB
creation, so this init is not required during atomic check time. This
also means the we don't need to reset the unused color plane info during
atomic check, as these are already reset during FB creation.
I noticed that initial FBs will only work atm if they are page aligned
(which BIOS most probably always ensures), but add a comment to sanitize
this part once. Also we won't disable the plane if
get_initial_plane_config() failed for some reason (for instance due to
unsupported rotation), add a TODO: comment for this too.
Imre Deak [Thu, 25 Mar 2021 21:48:00 +0000 (23:48 +0200)]
drm/i915: Store the normal view FB pitch in FB's intel_fb_view
Instead of special casing getting the pitch for the normal view, store
it during FB creation to the FB normal view struct and retrieve it from
there during atomic check, as it's done for the rotated view. A
follow-up patch does the same for a new FB remapped view.
Imre Deak [Sat, 27 Mar 2021 22:09:10 +0000 (00:09 +0200)]
drm/i915: Unify the FB and plane state view information into one struct
To allow the simplification of FB/plane view computation in the
follow-up patches, unify the corresponding state in the
intel_framebuffer and intel_plane_state structs into a new intel_fb_view
struct.
This adds some overhead to intel_framebuffer as the rotated view will
have now space for 4 color planes instead of the required 2 and it'll
also contain the unused offset for each color_plane info. Imo this is an
acceptable trade-off to get a simplified way of the remap computation.
Use the new intel_fb_view struct for the FB normal view as well, so (in
the follow-up patches) we can remove the special casing for normal view
calculation wrt. the calculation of remapped/rotated views. This also
adds an overhead to the intel_framebuffer struct, as the gtt remap info
and per-color plane offset/pitch is not required for the normal view,
but imo this is an acceptable trade-off as above. The per-color plane
pitch filed will be used by a follow-up patch, so we can retrieve the
pitch for each view in the same way.
No functional changes in this patch.
v2:
- Make the patch have _no functional change_.
(fix skl_check_nv12_aux_surface() and skl_check_main_surface()).
- s/i915_color_plane_view::pitch/stride/ (Ville)
Imre Deak [Thu, 25 Mar 2021 21:47:58 +0000 (23:47 +0200)]
drm/i915/intel_fb: Factor out calc_plane_normal_size()
Factor out to a new function the logic to calculate an FB plane's
normal-view size.
Instead of using intel_remapped_plane_info, which is related only to
remapping, add a helper to get the tile pitch and rows for an FB plane,
so these helpers can be used both by the normal size calculation and the
remapping code.
Also add a new fb_plane_view_dims struct in which we can pass around the
view (either FB plane or plane source) and tile dimensions conveniently
to functions calculating further view parameters.
v2:
- Add back the +1 tile adjustment for x!=0 in calc_plane_normal_size(). (Ville)
- s/pages/tiles/ in calc_plane_normal_size(). (Ville)
- Add a helper for the plane view width calculation. (Ville)
- Return tiles as unsigned int from calc_plane_normal_size().
Imre Deak [Thu, 25 Mar 2021 21:47:57 +0000 (23:47 +0200)]
drm/i915/intel_fb: Factor out calc_plane_aligned_offset()
Factor out to a new function the logic to convert the FB plane x/y
values to a tile size based offset and new x/y relative to this offset.
This makes intel_fill_fb_info() and intel_plane_remap_gtt() somewhat
more readable.
Imre Deak [Thu, 25 Mar 2021 21:47:56 +0000 (23:47 +0200)]
drm/i915/intel_fb: Factor out convert_plane_offset_to_xy()
Factor out to a new function the logic to convert the FB plane offset to
x/y and check the validity of x/y, with the goal to make
intel_fill_fb_info() more readable.
v2: Use &fb->base instead of a drm_fb alias. (Ville)
Imre Deak [Thu, 25 Mar 2021 21:47:53 +0000 (23:47 +0200)]
drm/i915/intel_fb: Pull FB plane functions from intel_display.c
Move the FB plane specific functions from intel_display.c to intel_fb.c.
There's more functions like this, but I leave moving those as well for a
follow up, and for now moving only the ones needed by the end of this
patchset (adding support for padding tile-rows in an FB GGTT view).
Imre Deak [Thu, 25 Mar 2021 21:47:48 +0000 (23:47 +0200)]
drm/i915/selftest: Make sure to init i915_ggtt_view in igt_vma_rotate_remap()
This probably doesn't cause an issue, since the code checks the view
type dependent size of the views before comparing them, but let's follow
the practice to bzero the whole struct when initializing it.
v2: Use {} instead of { } struct intializer. (Ville)
Imre Deak [Thu, 25 Mar 2021 21:47:47 +0000 (23:47 +0200)]
drm/i915: Make sure i915_ggtt_view is inited when creating an FB
This probably doesn't cause an issue, since the code checks the view
type dependent size of the views before comparing them, but let's follow
the practice to bzero the whole struct when initializing it.
Imre Deak [Thu, 25 Mar 2021 21:47:44 +0000 (23:47 +0200)]
drm/i915: Fix rotation setup during plane HW readout
The HW plane state is cleared and inited after we store the rotation to
it, so store it instead to the uapi state to match what we do with all
other plane state until intel_plane_copy_uapi_to_hw_state() is called.
Rotation for initial FBs is not supported atm, but let's still fix the
plane state setup here.
While at it remove the redundant intel_state->uapi.src/dst init, which
will be done in intel_plane_copy_uapi_to_hw_state().
Ville Syrjälä [Thu, 25 Mar 2021 00:44:15 +0000 (02:44 +0200)]
drm/i915: Stop adding planes to the commit needlessly
The dbuf bandwidth calculations don't need the planes to be
added to the state. Each plane's data rate has already been
precalculated and stored in the crtc state, and that with
the dbuf slice usage for each plane is all the dbuf bandwidth
code needs to figure out what the minimum cdclk is.
What we're trying to do here is make sure each plane recalculates
its minimum cdclk (ie. plane->min_cdclk()) on those platforms where
the number of active planes affects the result of said calculation.
Nothing to do with any dbuf cdclk requirements.
Not sure if we had stuff in slightly different order or what,
but at least in the current scheme this is not necessary.
Paul Cercueil [Sat, 27 Mar 2021 11:57:42 +0000 (11:57 +0000)]
drm/ingenic: Register devm action to cleanup encoders
Since the encoders have been devm-allocated, they will be freed way
before drm_mode_config_cleanup() is called. To avoid use-after-free
conditions, we then must ensure that drm_encoder_cleanup() is called
before the encoders are freed.
v2: Use the new __drmm_simple_encoder_alloc() function
v3: Use the new drmm_plain_simple_encoder_alloc() macro
Paul Cercueil [Sat, 27 Mar 2021 11:57:41 +0000 (11:57 +0000)]
drm/encoder: Add macro drmm_plain_encoder_alloc()
This performs the same operation as drmm_encoder_alloc(), but
only allocates and returns a struct drm_encoder instance.
v4: Rename macro drmm_plain_encoder_alloc() and move to
<drm/drm_encoder.h>. Since it's not "simple" anymore it
will now take funcs/name arguments as well.
Paul Cercueil [Sat, 27 Mar 2021 11:57:40 +0000 (11:57 +0000)]
drm: bridge/panel: Cleanup connector on bridge detach
If we don't call drm_connector_cleanup() manually in
panel_bridge_detach(), the connector will be cleaned up with the other
DRM objects in the call to drm_mode_config_cleanup(). However, since our
drm_connector is devm-allocated, by the time drm_mode_config_cleanup()
will be called, our connector will be long gone. Therefore, the
connector must be cleaned up when the bridge is detached to avoid
use-after-free conditions.
v2: Cleanup connector only if it was created
v3: Add FIXME
v4: (Use connector->dev) directly in if() block
Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.") Cc: <stable@vger.kernel.org> # 4.12+ Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210327115742.18986-2-paul@crapouillou.net
Jani Nikula [Fri, 26 Mar 2021 13:21:33 +0000 (15:21 +0200)]
drm/i915: add new helpers for accessing stepping info
Add new runtime info field for stepping. Add new helpers for accessing
them. As we'll be switching platforms over to the new scheme
incrementally, check for non-initialized steppings.
In case a platform does not have separate display and gt steppings, it's
okay to use a common shorthand. However, in this case the display
stepping must not be initialized, and gt stepping is the single point of
truth.
Jani Nikula [Fri, 26 Mar 2021 13:21:32 +0000 (15:21 +0200)]
drm/i915: split out stepping info to a new file
gt/intel_workarounds.c is decidedly the wrong place for handling
stepping info. Add new intel_step.[ch] for the data, and move the
stepping arrays there. No functional changes.
Christian König [Wed, 24 Mar 2021 12:50:56 +0000 (13:50 +0100)]
drm/ttm: switch back to static allocation limits for now
The shrinker based approach still has some flaws. Especially that we need
temporary pages to free up the pages allocated to the driver is problematic
in a shrinker.
Eryk Brol [Thu, 25 Mar 2021 18:06:14 +0000 (14:06 -0400)]
drm/mst: Enhance MST topology logging
[why]
MST topology print was missing fec logging and pdt printed
as an int wasn't clear. vcpi and payload info was printed as an
arbitrary series of ints which requires user to know the ordering
of the prints, making the logs difficult to use.
[how]
-add fec logging
-add pdt parsing into strings
-format vcpi and payload info into tables with headings
-clean up topology prints Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Eryk Brol <eryk.brol@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210325180614.37060-1-eryk.brol@amd.com
UAPI:
- amdgpu: Add a new INFO ioctl interface to query video capabilities
rather than hardcoding them in userspace. This allows us to provide
fine grained asic capabilities (e.g., if a particular part is
bandwidth limited, we can limit the capabilities). Proposed userspace:
https://gitlab.freedesktop.org/leoliu/drm/-/commits/info_video_caps
https://gitlab.freedesktop.org/leoliu/mesa/-/commits/info_video_caps
- amdkfd: bump the driver version. There was a problem with reporting
some RAS features on older versions of the driver. Proposed userspace:
https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/commit/7cdd63475c36bb9f49bb960f90f9a8cdb7e80a21
Danvet: A bunch of conflicts all over, but it seems to compile ... I
did put the call to dc_allow_idle_optimizations() on a single line
since it looked a bit too jarring to be left alone.
projects / kernel.git / log