[Intel-gfx] [PATCH i-g-t 4/5] tests: fix spelling mistakes

Signed-off-by: Eric Engestrom --- tests/gem_concurrent_all.c | 2 +- tests/gem_cpu_reloc.c | 2 +- tests/gem_flink_race.c | 2 +- tests/gem_seqno_wrap.c | 2 +- tests/gem_tiled_wb.c | 2 +- tests/prime_nv_api.c | 2 +- tests/prime_nv_pcopy.c | 2 +-

[Intel-gfx] [PATCH i-g-t 2/5] assembler: fix spelling mistakes

Signed-off-by: Eric Engestrom --- assembler/brw_defines.h| 2 +- assembler/brw_eu_compact.c | 2 +- assembler/brw_eu_emit.c| 4 ++-- assembler/gen4asm.h| 4 ++-- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/assembler/brw_defines.h

Re: [Intel-gfx] [PATCH] drm/i915/ddi: Silence compiler warning for unknown output type

On Mon, Apr 04, 2016 at 11:45:26AM +0300, Jani Nikula wrote: > On Mon, 04 Apr 2016, Chris Wilson wrote: > > On Mon, Apr 04, 2016 at 09:20:27AM +0300, Joonas Lahtinen wrote: > >> On su, 2016-04-03 at 21:59 +0100, Chris Wilson wrote: > >> > Silences > >> > > >> >

Re: [Intel-gfx] [PATCH 2/2] drm/i915/BXT: Get pipe conf from the port registers

Jani/Daniel, I am working on implementing the pipe_config compare as suggested by daniel at https://lists.freedesktop.org/archives/intel-gfx/2016-March/091148.html But I think this patch need not wait for that change. Either way this patch is required. We can continue review on this and

Re: [Intel-gfx] [PATCH] drm/i915/ddi: Silence compiler warning for unknown output type

On Mon, 04 Apr 2016, Joonas Lahtinen wrote: > Well, enumeration values *known* not to be acceptable should cause a > ERR_PTR(-EINVAL) or along that route, and there should be a > MISSING_CASE for rest totally unexpected values. In this case, they're all the same.

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

On 01/04/16 08:41, Ander Conselvan De Oliveira wrote: > On Thu, 2016-03-31 at 12:38 +, Patchwork wrote: >> == Series Details == >> >> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect >> URL : https://patchwork.freedesktop.org/series/5044/ >> State : success > > I

Re: [Intel-gfx] Fi.CI.BAT: failure for drm/i915: implement WaClearTdlStateAckDirtyBits

Pasted below are Bat results (don't seem to get an email from Bat anymore). > Series 4282v3 drm/i915: implement WaClearTdlStateAckDirtyBits > http://patchwork.freedesktop.org/api/1.0/series/4282/revisions/3/mbox/ > > Test kms_flip: > Subgroup basic-flip-vs-wf_vblank: >

Re: [Intel-gfx] [PATCH v4] drm/i915: Move execlists irq handler to a bottom half

On Mon, Apr 04, 2016 at 12:11:56PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Doing a lot of work in the interrupt handler introduces huge > latencies to the system as a whole. > > Most dramatic effect can be seen by running an all engine > stress test

Re: [Intel-gfx] [PATCH 07/16] drm/i915/bxt: Suspend power domains during suspend-to-idle

On Fri, Apr 01, 2016 at 04:02:38PM +0300, Imre Deak wrote: > On SKL/KBL suspend-to-idle (aka freeze/s0ix) is performed with DMC > firmware assistance where the target display power state is DC6. On > Broxton on the other hand we don't use the firmware for this, but rely > instead on a manual DC9

[Intel-gfx] [PATCH 01/12] drm: Add helper for DP++ adaptors

From: Ville Syrjälä MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8

[Intel-gfx] [PATCH 02/12] drm/i915: Respect DP++ adaptor TMDS clock limit

From: Ville Syrjälä MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Try to detect the max TMDS clock limit for the DP++ adaptor (if any) and take it into account when checking the port clock. Note that as with the sink

[Intel-gfx] [PATCH 03/12] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

From: Ville Syrjälä MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit To save a bit of power, let's try to turn off the TMDS output

[Intel-gfx] [PATCH 04/12] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

From: Ville Syrjälä MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit DP dual mode type 1 DVI adaptors aren't required to implement

[Intel-gfx] [PATCH v4] drm/i915: Move execlists irq handler to a bottom half

From: Tvrtko Ursulin Doing a lot of work in the interrupt handler introduces huge latencies to the system as a whole. Most dramatic effect can be seen by running an all engine stress test like igt/gem_exec_nop/all where, when the kernel config is lean enough, the whole

Re: [Intel-gfx] [PATCH] drm/i915/ddi: Silence compiler warning for unknown output type

On ma, 2016-04-04 at 10:00 +0100, Chris Wilson wrote: > On Mon, Apr 04, 2016 at 11:45:26AM +0300, Jani Nikula wrote: > > > > On Mon, 04 Apr 2016, Chris Wilson wrote: > > > > > > On Mon, Apr 04, 2016 at 09:20:27AM +0300, Joonas Lahtinen wrote: > > > > > > > > On su,

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

On 04/04/16 12:08, Jani Nikula wrote: On Mon, 04 Apr 2016, Tvrtko Ursulin wrote: On 01/04/16 08:41, Ander Conselvan De Oliveira wrote: On Thu, 2016-03-31 at 12:38 +, Patchwork wrote: == Series Details == Series: series starting with [1/5] drm/i915:

Re: [Intel-gfx] [PATCH] drm/i915/ddi: Silence compiler warning for unknown output type

On Mon, 04 Apr 2016, Chris Wilson wrote: > On Mon, Apr 04, 2016 at 09:20:27AM +0300, Joonas Lahtinen wrote: >> On su, 2016-04-03 at 21:59 +0100, Chris Wilson wrote: >> > Silences >> > >> >src/drivers/gpu/drm/i915/intel_ddi.c: warning: 'port' may be used >> >

Re: [Intel-gfx] [PATCH 06/16] drm/i915/gen9: Fix DMC/DC state asserts

On Fri, Apr 01, 2016 at 04:02:37PM +0300, Imre Deak wrote: > The display power well support and DC state management doesn't depend on > runtime PM support, so remove the incorrect asserts about this. > > Also Broxton does support DC5, so the related assert in > assert_can_enable_dc5() is

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

On Mon, 04 Apr 2016, Tvrtko Ursulin wrote: > On 01/04/16 08:41, Ander Conselvan De Oliveira wrote: >> On Thu, 2016-03-31 at 12:38 +, Patchwork wrote: >>> == Series Details == >>> >>> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect >>> URL

Re: [Intel-gfx] [PATCH 05/16] drm/i915/gen9: Make power well disabling synchronous

On Fri, Apr 01, 2016 at 04:02:36PM +0300, Imre Deak wrote: > So far we only power well enabling was synchronous not disabling. Since > we don't exactly know how the firmware (both DMC and PCU) synchronizes > against the actual power well state during DC transitions, make the > disabling also

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

On Friday 01 April 2016 01:11 PM, Ander Conselvan De Oliveira wrote: On Thu, 2016-03-31 at 12:38 +, Patchwork wrote: == Series Details == Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect URL : https://patchwork.freedesktop.org/series/5044/ State : success I

[Intel-gfx] [PATCH 10/12] drm/i915: Add lspcon core functions

This patch adds lspcon's internal functions, which work on the probe layer, and indicate the working status of lspcon, which are mostly: probe: A lspcon device is probed only once, during boot time, as its always present with the device, next to port. So the i2c_over_aux channel is alwyas

[Intel-gfx] [PATCH 11/12] drm/i915: Add lspcon hpd handler

This patch adds a new hpd handler for lspcon. As lspcon has its own way of reading EDID and detecting the device, it wont be efficient to use the existing hpd functions to handle the hot_plug scenarios. This new function reads the EDID and checks the status of the sink device. Signed-off-by:

[Intel-gfx] [PATCH 05/12] drm/i915: Add lspcon data structures

This patch adds lspcon structure in intel_dig_port. These strucres will be used to check runtime status of LSPCON device. Signed-off-by: Shashank Sharma Signed-off-by: Akashdeep Sharma --- drivers/gpu/drm/i915/intel_drv.h | 16

[Intel-gfx] [PATCH 07/12] drm/i915: Add and initialize lspcon connector

lspcon is a device which acts as DP in some cases and as HDMI in some. Here is how: - lspcon needs DP(aux) for all the i2c_ove_aux read/write transitions so it needs to have some DP level initializations - lspcon is detected by userspace/sink as HDMI device, so it needs to be detectd as HDMI

[Intel-gfx] [PATCH 09/12] drm/i915: Add and register lspcon connector functions

This patch adds various lspcon connector functions. Some of the functions are newly written, to meet the specific needs of lspcon HW, whereas few of them are just an abstraction layer on existing HDMI connector functions. Signed-off-by: Shashank Sharma ---

[Intel-gfx] [PATCH 08/12] drm: Add lspcon (custom type2 dp->hdmi) support

This patch adds support for LSPCON devices in dp++ adaptor helper layer. LSPCON is DP++ type-2 adaptor with some customized functionalities, to provide additional features in Intel Gen9 HW. LSPCON needs I2C-over-aux support to read/write control and data registers. This patch adds following: -

[Intel-gfx] [PATCH 12/12] DO_NOT_MERGE: drm/i915: Hack to enable lspcon initialization

This patch adds a hack to enable lspcon on GEN9 devices. This should not be merged, and the hack must be replaced by proper VBT parsing logic. Expecting this patch to enable lspcon bits in VBT: https://lists.freedesktop.org/archives/intel-gfx/2016-March/089541.html Signed-off-by: Shashank Sharma

[Intel-gfx] [PATCH 06/12] drm/i915: Add new lspcon file

This patch adds a new file for lspcon with some basic stuff like: - Some read/wrire addresses for lspcon device - Basic read/write functions, using i2c over aux channel - Utility functions to get lspcon/encoder/connector Signed-off-by: Shashank Sharma Signed-off-by:

[Intel-gfx] [PATCH v3 2/2] drm/i915: Make pages of GFX allocations movable

From: Chris Wilson On a long run of more than 2-3 days, physical memory tends to get fragmented severely, which considerably slows down the system. In such a scenario, Shrinker is also unable to help as lack of memory is not the actual problem, since it has been

Re: [Intel-gfx] [PATCH i-g-t 4/5] tests: fix spelling mistakes

On 03/04/16 17:35, Eric Engestrom wrote: Signed-off-by: Eric Engestrom --- tests/gem_concurrent_all.c | 2 +- tests/gem_cpu_reloc.c | 2 +- tests/gem_flink_race.c | 2 +- tests/gem_seqno_wrap.c | 2 +- tests/gem_tiled_wb.c | 2 +-

[Intel-gfx] [PATCH v2 2/3] mm/vmap: Add a notifier for when we run out of vmap address space

vmaps are temporary kernel mappings that may be of long duration. Reusing a vmap on an object is preferrable for a driver as the cost of setting up the vmap can otherwise dominate the operation on the object. However, the vmap address space is rather limited on 32bit systems and so we add a

[Intel-gfx] [PATCH v2 1/3] drm/i915/shrinker: Account for unshrinkable unbound pages

Since we only attempt to purge an object if can_release_pages() report true, we should also only add it to the count of potential recoverable pages when can_release_pages() is true. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Cc:

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix/enable display power well support/runtime PM (rev3)

== Series Details == Series: drm/i915/bxt: Fix/enable display power well support/runtime PM (rev3) URL : https://patchwork.freedesktop.org/series/5177/ State : failure == Summary == CC [M] drivers/net/ethernet/realtek/8139cp.o CC [M] drivers/net/ethernet/realtek/8139too.o LD

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Move execlists irq handler to a bottom half (rev4)

== Series Details == Series: drm/i915: Move execlists irq handler to a bottom half (rev4) URL : https://patchwork.freedesktop.org/series/4764/ State : failure == Summary == Series 4764v4 drm/i915: Move execlists irq handler to a bottom half

[Intel-gfx] [PATCH v2 08/16] drm/i915/skl: Unexport skl_pw1_misc_io_init

On Broxton we need to enable/disable power well 1 during the init/unit display sequence similarly to Skylake/Kabylake. The code for this will be added in a follow-up patch, but to prepare for that unexport skl_pw1_misc_io_init(). It's a simple function called only from a single place and having it

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] shmem: Support for registration of Driver/file owner specific ops (rev3)

== Series Details == Series: series starting with [1/2] shmem: Support for registration of Driver/file owner specific ops (rev3) URL : https://patchwork.freedesktop.org/series/4780/ State : failure == Summary == Series 4780v3 Series without cover letter

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Move execlists irq handler to a bottom half (rev4)

On 04/04/16 13:53, Chris Wilson wrote: On Mon, Apr 04, 2016 at 01:42:06PM +0100, Tvrtko Ursulin wrote: On 04/04/16 13:33, Patchwork wrote: == Series Details == Series: drm/i915: Move execlists irq handler to a bottom half (rev4) URL : https://patchwork.freedesktop.org/series/4764/ State

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/12] drm: Add helper for DP++ adaptors

== Series Details == Series: series starting with [01/12] drm: Add helper for DP++ adaptors URL : https://patchwork.freedesktop.org/series/5273/ State : failure == Summary == Series 5273v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/5273/revisions/1/mbox/ Test

[Intel-gfx] [PATCH v2 3/3] drm/i915/shrinker: Hook up vmap allocation failure notifier

If the core runs out of vmap address space, it will call a notifier in case any driver can reap some of its vmaps. As i915.ko is possibily holding onto vmap address space that could be recovered, hook into the notifier chain and try and reap objects holding onto vmaps. Signed-off-by: Chris Wilson

[Intel-gfx] vmap purge notifier for exhaustion of the vmalloc arena

Andrew has already acked this for merge through the DRM tree, but it still needs a review. vmalloc() is quite an extensively used interface so the key question is have we broken anything by adding a blocking notifier into the callchain (though we only block if gfp_t says we can). -Chris

Re: [Intel-gfx] [PATCH v2 08/16] drm/i915/skl: Unexport skl_pw1_misc_io_init

On ma, 2016-04-04 at 15:01 +0200, Patrik Jakobsson wrote: > On Mon, Apr 04, 2016 at 03:42:57PM +0300, Imre Deak wrote: > > On Broxton we need to enable/disable power well 1 during the > > init/unit display > > sequence similarly to Skylake/Kabylake. The code for this will be > > added in a > >

[Intel-gfx] [PATCH v3 14/16] drm/i915/bxt: Add HW state verification for DDI PHY and CDCLK

I caught a few errors in our current PHY/CDCLK programming by sanity checking the actual programmed state, so I thought it would be also useful for the future. In addition to verifying the state after programming it also verify it after exiting DC5, to make sure DMC restored/kept intact everything

Re: [Intel-gfx] [PATCH v4] drm/i915: Move execlists irq handler to a bottom half

On 04/04/16 12:27, Chris Wilson wrote: On Mon, Apr 04, 2016 at 12:11:56PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Doing a lot of work in the interrupt handler introduces huge latencies to the system as a whole. Most dramatic effect can be seen by running

Re: [Intel-gfx] System freeze apparently due to GPU memory exhaustion - why?

> That seems like a legit bug. If you can reproduce it with drm-intel- > nightly, could you please open a bug at freedesktop.org bugzilla? Just had this happen after running drm-intel-nightly for 18 days, so I have opened a bug here: https://bugs.freedesktop.org/show_bug.cgi?id=94814 > Have you

[Intel-gfx] [PATCH i-g-t] test/gem_mocs_settings: Testing MOCS register settings

The MOCS registers were added in Gen9 and define the caching policy. The registers are split into two sets. The first set controls the EDRAM policy and have a set for each engine, the second set controls the L3 policy. The two sets use the same index. The RCS registers and the L3CC registers are

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

Em Sex, 2016-04-01 às 17:45 +0300, Ville Syrjälä escreveu: > On Thu, Mar 31, 2016 at 10:06:37PM +, Zanoni, Paulo R wrote: > > > > Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com > > escreveu: > > > > > > From: Ville Syrjälä > > > > > > DP

Re: [Intel-gfx] [PATCH 08/16] drm/i915/skl: Unexport skl_pw1_misc_io_init

On Fri, Apr 01, 2016 at 04:02:39PM +0300, Imre Deak wrote: > On Broxton we need to enable/disable power well 1 during the init/unit display > sequence similarly to Skylake/Kabylake. The code for this will be added in a > follow-up patch, but to prepare for that unexport skl_pw1_misc_io_init().

Re: [Intel-gfx] [PATCH 08/16] drm/i915/skl: Unexport skl_pw1_misc_io_init

On ma, 2016-04-04 at 14:30 +0200, Patrik Jakobsson wrote: > On Fri, Apr 01, 2016 at 04:02:39PM +0300, Imre Deak wrote: > > On Broxton we need to enable/disable power well 1 during the > > init/unit display > > sequence similarly to Skylake/Kabylake. The code for this will be > > added in a > >

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Move execlists irq handler to a bottom half (rev4)

On Mon, Apr 04, 2016 at 01:42:06PM +0100, Tvrtko Ursulin wrote: > > > On 04/04/16 13:33, Patchwork wrote: > >== Series Details == > > > >Series: drm/i915: Move execlists irq handler to a bottom half (rev4) > >URL : https://patchwork.freedesktop.org/series/4764/ > >State : failure > > > >==

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Move execlists irq handler to a bottom half (rev4)

On 04/04/16 13:33, Patchwork wrote: == Series Details == Series: drm/i915: Move execlists irq handler to a bottom half (rev4) URL : https://patchwork.freedesktop.org/series/4764/ State : failure == Summary == Series 4764v4 drm/i915: Move execlists irq handler to a bottom half

Re: [Intel-gfx] System freeze apparently due to GPU memory exhaustion - why?

> > Have you tried running the I-G-T testing suite on your hardware? > > No I haven't - do I just install intel-gpu-tools and find some test > program to run? I cloned the git repo for this and tried to run the tests as best I could understand from the readme, but no luck:

[Intel-gfx] [PATCH v4 2/2] drm/i915: Make GPU pages movable

From: Akash Goel On a long run of more than 2-3 days, physical memory tends to get fragmented severely, which considerably slows down the system. In such a scenario, the shrinker is also unable to help as lack of memory is not the actual problem, since it has been observed

[Intel-gfx] [PATCH v4 1/2] shmem: Support for registration of driver/file owner specific ops

From: Akash Goel This provides support for the drivers or shmem file owners to register a set of callbacks, which can be invoked from the address space operations methods implemented by shmem. This allow the file owners to hook into the shmem address space operations to do

Re: [Intel-gfx] [PATCH v2 08/16] drm/i915/skl: Unexport skl_pw1_misc_io_init

On Mon, Apr 04, 2016 at 03:42:57PM +0300, Imre Deak wrote: > On Broxton we need to enable/disable power well 1 during the init/unit display > sequence similarly to Skylake/Kabylake. The code for this will be added in a > follow-up patch, but to prepare for that unexport skl_pw1_misc_io_init().

Re: [Intel-gfx] [PATCH i-g-t] test/gem_mocs_settings: Testing MOCS register settings

On Mon, Apr 04, 2016 at 02:43:08PM +0100, Peter Antoine wrote: > +static void run_test(int fd, unsigned mode) > +{ > + const int gen = intel_gen(intel_get_drm_devid(fd)); > + const struct intel_execution_engine *e; > + > + igt_require(gen >= 9); > + > + test_mocs_values(fd); > + >

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915/bxt: add bxt dsi gpio element support

On Fri, Mar 18, 2016 at 01:11:17PM +0200, Jani Nikula wrote: > Use a table similar to vlv to check for accepted gpio indexes. For now, > add all, but this list should be trimmed down. Use managed gpio request, > which will be automatically released when the driver is detached. > > Signed-off-by:

[Intel-gfx] [PATCH 3/3] drm/i915: Do not serialize forcewake acquire across domains

From: Tvrtko Ursulin On platforms with multiple forcewake domains it seems more efficient to request all desired ones and then to wait for acks to avoid needlessly serializing on each domain. Signed-off-by: Tvrtko Ursulin ---

[Intel-gfx] [PATCH 2/3] drm/i915: Simplify for_each_fw_domain iterators

From: Tvrtko Ursulin As the vast majority of users does not use the domain id variable, we can eliminate it from the iterator and also change the latter using the same principle as was recently done for for_each_engine. For a couple of callers which do need the domain

[Intel-gfx] [PATCH 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

From: Tvrtko Ursulin Current implementation releases the forcewake at any time between straight away, and one jiffie from the last put, or first automatic grab. This does not sound like what was desired since jiffies are typically between 1 and 10ms depending on the

Re: [Intel-gfx] [PATCH v2 3/9] drm/i915/dsi: clean up vlv gpio table and definitions

On Fri, Mar 18, 2016 at 01:11:11PM +0200, Jani Nikula wrote: > Define and store the pad base offset in the array, and reference the > pconf0 and padval registers through macros. Add VLV prefixes to > macros. Use spec nomenclature for pconf0 and padval. > > v2: Address Ville's review comments,

Re: [Intel-gfx] [PATCH v2 4/9] drm/i915/dsi: add gpio indexes to the gpio table

On Fri, Mar 18, 2016 at 01:11:12PM +0200, Jani Nikula wrote: > This lets us specify the exact gpios we want to let through, without > leaving holes in the array. > > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 54 >

[Intel-gfx] [PATCH v2] drm/i915/Gen9+: optional IPC enablement

With IPC(Isochronous Priority Control) enabled, display sends requests based on the priority of each request. To enable it, a i915 param, i915.enable_ipc should be set to 1. v2: corrected matched type of enable_ipc in module_param_named_unsafe macro Signed-off-by: Dongwon Kim

Re: [Intel-gfx] [PATCH v5 32/46] pwm: deprecate pwm_config(), pwm_enable() and pwm_disable()

On Thu, Mar 31, 2016 at 08:54:54PM +0200, Boris Brezillon wrote: > Hi Dmitry, > > On Thu, 31 Mar 2016 10:38:58 -0700 > Dmitry Torokhov wrote: > > > Hi Boris, > > > > On Wed, Mar 30, 2016 at 10:03:55PM +0200, Boris Brezillon wrote: > > > Prefix those function as

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915/shrinker: Account for unshrinkable unbound pages

== Series Details == Series: series starting with [v2,1/3] drm/i915/shrinker: Account for unshrinkable unbound pages URL : https://patchwork.freedesktop.org/series/5276/ State : success == Summary == Series 5276v1 Series without cover letter

Re: [Intel-gfx] [PATCH v5 34/46] clk: pwm: switch to the atomic API

On Thu, Mar 31, 2016 at 08:57:35AM +0200, Boris Brezillon wrote: > Hi Stephen, > > On Wed, 30 Mar 2016 15:01:49 -0700 > Stephen Boyd wrote: > > > On 03/30, Boris Brezillon wrote: > > > diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c > > > index ebcd738..49ec5b1

Re: [Intel-gfx] [PATCH v2 2/9] drm/i915/dsi: add support for DSI sequence block v2 gpio element

On Fri, Mar 18, 2016 at 01:11:10PM +0200, Jani Nikula wrote: > In sequence block v2, and only in v2, the gpio source (i.e. IOSF port) > is specified separately. > > v2: initialize gpio_source to 0 and handle v1 and v2 in the same branch > > Signed-off-by: Jani Nikula

Re: [Intel-gfx] [PATCH v2 7/9] drm/i915/chv: add more IOSF port definitions

On Fri, Mar 18, 2016 at 01:11:15PM +0200, Jani Nikula wrote: > Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/i915_reg.h | 4 > 1 file changed, 4 insertions(+) > > diff --git

[Intel-gfx] [PATCH v4 2/3] drm/i915/guc: always reset GuC before loading firmware

After a suspend-resume cycle, the resumed kernel has no idea what the booted kernel may have done to the GuC before replacing itself with the resumed image. In particular, it may have already loaded the GuC with firmware, which will then cause this kernel's attempt to (re)load the firmware to fail

[Intel-gfx] [PATCH v4 0/3] GuC reset-and-retry patches (resend)

This is a resend, primarily for CI purposes. All patches to be merged have already been reviewed. The final patch (NOT to be merged) enables GuC loading and submission for testing purposes. Arun Siluvery (1): drm/i915/guc: reset GuC and retry on firmware load failure Dave Gordon (2):

[Intel-gfx] [PATCH v4 3/3] DO NOT MERGE: add enable_guc_loading parameter

Split the function of "enable_guc_submission" into two separate options. The new one "enable_guc_loading" controls only the *fetching and loading* of the GuC firmware image. The existing one is redefined to control only the *use* of the GuC for batch submission once the firmware is loaded. In

Re: [Intel-gfx] [PATCH i-g-t] test/gem_mocs_settings: Testing MOCS register settings

Response inline. On Mon, 4 Apr 2016, Chris Wilson wrote: On Mon, Apr 04, 2016 at 02:43:08PM +0100, Peter Antoine wrote: +static void run_test(int fd, unsigned mode) +{ + const int gen = intel_gen(intel_get_drm_devid(fd)); + const struct intel_execution_engine *e; + +

[Intel-gfx] [PATCH v4 1/3] drm/i915/guc: reset GuC and retry on firmware load failure

From: Arun Siluvery Due to timing issues in the HW, some of the status bits required for GuC authentication occasionally don't get set; when that happens, the GuC cannot be initialized and we will be left with a wedged GPU. The W/A suggested is to perform a soft

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_kms: Fix atomic plane commit when fb_id is 0.

On Mon, Apr 04, 2016 at 06:47:25PM +0300, Marius Vlad wrote: > igt_atomic_prepare_plane_commit() assumes that the framebuffer is always > set-up. > > Signed-off-by: Marius Vlad > --- > lib/igt_kms.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/2] shmem: Support for registration of driver/file owner specific ops

== Series Details == Series: series starting with [v4,1/2] shmem: Support for registration of driver/file owner specific ops URL : https://patchwork.freedesktop.org/series/5274/ State : failure == Summary == Series 5274v1 Series without cover letter

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix/enable display power well support/runtime PM (rev4)

== Series Details == Series: drm/i915/bxt: Fix/enable display power well support/runtime PM (rev4) URL : https://patchwork.freedesktop.org/series/5177/ State : failure == Summary == Series 5177v4 drm/i915/bxt: Fix/enable display power well support/runtime PM

Re: [Intel-gfx] [PATCH v5 36/46] input: misc: max77693: switch to the atomic API

On Thu, Mar 31, 2016 at 08:57:18PM +0200, Boris Brezillon wrote: > On Thu, 31 Mar 2016 10:48:01 -0700 > Dmitry Torokhov wrote: > > > Hi Boris, > > > > On Wed, Mar 30, 2016 at 10:03:59PM +0200, Boris Brezillon wrote: > > > pwm_config/enable/disable() have been

[Intel-gfx] [PATCH i-g-t] lib/igt_kms: Fix atomic plane commit when fb_id is 0.

igt_atomic_prepare_plane_commit() assumes that the framebuffer is always set-up. Signed-off-by: Marius Vlad --- lib/igt_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 82257a6..30c5b7e 100644 ---

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_kms: Fix atomic plane commit when fb_id is 0.

Hi Marius, Thanks for this. I have the same patch on a branch I haven't send yet (oops). In my patch I implemented this by setting src_* to 0 if fb_id == 0. I'm not sure what makes more sense but anyway : Reviewed-by: Lionel Landwerlin On 04/04/16 16:47,

Re: [Intel-gfx] [PATCH v5 08/46] hwmon: pwm-fan: use pwm_get_args() where appropriate

On Thu, Mar 31, 2016 at 09:07:09AM +0200, Boris Brezillon wrote: > Hi Guenter, > > On Wed, 30 Mar 2016 15:52:44 -0700 > Guenter Roeck wrote: > > > On Wed, Mar 30, 2016 at 10:03:31PM +0200, Boris Brezillon wrote: > > > The PWM framework has clarified the concept of reference

Re: [Intel-gfx] [PATCH 2/2] drm/i915/BXT: Tolerance at BXT DSI pipe_config comparison

On Thursday 31 March 2016 12:34 AM, Daniel Vetter wrote: On Wed, Mar 30, 2016 at 07:49:40PM +0530, Ramalingam C wrote: On Wednesday 30 March 2016 05:02 PM, Daniel Vetter wrote: On Tue, Mar 29, 2016 at 11:04:51PM +0530, Ramalingam C wrote: At BXT DSI, PIPE registers are inactive. So we can't

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Do not serialize forcewake acquire across domains

On Mon, Apr 04, 2016 at 05:51:11PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > On platforms with multiple forcewake domains it seems more efficient > to request all desired ones and then to wait for acks to avoid > needlessly serializing on each domain. Not

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Simplify for_each_fw_domain iterators

On 04/04/16 17:51, Tvrtko Ursulin wrote: From: Tvrtko Ursulin As the vast majority of users does not use the domain id variable, "do not use" we can eliminate it from the iterator and also change the latter using the same principle as was recently done for

Re: [Intel-gfx] [PATCH i-g-t] test/gem_mocs_settings: Testing MOCS register settings

On Mon, Apr 04, 2016 at 06:30:21PM +0100, Peter Antoine wrote: > >As well as checking for creating new contexts after resume, we also need > >to check that the register values are preserved across suspend (i.e. > >that the register state is being saved back into the context image and > >then

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

On 04/04/16 19:58, Chris Wilson wrote: On Mon, Apr 04, 2016 at 05:51:09PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Current implementation releases the forcewake at any time between straight away, and one jiffie from the last put, or first automatic grab.

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

On 04/04/16 17:51, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Current implementation releases the forcewake at any time between straight away, and one jiffie from the last put, or first automatic grab. This does not sound like what was desired since jiffies are

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

On Mon, Apr 04, 2016 at 05:51:09PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Current implementation releases the forcewake at any time between > straight away, and one jiffie from the last put, or first automatic > grab. That isn't the problem though. The

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Simplify for_each_fw_domain iterators

On Mon, Apr 04, 2016 at 05:51:10PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > As the vast majority of users does not use the domain id variable, > we can eliminate it from the iterator and also change the latter > using the same principle as was recently

Re: [Intel-gfx] [PATCH v2 8/9] drm/i915/dsi: add support for gpio elements on CHV

On Fri, Mar 18, 2016 at 01:11:16PM +0200, Jani Nikula wrote: > From: Yogesh Mohan Marimuthu > > Add support for CHV gpio programming in DSI gpio elements. > > XXX: I'd like to have a gpio table for chv as well as others. > > [Rewritten by Jani, based on

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

On Mon, Apr 04, 2016 at 08:41:20PM +0100, Dave Gordon wrote: > On 04/04/16 19:58, Chris Wilson wrote: > >On Mon, Apr 04, 2016 at 05:51:09PM +0100, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>Current implementation releases the forcewake at any time between >

Re: [Intel-gfx] [PATCH] drm/i915/ddi: Silence compiler warning for unknown output type

On su, 2016-04-03 at 21:59 +0100, Chris Wilson wrote: > Silences > > src/drivers/gpu/drm/i915/intel_ddi.c: warning: 'port' may be used > uninitialized in this function [-Wuninitialized] > > Reported-by: Geert Uytterhoeven > Signed-off-by: Chris Wilson

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/userptr: Flush cancellations before mmu-notifier invalidate returns

== Series Details == Series: series starting with [1/3] drm/i915/userptr: Flush cancellations before mmu-notifier invalidate returns URL : https://patchwork.freedesktop.org/series/5240/ State : success == Summary == Series 5240v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ddi: Silence compiler warning for unknown output type

== Series Details == Series: drm/i915/ddi: Silence compiler warning for unknown output type URL : https://patchwork.freedesktop.org/series/5247/ State : success == Summary == Series 5247v1 drm/i915/ddi: Silence compiler warning for unknown output type

Re: [Intel-gfx] [PATCH] drm/i915/ddi: Silence compiler warning for unknown output type

On Mon, Apr 04, 2016 at 09:20:27AM +0300, Joonas Lahtinen wrote: > On su, 2016-04-03 at 21:59 +0100, Chris Wilson wrote: > > Silences > > > > src/drivers/gpu/drm/i915/intel_ddi.c: warning: 'port' may be used > > uninitialized in this function [-Wuninitialized] > > > > Reported-by: Geert

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Set ctx->ppgtt to aliasing PPGTT if full PPGTT mode isn't enabled

== Series Details == Series: drm/i915: Set ctx->ppgtt to aliasing PPGTT if full PPGTT mode isn't enabled URL : https://patchwork.freedesktop.org/series/5261/ State : failure == Summary == Series 5261v1 drm/i915: Set ctx->ppgtt to aliasing PPGTT if full PPGTT mode isn't enabled

[Intel-gfx] [PATCH i-g-t 3/5] lib: fix spelling mistakes

Signed-off-by: Eric Engestrom --- lib/gpgpu_fill.c | 4 ++-- lib/igt_aux.h| 2 +- lib/igt_core.c | 6 +++--- lib/igt_core.h | 4 ++-- lib/intel_reg.h | 2 +- lib/ioctl_wrappers.c | 2 +- lib/media_fill_gen8.c| 2 +-

[Intel-gfx] [PATCH i-g-t 1/5] README: fix spelling mistakes

Signed-off-by: Eric Engestrom --- README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README b/README index d302af3..cfb6ab2 100644 --- a/README +++ b/README @@ -29,7 +29,7 @@ tests/ changes. Many of the tests have subtests, which can be listed

[Intel-gfx] Status of 30-bit color depth support for Intel Graphics on Linux

Hi, referring to the recent exchange here: http://www.spinics.net/lists/intel-gfx/msg91010.html the response only mentions correct gamma ramp support, but it looks to me as if there is much more missing than in existence when it comes to 30-bit color depth support in Linux using Intel Graphics.

[Intel-gfx] [PATCH i-g-t 5/5] tools: fix spelling mistakes

Signed-off-by: Eric Engestrom --- tools/intel_audio_dump.c | 14 +++--- tools/intel_bios.h| 6 +++--- tools/intel_display_poller.c | 2 +- tools/intel_dump_decode.c | 2 +-

[Intel-gfx] [PATCH 1/4] drm/i915/fbc: update busy_bits even for GTT and flip flushes

We ignore ORIGIN_GTT because the hardware tracking can recognize GTT writes and take care of them. We also ignore ORIGIN_FLIP because we deal with flips without relying on the frontbuffer tracking infrastructure. On the other hand, a flush is a flush and means we're good to go, so we need to

  1   2   >