[Intel-gfx] [PATCH v4 01/11] drm/i915/dp: use the sink rates array for max sink rates

Looking at DPCD DP_MAX_LINK_RATE may be completely bogus for eDP 1.4 which is allowed to use link rate select method and have 0 in max link rate. With this change, it makes sense to store the max rate as the actual rate rather than as a bw code. Cc: Manasi Navare Cc:

[Intel-gfx] [PATCH v4 11/11] drm/i915: Implement Link Rate fallback on Link training failure

From: Manasi Navare If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed, update the link status property to

[Intel-gfx] [PATCH v4 09/11] drm/i915/dp: read sink count to a temporary variable first

Don't clobber intel_dp->sink_count with the raw value. Suggested-by: Ville Syrjälä Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dp.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git

[Intel-gfx] [PATCH v4 05/11] drm/i915/dp: add functions for max common link rate and lane count

These are the theoretical maximums common for source and sink. These are the maximums we should start with. They may be degraded in case of link training failures, and the dynamic link values are stored separately. Cc: Manasi Navare Cc: Ville Syrjälä

[Intel-gfx] [PATCH v4 08/11] drm/i915/dp: use readb and writeb calls for single byte DPCD access

This is what we have the readb and writeb variants for. Do some minor return value and variable cleanup while at it. Cc: Manasi Navare Cc: Ville Syrjälä Reviewed-by: Manasi Navare Signed-off-by: Jani Nikula

[Intel-gfx] [PATCH v4 04/11] drm/i915/dp: don't call the link parameters sink parameters

If we modify these on the fly depending on the link conditions, don't pretend they are sink properties. Some link vs. sink confusion still remains, but we'll take care of them in follow-up patches. Cc: Manasi Navare Cc: Ville Syrjälä

[Intel-gfx] [PATCH v4 06/11] drm/i915/mst: use max link not sink lane count

The source might not support as many lanes as the sink, or the link training might have failed at higher lane counts. Take these into account. Cc: Dhinakaran Pandiyan Cc: Manasi Navare Cc: Ville Syrjälä

[Intel-gfx] [PATCH v4 10/11] drm/i915/dp: Validate cached link rate and lane count before retraining

From: Manasi Navare Currently intel_dp_check_link_status() tries to retrain the link if Clock recovery or Channel EQ for any of the lanes indicated by intel_dp->lane_count is not set. However these values cached in intel_dp structure can be stale if link training has

[Intel-gfx] [PATCH v4 00/11] drm/i915/dp: rest of refactoring, link rate fallback

v4 of [1], after patches 1-5 have been merged, and with Manasi's patches [2] and [3] rebased on top. BR, Jani. [1] cover.1490712890.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1490712890.git.jani.nikula@intel.com [2]

[Intel-gfx] [PATCH v4 02/11] drm/i915/dp: cache common rates with sink rates

Now that source rates are static and sink rates are updated whenever DPCD is updated, we can do and cache the intersection of them whenever sink rates are updated. This reduces code complexity, as we don't have to keep calling the functions to intersect. We also get rid of several common rates

[Intel-gfx] [PATCH v4 03/11] drm/i915/dp: do not limit rate seek when not needed

In link training fallback, we're trying to find a rate that we know is in a sorted array of common link rates. We don't need to limit the array using the max rate. For test request, the DP CTS doesn't say we should limit the rate based on earlier fallback. This lets us get rid of

[Intel-gfx] [PATCH v4 07/11] drm/i915/dp: localize link rate index variable more

Localize link_rate_index to the if block, and rename to just index to reduce indent. Cc: Manasi Navare Cc: Ville Syrjälä Reviewed-by: Manasi Navare Signed-off-by: Jani Nikula ---

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/scheduler: add gvt notification for guc

On Thu, Apr 06, 2017 at 02:05:15PM +, Dong, Chuanxiao wrote: > > > > -Original Message- > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > > Sent: Thursday, April 6, 2017 9:32 PM > > To: Dong, Chuanxiao > > Cc: intel-gfx@lists.freedesktop.org;

Re: [Intel-gfx] [PATCH v4 10/11] drm/i915/dp: Validate cached link rate and lane count before retraining

On Thu, Apr 06, 2017 at 04:44:18PM +0300, Jani Nikula wrote: > From: Manasi Navare > > Currently intel_dp_check_link_status() tries to retrain the link if > Clock recovery or Channel EQ for any of the lanes indicated by > intel_dp->lane_count is not set. However these

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/scheduler: add gvt notification for guc

> -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Thursday, April 6, 2017 10:19 PM > To: Dong, Chuanxiao > Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org; > Zheng, Xiao; Tian, Kevin; joonas.lahti...@linux.intel.com > Subject:

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/scheduler: add gvt notification for guc

On Tue, Mar 28, 2017 at 05:38:41PM +0800, Chuanxiao Dong wrote: > GVT request needs a manual mmio load/restore. Before GuC submit > a request, send notification to gvt for mmio loading. And after > the GuC finished this GVT request, notify gvt again for mmio > restore. This follows the usage when

Re: [Intel-gfx] [PATCH v4 01/11] drm/i915/dp: use the sink rates array for max sink rates

On Thu, Apr 06, 2017 at 04:44:09PM +0300, Jani Nikula wrote: > Looking at DPCD DP_MAX_LINK_RATE may be completely bogus for eDP 1.4 > which is allowed to use link rate select method and have 0 in max link > rate. With this change, it makes sense to store the max rate as the > actual rate rather

Re: [Intel-gfx] [PATCH v4 09/11] drm/i915/dp: read sink count to a temporary variable first

On Thu, Apr 06, 2017 at 04:44:17PM +0300, Jani Nikula wrote: > Don't clobber intel_dp->sink_count with the raw value. > > Suggested-by: Ville Syrjälä > Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä >

Re: [Intel-gfx] [PATCH 0/4] drm/atomic: Cleanups for adding connector atomic check function.

On Thu, Apr 06, 2017 at 01:18:59PM +0200, Maarten Lankhorst wrote: > Some small cleanups I came across to make drm_atomic_helper_check_modeset > more readable. > > This makes it a lot more clear what atomic_check does and why it's called in > the place it is. > > Maarten Lankhorst (4): >

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/scheduler: add gvt notification for guc

> -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Thursday, April 6, 2017 9:32 PM > To: Dong, Chuanxiao > Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org; > Zheng, Xiao; Tian, Kevin; joonas.lahti...@linux.intel.com > Subject: Re:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: rest of refactoring, link rate fallback

== Series Details == Series: drm/i915/dp: rest of refactoring, link rate fallback URL : https://patchwork.freedesktop.org/series/22586/ State : success == Summary == Series 22586v1 drm/i915/dp: rest of refactoring, link rate fallback

Re: [Intel-gfx] [PATCH v3 4/7] drm/i915/perf: Add OA unit support for Gen 8+

On 05/04/17 17:23, Robert Bragg wrote: Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all share (more-or-less) the same OA unit design. Of particular note in comparison to Haswell: some OA unit HW config state has become per-context state and as a consequence it is somewhat

[Intel-gfx] [PATCH 1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework

Remove the per-mmio checking of the FIFO debug register into the common conditional mmio debug handling. Based on patch from Chris Wilson. v2: postpone warn on fifodbg for unclaimed reg debugs Signed-off-by: Mika Kuoppala Reviewed-by: Chris Wilson

[Intel-gfx] [PATCH 2/2] drm/i915: Use wait_for_atomic_us when waiting for gt fifo

Replace the handcrafter loop when checking for fifo slots with atomic wait for. This brings this wait in line with the other waits on register access. We also get a readable timeout constraint, so make it to fail after 10ms. Chris suggested that we should fail silently as the fifo debug handler,

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework (rev2)

== Series Details == Series: series starting with [1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework (rev2) URL : https://patchwork.freedesktop.org/series/22571/ State : success == Summary == Series 22571v2 Series without cover letter

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework

On Thu, Apr 06, 2017 at 06:46:29PM +0300, Ville Syrjälä wrote: > On Thu, Apr 06, 2017 at 06:39:42PM +0300, Mika Kuoppala wrote: > > +static bool > > check_for_unclaimed_mmio(struct drm_i915_private *dev_priv) > > { > > + bool ret = false; > > + > > if (HAS_FPGA_DBG_UNCLAIMED(dev_priv)) > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework (rev3)

== Series Details == Series: series starting with [1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework (rev3) URL : https://patchwork.freedesktop.org/series/22571/ State : failure == Summary == Series 22571v3 Series without cover letter

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/scheduler: add gvt notification for guc

On Thu, Apr 06, 2017 at 02:49:54PM +, Dong, Chuanxiao wrote: > > > > -Original Message- > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > > Sent: Thursday, April 6, 2017 10:19 PM > > To: Dong, Chuanxiao > > Cc: intel-gfx@lists.freedesktop.org;

[Intel-gfx] [PATCH v3] drm/i915: Advance ring->head fully when idle

When we retire the last request on the ring, before we ever access that ring again we know it will be completely idle and so we can advance the ring->head fully to the end (i.e. ring->tail) and not just to the start of the breadcrumb. This allows us to skip re-emitting the breadcrumb after

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Assert the engine is idle before overwiting the HWS (rev3)

== Series Details == Series: series starting with [1/2] drm/i915: Assert the engine is idle before overwiting the HWS (rev3) URL : https://patchwork.freedesktop.org/series/22527/ State : success == Summary == Series 22527v3 Series without cover letter

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework

On Thu, Apr 06, 2017 at 05:05:10PM +0100, Chris Wilson wrote: > On Thu, Apr 06, 2017 at 06:46:29PM +0300, Ville Syrjälä wrote: > > On Thu, Apr 06, 2017 at 06:39:42PM +0300, Mika Kuoppala wrote: > > > +static bool > > > check_for_unclaimed_mmio(struct drm_i915_private *dev_priv) > > > { > > > +

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/scheduler: add gvt notification for guc

> -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Thursday, April 6, 2017 11:07 PM > To: Dong, Chuanxiao > Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org; > Zheng, Xiao; Tian, Kevin; joonas.lahti...@linux.intel.com; Wang, Zhi A

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use wait_for_atomic_us when waiting for gt fifo

On Thu, Apr 06, 2017 at 06:40:16PM +0300, Mika Kuoppala wrote: > Replace the handcrafter loop when checking for fifo slots > with atomic wait for. This brings this wait in line with > the other waits on register access. We also get a readable > timeout constraint, so make it to fail after 10ms. >

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework

On Thu, Apr 06, 2017 at 06:39:42PM +0300, Mika Kuoppala wrote: > Remove the per-mmio checking of the FIFO debug register into the common > conditional mmio debug handling. Based on patch from Chris Wilson. > > v2: postpone warn on fifodbg for unclaimed reg debugs > > Signed-off-by: Mika Kuoppala

Re: [Intel-gfx] [PATCH 12/15] drm: Add acquire ctx to ->gamma_set hook

Daniel Vetter writes: > Atomic helpers really want this instead of the hacked-up legacy > backoff trick, which unfortunately prevents drivers from using their > own private drm_modeset_locks. > > Aside: There's a few atomic drivers (nv50, vc4, soon vmwgfx) which > don't

[Intel-gfx] [PATCH v4] drm/i915: Advance ring->head fully when idle

When we retire the last request on the ring, before we ever access that ring again we know it will be completely idle and so we can advance the ring->head fully to the end (i.e. ring->tail) and not just to the start of the breadcrumb. This allows us to skip re-emitting the breadcrumb after

Re: [Intel-gfx] [PATCH 12/15] drm: Add acquire ctx to ->gamma_set hook

On Thu, Apr 6, 2017 at 6:51 PM, Eric Anholt wrote: > Daniel Vetter writes: >> Atomic helpers really want this instead of the hacked-up legacy >> backoff trick, which unfortunately prevents drivers from using their >> own private drm_modeset_locks. >> >>

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Generate the engine name based on the instance number

On 05/04/2017 10:30, Oscar Mateo wrote: Not really needed, but makes the next change a little bit more compact. Cc: Tvrtko Ursulin Cc: Paulo Zanoni Cc: Rodrigo Vivi Cc: Chris Wilson Cc:

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Split the engine info table in two levels, using class + instance

On 05/04/2017 10:30, Oscar Mateo wrote: Commit message missing. Cc: Tvrtko Ursulin Cc: Paulo Zanoni Cc: Rodrigo Vivi Cc: Chris Wilson Cc: Daniele Ceraolo Spurio

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Use the same vfunc for BSD2 ring init

On 04/06/2017 10:48 AM, Tvrtko Ursulin wrote: On 05/04/2017 10:30, Oscar Mateo wrote: If we needed to do something different for the init functions, we could always look at the instance number to make the distinction.But, in any case, the two functions are virtually identical already (please

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Generate the engine name based on the instance number

On 06/04/2017 12:22, Oscar Mateo wrote: On 04/06/2017 11:02 AM, Tvrtko Ursulin wrote: On 05/04/2017 10:30, Oscar Mateo wrote: Not really needed, but makes the next change a little bit more compact. Cc: Tvrtko Ursulin Cc: Paulo Zanoni Cc:

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Use the same vfunc for BSD2 ring init

On 05/04/2017 10:30, Oscar Mateo wrote: If we needed to do something different for the init functions, we could always look at the instance number to make the distinction.But, in any case, the two functions are virtually identical already (please notice that BSD2_RING is only used from gen8

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Generate the engine name based on the instance number

On Thu, Apr 06, 2017 at 07:02:10PM +0100, Tvrtko Ursulin wrote: > > On 05/04/2017 10:30, Oscar Mateo wrote: > >@@ -100,6 +100,7 @@ > > { > > const struct engine_info *info = _engines[id]; > > struct intel_engine_cs *engine; > >+char instance[3] = ""; > > > >

Re: [Intel-gfx] [PATCH v4 10/11] drm/i915/dp: Validate cached link rate and lane count before retraining

On Thu, Apr 06, 2017 at 05:31:07PM +0300, Ville Syrjälä wrote: > On Thu, Apr 06, 2017 at 04:44:18PM +0300, Jani Nikula wrote: > > From: Manasi Navare > > > > Currently intel_dp_check_link_status() tries to retrain the link if > > Clock recovery or Channel EQ for any of

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Generate the engine name based on the instance number

On Thu, Apr 06, 2017 at 07:37:20PM +0100, Tvrtko Ursulin wrote: > > On 06/04/2017 12:22, Oscar Mateo wrote: > >On 04/06/2017 11:02 AM, Tvrtko Ursulin wrote: > >>On 05/04/2017 10:30, Oscar Mateo wrote: > >>>Not really needed, but makes the next change a little bit more compact. > >>> > >>>Cc:

Re: [Intel-gfx] [PATCH v3] drm/i915: Only report a wakeup if the waiter was truly asleep

On 06/04/2017 10:30, Chris Wilson wrote: If we attempt to wake up a waiter, who is currently checking the seqno it will be in the TASK_INTERRUPTIBLE state and ttwu will report success. However, it is actually awake and functioning -- so delay reporting the actual wake up until it sleeps. v2:

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Classify the engines in class + instance

On 05/04/2017 10:30, Oscar Mateo wrote: From: Daniele Ceraolo Spurio In such a way that vcs and vcs2 are just two different instances (0 and 1) of the same engine class (VIDEO_DECODE_CLASS). Cc: Tvrtko Ursulin Cc: Paulo Zanoni

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Use the engine class to get the context size

On 05/04/2017 10:30, Oscar Mateo wrote: From: Daniele Ceraolo Spurio Technically speaking, the context size is per engine class, not per instance. It is very nice to have the code match the documentation! Cc: Tvrtko Ursulin Cc:

[Intel-gfx] [PATCH 67/67] drm/i915/cnl: Adjust min pixel rate.

Cannonlake also needs to adjust the minimal pixel rate as gen9 platforms. Specially for the Azalia audio case. Cc: Dhinakaran Pandiyan Cc: Sanyog Kale Signed-off-by: Rodrigo Vivi ---

[Intel-gfx] [PATCH 33/67] drm/i915: Configure DPLL's for Cannonlake

From: "Kahola, Mika" DPLL's are defined in DPCLKA_CFGCR0 register (0x6C200). Let's use these definitions when computing dpll's for ddi ports. v2: (Rodrigo) Remove register that was defined in another patch with fixed name and more bits. Signed-off-by: Kahola, Mika

[Intel-gfx] [PATCH 37/67] drm/i915/cnl: Add registers related to voltage swing sequences.

This are the registers and bits needed for the voltage swing sequence on Cannonlake. v2: Remove CL_DW5 that was wrongly defined. v3: Use (1 << 1) instead of (1<<1) as Paulo suggested Change DW2 swing sel upper and lower macros to do the bit selection instead of definint a table that

[Intel-gfx] [PATCH 22/67] drm/i915/cnl: Add RT cache flush pipe control w/a

From: Ben Widawsky Signed-off-by: Ben Widawsky Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_lrc.c | 19 +++ 1 file changed, 15 insertions(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH 62/67] drm/i915/cnl: Add support slice/subslice/eu configs

From: Ben Widawsky Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_drv.h | 5 +++- drivers/gpu/drm/i915/i915_reg.h | 21 +++ drivers/gpu/drm/i915/intel_device_info.c | 45 +++- 3 files

[Intel-gfx] [PATCH 21/67] drm/i915/cnl: Update the context size

From: Ben Widawsky The docs are not yet correct, so I cannot provide a reference to it. In the current docs, the size is actually smaller than SKL. This seems unlikely given that in another part of the docs there are clearly more engines stored within the context

[Intel-gfx] [PATCH 15/67] drm/i915/cnl: Apply large line width optimization

From: Ben Widawsky This bit enables hardware that will change the approximation used for distances calculations for AA wide lines so that they are rendered more accurately. The default value for this bit leaves the legacy behavior. There is no good reason to not enable the

[Intel-gfx] [PATCH 02/67] drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH

From: Dhinakaran Pandiyan The first two bytes of PCI ID for CNP_LP PCH are the same as that of SPT_LP. We should really be looking at the first 9 bits instead of the first 8 to identify platforms, although this seems to have not caused any problems on earlier

[Intel-gfx] [PATCH 36/67] drm/i915: Add MMIO helper for 6 ports with different offsets.

Also new registers can have different mmio offsets per different lane per port. v2: Use _PICK as PORT3 instead of creating a new macro with if per port. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_reg.h | 4 1 file changed, 4 insertions(+) diff

[Intel-gfx] [PATCH 39/67] drm/i915/cnl: Implement voltage swing sequence.

This is an important part of the DDI initalization as well as for changing the voltage during DisplayPort link training. This new sequence for Cannonlake is more like Broxton style but still with different registers, different table and different steps. v2: Do not write to DW4_GRP to avoid

[Intel-gfx] [PATCH 53/67] drm/i915/cnl: don't apply the GEN9/CNL:A WM WAs to CNL:B+

From: Paulo Zanoni TODO: Right now we only have 2 of the 4 WAs implemented. There's one missing for render decompression and another for transition watermarks. When we upstream this patch, let's check if those missing WAs are also implemented. We may also consider not

[Intel-gfx] [PATCH 52/67] drm/i915/gen10: fix the gen 10 SAGV block time

From: Paulo Zanoni A previous commit added CNL to intel_has_sagv(), but forgot to adjust the SAGV block time to gen 10 platforms. Signed-off-by: Paulo Zanoni Signed-off-by: Rodrigo Vivi ---

[Intel-gfx] [PATCH 50/67] drm/i915/gen10+: use the SKL code for reading WM latencies

From: Paulo Zanoni Gen 10 should use the exact same code as Gen 9, so change the check to take this into consideration, and also assume that future platforms will run this code. Also add a MISSING_CASE(), just in case we do something wrong, instead of silently failing.

[Intel-gfx] [PATCH 47/67] drm/i915/cnl: Dump the right pll registers when dumping pipe config.

Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_dpll_mgr.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c b/drivers/gpu/drm/i915/intel_dpll_mgr.c index 8e669b6..7a2f1be 100644 ---

[Intel-gfx] [PATCH 56/67] drm/i915/cnl: Reuse skl_wm_get_hw_state on Cannonlake.

Otherwise it reuses the ilk that has a completely different wm. Cc: Paulo Zanoni Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH 45/67] drm/i915/cnl: Add max allowed Cannonlake DC.

This is a follow-up after enabling DC states with commit: "drm/i915/DMC/CNL: Load DMC on CNL". Cc: Anusha Srivatsa Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[Intel-gfx] [PATCH 48/67] drm/i915/cnl: Get DDI clock based on PLLs.

PLLs are the source clocks for the DDIs so in order to determine the ddi clock we need to check the PLL configuration. v2: Mika pointed out that 24 was hardcoded while it should consider ref clock that can be either 24KHz or 19.2KHz on CNL. Reviewed-by: Mika Kahola

[Intel-gfx] [PATCH 59/67] drm/i915/cnl: Fix Cannonlake scaler mode programing.

As Geminilake scalers Cannonlake also don't need and don't have the "high quality" mode programming. Cc: Ander Conselvan de Oliveira Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_atomic.c | 2 +- 1 file changed, 1

[Intel-gfx] [PATCH 64/67] drm/i915/cnl: WaThrottleEUPerfToAvoidTDBackPressure:cnl(pre-prod)

Wa for B-stepping only. A for a hang issue that requires throttling EU performace to 12.5% to avoid back pressure to thread dispatch Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_reg.h| 1 + drivers/gpu/drm/i915/intel_engine_cs.c | 4 2 files

[Intel-gfx] [PATCH 41/67] drm/i915/cnl: Add slice and subslice information to debugfs.

A missing part that maybe it is better to squash to commit "drm/i915/cnl: Configure EU slice power gating." later but before upstreaming it. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[Intel-gfx] [PATCH v5] drm/i915/dp: Validate cached link rate and lane count before retraining

Currently intel_dp_check_link_status() tries to retrain the link if Clock recovery or Channel EQ for any of the lanes indicated by intel_dp->lane_count is not set. However these values cached in intel_dp structure can be stale if link training has failed for these values during previous modeset.

Re: [Intel-gfx] [PATCH] drm: Take mode_config.mutex in setcrtc ioctl

On Thu, Apr 6, 2017 at 2:55 PM, Daniel Vetter wrote: > Legacy drivers insist that we really take all the locks in this path, > and the harm in doing so is minimal. > > Fixes: 2ceb585a956c ("drm: Add explicit acquire ctx handling around > ->set_config") > Cc: Harry

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes, v4.

== Series Details == Series: drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes, v4. URL : https://patchwork.freedesktop.org/series/22602/ State : success == Summary == Series 22602v1 drm/atomic: Acquire connection_mutex lock in

[Intel-gfx] [PATCH i-g-t v1] igt_kms: Allow pipes with no cursor plane

A cursor plane may not always be available. Since there already exist variables that signal the existance or non-existance of cursor planes like pipe->plane_cursor and display->has_cursor_plane, allow the pipes that have no cursor plane. Signed-off-by: Robert Foss ---

[Intel-gfx] [PATCH 63/67] drm/i915/cnl: Avoid ioremap_wc on Cannonlake as well.

WC is apparently not an option for CNL+ on GTT here. Trying to use it we get hard hangs. Credits-to: Ben Widawsky Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[Intel-gfx] [PATCH 54/67] drm/i915/gen10: fix WM latency printing

From: Paulo Zanoni Gen 10 is just like Gen 9, so let's consider that all the future platforms are going to be like gen 9 instead of being like gen8-. Signed-off-by: Paulo Zanoni Signed-off-by: Rodrigo Vivi ---

Re: [Intel-gfx] [PATCH 21/67] drm/i915/cnl: Update the context size

On Thu, Apr 06, 2017 at 12:15:17PM -0700, Rodrigo Vivi wrote: > From: Ben Widawsky > > The docs are not yet correct, so I cannot provide a reference to it. In the > current docs, the size is actually smaller than SKL. This seems unlikely given > that in another part

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Split the engine info table in two levels, using class + instance

On 04/06/2017 01:12 PM, Chris Wilson wrote: On Thu, Apr 06, 2017 at 05:55:43AM -0700, Oscar Mateo wrote: There are some properties that logically belong to the engine class, and some that belong to the engine instance. Make it explicit. v2: Commit message (Tvrtko) Cc: Tvrtko Ursulin

[Intel-gfx] ✗ Fi.CI.BAT: failure for Classify the engines in class + instance (rev3)

== Series Details == Series: Classify the engines in class + instance (rev3) URL : https://patchwork.freedesktop.org/series/22535/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/intel_lpe_audio.o LD drivers/usb/storage/usb-storage.o LD

Re: [Intel-gfx] [PATCH] drm: Take mode_config.mutex in setcrtc ioctl

On Thu, Apr 6, 2017 at 3:06 PM, Daniel Vetter wrote: > Legacy drivers insist that we really take all the locks in this path, > and the harm in doing so is minimal. > > v2: Like git add, it exists :( > > Fixes: 2ceb585a956c ("drm: Add explicit acquire ctx handling around >

[Intel-gfx] [PATCH 65/67] drm/i915/cnl: Enable Audio Pin Buffer.

Starting on CNL, we need to enable Audio Pin Buffer. By the spec it seems that this is part of audio programming, so let's give them the hability to set/unset this as needed. v2: With a hook so audio driver can control it. v3: Put back reg definition lost on v2. Cc: Jani Nikula

[Intel-gfx] [PATCH 34/67] drm/i915/cnl: Initialize PLLs

Although CNL follows PLL initialization more like Skylake than Broxton we have a completely different initialization sequence and registers used. One big difference from SKL is that CDCLK PLL is now exclusive (ADPLL) and for DDIs and MIPI we need to use DFGPLLs 0, 1 or 2. v2: Accept all Ander's

[Intel-gfx] [PATCH 58/67] drm/i915/cnl: Cannonlake color init.

Cannonlake has same color setup as Geminilake. Legacy color load luts doesn't work anymore on Cannonlake+. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_pci.c | 1 + drivers/gpu/drm/i915/intel_color.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 4

[Intel-gfx] [PATCH 25/67] drm/i915/cnl: Inherit RPS stuff from previous platforms.

Apparently no change on RPS stuff from previous platforms. v2: Merging to rps related patches in one and also adding missed cases. Cc: David Weinehall Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_debugfs.c | 20

[Intel-gfx] [PATCH 12/67] drm/i915/cnl: Introduce initial Cannonlake Workarounds.

Let's inherit workarounds from previous platforms that according to wa_database and BSpec are still valid for Cannonlake. v2: Add missed workarounds. v3: Rebase Cc: Mika Kuoppala Signed-off-by: Rodrigo Vivi ---

[Intel-gfx] [PATCH 29/67] drm/i915/cnl: Implement .set_cdclk() for CNL

From: Ville Syrjälä Add support for changing the cdclk frequency on CNL. Again, quite similar to BXT, but there are some annoying differences which means trying to share more code might not be feasible: * PLL ratio now lives in the PLL enable register * pcode came

[Intel-gfx] [PATCH 26/67] drm/i915/cnl: Add power wells for CNL

From: Ville Syrjälä CNL power wells are very similar to SKL, with the exception that the misc IO well has been split into separate AUX IO wells. Not sure if DMC is supposed to manage the AUX wells for us or not. Let's assume so for now. v2: DDI A power well wants

[Intel-gfx] [PATCH 46/67] drm/i915/cnl: Add allowed DP rates for Cannonlake.

One warning is that in order to get DPLL Link rates 3240 and 4050 that allows 648000 and 81 is that: "Some SKUs may require elevated I/O voltage to support this." v2: Rebase on top of source_rates changes. Signed-off-by: Rodrigo Vivi ---

[Intel-gfx] [PATCH 38/67] drm/i915/cnl: Add DDI Buffer translation tables for Cannonlake.

These tables are used on voltage wswing sequence initialization on Cannonlake. It is a complete new format now in use by the voltage swing team, not following any other standard in use by any other platform. Also the registers are different as well. So let's redefine the translation table for

[Intel-gfx] [PATCH 66/67] drm/i915/cnl: LSPCON support is gen9+

There is no platform specific change needed for LSPCON support on Cannonlake. So let's make it gen9+. Cc: Shashank Sharma Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_drv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[Intel-gfx] [PATCH 49/67] drm/i915/cnl: Avoid old DDI translation functions on Cannonlake.

Cannonlake uses a different swing voltage initalization sequence scheme that doesn't require these old functions. All other DDI, voltage swing and PLLs initialialization and configuration are already in place for Cannonlake. This patch only removes unecessary steps probably saving us from some

[Intel-gfx] [PATCH 31/67] drm/i915/cnl: Allow dynamic cdclk changes on CNL

All the low level cdclk bits are present, so let's add the required hooks to reconfigure cdclk on the fly. v2: Rebase due to cnl_sanitize_cdclk() v3: Rebased by Rodrigo on top of Ville's cdclk rework. v4: Rebase moving cnl_calc_cdclk up to follow same order as previous platforms.

[Intel-gfx] [PATCH 42/67] drm/i915/DMC/CNL: Load DMC on CNL

From: Anusha Srivatsa This patch loads the DMC on CNL.The firmware version is 1.04. v2: (Rodrigo) Remove MODULE_FIRMWARE. Cc: Rodrigo Vivi Signed-off-by: Anusha Srivatsa Signed-off-by: Rodrigo Vivi

[Intel-gfx] [PATCH 40/67] drm/i915/cnl: Enable loadgen_select bit for vswing sequence

From: Clint Taylor vswing programming sequence step 2 requires the Loadgen_select bit to be set in PORT_TX_DW4 lane reigsters per table defined by Bit rate and lane width. Implemented the change that was marked as FIXME in the driver. v2: (Rodrigo) checkpatch fixes.

[Intel-gfx] [PATCH 16/67] drm/i915/cnl: Cannonlake has 4 planes (3 sprites) per pipe

From: James Irwin Issue: VIZ-4525 Reviewed-by: Damien Lespiau Signed-off-by: James Irwin Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/intel_device_info.c | 2 +- 1 file changed, 1

[Intel-gfx] [PATCH 06/67] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

As for BXT, PP_DIVISOR was removed from CNP PCH and power cycle delay has been moved to PP_CONTROL. Cc: Jani Nikula Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_dp.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-)

[Intel-gfx] [PATCH 35/67] drm/i915/cnl: Enable wrpll computation for CNL

From: "Kahola, Mika" Enable wrpll computation for Cannonlake platform to support pll's required for HDMI output. The patch contains the following features - compute Cannonlake port clock programming dividers P, Q, and K. - compute PLL parameters for Cannonlake. These

[Intel-gfx] [PATCH 51/67] drm/i915/cnl: Enable SAGV for Cannonlake.

For now inherit from previous platforms. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index a2b2509..20a0701 100644

[Intel-gfx] [PATCH 09/67] drm/i915/cnl: Add Cannonlake PCI IDs for U-skus.

Platform enabling and its power-on are organized in different skus (U x Y x S x H, etc). So instead of organizing it in GT1 x GT2 x GT3 let's also use the platform sku. This is also the new Spec style what makes the review much more easy and straightforward. v2: Really include the PCI IDs to the

[Intel-gfx] [PATCH 57/67] x86/gpu: CNL uses the same GMS values as SKL

From: Paulo Zanoni So don't forget to reserve its stolen memory bits. TODO: Cc the appropriate maintainers outside Intel before submitting the patch to the public mailing lists. Acked-by: Rodrigo Vivi Signed-off-by: Paulo Zanoni

[Intel-gfx] [PATCH 55/67] drm/i915/gen10: implement gen 10 watermarks calculations

From: Paulo Zanoni They're slightly different than the gen 9 calculations. TODO: before upstraming this, check if the spec is still the same. Signed-off-by: Paulo Zanoni Signed-off-by: Rodrigo Vivi ---

[Intel-gfx] [PATCH 60/67] drm/i915/cnl: Enable fifo underrun for Cannonlake.

Also in a way that reuse bdw+ for all next platforms. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_fifo_underrun.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c

  1   2   3   >