[Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [1/3] drm/i915: rename macro parameter(ring) to (engine)

== Series Details == Series: series starting with [1/3] drm/i915: rename macro parameter(ring) to (engine) URL : https://patchwork.freedesktop.org/series/10101/ State : success == Summary == Series 10101v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/vgem: Allow root to inject hanging fences onto dmabufs

On Wed, Jul 20, 2016 at 04:28:40PM -0700, Kristian Høgsberg wrote: > Why is this useful if only root can use it? > > When performing driver testing, one factor we want to test is how we > > handle a foreign fence that is never signaled. We can wait on that fence > > indefinitely, in which case

Re: [Intel-gfx] [PATCH 17/17] drm/i915: Use rt priority kthread to do GuC log buffer sampling

On Thu, Jul 21, 2016 at 09:11:42AM +0530, Goel, Akash wrote: > > > On 7/21/2016 1:04 AM, Chris Wilson wrote: > >In the end, just the silly locking and placement of complete_all() is > >dangerous. reinit_completion() lacks the barrier to be used like this > >really, at any rate, racy with the irq

Re: [Intel-gfx] [PATCH v3 0/4] Enable lspcon support for GEN9 devices

> Oh. Do we have some idea of the power cost? > Curiously when I tried to measure the idle power consumption on my BSW, DP > seemed to be a bit less hungry than HDMI. But I guess the PCON stuff itself > will use some amount of power which might offset any benefit from using DP on > the SoC

Re: [Intel-gfx] [PATCH 17/17] drm/i915: Use rt priority kthread to do GuC log buffer sampling

On 7/21/2016 1:04 AM, Chris Wilson wrote: On Sun, Jul 10, 2016 at 07:11:24PM +0530, akash.g...@intel.com wrote: @@ -1707,8 +1692,8 @@ static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32 gt_iir) I915_READ(SOFT_SCRATCH(15)) & ~msg);

Re: [Intel-gfx] [PATCH v2] drm/i915:gen9: restrict WaC6DisallowByGfxPause

Reviewed-by: Sagar Arun Kamble On 7/20/2016 3:30 PM, tim.g...@intel.com wrote: From: Tim Gore WaC6DisallowByGfxPause is currently applied unconditionally but is not required in all revisions. v2: extend application of workaround to agree with

Re: [Intel-gfx] [PATCH 4/6] drm/i915/skl: Always wait for pipes to update after a flush

On Wed, Jul 20, 2016 at 05:00:00PM -0400, Lyude wrote: > As we've learned, all watermark updates on Skylake have to be strictly > atomic or things fail. While the bspec doesn't mandate that we need to > wait for pipes to finish after the third iteration of flushes, not doing > so gives us the

Re: [Intel-gfx] [PATCH] drm/vgem: Allow root to inject hanging fences onto dmabufs

Why is this useful if only root can use it? Kristian On Wed, Jul 20, 2016 at 12:39 PM, Chris Wilson wrote: > When performing driver testing, one factor we want to test is how we > handle a foreign fence that is never signaled. We can wait on that fence > indefinitely,

Re: [Intel-gfx] [PATCH 3/6] drm/i915/skl: Actually reuse wm values when pipes don't change

On Wed, Jul 20, 2016 at 04:59:59PM -0400, Lyude wrote: > Up until now we've actually been making the mistake of leaving the > watermark results for each pipe completely blank in skl_compute_wm() > when they haven't changed, fix this. Should this be moved before patch #1? With the existing code

Re: [Intel-gfx] [PATCH 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

On Wed, Jul 20, 2016 at 04:59:58PM -0400, Lyude wrote: > From: Matt Roper > > When we write watermark values to the hardware, those values are stored > in dev_priv->wm.skl_hw. However with recent watermark changes, the > results structure we're copying from only

Re: [Intel-gfx] [PATCH 1/6] drm/i915/skl: Update plane watermarks atomically during plane updates

On Wed, Jul 20, 2016 at 04:59:57PM -0400, Lyude wrote: > Thanks to Ville for suggesting this as a potential solution to pipe > underruns on Skylake. > > On Skylake all of the registers for configuring planes, including the > registers for configuring their watermarks, are double buffered. New >

Re: [Intel-gfx] [PATCH 23/23] drm/i915: Move HAS_GMCH_DISPLAY definition to platform

well... this is where one inheriting and extending the previous make it a bit ugly... you would need to set it to 0 at GEN5_FEATURES. maybe with a comment /* support discontinued */ On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Moving all GPU features to the

Re: [Intel-gfx] [PATCH 22/23] drm/i915: Move HAS_L3_DPF definition to platform definition

This patch is adding support to l3_dpf to bdw, skl and kbl... On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Moving all GPU features to the platform definition allows for > - standard place when adding new features from new platforms > - possible

Re: [Intel-gfx] [PATCH 21/23] drm/i915: Move HAS_LOGICAL_RING_CONTEXTS definition to platform definition

Reviewed-by: Rodrigo Vivi On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Moving all GPU features to the platform definition allows for > - standard place when adding new features from new platforms > - possible to see

Re: [Intel-gfx] [PATCH 20/23] drm/i915: Move HAS_HW_CONTEXTS definition to platform

this patch could be cleaner if on gen inherit and extend the previous. On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Moving all GPU features to the platform definition allows for > - standard place when adding new features from new platforms > -

Re: [Intel-gfx] [PATCH 19/23] drm/915: Move HAS_FW_BLC definition to platform

this patch could be cleaner if on gen inherit and extend the previous. On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Moving all GPU features to the platform definition allows for > - standard placae when adding new features from new platforms > -

Re: [Intel-gfx] [PATCH 18/23] drm/i915: Introduce GEN2 FEATURES for device info

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Based on the GEN7_FEATURES changes from Ben W. > > Use it for 830, 845g, i85x, i865g. > > Signed-off-by: Carlos Santa > --- > drivers/gpu/drm/i915/i915_pci.c | 33

Re: [Intel-gfx] [PATCH 17/23] drm/i915: Introduce GEN3_FEATURES for device info

same as previous patch On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Based on the GEN7_FEATURES changes from Ben W. > > Use it for i915g, i915gm, i945g, i945gm, g33 and pineview. > > Signed-off-by: Carlos Santa > --- >

Re: [Intel-gfx] [PATCH 16/23] drm/i915: Introduce GEN4_FEATURES for device info

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Based on the GEN7_FEATURES changes from Ben W. > > Use it for i965g, i965gm, g45,and gm45. > > Signed-off-by: Carlos Santa > --- > drivers/gpu/drm/i915/i915_pci.c | 51 >

Re: [Intel-gfx] [PATCH 15/23] drm/i915: Move HAS_GMBUS_IRQ definition to platform definition

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct >

Re: [Intel-gfx] [PATCH 14/23] drm/i915: Move HAS_AUX_IRQ definition to platform definition

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct >

Re: [Intel-gfx] [PATCH 13/23] drm/i915: Introduce GEN5_FEATURES for device info

ops, actually on this one you could do GEN6_FEATURE inherit and extend this. On Wed, Jul 20, 2016 at 2:22 PM, Rodrigo Vivi wrote: > Reviewed-by: Rodrigo Vivi > > On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: >>

Re: [Intel-gfx] [PATCH 13/23] drm/i915: Introduce GEN5_FEATURES for device info

Reviewed-by: Rodrigo Vivi On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Based on the GEN7_FEATURES changes from Ben W. > > Use it for ilk. > > Signed-off-by: Carlos Santa > --- > drivers/gpu/drm/i915/i915_pci.c

Re: [Intel-gfx] [PATCH 12/23] drm/i915: Move HAS_DP_MST definition to platform definition

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct >

Re: [Intel-gfx] [PATCH 11/23] drm/i915: Move HAS_RC6p definition to platform definition

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct >

Re: [Intel-gfx] [PATCH 10/23] drm/i915: Move HAS_RC6 definition to platform definition

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct >

Re: [Intel-gfx] [PATCH 09/23] drm/i915: Move HAS_RESOURCE_STREAMER definition to platform definition

Reviewed-by: Rodrigo Vivi On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to

Re: [Intel-gfx] [PATCH 08/23] drm/i915: Move HAS_GUC_SCHED definition to platform definition

please kill this _sched variation that is just a alias to guc instead On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Moving all GPU features to the platform definition allows for > - standard place when adding new features from new platforms >

Re: [Intel-gfx] [PATCH 07/23] drm/i915: Move HAS_GUC_UCODE definition to platform definition

please kill this _ucode variation that is just a alias to guc instead On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Moving all GPU features to the platform definition allows for > - standard place when adding new features from new platforms >

Re: [Intel-gfx] [PATCH 05/23] drm/i915: Move HAS_CSR definition to platform definition

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct >

[Intel-gfx] [PATCH 3/6] drm/i915/skl: Actually reuse wm values when pipes don't change

Up until now we've actually been making the mistake of leaving the watermark results for each pipe completely blank in skl_compute_wm() when they haven't changed, fix this. Fixes: 734fa01f3a17 ("drm/i915/gen9: Calculate watermarks during atomic 'check' (v2)") Cc: sta...@vger.kernel.org Cc: Ville

[Intel-gfx] [PATCH 5/6] drm/i915/skl: Only flush pipes when we change the ddb allocation

Manual pipe flushes are only necessary in order to make sure that we prevent pipes with changed ddb allocations from overlapping from one another at any point in time. Additionally, forcing us to wait for the next vblank every time we have to update the watermark values because the cursor was

[Intel-gfx] [PATCH 6/6] drm/i915/skl: Fix extra whitespace in skl_flush_wm_values()

Similar to how a vehicle will travel faster if you paint flames on it, cleaning up this extra whitespace is guaranteed to provide additional stability while updating watermark values. Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_pm.c | 1 - 1 file changed, 1 deletion(-)

[Intel-gfx] [PATCH 4/6] drm/i915/skl: Always wait for pipes to update after a flush

As we've learned, all watermark updates on Skylake have to be strictly atomic or things fail. While the bspec doesn't mandate that we need to wait for pipes to finish after the third iteration of flushes, not doing so gives us the opportunity to break this atomicity later. This example assumes

[Intel-gfx] [PATCH 1/6] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

[Intel-gfx] [PATCH 0/6] drm/i915/skl: Finally fix watermarks

To Sebastian Reichel: If this e-mail has the bizarre email address formatting issue you noticed in the last patch series I sent please let me know. I haven't gotten a chance to properly look at the e-mail you forwarded to me to see what's causing the problem, but I

[Intel-gfx] [PATCH 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

From: Matt Roper When we write watermark values to the hardware, those values are stored in dev_priv->wm.skl_hw. However with recent watermark changes, the results structure we're copying from only contains valid watermark and DDB values for the pipes that are

Re: [Intel-gfx] [PATCH 04/23] drm/i915: Move HAS_CORE_RING_FREQ definition to platform definition

another reason to have GEN7_FEATURES based on GEN6_FEATURES. Please add that before patches like this so we avoid duplication since the beginning. And do that has_runtime_pm=0 and put a comment or a FIXME there... Thanks, Rodrigo. On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa

Re: [Intel-gfx] [PATCH 03/23] drm/i915: Move HAS_RUNTIME_PM definition to platform

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct >

Re: [Intel-gfx] [PATCH 02/23] drm/i915: Introduce GEN6_FEATURES for device info

Reviewed-by: Rodrigo Vivi On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > Based on the GEN7_FEATURES changes from Ben W. > > Use it for snb. > > Signed-off-by: Carlos Santa > --- > drivers/gpu/drm/i915/i915_pci.c

Re: [Intel-gfx] [PATCH 01/23] drm/i915: Move HAS_PSR definition to platform struct definition

Reviewed-by: Rodrigo Vivi On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > [patch series] Moving all GPU features to the platform struct definition > allows for > - standard place when adding new features from new platforms >

[Intel-gfx] [PATCH] drm/vgem: Allow root to inject hanging fences onto dmabufs

When performing driver testing, one factor we want to test is how we handle a foreign fence that is never signaled. We can wait on that fence indefinitely, in which case the driver appears hung, or we can take some remedial action (with risks regarding the state of any shared content). Whatever

Re: [Intel-gfx] [PATCH 17/17] drm/i915: Use rt priority kthread to do GuC log buffer sampling

On Sun, Jul 10, 2016 at 07:11:24PM +0530, akash.g...@intel.com wrote: > @@ -1707,8 +1692,8 @@ static void gen9_guc_irq_handler(struct > drm_i915_private *dev_priv, u32 gt_iir) > I915_READ(SOFT_SCRATCH(15)) & ~msg); > > /*

[Intel-gfx] [PATCH 1/2] drm/i915: Drop racy markup of missed-irqs from idle-worker

During the idle-worker we disable the hangcheck and so kick any waiters that should have been completed (since the GPU is now idle). Unlike the hangcheck, we do not take any care to avoid the race between the irq handler and ourselves, and so it is possible for us to declare a missed interrupt

[Intel-gfx] [PATCH 2/2] drm/i915: Update the breadcrumb interrupt counter before enabling

In order to close a race with a long running hangcheck comparing a stale interrupt counter with a just started waiter, we need to first bump the counter as we start the fresh wait. References: https://bugs.freedesktop.org/show_bug.cgi?id=96974 Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 1/2] meh

On Wed, Jul 20, 2016 at 07:57:08PM +0100, Chris Wilson wrote: Bleh, send-email from wrong branch. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH 2/2] drm/vgem: Allow root to inject hanging fences onto dmabufs

When performing driver testing, one factor we want to test is how we handle a foreign fence that is never signaled. We can wait on that fence indefinitely, in which case the driver appears hung, or we can take some remedial action (with risks regarding the state of any shared content). Whatever

[Intel-gfx] [PATCH 1/2] meh

--- drivers/gpu/drm/i915/i915_debugfs.c| 162 +--- drivers/gpu/drm/i915/i915_drv.h| 84 ++--- drivers/gpu/drm/i915/i915_gem.c| 150 --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +- drivers/gpu/drm/i915/i915_gem_request.c|

[Intel-gfx] [PATCH 06/23] drm/i915: Move HAS_GUC definition to platform definition

Moving all GPU features to the platform definition allows for - standard place when adding new features from new platform - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 09/23] drm/i915: Move HAS_RESOURCE_STREAMER definition to platform definition

Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 10/23] drm/i915: Move HAS_RC6 definition to platform definition

Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 15/23] drm/i915: Move HAS_GMBUS_IRQ definition to platform definition

Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 19/23] drm/915: Move HAS_FW_BLC definition to platform

Moving all GPU features to the platform definition allows for - standard placae when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 02/23] drm/i915: Introduce GEN6_FEATURES for device info

Based on the GEN7_FEATURES changes from Ben W. Use it for snb. Signed-off-by: Carlos Santa --- drivers/gpu/drm/i915/i915_pci.c | 26 -- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_pci.c

[Intel-gfx] [PATCH 07/23] drm/i915: Move HAS_GUC_UCODE definition to platform definition

Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported featurs when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 21/23] drm/i915: Move HAS_LOGICAL_RING_CONTEXTS definition to platform definition

Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 00/23] drm/i915: Organize most GPU features by platform

This patchset includes the following changes: - organize most GPU features so that they are easy to group by platforms. It seems some of the ground work was already done for Gen7 features. Reuse some of that work for the rest of the Gen platforms (GEN6, GEN5, GEN4, GEN3 and GEN2). -

[Intel-gfx] [PATCH 18/23] drm/i915: Introduce GEN2 FEATURES for device info

Based on the GEN7_FEATURES changes from Ben W. Use it for 830, 845g, i85x, i865g. Signed-off-by: Carlos Santa --- drivers/gpu/drm/i915/i915_pci.c | 33 + 1 file changed, 13 insertions(+), 20 deletions(-) diff --git

[Intel-gfx] [PATCH 04/23] drm/i915: Move HAS_CORE_RING_FREQ definition to platform definition

Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 01/23] drm/i915: Move HAS_PSR definition to platform struct definition

[patch series] Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definition Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 14/23] drm/i915: Move HAS_AUX_IRQ definition to platform definition

Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 12/23] drm/i915: Move HAS_DP_MST definition to platform definition

Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 05/23] drm/i915: Move HAS_CSR definition to platform definition

Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 23/23] drm/i915: Move HAS_GMCH_DISPLAY definition to platform

Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 03/23] drm/i915: Move HAS_RUNTIME_PM definition to platform

Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 22/23] drm/i915: Move HAS_L3_DPF definition to platform definition

Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 20/23] drm/i915: Move HAS_HW_CONTEXTS definition to platform

Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumpig struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 16/23] drm/i915: Introduce GEN4_FEATURES for device info

Based on the GEN7_FEATURES changes from Ben W. Use it for i965g, i965gm, g45,and gm45. Signed-off-by: Carlos Santa --- drivers/gpu/drm/i915/i915_pci.c | 51 ++--- 1 file changed, 28 insertions(+), 23 deletions(-) diff --git

[Intel-gfx] [PATCH 08/23] drm/i915: Move HAS_GUC_SCHED definition to platform definition

Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 13/23] drm/i915: Introduce GEN5_FEATURES for device info

Based on the GEN7_FEATURES changes from Ben W. Use it for ilk. Signed-off-by: Carlos Santa --- drivers/gpu/drm/i915/i915_pci.c | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_pci.c

[Intel-gfx] [PATCH 11/23] drm/i915: Move HAS_RC6p definition to platform definition

Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH 17/23] drm/i915: Introduce GEN3_FEATURES for device info

Based on the GEN7_FEATURES changes from Ben W. Use it for i915g, i915gm, i945g, i945gm, g33 and pineview. Signed-off-by: Carlos Santa --- drivers/gpu/drm/i915/i915_pci.c | 58 - 1 file changed, 29 insertions(+), 29 deletions(-)

Re: [Intel-gfx] [PATCH 3/3] drm/i915: rename & update eb_select_ring()

On Wed, Jul 20, 2016 at 06:16:07PM +0100, Dave Gordon wrote: > 'ring' is an old deprecated term for a GPU engine, so we're trying to > phase out all such terminology. eb_select_ring() not only has 'ring' > (meaning engine) in its name, but it has an ugly calling convention > whereby it returns an

Re: [Intel-gfx] [PATCH 2/3] drm/i915: rename 'ring' where it refers to an engine or engine_id

On Wed, Jul 20, 2016 at 06:16:06PM +0100, Dave Gordon wrote: > 'ring' is an old deprecated term for a GPU engine. Chris Wilson wants to > use the name for what is currently known as an intel_ringbuffer, but it > will be dreadfully confusing if some rings are ringbuffers but other > rings are still

Re: [Intel-gfx] [PATCH 1/3] drm/i915: rename macro parameter(ring) to (engine)

On Wed, Jul 20, 2016 at 06:16:05PM +0100, Dave Gordon wrote: > 'ring' is an old deprecated term for a GPU engine. Here we make the > terminology more consistent by renaming the 'ring' parameter of lots of > macros that calculate addresses within the MMIO space of an engine. > > Signed-off-by:

Re: [Intel-gfx] Reduce usage of the name 'ring' for engines et al

On Wed, Jul 20, 2016 at 06:16:04PM +0100, Dave Gordon wrote: > Chris Wilson is trying to convert 'ringbuffer' to 'ring', but at present > there's rather too much legacy code using 'ring' for various other things, > usually engines or engine-ids. This patchset converts some of them (but > not as

[Intel-gfx] [PATCH 2/3] drm/i915: rename 'ring' where it refers to an engine or engine_id

'ring' is an old deprecated term for a GPU engine. Chris Wilson wants to use the name for what is currently known as an intel_ringbuffer, but it will be dreadfully confusing if some rings are ringbuffers but other rings are still engines. So this patch changes the names of a bunch of parameters

[Intel-gfx] Reduce usage of the name 'ring' for engines et al

Chris Wilson is trying to convert 'ringbuffer' to 'ring', but at present there's rather too much legacy code using 'ring' for various other things, usually engines or engine-ids. This patchset converts some of them (but not as yet the gpu_error or trace code). Chris: what is your prefered name

[Intel-gfx] [PATCH 1/3] drm/i915: rename macro parameter(ring) to (engine)

'ring' is an old deprecated term for a GPU engine. Here we make the terminology more consistent by renaming the 'ring' parameter of lots of macros that calculate addresses within the MMIO space of an engine. Signed-off-by: Dave Gordon ---

[Intel-gfx] [PATCH 3/3] drm/i915: rename & update eb_select_ring()

'ring' is an old deprecated term for a GPU engine, so we're trying to phase out all such terminology. eb_select_ring() not only has 'ring' (meaning engine) in its name, but it has an ugly calling convention whereby it returns an errno and stores a pointer-to-engine indirectly through an output

Re: [Intel-gfx] [PATCH 12/13] drm/i915: Consolidate legacy semaphore initialization

On 20/07/16 17:07, Tvrtko Ursulin wrote: On 20/07/16 13:50, Dave Gordon wrote: On 20/07/16 10:54, Tvrtko Ursulin wrote: On 19/07/16 19:38, Dave Gordon wrote: On 15/07/16 14:13, Tvrtko Ursulin wrote: On 29/06/16 17:00, Chris Wilson wrote: On Wed, Jun 29, 2016 at 04:41:58PM +0100, Tvrtko

Re: [Intel-gfx] [PATCH v3 0/4] Enable lspcon support for GEN9 devices

On Wed, Jul 20, 2016 at 04:16:30PM +, Sharma, Shashank wrote: > Hi Ville. > > > This thing seems to be missing a lot of stuff: > > - where is the EDID etc. handling? > None required for LSPCON as of now. > The 4k@60 pixel clock support was already added with SKL, so we can see > a HDMI 4k@60

Re: [Intel-gfx] [PATCH v3 0/4] Enable lspcon support for GEN9 devices

Hi Ville. > This thing seems to be missing a lot of stuff: > - where is the EDID etc. handling? None required for LSPCON as of now. The 4k@60 pixel clock support was already added with SKL, so we can see a HDMI 4k@60 output already on PCON mode, when connected to a 4k@60 monitor. I have started

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,1/9] drm/i915: Rename request reference/unreference to get/put

On Wed, Jul 20, 2016 at 05:03:10PM +0100, Tvrtko Ursulin wrote: > > On 20/07/16 16:51, Dave Gordon wrote: > >On 20/07/16 14:02, Patchwork wrote: > >>== Series Details == > >> > >>Series: series starting with [CI,1/9] drm/i915: Rename request > >>reference/unreference to get/put > >>URL :

Re: [Intel-gfx] [PATCH v4 2/5] drm: Add private data field to trace control block

On Jul 20, 2016 4:50 PM, "Dmitry V. Levin" wrote: > > On Mon, Sep 07, 2015 at 08:23:57PM +0200, Patrik Jakobsson wrote: > > On Mon, Sep 7, 2015 at 6:51 PM, Dmitry V. Levin wrote: > > > On Mon, Aug 31, 2015 at 02:37:07PM +0200, Patrik Jakobsson wrote: > > > [...] > > >> Here's

Re: [Intel-gfx] [PATCH 12/13] drm/i915: Consolidate legacy semaphore initialization

On 20/07/16 13:50, Dave Gordon wrote: On 20/07/16 10:54, Tvrtko Ursulin wrote: On 19/07/16 19:38, Dave Gordon wrote: On 15/07/16 14:13, Tvrtko Ursulin wrote: On 29/06/16 17:00, Chris Wilson wrote: On Wed, Jun 29, 2016 at 04:41:58PM +0100, Tvrtko Ursulin wrote: On 29/06/16 16:34, Chris

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,1/9] drm/i915: Rename request reference/unreference to get/put

On 20/07/16 16:51, Dave Gordon wrote: On 20/07/16 14:02, Patchwork wrote: == Series Details == Series: series starting with [CI,1/9] drm/i915: Rename request reference/unreference to get/put URL : https://patchwork.freedesktop.org/series/10089/ State : failure == Summary == Series 10089v1

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,1/9] drm/i915: Rename request reference/unreference to get/put

On 20/07/16 14:02, Patchwork wrote: == Series Details == Series: series starting with [CI,1/9] drm/i915: Rename request reference/unreference to get/put URL : https://patchwork.freedesktop.org/series/10089/ State : failure == Summary == Series 10089v1 Series without cover letter

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [01/18] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit (rev2)

== Series Details == Series: series starting with [01/18] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit (rev2) URL : https://patchwork.freedesktop.org/series/10090/ State : failure == Summary == Applying: drm/i915: Unify intel_logical_ring_emit and intel_ring_emit Applying:

[Intel-gfx] [PATCH] drm/i915: Convert stray struct intel_engine_cs *ring

We still have a few uses of the identifier "ring" used when referring to the struct intel_engine_cs (a remanent from when there was only one dual purpose engine/ringbuffer). Rename all of this to use the familiar engine so that the separation between the hardware engine and the ringbuffer

Re: [Intel-gfx] [PATCH v4 2/5] drm: Add private data field to trace control block

On Mon, Sep 07, 2015 at 08:23:57PM +0200, Patrik Jakobsson wrote: > On Mon, Sep 7, 2015 at 6:51 PM, Dmitry V. Levin wrote: > > On Mon, Aug 31, 2015 at 02:37:07PM +0200, Patrik Jakobsson wrote: > > [...] > >> Here's my take on it (I assume it needs some discussion): > >> > >> int > >>

Re: [Intel-gfx] [PATCH 02/18] drm/i915: Rename request->ringbuf to request->ring

On 20/07/16 15:12, Dave Gordon wrote: On 20/07/16 14:11, Chris Wilson wrote: Now that we have disambuigated ring and engine, we can use the clearer and more consistent name for the intel_ringbuffer pointer in the request. Signed-off-by: Chris Wilson You missed a

Re: [Intel-gfx] [PATCH 03/18] drm/i915: Rename backpointer from intel_ringbuffer to intel_engine_cs

On 20/07/16 14:11, Chris Wilson wrote: Having ringbuf->ring point to an engine is confusing, so rename it once again to ring->engine. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_ringbuffer.c | 12 ++-- 1 file changed, 6 insertions(+), 6

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: Per-plane rotation, fixes, and mirroring for CHV

== Series Details == Series: drm/i915: Per-plane rotation, fixes, and mirroring for CHV URL : https://patchwork.freedesktop.org/series/10093/ State : success == Summary == Series 10093v1 drm/i915: Per-plane rotation, fixes, and mirroring for CHV

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Use the per-plane rotation property

On Wed, Jul 20, 2016 at 04:57:32PM +0300, Joonas Lahtinen wrote: > On ke, 2016-07-20 at 16:18 +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > On certain platforms not all planes support the same set of > > rotations/reflections, so let's

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Use & instead if == to check for rotations

On Wed, Jul 20, 2016 at 05:01:00PM +0300, Joonas Lahtinen wrote: > On ke, 2016-07-20 at 16:18 +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Using == to check for 180 degree rotation only works as long as the > > reflection bits aren't

Re: [Intel-gfx] [PATCH 02/18] drm/i915: Rename request->ringbuf to request->ring

On 20/07/16 14:11, Chris Wilson wrote: Now that we have disambuigated ring and engine, we can use the clearer and more consistent name for the intel_ringbuffer pointer in the request. Signed-off-by: Chris Wilson You missed a few instances of 'ring' meaning engine:

Re: [Intel-gfx] [PATCH 3/7] drm: Add support for optional per-plane rotation property

On ke, 2016-07-20 at 17:08 +0300, Ville Syrjälä wrote: > On Wed, Jul 20, 2016 at 04:51:57PM +0300, Joonas Lahtinen wrote: > > > > On ke, 2016-07-20 at 16:18 +0300, ville.syrj...@linux.intel.com wrote: > > > > > > From: Ville Syrjälä > > > > > > Not all planes on

Re: [Intel-gfx] [PATCH 3/7] drm: Add support for optional per-plane rotation property

On Wed, Jul 20, 2016 at 04:51:57PM +0300, Joonas Lahtinen wrote: > On ke, 2016-07-20 at 16:18 +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Not all planes on the ssytem may support the same rotations/reflections, > > s/ssytem/system/

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup

On ke, 2016-07-20 at 16:18 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Move the plane control register rotation setup away from the > coordinate munging code. This will result in neater looking > code once we add reflection support for

  1   2   3   >