drm/i915: Fix CFI violation with show_dynamic_id()
When an attribute group is created with sysfs_create_group(), the
->sysfs_ops() callback is set to kobj_sysfs_ops, which sets the ->show()
callback to kobj_attr_show(). kobj_attr_show() uses container_of() to
get the ->show() callback from the attribute it was passed, meaning the
->show() callback needs to be the same type as the ->show() callback in
'struct kobj_attribute'.
However, show_dynamic_id() has the type of the ->show() callback in
'struct device_attribute', which causes a CFI violation when opening the
'id' sysfs node under drm/card0/metrics. This happens to work because
the layout of 'struct kobj_attribute' and 'struct device_attribute' are
the same, so the container_of() cast happens to allow the ->show()
callback to still work.
Change the type of show_dynamic_id() to match the ->show() callback in
'struct kobj_attributes' and update the type of sysfs_metric_id to
match, which resolves the CFI violation.
Anusha Srivatsa [Wed, 11 May 2022 00:08:47 +0000 (17:08 -0700)]
drm/i915/dmc: Add MMIO range restrictions
Bspec has added some steps that check forDMC MMIO range before
programming them
v2: Fix for CI
v3: move register defines to .h (Anusha)
- Check MMIO restrictions per pipe
- Add MMIO restricton for v1 dmc header as well (Lucas)
v4: s/_PICK/_PICK_EVEN and use it only for Pipe DMC scenario.
- clean up sanity check logic.(Lucas)
- Add MMIO range for RKL as well.(Anusha)
v5: Use DISPLAY_VER instead of per platform check (Lucas)
i915/guc/reset: Make __guc_reset_context aware of guilty engines
There are 2 ways an engine can get reset in i915 and the method of reset
affects how KMD labels a context as guilty/innocent.
(1) GuC initiated engine-reset: GuC resets a hung engine and notifies
KMD. The context that hung on the engine is marked guilty and all other
contexts are innocent. The innocent contexts are resubmitted.
(2) GT based reset: When an engine heartbeat fails to tick, KMD
initiates a gt/chip reset. All active contexts are marked as guilty and
discarded.
In order to correctly mark the contexts as guilty/innocent, pass a mask
of engines that were reset to __guc_reset_context.
Imre Deak [Tue, 10 May 2022 11:49:57 +0000 (14:49 +0300)]
drm/i915: Fix 'mixing different enum types' warnings in intel_display_power.c
Fix the following sparse warnings:
drivers/gpu/drm/i915/display/intel_display_power.c:2431:34: warning: mixing different enum types:
drivers/gpu/drm/i915/display/intel_display_power.c:2431:34: unsigned int enum intel_display_power_domain
drivers/gpu/drm/i915/display/intel_display_power.c:2431:34: int enum port
drivers/gpu/drm/i915/display/intel_display_power.c:2442:37: warning: mixing different enum types:
drivers/gpu/drm/i915/display/intel_display_power.c:2442:37: unsigned int enum intel_display_power_domain
drivers/gpu/drm/i915/display/intel_display_power.c:2442:37: int enum port
drivers/gpu/drm/i915/display/intel_display_power.c:2468:43: warning: mixing different enum types:
drivers/gpu/drm/i915/display/intel_display_power.c:2468:43: unsigned int enum intel_display_power_domain
drivers/gpu/drm/i915/display/intel_display_power.c:2468:43: unsigned int enum aux_ch
drivers/gpu/drm/i915/display/intel_display_power.c:2479:35: warning: mixing different enum types:
drivers/gpu/drm/i915/display/intel_display_power.c:2479:35: unsigned int enum intel_display_power_domain
drivers/gpu/drm/i915/display/intel_display_power.c:2479:35: unsigned int enum aux_ch
Lucas De Marchi [Thu, 5 May 2022 21:38:12 +0000 (14:38 -0700)]
drm/i915/pvc: read fuses for link copy engines
The new Link Copy engines in PVC may be fused off according to the
mslice_mask. Each bit of the MEML3_EN_MASK we read from the
GEN10_MIRROR_FUSE3 register disables a pair of link copy engines.
v2 (Tvrtko):
- Minor cosmetic changes: s/u8/unsigned long/, use instance local
variable. (Tvrtko)
Matt Roper [Thu, 5 May 2022 21:38:08 +0000 (14:38 -0700)]
drm/i915/pvc: Engine definitions for new copy engines
This patch adds the basic definitions needed to support
new copy engines. Also updating the cmd_info to accommodate
new engines, as the engine id's of legacy engines have been
changed.
v2:
- Add _BCS(n) definition, similar to other engines. (Tvrtko)
- Add I915_MAX_BCS definition, similar to other engnes. (Prathap)
- Move GVT change to avoid u16 overflow to its own patch. (Tvrtko)
Matt Roper [Thu, 5 May 2022 21:38:07 +0000 (14:38 -0700)]
drm/i915/gvt: Use intel_engine_mask_t for ring mask
When i915 adds additional PVC blitter instances (in an upcoming patch),
the definition of VECS0 will change from bit(10) to bit(18), causing
GVT's R_ALL mask to overflow the u16 storage that's currently used.
Let's replace the u16 with an intel_engine_mask_t to ensure we avoid
this.
John Harrison [Thu, 5 May 2022 21:38:06 +0000 (14:38 -0700)]
drm/i915/pvc: Reduce stack usage in reset selftest with extra blitter engine
PVC adds extra blitter engines (in the following patch). The reset
selftest has a local array on the stack which is sized by the number
of engines. The increase pushes the size of this array to the point
where it trips the 'stack too large' compile warning. This patch takes
the allocation of the stack and makes it dynamic instead.
v2 (MattR):
- Minor cosmetic changes: re-sort definition and allocate using
kmalloc_array(). (Tvrtko)
Matt Roper [Thu, 5 May 2022 21:38:04 +0000 (14:38 -0700)]
drm/i915/pvc: Read correct RP_STATE_CAP register
The SoC registers, including RP_STATE_CAP, have moved to a new location
in GTTMMADR on Ponte Vecchio. We need to update the register offset
accordingly.
Ayaz A Siddiqui [Thu, 5 May 2022 21:38:03 +0000 (14:38 -0700)]
drm/i915/pvc: Define MOCS table for PVC
v2 (MattR):
- Clarify comment above RING_CMD_CCTL programming.
- Remove bspec reference from field definition. (Lucas)
- Add WARN if we try to use a (presumably uninitialized) wb_index of 0.
On most platforms 0 is an invalid MOCS entry and even on the ones
where it isn't, it isn't the right setting for wb_index. (Lucas)
Lucas De Marchi [Tue, 3 May 2022 06:15:56 +0000 (23:15 -0700)]
drm/i915/gem: Make drop_pages() return bool
Commit e4e806253003 ("drm/i915: Change shrink ordering to use locking
around unbinding.") changed the return type to int without changing the
return values or their meaning to "0 is success". Move it back to
boolean.
drm/i915: Only setup private tmpfs mount when needed and fix logging
If i915 does not want to use huge pages there is a) no point in setting up
the private mount and b) should former fail, it is misleading to log THP
support is disabled in the caller, which does not even know if callee
tried to enable it.
Fix both by restructuring the flow in i915_gemfs_init and at the same time
note the failure to set it up in all cases.
We have a statement from HW designers that the GPU read regression when
using 2M pages was fixed from Icelake onwards, which was also confirmed
by bencharking Eero did last year:
"""
When IOMMU is disabled, enabling THP causes following perf changes on
TGL-H (GT1):
In the above 3D benchmark names, * means all the variants of tests with
the same prefix. For example "SynMark TexMem*", means both TexMem128 &
TexMem512 tests in the synthetic (Intel internal) SynMark test suite.
In the (public, but proprietary) GfxBench & GLB(enchmark) test suites,
there are both onscreen and offscreen variants of each test. Unless
explicitly stated otherwise, numbers are for both variants.
All tests are run with FullHD monitor. All tests are fullscreen except
for GLB and GpuTest ones, which are run in 1/2 screen window (GpuTest
triangle is run both in fullscreen and 1/2 screen window).
"""
Since the only regression is MemBW GPU blend, against many more gains,
it sounds it is time to enable THP on Gen11+.
Jani Nikula [Wed, 4 May 2022 18:37:15 +0000 (21:37 +0300)]
drm/i915: remove single-use GEM_DEBUG_EXEC()
Reduce the magic of what's going on in GEM_DEBUG_EXEC() by expanding it
inline and being explicit about it. It's as single use case anyway, so
the macro feels overkill.
No need to have this parameter in intel_device_info struct
as all platforms with display version 9 or newer has this feature.
As a side effect of the of removal this flag, it will not be printed
in dmesg during driver load anymore and developers will have to rely
on to check the macro and compare with platform being used and IP
versions of it.
No need to have this parameter in intel_device_info struct
as the requirement to support it is the DDI support.
As a side effect of the of removal this flag, it will not be printed
in dmesg during driver load anymore and developers will have to rely
on to check the macro and compare with platform being used and IP
versions of it.
No need to have this parameter in intel_device_info struct
as all platforms with display version 9 or newer, haswell or broadwell
supports it.
As a side effect of the of removal this flag, it will not be printed
in dmesg during driver load anymore and developers will have to rely
on to check the macro and compare with platform being used and IP
versions of it.
drm/i915: Drop has_logical_ring_elsq from device info
No need to have this parameter in intel_device_info struct
as all platforms with graphics version 11 or newer has this feature.
As a side effect of the of removal this flag, it will not be printed
in dmesg during driver load anymore and developers will have to rely
on to check the macro and compare with platform being used and IP
versions of it.
No need to have this parameter in intel_device_info struct
as all platforms with graphics version 7 or newer can reset engines.
As a side effect of the of removal this flag, it will not be printed
in dmesg during driver load anymore and developers will have to rely
on to check the macro and compare with platform being used and IP
versions of it.
No need to have this parameter in intel_device_info struct
as all platforms with graphics version 6 or newer have software
support for this feature.
As a side effect of the of removal this flag, it will not be printed
in dmesg during driver load anymore and developers will have to rely
on to check the macro and compare with platform being used and IP
versions of it.
No need to have this parameter in intel_device_info struct
as all platforms with graphics version 9 or newer has graphics
microcontroller.
As a side effect of the of removal this flag, it will not be printed
in dmesg during driver load anymore and developers will have to rely
on to check the macro and compare with platform being used and IP
versions of it.
Tvrtko Ursulin [Thu, 5 May 2022 11:00:07 +0000 (12:00 +0100)]
drm/i915: Don't use DRM_DEBUG_WARN_ON for ring unexpectedly not idle
DRM_DEBUG_WARN_ON should only be used when we are certain CI is guaranteed
to exercise a certain code path, so in case of values coming from MMIO
reads we cannot be sure CI will have all the possible SKUs and parts, or
that it will catch all possible error conditions. Use drm_warn instead.
Tvrtko Ursulin [Thu, 5 May 2022 11:00:06 +0000 (12:00 +0100)]
drm/i915: Don't use DRM_DEBUG_WARN_ON for unexpected l3bank/mslice config
DRM_DEBUG_WARN_ON should only be used when we are certain CI is guaranteed
to exercise a certain code path, so in case of values coming from MMIO
reads we cannot be sure CI will have all the possible SKUs and parts.
Use drm_warn instead and move logging to init phase while at it.
drm/i915/huc: Don't fail the probe if HuC init fails
The previous patch introduced new failure cases in the HuC init flow
that can be hit by simply changing the config, so we want to avoid
failing the probe in those scenarios. HuC load failure is already
considered a non-fatal error and we have a way to report to userspace
if the HuC is not available via a dedicated getparam, so no changes
in expectation there.
The error message in the HuC init code has also been lowered to info to
avoid throwing error message for an expected behavior.
HuC loading via GSC is performed via a PXP command sent through the mei
modules, so we need both MEI_GSC and MEI_PXP to be available. Given that
the GSC will do both the transfer and the authentication, the legacy HuC
loading paths can be safely skipped.
Also note that the GSC-loaded HuC survives GT reset.
v2: move the huc_is_authenticated() function to this patch.
drm/i915/huc: Add fetch support for gsc-loaded HuC binary
On newer platforms (starting DG2 G10 B-step and G11 A-step), ownership of
HuC loading has been moved from the GuC to the GSC. As part of the
change, the header format of the HuC binary has been updated and does not
match the GuC anymore. The GSC will perform all the required checks on
the binary size, so we only need to check that the version matches.
Note that since we still haven't added any gsc-loaded FWs, the
loaded_via_gsc variable will always be kept to its initialization value
of zero.
v2: Add a note about loaded_via_gsc being zero (Alan)
The function name is confusing, because it doesn't check the actual auth
status in HW but the SW status. Given that there is only one user (the
huc_auth function itself), just get rid of it and use the FW status
checker directly.
Matthew Brost [Wed, 4 May 2022 23:46:36 +0000 (16:46 -0700)]
drm/i915/guc: Support programming the EU priority in the GuC descriptor
In GuC submission mode the EU priority must be updated by the GuC rather
than the driver as the GuC owns the programming of the context descriptor.
Given that the GuC code uses the GuC priorities, we can't use a generic
function using i915 priorities for both execlists and GuC submission.
The existing function has therefore been pushed to the execlists
back-end while a new one has been added for GuC.
Ville Syrjälä [Wed, 4 May 2022 15:04:38 +0000 (18:04 +0300)]
drm/i915/bios: Refactor panel_type code
Make the panel type code a bit more abstract along the
lines of the source of the panel type. For the moment
we have three classes: OpRegion, VBT, fallback.
Well introduce another one shortly.
We can now also print out all the different panel types,
and indicate which one we ultimately selected. Could help
with debugging.
Ville Syrjälä [Wed, 4 May 2022 15:04:36 +0000 (18:04 +0300)]
drm/i915/bios: Assume panel_type==0 if the VBT has bogus data
Just assume panel_type==0 always if the VBT gives us bogus data.
We actually already do this everywhere else except in
parse_panel_options() since we just leave i915->vbt.panel_type
zeroed. This also seems to be what Windows does.
Ville Syrjälä [Wed, 4 May 2022 15:04:34 +0000 (18:04 +0300)]
drm/i915/bios: Get access to the tail end of the LFP data block
We need to start parsing stuff from the tail end of the LFP data block.
This is made awkward by the fact that the fp_timing table has variable
size. So we must use a bit more finesse to get the tail end, and to
make sure we allocate enough memory for it to make sure our struct
representation fits.
v2: Rebase due to the preallocation of BDB blocks
v3: Rebase due to min_size WARN relocation
v4: Document BDB_LVDS_LFP_DATA vs. BDB_LVDS_LFP_DATA_PTRS order (Jani)
Ville Syrjälä [Wed, 4 May 2022 15:04:33 +0000 (18:04 +0300)]
drm/i915/bios: Generate LFP data table pointers if the VBT lacks them
Modern VBTs no longer contain the LFP data table pointers
block (41). We are expecting to have one in order to be able
to parse the LFP data block (42), so let's make one up.
Since the fp_timing table has variable size we must somehow
determine its size. Rather than just hardcode it we look for
the terminator bytes (0xffff) to figure out where each table
entry starts. dvo_timing, panel_pnp_id, and panel_name are
expected to have fixed size.
This has been observed on various machines, eg. TGL with BDB
version 240, CML with BDB version 231, etc. The most recent
VBT I've observed that still had block 41 had BDB version
228. So presumably the cutoff (if an exact cutoff even exists)
is somewhere around BDB version 229-231.
v2: kfree the thing we allocated, not the thing+3 bytes
v3: Do the debugprint only if we found the LFP data block
v4: Fix t0 null check (Jani)
Ville Syrjälä [Fri, 18 Feb 2022 10:03:59 +0000 (12:03 +0200)]
drm/i915: Use drm_mode_init() for on-stack modes
Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.
Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M = E;
+ struct drm_display_mode M;
@@
identifier decl.M;
expression decl.E;
statement S, S1;
@@
struct drm_display_mode M;
... when != S
+ drm_mode_init(&M, &E);
+
S1
Ramalingam C [Mon, 2 May 2022 14:26:17 +0000 (19:56 +0530)]
drm/i915/gt: optimize the ccs_sz calculation per chunk
Calculate the ccs_sz that needs to be emitted based on the src
and dst pages emitted per chunk. And handle the return value of emit_pte
for the ccs pages.
Chris Wilson [Mon, 25 Apr 2022 15:23:17 +0000 (20:53 +0530)]
drm/i915/gt: Clear SET_PREDICATE_RESULT prior to executing the ring
Userspace may leave predication enabled upon return from the batch
buffer, which has the consequent of preventing all operation from the
ring from being executed, including all the synchronisation, coherency
control, arbitration and user signaling. This is more than just a local
gpu hang in one client, as the user has the ability to prevent the
kernel from applying critical workarounds and can cause a full GT reset.
We could simply execute MI_SET_PREDICATE upon return from the user
batch, but this has the repercussion of modifying the user's context
state. Instead, we opt to execute a fixup batch which by mixing
predicated operations can determine the state of the
SET_PREDICATE_RESULT register and restore it prior to the next userspace
batch. This allows us to protect the kernel's ring without changing the
uABI.
Chris Wilson [Mon, 25 Apr 2022 15:23:16 +0000 (20:53 +0530)]
drm/i915/selftests: Skip poisoning SET_PREDICATE_RESULT on dg2
When predication is enabled all commands baring a few (such as MI_BB_END)
are nop'ed. If we accidentally enable predication while poisoning the
context, not only is the rest of the poisoning skipped (thus disabling
the test), but the closing instructions of the poison request are
nop'ed. Not only do we then not signal the waiting context, but we even
prevent re-enabling arbitration and the GPU will not perform a context
switch at the end of the request.
drm/i915/xehpsdv/dg1/tgl: Fix issue with LRI relative addressing
When bit 19 of MI_LOAD_REGISTER_IMM instruction opcode is set on tgl+
devices, HW does not care about certain register address offsets, but
instead check the following for valid address ranges on specific engines:
RCS && CCS: BITS(0 - 10)
BCS: BITS(0 - 11)
VECS && VCS: BITS(0 - 13)
Also, tgl+ now support relative addressing for BCS engine - So, this
patch fixes issue with live_gt_lrc selftest that is failing where there is
mismatch between LRC register layout generated during init and HW
default register offsets.
Jani Nikula [Fri, 29 Apr 2022 14:21:40 +0000 (17:21 +0300)]
drm/i915: move tons of power well initializers to rodata
Using compound literals for initialization can be tricky. Lacking a
const qualifier, they won't end up in rodata, which is probably not
expected or intended. Add const to move a whopping 136 initializers to
rodata.
Matt Roper [Thu, 28 Apr 2022 04:19:24 +0000 (21:19 -0700)]
drm/i915/xehp: Add register for compute engine's MMIO-based TLB invalidation
Compute engines have a separate register that the driver should use to
perform MMIO-based TLB invalidation.
Note that the term "context" in this register's bspec description is
used to refer to the engine instance (in the same way "context" is used
on bspec 46167).
Matt Roper [Thu, 28 Apr 2022 04:19:23 +0000 (21:19 -0700)]
drm/i915/uapi: Add kerneldoc for engine class enum
We'll be adding a new type of engine soon. Let's document the existing
engine classes first to help make it clear what each type of engine is
used for.
Jani Nikula [Fri, 29 Apr 2022 09:58:40 +0000 (12:58 +0300)]
Merge tag 'gvt-next-2022-04-29' of https://github.com/intel/gvt-linux into drm-intel-next
gvt-next-2022-04-29
Introduce fixes from previous pull.
- Fix a compiling warning of non-static funtion only having one caller.
- Fix a potential NULL pointer reference in the code re-factor.
- Fix a compiling error when CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n
Matt Roper [Mon, 25 Apr 2022 21:12:50 +0000 (14:12 -0700)]
drm/i915: Add first set of DG2 PCI IDs
The IDs added here are the subset reserved for 'motherboard down'
designs of DG2. We have all the necessary support upstream to enable
these now (although they'll continue to require force_probe until the
usual requirements are met).
The remaining DG2 IDs for add-in cards will come in a future patch once
some additional required functionality has fully landed.
Imre Deak [Fri, 8 Apr 2022 22:46:29 +0000 (01:46 +0300)]
drm/i915/dp: Add workaround for spurious AUX timeouts/hotplugs on LTTPR links
To avoid AUX timeouts and subsequent spurious hotplug interrupts, make
sure that the first DPCD access during detection is a read from an LTTPR
register.
Some ADLP DP link configuration at least with multiple LTTPRs expects
the first DPCD access during the LTTPR/DPCD detection after hotplug to
be a read from the LTTPR range starting with
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV. The side effect of
this read is to put each LTTPR into the LTTPR transparent or LTTPR
non-transparent mode.
The lack of the above read may leave some of the LTTPRs in non-LTTPR
mode, while other LTTPRs in LTTPR transparent or LTTPR non-transparent
mode (for instance LTTPRs after system suspend/resume that kept their
mode from before suspend). Due to the different AUX timeouts the
different modes imply, the DPCD access from a non-LTTPR range will
timeout and lead to an LTTPR generated hotplug towards the source (which
the LTTPR firmware uses to account for buggy TypeC adapters with a long
wake-up delay).
SYSCROS: 72939
v2: Keep DPCD read-out working on non-LTTPR platforms.
v3: Summarize what and why the patch does at the beginning of the commit
log. (Jani)
Ville Syrjälä [Fri, 25 Mar 2022 12:32:01 +0000 (14:32 +0200)]
drm/i915: Add crtc .crtc_get_shared_dpll()
Start splitting the .compute_crtc_clock() into two parts; one
part does the computation, the second part does the shared dpll
assignment. I want to move the actual computation part much earlier
into the compute_config() phase.
Ville Syrjälä [Fri, 25 Mar 2022 12:31:58 +0000 (14:31 +0200)]
drm/i915: Move the dpll_hw_state clearing to intel_dpll_crtc_compute_clock()
All .crtc_compute_clock() implementations do the same memset() to
clear the dpll_hw_state (since we preserve it across
intel_crtc_prepare_cleared_state()). Move the memset() to the common
wrapper.
Ville Syrjälä [Fri, 25 Mar 2022 12:31:57 +0000 (14:31 +0200)]
drm/i915: Move stuff into intel_dpll_crtc_compute_clock()
Move some checks into intel_dpll_crtc_compute_clock() from the
caller. Avoids the caller from having to worry about all this
crap.
We'll also reorder the hw.enable vs. shared_dpll checks since
it makes sense to sanity check that we've cleared out the
old shared_dpll even if the pipe is getting disabled.
Ville Syrjälä [Wed, 13 Apr 2022 15:28:52 +0000 (18:28 +0300)]
drm/i915/fbc: s/false/0/
intel_fbc_check_plane() is supposed to an int, not a boolean.
So replace the bogus 'return false's with the correct 'return 0's.
These were accidental copy-paste mistakes when the code got moved
into intel_fbc_check_plane() from somewhere else tht did return
a boolean.
Ville Syrjälä [Wed, 13 Apr 2022 15:28:51 +0000 (18:28 +0300)]
drm/i915/fbc: Consult hw.crtc instead of uapi.crtc
plane_state->uapi.crtc is not what we want to be looking at.
If bigjoiner is used hw.crtc is what tells us what crtc the plane
is supposedly using.
Not an actual problem on current hardware as the only FBC capable
pipe (A) can't be a bigjoiner slave and thus uapi.crtc==hw.crtc
always here. But when we get more FBC instances this will become
actually important.
Dave Airlie [Thu, 21 Apr 2022 20:43:52 +0000 (06:43 +1000)]
Merge tag 'drm-misc-next-2022-04-21' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 5.19-rc1
UAPI Changes:
Cross-subsystem Changes:
- of: Create a platform_device for offb
Core Changes:
- edid: block read refactoring
- ttm: Add common debugfs code for resource managers
Driver Changes:
- bridges:
- adv7611: Enable DRM_BRIDGE_OP_HPD if there's an interrupt
- anx7625: Fill ELD if no monitor is connected
- dw_hdmi: Add General Parallel Audio support
- icn6211: Add data-lanes DT property
- new driver: Lontium LT9211
- nouveau: make some structures static
- tidss: Reset DISPC on startup
- solomon: SPI Support and DT bindings improvements
Add a hook to retrieve the firmware version of the
GSC devices to bus-fixup.
GSC has a different MKHI clients GUIDs but the same message structure
to retrieve the firmware version as MEI so mei_fwver() can be reused.
mei: gsc: setup char driver alive in spite of firmware handshake failure
Setup char device in spite of firmware handshake failure.
In order to provide host access to the firmware status registers and other
information required for the manufacturing process.
Tomas Winkler [Tue, 19 Apr 2022 19:33:09 +0000 (12:33 -0700)]
mei: add support for graphics system controller (gsc) devices
GSC is a graphics system controller, based on CSE, it provides
a chassis controller for graphics discrete cards, as well as it
supports media protection on selected devices.
mei_gsc binds to a auxiliary devices exposed by Intel discrete
driver i915.
v2: fix error check in mei_gsc_probe
v3: update MODULE_LICENSE ("GPL" is preferred over "GPL v2" and they
both map to GPL version 2)
Tomas Winkler [Tue, 19 Apr 2022 19:33:08 +0000 (12:33 -0700)]
drm/i915/gsc: add gsc as a mei auxiliary device
GSC is a graphics system controller, it provides
a chassis controller for graphics discrete cards.
There are two MEI interfaces in GSC: HECI1 and HECI2.
Both interfaces are on the BAR0 at offsets 0x00258000 and 0x00259000.
GSC is a GT Engine (class 4: instance 6). HECI1 interrupt is signaled
via bit 15 and HECI2 via bit 14 in the interrupt register.
This patch exports GSC as auxiliary device for mei driver to bind to
for HECI2 interface and prepares for HECI1 interface as
it will follow up soon.
drm/i915: Check EDID for HDR static metadata when choosing blc
We have now seen panel (XMG Core 15 e21 laptop) advertizing support
for Intel proprietary eDP backlight control via DPCD registers, but
actually working only with legacy pwm control.
This patch adds panel EDID check for possible HDR static metadata and
Intel proprietary eDP backlight control is used only if that exists.
Missing HDR static metadata is ignored if user specifically asks for
Intel proprietary eDP backlight control via enable_dpcd_backlight
parameter.
v2 :
- Ignore missing HDR static metadata if Intel proprietary eDP
backlight control is forced via i915.enable_dpcd_backlight
- Printout info message if panel is missing HDR static metadata and
support for Intel proprietary eDP backlight control is detected
Jason Gunthorpe [Mon, 11 Apr 2022 14:14:02 +0000 (16:14 +0200)]
vfio/mdev: Use the driver core to create the 'remove' file
The device creator is supposed to use the dev.groups value to add sysfs
files before device_add is called, not call sysfs_create_files() after
device_add() returns. This creates a race with uevent delivery where the
extra attribute will not be visible.
This was being done because the groups had been co-opted by the mdev
driver, now that prior patches have moved the driver's groups to the
struct device_driver the dev.group is properly free for use here.
Jason Gunthorpe [Mon, 11 Apr 2022 14:14:00 +0000 (16:14 +0200)]
vfio/mdev: Remove mdev_parent_ops dev_attr_groups
This is only used by one sample to print a fixed string that is pointless.
In general, having a device driver attach sysfs attributes to the parent
is horrific. This should never happen, and always leads to some kind of
liftime bug as it become very difficult for the sysfs attribute to go back
to any data owned by the device driver.
Remove the general mechanism to create this abuse.
Jason Gunthorpe [Mon, 11 Apr 2022 14:13:59 +0000 (16:13 +0200)]
vfio/mdev: Remove vfio_mdev.c
Now that all mdev drivers directly create their own mdev_device driver and
directly register with the vfio core's vfio_device_ops this is all dead
code.
Delete vfio_mdev.c and the mdev_parent_ops members that are connected to
it.
projects / linux.git / log