- 11 Jul, 2019 8 commits
-
-
Chris Wilson authored
Preemption via GuC submission is not being supported with its current legacy incarnation. The current FW does support a similar pre-emption flow via H2G, but it is class-based instead of being instance-based, which doesn't fit well with the i915 tracking. To fix this, the firmware is being updated to better support our needs with a new flow, so we can safely remove the old code. v2 (Daniele): resurrect & rebase, reword commit message, remove preempt_context as well Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Acked-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190710005437.3496-2-daniele.ceraolospurio@intel.com
-
Chris Wilson authored
Specify that we do want a 64b value for sizeof(u32) as we want to compute the mask of the upper 62bits. v2: Use round_down() for automatic type promotion Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190710161413.7115-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
The extra w/a was revived in the backmerge that was meant to fix it! Fixes: 88c90e80 ("Merge drm/drm-next into drm-intel-next-queued") Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190710200428.3275-1-chris@chris-wilson.co.uk
-
Matt Roper authored
EHL has four DDI's (DDI-A and DDI-D share combo PHY A). Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190709183934.445-6-matthew.d.roper@intel.com
-
Matt Roper authored
Transition the remaining uses of intel_port_is_* over to the equivalent intel_phy_is_* functions and drop the port functions. v5: Fix a call in a debug function that's only called when CONFIG_DRM_I915_DEBUG_RUNTIME_PM is on. (CI) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Matt Roper authored
Convert the code that operates directly on gen11 combo PHY's to use the new namespace. Combo PHY registers are those named "ICL_PORT_*" plus ICL_DPHY_CHKN. Note that a lot of the PHY programming happens in the MIPI DSI code. For clarity I've added a for_each_dsi_phy() to loop over the phys used by DSI. Since DSI always uses A & B on gen11, port=phy in all cases so it doesn't actually matter which form we use in the DSI code. I've used the phy iterator in code that's explicitly working with the combo PHY, but left the rest of the DSI code using the port iterator and namespace to minimize patch deltas. We can switch the rest of the DSI code over to use phy terminology later if this winds up being too confusing. v6: Drop an include of drm/i915_drm.h; that was previously included just for the definition of 'enum port' which this patch removes the need for. (Jose) Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: -
Matt Roper authored
Although the register name implies that it operates on DDI's, DPCLKA_CFGCR0_ICL actually needs to be programmed according to the PHY that's in use. I.e., when using EHL's DDI-D on combo PHY A, the bits described as "port A" in the bspec are what we need to set. The bspec clarifies: "[For EHL] DDID clock tied to DDIA clock, so DPCLKA_CFGCR0 DDIA Clock Select chooses the PLL for both DDIA and DDID and drives port A in all cases." Also, since the CNL DPCLKA_CFGCR0 bit defines are still port-based, we create separate ICL-specific defines that accept the PHY rather than trying to share the same bit definitions between CNL and ICL. v5: Make icl_dpclka_cfgcr0_clk_off() take phy rather than port. When splitting the original patch the hunk to handle this wound up too late in the series. (Sparse) v6: Since we're already changing this code, s/DPCLKA_CFGCR0_ICL/ICL_DPCLKA_CFGCR0/ for consistency. (Jose) Bspec: 33148 Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: -
Matt Roper authored
Our past DDI-based Intel platforms have had a fixed DDI<->PHY mapping. Because of this, both the bspec documentation and our i915 code has used the term "port" when talking about either DDI's or PHY's; it was always easy to tell what terms like "Port A" were referring to from the context. Unfortunately this is starting to break down now that EHL allows PHY-A to be driven by either DDI-A or DDI-D. Is a setup with DDI-D driving PHY-A considered "Port A" or "Port D?" The answer depends on which register we're working with, and even the bspec doesn't do a great job of clarifying this. Let's try to be more explicit about whether we're talking about the DDI or the PHY on gen11+ by using 'port' to refer to the DDI and creating a new 'enum phy' namespace to refer to the PHY in use. This patch just adds the new PHY namespace, new phy-based versions of intel_port_is_*(), and a helper to convert a port to a PHY. Transitioning various areas of the code over to using the PHY namespace will be done in subsequent patches to make review easier. We'll remove the intel_port_is_*() functions at the end of the series when we transition all callers over to using the PHY-based versions. v2: - Convert a few more 'port' uses to 'phy.' (Sparse) v3: - Switch DDI_CLK_SEL() back to 'port.' (Jose) - Add a code comment clarifying why DPCLKA_CFGCR0_ICL needs to use PHY for its bit definitions, even though the register description is given in terms of DDI. - To avoid confusion, switch CNL's DPCLKA_CFGCR0 defines back to using port and create separate ICL+ definitions that work in terms of PHY. v4: - Rebase and resolve conflicts with Imre's TC series. - This patch now just adds the namespace and a few convenience functions; the important changes are now split out into separate patches to make review easier. Suggested-by:
-
- 10 Jul, 2019 9 commits
-
-
Lucas De Marchi authored
PORT_TX_DFLEXDPMLE1 is a FIA register so move it to intel_tc.c where we access other FIA registers. In Tiger Lake we have multiple/modular FIAs so it makes sense to start moving all access to their registers to a common place. While at it, make it clear that we will only ever call this function for ports with TC phy. Previously we were relying on tc_mode being TC_PORT_TBT_ALT for combo phy ports. However it's confusing since in this same function we have checks for is_tc_port. Also, if we manage to make each phy access only their own field, we may in future add them as a union inside intel_digital_port. v2: Fix coding style while moving the code Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190708172815.6814-4-lucas.demarchi@intel.com
-
Lucas De Marchi authored
Separate local includes with a blank line and sort the groups alphabetically. v2: don't make intel_tc.h be the first include v3: don't make local includes be included first Signed-off-by:
-
Lucas De Marchi authored
Let's make the just created intel_tc.c already follow the trend of using i915 instead of dev_priv and calling the intel_uncore_*() functions. Signed-off-by:
-
Rodrigo Vivi authored
Catch-up with 5.2. Specially to remove a drm-tip merge fixup around intel_workarounds. Signed-off-by: -
Uma Shankar authored
Input CSC Co-efficients for BT601 and BT709 YCbCR to RGB conversion were slightly off. Fixed the same. v2: Fixed the co-eficients as there was issue with reference matrix, spotted by Ville. v3: Rebase Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Uma Shankar authored
Fixed Y Pre-offset in case of Full Range YCbCr. v2: Rebase Reviewed-by:
-
Uma Shankar authored
Currently input csc for YCbCR to RGB conversion handles only BT601 and Bt709. Extending it to support BT2020 as well. v2: Fixed the co-efficients for LR to FR conversion, as suggested by Ville. v3: Fixed Y Pre-offset in case of Full Range YCbCr as suggested by Ville. v4: Split the v2 and v3 changes. v5: Rebase v6: Fix a rebase fumble. Reviewed-by:
Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
-
Lionel Landwerlin authored
This was dropped from the original patch series, we weren't sure whether it was needed at the time. More recent tests show it's definitely needed to have acurate performance data. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 19f81df2 ("drm/i915/perf: Add OA unit support for Gen 8+") Acked-by:
-
Chris Wilson authored
Put back the preemption counters lost in commit 22b7a426 ("drm/i915/execlists: Preempt-to-busy") so that our selftests that assert no preemption took place continue to function. v2: But a timeslice is only a "soft" preemption! Fixes: 22b7a426 ("drm/i915/execlists: Preempt-to-busy") Signed-off-by:
-
- 09 Jul, 2019 18 commits
-
-
Tvrtko Ursulin authored
There are no known plans to start using it either. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Lionel Landwerlin authored
We want to set this flag in the next commit on requests containing perf queries so that the result of the perf query can just be a delta of global counters, rather than doing post processing of the OA buffer. Signed-off-by:
-
Lionel Landwerlin authored
We have a bunch of offsets in the scratch buffer. As we're about to add some more, let's group all of the offsets in a common location. Signed-off-by:
-
Lionel Landwerlin authored
The i915 perf stream has its own file descriptor and is tied to reference of the driver. We haven't taken care of keep the driver alive. Signed-off-by:
-
Chris Wilson authored
If we map an object as readonly into the GTT, we know that the GPU cannot have written to it and so the object is not dirty and we don't need to flush the writes back to the system. Signed-off-by:
-
Imre Deak authored
For consistency clear the icl_port_dplls from the new crtc state, when releasing the DPLLs from the old crtc state. Leaving them set could result in releasing the same PLLs multiple times from the same CRTC state incorrectly (if the same CRTC was first used for a TypeC port then for a combo PHY port). Leaving the stale pointers behind happens not to cause a problem atm (since the incorrect releasing will be a NOP), but we need to fix that for consistency. Signed-off-by:
-
Imre Deak authored
For symmetry with the get_dplls() hook which sets the shared_dpll pointer clear the same pointer from the put_dplls() hook. While at it also constify the old crtc state. v2: - Constify the old crtc state. (Ville) Signed-off-by:
-
Ville Syrjälä authored
Add sdvo_cmd_name() and sdvo_cmd_status() helpers to avoid bothering the callers with the implementation details of the storage for these strings. Signed-off-by:
-
Ville Syrjälä authored
Drop the redundant "SDVO_CMD_" prefix from the command name strings in sdvo_cmd_names[]. While at it throw away the unused struct name, and undef SDVO_CMD_NAME_ENTRY() when we're done. Signed-off-by:
-
Ville Syrjälä authored
sdvo_cmd_names[] contains two entries for SET_INPUT_TIMINGS_PART1. Remove one of them. Signed-off-by:
-
Ville Syrjälä authored
Use named initializers to make it easier to associate the SDVO debug prints with the SDVO command defines. Also switch to using ARRAY_SIZE() instead of assuming that SDVO_CMD_STATUS_SCALING_NOT_SUPP is the last command type. Signed-off-by:
-
Vandita Kulkarni authored
Add scaling and panel orientation properties for icl mipi dsi. v2: Add platform specific function (Ville) v3: Remove redundant check and update scaler call (Jani, Ville) Signed-off-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
-
Ramalingam C authored
Adding few more debug logs to identify the sink specific HDCP failures along with a out of mem failure. v2: Capturing the Bug and a-b Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110991Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Signed-off-by:
Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190708113319.2517-1-ramalingam.c@intel.com
-
Chris Wilson authored
We now track features correctly instead of probing i915->engine[RCS0] which is much more flexible and avoids any nasty surprises. Signed-off-by:
-
Chris Wilson authored
Treat all render engines to the RCS workarounds, simply to avoid using engine->id when we are trying to think in terms of classes. Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190705124325.14270-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Initialise the dma_fence innards in preparation for making dma_fence_signal() always check the callback list. Signed-off-by:
-
Chris Wilson authored
set_page_dirty says: For pages with a mapping this should be done under the page lock for the benefit of asynchronous memory errors who prefer a consistent dirty state. This rule can be broken in some special cases, but should be better not to. Under those rules, it is only safe for us to use the plain set_page_dirty calls for shmemfs/anonymous memory. Userptr may be used with real mappings and so needs to use the locked version (set_page_dirty_lock). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317 Fixes: 5cc9ed4b ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") References: 6dcc693b ("ext4: warn when page is dirtied without buffers") Signed-off-by:
-
Chris Wilson authored
Set up a default gt pointer for an early cleanup of igt_spinnter, before a request is created and igt_spinner.gt set to the active engine's. Signed-off-by:
-
- 08 Jul, 2019 3 commits
-
-
Rodrigo Vivi authored
Signed-off-by: -
Chris Wilson authored
Reorder the error paths so that we unwind all the locals from any error path and so avoid setting off divers alarum in case we find an error in case we find an error. References: https://bugs.freedesktop.org/show_bug.cgi?id=111048Signed-off-by:
-
Chris Wilson authored
Stop guessing over whether we have an extra wakeref held by the delayed fw put, and track it explicitly for the sake of debug. Signed-off-by:
-
- 07 Jul, 2019 1 commit
-
-
Chris Wilson authored
Make no assumption that something in the background is not acquiring the fw_domain -- but we still do not track owner so assume that any active domain is intended by the caller. Signed-off-by:
-
- 06 Jul, 2019 1 commit
-
-
Mika Kuoppala authored
By encapsulating the locking upper level and used check for entry into a helper function, we can use it in all callsites. v2: get rid of atomic_reads on lower level clears (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
