Re: [Intel-gfx] [PATCH] intel: Export pooled EU and min no. of eus in a pool.

Yes, it is libdrm patch. I have merged the beignet patch right now, but still depend on the libdrm patch, I will resend it to libdrm now. Thanks. > -Original Message- > From: Arun Siluvery [mailto:arun.siluv...@linux.intel.com] > Sent: Tuesday, July 5, 2016 18:01 > To: Yang, Rong R

Re: [Intel-gfx] linux-next: build failure after merge of the tip tree (from the drm-intel tree)

On Tue, Jul 05, 2016 at 10:25:12AM +0200, Peter Zijlstra wrote: > On Tue, Jul 05, 2016 at 01:53:03PM +1000, Stephen Rothwell wrote: > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > b/drivers/gpu/drm/i915/i915_gem.c > > index d3502c0603e5..1f91f187b2a8 100644 > > ---

[Intel-gfx] [PATCH] drm/i915: Separate out reset flags from the reset counter

In preparation for introducing a per-engine reset, we can first separate the mixing of the reset state from the global reset counter. The loss of atomicity in updating the reset state poses a small problem for handling the waiters. For requests, this is solved by advancing the seqno so that a

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915/guc: Make the GuC fw loading helper functions general

On 01/07/16 14:15, Peter Antoine wrote: Rename some of the GuC fw loading code to make them more general. We will utilise them for HuC loading as well. s/intel_guc_fw/intel_uc_fw/g s/GUC_FIRMWARE/UC_FIRMWARE/g Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,

Re: [Intel-gfx] [PATCH 3/6] drm/i915/huc: Add HuC fw loading support

On 29/06/16 18:59, Rodrigo Vivi wrote: On Wed, Jun 29, 2016 at 7:31 AM, Dave Gordon wrote: On 29/06/16 00:03, Rodrigo Vivi wrote: I don't believe we need to be that extreme here. Daniel asked a cleaner version, but we don't need to block the huc on a full rework of

Re: [Intel-gfx] linux-firmware-i915 pull request (bxt dmc, kbl dmc)

On Fri, Jul 01, 2016 at 11:20:09PM +, Vivi, Rodrigo wrote: > Hi, > > Please consider pulling i915 updates to linux-firmware.git > > > The following changes since commit > 040c24514b94fcdbd6308d986d1bde59a704a21a: > >   linux-firmware: intel: Update Broxton audio firmware (2016-06-29 >

Re: [Intel-gfx] [PATCH] drm/i915: Convert dev_priv->dev backpointers to dev_priv->drm

On 05/07/16 09:51, Chris Wilson wrote: Since drm_i915_private is now a subclass of drm_device we do not need to chase the drm_i915_private->dev backpointer and can instead simply access drm_i915_private->drm directly. text data bss dec hex filename 10687574565

[Intel-gfx] ✗ Ro.CI.BAT: warning for Enable lspcon support for GEN9 devices (rev3)

== Series Details == Series: Enable lspcon support for GEN9 devices (rev3) URL : https://patchwork.freedesktop.org/series/8024/ State : warning == Summary == Series 8024v3 Enable lspcon support for GEN9 devices http://patchwork.freedesktop.org/api/1.0/series/8024/revisions/3/mbox Test

Re: [Intel-gfx] [PATCH] drm/i915: Always double check for a missed interrupt for new bottom halves

On 05/07/16 12:29, Chris Wilson wrote: After assigning ourselves as the new bottom-half, we must perform a cursory check to prevent a missed interrupt. Either we miss the interrupt whilst programming the hardware, or if there was a previous waiter (for a later seqno) they may be woken instead

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: remove superfluous i915_gem_object_free_mmap_offset call

== Series Details == Series: drm/i915: remove superfluous i915_gem_object_free_mmap_offset call URL : https://patchwork.freedesktop.org/series/9516/ State : failure == Summary == Series 9516v1 drm/i915: remove superfluous i915_gem_object_free_mmap_offset call

Re: [Intel-gfx] [PATCH] drm/i915: Wake up the bottom-half if we steal their interrupt

On Tue, Jul 05, 2016 at 12:45:55PM +0100, Chris Wilson wrote: > Following on from the scenario Tvrtko envision to explain a hard-to-hit > race with multiple first waiters, we could also then race in the > __i915_request_irq_complete() and the bottom-half may miss the vital > irq-seqno barrier and

[Intel-gfx] [PATCH v3 3/4] drm/i915: Parse VBT data for lspcon

Many GEN9 boards come with on-board lspcon cards. Fot these boards, VBT configuration should properly point out if a particular port contains lspcon device, so that driver can initialize it properly. This patch adds a utility function, which checks the VBT flag for lspcon bit, and tells us if a

[Intel-gfx] [PATCH v3 1/4] drm: Helper for lspcon in drm_dp_dual_mode

This patch adds lspcon support in dp_dual_mode helper. lspcon is essentially a dp->hdmi dongle with dual personality. LS mode: It works as a passive dongle, by level shifting DP++ signals to HDMI signals, in LS mode. PCON mode: It works as a protocol converter active dongle in pcon mode, by

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

LSPCON is essentially a dp++->hdmi adapter with dual mode of operation. These modes are: - Level Shifter mode: In LS mode, this device works as a type2 dp->hdmi passive dongle, which steps up DP++ output to appropriate HDMI 1.4 signal. This mode doesn't do any conversion at the protocol level. -

[Intel-gfx] [PATCH v3 2/4] drm/i915: Add lspcon support for I915 driver

This patch adds a new file, to accommodate lspcon support for I915 driver. These functions probe, detect, initialize and configure an on-board lspcon device during the driver init time. Also, this patch adds a small structure for lspcon device, which will provide the runtime status of the device.

[Intel-gfx] [PATCH v3 4/4] drm/i915: Enable lspcon initialization

This patch adds initialization code for lspcon. What we are doing here is: - Check if lspcon is configured in VBT for this port - If lspcon is configured, initialize it and configure it as DP port. V2: Addressed Ville's review comments: - Not adding AVI IF functions for

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/guc: Protect against HAS_GUC_* returning true values other than one (rev3)

== Series Details == Series: drm/i915/guc: Protect against HAS_GUC_* returning true values other than one (rev3) URL : https://patchwork.freedesktop.org/series/9473/ State : failure == Summary == Applying: drm/i915/guc: Protect against HAS_GUC_* returning true values other than one Using

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Wake up the bottom-half if we steal their interrupt

== Series Details == Series: drm/i915: Wake up the bottom-half if we steal their interrupt URL : https://patchwork.freedesktop.org/series/9515/ State : failure == Summary == Series 9515v1 drm/i915: Wake up the bottom-half if we steal their interrupt

Re: [Intel-gfx] [PATCH] drm/i915/guc: Protect against HAS_GUC_* returning true values other than one

On 05/07/16 12:56, Tvrtko Ursulin wrote: On 05/07/16 12:50, Dave Gordon wrote: On 04/07/16 15:30, Tvrtko Ursulin wrote: From: Tvrtko Ursulin At the moment HAS_GUC_UCODE == HAS_GUC == IS_GEN9 == (INTEL_INFO(dev)->gen_mask & BIT(8)), which is true but not one. And

Re: [Intel-gfx] [PATCH] drm/i915: remove superfluous i915_gem_object_free_mmap_offset call

On Tue, Jul 05, 2016 at 01:00:19PM +0100, Matthew Auld wrote: > This should already be handled by drm_gem_object_release, which is > called later on. > > Cc: Chris Wilson > Signed-off-by: Matthew Auld Reviewed-by: Chris Wilson

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Always double check for a missed interrupt for new bottom halves

== Series Details == Series: drm/i915: Always double check for a missed interrupt for new bottom halves URL : https://patchwork.freedesktop.org/series/9514/ State : warning == Summary == Series 9514v1 drm/i915: Always double check for a missed interrupt for new bottom halves

[Intel-gfx] [PATCH] drm/i915: remove superfluous i915_gem_object_free_mmap_offset call

This should already be handled by drm_gem_object_release, which is called later on. Cc: Chris Wilson Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem.c | 1 - 1 file changed, 1 deletion(-) diff --git

Re: [Intel-gfx] [PATCH] drm/i915/guc: Protect against HAS_GUC_* returning true values other than one

On 05/07/16 12:50, Dave Gordon wrote: On 04/07/16 15:30, Tvrtko Ursulin wrote: From: Tvrtko Ursulin At the moment HAS_GUC_UCODE == HAS_GUC == IS_GEN9 == (INTEL_INFO(dev)->gen_mask & BIT(8)), which is true but not one. And module parameters are integers and not

Re: [Intel-gfx] [PATCH] drm/i915: Always double check for a missed interrupt for new bottom halves

On Tue, Jul 05, 2016 at 12:29:05PM +0100, Chris Wilson wrote: > After assigning ourselves as the new bottom-half, we must perform a > cursory check to prevent a missed interrupt. Either we miss the interrupt > whilst programming the hardware, or if there was a previous waiter (for > a later

Re: [Intel-gfx] [PATCH] drm/i915: Wake up the bottom-half if we steal their interrupt

On Tue, Jul 05, 2016 at 12:45:55PM +0100, Chris Wilson wrote: > Following on from the scenario Tvrtko envision to explain a hard-to-hit > race with multiple first waiters, we could also then race in the > __i915_request_irq_complete() and the bottom-half may miss the vital > irq-seqno barrier and

Re: [Intel-gfx] [PATCH] drm/i915/guc: Protect against HAS_GUC_* returning true values other than one

On 04/07/16 15:30, Tvrtko Ursulin wrote: From: Tvrtko Ursulin At the moment HAS_GUC_UCODE == HAS_GUC == IS_GEN9 == (INTEL_INFO(dev)->gen_mask & BIT(8)), which is true but not one. And module parameters are integers and not booleans so compiler will not normalize the

[Intel-gfx] [PATCH] drm/i915: Wake up the bottom-half if we steal their interrupt

Following on from the scenario Tvrtko envision to explain a hard-to-hit race with multiple first waiters, we could also then race in the __i915_request_irq_complete() and the bottom-half may miss the vital irq-seqno barrier and so go to sleep not noticing their seqno is complete. Signed-off-by:

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/4] drm/i915: Split out runtime configuration of device info to its own file

== Series Details == Series: series starting with [1/4] drm/i915: Split out runtime configuration of device info to its own file URL : https://patchwork.freedesktop.org/series/9512/ State : failure == Summary == Series 9512v1 Series without cover letter

[Intel-gfx] [PATCH] drm/i915: Always double check for a missed interrupt for new bottom halves

After assigning ourselves as the new bottom-half, we must perform a cursory check to prevent a missed interrupt. Either we miss the interrupt whilst programming the hardware, or if there was a previous waiter (for a later seqno) they may be woken instead of us (due to the inherent race in the

Re: [Intel-gfx] [PATCH] drm/i915/guc: Protect against HAS_GUC_* returning true values other than one

This is not quite right. If no guc loading then there should be no guc_submission can't have submission without loading. But, I guess that should be handled later. Peter. -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Split out runtime configuration of device info to its own file

On Tue, Jul 05, 2016 at 11:44:07AM +0100, Matthew Auld wrote: > > + > > +#include "i915_drv.h" > > + > > +void intel_device_info_dump(struct drm_i915_private *dev_priv) > > +{ > > + const struct intel_device_info *info = _priv->info; > mkwrite_device_info(dev_priv)? Here we just want the

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Split out runtime configuration of device info to its own file

> + > +#include "i915_drv.h" > + > +void intel_device_info_dump(struct drm_i915_private *dev_priv) > +{ > + const struct intel_device_info *info = _priv->info; mkwrite_device_info(dev_priv)? On a similar note there is one other in intel_lrc.c, maybe fix in a follow up patch :) Reviewed-by:

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Skip capturing an error state if we already have one

On Tue, Jul 05, 2016 at 01:10:29PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > As we only ever keep the first error state around, we can avoid some > > work that can be quite intrusive if we don't record the error the second > > time around. This does move

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: remove redundant fbc warnings

== Series Details == Series: drm/i915: remove redundant fbc warnings URL : https://patchwork.freedesktop.org/series/9509/ State : failure == Summary == Series 9509v1 drm/i915: remove redundant fbc warnings http://patchwork.freedesktop.org/api/1.0/series/9509/revisions/1/mbox Test

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Skip capturing an error state if we already have one

Chris Wilson writes: > As we only ever keep the first error state around, we can avoid some > work that can be quite intrusive if we don't record the error the second > time around. This does move the race whereby the user could discard one > error state as the second

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Amalgamate gen6_mm_switch() and vgpu_mm_switch()

Chris Wilson writes: > These are identical, so let's just use the same vfunc. > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_gem_gtt.c | 29

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Remove impossible tests for dev->dev_private

Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Amalgamate gen6_mm_switch() and vgpu_mm_switch()

On Tue, Jul 05, 2016 at 12:59:25PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > These are identical, so let's just use the same vfunc. > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/i915_gem_gtt.c | 29

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Remove use of dev_priv->dev backpointer in __i915_printk()

Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Clean up GPU hang message

Chris Wilson writes: > Remove some redundant kernel messages as we deduce a hung GPU and > capture the error state. > > v2: Fix "hang" vs "no progress" message whilst I was there > v3: s/snprintf/scnprintf/ > > Signed-off-by: Chris Wilson >

Re: [Intel-gfx] [PATCH] intel: Export pooled EU and min no. of eus in a pool.

On 15/06/2016 09:19, Yang Rong wrote: Update kernel interface with new I915_GETPARAM ioctl entries for pooled EU and min no. of eus in a pool. Add a wrapping function for each parameter. Userspace drivers need these values when decide the thread count. This kernel enabled pooled eu by default

Re: [Intel-gfx] [PATCH] drm/i915: Replace lockless_dereference(bool) with READ_ONCE()

On Tue, Jul 05, 2016 at 12:54:50PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > After Joonas complained about using READ_ONCE() on the only use of the > > variable in the function, where the intent was to simply document that > > the read was intentionally

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Amalgamate gen6_mm_switch() and vgpu_mm_switch()

Chris Wilson writes: > These are identical, so let's just use the same vfunc. > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/i915_gem_gtt.c | 29 + > 1 file changed, 5 insertions(+), 24 deletions(-) >

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/dmc: Accept symbolic link in firmware name

== Series Details == Series: drm/i915/dmc: Accept symbolic link in firmware name URL : https://patchwork.freedesktop.org/series/9508/ State : failure == Summary == Series 9508v1 drm/i915/dmc: Accept symbolic link in firmware name

Re: [Intel-gfx] [PATCH] drm/i915: Replace lockless_dereference(bool) with READ_ONCE()

Chris Wilson writes: > After Joonas complained about using READ_ONCE() on the only use of the > variable in the function, where the intent was to simply document that > the read was intentionally racy and unlocked, I switched the READ_ONCE() > over to

[Intel-gfx] [PATCH 4/4] drm/i915: Convert dev_priv->dev backpointers to dev_priv->drm

Since drm_i915_private is now a subclass of drm_device we do not need to chase the drm_i915_private->dev backpointer and can instead simply access drm_i915_private->drm directly. textdata bss dec hex filename 10687574565 416 1073738 10624a drivers/gpu/drm/i915/i915.ko

[Intel-gfx] [PATCH 2/4] drm/i915: Remove use of dev_priv->dev backpointer in __i915_printk()

As we can just directly use drm_dev->drm.dev, we do not need the drm_dev->dev backpointer anymore and can also loose the warning about order of __i915_printk() and our initialisation (which is now always safe). Signed-off-by: Chris Wilson Cc: Imre Deak

[Intel-gfx] [PATCH 3/4] drm/i915: Remove impossible tests for dev->dev_private

If we have a drm_device, we have a drm_i915_private (since they are the same). Signed-off-by: Chris Wilson Cc: Imre Deak --- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH 1/4] drm/i915: Split out runtime configuration of device info to its own file

Let's reclaim a few hundred lines from i915_drv.c by splitting out the runtime configuration of the "constant" dev_priv->info. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Makefile| 1 + drivers/gpu/drm/i915/i915_drv.c | 413

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915:gen9: implement WaMediaPoolStateCmdInWABB (rev2)

== Series Details == Series: drm/i915:gen9: implement WaMediaPoolStateCmdInWABB (rev2) URL : https://patchwork.freedesktop.org/series/9467/ State : failure == Summary == Series 9467v2 drm/i915:gen9: implement WaMediaPoolStateCmdInWABB

Re: [Intel-gfx] [PATCH v2] drm/i915:gen9: implement WaMediaPoolStateCmdInWABB

Tim Gore  Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ > -Original Message- > From: Chris Wilson [mailto:chris.ickle.wil...@gmail.com] On Behalf Of Chris > Wilson > Sent: Tuesday, July 05, 2016 10:08 AM > To: Gore, Tim > Cc:

[Intel-gfx] [PATCH] drm/i915: remove redundant fbc warnings

The fbc enabled/active sanity checks are already done in __intel_fbc_disable so no need to do them again. Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/intel_fbc.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH] drm/i915/dmc: Accept symbolic link in firmware name

We need the ability to explicitly load only a specified firmware version. As the firmware blob contains the version, we use that to filter out the ones we don't want. The version encoded into the firmware name is superfluous and we should allow user to point into specific firmware through a

Re: [Intel-gfx] [PATCH] drm/i915: Convert dev_priv->dev backpointers to dev_priv->drm

Hi, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160705] [cannot apply to v4.7-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915

Re: [Intel-gfx] [PATCH] drm/i915: Convert dev_priv->dev backpointers to dev_priv->drm

I couldn't see any issues so: Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915:gen9: implement WaMediaPoolStateCmdInWABB

On Tue, Jul 05, 2016 at 10:01:30AM +0100, tim.g...@intel.com wrote: > From: Tim Gore > > This patch applies WaMediaPoolStateCmdInWABB which fixes > a problem with the restoration of thread counts on resuming > from RC6. > > References: HSD#2137167 > Signed-off-by: Tim Gore

[Intel-gfx] [PATCH v2] drm/i915:gen9: implement WaMediaPoolStateCmdInWABB

From: Tim Gore This patch applies WaMediaPoolStateCmdInWABB which fixes a problem with the restoration of thread counts on resuming from RC6. References: HSD#2137167 Signed-off-by: Tim Gore --- drivers/gpu/drm/i915/intel_lrc.c | 25

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Convert dev_priv->dev backpointers to dev_priv->drm

== Series Details == Series: drm/i915: Convert dev_priv->dev backpointers to dev_priv->drm URL : https://patchwork.freedesktop.org/series/9504/ State : failure == Summary == CC lib/is_single_threaded.o CC drivers/acpi/acpica/utxfmutex.o CC lib/klist.o CC

[Intel-gfx] [PATCH] drm/i915: Convert dev_priv->dev backpointers to dev_priv->drm

Since drm_i915_private is now a subclass of drm_device we do not need to chase the drm_i915_private->dev backpointer and can instead simply access drm_i915_private->drm directly. textdata bss dec hex filename 10687574565 416 1073738 10624a drivers/gpu/drm/i915/i915.ko

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: Replace lockless_dereference(bool) with READ_ONCE()

== Series Details == Series: drm/i915: Replace lockless_dereference(bool) with READ_ONCE() URL : https://patchwork.freedesktop.org/series/9501/ State : success == Summary == Series 9501v1 drm/i915: Replace lockless_dereference(bool) with READ_ONCE()

Re: [Intel-gfx] linux-next: build failure after merge of the tip tree (from the drm-intel tree)

On Tue, Jul 05, 2016 at 01:53:03PM +1000, Stephen Rothwell wrote: > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index d3502c0603e5..1f91f187b2a8 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3290,7 +3290,7 @@

[Intel-gfx] [PATCH] drm/i915: Replace lockless_dereference(bool) with READ_ONCE()

After Joonas complained about using READ_ONCE() on the only use of the variable in the function, where the intent was to simply document that the read was intentionally racy and unlocked, I switched the READ_ONCE() over to lockless_dereference(). However, in linux-next that has a stronger