[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/skl: Add support for the SAGV, fix underrun hangs (rev3)

== Series Details == Series: drm/i915/skl: Add support for the SAGV, fix underrun hangs (rev3) URL : https://patchwork.freedesktop.org/series/9736/ State : failure == Summary == Series 9736v3 drm/i915/skl: Add support for the SAGV, fix underrun hangs

[Intel-gfx] linux-next: manual merge of the drm-misc tree with the arm tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/rockchip/rockchip_drm_drv.c between commit: 062993b15e8e ("drm: convert DT component matching to component_match_add_release()") from the arm tree and commit: 6d5fa28c13b9 ("gpu: drm:

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

On 07/01/2016 09:40 PM, Deak, Imre wrote: Setting a write-back cache policy in the MOCS entry definition also implies snooping, which has a considerable overhead. This is unexpected for a few reasons: - From user-space's point of view since it didn't want a coherent surface (it didn't set the

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: Give proper names to MOCS entries

On 07/01/2016 09:40 PM, Deak, Imre wrote: The purpose for each MOCS entry isn't well defined atm. Defining these is important to remove any uncertainty about the use of these entries for example in terms of performance and GPU/CPU coherency. Suggested by Ville. CC: Rong R

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915/gen9: Clean up MOCS table definitions

On 07/01/2016 09:40 PM, Deak, Imre wrote: Use named struct initializers for clarity. Also fix the target cache definition to reflect its role in GEN9 onwards. On GEN8 a TC value of 0 meant ELLC but on GEN9+ it means the TC and LRU controls are taken from the PTE. No functional change,

Re: [Intel-gfx] Kernel stability on baytrail machines

On Tue 2016-07-12 16:41:58, Ezequiel Garcia wrote: > Hi Alan, > > (Adding interested people to this thread) > > On 09 Apr 08:14 PM, One Thousand Gnomes wrote: > > > > I do feel that the importance of the mentioned bug is currently > > > > underestimated. Can anyone here give a note, how much

Re: [Intel-gfx] [PATCH] drm/i915: Unbreak interrupts on pre-gen6

On Tue, Jul 12, 2016 at 10:13:48PM +0300, Ville Syrjälä wrote: > On Tue, Jul 12, 2016 at 05:47:02PM +0100, Chris Wilson wrote: > > On Tue, Jul 12, 2016 at 07:24:47PM +0300, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > Prior to

Re: [Intel-gfx] Kernel stability on baytrail machines

Hi Alan, (Adding interested people to this thread) On 09 Apr 08:14 PM, One Thousand Gnomes wrote: > > > I do feel that the importance of the mentioned bug is currently > > > underestimated. Can anyone here give a note, how much current linux > > > kernel is supposed to be stable on general

Re: [Intel-gfx] [PATCH] drm/i915: Unbreak interrupts on pre-gen6

On Tue, Jul 12, 2016 at 05:47:02PM +0100, Chris Wilson wrote: > On Tue, Jul 12, 2016 at 07:24:47PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Prior to gen6 we didn't have per-ring IMR registers, which means that > > since commit

[Intel-gfx] [PATCH v2 2/3] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

Where we're going to continue regardless of the problem, rather than fail, then the message should be a WARNing rather than an ERROR. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++--- 1 file changed, 7 insertions(+), 11

[Intel-gfx] [PATCH v2 3/3] drm/i915/guc: revisit GuC loader message levels

Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(), a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(), and one eliminated completely. A typical failure mode might now look like this in the dmesg log: [drm] Failed to fetch valid GuC firmware from i915/skl_guc_ver6_1.bin (error

[Intel-gfx] [PATCH v2 1/3] drm: extra printk() wrapper macros

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk() provides several other useful intermediate levels such as NOTICE and WARNING. So this patch fills out the set by providing both regular and once-only macros for each of the levels INFO, NOTICE, and WARNING, using a common

Re: [Intel-gfx] [PATCH v3] drm/i915/skl: Add support for the SAGV, fix underrun hangs

On Tue, Jul 12, 2016 at 01:36:03PM -0400, Lyude wrote: > Since the watermark calculations for Skylake are still broken, we're apt > to hitting underruns very easily under multi-monitor configurations. > While it would be lovely if this was fixed, it's not. Another problem > that's been coming from

[Intel-gfx] [PATCH v3] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this however, is the mysterious issue of underruns causing

[Intel-gfx] [PATCH v2] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this however, is the mysterious issue of underruns causing

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: Unbreak interrupts on pre-gen6

== Series Details == Series: drm/i915: Unbreak interrupts on pre-gen6 URL : https://patchwork.freedesktop.org/series/9762/ State : success == Summary == Series 9762v1 drm/i915: Unbreak interrupts on pre-gen6 http://patchwork.freedesktop.org/api/1.0/series/9762/revisions/1/mbox Test

Re: [Intel-gfx] [PATCH] drm/i915: Unbreak interrupts on pre-gen6

On Tue, Jul 12, 2016 at 07:24:47PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Prior to gen6 we didn't have per-ring IMR registers, which means that > since commit 61ff75ac20ff ("drm/i915: Simplify enabling > user-interrupts with

Re: [Intel-gfx] [PATCH 47/64] drm/i915: Be more careful when unbinding vma

On Tue, Jul 12, 2016 at 04:04:57PM +0100, Tvrtko Ursulin wrote: > >@@ -3463,11 +3483,18 @@ int i915_gem_object_set_cache_level(struct > >drm_i915_gem_object *obj, > > return -EBUSY; > > } > > > >-if (!i915_gem_valid_gtt_space(vma, cache_level)) { > >-

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: SKL iboost fixes

== Series Details == Series: drm/i915: SKL iboost fixes URL : https://patchwork.freedesktop.org/series/9759/ State : success == Summary == Series 9759v1 drm/i915: SKL iboost fixes http://patchwork.freedesktop.org/api/1.0/series/9759/revisions/1/mbox fi-kbl-qkkr total:237 pass:174

Re: [Intel-gfx] [PATCH 49/64] drm/i915: Introduce i915_gem_active for request tracking

On Tue, Jul 12, 2016 at 05:05:44PM +0100, Tvrtko Ursulin wrote: > > On 07/07/16 09:41, Chris Wilson wrote: > >@@ -2383,10 +2383,10 @@ void i915_vma_move_to_active(struct i915_vma *vma, > > static void > > i915_gem_object_retire__write(struct drm_i915_gem_object *obj) > > { > >-

[Intel-gfx] [PATCH] drm/i915: Unbreak interrupts on pre-gen6

From: Ville Syrjälä Prior to gen6 we didn't have per-ring IMR registers, which means that since commit 61ff75ac20ff ("drm/i915: Simplify enabling user-interrupts with L3-remapping") we're now masking off all interrupts when init_render_ring() gets called. That's

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

== Series Details == Series: drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl) URL : https://patchwork.freedesktop.org/series/9757/ State : failure == Summary == Series 9757v1 drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

Re: [Intel-gfx] [PATCH 46/64] drm/i915: Count how many VMA are bound for an object

On Tue, Jul 12, 2016 at 04:12:43PM +0100, Tvrtko Ursulin wrote: > > On 12/07/16 15:38, Chris Wilson wrote: > >On Tue, Jul 12, 2016 at 03:30:25PM +0100, Tvrtko Ursulin wrote: > >>On 07/07/16 09:41, Chris Wilson wrote: > >>>@@ -3684,6 +3684,9 @@ i915_gem_object_pin_to_display_plane(struct >

Re: [Intel-gfx] [PATCH 49/64] drm/i915: Introduce i915_gem_active for request tracking

On 07/07/16 09:41, Chris Wilson wrote: In the next patch, request tracking is made more generic and for that we need a new expanded struct and to separate out the logic changes from the mechanical churn, we split out the structure renaming into this patch. v2: Writer's block. Add some spiel

Re: [Intel-gfx] [PATCH] drm/i915: Fix legacy gamma lut updates in Linux 4.7-rc6

On 07/12/2016 05:02 PM, Lionel Landwerlin wrote: On 12/07/16 13:11, Mario Kleiner wrote: On 07/12/2016 12:50 PM, Lionel Landwerlin wrote: Hi Mario, Hi Lionel, There was a couple of patch to fix this issue : https://patchwork.freedesktop.org/series/5467/

Re: [Intel-gfx] [PATCH] drm/i915/skl: Add support for the SAGV, fix underrun hangs

On Mon, Jul 11, 2016 at 06:00:46PM -0400, Lyude wrote: > Since the watermark calculations for Skylake are still broken, we're apt > to hitting underruns very easily under multi-monitor configurations. > While it would be lovely if this was fixed, it's not. Another problem > that's been coming from

Re: [Intel-gfx] [PATCH 48/64] drm/i915: Kill drop_pages()

On 07/07/16 09:41, Chris Wilson wrote: The drop_pages() function is a dangerous trap in that it can release the passed in object pointer and so unless the caller is aware, it can easily trick us into using the stale object afterwards. Move it into its solitary callsite where we know it is safe.

Re: [Intel-gfx] [PATCH 46/64] drm/i915: Count how many VMA are bound for an object

On 12/07/16 15:38, Chris Wilson wrote: On Tue, Jul 12, 2016 at 03:30:25PM +0100, Tvrtko Ursulin wrote: On 07/07/16 09:41, Chris Wilson wrote: @@ -3684,6 +3684,9 @@ i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,

Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc: revisit GuC loader message levels

On 12/07/16 10:26, Tvrtko Ursulin wrote: On 11/07/16 19:01, Dave Gordon wrote: Some downgraded from DRM_ERROR() to DRM_WARN(), some eliminated, and a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(). Signed-off-by: Dave Gordon ---

Re: [Intel-gfx] [PATCH 47/64] drm/i915: Be more careful when unbinding vma

On 07/07/16 09:41, Chris Wilson wrote: When we call i915_vma_unbind(), we will wait upon outstanding rendering. This will also trigger a retirement phase, which may update the object lists. If, we extend request tracking to the VMA itself (rather than keep it at the encompassing object), then

Re: [Intel-gfx] [PATCH] drm/i915: Fix legacy gamma lut updates in Linux 4.7-rc6

On 12/07/16 13:11, Mario Kleiner wrote: On 07/12/2016 12:50 PM, Lionel Landwerlin wrote: Hi Mario, Hi Lionel, There was a couple of patch to fix this issue : https://patchwork.freedesktop.org/series/5467/ https://patchwork.freedesktop.org/series/5466/ Looking at them they should fix

Re: [Intel-gfx] [PATCH 1/3] drm: extra printk() wrapper macros

On 12/07/16 15:25, Daniel Vetter wrote: On Mon, Jul 11, 2016 at 07:01:27PM +0100, Dave Gordon wrote: We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk() provides several other useful intermediate levels such as NOTICE and WARNING. So this patch fills out the set by providing

Re: [Intel-gfx] [PATCH 1/3] drm: extra printk() wrapper macros

On Tue, Jul 12, 2016 at 03:53:55PM +0100, Dave Gordon wrote: > On 12/07/16 15:25, Daniel Vetter wrote: > > On Mon, Jul 11, 2016 at 07:01:27PM +0100, Dave Gordon wrote: > > > We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk() > > > provides several other useful intermediate

Re: [Intel-gfx] [PATCH 46/64] drm/i915: Count how many VMA are bound for an object

On Tue, Jul 12, 2016 at 03:30:25PM +0100, Tvrtko Ursulin wrote: > On 07/07/16 09:41, Chris Wilson wrote: > >@@ -3684,6 +3684,9 @@ i915_gem_object_pin_to_display_plane(struct > >drm_i915_gem_object *obj, > > old_read_domains, > >

Re: [Intel-gfx] [PATCH 46/64] drm/i915: Count how many VMA are bound for an object

On 07/07/16 09:41, Chris Wilson wrote: Since we may have VMA allocated for an object, but we interrupted their binding, there is a disparity between have elements on the obj->vma_list and being bound. i915_gem_obj_bound_any() does this check, but this is not rigorously observed - add an

Re: [Intel-gfx] [PATCH 1/3] drm: extra printk() wrapper macros

On Mon, Jul 11, 2016 at 07:01:27PM +0100, Dave Gordon wrote: > We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk() > provides several other useful intermediate levels such as NOTICE and > WARNING. So this patch fills out the set by providing both regular and > once-only macros

Re: [Intel-gfx] [PATCH 3/3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

On Tue, Jul 12, 2016 at 12:04:03PM +0100, Chris Wilson wrote: > On Tue, Jul 12, 2016 at 12:44:17PM +0200, Daniel Vetter wrote: > > On Mon, Jul 11, 2016 at 04:24:45PM +0100, Chris Wilson wrote: > > > That doesn't fit the out-of-order unbound nature of the interface. The > > > interface is just a

Re: [Intel-gfx] [PATCH v6 09/10] drm/i915: Update bits per component for display info

On Wed, Jul 06, 2016 at 02:04:53PM +0300, Mika Kahola wrote: > DisplayPort branch device may define max supported bits per > component. Update display info based on this value if bpc > is defined. > > v2: cleanup to match the drm_dp_helper.c patches introduced > earlier in this series > >

Re: [Intel-gfx] [PATCH 06/64] drm: Restore double clflush on the last partial cacheline

On Thu, Jul 07, 2016 at 09:41:12AM +0100, Chris Wilson wrote: > This effectively reverts > > commit afcd950cafea6e27b739fe7772cbbeed37d05b8b > Author: Chris Wilson > Date: Wed Jun 10 15:58:01 2015 +0100 > > drm: Avoid the double clflush on the last cache line in

Re: [Intel-gfx] [PATCH v6 06/10] drm: Read DP branch device HW revision

On Wed, Jul 06, 2016 at 02:04:50PM +0300, Mika Kahola wrote: > HW revision is mandatory field for DisplayPort branch > devices. This is defined in DPCD register field 0x509. > > Signed-off-by: Mika Kahola > --- > drivers/gpu/drm/drm_dp_helper.c | 21 +

Re: [Intel-gfx] [PATCH v6 10/10] drm/i915: Add DP branch device info on debugfs

On Wed, Jul 06, 2016 at 02:04:54PM +0300, Mika Kahola wrote: > Read DisplayPort branch device info from through debugfs > interface. > > v2: use drm_dp_helper routines to collect data > v3: cleanup to match the drm_dp_helper.c patches introduced > earlier in this series > v4: move DP branch

Re: [Intel-gfx] [PATCH 1/3] drm: extra printk() wrapper macros

On 12/07/16 14:28, Dave Gordon wrote: On 12/07/16 10:06, Tvrtko Ursulin wrote: On 11/07/16 19:01, Dave Gordon wrote: We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk() provides several other useful intermediate levels such as NOTICE and WARNING. So this patch fills out

Re: [Intel-gfx] [PATCH v6 08/10] drm/i915: Check pixel rate for DP to VGA dongle

On Wed, Jul 06, 2016 at 02:04:52PM +0300, Mika Kahola wrote: > Filter out a mode that exceeds the max pixel rate setting > for DP to VGA dongle. This is defined in DPCD register 0x81 > if detailed cap info i.e. info field is 4 bytes long and > it is available for DP downstream port. > > The

Re: [Intel-gfx] Legacy gamma table updates broken in 4.7-rc4

On Wed, Jul 06, 2016 at 12:26:44PM +0200, Mario Kleiner wrote: > A strange one. In Linux 4.7-rc4, at least as build by the Ubuntu mainline > ppa, gamma table updates via RandR don't work. No errors are reported and > the X-Server thinks everything went well, but on Intel Ironlake and > Ivybridge

Re: [Intel-gfx] [PATCH 1/3] drm: extra printk() wrapper macros

On 12/07/16 10:06, Tvrtko Ursulin wrote: On 11/07/16 19:01, Dave Gordon wrote: We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk() provides several other useful intermediate levels such as NOTICE and WARNING. So this patch fills out the set by providing both regular and

Re: [Intel-gfx] [PATCH] drm/i915: Acquire intel_runtime_pm for HD-Audio registers

On Tue, Jul 12, 2016 at 04:10:22PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > On Haswell/Broadwell, the HD-Audio block is inside the HDMI/display > > power well and so the sna-hda audio codec acquires the display power > > well while it is operational.

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Ignore panel type from OpRegion on SKL

== Series Details == Series: drm/i915: Ignore panel type from OpRegion on SKL URL : https://patchwork.freedesktop.org/series/9752/ State : warning == Summary == Series 9752v1 drm/i915: Ignore panel type from OpRegion on SKL http://patchwork.freedesktop.org/api/1.0/series/9752/revisions/1/mbox

Re: [Intel-gfx] [PATCH] drm/i915: Acquire intel_runtime_pm for HD-Audio registers

Chris Wilson writes: > On Haswell/Broadwell, the HD-Audio block is inside the HDMI/display > power well and so the sna-hda audio codec acquires the display power > well while it is operational. However, Skylake separates the powerwells > again, and so we must remember

[Intel-gfx] [PATCH 3/9] drm/i915: Program iboost settings for HDMI/DVI on SKL

From: Ville Syrjälä Currently we fail to program the iboost stuff for HDMI/DVI. Let's remedy that. Cc: David Weinehall Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ddi.c | 51

[Intel-gfx] [PATCH 8/9] drm/i915: Simplify intel_ddi_get_encoder_port()

From: Ville Syrjälä We no longer have any need to look up the intel_digital_port based on the passed in intel_encoder, but we still want to look up the port. Let's just move that logic into intel_ddi_get_encoder_port() and drop the dig_port stuff. Signed-off-by:

[Intel-gfx] [PATCH 5/9] drm/i915: Explicitly use ddi buf trans entry 9 for hdmi

From: Ville Syrjälä When the DDI port is in HDMI/DVI mode, it automagically uses the buffer translations values from entry 9. Let's make that explicit in the code. Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter

[Intel-gfx] [PATCH 4/9] drm/i915: Move bxt_ddi_vswing_sequence() call into intel_ddi_pre_enable() for HDMI

From: Ville Syrjälä Now that the SKL iboost programming is done from intel_ddi_pre_enable() for HDMI, let's move the BXT bxt_ddi_vswing_sequence() call there as well. This makes things look more similar to the DP/eDP case which is handled in ddi_signal_levels().

[Intel-gfx] [PATCH 0/9] drm/i915: SKL iboost fixes

From: Ville Syrjälä While looking into the recent low vs. normal vswing SKL regression, I ended up going through the iboost handling as well. I spotted several problems which I've tried to fix. I also picked up a bunch of related patches from my earlier split DDI

[Intel-gfx] [PATCH 7/9] drm/i915: Get the iboost setting based on the port type

From: Ville Syrjälä Program the 'iboost_bit' based on what the VBT says it should be for the specific port type, rather than assume it's always the same for DP and HDMI. Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter

[Intel-gfx] [PATCH 9/9] drm/i915: Extract bdw_get_buf_trans_edp()

From: Ville Syrjälä Make the BDW and SKL code a bit more similar by extracting the low vswing handling for BDW into a helper, as we already have it like that for SKL+. Cc: Mika Kahola Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 2/9] drm/i915: Name the "iboost bit"

From: Ville Syrjälä Give a proper name for the SKL DDI_BUF_TRANS iboost bit. Cc: David Weinehall Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 1 +

[Intel-gfx] [PATCH 1/9] drm/i915: Fix iboost setting for DDI with 4 lanes on SKL

From: Ville Syrjälä Bspec says: "For DDIA with x4 capability (DDI_BUF_CTL DDIA Lane Capability Control = DDIA x4), the I_boost value has to be programmed in both tx_blnclegsctl_0 and tx_blnclegsctl_4." Currently we only program tx_blnclegsctl_0. Let's do the

[Intel-gfx] [PATCH 6/9] drm/i915: Split DP/eDP/FDI and HDMI/DVI DDI buffer programming apart

From: Ville Syrjälä DDI buffer prorgramming works quite differently depending on the mode of the DDI port (DP/eDP/FDI vs. HDMI/DVI). Let's split the function that does the programming into two matching variants as well. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH v2] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

vGEM buffers are useful for passing data between software clients and hardware renders. By allowing the user to create and attach fences to the exported vGEM buffers (on the dma-buf), the user can implement a deferred renderer and queue hardware operations like flipping and then signal the buffer

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Provide argument names for static stubs

== Series Details == Series: drm/i915: Provide argument names for static stubs URL : https://patchwork.freedesktop.org/series/9751/ State : failure == Summary == Series 9751v1 drm/i915: Provide argument names for static stubs

[Intel-gfx] [drm-intel:topic/drm-misc 2/11] drivers/gpu/drm/vgem/vgem_drv.c:238:33: note: in expansion of macro 'pgprot_writecombine'

tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 37035e7411fc90d57e4aca83ef654f50c3a0f626 commit: e6f15b763ab2bc47000ec302123e2fb3bf2ad7d4 [2/11] drm/vgem: Enable dmabuf interface for export config: m68k-allyesconfig (attached as .config) compiler: m68k-linux-gcc (GCC) 4.9.0

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

On 12/07/16 10:20, Tvrtko Ursulin wrote: On 11/07/16 19:01, Dave Gordon wrote: Where we're going to continue regardless of the problem, rather than fail, then the message should be a WARNing rather than an ERROR. Signed-off-by: Dave Gordon ---

[Intel-gfx] [drm-intel:topic/drm-misc 2/11] arch/ia64/include/asm/pgtable.h:353:45: note: in expansion of macro 'pgprot_val'

tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 37035e7411fc90d57e4aca83ef654f50c3a0f626 commit: e6f15b763ab2bc47000ec302123e2fb3bf2ad7d4 [2/11] drm/vgem: Enable dmabuf interface for export config: ia64-allyesconfig (attached as .config) compiler: ia64-linux-gcc (GCC) 4.9.0

Re: [Intel-gfx] [PATCH] backlight: Avoid double fbcon backlight handling

On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote: > Backlights controlled by i915.ko and only associated with its connectors > and also only associated with the intel_drmfb fbcon, controlled by > i915.ko. In this situation, we already handle adjusting the backlight > when the fbcon is

Re: [Intel-gfx] [PATCH] drm/i915: Fix legacy gamma lut updates in Linux 4.7-rc6

On 07/12/2016 12:50 PM, Lionel Landwerlin wrote: Hi Mario, Hi Lionel, There was a couple of patch to fix this issue : https://patchwork.freedesktop.org/series/5467/ https://patchwork.freedesktop.org/series/5466/ Looking at them they should fix the issue, but they seem to be stuck in

[Intel-gfx] [PATCH] drm/i915: Ignore panel type from OpRegion on SKL

From: Ville Syrjälä Dell XPS 13 9350 apparently doesn't like it when we use the panel type from OpRegion. The OpRegion panel type (0) tells us to use use low vswing for eDP, whereas the VBT panel type (2) tells us to use normal vswing. The problem is that low

[Intel-gfx] [CI] drm/i915: Provide argument names for static stubs

Make sure we keep kbuilder happy in all of its random configs by providing argument names for compile-time stubs. In file included from drivers/gpu/drm/i915/intel_dp_mst.c:27:0: drivers/gpu/drm/i915/i915_drv.h: In function 'i915_debugfs_register': >> drivers/gpu/drm/i915/i915_drv.h:3612:48:

Re: [Intel-gfx] [PATCH] drm/i915/guc: symbolic names for user load/submission preferences

On 11/07/16 20:58, Chris Wilson wrote: On Mon, Jul 11, 2016 at 06:12:40PM +0100, Dave Gordon wrote: The existing code that accesses the "enable_guc_loading" and "enable_guc_submission" parameters uses explicit numerical values for the various possibilities, including in some cases relying on

Re: [Intel-gfx] [drm-intel:topic/drm-misc 2/2] drivers/gpu/drm/vgem/vgem_drv.c:238:53: error: 'PAGE_KERNEL_IO' undeclared

On Tue, Jul 12, 2016 at 07:23:55PM +0800, kbuild test robot wrote: > tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc > head: e6f15b763ab2bc47000ec302123e2fb3bf2ad7d4 > commit: e6f15b763ab2bc47000ec302123e2fb3bf2ad7d4 [2/2] drm/vgem: Enable > dmabuf interface for export > config:

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Check live status before reading edid

On Thu, Jul 09, 2015 at 07:27:57PM +0200, Daniel Vetter wrote: > On Thu, Jul 09, 2015 at 05:34:29PM +0530, Sonika Jindal wrote: > > Adding this for SKL onwards. > > > > Signed-off-by: Sonika Jindal > > I think this is the critical piece really, and I'd like to roll it

[Intel-gfx] [drm-intel:topic/drm-misc 2/2] drivers/gpu/drm/vgem/vgem_drv.c:238:53: error: 'PAGE_KERNEL_IO' undeclared

tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: e6f15b763ab2bc47000ec302123e2fb3bf2ad7d4 commit: e6f15b763ab2bc47000ec302123e2fb3bf2ad7d4 [2/2] drm/vgem: Enable dmabuf interface for export config: sparc64-allmodconfig (attached as .config) compiler: sparc64-linux-gnu-gcc

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915/gen9: Clean up MOCS table definitions

On pe, 2016-07-01 at 14:47 -0700, Francisco Jerez wrote: > Hi Imre, > > Imre Deak writes: > > > Use named struct initializers for clarity. Also fix the target > > cache > > definition to reflect its role in GEN9 onwards. On GEN8 a TC value > > of 0 > > meant ELLC but on

Re: [Intel-gfx] [PATCH 1/3] drm: extra printk() wrapper macros

On Mon, Jul 11, 2016 at 07:01:27PM +0100, Dave Gordon wrote: > We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk() > provides several other useful intermediate levels such as NOTICE and > WARNING. So this patch fills out the set by providing both regular and > once-only macros

Re: [Intel-gfx] [PATCH 3/3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

On Tue, Jul 12, 2016 at 12:44:17PM +0200, Daniel Vetter wrote: > On Mon, Jul 11, 2016 at 04:24:45PM +0100, Chris Wilson wrote: > > That doesn't fit the out-of-order unbound nature of the interface. The > > interface is just a collection of fences that userspace associates with > > the buffer that

Re: [Intel-gfx] [PATCH] drm/i915: Update ifdeffery for mutex->owner

On Tue, Jul 12, 2016 at 11:48:09AM +0100, Matthew Auld wrote: > Reviewed-by: Matthew Auld Thanks, pushed. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH] drm/i915: Fix legacy gamma lut updates in Linux 4.7-rc6

Hi Mario, There was a couple of patch to fix this issue : https://patchwork.freedesktop.org/series/5467/ https://patchwork.freedesktop.org/series/5466/ I tested this late last week on drm-intel-nightly, it seems a series of revert fixed most of the issues. Cheers, - Lionel On 12/07/16

Re: [Intel-gfx] [PATCH] drm/i915: Set the access right of kernel param "i915.enable_gvt" to read-only.

On ma, 2016-06-20 at 08:17 -0400, Zhi Wang wrote: > The access right of kernel param "i915.enable_gvt" should be read-only as > it only applies during module load (and is not *runtime* writable). > > Cc: Chris Wilson Reviewed-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH] drm/i915: Update ifdeffery for mutex->owner

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

Re: [Intel-gfx] [PATCH 2/3] drm/vgem: Enable dmabuf interface for export

On Mon, Jul 11, 2016 at 02:08:07PM +0100, Chris Wilson wrote: > Enable the standard GEM dma-buf interface provided by the DRM core, but > only for exporting the VGEM object. This allows passing around the VGEM > objects created from the dumb interface and using them as sources > elsewhere.

Re: [Intel-gfx] [PATCH 32/44] drm/i915: Move module init/exit to i915_pci.c

On ke, 2016-06-15 at 13:18 +0100, Chris Wilson wrote: > The module init/exit routines are a wrapper around the PCI device > init/exit, so move them across. > > Note that in order to avoid exporting the driver struct, instead of > manipulating driver.features inside i915_init we instead opt to

Re: [Intel-gfx] [PATCH 3/3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

On Mon, Jul 11, 2016 at 04:24:45PM +0100, Chris Wilson wrote: > On Mon, Jul 11, 2016 at 12:10:40PM -0300, Gustavo Padovan wrote: > > 2016-07-11 Chris Wilson : > > > > > vGEM buffers are useful for passing data between software clients and > > > hardware renders. By

[Intel-gfx] [PATCH] drm/i915: Fix legacy gamma lut updates in Linux 4.7-rc6

Updating legacy gamma tables, e.g., via RandR doesn't work at all as of Linux 4.7-rc6. Reason seems to be that the required call to drm_atomic_helper_commit_planes_on_crtc is skipped in intel_atomic_commit after userspace set new gamma tables, because neither crtc->state->planes_changed nor

Re: [Intel-gfx] [PATCH v4 0/2] drm/i915/opregion: proper handling of DIDL and CADL

Op 01-07-16 om 15:51 schreef Jani Nikula: > On Fri, 01 Jul 2016, Rainer Koenig wrote: >> Found a problem: After screensaver kicked in and display was turned off >> the brightness keys stop working. >> >> Problem can be reproduced like that: >> >> 1. Boot laptop >> 2.

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

On Fri, Jun 24, 2016 at 01:42:06PM +0100, Chris Wilson wrote: > On Fri, Jun 24, 2016 at 12:48:17PM +0100, Steven Newbury wrote: > > On Fri, 2016-06-24 at 11:59 +0100, Chris Wilson wrote: > > > On Thu, Jun 23, 2016 at 02:14:12PM +0100, Steven Newbury wrote: > > > > On Thu, 2016-06-23 at 15:59

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

On 12/07/16 10:27, Chris Wilson wrote: On Tue, Jul 12, 2016 at 10:20:43AM +0100, Tvrtko Ursulin wrote: On 11/07/16 19:01, Dave Gordon wrote: @@ -553,8 +551,8 @@ static int guc_ring_doorbell(struct i915_guc_client *gc) if (db_ret.db_status == GUC_DOORBELL_DISABLED)

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

On Tue, Jul 12, 2016 at 10:20:43AM +0100, Tvrtko Ursulin wrote: > On 11/07/16 19:01, Dave Gordon wrote: > >@@ -553,8 +551,8 @@ static int guc_ring_doorbell(struct i915_guc_client *gc) > > if (db_ret.db_status == GUC_DOORBELL_DISABLED) > > break; > > > >-

Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc: revisit GuC loader message levels

On 11/07/16 19:01, Dave Gordon wrote: Some downgraded from DRM_ERROR() to DRM_WARN(), some eliminated, and a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(). Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/intel_guc_loader.c | 20 ++--

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

On 11/07/16 19:01, Dave Gordon wrote: Where we're going to continue regardless of the problem, rather than fail, then the message should be a WARNing rather than an ERROR. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_guc_submission.c | 18

Re: [Intel-gfx] [PATCH 1/3] drm: extra printk() wrapper macros

On 11/07/16 19:01, Dave Gordon wrote: We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk() provides several other useful intermediate levels such as NOTICE and WARNING. So this patch fills out the set by providing both regular and once-only macros for each of the levels

[Intel-gfx] [PATCH resend xf86-video-intel] Fix fd (and mem) leak when intel_scrn_create fails

The probe functions in intel_module.c call intel_open_device() before calling intel_scrn_create(), but if the later fails because of e.g. an unsupported (new) pci-id they were not cleaning up the resources claimed by intel_open_device(), esp. leaking the fd is a problem because this breaks the

Re: [Intel-gfx] [PATCH] drm/i915: Fill unused GGTT with scratch pages for VT-d

On Tue, Jul 12, 2016 at 11:50:26AM +0300, Joonas Lahtinen wrote: > On pe, 2016-06-24 at 14:07 +0100, Chris Wilson wrote: > > One of the numerous VT-d workarounds we require is that the display > > hardware reads past the end of the buffer triggering VT-d faults. This > > is acknowledged in the

Re: [Intel-gfx] [PATCH] drm/i915: Fill unused GGTT with scratch pages for VT-d

On pe, 2016-06-24 at 14:07 +0100, Chris Wilson wrote: > One of the numerous VT-d workarounds we require is that the display > hardware reads past the end of the buffer triggering VT-d faults. This > is acknowledged in the code as being safe "since we fill the unused > portions of the GGTT with the

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: intel_dp_link_is_valid() should only return status of link

== Series Details == Series: drm/i915: intel_dp_link_is_valid() should only return status of link URL : https://patchwork.freedesktop.org/series/9737/ State : failure == Summary == Series 9737v1 drm/i915: intel_dp_link_is_valid() should only return status of link