- 11 Jul, 2019 29 commits
-
-
José Roberto de Souza authored
On TGL the special EDP transcoder is gone and it should be handled by transcoder A. v2 (Lucas): - Reuse POWER_DOMAIN_TRANSCODER_EDP_VDSC (suggested by Ville) - Use crtc->dev since new_crtc_state->state may be NULL on atomic commit (suggested by Maarten) v3 (Lucas): - Rename power domain so it's clear it can also be used for transcoder A in TGL (requested by José and Manasi) Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Acked-by:
Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190711173115.28296-8-lucas.demarchi@intel.com
-
José Roberto de Souza authored
On Tiger Lake there is one more pipe - check if it's fused. Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190711173115.28296-7-lucas.demarchi@intel.com
-
Lucas De Marchi authored
Current list of PCI IDs for Tiger Lake. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Mahesh Kumar authored
Assume PCH_TGP when platform is TGL. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190711173115.28296-5-lucas.demarchi@intel.com
-
Radhakrishna Sripada authored
Add the enum additions to TGP. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: David Weinehall <david.weinehall@intel.com> Cc: James Ausmus <james.ausmus@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
Tiger Lake is a Intel
® Processor containing Intel® HD Graphics. This is just an initial Tiger Lake definition. PCI IDs, generic support and new features coming in following patches. v2 (Lucas): - Remove modular FIA - feature will be re-introduced in future Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Add pipe D and transcoder D to prepare for platforms having them. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190711173115.28296-2-lucas.demarchi@intel.com
-
Ville Syrjälä authored
With 4:2:0 output the LS clock can be half of what it is with 4:4:4. Make that happen. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Tested-by:
-
Steven Rostedt (VMware) authored
Currently the intel_update_plane and intel_disable_plane tracepoints record the address of plane->name in the ring buffer, and then when reading the ring buffer uses %s to get the name. The issue with this, is that those two events can be minutes, hours or even days apart. It is very dangerous to dereference a string pointer without knowing if it still exists or not. The proper way to handle this is to use the __string() macro in the tracepoint which will save the string into the ring buffer at the time of recording. Then there's no worries if the original string still exists in memory when the ring buffer is read. Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> [vsyrjala: Rebase on top of drm-tip] Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/intel_guc_submission.c:799: warning: Excess function parameter 'ctx' description in 'guc_client_alloc' Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Zero initialize val2 so that we don't pass stack garbage to the pcode qgv read command. I suspect in this case pcode just ignores the initial value in that registers, but better safe than sorry. Cc: Dan Carpenter <dan.carpenter@oracle.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Ville Syrjälä authored
Make life less annoying by favoring the intel_ types over the drm_ types in intel_atomic_commit(). Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
Streamline the code a bit by using intel_ types instead of the drm_ types. Signed-off-by:
-
Ville Syrjälä authored
Streamline the code a bit by using intel_ types instead of drm_ types in intel_atomic_track_fbs(). Signed-off-by:
-
Ville Syrjälä authored
Use swap() instead of hand rolling it in intel_shared_dpll_swap_state(), and pass in the intel_atomic_state instead of drm_atomic_state. Makes the code less convoluted. Signed-off-by:
-
Ville Syrjälä authored
Pass just the crtc state to modeset_get_crtc_power_domains(). We can get the crtc from therein. Signed-off-by:
-
Ville Syrjälä authored
wm.mutex does not protect the crtc state so no point in grabbing it to check crtc_state->wm.need_postvbl_update. Also do a bit of s/intel_crtc/crtc/ while at it. Signed-off-by:
-
Ville Syrjälä authored
The PFI credit programming performed during cdclk change on vlv/chv requires access to a register in the disp2d power well. So far we've abused pipe-A power domain for this, but now we have the more appropriate "display core" domain so let's make use of it. Signed-off-by:
-
Chris Wilson authored
Right idea, wrong lock. We already drop struct_mutex before we free the mmap_offset when freeing the object, so we need to take the vma manager lock when manipulating the mmap_offset address space for our selftests. Fixes: 8221d21b ("drm/i915/selftests: Lock the drm_mm while modifying") Signed-off-by:
-
Ville Syrjälä authored
The spec says: "A value of 0 indicates that this buffer does not exist" So we should not convert a hbuf_size of 0 into 1. Also pull the relevant code into a helper to avoid making the same mistake multiple times. And while at it fix the debug prints to not say "hbuf_len" twice. v2: s/%i/%u/ in the debug (Imre) Signed-off-by:
-
Daniele Ceraolo Spurio authored
We originally added support, in some cases partial, for different modes of operations via guc clients: - proxy vs direct submission; - variable engine mask per-client. We only ever used one flow (all submissions via a single proxy), so the other code paths haven't been exercised and are most likely non-functional. The guc firmware interface is also in the process of being updated to better fit the i915 flow and our client abstraction will need to change accordingly (or possibly go away entirely), so these old unused paths can be considered dead and removed. Signed-off-by:
Matthew Brost <Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
-
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 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:
-
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:
-
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: -
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 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 2 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:
-
