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
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 code
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 fall
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 INFO,
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 +++---
1 file changed, 7 in
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 ++--
1 file changed, 10 inserti
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;
> >
> >-D
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)
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 +0300,
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. Test brightness keys, they are
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
update
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 allowing the user to create and
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 simp
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. Creating
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 11:3
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
Maybe also add,
Suggested-by: Chris Wilson
>
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
https://lists.freedesktop.
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 i
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 f
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 GEN9+ it means the TC and
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 (De
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 out for
> all platforms. gi
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: s
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 boo
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: err
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 vswing results in some display flicke
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
rev
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 b
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
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
---
drivers/gpu/drm/i915/i915_guc_submission.c | 18
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
== 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
http://patchwork.freedesktop.org/api/1.0/series/9751/revisions/1/mbo
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 r
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 other one as
well.
Cc: David Weine
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ä
Reviewed-by: Daniel Vetter
---
drivers/gpu/d
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 encoder series [1].
Entire serie
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
---
drivers/gpu/drm/i915/intel_ddi.c | 7 +++
1 file changed, 3
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ä
---
drivers/gpu/drm/i915/intel_ddi.c | 20 +---
1 file changed,
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 +
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915
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
---
drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
1 file changed, 2 insertio
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().
Cc: Imre Deak
Signed-off-by: Vil
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: Ville Syrjälä
Reviewed-by: Danie
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 +++-
1 file changed, 40 insertions(+), 11 deletions(-)
diff --git
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 to acquire the rpm wakeref f
== 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
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. However, Skylake separates the
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
once
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 th
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 th
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 regist
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 de
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 +
> include/drm/drm_dp_he
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
> drm_clflush_virt_range()
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
>
> Sig
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 col
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 f
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 explicit
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,
> >
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 leve
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
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 the
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 th
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
---
drivers/gpu/drm/i915/intel_guc_loader.c | 20 +++
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,
old_read_domain
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.
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
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/
https://patchwork.freedesktop.org/s
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 abo
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
> >>>drm_
== 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)
http://patchwork.freedesktop.org/api/1.0/series/
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 rather rude. Let's limit
the ring
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)
> > {
> >-GEM_BUG_ON(ob
== 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 dwar
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)) {
> >-
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 L3-remapping") we're now masking off all
== 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 kms_pipe_c
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 full
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 full
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
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 under
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 deletions(-)
diff --git a/
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 -2
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 61ff75ac20ff ("drm/i915: Simplify e
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 baytra
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 gen6 we didn't have per-ring IMR re
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 curr
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, igt/gem_mo
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 Yang
CC: Yakui Zhao
CC
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
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: rockchip_drm_
== 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
http://patchwork.freedesktop.org/api/1.0/se
Thanks! :P. Welcome back.
On 07/12/16 18:50, Joonas Lahtinen wrote:
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: J
93 matches
Mail list logo
