- 26 Feb, 2019 11 commits
-
-
Ville Syrjälä authored
As with regular HDMI encoders, let's precompute the infoframes (actually just AVI infoframe for the time being) with SDVO HDMI encoders. v2: Drop the WARN_ON() from drm_hdmi_avi_infoframe_from_display_mode() return since that could genuinely fail due to user asking for incompatible aspect ratio v3: .compute_config() now returns int Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190225174106.2163-7-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Add code to read the infoframes from the video DIP and unpack them into the crtc state. v2: Make the read funcs return void (Daniel) Drop the duplicate infoframe enabled checks (Daniel) Add a FIXME for lspcon infoframe readout Signed-off-by: -
Ville Syrjälä authored
Store the infoframes in the crtc state and precompute them in .compute_config(). While precomputing we'll also fill out the inforames.enable bitmask appropriately. v2: Drop the null packet stuff (Daniel) Add a FIXME for lspcon v3: .compute_config() now returns int Signed-off-by: -
Ville Syrjälä authored
Store the mask of enabled infoframes in the crtc state. We'll start with just the readout for HDMI encoder, and we'll expand this to compute the bitmask in .compute_config() later. SDVO will also follow later. Signed-off-by:
-
Ville Syrjälä authored
We want to start tracking which infoframes are enabled, so let's replace the boolean flag with a bitmask. We'll abstract the bitmask so that it's not platform dependent. That will allow us to examine the bitmask later in platform independent code. v2: Don't map VIDEO_DIP_ENABLE to the null packet (Daniel) Put a FIXME in the lspcon function Signed-off-by: -
Ville Syrjälä authored
We have definitions and low level code for everything except the gamut metadata HDMI packet. Add the missing bits. Signed-off-by:
-
Abdiel Janulgue authored
This simplifies adding new query item objects. v2: Use query_hdr (Tvrtko, Chris). int instead of u32 in return (Tvrtko) v3: More naming fixes (Tvrtko) Signed-off-by:Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190211173251.7131-1-abdiel.janulgue@linux.intel.com
-
Chris Wilson authored
In selftests/live_hangcheck, we have a lot of tests for resetting simple spinners, but nothing quite prepared us for how the GPU reacted to triggering a reset outside of the safe spinner. These two subtests fill the ring with plain old empty, non-spinning requests, and then triggers a reset. Without a user-payload to blame, these requests will exercise the 'non-started' paths and mostly be replayed verbatim. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190226094922.31617-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
Having weaned the interrupt handling off using a single global execution queue, we no longer need to emit a global_seqno. Note that we still have a few assumptions about execution order along engine timelines, but this removes the most obvious artefact! Signed-off-by:
-
Chris Wilson authored
Stop accessing the HWSP to read the global seqno, and stop tracking the mirror in the engine's execution timeline -- it is unused. Signed-off-by:
-
Chris Wilson authored
To determine whether an engine has 'stuck', we simply check whether or not is still on the same seqno for several seconds. To keep this simple mechanism intact over the loss of a global seqno, we can simply add a new global heartbeat seqno instead. As we cannot know the sequence in which requests will then be completed, we use a primitive random number generator instead (with a cycle long enough to not matter over an interval of a few thousand requests between hangcheck samples). The alternative to using a dedicated seqno on every request is to issue a heartbeat request and query its progress through the system. Sadly this requires us to reduce struct_mutex so that we can issue requests without requiring that bkl. v2: And without the extra CS_STALL for the hangcheck seqno -- we don't need strict serialisation with what comes later, we just need to be sure we don't write the hangcheck seqno before our batch is flushed. Signed-off-by:
-
- 25 Feb, 2019 1 commit
-
-
José Roberto de Souza authored
The commit that this patch fixes changed the order of the parameters of MG_DP_MODE() but din't update the callers, breaking type-c on ICL. Fixes: 58106b7d ("drm/i915: Make MG PHY macros semantically consistent") Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Cc: Manasi navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190222202437.6575-1-jose.souza@intel.com
-
- 23 Feb, 2019 1 commit
-
-
Chris Wilson authored
As we no longer have a precise indication of requests queued to an engine, make no presumptions and just sample the ring registers to see if the engine is busy. v2: Report busy while the ring is idling on a semaphore/event. v3: Give the struct a name! v4: Always 0 outside the powerwell; trusting the powerwell is accurate enough for our sampling pmu. v5: Protect against gen7 mmio madness and try to improve grammar Signed-off-by:
-
- 22 Feb, 2019 4 commits
-
-
Rodrigo Vivi authored
Other than LPT, no other PCH needed to differentiate between LP and HP. So let's remove this before we spread this mistake to future platforms. Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
No functional change. Just a reorg to match the preferred behavior. v2: missing else (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
No functional change. Just a reorg to match the preferred behavior. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Chris Wilson authored
As we disable the log capture events, flush any residual interrupt before we flush and disable the worker. v2: Mika pointed out that it wasn't the worker re-queueing itself, but a rogue irq. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109716Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190221163833.21393-1-chris@chris-wilson.co.uk
-
- 21 Feb, 2019 4 commits
-
-
Chengguang Xu authored
unlikely has already included in IS_ERR(), so just remove redundant likely/unlikely annotation. Signed-off-by:
Chengguang Xu <cgxu519@gmx.com> Reviewed-by:
-
Chris Wilson authored
Annoyingly, struct_mutex was not entirely eliminated from the reset pathway; for reasons of its own, intel_display_resume() requires struct_mutex to prepare the planes it already captured. To avoid the immediate problem of a deadlock between the struct_mutex and the reset srcu, we have to acquire the reset_lock before struct_mutex in i915_gem_fault(). Now any wait underneath struct_mutex will result us in having to forcibly reset all inflight rendering, less than ideal, but better than a deadlock (and will do for the short term). Signed-off-by:
-
Uma Shankar authored
gamma mode mask was not considering the 30th and 31st bits. Due to this state readout was masking these bits, causing a mismatch and false warning, even though the registers were updated correctly. Dropped the gamma mode mask as it is redundant and ideally entire register content should be matching. This resolves the state mismatch warnings. Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/intel_hdcp.c:92 intel_hdcp2_capable() warn: inconsistent indenting drivers/gpu/drm/i915/intel_hdcp.c:786:5: error: no previous prototype for ‘intel_hdcp_check_link’ Signed-off-by:
-
- 20 Feb, 2019 19 commits
-
-
Sujaritha Sundaresan authored
This aim of this patch is to call guc_disable_communication in all suspend paths. The reason to introduce this is to resolve a bug that occurred due to suspend late not being called in the hibernate devices path. Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Sujaritha Sundaresan authored
The aim of this patch is to allow enabling and disabling of CTB without requiring the mutex lock. v2: Phasing out ctch_is_enabled function and replacing it with ctch->enabled (Daniele) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: -
Chris Wilson authored
Introduce a new ABI method for detecting a wedged driver by reporting -EIO from DRM_IOCTL_I915_GEM_CONTEXT_CREATE. This came up in considering how to handle context recovery from userspace. There we wish to create a new context after the original is banned (the clients opts into the no recovery after reset strategy) in order to rebuild the mesa context from scratch. In doing so, if the device was wedged and not the context banned, we would fall into a loop of permanently trying to recreate the context and never making forward progress. This patch would inform the client that we are no longer able to create a context, and the client would have no choice but to abort (or at least inform its callers about the lost device for anv). References: https://lists.freedesktop.org/archives/mesa-dev/2019-February/215469.htmlSigned-off-by:
-
Ville Syrjälä authored
On skl the crc registers were extended to provide plane crcs for up to 7 planes. Add the new crc sources. The current code uses the ivb+ register definitions for skl+ which does happen to work as the plane1, plane2, and dmux/pf bits happen the match what ivb+ had. So no bug in the current code. v2: Drop the unused set_wa parameter (DK) Signed-off-by:
-
Ville Syrjälä authored
DP CRCs don't really work on g4x. If you want any CRCs on DP you must select the CRC source before the port is enabled, otherwise the CRC source select bits simply ignore any writes to them. And once the port is enabled we mustn't change the CRC source select until the port is disabled. That almost works, but not quite :( Eventually the CRC source select bits get permanently stuck one way or the other, and after that a reboot (or possibly a display reset) is needed to get working CRCs on that pipe (not matter which CRC source we try to use). Additionally the DFT scrambler reset bits we're trying to use don't seem to exist on g4x. There are some potentially relevant looking bits in the pipe registers, but when I tried it I got stable looking CRCs without setting any bits for this. If there is a way to make DP CRCs work reliably on g4x, I wasn't able to find it. So let's just remove the broken code we have. Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
-
Ville Syrjälä authored
We assume that the index of the string in the crc source names array matches the enum value for the crc source. Let's use named initializers to make sure that is indeed the case even if someone rearranges either the enum or the array. Signed-off-by:
-
Ville Syrjälä authored
The "pipe" and "pf" crc sources are in fact the same thing. Remove the "pf" one. Signed-off-by:
-
Chris Wilson authored
Limit deboosting and boosting to keep ourselves at the extremes when in the respective power modes (i.e. slowly decrease frequencies while in the HIGH_POWER zone and slowly increase frequencies while in the LOW_POWER zone). On idle, we will hit the timeout and drop to the next level quickly, and conversely if busy we expect to hit a waitboost and rapidly switch into max power. This should improve the UX experience by keeping the GPU clocks higher than they ostensibly should be (based on simple busyness) by switching into the INTERACTIVE mode (due to waiting for pageflips) and increasing clocks via waitboosting. This will incur some additional power, our saving grace should be rc6 and powergating to keep the extra current draw in check. Food for future thought would be deadline scheduling? If we know certain contexts (high priority compositors) absolutely must hit the next vblank then we can raise the frequencies ahead of time. Part of this is covered by per-context frequencies, where userspace is given control over the frequency range they want the GPU to execute at (for largely the same problem as this, where the workload is very latency sensitive but at the EI level appears mostly idle). Indeed, the per-context series does extend the modeset boosting to include a frequency range tweak which seems applicable to solving this jittery UX behaviour. Reported-by:
Lyude Paul <lyude@redhat.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109408 References: 0d55babc ("drm/i915: Drop stray clearing of rps->last_adj") References: 60548c55 ("drm/i915: Interactive RPS mode") Signed-off-by:
-
Ramalingam C authored
HDCP transmitter is supposed to indicate the HDCP encryption status of the link through enc_en signals in a window of time called "window of opportunity" defined by HDCP HDMI spec. But on KBL this timing of signalling has an issue. To fix the issue this WA of resetting the signalling is required. v2: WA is moved into the toggle_signalling [Daniel] v3: Commit msg is rewritten with more information v4: Reviewed-by Daniel. Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
-
Ramalingam C authored
Implements the Waitqueue is created to wait for CP_IRQ Signaling the CP_IRQ arrival through atomic variable. For applicable DP HDCP2.2 msgs read wait for CP_IRQ. As per HDCP2.2 spec "HDCP Transmitters must process CP_IRQ interrupts when they are received from HDCP Receivers" Without CP_IRQ processing, DP HDCP2.2 H_Prime msg was getting corrupted while reading it based on corresponding status bit. This creates the random failures in reading the DP HDCP2.2 msgs. v2: CP_IRQ arrival is tracked based on the atomic val inc [daniel] Recording the reviewed-by Daniel from IRC. Signed-off-by:
-
Ramalingam C authored
Implements the HDMI adaptation specific HDCP2.2 operations. Basically these are DDC read and write for authenticating through HDCP2.2 messages. v2: Rebased. v3: No more special handling of Gmbus burst read for AKE_SEND_CERT. Style fixed with few naming. [Uma] %s/PARING/PAIRING v4: msg_sz is initialized at definition. Lookup table is defined for HDMI HDCP2.2 msgs [Daniel]. v5: Rebased. v6: Make a function as inline [Uma] %s/uintxx_t/uxx v7: Errors due to sinks are reported as DEBUG logs. Adjust to the new mei interface. v8: ARRAY_SIZE for the # of array members [Jon & Daniel]. hdcp adaptation is added as a const in the hdcp_shim [Daniel] Signed-off-by:
-
Ramalingam C authored
Implements the DP adaptation specific HDCP2.2 functions. These functions perform the DPCD read and write for communicating the HDCP2.2 auth message back and forth. v2: wait for cp_irq is merged with this patch. Rebased. v3: wait_queue is used for wait for cp_irq [Chris Wilson] v4: Style fixed. %s/PARING/PAIRING Few style fixes [Uma] v5: Lookup table for DP HDCP2.2 msg details [Daniel]. Extra lines are removed. v6: Rebased. v7: Fixed some regression introduced at v5. [Ankit] Macro HDCP_2_2_RX_CAPS_VERSION_VAL is reused [Uma] Converted a function to inline [Uma] %s/uintxx_t/uxx v8: Error due to the sinks are reported as DEBUG logs. Adjust to the new mei interface. v9: ARRAY_SIZE for no of array members [Jon & Daniel] return of the wait_for_cp_irq is made as void [Daniel] Wait for HDCP2.2 msg is done based on polling the reg bit than CP_IRQ based. [Daniel] hdcp adaptation is added as a const in the hdcp_shim [Daniel] v10: config_stream_type is redefined [Daniel] DP Errata specific defines are moved into intel_dp.c. Signed-off-by:Ankit K Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
-
Ramalingam C authored
Since DP ERRATA message is not defined at spec, those structure definition is removed from drm_hdcp.h Signed-off-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
-
Ramalingam C authored
When repeater notifies a downstream topology change, this patch reauthenticate the repeater alone without disabling the hdcp encryption. If that fails then complete reauthentication is executed. v2: Rebased. v3: Typo in commit msg is fixed [Uma] v4: Rebased as part of patch reordering. Minor style fixes. v5: Rebased. v6: Rebased. v7: Errors due to sinks are reported as DEBUG logs. Signed-off-by:
-
Ramalingam C authored
Implements the link integrity check once in 500mSec. Once encryption is enabled, an ongoing Link Integrity Check is performed by the HDCP Receiver to check that cipher synchronization is maintained between the HDCP Transmitter and the HDCP Receiver. On the detection of synchronization lost, the HDCP Receiver must assert the corresponding bits of the RxStatus register. The Transmitter polls the RxStatus register and it may initiate re-authentication. v2: Rebased. v3: enum check_link_response is used check the link status [Uma] v4: Rebased as part of patch reordering. v5: Required members of intel_hdcp is defined [Sean Paul] v6: hdcp2_check_link is cancelled at required places. v7: Rebased for the component i/f changes. Errors due to the sinks are reported as DEBUG logs. v8: hdcp_check_work is used for both hdcp1 and hdcp2 check_link [Daniel] hdcp2.2 encryption status check is put under WARN_ON [Daniel] drm_hdcp.h changes are moved into separate patch [Daniel] v9: enum check_link_status is defined at intel_drv.h [Daniel] Signed-off-by:
-
Ramalingam C authored
Time period for HDCP2.2 link check. Signed-off-by:
-
Ramalingam C authored
Implements the HDCP2.2 repeaters authentication steps such as verifying the downstream topology and sending stream management information. v2: Rebased. v3: -EINVAL is returned for topology error and rollover scenario. Endianness conversion func from drm_hdcp.h is used [Uma] v4: Rebased as part of patches reordering. Defined the mei service functions [Daniel] v5: Redefined the mei service functions as per comp redesign. v6: %s/uintxx_t/uxx Check for comp_master is removed. v7: Adjust to the new mei interface. style issue fixed. v8: drm_hdcp.h change is moved into separate patch [Daniel] v9: %s/__swab16/cpu_to_be16. [Tomas] Reviewed-by Uma. Signed-off-by:
-
Ramalingam C authored
Implements HDCP2.2 authentication for hdcp2.2 receivers, with following steps: Authentication and Key exchange (AKE). Locality Check (LC). Session Key Exchange(SKE). DP Errata for stream type configuration for receivers. At AKE, the HDCP Receiver’s public key certificate is verified by the HDCP Transmitter. A Master Key k m is exchanged. At LC, the HDCP Transmitter enforces locality on the content by requiring that the Round Trip Time (RTT) between a pair of messages is not more than 20 ms. At SKE, The HDCP Transmitter exchanges Session Key ks with the HDCP Receiver. In DP HDCP2.2 encryption and decryption logics use the stream type as one of the parameter. So Before enabling the Encryption DP HDCP2.2 receiver needs to be communicated with stream type. This is added to spec as ERRATA. This generic implementation is complete only with the hdcp2 specific functions defined at hdcp_shim. v2: Rebased. v3: %s/PARING/PAIRING Coding style fixing [Uma] v4: Rebased as part of patch reordering. Defined the functions for mei services. [Daniel] v5: Redefined the mei service functions as per comp redesign. Required intel_hdcp members are defined [Sean Paul] v6: Typo of cipher is Fixed [Uma] %s/uintxx_t/uxx Check for comp_master is removed. v7: Adjust to the new interface. Avoid using bool structure members. [Tomas] v8: Rebased. v9: bool is used in struct intel_hdcp [Daniel] config_stream_type is redesigned [Daniel] Reviewed-by Uma. Signed-off-by:
-
Ramalingam C authored
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled. When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is enabled. This change implements a sequence of enabling and disabling of HDCP2.2 authentication and HDCP2.2 port encryption. v2: Included few optimization suggestions [Chris Wilson] Commit message is updated as per the rebased version. intel_wait_for_register is used instead of wait_for. [Chris Wilson] v3: Extra comment added and Style issue fixed [Uma] v4: Rebased as part of patch reordering. HDCP2 encryption status is tracked. HW state check is moved into WARN_ON [Daniel] v5: Redefined the mei service functions as per comp redesign. Merged patches related to hdcp2.2 enabling and disabling [Sean Paul]. Required shim functionality is defined [Sean Paul] v6: Return values are handles [Uma] Realigned the code. Check for comp_master is removed. v7: HDCP2.2 is attempted only if mei interface is up. Adjust to the new interface Avoid bool usage in struct [Tomas] v8: mei_binded status check is removed. %s/hdcp2_in_use/hdcp2_encrypted v9: bool is used in struct intel_hdcp. [Daniel] v10: panel is replaced with sink [Uma] Mei interface decided the hdcp2_capability. WARN_ON if hdcp_enable is called when hdcp state is ENABLED. Reviewed-by Uma. Signed-off-by:
-
