OSDN Git Service
Imre Deak [Thu, 14 Apr 2022 21:06:45 +0000 (00:06 +0300)]
drm/i915: Rename the power domain names to end with pipes/ports
Make all power domain names end with the pipe/port instance for
consistency.
No functional changes.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-6-imre.deak@intel.com
Imre Deak [Thu, 14 Apr 2022 21:06:44 +0000 (00:06 +0300)]
drm/i915: Move the HSW power well flags to a common bitfield
Save some space by grouping the HSW power well descriptor flags along
with other flags in one bitfield.
This change also lets simplifying the definition of power well
descriptors sharing the same flags in an upcoming patch.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-5-imre.deak@intel.com
Imre Deak [Thu, 14 Apr 2022 21:06:43 +0000 (00:06 +0300)]
drm/i915: Move the dg2 fixed_enable_delay power well param to a common bitfield
The DG2 fixed delay duration is always 600usec, so save some space in
the power well descriptors by converting the parameter to a flag. While
at it also use a bitfield for both the always_on and fixed_enable_delay
flag.
This change also lets simplifying the definiton of power wells sharing
the same flags in an upcoming patch.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-4-imre.deak@intel.com
Imre Deak [Thu, 14 Apr 2022 21:06:42 +0000 (00:06 +0300)]
drm/i915: Move the power domain->well mappings to intel_display_power_map.c
Move the list of platform specific power domain -> power well
definitions to intel_display_power_map.c. While at it group the
platforms' power domain macros with the corresponding power well lists
and keep all the power domain lists in the same order (matching the enum
order).
No functional changes.
v2:
- s/intel_display_power_internal.h/intel_display_power_map.h/ (Jani)
- Simplify intel_cleanup_power_wells().
- Don't move intel_display_power_domain_str().
v3:
- Rename intel_init/cleanup_power_wells() to
intel_display_power_map_init/cleanup().
- Add documentation to intel_display_power_map_init/cleanup().
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-3-imre.deak@intel.com
Imre Deak [Thu, 14 Apr 2022 21:06:41 +0000 (00:06 +0300)]
drm/i915: Unexport the for_each_power_well() macros
The for_each_power_well() macros are only used in intel_display_power.c
and intel_display_power_well.c, so unexport them.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-2-imre.deak@intel.com
Imre Deak [Thu, 14 Apr 2022 21:06:40 +0000 (00:06 +0300)]
drm/i915: Move per-platform power well hooks to intel_display_power_well.c
Move the implementation of platform specific power well hooks to
intel_display_power_well.c, to reduce the clutter in
intel_display_power.c.
The locking of all the power domain/power well state is handled in the
power domain functions in intel_display_power.c using
i915_power_domains::lock. This patch also moves the
chy_phy_powergate_ch/lanes() functions to intel_display_power_well.c
which borrow the same lock to protect the DISPLAY_PHY_CONTROL register
state, which the HW uses both for toggling power wells and power gating
PHY lanes.
No functional change.
v2:
- Clarify in the commit log why CHV functions using the
i915_power_domains::lock were moved, while others locking the power
domain/well state were kept in intel_display_power.c . (Jouni)
- Move forward declaration of chv_phy_powergate_ch/lanes() to
intel_display_power_well.h .
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-1-imre.deak@intel.com
José Roberto de Souza [Tue, 19 Apr 2022 18:27:52 +0000 (11:27 -0700)]
drm/i915/display: Add workaround
22014263786
This workaround fixes screen flickers with FBC.
BSpec: 33450
BSpec: 52890
BSpec: 54369
BSpec: 66624
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220419182753.364237-1-jose.souza@intel.com
Ville Syrjälä [Mon, 21 Mar 2022 19:50:04 +0000 (21:50 +0200)]
drm/i915: Program i830 DPLL FP register later
Follow the new i9xx DPLL FP register programming sequence
introduced in commit
62d66b218386 ("drm/i915: Fold
i9xx_set_pll_dividers() into i9xx_enable_pll()") in the
i830 "power well" code as well. Just for consistency.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220321195006.775-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Vinod Govindapillai [Sun, 17 Apr 2022 09:31:05 +0000 (12:31 +0300)]
drm/i915: program wm blocks to at least blocks required per line
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: Vinod Govindapillai <vinod.govindapillai@intel.com>
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/20220417093105.729014-1-vinod.govindapillai@intel.com
Hans de Goede [Mon, 18 Apr 2022 15:09:36 +0000 (17:09 +0200)]
drm/i915: Fix DISP_POS_Y and DISP_HEIGHT defines
Commit
428cb15d5b00 ("drm/i915: Clean up pre-skl primary plane registers")
introduced DISP_POS_Y and DISP_HEIGHT defines but accidentally set these
their masks to REG_GENMASK(31, 0) instead of REG_GENMASK(31, 16).
This breaks the primary display pane on at least pineview machines, fix
the mask to fix the primary display pane only showing black.
Tested on an Acer One AO532h with an Intel N450 SoC.
Fixes:
428cb15d5b00 ("drm/i915: Clean up pre-skl primary plane registers")
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220418150936.5499-1-hdegoede@redhat.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Matt Atwood [Mon, 18 Apr 2022 06:21:57 +0000 (11:51 +0530)]
drm/i915/rpl-p: Add PCI IDs
Adding initial PCI ids for RPL-P.
RPL-P behaves identically to ADL-P from i915's point of view.
Changes since V1 :
- SUBPLATFORM ADL_N and RPL_P clash as both are ADLP
based - Matthew R
Bspec: 55376
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com>
Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
[mattrope: Corrected comment formatting to match coding style]
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220418062157.2974665-1-tejaskumarx.surendrakumar.upadhyay@intel.com
José Roberto de Souza [Thu, 14 Apr 2022 15:11:18 +0000 (08:11 -0700)]
drm/i915/display/psr: Clear more PSR state during disable
After commit
805f04d42a6b ("drm/i915/display/psr: Use continuos full
frame to handle frontbuffer invalidations") was merged we started to
get some drm_WARN_ON(&dev_priv->drm, !(tmp & PSR2_MAN_TRK_CTL_ENABLE))
in tests that are executed in pipe B.
This is probably due psr2_sel_fetch_cff_enabled being left set during
PSR disable in the pipe A, so the PSR2_MAN_TRK_CTL write in
intel_psr2_program_trans_man_trk_ctl() is skipped in pipe B and then
we get the warning when actually enabling PSR after planes programing.
We don't get such warnings when running tests in pipe A because
PSR2_MAN_TRK_CTL is only cleared when enabling PSR2 with hardware
tracking.
Was not able to reproduce this issue but cleaning the PSR state
disable will not harm anything at all.
Fixes:
805f04d42a6b ("drm/i915/display/psr: Use continuos full frame to handle frontbuffer invalidations")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5634
Cc: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414151118.21980-2-jose.souza@intel.com
José Roberto de Souza [Thu, 14 Apr 2022 15:11:17 +0000 (08:11 -0700)]
drm/i915/display/psr: Unset enable_psr2_sel_fetch if other checks in intel_psr2_config_valid() fails
If any of the PSR2 checks after intel_psr2_sel_fetch_config_valid()
fails, enable_psr2_sel_fetch will be kept enabled causing problems
in the functions that only checks for it and not for has_psr2.
So here moving the check that do not depend on enable_psr2_sel_fetch
and for the remaning ones jumping to a section that unset
enable_psr2_sel_fetch in case of failure to support PSR2.
Fixes:
6e43e276b8c9 ("drm/i915: Initial implementation of PSR2 selective fetch")
Cc: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414151118.21980-1-jose.souza@intel.com
Ville Syrjälä [Tue, 15 Mar 2022 14:00:01 +0000 (16:00 +0200)]
drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush
Remove the pointless detour via __intel_fbc_post_update() during
frontbuffer flush.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-8-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Tue, 15 Mar 2022 14:00:00 +0000 (16:00 +0200)]
drm/i915/fbc: Introduce intel_fbc_sanitize()
Let's make sure FBC is always disabled when we start to take
over the hardware state.
I suspect this should never really happen, since the only time
when we really should be taking over with the display already
active is when the previous state was progammed by the BIOS,
which likely shouldn't use FBC. This could be driver init,
or S4 resume when the boot kernel doesn't load i915. But I
suppose no harm in keeping this code around for exra safety
since it's quite trivial.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-7-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Tue, 15 Mar 2022 13:59:59 +0000 (15:59 +0200)]
drm/i915/fbc: Remove intel_fbc_global_disable()
By the time intel_fbc_global_disable() gets called during driver
teardown we should have already disabled all the crtcs, so
no way FBC should be enabled at this point.
And I have no idea what the other user (i915_restore_display())
is even trying to achieve.
So let's just throw intel_fbc_global_disable() into the bin.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-6-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Tue, 15 Mar 2022 13:59:58 +0000 (15:59 +0200)]
drm/i915: Remove remaining locks from i9xx plane udpates
Now that fbc no longer nukes while a flip is pending we can
remove the last uncore.lock from the i9xx plane code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-5-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Tue, 15 Mar 2022 13:59:57 +0000 (15:59 +0200)]
drm/i915/fbc: Skip nuke when flip is pending
Don't issue a nuke from frontbuffer flush while a flip is pending.
This avoids the DSPADDR/DSPSURF rmw abuse from the pre-snb nuke
from racing with the DSPADDR/DSPSURF write being performed by
the flip/plane update. The flip itself will already cause the nuke
so a double nuke is redundant.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-4-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Tue, 15 Mar 2022 13:59:56 +0000 (15:59 +0200)]
drm/i915/fbc: Streamline frontbuffer busy bits handling
If the frontbuffer bits say this fbc instance isn't affected just
skip the whole thing.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-3-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Tue, 15 Mar 2022 13:59:55 +0000 (15:59 +0200)]
drm/i915/fbc: Eliminate possible_framebuffer_bits
Not sure what the point of this fbc->possible_frontbuffer_bits is.
And especially don't see why it's returning all the bits when
fbc is not even enabled. So let's just get rid of this and only
say we are interested in the plane's frontbuffer bits when fbc
is actually enabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-2-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Manasi Navare [Thu, 3 Mar 2022 23:32:22 +0000 (15:32 -0800)]
drm/i915/display/vrr: Reset VRR capable property on a long hpd
With some VRR panels, user can turn VRR ON/OFF on the fly from the panel settings.
When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore MSA bit
in the DPCD. Currently the driver parses that onevery HPD but fails to reset
the corresponding VRR Capable Connector property.
Hence the userspace still sees this as VRR Capable panel which is incorrect.
Fix this by explicitly resetting the connector property.
v2: Reset vrr capable if status == connector_disconnected
v3: Use i915 and use bool vrr_capable (Jani Nikula)
v4: Move vrr_capable to after update modes call (Jani N)
Remove the redundant comment (Jan N)
v5: Fixes the regression on older platforms by resetting the VRR
only if HAS_VRR
v6: Remove the checks from driver, add in drm core before
setting VRR prop (Ville)
v7: Move VRR set/reset to set/unset_edid (Ville)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes:
9bc34b4d0f3c ("drm/i915/display/vrr: Reset VRR capable property on a long hpd")
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303233222.4698-1-manasi.d.navare@intel.com
Juha-Pekka Heikkilä [Mon, 11 Apr 2022 14:34:05 +0000 (17:34 +0300)]
drm/i915/dg2: Add support for DG2 clear color compression
Add support for the DG2 specific render compression with clear color
framebuffer format.
DG2 onwards discrete gfx has support for new flat CCS mapping,
which brings in display feature in to avoid Aux walk for compressed
surface. This support build on top of Flat CCS support added in XEHPSDV.
FLAT CCS surface base address should be 64k aligned,
Compressed displayable surfaces must use tile4 format.
HAS:
1407880786
B.Spec : 7655
B.Spec : 53902
v2: Merge all bits required for the support of functionality into this
patch from the patch adding the corresponding modifier.
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220411143405.1073845-5-imre.deak@intel.com
Mika Kahola [Mon, 11 Apr 2022 14:34:04 +0000 (17:34 +0300)]
drm/fourcc: Introduce format modifier for DG2 clear color
DG2 clear color render compression uses Tile4 layout. Therefore, we need
to define a new format modifier for uAPI to support clear color rendering.
v2:
Display version is fixed. [Imre]
KDoc is enhanced for cc modifier. [Nanley & Lionel]
v3:
Split out the modifier addition to a separate patch.
Clarify the modifier layout description.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
cc: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220411143405.1073845-4-imre.deak@intel.com
Matt Roper [Mon, 11 Apr 2022 14:34:03 +0000 (17:34 +0300)]
drm/i915/dg2: Add support for DG2 render and media compression
Add support for DG2 render and media compression, for the description of
buffer layouts see the previous patch adding the corresponding
frame buffer modifiers.
v2:
Display version fix [Imre]
v3:
Split out modifier addition to separate patch.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
cc: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220411143405.1073845-3-imre.deak@intel.com
Matt Roper [Mon, 11 Apr 2022 14:34:02 +0000 (17:34 +0300)]
drm/fourcc: Introduce format modifiers for DG2 render and media compression
The render/media engines on DG2 unify render compression and media
compression into a single format for the first time, using the Tile 4
layout for main surfaces. The compression algorithm is different from
any previous platform and the display engine must still be configured to
decompress either a render or media compressed surface; as such, we
need new RC and MC framebuffer modifiers to represent buffers in this
format.
v2: Clarify modifier layout description.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220411143405.1073845-2-imre.deak@intel.com
Ville Syrjälä [Tue, 5 Apr 2022 17:33:54 +0000 (20:33 +0300)]
drm/i915/bios: Validate the panel_name table
In addition to the fp_timing,dvo_timing,panel_pnp_id tables
there also exists a panel_name table. Unlike the others this
is just one offset+table_size even though there are still 16
actual panel_names in the data block.
The panel_name table made its first appearance somewhere
around VBT version 156-163. The exact version is not known.
But we don't need to know that since we can just check whether
the pointers block has enough room for it or not.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220405173410.11436-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 5 Apr 2022 17:33:53 +0000 (20:33 +0300)]
drm/i915/bios: Trust the LFP data pointers
Now that we've sufficiently validated the LFP data pointers we
can trust them.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220405173410.11436-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 5 Apr 2022 17:33:52 +0000 (20:33 +0300)]
drm/i915/bios: Validate LFP data table pointers
Make sure the LFP data table pointers sane. Sensible looking
table entries, everything points correctly into the data block,
etc.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220405173410.11436-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 5 Apr 2022 17:33:51 +0000 (20:33 +0300)]
drm/i915/bios: Use the copy of the LFP data table always
Currently get_lvds_fp_timing() still returns a pointer to the original
data block rather than our copy. Let's convert the data pointer offsets
to be relative to the data block rather than the whole BDB. With that
we can make get_lvds_fp_timing() return a pointer to the copy.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220405173410.11436-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Wed, 6 Apr 2022 13:38:17 +0000 (16:38 +0300)]
drm/i915/bios: Make copies of VBT data blocks
Make a copy of each VBT data block with a guaranteed minimum
size. The extra (if any) will just be left zeroed.
This means we don't have to worry about going out of bounds
when accessing any of the structure members. Otherwise that
could easliy happen if we simply get the version check wrong,
or if the VBT is broken/malicious.
v2: Don't do arithmetic between bdb header and copy
of the LFP data block (Jani)
v3: Make all the copies up front
v4: Only WARN about min_size==0 if we found the block
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220406133817.30652-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 5 Apr 2022 17:33:49 +0000 (20:33 +0300)]
drm/i915/bios: Use the cached BDB version
We have the BDB version cached, use it. We're going to have to
start doing some of the BDB block parsing later, at which point
we may no longer have the VBT around anymore (we free it at the
end of intel_bios_init() when it didn't come via OpRegion).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220405173410.11436-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Lucas De Marchi [Sun, 10 Apr 2022 06:15:36 +0000 (23:15 -0700)]
drm/i915/dg2: Do not explode on phy calibration error
When the PHY fails on calibration we were previously skipping the ddi
initialization. However the driver is not really prepared for that,
ultimately leading to a NULL pointer dereference:
[ 75.748348] i915 0000:03:00.0: [drm:intel_modeset_init_nogem [i915]] SNPS PHY A failed to calibrate; output will not be used.
...
[ 75.750336] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [CRTC:80:pipe A] hw state readout: enabled
...
( no DDI A/PHY A )
[ 75.753080] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [ENCODER:235:DDI B/PHY B] hw state readout: disabled, pipe A
[ 75.753164] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [ENCODER:245:DDI C/PHY C] hw state readout: disabled, pipe A
...
[ 75.754425] i915 0000:03:00.0: [drm] *ERROR* crtc 80: Can't calculate constants, dotclock = 0!
[ 75.765558] i915 0000:03:00.0: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev))
[ 75.765569] WARNING: CPU: 5 PID: 1759 at drivers/gpu/drm/drm_vblank.c:728 drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x347/0x360
...
[ 75.781230] BUG: kernel NULL pointer dereference, address:
000000000000007c
[ 75.788198] #PF: supervisor read access in kernel mode
[ 75.793347] #PF: error_code(0x0000) - not-present page
[ 75.798480] PGD 0 P4D 0
[ 75.801019] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 75.805377] CPU: 5 PID: 1759 Comm: modprobe Tainted: G W 5.18.0-rc1-demarchi+ #199
[ 75.827613] RIP: 0010:icl_aux_power_well_disable+0x3b/0x200 [i915]
[ 75.833890] Code: 83 ec 30 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 48 8b 06 0f b6 70 1c f6 40 20 04 8d 56 fa 0f 45 f2 e8 88 bd ff ff 48 89 ef <8b> 70 7c e8 ed 67 ff ff 48 89 ef 89 c6 e8 73 67 ff ff 84 c0 75 0a
[ 75.852629] RSP: 0018:
ffffc90003a7fb30 EFLAGS:
00010246
[ 75.857852] RAX:
0000000000000000 RBX:
ffff8881145e8f10 RCX:
0000000000000000
[ 75.864978] RDX:
ffff888115220840 RSI:
0000000000000000 RDI:
ffff888115220000
[ 75.872106] RBP:
ffff888115220000 R08:
ffff88888effffe8 R09:
00000000fffdffff
[ 75.879234] R10:
ffff88888e200000 R11:
ffff88888ed00000 R12:
ffff8881145e8f10
[ 75.886363] R13:
0000000000000001 R14:
ffff888115223240 R15:
0000000000000000
[ 75.893490] FS:
00007ff6e753a740(0000) GS:
ffff88888f680000(0000) knlGS:
0000000000000000
[ 75.901573] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 75.907313] CR2:
000000000000007c CR3:
00000001216a6001 CR4:
0000000000770ee0
[ 75.914446] PKRU:
55555554
[ 75.917153] Call Trace:
[ 75.919603] <TASK>
[ 75.921709] intel_power_domains_sanitize_state+0x88/0xb0 [i915]
[ 75.927814] intel_modeset_init_nogem+0x317/0xef0 [i915]
[ 75.933205] i915_driver_probe+0x5f6/0xdf0 [i915]
[ 75.937976] i915_pci_probe+0x51/0x1d0 [i915]
We skip the initialization of PHY A, but later we try to find out what
is the phy for that power well and dereference dig_port, which is NULL.
Failing the PHY calibration could be left as a warning or error, like it
was before commit
b4eb76d82a0e ("drm/i915/dg2: Skip output init on PHY
calibration failure"). However that often fails for outputs not being
used, which would make the warning/error appear on systems that have no
visible issues. Anyway, there is still a need to fix those failures,
but that is left for later.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220410061537.4187383-1-lucas.demarchi@intel.com
Stanislav Lisovskiy [Mon, 11 Apr 2022 08:13:43 +0000 (11:13 +0300)]
drm/i915: Swap ret and status returned from skl_pcode_request
If ret isn't zero, it is almost for sure ETIMEDOUT, because
we use it in wait_for macro which does continuous retries
until timeout is reached. If we still ran out of time and
retries, we most likely would be interested in getting status,
to understand what was the actual error propagated from PCode,
rather than to find out that we had a time out, which is anyway
quite obvious, if the function fails.
v2: Make it status ? status : ret(thanks Vinod for the hint)
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220411081343.18099-1-stanislav.lisovskiy@intel.com
Stanislav Lisovskiy [Fri, 8 Apr 2022 12:51:59 +0000 (15:51 +0300)]
drm/i915: Fix skl_pcode_try_request function
Currently skl_pcode_try_request function doesn't
properly handle return value it gets from
snb_pcode_rw, but treats status != 0 as success,
returning true, which basically doesn't allow
to use retry/timeout mechanisms if PCode happens
to be busy and returns EGAIN or some other status
code not equal to 0.
We saw this on real hw and also tried simulating this
by always returning -EAGAIN from snb_pcode_rw for 6 times, which
currently will just result in false success, while it should
have tried until timeout is reached:
[ 22.357729] i915 0000:00:02.0: [drm:intel_cdclk_dump_config [i915]] Changing CDCLK to
307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0
[ 22.357831] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 1
[ 22.357892] i915 0000:00:02.0: [drm:skl_pcode_request [i915]] Success, exiting
[ 22.357936] i915 0000:00:02.0: [drm] ERROR Failed to inform PCU about cdclk change (err -11, freq 307200)
We see en error because higher level api, still notices that status was wrong,
however we still did try only once.
We fix it by requiring _both_ the status to be 0 and
request/reply match for success(true) and function
should return failure(false) if either status turns
out to be EAGAIN, EBUSY or whatever or reply/request
masks do not match.
So now we see this in the logs:
[ 22.318667] i915 0000:00:02.0: [drm:intel_cdclk_dump_config [i915]] Changing CDCLK to
307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0
[ 22.318782] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 1
[ 22.318849] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 2
[ 22.319006] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 3
[ 22.319091] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 4
[ 22.319158] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 5
[ 22.319224] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 6
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220408125200.9069-2-stanislav.lisovskiy@intel.com
Jani Nikula [Mon, 11 Apr 2022 13:01:56 +0000 (16:01 +0300)]
Merge drm/drm-next into drm-intel-next
Sync up with v5.18-rc1, in particular to get
5e3094cfd9fb
("drm/i915/xehpsdv: Add has_flat_ccs to device info").
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Lucas De Marchi [Fri, 8 Apr 2022 16:48:37 +0000 (09:48 -0700)]
drm/i915/uncore: Warn only if unclaimed access remains flagged
Commit
4b276ed3c7ac ("drm/i915/uncore: Warn on previous unclaimed
accesses") tried to improve our report of unclaimed register access,
however it unveiled cases that were not previously causing any harm.
Downgrade the first message to debug so we can still see them and
eventually fix, but don't warn.
Fixes:
4b276ed3c7ac ("drm/i915/uncore: Warn on previous unclaimed accesses")
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220408164837.3845786-1-lucas.demarchi@intel.com
José Roberto de Souza [Wed, 6 Apr 2022 21:05:40 +0000 (14:05 -0700)]
drm/i915/display: Fix warnings about PSR lock not held
Commit
3b6f409547fb ("drm/i915/display/psr: Lock and unlock PSR around
pipe updates") did not took into account async flips with PSR1 and
PSR2 HW tracking, causing PSR lock not be held and causing warnings
when intel_psr2_program_trans_man_trk_ctl() is executed.
So here taking the PSR lock before the earlier return in
intel_pipe_update_start/end().
Cc: Jouni Högander <jouni.hogander@intel.com>
Reported-by: Imre Deak <imre.deak@intel.com>
Fixes:
3b6f409547fb ("drm/i915/display/psr: Lock and unlock PSR around pipe updates")
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220406210540.493610-1-jose.souza@intel.com
Lucas De Marchi [Tue, 5 Apr 2022 00:11:49 +0000 (17:11 -0700)]
drm/i915/uncore: Warn on previous unclaimed accesses
Since gen6 we use FPGA_DBG register to detect unclaimed MMIO registers.
This register is in the display engine IP and can only ever detect
unclaimed accesses to registers in this area. However sometimes there
are reports of this triggering for registers in other areas, which
should not be possible.
Right now we always warn after the read/write of registers going through
unclaimed_reg_debug(). However places using __raw_uncore_* may be
triggering the unclaimed access and those being later accounted to a
different register. Let's warn both before and after the read/write
with a slightly different message, so it's clear if the register
reported in the warning is actually the culprit.
Commit
dda960335e02 ("drm/i915: Just clear the mmiodebug before a
register access") attempted to solve the same issue by removing the
warning when if FPGA_DBG flags before the mmio read/write. However, it
doesn't solve it completely as FPGA_DBG may remain set when reading
registers outside display. So in the end the check after the mmio
read/write triggers the warning pointing to the wrong register.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220405001149.2675226-1-lucas.demarchi@intel.com
Imre Deak [Wed, 23 Mar 2022 20:17:49 +0000 (22:17 +0200)]
drm/i915/adlp: Fix register corruption after DDI clock enabling
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: Imre Deak <imre.deak@intel.com>
Acked-by: Arthur J Runyan <arthur.j.runyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323201749.288566-1-imre.deak@intel.com
Casey Bowman [Thu, 31 Mar 2022 20:43:43 +0000 (13:43 -0700)]
drm/i915: Split i915_run_as_guest into x86 and non-x86
Split i915_run_as_guest() into a more arch-friendly function
as non-x86 builds do not support this functionality.
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220331204343.1256150-2-casey.g.bowman@intel.com
José Roberto de Souza [Tue, 5 Apr 2022 15:53:44 +0000 (08:53 -0700)]
drm/i915/display/psr: Use continuos full frame to handle frontbuffer invalidations
Instead of exit PSR when a frontbuffer invalidation happens, we can
enable the PSR2 selective fetch continuous full frame, that will keep
the panel updated like PSR was disabled but without keeping PSR active.
So as soon as the frontbuffer flush happens we can disable the
continuous full frame and start to do selective fetches much quicker
than the path that would enable PSR, that will wait a few frames
to actually activate PSR.
Also this approach has proven to fix some glitches found in Alderlake-P
when there are a lot of invalidations happening together with page
flips.
Some may ask why it is writing to CURSURFLIVE(), it is because
that is the way that hardware team provided us to poke display to
handle PSR updates, and it is being used since display 9.
v2:
- handling possible race conditions between frontbuffer rendering and
page flips
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Cc: Khaled Almahallawy <khaled.almahallawy@intel.com>
Cc: Shawn C Lee <shawn.c.lee@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220405155344.47219-3-jose.souza@intel.com
José Roberto de Souza [Tue, 5 Apr 2022 15:53:43 +0000 (08:53 -0700)]
drm/i915/display/psr: Lock and unlock PSR around pipe updates
Frontbuffer rendering and page flips can race with each other
and this can potentialy cause issues with PSR2 selective fetch.
And because pipe/crtc updates are time sentive we can't grab the
PSR lock after intel_pipe_update_start() and before
intel_pipe_update_end().
So here adding the lock and unlock functions and calls, the
proper PSR2 selective fetch handling will come in a separated patch.
v2:
- fixed new functions documentation
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220405155344.47219-2-jose.souza@intel.com
José Roberto de Souza [Tue, 5 Apr 2022 15:53:42 +0000 (08:53 -0700)]
drm/i915/display/psr: Set partial frame enable when forcing full frame fetch
Following up what was done in commit
804f46885317 ("drm/i915/psr: Set
"SF Partial Frame Enable" also on full update") and also setting
partial frame enable when psr_force_hw_tracking_exit() is called.
Also as PSR2_MAN_TRK_CTL is a double buffered registers do a RMW
is not a good idea so here also setting the man_trk_ctl_enable_bit()
that is required in TGL and only doing a register write.
v2:
- not doing a rmw
v3:
- removing the inline from functions that return PSR2_MAN_TRK_CTL
bits
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220405155344.47219-1-jose.souza@intel.com
Ashutosh Dixit [Mon, 14 Mar 2022 16:13:10 +0000 (09:13 -0700)]
drm/i915/pmu: Drop redundant IS_VALLEYVIEW check in __get_rc6()
Because VLV_GT_RENDER_RC6 == GEN6_GT_GFX_RC6, the IS_VALLEYVIEW() check is
not needed. Neither is the check present in other code paths which call
intel_rc6_residency_ns() (in functions gen6_drpc(), rc6_residency() and
rc6_residency_ms_show()).
v2: Elimintate VLV_GT_RENDER_RC6 #define (Jani)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Badal Nilawar <badal.nilawar@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220314161310.6468-1-ashutosh.dixit@intel.com
Animesh Manna [Fri, 25 Mar 2022 16:11:40 +0000 (21:41 +0530)]
drm/i915/dsb: modified to drm_info in dsb_prepare()
The request to aqquire gem resources is failing for DSB in rare
scenario where it is busy and the register programming will be done
through mmio fallback path.
DSB has extra advantage of faster register programming which may
go away through mmio path. Adding wait for gem resource also may
not be right as anyways losing time.
To make the CI execution happy replaced drm_err() to drm_info()
for printing debug info during dsb buffer preparation.
v1: Initial version.
v2: Added print for mmio fallback at out label. [Nirmoy]
v3: Improved debug message. [Nirmoy]
Cc: Nirmoy Das <nirmoy.das@linux.intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220325161140.11906-1-animesh.manna@intel.com
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Ville Syrjälä [Tue, 22 Mar 2022 12:00:14 +0000 (14:00 +0200)]
drm/i915/dp: Fix DFP rgb->ycbcr conversion matrix
Our YCbCr output is always supposed to be limited range BT.709.
That's what we send with native HDMI. The conn_state->colorspace
stuff is entirely independent of that and is not supposed to alter
the generated output in any way. If we want a way to do that then
we need a new proprty for it.
Make it so that the RGB->YCbCr conversion when performed by the
DPF will match the BT.709 we would transmit with native HDMI.
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-12-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Tue, 22 Mar 2022 12:00:13 +0000 (14:00 +0200)]
drm/i915/dp: Duplicate native HDMI TMDS clock limit handling for DP HDMI DFPs
With native HDMI we allow the user to override the mode with
something that may not respect the downstream (sink,dual-mode adapter)
TMDS clock limits. Let's reuse the same logic for DP HDMI DFPs
so that behaviour is more or less uniform.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-11-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Tue, 22 Mar 2022 12:00:12 +0000 (14:00 +0200)]
drm/i915/dp: Add support for "4:2:0 also" modes for DP
Currently we only support "4:2:0 also" modes on native HDMI.
Extend that support for DP as well.
With all the HDMI DFP TMDS clock handling sorted out this
is now going to work for both native DP and DP->HDMI
converters. As with native HDMI we first check if RGB
output is possible, and if not we try YCbCr 4:2:0 instead.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-10-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Tue, 22 Mar 2022 12:00:11 +0000 (14:00 +0200)]
drm/i915/dp: Rework HDMI DFP TMDS clock handling
Rework the HDMI DFP TMDS clock checks to also check at 8bpc.
Previously we only checked the deep color cases. But I suppose
a sink could potentially declare "4:2:0 also" modes that only
actually fit within its own limits when using 4:2:0. Even if
that is too nuts to be real there is no real harm in running
through the full checks for everything.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-9-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Tue, 22 Mar 2022 12:00:10 +0000 (14:00 +0200)]
drm/i915/dp: Make intel_dp_output_format() usable for "4:2:0 also" modes
Hoist the drm_mode_is_420_only() from intel_dp_output_format()
into the caller. This will allow intel_dp_output_format() to be
reused for "4:2:0 also" modes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-8-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Tue, 22 Mar 2022 12:00:09 +0000 (14:00 +0200)]
drm/i915/dp: Pass around intel_connector rather than drm_connector
Prefer to use intel_connector over drm_connector. Also clean
up the related variable names a bit.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-7-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Tue, 22 Mar 2022 12:00:08 +0000 (14:00 +0200)]
drm/i915/dp: Reorder intel_dp_compute_config() a bit
Consolidate the double pfit call, and reorder things so that
intel_dp_output_format() and intel_dp_compute_link_config() are
back-to-back. They are intimately related, and will need to be
called twice to properly handle the "4:2:0 also" modes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-6-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Tue, 22 Mar 2022 12:00:07 +0000 (14:00 +0200)]
drm/i915/dp: s/intel_dp_hdmi_ycbcr420/intel_dp_is_ycbcr420/
intel_dp_hdmi_ycbcr420() does account for native DP 4:2:0
output as well, so lets rename it a bit.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-5-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Tue, 22 Mar 2022 12:00:06 +0000 (14:00 +0200)]
drm/i915/dp: Extract intel_dp_has_audio()
Declutter intel_dp_compute_config() a bit by moving the
has_audio computation into a helper. HDMI already does the same thing.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-4-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Tue, 22 Mar 2022 12:00:05 +0000 (14:00 +0200)]
drm/i915/dp: Respect the sink's max TMDS clock when dealing with DP->HDMI DFPs
Currently we only look at the DFPs max TMDS clock limit when
considering whether the mode is valid, or whether we can do
deep color. The sink's max TMDS clock limit may be lower than
the DFPs, so we need to account for it as well.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4095
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2844
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-3-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Tue, 22 Mar 2022 12:00:04 +0000 (14:00 +0200)]
drm/i915/dp: Extract intel_dp_tmds_clock_valid()
We're currently duplicating the DFP min/max TMDS clock checks
in .mode_valid() and .compute_config(). Extract a helper suitable
for both use cases.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-2-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Thu, 17 Mar 2022 17:19:38 +0000 (19:19 +0200)]
drm/i915/bios: Extract struct lvds_lfp_data_ptr_table
All the LFP data table pointers have uniform layout. Turn
that into a struct.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220317171948.10400-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Mon, 21 Mar 2022 19:50:06 +0000 (21:50 +0200)]
drm/i915: Remove dead members from dev_priv
Remove some zombies from our device structure.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220321195006.775-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Mon, 21 Mar 2022 19:50:05 +0000 (21:50 +0200)]
drm/i915: Use drm_connector_attach_hdr_output_metadata_property()
Stop hand rolling drm_connector_attach_hdr_output_metadata_property().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220321195006.775-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Linus Torvalds [Sun, 3 Apr 2022 21:08:21 +0000 (14:08 -0700)]
Linux 5.18-rc1
Linus Torvalds [Sun, 3 Apr 2022 19:26:01 +0000 (12:26 -0700)]
Merge tag 'trace-v5.18-2' of git://git./linux/kernel/git/rostedt/linux-trace
Pull more tracing updates from Steven Rostedt:
- Rename the staging files to give them some meaning. Just
stage1,stag2,etc, does not show what they are for
- Check for NULL from allocation in bootconfig
- Hold event mutex for dyn_event call in user events
- Mark user events to broken (to work on the API)
- Remove eBPF updates from user events
- Remove user events from uapi header to keep it from being installed.
- Move ftrace_graph_is_dead() into inline as it is called from hot
paths and also convert it into a static branch.
* tag 'trace-v5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Move user_events.h temporarily out of include/uapi
ftrace: Make ftrace_graph_is_dead() a static branch
tracing: Set user_events to BROKEN
tracing/user_events: Remove eBPF interfaces
tracing/user_events: Hold event_mutex during dyn_event_add
proc: bootconfig: Add null pointer check
tracing: Rename the staging files for trace_events
Linus Torvalds [Sun, 3 Apr 2022 19:21:14 +0000 (12:21 -0700)]
Merge tag 'clk-for-linus' of git://git./linux/kernel/git/clk/linux
Pull clk fix from Stephen Boyd:
"A single revert to fix a boot regression seen when clk_put() started
dropping rate range requests. It's best to keep various systems
booting so we'll kick this out and try again next time"
* tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
Revert "clk: Drop the rate range on clk_put()"
Linus Torvalds [Sun, 3 Apr 2022 19:15:47 +0000 (12:15 -0700)]
Merge tag 'x86-urgent-2022-04-03' of git://git./linux/kernel/git/tip/tip
Pull x86 fixes from Thomas Gleixner:
"A set of x86 fixes and updates:
- Make the prctl() for enabling dynamic XSTATE components correct so
it adds the newly requested feature to the permission bitmap
instead of overwriting it. Add a selftest which validates that.
- Unroll string MMIO for encrypted SEV guests as the hypervisor
cannot emulate it.
- Handle supervisor states correctly in the FPU/XSTATE code so it
takes the feature set of the fpstate buffer into account. The
feature sets can differ between host and guest buffers. Guest
buffers do not contain supervisor states. So far this was not an
issue, but with enabling PASID it needs to be handled in the buffer
offset calculation and in the permission bitmaps.
- Avoid a gazillion of repeated CPUID invocations in by caching the
values early in the FPU/XSTATE code.
- Enable CONFIG_WERROR in x86 defconfig.
- Make the X86 defconfigs more useful by adapting them to Y2022
reality"
* tag 'x86-urgent-2022-04-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/fpu/xstate: Consolidate size calculations
x86/fpu/xstate: Handle supervisor states in XSTATE permissions
x86/fpu/xsave: Handle compacted offsets correctly with supervisor states
x86/fpu: Cache xfeature flags from CPUID
x86/fpu/xsave: Initialize offset/size cache early
x86/fpu: Remove unused supervisor only offsets
x86/fpu: Remove redundant XCOMP_BV initialization
x86/sev: Unroll string mmio with CC_ATTR_GUEST_UNROLL_STRING_IO
x86/config: Make the x86 defconfigs a bit more usable
x86/defconfig: Enable WERROR
selftests/x86/amx: Update the ARCH_REQ_XCOMP_PERM test
x86/fpu/xstate: Fix the ARCH_REQ_XCOMP_PERM implementation
Linus Torvalds [Sun, 3 Apr 2022 19:08:26 +0000 (12:08 -0700)]
Merge tag 'core-urgent-2022-04-03' of git://git./linux/kernel/git/tip/tip
Pull RT signal fix from Thomas Gleixner:
"Revert the RT related signal changes. They need to be reworked and
generalized"
* tag 'core-urgent-2022-04-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
Revert "signal, x86: Delay calling signals in atomic on RT enabled kernels"
Linus Torvalds [Sun, 3 Apr 2022 17:31:00 +0000 (10:31 -0700)]
Merge tag 'dma-mapping-5.18-1' of git://git.infradead.org/users/hch/dma-mapping
Pull more dma-mapping updates from Christoph Hellwig:
- fix a regression in dma remap handling vs AMD memory encryption (me)
- finally kill off the legacy PCI DMA API (Christophe JAILLET)
* tag 'dma-mapping-5.18-1' of git://git.infradead.org/users/hch/dma-mapping:
dma-mapping: move pgprot_decrypted out of dma_pgprot
PCI/doc: cleanup references to the legacy PCI DMA API
PCI: Remove the deprecated "pci-dma-compat.h" API
Linus Torvalds [Sun, 3 Apr 2022 17:17:48 +0000 (10:17 -0700)]
Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm
Pull ARM fixes from Russell King:
- avoid unnecessary rebuilds for library objects
- fix return value of __setup handlers
- fix invalid input check for "crashkernel=" kernel option
- silence KASAN warnings in unwind_frame
* tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm:
ARM: 9191/1: arm/stacktrace, kasan: Silence KASAN warnings in unwind_frame()
ARM: 9190/1: kdump: add invalid input check for 'crashkernel=0'
ARM: 9187/1: JIVE: fix return value of __setup handler
ARM: 9189/1: decompressor: fix unneeded rebuilds of library objects
Stephen Boyd [Sun, 3 Apr 2022 02:28:18 +0000 (19:28 -0700)]
Revert "clk: Drop the rate range on clk_put()"
This reverts commit
7dabfa2bc4803eed83d6f22bd6f045495f40636b. There are
multiple reports that this breaks boot on various systems. The common
theme is that orphan clks are having rates set on them when that isn't
expected. Let's revert it out for now so that -rc1 boots.
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reported-by: Tony Lindgren <tony@atomide.com>
Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Link: https://lore.kernel.org/r/366a0232-bb4a-c357-6aa8-636e398e05eb@samsung.com
Cc: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20220403022818.39572-1-sboyd@kernel.org
Linus Torvalds [Sat, 2 Apr 2022 19:57:17 +0000 (12:57 -0700)]
Merge tag 'perf-tools-for-v5.18-2022-04-02' of git://git./linux/kernel/git/acme/linux
Pull more perf tools updates from Arnaldo Carvalho de Melo:
- Avoid SEGV if core.cpus isn't set in 'perf stat'.
- Stop depending on .git files for building PERF-VERSION-FILE, used in
'perf --version', fixing some perf tools build scenarios.
- Convert tracepoint.py example to python3.
- Update UAPI header copies from the kernel sources: socket,
mman-common, msr-index, KVM, i915 and cpufeatures.
- Update copy of libbpf's hashmap.c.
- Directly return instead of using local ret variable in
evlist__create_syswide_maps(), found by coccinelle.
* tag 'perf-tools-for-v5.18-2022-04-02' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux:
perf python: Convert tracepoint.py example to python3
perf evlist: Directly return instead of using local ret variable
perf cpumap: More cpu map reuse by merge.
perf cpumap: Add is_subset function
perf evlist: Rename cpus to user_requested_cpus
perf tools: Stop depending on .git files for building PERF-VERSION-FILE
tools headers cpufeatures: Sync with the kernel sources
tools headers UAPI: Sync drm/i915_drm.h with the kernel sources
tools headers UAPI: Sync linux/kvm.h with the kernel sources
tools kvm headers arm64: Update KVM headers from the kernel sources
tools arch x86: Sync the msr-index.h copy with the kernel sources
tools headers UAPI: Sync asm-generic/mman-common.h with the kernel
perf beauty: Update copy of linux/socket.h with the kernel sources
perf tools: Update copy of libbpf's hashmap.c
perf stat: Avoid SEGV if core.cpus isn't set
Linus Torvalds [Sat, 2 Apr 2022 19:33:31 +0000 (12:33 -0700)]
Merge tag 'kbuild-fixes-v5.18' of git://git./linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild fixes from Masahiro Yamada:
- Fix empty $(PYTHON) expansion.
- Fix UML, which got broken by the attempt to suppress Clang warnings.
- Fix warning message in modpost.
* tag 'kbuild-fixes-v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
modpost: restore the warning message for missing symbol versions
Revert "um: clang: Strip out -mno-global-merge from USER_CFLAGS"
kbuild: Remove '-mno-global-merge'
kbuild: fix empty ${PYTHON} in scripts/link-vmlinux.sh
kconfig: remove stale comment about removed kconfig_print_symbol()
Linus Torvalds [Sat, 2 Apr 2022 19:14:38 +0000 (12:14 -0700)]
Merge tag 'mips_5.18_1' of git://git./linux/kernel/git/mips/linux
Pull MIPS fixes from Thomas Bogendoerfer:
- build fix for gpio
- fix crc32 build problems
- check for failed memory allocations
* tag 'mips_5.18_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
MIPS: crypto: Fix CRC32 code
MIPS: rb532: move GPIOD definition into C-files
MIPS: lantiq: check the return value of kzalloc()
mips: sgi-ip22: add a check for the return of kzalloc()
Linus Torvalds [Sat, 2 Apr 2022 19:09:02 +0000 (12:09 -0700)]
Merge tag 'for-linus' of git://git./virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
- Only do MSR filtering for MSRs accessed by rdmsr/wrmsr
- Documentation improvements
- Prevent module exit until all VMs are freed
- PMU Virtualization fixes
- Fix for kvm_irq_delivery_to_apic_fast() NULL-pointer dereferences
- Other miscellaneous bugfixes
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (42 commits)
KVM: x86: fix sending PV IPI
KVM: x86/mmu: do compare-and-exchange of gPTE via the user address
KVM: x86: Remove redundant vm_entry_controls_clearbit() call
KVM: x86: cleanup enter_rmode()
KVM: x86: SVM: fix tsc scaling when the host doesn't support it
kvm: x86: SVM: remove unused defines
KVM: x86: SVM: move tsc ratio definitions to svm.h
KVM: x86: SVM: fix avic spec based definitions again
KVM: MIPS: remove reference to trap&emulate virtualization
KVM: x86: document limitations of MSR filtering
KVM: x86: Only do MSR filtering when access MSR by rdmsr/wrmsr
KVM: x86/emulator: Emulate RDPID only if it is enabled in guest
KVM: x86/pmu: Fix and isolate TSX-specific performance event logic
KVM: x86: mmu: trace kvm_mmu_set_spte after the new SPTE was set
KVM: x86/svm: Clear reserved bits written to PerfEvtSeln MSRs
KVM: x86: Trace all APICv inhibit changes and capture overall status
KVM: x86: Add wrappers for setting/clearing APICv inhibits
KVM: x86: Make APICv inhibit reasons an enum and cleanup naming
KVM: X86: Handle implicit supervisor access with SMAP
KVM: X86: Rename variable smap to not_smap in permission_fault()
...
Masahiro Yamada [Fri, 1 Apr 2022 15:56:10 +0000 (00:56 +0900)]
modpost: restore the warning message for missing symbol versions
This log message was accidentally chopped off.
I was wondering why this happened, but checking the ML log, Mark
precisely followed my suggestion [1].
I just used "..." because I was too lazy to type the sentence fully.
Sorry for the confusion.
[1]: https://lore.kernel.org/all/CAK7LNAR6bXXk9-ZzZYpTqzFqdYbQsZHmiWspu27rtsFxvfRuVA@mail.gmail.com/
Fixes:
4a6795933a89 ("kbuild: modpost: Explicitly warn about unprototyped symbols")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Linus Torvalds [Sat, 2 Apr 2022 18:03:03 +0000 (11:03 -0700)]
Merge tag 'for-5.18/drivers-2022-04-02' of git://git.kernel.dk/linux-block
Pull block driver fix from Jens Axboe:
"Got two reports on nbd spewing warnings on load now, which is a
regression from a commit that went into your tree yesterday.
Revert the problematic change for now"
* tag 'for-5.18/drivers-2022-04-02' of git://git.kernel.dk/linux-block:
Revert "nbd: fix possible overflow on 'first_minor' in nbd_dev_add()"
Linus Torvalds [Sat, 2 Apr 2022 17:54:52 +0000 (10:54 -0700)]
Merge tag 'pci-v5.18-changes-2' of git://git./linux/kernel/git/helgaas/pci
Pull pci fix from Bjorn Helgaas:
- Fix Hyper-V "defined but not used" build issue added during merge
window (YueHaibing)
* tag 'pci-v5.18-changes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
PCI: hv: Remove unused hv_set_msi_entry_from_desc()
Linus Torvalds [Sat, 2 Apr 2022 17:44:18 +0000 (10:44 -0700)]
Merge tag 'tag-chrome-platform-for-v5.18' of git://git./linux/kernel/git/chrome-platform/linux
Pull chrome platform updates from Benson Leung:
"cros_ec_typec:
- Check for EC device - Fix a crash when using the cros_ec_typec
driver on older hardware not capable of typec commands
- Make try power role optional
- Mux configuration reorganization series from Prashant
cros_ec_debugfs:
- Fix use after free. Thanks Tzung-bi
sensorhub:
- cros_ec_sensorhub fixup - Split trace include file
misc:
- Add new mailing list for chrome-platform development:
chrome-platform@lists.linux.dev
Now with patchwork!"
* tag 'tag-chrome-platform-for-v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux:
platform/chrome: cros_ec_debugfs: detach log reader wq from devm
platform: chrome: Split trace include file
platform/chrome: cros_ec_typec: Update mux flags during partner removal
platform/chrome: cros_ec_typec: Configure muxes at start of port update
platform/chrome: cros_ec_typec: Get mux state inside configure_mux
platform/chrome: cros_ec_typec: Move mux flag checks
platform/chrome: cros_ec_typec: Check for EC device
platform/chrome: cros_ec_typec: Make try power role optional
MAINTAINERS: platform-chrome: Add new chrome-platform@lists.linux.dev list
Jens Axboe [Sat, 2 Apr 2022 17:40:23 +0000 (11:40 -0600)]
Revert "nbd: fix possible overflow on 'first_minor' in nbd_dev_add()"
This reverts commit
6d35d04a9e18990040e87d2bbf72689252669d54.
Both Gabriel and Borislav report that this commit casues a regression
with nbd:
sysfs: cannot create duplicate filename '/dev/block/43:0'
Revert it before 5.18-rc1 and we'll investigage this separately in
due time.
Link: https://lore.kernel.org/all/YkiJTnFOt9bTv6A2@zn.tnic/
Reported-by: Gabriel L. Somlo <somlo@cmu.edu>
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Eric Dumazet [Mon, 28 Mar 2022 17:07:04 +0000 (18:07 +0100)]
watch_queue: Free the page array when watch_queue is dismantled
Commit
7ea1a0124b6d ("watch_queue: Free the alloc bitmap when the
watch_queue is torn down") took care of the bitmap, but not the page
array.
BUG: memory leak
unreferenced object 0xffff88810d9bc140 (size 32):
comm "syz-executor335", pid 3603, jiffies
4294946994 (age 12.840s)
hex dump (first 32 bytes):
40 a7 40 04 00 ea ff ff 00 00 00 00 00 00 00 00 @.@.............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
kmalloc_array include/linux/slab.h:621 [inline]
kcalloc include/linux/slab.h:652 [inline]
watch_queue_set_size+0x12f/0x2e0 kernel/watch_queue.c:251
pipe_ioctl+0x82/0x140 fs/pipe.c:632
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
Reported-by: syzbot+25ea042ae28f3888727a@syzkaller.appspotmail.com
Fixes:
c73be61cede5 ("pipe: Add general notification queue support")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Jann Horn <jannh@google.com>
Link: https://lore.kernel.org/r/20220322004654.618274-1-eric.dumazet@gmail.com/
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Steven Rostedt (Google) [Fri, 1 Apr 2022 18:39:03 +0000 (14:39 -0400)]
tracing: mark user_events as BROKEN
After being merged, user_events become more visible to a wider audience
that have concerns with the current API.
It is too late to fix this for this release, but instead of a full
revert, just mark it as BROKEN (which prevents it from being selected in
make config). Then we can work finding a better API. If that fails,
then it will need to be completely reverted.
To not have the code silently bitrot, still allow building it with
COMPILE_TEST.
And to prevent the uapi header from being installed, then later changed,
and then have an old distro user space see the old version, move the
header file out of the uapi directory.
Surround the include with CONFIG_COMPILE_TEST to the current location,
but when the BROKEN tag is taken off, it will use the uapi directory,
and fail to compile. This is a good way to remind us to move the header
back.
Link: https://lore.kernel.org/all/20220330155835.5e1f6669@gandalf.local.home
Link: https://lkml.kernel.org/r/20220330201755.29319-1-mathieu.desnoyers@efficios.com
Suggested-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Steven Rostedt (Google) [Fri, 1 Apr 2022 18:39:03 +0000 (14:39 -0400)]
tracing: Move user_events.h temporarily out of include/uapi
While user_events API is under development and has been marked for broken
to not let the API become fixed, move the header file out of the uapi
directory. This is to prevent it from being installed, then later changed,
and then have an old distro user space update with a new kernel, where
applications see the user_events being available, but the old header is in
place, and then they get compiled incorrectly.
Also, surround the include with CONFIG_COMPILE_TEST to the current
location, but when the BROKEN tag is taken off, it will use the uapi
directory, and fail to compile. This is a good way to remind us to move
the header back.
Link: https://lore.kernel.org/all/20220330155835.5e1f6669@gandalf.local.home
Link: https://lkml.kernel.org/r/20220330201755.29319-1-mathieu.desnoyers@efficios.com
Link: https://lkml.kernel.org/r/20220401143903.188384f3@gandalf.local.home
Suggested-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Christophe Leroy [Wed, 30 Mar 2022 07:00:19 +0000 (09:00 +0200)]
ftrace: Make ftrace_graph_is_dead() a static branch
ftrace_graph_is_dead() is used on hot paths, it just reads a variable
in memory and is not worth suffering function call constraints.
For instance, at entry of prepare_ftrace_return(), inlining it avoids
saving prepare_ftrace_return() parameters to stack and restoring them
after calling ftrace_graph_is_dead().
While at it using a static branch is even more performant and is
rather well adapted considering that the returned value will almost
never change.
Inline ftrace_graph_is_dead() and replace 'kill_ftrace_graph' bool
by a static branch.
The performance improvement is noticeable.
Link: https://lkml.kernel.org/r/e0411a6a0ed3eafff0ad2bc9cd4b0e202b4617df.1648623570.git.christophe.leroy@csgroup.eu
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Steven Rostedt (Google) [Wed, 30 Mar 2022 19:58:35 +0000 (15:58 -0400)]
tracing: Set user_events to BROKEN
After being merged, user_events become more visible to a wider audience
that have concerns with the current API. It is too late to fix this for
this release, but instead of a full revert, just mark it as BROKEN (which
prevents it from being selected in make config). Then we can work finding
a better API. If that fails, then it will need to be completely reverted.
Link: https://lore.kernel.org/all/2059213643.196683.1648499088753.JavaMail.zimbra@efficios.com/
Link: https://lkml.kernel.org/r/20220330155835.5e1f6669@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Beau Belgrave [Tue, 29 Mar 2022 17:30:51 +0000 (10:30 -0700)]
tracing/user_events: Remove eBPF interfaces
Remove eBPF interfaces within user_events to ensure they are fully
reviewed.
Link: https://lore.kernel.org/all/20220329165718.GA10381@kbox/
Link: https://lkml.kernel.org/r/20220329173051.10087-1-beaub@linux.microsoft.com
Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Signed-off-by: Beau Belgrave <beaub@linux.microsoft.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Beau Belgrave [Mon, 28 Mar 2022 22:32:25 +0000 (15:32 -0700)]
tracing/user_events: Hold event_mutex during dyn_event_add
Make sure the event_mutex is properly held during dyn_event_add call.
This is required when adding dynamic events.
Link: https://lkml.kernel.org/r/20220328223225.1992-1-beaub@linux.microsoft.com
Reported-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Beau Belgrave <beaub@linux.microsoft.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Lv Ruyi [Tue, 29 Mar 2022 10:40:04 +0000 (10:40 +0000)]
proc: bootconfig: Add null pointer check
kzalloc is a memory allocation function which can return NULL when some
internal memory errors happen. It is safer to add null pointer check.
Link: https://lkml.kernel.org/r/20220329104004.2376879-1-lv.ruyi@zte.com.cn
Cc: stable@vger.kernel.org
Fixes:
c1a3c36017d4 ("proc: bootconfig: Add /proc/bootconfig to show boot config list")
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Lv Ruyi <lv.ruyi@zte.com.cn>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Steven Rostedt (Google) [Tue, 29 Mar 2022 20:50:44 +0000 (16:50 -0400)]
tracing: Rename the staging files for trace_events
When looking for implementation of different phases of the creation of the
TRACE_EVENT() macro, it is pretty useless when all helper macro
redefinitions are in files labeled "stageX_defines.h". Rename them to
state which phase the files are for. For instance, when looking for the
defines that are used to create the event fields, seeing
"stage4_event_fields.h" gives the developer a good idea that the defines
are in that file.
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Li RongQing [Wed, 9 Mar 2022 08:35:44 +0000 (16:35 +0800)]
KVM: x86: fix sending PV IPI
If apic_id is less than min, and (max - apic_id) is greater than
KVM_IPI_CLUSTER_SIZE, then the third check condition is satisfied but
the new apic_id does not fit the bitmask. In this case __send_ipi_mask
should send the IPI.
This is mostly theoretical, but it can happen if the apic_ids on three
iterations of the loop are for example 1, KVM_IPI_CLUSTER_SIZE, 0.
Fixes:
aaffcfd1e82 ("KVM: X86: Implement PV IPIs in linux guest")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Message-Id: <
1646814944-51801-1-git-send-email-lirongqing@baidu.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Tue, 29 Mar 2022 16:56:24 +0000 (12:56 -0400)]
KVM: x86/mmu: do compare-and-exchange of gPTE via the user address
FNAME(cmpxchg_gpte) is an inefficient mess. It is at least decent if it
can go through get_user_pages_fast(), but if it cannot then it tries to
use memremap(); that is not just terribly slow, it is also wrong because
it assumes that the VM_PFNMAP VMA is contiguous.
The right way to do it would be to do the same thing as
hva_to_pfn_remapped() does since commit
add6a0cd1c5b ("KVM: MMU: try to
fix up page faults before giving up", 2016-07-05), using follow_pte()
and fixup_user_fault() to determine the correct address to use for
memremap(). To do this, one could for example extract hva_to_pfn()
for use outside virt/kvm/kvm_main.c. But really there is no reason to
do that either, because there is already a perfectly valid address to
do the cmpxchg() on, only it is a userspace address. That means doing
user_access_begin()/user_access_end() and writing the code in assembly
to handle exceptions correctly. Worse, the guest PTE can be 8-byte
even on i686 so there is the extra complication of using cmpxchg8b to
account for. But at least it is an efficient mess.
(Thanks to Linus for suggesting improvement on the inline assembly).
Reported-by: Qiuhao Li <qiuhao@sysec.org>
Reported-by: Gaoning Pan <pgn@zju.edu.cn>
Reported-by: Yongkang Jia <kangel@zju.edu.cn>
Reported-by: syzbot+6cde2282daa792c49ab8@syzkaller.appspotmail.com
Debugged-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Tested-by: Maxim Levitsky <mlevitsk@redhat.com>
Cc: stable@vger.kernel.org
Fixes:
bd53cb35a3e9 ("X86/KVM: Handle PFNs outside of kernel reach when touching GPTEs")
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Zhenzhong Duan [Fri, 11 Mar 2022 10:26:43 +0000 (18:26 +0800)]
KVM: x86: Remove redundant vm_entry_controls_clearbit() call
When emulating exit from long mode, EFER_LMA is cleared with
vmx_set_efer(). This will already unset the VM_ENTRY_IA32E_MODE control
bit as requested by SDM, so there is no need to unset VM_ENTRY_IA32E_MODE
again in exit_lmode() explicitly. In case EFER isn't supported by
hardware, long mode isn't supported, so exit_lmode() cannot be reached.
Note that, thanks to the shadow controls mechanism, this change doesn't
eliminate vmread or vmwrite.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Message-Id: <
20220311102643.807507-3-zhenzhong.duan@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Zhenzhong Duan [Fri, 11 Mar 2022 10:26:42 +0000 (18:26 +0800)]
KVM: x86: cleanup enter_rmode()
vmx_set_efer() sets uret->data but, in fact if the value of uret->data
will be used vmx_setup_uret_msrs() will have rewritten it with the value
returned by update_transition_efer(). uret->data is consumed if and only
if uret->load_into_hardware is true, and vmx_setup_uret_msrs() takes care
of (a) updating uret->data before setting uret->load_into_hardware to true
(b) setting uret->load_into_hardware to false if uret->data isn't updated.
Opportunistically use "vmx" directly instead of redoing to_vmx().
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Message-Id: <
20220311102643.807507-2-zhenzhong.duan@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Maxim Levitsky [Tue, 22 Mar 2022 17:24:48 +0000 (19:24 +0200)]
KVM: x86: SVM: fix tsc scaling when the host doesn't support it
It was decided that when TSC scaling is not supported,
the virtual MSR_AMD64_TSC_RATIO should still have the default '1.0'
value.
However in this case kvm_max_tsc_scaling_ratio is not set,
which breaks various assumptions.
Fix this by always calculating kvm_max_tsc_scaling_ratio regardless of
host support. For consistency, do the same for VMX.
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <
20220322172449.235575-8-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Maxim Levitsky [Tue, 22 Mar 2022 17:24:47 +0000 (19:24 +0200)]
kvm: x86: SVM: remove unused defines
Remove some unused #defines from svm.c
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <
20220322172449.235575-7-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Maxim Levitsky [Tue, 22 Mar 2022 17:24:46 +0000 (19:24 +0200)]
KVM: x86: SVM: move tsc ratio definitions to svm.h
Another piece of SVM spec which should be in the header file
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <
20220322172449.235575-6-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Maxim Levitsky [Tue, 22 Mar 2022 17:24:45 +0000 (19:24 +0200)]
KVM: x86: SVM: fix avic spec based definitions again
Due to wrong rebase, commit
4a204f7895878 ("KVM: SVM: Allow AVIC support on system w/ physical APIC ID > 255")
moved avic spec #defines back to avic.c.
Move them back, and while at it extend AVIC_DOORBELL_PHYSICAL_ID_MASK to 12
bits as well (it will be used in nested avic)
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <
20220322172449.235575-5-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Sun, 13 Mar 2022 14:05:22 +0000 (15:05 +0100)]
KVM: MIPS: remove reference to trap&emulate virtualization
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <
20220313140522.
1307751-1-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Tue, 15 Mar 2022 22:17:15 +0000 (18:17 -0400)]
KVM: x86: document limitations of MSR filtering
MSR filtering requires an exit to userspace that is hard to implement and
would be very slow in the case of nested VMX vmexit and vmentry MSR
accesses. Document the limitation.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Hou Wenlong [Mon, 7 Mar 2022 12:26:33 +0000 (20:26 +0800)]
KVM: x86: Only do MSR filtering when access MSR by rdmsr/wrmsr
If MSR access is rejected by MSR filtering,
kvm_set_msr()/kvm_get_msr() would return KVM_MSR_RET_FILTERED,
and the return value is only handled well for rdmsr/wrmsr.
However, some instruction emulation and state transition also
use kvm_set_msr()/kvm_get_msr() to do msr access but may trigger
some unexpected results if MSR access is rejected, E.g. RDPID
emulation would inject a #UD but RDPID wouldn't cause a exit
when RDPID is supported in hardware and ENABLE_RDTSCP is set.
And it would also cause failure when load MSR at nested entry/exit.
Since msr filtering is based on MSR bitmap, it is better to only
do MSR filtering for rdmsr/wrmsr.
Signed-off-by: Hou Wenlong <houwenlong.hwl@antgroup.com>
Message-Id: <
2b2774154f7532c96a6f04d71c82a8bec7d9e80b.
1646655860.git.houwenlong.hwl@antgroup.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Hou Wenlong [Wed, 2 Mar 2022 13:15:14 +0000 (21:15 +0800)]
KVM: x86/emulator: Emulate RDPID only if it is enabled in guest
When RDTSCP is supported but RDPID is not supported in host,
RDPID emulation is available. However, __kvm_get_msr() would
only fail when RDTSCP/RDPID both are disabled in guest, so
the emulator wouldn't inject a #UD when RDPID is disabled but
RDTSCP is enabled in guest.
Fixes:
fb6d4d340e05 ("KVM: x86: emulate RDPID")
Signed-off-by: Hou Wenlong <houwenlong.hwl@antgroup.com>
Message-Id: <
1dfd46ae5b76d3ed87bde3154d51c64ea64c99c1.
1646226788.git.houwenlong.hwl@antgroup.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Like Xu [Wed, 9 Mar 2022 08:42:57 +0000 (16:42 +0800)]
KVM: x86/pmu: Fix and isolate TSX-specific performance event logic
HSW_IN_TX* bits are used in generic code which are not supported on
AMD. Worse, these bits overlap with AMD EventSelect[11:8] and hence
using HSW_IN_TX* bits unconditionally in generic code is resulting in
unintentional pmu behavior on AMD. For example, if EventSelect[11:8]
is 0x2, pmc_reprogram_counter() wrongly assumes that
HSW_IN_TX_CHECKPOINTED is set and thus forces sampling period to be 0.
Also per the SDM, both bits 32 and 33 "may only be set if the processor
supports HLE or RTM" and for "IN_TXCP (bit 33): this bit may only be set
for IA32_PERFEVTSEL2."
Opportunistically eliminate code redundancy, because if the HSW_IN_TX*
bit is set in pmc->eventsel, it is already set in attr.config.
Reported-by: Ravi Bangoria <ravi.bangoria@amd.com>
Reported-by: Jim Mattson <jmattson@google.com>
Fixes:
103af0a98788 ("perf, kvm: Support the in_tx/in_tx_cp modifiers in KVM arch perfmon emulation v5")
Co-developed-by: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Like Xu <likexu@tencent.com>
Message-Id: <
20220309084257.88931-1-likexu@tencent.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Maxim Levitsky [Wed, 2 Mar 2022 10:24:57 +0000 (12:24 +0200)]
KVM: x86: mmu: trace kvm_mmu_set_spte after the new SPTE was set
It makes more sense to print new SPTE value than the
old value.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Sean Christopherson <seanjc@google.com>
Message-Id: <
20220302102457.588450-1-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Jim Mattson [Sat, 26 Feb 2022 23:41:31 +0000 (15:41 -0800)]
KVM: x86/svm: Clear reserved bits written to PerfEvtSeln MSRs
AMD EPYC CPUs never raise a #GP for a WRMSR to a PerfEvtSeln MSR. Some
reserved bits are cleared, and some are not. Specifically, on
Zen3/Milan, bits 19 and 42 are not cleared.
When emulating such a WRMSR, KVM should not synthesize a #GP,
regardless of which bits are set. However, undocumented bits should
not be passed through to the hardware MSR. So, rather than checking
for reserved bits and synthesizing a #GP, just clear the reserved
bits.
This may seem pedantic, but since KVM currently does not support the
"Host/Guest Only" bits (41:40), it is necessary to clear these bits
rather than synthesizing #GP, because some popular guests (e.g Linux)
will set the "Host Only" bit even on CPUs that don't support
EFER.SVME, and they don't expect a #GP.
For example,
root@Ubuntu1804:~# perf stat -e r26 -a sleep 1
Performance counter stats for 'system wide':
0 r26
1.
001070977 seconds time elapsed
Feb 23 03:59:58 Ubuntu1804 kernel: [ 405.379957] unchecked MSR access error: WRMSR to 0xc0010200 (tried to write 0x0000020000130026) at rIP: 0xffffffff9b276a28 (native_write_msr+0x8/0x30)
Feb 23 03:59:58 Ubuntu1804 kernel: [ 405.379958] Call Trace:
Feb 23 03:59:58 Ubuntu1804 kernel: [ 405.379963] amd_pmu_disable_event+0x27/0x90
Fixes:
ca724305a2b0 ("KVM: x86/vPMU: Implement AMD vPMU code for KVM")
Reported-by: Lotus Fenn <lotusf@google.com>
Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Like Xu <likexu@tencent.com>
Reviewed-by: David Dunn <daviddunn@google.com>
Message-Id: <
20220226234131.
2167175-1-jmattson@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>