[Intel-gfx] [PATCH v3 17/17] drm/i915: Split out load time interface registration

According to the new init phases scheme we should register the device making it available via some kernel internal or user space interface as the last step in the init sequence, so move the corresponding code to a separate function. Also add a TODO comment about code that still needs to be moved

Re: [Intel-gfx] [PATCH v1 00/12] PCI: Rework shadow ROM handling

On Tue, Mar 8, 2016 at 9:45 AM, Bjorn Helgaas wrote: > On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote: >> The purpose of this series is to: >> >> - Fix the "BAR 6: [??? 0x flags 0x2] has bogus alignment" >> messages reported by Linus [1], Andy [2],

Re: [Intel-gfx] [PATCH v2 17/17] drm/i915: Split out load time interface registration

On Fri, 2016-03-11 at 20:38 +, Chris Wilson wrote: > On Fri, Mar 11, 2016 at 10:11:20PM +0200, Imre Deak wrote: > > On Fri, 2016-03-11 at 19:55 +, Chris Wilson wrote: > > > On Fri, Mar 11, 2016 at 06:31:42PM +0200, Imre Deak wrote: > > > > According to the new init phases scheme we should

Re: [Intel-gfx] [PATCH v3] drm/i915/mocs: Program MOCS for all engines on init

On Fri, Mar 11, 2016 at 02:00:22PM +, Peter Antoine wrote: > Allow for the MOCS to be programmed for all engines. > Currently we program the MOCS when the first render batch > goes through. This works on most platforms but fails on > platforms that do not run a render batch early, > i.e.

[Intel-gfx] [PATCH igt] drv_module_reload_basic: Add inject-fault option

Add an option to insert the module with fault injection enabled. Requested by Chris. CC: Chris Wilson Signed-off-by: Imre Deak --- tests/drv_module_reload_basic | 28 +++- 1 file changed, 27 insertions(+), 1 deletion(-)

Re: [Intel-gfx] [PATCH v1 00/12] PCI: Rework shadow ROM handling

On Fri, Mar 11, 2016 at 01:16:09PM -0800, Andy Lutomirski wrote: > On Tue, Mar 8, 2016 at 9:45 AM, Bjorn Helgaas wrote: > > On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote: > >> The purpose of this series is to: > >> > >> - Fix the "BAR 6: [??? 0x flags

Re: [Intel-gfx] [PATCH v2 17/17] drm/i915: Split out load time interface registration

On Fri, Mar 11, 2016 at 10:11:20PM +0200, Imre Deak wrote: > On Fri, 2016-03-11 at 19:55 +, Chris Wilson wrote: > > On Fri, Mar 11, 2016 at 06:31:42PM +0200, Imre Deak wrote: > > > According to the new init phases scheme we should register the > > > device > > > making it available via some

[Intel-gfx] [PATCH v3] drm/i915: Move load time init of clock gating hooks earlier

Split out the part initing the clock gating hooks and move it earlier. Add a new NOP hook for platforms without the need to apply clockgating or workaround settings, so that the hook can be called unconditionally. Also add a WARN for future platforms that forget to add a hook. The rest of the

[Intel-gfx] [PATCH] drm/i915: Add fault injection support

Add support for forcing an error at selected places in the driver. As an example add 3 options to fail during driver loading. Requested by Chris. CC: Chris Wilson Signed-off-by: Imre Deak --- [This depends on

[Intel-gfx] [PATCH] drm/i915: Fixup the free space logic in ring_prepare

From: Akash Goel Currently for the case where there is enough space at the end of Ring buffer for accommodating only the base request, the wrapround is done immediately and as a result the base request gets added at the start of Ring buffer. But there may not be enough free

[Intel-gfx] [PATCH] lib/igt_kms: Add COMMIT_ATOMIC to igt_display_commit2()

Co-Author : Marius Vlad Co-Author : Pratik Vishwakarma So far we have had only two commit styles, COMMIT_LEGACY and COMMIT_UNIVERSAL. This patch adds another commit style COMMIT_ATOMIC which makes use of drmModeAtomicCommit() v2: (Marius)

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for intel_engine_cs renaming bomb (rev3)

On 11/03/2016 09:49, Tvrtko Ursulin wrote: On 10/03/16 16:30, Patchwork wrote: == Series Details == Series: intel_engine_cs renaming bomb (rev3) URL : https://patchwork.freedesktop.org/series/4303/ State : warning == Summary == Series 4303v3 intel_engine_cs renaming bomb

Re: [Intel-gfx] [RFC/PATCH xf86-video-intel] sna: Let modestting + glamor handle gen9+

29.02.2016, 16:47, Hans de Goede kirjoitti: > sna has no meaningfull accel for gen9+, this causes problems with i.e. > apps using XVideo since the sprite XVideo support does not work well > for many apps. > > Therefor it is better to just let the xserver fall back to modesetting + > glamor. This

Re: [Intel-gfx] [PATCH v2] drm/i915: Restrict usage of live status check

On Thu, 10 Mar 2016, Shashank Sharma wrote: > This patch does the following: > - Restricts usage of live status check for HDMI detection. > While testing certain (monitor + cable) combinations with > various intel platforms, it seems that live status register >

[Intel-gfx] i915 on Xeon E3-1275 v5

Hi guys, I spent some time trying to figure out what's wrong with my shiny new system and it turned out that it is a problem somewhere between v4.5-rc[67] and DP 1.2 on Skylake. With DP 1.2 enabled 'xrandr' reports half of the real monitor's (Dell UP2414Q) resolution, IOW 1920x2160.

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2,i915] add module param "force_dp_sst"

Hi, The series seems to be against rather old source tree. Please do rebase all patches against drm-intel-nightly prior to submitting. Regards, Joonas On pe, 2016-03-11 at 07:40 +, Patchwork wrote: > == Series Details == > > Series: series starting with [1/2,i915] add module param

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fixup the free space logic in ring_prepare

== Series Details == Series: drm/i915: Fixup the free space logic in ring_prepare URL : https://patchwork.freedesktop.org/series/4346/ State : failure == Summary == Series 4346v1 drm/i915: Fixup the free space logic in ring_prepare

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for intel_engine_cs renaming bomb (rev3)

On 10/03/16 16:30, Patchwork wrote: == Series Details == Series: intel_engine_cs renaming bomb (rev3) URL : https://patchwork.freedesktop.org/series/4303/ State : warning == Summary == Series 4303v3 intel_engine_cs renaming bomb

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Get the i2c bus number from the ACPI

== Series Details == Series: series starting with [1/2] drm/i915: Get the i2c bus number from the ACPI URL : https://patchwork.freedesktop.org/series/4348/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/intel_dp_link_training.o CC [M] drivers/gpu/drm/i915/intel_dp_mst.o CC

Re: [Intel-gfx] [PATCH] drm/i915: Fixup the free space logic in ring_prepare

On Fri, Mar 11, 2016 at 02:56:42PM +0530, akash.g...@intel.com wrote: > From: Akash Goel > > Currently for the case where there is enough space at the end of Ring > buffer for accommodating only the base request, the wrapround is done > immediately and as a result the base

[Intel-gfx] [PATCH 2/2] drm/i915: Adding the parsing logic for the i2c element

From: vkorjani New sequence element for i2c is been added in the mipi sequence block of the VBT. This patch parses and executes the i2c sequence. v2: Add i2c_put_adapter call(Jani), rebase v3: corrected the retry loop(Jani), rebase v4 by Jani: - don't put the adapter

[Intel-gfx] [PATCH 1/2] drm/i915: Get the i2c bus number from the ACPI

Currently for executing the i2c MIPI sequence, we are relaying on the i2c bus bunmber which is specified in the VBT. But there are cases where different Fab versions of the board will drive the same chip with different i2c port, in which case the i2c bus number from the VBT cant be relied on. To

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Restrict usage of live status check

Right now live status check is helping in many scenarios, including: - HDMI compliance - HDMI connector status to be shown to user space - While running HDCP compliance, we pass a train of hot-plugs/unplugs via analyzers, and without live status check and HDMI optimization patches, our software

Re: [Intel-gfx] [PATCH v1 00/12] PCI: Rework shadow ROM handling

On Fri, Mar 11, 2016 at 8:09 PM, Linus Torvalds wrote: > On Fri, Mar 11, 2016 at 4:49 PM, Andy Lutomirski wrote: >> >> FWIW, if I disable all the checks in pci_get_rom_size, I learn that my >> video ROM consists entirely of 0xff bytes. Maybe

Re: [Intel-gfx] [PATCH v1 00/12] PCI: Rework shadow ROM handling

On Fri, Mar 11, 2016 at 3:29 PM, Bjorn Helgaas wrote: > On Fri, Mar 11, 2016 at 01:16:09PM -0800, Andy Lutomirski wrote: >> On Tue, Mar 8, 2016 at 9:45 AM, Bjorn Helgaas wrote: >> > On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote: >> >> The

Re: [Intel-gfx] [PATCH v1 00/12] PCI: Rework shadow ROM handling

On Fri, Mar 11, 2016 at 4:49 PM, Andy Lutomirski wrote: > > FWIW, if I disable all the checks in pci_get_rom_size, I learn that my > video ROM consists entirely of 0xff bytes. Maybe there just isn't a > ROM shadow on my laptop. I think most laptops end up having the

Re: [Intel-gfx] Possible 4.5 i915 Skylake regression

On Mon, Feb 22, 2016 at 7:13 PM, Andy Lutomirski wrote: > On Wed, Feb 17, 2016 at 5:36 PM, Andy Lutomirski wrote: >> On Wed, Feb 17, 2016 at 8:18 AM, Daniel Vetter wrote: >>> On Tue, Feb 16, 2016 at 09:26:35AM -0800, Andy Lutomirski

[Intel-gfx] [PATCH] drm: atomic helper: do not unreference error pointer

562c5b4d8986 didn't quite fix the issue of dealing with an error pointer. We can't free/unref an error pointer so reset it to NULL. Many thanks to Dan Carpenter for pointing this out again. Signed-off-by: Lionel Landwerlin Cc: Dan Carpenter

Re: [Intel-gfx] [RFCv3 10/15] drm/i915: update PDPs by condition when submit the LRC context

OK. I will see. :) Thanks for the comments. -Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Friday, March 11, 2016 7:28 PM To: Wang, Zhi A Cc: intel-gfx@lists.freedesktop.org; igv...@lists.01.org; Tian, Kevin; Lv, Zhiyuan; Niu, Bing; Song, Jike;

Re: [Intel-gfx] [PATCH 1/2] [i915] add module param "force_dp_sst"

On Fri, 11 Mar 2016, Nathan Schulte wrote: > Adds an (unsafe; auto-kernel-tainting) boolean module parameter to the i915 > drm driver: "force_dp_sst", which is disabled by default. Enabling the > parameter forces newly connected DisplayPort sinks to report as not >

Re: [Intel-gfx] [PATCH 0/7] drm/i915: Move some load time init steps earlier

On Wed, 09 Mar 2016, Chris Wilson wrote: > On Wed, Mar 09, 2016 at 05:31:39PM +0200, Imre Deak wrote: >> While working on the CDCLK init code I realized that the driver load time >> dependencies between the different init steps are rather difficult to follow >> and so

[Intel-gfx] [RFCv3 15/15] drm/i915: expose i915_find_fence_reg()

Expose i915_find_fence_reg() for GVT-g to allocate the fence registers for vGPUs. Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem_fence.c | 10 +- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git

[Intel-gfx] [RFCv3 03/15] drm/i915: Introduce host graphics memory partition for GVT-g

From: Bing Niu This patch introduces host graphics memory partition when GVT-g is enabled. Under GVT-g, i915 host driver only owned limited graphics resources, others are managed by GVT-g resource allocator and kept for other vGPUs. v3: - Remove fence partition, will use

[Intel-gfx] [RFCv3 06/15] drm/i915: let __i915_gem_context_create() takes context creation params

Let the core logic of context creation service creates the GEM context by context creation params. Now it provides following options for context creation: - Need to create legacy context for this GEM context? - Need to create PPGTT instance for this GEM context? - Need to treat this context as

Re: [Intel-gfx] [RFCv3 14/15] drm/i915: factor out and expose i915_steal_fence()

On Fri, Mar 11, 2016 at 06:59:45PM +0800, Zhi Wang wrote: > Factor out and expose fence stealing functionality for GVT-g. GVT-g > will use i915_find_fence_reg() to find a free/unpin fence register > and use i915_steal_fence() to steal it. > > Signed-off-by: Zhi Wang > --- >

Re: [Intel-gfx] [RFCv3 14/15] drm/i915: factor out and expose i915_steal_fence()

Hi Chris: Do you mean I should also check the fence pin count in this API like i915_find_fence_reg, then it will be safe here? :) -Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Friday, March 11, 2016 7:22 PM To: Wang, Zhi A Cc:

[Intel-gfx] [PATCH 2/2] drm/i915: Set invert bit for hpd based on VBT

This patch sets the invert bit for hpd detection for each port based on VBT configuration. Since each AOB can be designed to depend on invert bit or not, it is expected if an AOB requires invert bit, the user will set respective bit in VBT. v2: Separated VBT parsing from the rest of the logic.

[Intel-gfx] [PATCH 1/2] drm/i915: Update VBT fields for child devices

This patch adds new fields that are not yet added in drm code in child devices struct Signed-off-by: Sivakumar Thulasimani Signed-off-by: Durgadoss R Signed-off-by: Shubhangi Shrivastava ---

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

At BXT DSI, PIPE registers are inactive. So we can get the PIPE's mode parameters from them. The possible option is retriving them from the PORT registers. But mode timing parameters are progammed to port registers interms of byteclocks. The formula used to convert the pixels interms of byteclk

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Set invert bit for hpd based on VBT

Hi Shubhangi, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160311] [cannot apply to v4.5-rc7] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Shubhangi

[Intel-gfx] [PATCH 2/2] drm/i915: Set invert bit for hpd based on VBT

This patch sets the invert bit for hpd detection for each port based on VBT configuration. Since each AOB can be designed to depend on invert bit or not, it is expected if an AOB requires invert bit, the user will set respective bit in VBT. v2: Separated VBT parsing from the rest of the logic.

[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave - I first thought I'd missed the train, and by now maybe I really have. *sigh*. Both need to be backported to v4.5 through stable if these miss the release. BR, Jani. The following changes since commit f6cede5b49e822ebc41a099fe41ab4989f64e2cb: Linux 4.5-rc7 (2016-03-06 14:48:03

[Intel-gfx] External output completely broken on Skylake (hard freeze)?

Hi, My laptop seem to work ok with the internal display (though I haven't used it extensively yet). When I connect an external monitor it's being recognized and show up in xrandr, but I get severe "animated" distortion on the _internal_ panel. Sometimes the distortion doesn't happen until i move

[Intel-gfx] [RFCv3 11/15] drm/i915: Introduce execlist context status change notification

This patch introduces an approach to track the execlist context status change. GVT-g uses GVT context as the "shadow context". The content inside GVT context will be copied back to guest after the context is idle. So GVT-g has to know the status of the execlist context. This function is

[Intel-gfx] [RFCv3 02/15] drm/i915/gvt: Introduce the basic architecture of GVT-g

This patch introduces the very basic framework of GVT-g device model, includes basic prototypes, definitions, initialization. v3: Take Joonas' comments: - Change file name i915_gvt.* to intel_gvt.* - Move GVT kernel parameter into intel_gvt.c - Remove redundant debug macros - Change error

[Intel-gfx] [RFCv3 04/15] drm/i915: factor out alloc_context_idr() and __i915_gem_create_context()

For flexible GEM context creation, we factor out __i915_gem_create_context as the core logic of creation a GEM context. After the refactor, it more likes a context creation service, which is able to create context by explicit requirement of upper level components. For the assumptions in original

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Reset GuC and retry on firmware load failure

On 10/03/2016 17:57, Yu Dai wrote: LGTM. Reviewed-by: Alex Dai thanks for the review. This patch is dependent on patch1 which is being reworked. I will rebase send this to the list again once all dependencies are resolved. regards Arun On 03/08/2016 03:38 AM, Arun

[Intel-gfx] [RFCv3 05/15] drm/i915: factor out __create_legacy_hw_context()

As creating the legacy HW context has become into an option in GEM context creating service and will only be used in legacy ring buffer mode, we factor out __create_legacy_hw_context() from __create_hw_context() for better code structure. Signed-off-by: Zhi Wang ---

[Intel-gfx] [RFCv3 13/15] drm/i915: Introduce GVT context creation API

GVT workload scheduler needs special host LRC contexts, the so called "shadow LRC context" to submit guest workload to host i915. During the guest workload submission, GVT fills the shadow LRC context with the content of guest LRC context: engine context is copied without changes, ring context is

[Intel-gfx] [RFCv3 01/15] drm/i915: factor out i915_pvinfo.h

As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g host (GVT-g kernel device model), factor it out for better code structure. v3: Take Joonas's comments: - Use offsetof to calculate the member offset of PVINFO structure Signed-off-by: Zhi Wang ---

[Intel-gfx] [RFCv3 12/15] drm/i915: Support context single submission

This patch introduces the support of context signle submission. As GVT context may come from different guests, which requires different configuration of render registers. It can't be combined in a dual ELSP submission combo. We make this function as a context feature in context creation service.

[Intel-gfx] [RFCv3 07/15] drm/i915: factor out __intel_lr_context_deferred_alloc()

For flexible LRC context creation, we factor out the core logic of LRC context creation as __intel_lr_context_deferred_alloc(). For the hard-coded LRC context configurations, we keep them in the upper-level function intel_lr_context_deferred_alloc(). Signed-off-by: Zhi Wang

[Intel-gfx] [RFCv3 14/15] drm/i915: factor out and expose i915_steal_fence()

Factor out and expose fence stealing functionality for GVT-g. GVT-g will use i915_find_fence_reg() to find a free/unpin fence register and use i915_steal_fence() to steal it. Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915/i915_drv.h | 1 +

[Intel-gfx] [RFCv3 08/15] drm/i915: Support per-PPGTT address space mode

Previously the address space mode of each PPGTT instance is hard-coded to host system configuration, e.g. if the host system is configured to use 48bit full PPGTT, then address space mode of all PPGTT instances is 48bit. Per Daniel and Kevin's advice, GVT-g will leverage i915 PPGTT interface to

[Intel-gfx] [RFCv3 00/15] Introduce GVT context support

This patchset is used to discuss and finalize the i915 changes required by GVT context. Thanks Joonas/Daniel/Kevin for the comments. v3: - Address comments from Joonas/Kevin. - Add more introductions for better review. - Factor out and expose some functions in i915_gem_fence.c for fence

[Intel-gfx] [RFCv3 10/15] drm/i915: update PDPs by condition when submit the LRC context

Previously the PDPs inside the ring context will be updated - When populating a LRC context - Before submitting a LRC context (only for 32 bit PPGTT, as the amount of used PDPs may be changed during PPGTT page table grow) Under GVT-g, each VM owns a GVT context used as the shadow context. When

[Intel-gfx] [RFCv3 09/15] drm/i915: generate address mode bit from PPGTT instance

After the per-PPGTT address mode gets support, the LRC submission should generate the address mode bit from PPGTT instance, instead of the hard-coded system configuration. Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915/intel_lrc.c | 6 +++--- 1 file changed, 3

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Support to enable TRTT on GEN9 (rev6)

== Series Details == Series: drm/i915: Support to enable TRTT on GEN9 (rev6) URL : https://patchwork.freedesktop.org/series/2321/ State : failure == Summary == CC [M] drivers/net/ethernet/intel/igb/e1000_mac.o CC [M] drivers/net/ethernet/intel/e1000e/mac.o CC [M]

[Intel-gfx] [PATCH i-g-t 3/6] lib: fb: add igt_paint_color_gradient_range

This is a helper to draw a gradient between 2 colors. Signed-off-by: Lionel Landwerlin --- lib/igt_fb.c | 34 ++ lib/igt_fb.h | 3 +++ 2 files changed, 37 insertions(+) diff --git a/lib/igt_fb.c b/lib/igt_fb.c index

[Intel-gfx] [PATCH i-g-t 0/6] New pipe level color management tests

Hi, This series enables testing pipe level color management using kernel patches from this serie : https://patchwork.freedesktop.org/series/2720/ Most of the tests use pipe CRCs to check the results by comparing the output with the expected output drawn using cairo. Cheers, Lionel Lionel

[Intel-gfx] [PATCH i-g-t 1/6] lib: kms: add crtc_id to igt_pipe_t

Signed-off-by: Lionel Landwerlin --- lib/igt_kms.c | 1 + lib/igt_kms.h | 1 + 2 files changed, 2 insertions(+) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 9f18aef..e47a76e 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -1095,6 +1095,7 @@ void

[Intel-gfx] [PATCH i-g-t 6/6] test/kms_pipe_color: add test to verify legacy ioctl resets GAMMA_LUT

The GAMMA_LUT/DEGAMMA_LUT/CTM properties must be updated when the legacy ioctl is triggered to ensure the new properties do not impact older userspace code. v2: Add checks verifying the content of CTM & DEGAMMA_LUT properties Signed-off-by: Lionel Landwerlin

[Intel-gfx] [PATCH i-g-t 5/6] tests/kms_color: New test for pipe level color management

This test enables testing of : * degamma LUTs * csc matrix * gamma LUTs * legacy gamma LUTs v2: turn assert into require to skip on platform not supporting color management v3: add invalid blob ids tests v4: Try to match CRC results against several values around the

[Intel-gfx] [PATCH i-g-t 4/6] lib: add crc comparison function without an assert

Signed-off-by: Lionel Landwerlin --- lib/igt_debugfs.c | 17 + lib/igt_debugfs.h | 1 + 2 files changed, 18 insertions(+) diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c index c291ef3..a32ed78 100644 --- a/lib/igt_debugfs.c +++

Re: [Intel-gfx] [RFCv3 11/15] drm/i915: Introduce execlist context status change notification

Hi Chirs: Could you elaborate your idea here? :) As we have to know the status change of the LRC context, not only the request to copy the content back to guest (There will be a small window between a request is finished and the context is switched out). We tried i915_wait_request()

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

Hi Ramalingam, [auto build test ERROR on v4.5-rc7] [cannot apply to drm-intel/for-linux-next next-20160311] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-BXT-Tolerance

[Intel-gfx] [PATCH] drm/i915: GPIO for BXT generic MIPI

Added the BXT GPIO pin configuration and programming logic for backlight and panel control. v2 by Deepak - Added the GPIO table for BXT. - Added gpio_free v3 by Deepak - requesting the gpio once - freeing the gpio while unloading Cc: Jani Nikula Cc: Ville Syrjälä

Re: [Intel-gfx] [RFCv3 11/15] drm/i915: Introduce execlist context status change notification

On Fri, Mar 11, 2016 at 06:59:42PM +0800, Zhi Wang wrote: > This patch introduces an approach to track the execlist context status > change. > > GVT-g uses GVT context as the "shadow context". The content inside GVT > context will be copied back to guest after the context is idle. So GVT-g > has

Re: [Intel-gfx] [RFCv3 10/15] drm/i915: update PDPs by condition when submit the LRC context

On Fri, Mar 11, 2016 at 06:59:41PM +0800, Zhi Wang wrote: > Previously the PDPs inside the ring context will be updated > > - When populating a LRC context > - Before submitting a LRC context (only for 32 bit PPGTT, as the amount > of used PDPs may be changed during PPGTT page table grow) > >

[Intel-gfx] [PATCH v6] drm/i915: Support to enable TRTT on GEN9

From: Akash Goel Gen9 has an additional address translation hardware support in form of Tiled Resource Translation Table (TR-TT) which provides an extra level of abstraction over PPGTT. This is useful for mapping Sparse/Tiled texture resources. Sparse resources are created

[Intel-gfx] [PATCH v2 5/5] drm/i915: More renaming of rings to engines

From: Tvrtko Ursulin This time using only sed and a few by hand. v2: Rename also intel_ring_id and intel_ring_initialized. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c| 2 +- drivers/gpu/drm/i915/i915_dma.c

Re: [Intel-gfx] [PATCH v5 17/35] drm/i915: Added scheduler support to __wait_request() calls

On 01/03/2016 10:02, Joonas Lahtinen wrote: On to, 2016-02-18 at 14:27 +, john.c.harri...@intel.com wrote: From: John Harrison The scheduler can cause batch buffers, and hence requests, to be submitted to the ring out of order and asynchronously to their

[Intel-gfx] ✗ Fi.CI.BAT: warning for intel_engine_cs renaming bomb (rev4)

== Series Details == Series: intel_engine_cs renaming bomb (rev4) URL : https://patchwork.freedesktop.org/series/4303/ State : warning == Summary == Series 4303v4 intel_engine_cs renaming bomb http://patchwork.freedesktop.org/api/1.0/series/4303/revisions/4/mbox/ Test gem_mmap_gtt:

[Intel-gfx] [PATCH 5/5 v3] drm/i915: More renaming of rings to engines

From: Tvrtko Ursulin This time using only sed and a few by hand. v2: Rename also intel_ring_id and intel_ring_initialized. v3: Fixed typo in intel_ring_initialized. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: atomic helper: do not unreference error pointer

== Series Details == Series: drm: atomic helper: do not unreference error pointer URL : https://patchwork.freedesktop.org/series/4352/ State : failure == Summary == Series 4352v1 drm: atomic helper: do not unreference error pointer

[Intel-gfx] [PATCH 1/2] drm/i915: Update VBT fields for child devices

This patch adds new fields that are not yet added in drm code in child devices struct Signed-off-by: Sivakumar Thulasimani Signed-off-by: Durgadoss R Signed-off-by: Shubhangi Shrivastava ---

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: GPIO for BXT generic MIPI (rev2)

== Series Details == Series: drm/i915: GPIO for BXT generic MIPI (rev2) URL : https://patchwork.freedesktop.org/series/4020/ State : failure == Summary == Series 4020v2 drm/i915: GPIO for BXT generic MIPI 2016-03-11T10:34:59.405207

Re: [Intel-gfx] [RFCv3 12/15] drm/i915: Support context single submission

On Fri, Mar 11, 2016 at 06:59:43PM +0800, Zhi Wang wrote: > This patch introduces the support of context signle submission. As GVT > context may come from different guests, which requires different > configuration of render registers. It can't be combined in a dual ELSP > submission combo. That

[Intel-gfx] [PATCH v5] igt/gem_trtt: Exercise the TRTT hardware

From: Akash Goel This patch provides the testcase to exercise the TRTT hardware. Some platforms have an additional address translation hardware support in form of Tiled Resource Translation Table (TR-TT) which provides an extra level of abstraction over PPGTT. This is

Re: [Intel-gfx] [PATCH i-g-t] benchmarks/gem_syslatency: Add extra android guard to attr_setaffinity_np

On Thu, Mar 10, 2016 at 02:27:05PM +, Derek Morton wrote: > Android defines __USE_GNU but does not provide pthread_attr_setaffinity_np() > so added an extra guard arround pthread_attr_setaffinity_np(). > > Signed-off-by: Derek Morton Pushed, thanks. -Chris --

[Intel-gfx] ✗ Fi.CI.BAT: failure for Changes in HDMI detection

== Series Details == Series: Changes in HDMI detection URL : https://patchwork.freedesktop.org/series/4378/ State : failure == Summary == Series 4378v1 Changes in HDMI detection http://patchwork.freedesktop.org/api/1.0/series/4378/revisions/1/mbox/ Test core_prop_blob: Subgroup

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Split driver init step to phases (rev3)

== Series Details == Series: drm/i915: Split driver init step to phases (rev3) URL : https://patchwork.freedesktop.org/series/4374/ State : failure == Summary == Series 4374v3 drm/i915: Split driver init step to phases http://patchwork.freedesktop.org/api/1.0/series/4374/revisions/3/mbox/

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

Hi Ramalingam, [auto build test ERROR on v4.5-rc7] [cannot apply to drm-intel/for-linux-next next-20160311] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-BXT-Tolerance

[Intel-gfx] [PATCH 8/8] drm/i915: Simplify ironlake_crtc_compute_clock() CPU eDP case

None of the code in ironlake_crtc_compute_clock() is relevant for CPU eDP. The CPU eDP PLL is turned on and off in ironlake_edp_pll_{on,off} from the DP code and that doesn't depend on the crtc_state->dpll values, so just return early in that case. Signed-off-by: Ander Conselvan de Oliveira

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/BXT: Tolerance at BXT DSI pipe_config comparison

== Series Details == Series: drm/i915/BXT: Tolerance at BXT DSI pipe_config comparison URL : https://patchwork.freedesktop.org/series/4358/ State : failure == Summary == Series 4358v1 drm/i915/BXT: Tolerance at BXT DSI pipe_config comparison 2016-03-11T13:01:38.194370

[Intel-gfx] [PATCH v2] dim: Avoid false positives with BUG detection

From: Tvrtko Ursulin Makes sure that the diff line adding the BUG is not immediately preceded by the diff line removing the BUG. Or in other words, avoids false positives when existing BUG is edited. v2: Sent the incomplete version out... Signed-off-by: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Move load time display/audio callback init earlier

On Wed, 09 Mar 2016, Imre Deak wrote: > All of this is SW only initialization so we can move them earlier. Move > the mutex init where the rest of the locks are inited. While at it also > convert dev to dev_priv. Bikeshedding on this patch and the next: I don't think the

Re: [Intel-gfx] [PATCH v2] drm/i915/mocs: Program MOCS for all engines on init

Hi Chris, Just posted patch that moves to the engine->init_hw(). Have moved the L3CC registers programming out of the function and left in the same place as the original function was. These registers are shared with all engines. Peter. On Thu, 10 Mar 2016, Chris Wilson wrote: On Thu, Mar

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Move load time display/audio callback init earlier

On pe, 2016-03-11 at 16:00 +0200, Jani Nikula wrote: > On Wed, 09 Mar 2016, Imre Deak wrote: > > All of this is SW only initialization so we can move them earlier. > > Move > > the mutex init where the rest of the locks are inited. While at it > > also > > convert dev to

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Set invert bit for hpd based on VBT

On Fri, 11 Mar 2016, Shubhangi Shrivastava wrote: > [ text/plain ] > This patch sets the invert bit for hpd detection for each port > based on VBT configuration. Since each AOB can be designed to > depend on invert bit or not, it is expected if an AOB requires >

[Intel-gfx] ✗ Fi.CI.BAT: failure for intel_engine_cs renaming bomb (rev5)

== Series Details == Series: intel_engine_cs renaming bomb (rev5) URL : https://patchwork.freedesktop.org/series/4303/ State : failure == Summary == Series 4303v5 intel_engine_cs renaming bomb http://patchwork.freedesktop.org/api/1.0/series/4303/revisions/5/mbox/ Test core_prop_blob:

Re: [Intel-gfx] [PATCH 0/8] Clean up ironlake clock computation code

On Fri, Mar 11, 2016 at 04:52:27PM +0200, Ander Conselvan de Oliveira wrote: > Hi, > > This patch series simplifies the ironlake clock computation code a bit > by deleting some unused/unnecessary code and moving things around a > little. > > I'm planning to split i9xx_crtc_compute_clock() into

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Call g4x_find_best_dpll() directly from ILK+ code

On Fri, Mar 11, 2016 at 04:52:32PM +0200, Ander Conselvan de Oliveira wrote: > The call to dev_priv->display.find_dpll() is already in platform > specific code, so avoid the extra detour. > > Signed-off-by: Ander Conselvan de Oliveira > Reviewed-by: Ville

[Intel-gfx] [PATCH v3] drm/i915/mocs: Program MOCS for all engines on init

Allow for the MOCS to be programmed for all engines. Currently we program the MOCS when the first render batch goes through. This works on most platforms but fails on platforms that do not run a render batch early, i.e. headless servers. The patch now programs all initialised engines on init and

Re: [Intel-gfx] [PATCH v2] drm/i915/mocs: Program MOCS for all engines on init

Just seen a documentation error in program_mocs_l3cc_table() still documents a parameter that has been removed. Will fix later. Peter. On Fri, 11 Mar 2016, Peter Antoine wrote: Hi Chris, Just posted patch that moves to the engine->init_hw(). Have moved the L3CC registers programming out of

[Intel-gfx] [PATCH i-g-t] tools/intel_reg: Add extra pipe B registers for CHV

From: Ville Syrjälä CHV pipe B has some extra features (programmable sprite CSC, primary plane windowing, primary plane scaler, fancier blending). Add all the relevant registers to the "quickdump" register list. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 4/8] drm/i915: Fold intel_ironlake_limit() into clock computation function

The funcion intel_ironlake_limit() is only called by the crtc compute clock path. By merging it into ironlake_compute_clocks(), the code gets clearer, since there's no more if-ladders to follow. Signed-off-by: Ander Conselvan de Oliveira ---

[Intel-gfx] [PATCH 6/8] drm/i915: Don't calculate a new clock in ILK+ code if it is already set

Remove the clock calculation from ironlake_crtc_compute_clock() when the encoder compute_config() already set one. The value was just thrown away in that case. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_display.c | 14

[Intel-gfx] [PATCH 1/8] drm/i915: Remove ironlake reduced clock computation

The irolanke reduced clock computation code is not used since commit c329a4ec595e ("drm/i915: Nuke lvds downclock support"), so clean it up. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_display.c | 38

[Intel-gfx] [PATCH 3/8] drm/i915: Merge ironlake_get_refclk() into its only caller

Previous patches made ironlake_get_refclk() and its only caller, ironlake_compute_clocks(), very simple, so merge them into one simple function. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_display.c | 24

  1   2   >