Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: signal first fence from irq handler if complete

On Fri, Feb 24, 2017 at 10:04:23AM +, Tvrtko Ursulin wrote: > > On 23/02/2017 15:42, Chris Wilson wrote: > >diff --git a/drivers/gpu/drm/i915/i915_gem_request.h > >b/drivers/gpu/drm/i915/i915_gem_request.h > >index 5f73d8c0a38a..0efee879df23 100644 > >---

Re: [Intel-gfx] [RFC 2/3] drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+

On 23/02/2017 21:03, Chris Wilson wrote: On Thu, Feb 23, 2017 at 11:44:18AM -0800, Michel Thierry wrote: [snip] +static int gen8_emit_stop_watchdog(struct drm_i915_gem_request *req) +{ + struct intel_engine_cs *engine = req->engine; + u32 *cs; + + cs =

[Intel-gfx] [PATCH v4 09/12] i2c: designware-baytrail: Acquire P-Unit access on bus acquire

Acquire P-Unit access to stop others from accessing the P-Unit while the PMIC i2c bus is in use. This is necessary because accessing the P-Unit from the kernel may result in the P-Unit trying to access the PMIC i2c bus, which results in a hang when it happens while we own the PMIC i2c bus

[Intel-gfx] [PATCH v4 12/12] drm/i915: Listen for PMIC bus access notifications

Listen for PMIC bus access notifications and get FORCEWAKE_ALL while the bus is accessed to avoid needing to do any forcewakes, which need PMIC bus access, while the PMIC bus is busy: This fixes errors like these showing up in dmesg, usually followed by a gfx or system freeze:

[Intel-gfx] [PATCH v4 02/12] x86/platform/intel/iosf_mbi: Add a PMIC bus access notifier

Some drivers may need to acquire P-Unit managed resources from interrupt context, where they cannot call iosf_mbi_punit_acquire(). This commit adds a notifier chain which allows a driver to get notified (in a process context) before other drivers start accessing the PMIC bus, so that the driver

[Intel-gfx] [PATCH v4 08/12] i2c: designware-baytrail: Add support for cherrytrail

The cherrytrail punit has the pmic i2c bus access semaphore at a different register address. Signed-off-by: Hans de Goede Reviewed-by: Takashi Iwai Tested-by: Takashi Iwai Reviewed-by: Andy Shevchenko

[Intel-gfx] [PATCH v4 00/12] coordinate cht i2c-pmic and i915-punit accesses

Hi All, Here is v4 of my "coordinate cht i2c-pmic and i915-punit accesses" patch-set this version adds a #include " to asm/iosf_mbi.h fixing a compile warning in arch/x86/platform/intel-quark/imr.c . Otherwise there are no changes, here is the cover-letter from v3 with more background info on

[Intel-gfx] [PATCH v4 10/12] i2c: designware-baytrail: Call pmic_bus_access_notifier_chain

Call the iosf_mbi pmic_bus_access_notifier_chain on bus acquire / release. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241 Signed-off-by: Hans de Goede Tested-by: tagorereddy Reviewed-by: Andy Shevchenko

[Intel-gfx] [PATCH v4 05/12] i2c: designware-baytrail: Only check iosf_mbi_available() for shared hosts

If (!shared_host) simply return 0, this avoids delaying the probe if iosf_mbi_available() returns false when an i2c bus is not using the punit semaphore. Also move the if (!iosf_mbi_available()) check to above the dev_info, so that we do not repeat the dev_info on every probe until

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Remove redundant TLB invalidate on switching ppgtt

On Fri, Feb 24, 2017 at 11:47:56AM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > We are required to reload the TLBs around ppgtt switches. However, we > > already do an unconditional TLB invalidate before every batch and a flush > > afterwards, so this

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: signal first fence from irq handler if complete

On Fri, Feb 24, 2017 at 10:19:07AM +, Chris Wilson wrote: > On Fri, Feb 24, 2017 at 10:04:23AM +, Tvrtko Ursulin wrote: > > >diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c > > >b/drivers/gpu/drm/i915/intel_breadcrumbs.c > > >index 027c93e34c97..5f2665aa817c 100644 > > >---

Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Stop repeating tile configuration on stagnation

Looks good to me. Reviewed-by: Tomasz Lis W dniu 2017-02-20 o 16:46, Chris Wilson pisze: On Mon, Feb 20, 2017 at 04:37:47PM +0100, Tomasz Lis wrote: I tested this variant (reverted the change to "pass" variable before testing), and it fixes the issue with count=0 as

Re: [Intel-gfx] [PATCH] drm/i915: Include GuC fw version in error state

On Thu, Feb 23, 2017 at 03:11:37PM -0800, Michel Thierry wrote: > There was no way to check if the platform is running the latest firmware. Can we also add similar patch for the HuC ? > > Cc: Tvrtko Ursulin > Cc: Arkadiusz Hiler >

Re: [Intel-gfx] [PATCH] drm/i915: Include GuC fw version in error state

On Fri, Feb 24, 2017 at 11:43:32AM +0100, Michal Wajdeczko wrote: > On Fri, Feb 24, 2017 at 09:13:29AM +, Chris Wilson wrote: > > On Fri, Feb 24, 2017 at 09:13:05AM +0530, Kamble, Sagar A wrote: > > >Reviewed-by: Sagar Arun Kamble [1] > > > > > >On 2/24/2017

Re: [Intel-gfx] [PATCH] drm/i915: Include GuC fw version in error state

On Fri, Feb 24, 2017 at 09:13:05AM +0530, Kamble, Sagar A wrote: >Reviewed-by: Sagar Arun Kamble [1] > >On 2/24/2017 4:41 AM, Michel Thierry wrote: > > There was no way to check if the platform is running the latest firmware. > > Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH v4 03/12] i2c: designware: Rename accessor_flags to flags

Rename accessor_flags to flags, so that we can use the field for other flags too. This is a preparation patch for adding cherrytrail support to the punit semaphore code. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Acked-by:

[Intel-gfx] [PATCH v4 04/12] i2c: designware-baytrail: Pass dw_i2c_dev into helper functions

Pass dw_i2c_dev into the helper functions, this is a preparation patch for the punit semaphore fixes done in the other patches in this set. Signed-off-by: Hans de Goede Reviewed-by: Takashi Iwai Tested-by: Takashi Iwai Reviewed-by: Andy

[Intel-gfx] [PATCH v4 07/12] i2c: designware-baytrail: Fix race when resetting the semaphore

Use iosf_mbi_modify instead of iosf_mbi_read + iosf_mbi_write so that we keep the iosf_mbi_lock locked during the read-modify-write done to reset the semaphore. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Acked-by: Jarkko

[Intel-gfx] [PATCH v4 06/12] i2c: designware-baytrail: Disallow the CPU to enter C6 or C7 while holding the punit semaphore

On my cherrytrail tablet with axp288 pmic, just doing a bunch of repeated reads from the pmic, e.g. "i2cdump -y 14 0x34" would lookup the tablet in 1 - 3 runs guaranteed. This seems to be causes by the cpu trying to enter C6 or C7 while we hold the punit bus semaphore, at which point everything

[Intel-gfx] [PATCH v4 11/12] drm/i915: Add intel_uncore_suspend / resume functions

Rename intel_uncore_early_sanitize to intel_uncore_resume, dropping the (always true) restore_forcewake argument and add a new intel_uncore_resume function to replace the intel_uncore_forcewake_reset(dev_priv, false) calls done from the suspend / runtime_suspend functions and make

[Intel-gfx] [PATCH v4 01/12] x86/platform/intel/iosf_mbi: Add a mutex for P-Unit access

One some systems the P-Unit accesses the PMIC to change various voltages through the same bus as other kernel drivers use for e.g. battery monitoring. If a driver sends requests to the P-Unit which require the P-Unit to access the PMIC bus while another driver is also accessing the PMIC bus

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Remove redundant TLB invalidate on switching contexts

Chris Wilson writes: > We are required to reload the TLBs around context switches > (MI_SET_CONTEXT specifically) and the recommendation is do that before > the MI_SET_CONTEXT so that it is serialised with the switch and not > forgotten: > > [DevSNB] If Flush TLB

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Delay disabling the user interrupt for breadcrumbs

On 23/02/2017 15:42, Chris Wilson wrote: A significant cost in setting up a wait is the overhead of enabling the interrupt. As we disable the interrupt whenever the queue of waiters is empty, if we are frequently waiting on alternating batches, we end up re-enabling the interrupt on a frequent

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Delay disabling the user interrupt for breadcrumbs

On Fri, Feb 24, 2017 at 10:34:07AM +, Tvrtko Ursulin wrote: > > On 23/02/2017 15:42, Chris Wilson wrote: > >A significant cost in setting up a wait is the overhead of enabling the > >interrupt. As we disable the interrupt whenever the queue of waiters is > >empty, if we are frequently waiting

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: signal first fence from irq handler if complete

On 24/02/2017 10:19, Chris Wilson wrote: On Fri, Feb 24, 2017 at 10:04:23AM +, Tvrtko Ursulin wrote: On 23/02/2017 15:42, Chris Wilson wrote: diff --git a/drivers/gpu/drm/i915/i915_gem_request.h b/drivers/gpu/drm/i915/i915_gem_request.h index 5f73d8c0a38a..0efee879df23 100644 ---

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Suppress context restore w/a when using MI_RESTORE_INHIBIT

Chris Wilson writes: > If we are setting the context and do inhibit the restoration from the > context image, also forgo applying the set-context w/a. > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/i915_gem_context.c | 12

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Remove redundant TLB invalidate on switching ppgtt

Chris Wilson writes: > We are required to reload the TLBs around ppgtt switches. However, we > already do an unconditional TLB invalidate before every batch and a flush > afterwards, so this condition is already satisfied without extra flushes > around the LRI

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: signal first fence from irq handler if complete

On 23/02/2017 15:42, Chris Wilson wrote: As execlists and other non-semaphore multi-engine devices coordinate between engines using interrupts, we can shave off a few 10s of microsecond of scheduling latency by doing the fence signaling from the interrupt as opposed to a RT kthread.

Re: [Intel-gfx] [GIT PULL] more GVT-g fixes for 4.11

On Fri, 24 Feb 2017, Zhenyu Wang wrote: > Hi, > > This pull includes latest GVT-g fixes for 4.11 to resolve stablity > and usability issues found during co-debugging with distribution > developers which improves a lot. I'll pull this in when we have v4.11-rc1. BR, Jani.

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Reduce context alignment

Chris Wilson writes: > No hardware was ever shipped that needed more than 4096 byte alignment > and future hardware will not use this legacy path. So reduce the > alignment to make it easier and quicker to launch workloads. > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/i915: Include GuC fw version in error state

On Fri, Feb 24, 2017 at 09:13:29AM +, Chris Wilson wrote: > On Fri, Feb 24, 2017 at 09:13:05AM +0530, Kamble, Sagar A wrote: > >Reviewed-by: Sagar Arun Kamble [1] > > > >On 2/24/2017 4:41 AM, Michel Thierry wrote: > > > > There was no way to check if the

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Suppress context restore w/a when using MI_RESTORE_INHIBIT

On Fri, Feb 24, 2017 at 12:45:54PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > If we are setting the context and do inhibit the restoration from the > > context image, also forgo applying the set-context w/a. > > > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/pm_rps: Add waitboost-softlimit test

On Fri, Feb 24, 2017 at 11:58:53AM +0100, Radoslaw Szwichtenberg wrote: > Test verifies that frequency gets boosted to gt_boost_freq_mhz > even though gt_max_freq_mhz is lower than gt_boost_freq_mhz. And the converse check would be good, that setting boost to min prevents boosting. -Chris --

[Intel-gfx] [CI] drm/i915/fbdev: Stop repeating tile configuration on stagnation

If we cease making progress in finding matching outputs for a tiled configuration, stop looping over the remaining unconfigured outputs. v2: Use conn_seq (instead of pass) to only apply tile configuration on first pass. Fixes: b0ee9e7fa5b4 ("drm/fb: add support for tiled monitor configurations.

Re: [Intel-gfx] [PATCH 03/15] drm/i915: Drop spinlocks around adding to the client request list

Chris Wilson writes: > Adding to the tail of the client request list as the only other user is > in the throttle ioctl that iterates forwards over the list. It only > needs protection against deletion of a request as it reads it, it simply > won't see a new request

Re: [Intel-gfx] [PATCH v2] Add the new tool for create GVT-g Linux guest based on KVMGT

A couple of comments below. On Thu, Jan 19, 2017 at 04:32:19PM +0800, Terrence Xu wrote: > GVT-g (Intel® Graphics Virtualization Technology) is a full GPU > virtualization solution with mediated pass-through support. > > This tool is for create basic Linux guest based on KVMGT with VFIO >

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/fbdev: Stop repeating tile configuration on stagnation

On Fri, Feb 24, 2017 at 12:22:35PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915/fbdev: Stop repeating tile configuration on stagnation > URL : https://patchwork.freedesktop.org/series/20203/ > State : success > > == Summary == > > Series 20203v1 drm/i915/fbdev: Stop

Re: [Intel-gfx] [PATCH i-g-t 1/2] tests/pm_rps: Replace custom load function with dummy load

On Fri, Feb 24, 2017 at 11:58:52AM +0100, Radoslaw Szwichtenberg wrote: > There is no point in using custom function if there lib counterpart. > > Cc: Arkadiusz Hiler > Cc: Michal Winiarski > Signed-off-by: Radoslaw Szwichtenberg

Re: [Intel-gfx] [PATCH 07/15] drm/i915: Stop using obj->obj_exec_link outside of execbuf

Chris Wilson writes: > i915_gem_stolen_list_info() sneakily takes advantage of the > obj->obj_exec_link to save itself from having to allocate. Enough of the > subterfuge, just allocate an array of pointers and sort them instead of > the list. > Justifiable by itself

[Intel-gfx] [PATCH i-g-t] benchmarks/gem_latency: Fix compiler warning

Fix compiler warning about I915_EXEC_FENCE_OUT definition/redefinition as it is defined in libdrm/i915_drm.h:890:0 gem_latency.c:48:0: warning: "I915_EXEC_FENCE_OUT" redefined #define I915_EXEC_FENCE_OUT (1 << 17) ^ In file included from ../lib/intel_batchbuffer.h:6:0, from

[Intel-gfx] [PATCH i-g-t 1/2] tests/pm_rps: Replace custom load function with dummy load

There is no point in using custom function if there lib counterpart. Cc: Arkadiusz Hiler Cc: Michal Winiarski Signed-off-by: Radoslaw Szwichtenberg --- tests/pm_rps.c | 79

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: signal first fence from irq handler if complete

On Fri, Feb 24, 2017 at 10:47:29AM +, Tvrtko Ursulin wrote: > > On 24/02/2017 10:19, Chris Wilson wrote: > >Ah, found the complication. Here we want intel_engine_wakeup() to > >report if there was a waiter, but in intel_breadcrumbs_hangcheck, we > >want to know if we failed to wakeup the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/fbdev: Stop repeating tile configuration on stagnation

== Series Details == Series: drm/i915/fbdev: Stop repeating tile configuration on stagnation URL : https://patchwork.freedesktop.org/series/20203/ State : success == Summary == Series 20203v1 drm/i915/fbdev: Stop repeating tile configuration on stagnation

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Detect an out-of-order context switch

Chris Wilson writes: > We require that the request is completed before the context is switched > away. > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/intel_lrc.c | 1 + > 1

[Intel-gfx] [PATCH i-g-t 2/2] tests/pm_rps: Add waitboost-softlimit test

Test verifies that frequency gets boosted to gt_boost_freq_mhz even though gt_max_freq_mhz is lower than gt_boost_freq_mhz. Cc: Arkadiusz Hiler Cc: Michal Winiarski Signed-off-by: Radoslaw Szwichtenberg

Re: [Intel-gfx] [PATCH 06/15] drm/i915: Split vma exec_link/evict_link

Chris Wilson writes: > Currently the vma has one link member that is used for both holding its > place in the execbuf reservation list, and in any eviction list. This > dual property is quite tricky and error prone. > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Refactor code to select the DDI buf translation table

On Thu, Feb 23, 2017 at 07:49:21PM +0200, David Weinehall wrote: > On Thu, Feb 23, 2017 at 07:35:05PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Split the code to select the correct trasnslation table into DP, > > translations,

Re: [Intel-gfx] [PATCH] drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW

On Mon, Feb 20, 2017 at 03:30:58PM +0100, Maarten Lankhorst wrote: > Op 20-02-17 om 14:38 schreef Ville Syrjälä: > > On Mon, Feb 20, 2017 at 10:04:06AM +0100, Maarten Lankhorst wrote: > >> Op 17-02-17 om 16:01 schreef ville.syrj...@linux.intel.com: > >>> From: Ville Syrjälä

Re: [Intel-gfx] [PATCH i-g-t] benchmarks/gem_latency: Fix compiler warning

On Fri, Feb 24, 2017 at 03:03:32PM +0200, Mika Kahola wrote: > Fix compiler warning about I915_EXEC_FENCE_OUT definition/redefinition > as it is defined in libdrm/i915_drm.h:890:0 > > gem_latency.c:48:0: warning: "I915_EXEC_FENCE_OUT" redefined > #define I915_EXEC_FENCE_OUT (1 << 17) > ^ > In

Re: [Intel-gfx] [PATCH v3 6/6] drm/i915: Only enable DDI IO power domains after enabling DPLL

On Wed, Feb 22, 2017 at 08:34:31AM +0200, Ander Conselvan de Oliveira wrote: > According to bspec, the DDI IO power domains should be enabled after > enabling the DPLL and mapping it to the DDI. The current order doesn't > seem to create problems with Skylake and Kabylake, but causes enable >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/915/glk: Enable pooled EUs for Geminilake

== Series Details == Series: drm/915/glk: Enable pooled EUs for Geminilake URL : https://patchwork.freedesktop.org/series/20212/ State : success == Summary == Series 20212v1 drm/915/glk: Enable pooled EUs for Geminilake https://patchwork.freedesktop.org/api/1.0/series/20212/revisions/1/mbox/

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lspcon: Switch back to PCON mode after output replug (rev2)

On Wed, Feb 22, 2017 at 05:52:19PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/lspcon: Switch back to PCON mode after output replug (rev2) > URL : https://patchwork.freedesktop.org/series/20072/ > State : success I pushed the patch to -dinq, thanks for the

[Intel-gfx] [PATCH v2] drm/i915/gen9: Increase PCODE request timeout to 50ms

After commit 2c7d0602c815277f7cb7c932b091288710d8aba7 Author: Imre Deak Date: Mon Dec 5 18:27:37 2016 +0200 drm/i915/gen9: Fix PCODE polling during CDCLK change notification there is still one report of the CDCLK-change request timing out on a KBL machine, see the

Re: [Intel-gfx] [PATCH v3 3/6] drm/i915: Check encoder type in enc_to_dig_port()

On Wed, Feb 22, 2017 at 08:34:28AM +0200, Ander Conselvan de Oliveira wrote: > Don't allow conversion from arbitraty encoder types to a digital port. > Calling enc_to_dig_port() with the wrong encoder may seem far fetched, > but certain paths of the ddi code may be called with hasell's analog >

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Detect an out-of-order context switch

On Fri, Feb 24, 2017 at 02:49:25PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > We require that the request is completed before the context is switched > > away. > > > > Signed-off-by: Chris Wilson > > Reviewed-by: Mika Kuoppala

Re: [Intel-gfx] [PATCH 12/15] drm/i915: Wait upon userptr get-user-pages within execbuffer

On Thu, Feb 23, 2017 at 04:18:27PM +, Chris Wilson wrote: > This simply hides the EAGAIN caused by userptr when userspace causes > resource contention. However, it is quite beneficial with highly > contended userptr users as we avoid repeating the setup costs and > kernel-user context

[Intel-gfx] [PATCH] drm/i915: Only enable DDI IO power domains after enabling DPLL

According to bspec, the DDI IO power domains should be enabled after enabling the DPLL and mapping it to the DDI. The current order doesn't seem to create problems with Skylake and Kabylake, but causes enable timeouts in Geminilake. v2: Rebase. - Take power domain references before sanitizing

[Intel-gfx] [PATCH] drm/i915: Check encoder type in enc_to_dig_port()

Don't allow conversion from arbitraty encoder types to a digital port. Calling enc_to_dig_port() with the wrong encoder may seem far fetched, but certain paths of the ddi code may be called with hasell's analog encoder and the conversion is wrong for DP mst encoders too, so safe guard against it.

[Intel-gfx] [PATCH] drm/915/glk: Enable pooled EUs for Geminilake

Geminilake also supports pooled EUs. Enable it. It is unclear if the recommendation to disable it for 2x6 configurations from commit e015dd69b2cf ("drm/i915/bxt: Add WaEnablePooledEuFor2x6") should also apply to GLK, but the only userspace that uses this only cares about the 3x6 configuration.

[Intel-gfx] [PATCH] drm/i915: Check encoder type in enc_to_dig_port()

Don't allow conversion from arbitraty encoder types to a digital port. Calling enc_to_dig_port() with the wrong encoder may seem far fetched, but certain paths of the ddi code may be called with hasell's analog encoder and the conversion is wrong for DP mst encoders too, so safe guard against it.

Re: [Intel-gfx] [PATCH 12/15] drm/i915: Wait upon userptr get-user-pages within execbuffer

On Fri, Feb 24, 2017 at 02:53:07PM +0100, Michał Winiarski wrote: > On Thu, Feb 23, 2017 at 04:18:27PM +, Chris Wilson wrote: > > This simply hides the EAGAIN caused by userptr when userspace causes > > resource contention. However, it is quite beneficial with highly > > contended userptr

[Intel-gfx] [PATCH 3/3] drm/i915: Include HuC fw version in error state

HuC depends on GuC, so be it. Suggested-by: Michal Wajdeczko Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/i915_gpu_error.c | 11 +++ 2 files changed, 13 insertions(+) diff

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Include GuC fw version in error state

On Fri, Feb 24, 2017 at 11:05:29AM -0800, Michel Thierry wrote: > There was no way to check if the platform is running the latest > firmware. > > v2: use HAS_GUC and intel_guc* (Michal) > capture before reset (Chris) > > Cc: Chris Wilson > Cc: Michal Wajdeczko

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Include HuC fw version in error state

On Fri, Feb 24, 2017 at 11:05:30AM -0800, Michel Thierry wrote: > HuC depends on GuC, so be it. > > Suggested-by: Michal Wajdeczko > Signed-off-by: Michel Thierry > --- > drivers/gpu/drm/i915/i915_drv.h | 2 ++ >

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Capture dmc firmware information before reset

On Fri, Feb 24, 2017 at 11:25:29AM -0800, Michel Thierry wrote: > On 2/24/2017 11:22 AM, Chris Wilson wrote: > >On Fri, Feb 24, 2017 at 11:05:28AM -0800, Michel Thierry wrote: > >>The firmware may change between the hang and cat /sys/class/drm/card0/error > >> > >>Cc: Chris Wilson

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Capture dmc firmware information before reset

== Series Details == Series: series starting with [1/3] drm/i915: Capture dmc firmware information before reset URL : https://patchwork.freedesktop.org/series/20220/ State : success == Summary == Series 20220v1 Series without cover letter

Re: [Intel-gfx] [RFC] drm/i915/guc: Smurf the GuC context

On 24/02/17 06:33, Oscar Mateo wrote: While trying to get up to speed with the GuC, the thing that bothers me the most is that we have so many things called "context" in the driver, that when I talk with someone about it we invariably end up sounding like The Smurfs (update the context ID in

Re: [Intel-gfx] [PATCH] drm/i915: Check encoder type in enc_to_dig_port()

On Fri, Feb 24, 2017 at 04:18:45PM +0200, Ander Conselvan de Oliveira wrote: > Don't allow conversion from arbitraty encoder types to a digital port. > Calling enc_to_dig_port() with the wrong encoder may seem far fetched, > but certain paths of the ddi code may be called with hasell's analog >

[Intel-gfx] ✗ Fi.CI.BAT: failure for GuC Scrub vol. 1 (rev5)

== Series Details == Series: GuC Scrub vol. 1 (rev5) URL : https://patchwork.freedesktop.org/series/16856/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/gvt/gtt.o LD drivers/thermal/thermal_sys.o CC [M] drivers/gpu/drm/i915/gvt/cfg_space.o LD

Re: [Intel-gfx] [PATCH 05/10] drm/i915/uc: Introduce intel_uc_init_fw()

On Fri, Feb 24, 2017 at 04:39:59PM +0100, Arkadiusz Hiler wrote: > Instead of calling intel_guc_init() and intel_huc_init() one by one this > patch introduces intel_uc_init_fw() function that calls them both. > > Called functions are renamed accordingly. > > Trying to have subject_verb_object

Re: [Intel-gfx] [PATCH resend 06/15] drm/i915/dsi: Make intel_dsi_enable/disable directly exec VBT sequences

On Mon, 20 Feb 2017 15:08:36 +0100 Hans de Goede wrote: > The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are > not fine grained enough to abstract all the different steps we need to > take (and VBT sequences we need to exec) properly. So simply remove the

Re: [Intel-gfx] [PATCH resend 03/15] drm/i915/dsi: Add intel_dsi_unprepare() helper

On Mon, 20 Feb 2017 15:08:33 +0100 Hans de Goede wrote: > The enable path has an intel_dsi_prepare() helper which prepares various > registers for the mode-set. Move the code undoing this to a new > intel_dsi_unprepare() helper function for better symmetry between the >

Re: [Intel-gfx] [PATCH resend 02/15] drm/i915/dsi: Merge intel_dsi_disable/enable into their respective callers

On Mon, 20 Feb 2017 15:08:32 +0100 Hans de Goede wrote: > intel_dsi_disable/enable only have one caller, merge them into their > respective callers. > > Change msleep(2) into usleep_range(2000, 5000) to make checkpatch happy, > otherwise no functional changes. > > The main

Re: [Intel-gfx] [PATCH resend 04/15] drm/i915/dsi: Move intel_dsi_clear_device_ready()

On Mon, 20 Feb 2017 15:08:34 +0100 Hans de Goede wrote: > Move the intel_dsi_clear_device_ready() function to higher up in > intel_dsi.c this pairs it with intel_dsi_device_ready(); and pairs > intel_dsi_*enable* with intel_dsi_*disable without >

Re: [Intel-gfx] [PATCH] drm/i915: Include GuC fw version in error state

On Fri, Feb 24, 2017 at 08:30:43AM -0800, Michel Thierry wrote: > On 2/24/2017 2:49 AM, Chris Wilson wrote: > >On Fri, Feb 24, 2017 at 11:43:32AM +0100, Michal Wajdeczko wrote: > >>On Fri, Feb 24, 2017 at 09:13:29AM +, Chris Wilson wrote: > >>>On Fri, Feb 24, 2017 at 09:13:05AM +0530, Kamble,

Re: [Intel-gfx] [PATCH resend 11/15] drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight

On Mon, 20 Feb 2017 15:08:41 +0100 Hans de Goede wrote: > Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as > we call intel_panel_enable_backlight() / intel_panel_disable_backlight(). > > Signed-off-by: Hans de Goede I'm not sure

Re: [Intel-gfx] [PATCH resend 10/15] drm/i915/dsi: Execute MIPI_SEQ_DEASSERT_RESET before calling device_ready()

On Mon, 20 Feb 2017 15:08:40 +0100 Hans de Goede wrote: > Execute MIPI_SEQ_DEASSERT_RESET before putting the device in ready > state (LP-11), this is the sequence in which things should be done > according to the spec. > > Signed-off-by: Hans de Goede

Re: [Intel-gfx] [PATCH resend 09/15] drm/i915/dsi: Group DPOunit clock gate workaround with PLL enable

On Mon, 20 Feb 2017 15:08:39 +0100 Hans de Goede wrote: > Move the DPOunit clock gate workaround to directly after the PLL enable. > > The exact location of the workaround does not matter and there are 2 > reasons to group it with the PLL enable: > > 1) This moves it out

Re: [Intel-gfx] [PATCH resend 08/15] drm/i915/dsi: Move MIPI_SEQ_POWER_ON/OFF calls together with pmic gpio calls

On Mon, 20 Feb 2017 15:08:38 +0100 Hans de Goede wrote: > Now that we are no longer bound to the drm_panel_ callbacks, call > MIPI_SEQ_POWER_ON/OFF at the proper place. > > Signed-off-by: Hans de Goede Reviewed-by: Bob Paauwe

Re: [Intel-gfx] [PATCH resend 05/15] drm/i915/dsi: Document the panel enable / disable sequences from the spec

On Mon, 20 Feb 2017 15:08:35 +0100 Hans de Goede wrote: > Document the DSI panel enable / disable sequences from the spec, > for easy comparison between the code and the spec. > > Signed-off-by: Hans de Goede > Acked-by: Jani Nikula

Re: [Intel-gfx] [PATCH resend 07/15] drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ON

On Mon, 20 Feb 2017 15:08:37 +0100 Hans de Goede wrote: > MIPI_SEQ_ASSERT_RESET before POWER_ON is not necessary for 2 reasons: > 1) The reset should already be asserted before intel_dsi_pre_enable() >gets called > 2) Most (some?) VBTs will ensure reset was asserted in

[Intel-gfx] ✓ Fi.CI.BAT: success for Fix Geminilake DDI power well enable timeouts (rev6)

== Series Details == Series: Fix Geminilake DDI power well enable timeouts (rev6) URL : https://patchwork.freedesktop.org/series/19451/ State : success == Summary == Series 19451v6 Fix Geminilake DDI power well enable timeouts

Re: [Intel-gfx] [PATCH] drm/i915: Include GuC fw version in error state

On 2/24/2017 2:49 AM, Chris Wilson wrote: On Fri, Feb 24, 2017 at 11:43:32AM +0100, Michal Wajdeczko wrote: On Fri, Feb 24, 2017 at 09:13:29AM +, Chris Wilson wrote: On Fri, Feb 24, 2017 at 09:13:05AM +0530, Kamble, Sagar A wrote: Reviewed-by: Sagar Arun Kamble

Re: [Intel-gfx] [PATCH] drm/i915: Include GuC fw version in error state

On 2/24/2017 9:15 AM, Chris Wilson wrote: On Fri, Feb 24, 2017 at 08:30:43AM -0800, Michel Thierry wrote: On 2/24/2017 2:49 AM, Chris Wilson wrote: On Fri, Feb 24, 2017 at 11:43:32AM +0100, Michal Wajdeczko wrote: On Fri, Feb 24, 2017 at 09:13:29AM +, Chris Wilson wrote: On Fri, Feb

[Intel-gfx] [PATCH 10/10] drm/i915/uc: Add params for specifying firmware

`guc_firmware_path` and `huc_firmware_path` module parameters are added. Using the parameter disabled version checks and loads desired firmware instead of the default one. Cc: Chris Wilson Cc: Joonas Lahtinen Cc: Michal Winiarski

[Intel-gfx] [PATCH 04/10] drm/i915/uc: Move intel_uc_fw_fetch() to intel_uc.c

The file fits better. Additionally rename it to intel_uc_prepare_fw(), as the function does more than simple fetch. Signed-off-by: Arkadiusz Hiler --- drivers/gpu/drm/i915/intel_guc_loader.c | 137 +--- drivers/gpu/drm/i915/intel_huc.c

[Intel-gfx] [PATCH 03/10] drm/i915/huc: Add huc_to_i915

Used to obtain "dev_priv" from huc struct pointer. We already have similar thing for guc. Cc: Michal Wajdeczko Signed-off-by: Arkadiusz Hiler Reviewed-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_drv.h |

[Intel-gfx] [PATCH 08/10] drm/i915/uc: Simplify firmware path handling

Currently fw->path values can represent one of three possible states: 1) NULL - device without the uC 2) '\0' - device with the uC but have no firmware 3) else - device with the uC and we have firmware Second case is used only to WARN at a later stage. We can WARN right away and merge cases

[Intel-gfx] [PATCH 07/10] drm/i915/guc: Simplify intel_guc_init_hw()

Current version of intel_guc_init_hw() does a lot: - cares about submission - loads huc - implement WA This change offloads some of the logic to intel_uc_init_hw(), which now cares about the above. v2: rename guc_hw_reset and fix typo in define name (M. Wajdeczko) v3: rename once again v4:

[Intel-gfx] [PATCH 05/10] drm/i915/uc: Introduce intel_uc_init_fw()

Instead of calling intel_guc_init() and intel_huc_init() one by one this patch introduces intel_uc_init_fw() function that calls them both. Called functions are renamed accordingly. Trying to have subject_verb_object ordering and more descriptive names, the intel_huc_init() and intel_guc_init()

[Intel-gfx] [PATCH 09/10] drm/i915/uc: Separate firmware selection and preparation

intel_{h,g}uc_init_fw selects correct firmware and then triggers it's preparation (fetch + initial parsing). This change separates out select steps, so those can be called by the sanitize_options(). Then, during the init_fw() we prepare the firmware if the firmware was selected. Cc: Michal

[Intel-gfx] [PATCH 02/10] drm/i915/uc: Drop superfluous externs in intel_uc.h

Externs are implicit and we generally try to avoid them. Cc: Michal Wajdeczko Signed-off-by: Arkadiusz Hiler Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_uc.h | 12 ++-- 1 file

[Intel-gfx] [PATCH 01/10] drm/i915/uc: Rename intel_?uc_{setup, load}() to _init_hw()

GuC historically has two "startup" functions called _init() and _setup() Then HuC came with it's _init() and _load(). This commit renames intel_guc_setup() and intel_huc_load() to *uc_init_hw() as they called from the i915_gem_init_hw(). The aim is to be consistent in that entry points called

[Intel-gfx] [PATCH 06/10] drm/i915/guc: Extract param logic form guc_init_fw()

Let intel_guc_init_fw() focus on determining and fetching the correct firmware. This patch introduces intel_uc_sanitize_options() that is called from intel_sanitize_options(). Then, if we have GuC, we can call intel_guc_intel_fw() conditionally and we do not have to do the internal checks. v2:

Re: [Intel-gfx] [PATCH] drm/i915: Include GuC fw version in error state

On 2/24/2017 4:19 PM, Chris Wilson wrote: On Fri, Feb 24, 2017 at 11:43:32AM +0100, Michal Wajdeczko wrote: On Fri, Feb 24, 2017 at 09:13:29AM +, Chris Wilson wrote: On Fri, Feb 24, 2017 at 09:13:05AM +0530, Kamble, Sagar A wrote: Reviewed-by: Sagar Arun Kamble

Re: [Intel-gfx] [PATCH] drm/i915: Include GuC fw version in error state

On 2/24/2017 8:15 AM, Michel Thierry wrote: On 2/24/2017 2:40 AM, Michal Wajdeczko wrote: On Thu, Feb 23, 2017 at 03:11:37PM -0800, Michel Thierry wrote: There was no way to check if the platform is running the latest firmware. Can we also add similar patch for the HuC ? Please don't

Re: [Intel-gfx] [PATCH 06/10] drm/i915/guc: Extract param logic form guc_init_fw()

On Fri, Feb 24, 2017 at 04:40:00PM +0100, Arkadiusz Hiler wrote: > Let intel_guc_init_fw() focus on determining and fetching the correct > firmware. > > This patch introduces intel_uc_sanitize_options() that is called from > intel_sanitize_options(). > > Then, if we have GuC, we can call

Re: [Intel-gfx] [PATCH resend 01/15] drm/i915/dsi: Move calling of wait_for_dsi_fifo_empty to mipi_exec_send_packet

On Mon, 20 Feb 2017 15:08:31 +0100 Hans de Goede wrote: > Instead of calling wait_for_dsi_fifo_empty on all dsi ports after calling > a drm_panel_foo helper which calls VBT sequences, move it to the VBT > mipi_exec_send_packet helper, which is the one VBT instruction which >

Re: [Intel-gfx] [PATCH] drm/i915: Include GuC fw version in error state

On 2/24/2017 2:40 AM, Michal Wajdeczko wrote: On Thu, Feb 23, 2017 at 03:11:37PM -0800, Michel Thierry wrote: There was no way to check if the platform is running the latest firmware. Can we also add similar patch for the HuC ? Please don't tell me the HuC can hang the gpu too. Cc:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen9: Increase PCODE request timeout to 100ms (rev2)

== Series Details == Series: drm/i915/gen9: Increase PCODE request timeout to 100ms (rev2) URL : https://patchwork.freedesktop.org/series/19961/ State : success == Summary == Series 19961v2 drm/i915/gen9: Increase PCODE request timeout to 100ms

  1   2   >