git 2.5 gained native support for worktrees, so let's use them.
Since this is fairly new I don't think we should switch the general
dim setup over to using it (for e.g. the maintainer-tools and other
auxiliary branches) since 2.5 was only released July 2015.
Signed-off-by: Daniel Vetter
---
dim
On 17 December 2015 at 02:54, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
> that will increment the device's runtime PM usage counter and
> return 'true' if its status is RPM_ACTIVE and its usage counter
> is greater than
Op 15-12-15 om 10:17 schreef Daniel Vetter:
> On Mon, Dec 14, 2015 at 01:06:12PM +0100, Maarten Lankhorst wrote:
>> Op 04-12-15 om 09:12 schreef Daniel Vetter:
>>> On Thu, Dec 03, 2015 at 12:01:02PM +0100, Maarten Lankhorst wrote:
Op 03-12-15 om 10:53 schreef Daniel Vetter:
> On Tue, Nov 2
On Thu, 17 Dec 2015, Mika Kahola wrote:
> On Mon, 2015-12-14 at 12:50 +0200, Jani Nikula wrote:
>> The RVDA and RVDS (raw VBT data address and size) fields of the ASLE
>> mailbox may specify an alternate location for VBT instead of mailbox #4.
>> Use the alternate location if available and valid,
On Thu, Dec 17, 2015 at 10:06:53AM +0100, Maarten Lankhorst wrote:
> Op 15-12-15 om 10:17 schreef Daniel Vetter:
> > On Mon, Dec 14, 2015 at 01:06:12PM +0100, Maarten Lankhorst wrote:
> >> Op 04-12-15 om 09:12 schreef Daniel Vetter:
> >>> On Thu, Dec 03, 2015 at 12:01:02PM +0100, Maarten Lankhorst
On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
i915_gem_object_get_dma_address function is used to retrieve the dma address
of a particular page so as to map it in a given GTT entry for CPU access.
This function would be used for stolen backed objects also fo
Hi,
On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This patch adds support for clearing buffer objects via CPU/GTT. This
is particularly useful for clearing out the non shmem backed objects.
Currently intend to use this only for buffers allocated from stolen
Hi,
On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
we try a nonblocking pin for the whole object (since that is fastest if
reused), then failing that we try to grab one page in the mapp
Reviewed-by: Nick Hoath
On 16/12/2015 18:36, Gordon, David S wrote:
We set up engines in forwards order, so some things (notably the
default context) are "owned" by engine 0 (the render engine, aka "RCS").
For symmetry and to make sure such shared objects don't disappear too
early, we should ge
On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote:
From: Chris Wilson
If we run out of stolen memory when trying to allocate an object, see if
we can reap enough purgeable objects to free up enough contiguous free
space for the allocation. This is in principle very much like evicting
ob
On 16/12/2015 19:30, Chris Wilson wrote:
On Wed, Dec 16, 2015 at 07:22:52PM +, Dave Gordon wrote:
On 16/12/15 18:57, Chris Wilson wrote:
On Wed, Dec 16, 2015 at 06:36:49PM +, Dave Gordon wrote:
Some of the LRC-specific context-destruction code has to special-case
the global default con
On 14/12/15 11:36, Chris Wilson wrote:
Elsewhere we have adopted the convention of using '_link' to denote
elements in the list (and '_list' for the actual list_head itself), and
that the name should indicate which list the link belongs to (and
preferrably not just where the link is being stored
On Thu, Dec 17, 2015 at 10:45:15AM +, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote:
> >From: Ankitprasad Sharma
> >
> >In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
> >we try a nonblocking pin for the whole object (since
On 14/12/15 11:36, Chris Wilson wrote:
As we can now have multiple VMA inside the global GTT (with partial
mappings, rotations, etc), it is no longer true that there may just be a
single GGTT entry and so we should walk the full vma_list to count up
the actual usage. In addition to unifying the
On Thu, Dec 17, 2015 at 11:14:54AM +, Tvrtko Ursulin wrote:
>
> On 14/12/15 11:36, Chris Wilson wrote:
> >Elsewhere we have adopted the convention of using '_link' to denote
> >elements in the list (and '_list' for the actual list_head itself), and
> >that the name should indicate which list t
Hi,
On 14/12/15 11:36, Chris Wilson wrote:
The multiple levels of indirect do nothing but hinder the compiler and
the pointer chasing turns to be quite painful but painless to fix.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 13 ++---
drivers/gpu/dr
On Wed, Dec 16, 2015 at 11:52:17AM +0100, Daniel Vetter wrote:
> On Sun, Dec 06, 2015 at 09:33:20PM +0100, Lukas Wunner wrote:
> > Hi Chris,
> >
> > On Fri, Dec 04, 2015 at 04:05:26PM +, Chris Wilson wrote:
> > > A long time ago (before 3.14) we relied on a permanent pinning of the
> > > ifbde
On 16/12/2015 18:36, Gordon, David S wrote:
1. Fix intel_cleanup_ring_buffer() to handle the error cleanup
case where the ringbuffer has been allocated but map-and-pin
failed. Unpin it iff it's previously been mapped-and-pinned.
2. Fix the error path in intel_init_ring_buffer(), which al
On 16/12/2015 18:36, Gordon, David S wrote:
1. add call to i915_gem_context_fini() to deallocate the default
context(s) if the call to init_rings() fails, so that we don't
leak the context in that situation.
2. remove useless code in intel_logical_ring_cleanup(), presumably
copypaste
On Thu, Dec 17, 2015 at 01:04:25AM +, Kumar, Abhay wrote:
> Sure. In next patch set will get rid of jiffies altogether and will use
> getboottime() instead of do_gettimeofday() for panel_power_cycle_delay.
>
> Does this make sense?
I can't say for sure until I see a patch, but that's my curr
Currently we disable RPM functionality on platforms that doesn't support
this by not putting/getting the RPM reference we receive from the RPM
core during driver loading/unloading respectively. This is somewhat
obscure, so make it more explicit by keeping a reference dedicated for
this particular p
On Thu, Dec 17, 2015 at 11:24:34AM +, Chris Wilson wrote:
> On Thu, Dec 17, 2015 at 11:14:54AM +, Tvrtko Ursulin wrote:
> >
> > On 14/12/15 11:36, Chris Wilson wrote:
> > >Elsewhere we have adopted the convention of using '_link' to denote
> > >elements in the list (and '_list' for the act
Thanks for the testing and comments Lionel.
My comments inline.
Regards
Shashank
On 12/16/2015 9:36 PM, Lionel Landwerlin wrote:
I gave a try to this patch on Braswell.
A couple of comments below.
On 03/12/15 11:36, Shashank Sharma wrote:
CHV/BSW supports Degamma color correction, which linea
We don't really need to check this flag in the get/put/assert helpers,
as on platforms without RPM support we won't ever enable RPM. That means
pm.suspend will be always false and the assert will be always true.
Do this to simplify the code and to let us extend the RPM asserts to all
platforms for
Hi,
On 14/12/15 11:36, Chris Wilson wrote:
For the global GTT (and aliasing GTT), the address space is owned by the
device (it is a global resource) and so the per-file owner field is
NULL. For per-process GTT (where we create an address space per
context), each is owned by the opening file. We
On 14/12/15 11:36, Chris Wilson wrote:
This patch is broken out of the next just to remove the code motion from
that patch and make it more readable. What we do here is move the
i915_vma_move_to_active() to i915_gem_execbuffer.c and put the three
stages (read, write, fenced) together so that fut
Hi,
On 14/12/15 11:36, Chris Wilson wrote:
Hook the vma itself into the i915_gem_request_retire() so that we can
accurately track when a solitary vma is inactive (as opposed to having
s/solitary/individual/ ?
to wait for the entire object to be idle). This improves the interaction
when usin
On Thu, Dec 17, 2015 at 11:09:54AM +, Nick Hoath wrote:
> On 16/12/2015 19:30, Chris Wilson wrote:
> >On Wed, Dec 16, 2015 at 07:22:52PM +, Dave Gordon wrote:
> >>On 16/12/15 18:57, Chris Wilson wrote:
> >>>On Wed, Dec 16, 2015 at 06:36:49PM +, Dave Gordon wrote:
> Some of the LRC-s
Hi,
On 14/12/15 11:36, Chris Wilson wrote:
When the user closes the context mark it and the dependent address space
as closed. As we use an asynchronous destruct method, this has two purposes.
First it allows us to flag the closed context and detect internal errors if
we to create any new objec
On 17/12/15 12:37, Tvrtko Ursulin wrote:
Hi,
On 14/12/15 11:36, Chris Wilson wrote:
When the user closes the context mark it and the dependent address space
as closed. As we use an asynchronous destruct method, this has two
purposes.
First it allows us to flag the closed context and detect in
Disable DP fast link training if DP link configuration
changes. If one of the DP link parameters i.e. link
bandwidth, lane count, rate selection, port clock or bpp
changes the link training does no longer apply the
previously computed voltage swing and pre-emphasis values.
Instead, the link trainin
On to, 2015-12-17 at 13:48 +0200, Imre Deak wrote:
> We don't really need to check this flag in the get/put/assert
> helpers,
> as on platforms without RPM support we won't ever enable RPM. That
> means
> pm.suspend will be always false and the assert will be always true.
>
> Do this to simplify t
On Thu, Dec 17, 2015 at 12:37:13PM +, Tvrtko Ursulin wrote:
> >-static void i915_vma_close(struct i915_vma *vma)
>
> Can't find this in this series?
Should be the previous patch (9/11: Release vma when the handle is
closed) that hooks in gem_object_close to mark each vma as closed if it
is ow
On Thu, Dec 17, 2015 at 02:46:03PM +0200, Mika Kahola wrote:
> Disable DP fast link training if DP link configuration
> changes. If one of the DP link parameters i.e. link
> bandwidth, lane count, rate selection, port clock or bpp
This list of things we check should be updated to match the actual
This patch adds drm flag bits for aspect ratio information
Currently drm flag bits don't have field for mode's picture
aspect ratio. This field will help the driver to pick mode with
right aspect ratio, and help in setting right VIC field in avi
infoframes.
Signed-off-by: Shashank Sharma
---
in
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch adds DRM flags for the new aspect ratios
in the existing aspect ratio flags.
Signed-off-by: Shashank Sharma
---
include/uapi/drm/drm_mode.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/dr
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.
Signed-off-by: Shashank Sharma
---
drivers/video/hdmi.c | 4
include/linux/hdmi.h | 2 ++
2 files changed, 6 insertions(+)
diff -
Current DRM layer functions dont parse aspect ratio information
while converting a user mode->kernel mode or viceversa. This
causes modeset to pick mode with wrong aspect ratio, eventually
cauing failures in HDMI compliance test cases, due to wrong VIC.
This patch adds aspect ratio information in
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch adds support for these aspect ratios in
I915 driver, at various places.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_modes.c | 12
drivers/gpu/drm/i915/intel_hdmi.c | 6 ++
driver
Currently DRM framework doesn't parse aspect ratio of a videomode
while converting it from a umode->kmode or viceversa. This causes
modeset of CEA modes with incorrect aspect ratio.
While running HDMI complaince, tests (like 7-27) expect the DUT
to apply the mode as per the VIC, but as driver does
On Thu, Dec 17, 2015 at 11:52:06AM +, Tvrtko Ursulin wrote:
> >-ret = __hw_ppgtt_init(dev, ppgtt);
> >+ret = __hw_ppgtt_init(ppgtt, dev_priv);
> > if (ret == 0) {
> > kref_init(&ppgtt->ref);
> > i915_address_space_init(&ppgtt->base, dev_priv);
> >+
On 17/12/15 12:48, Chris Wilson wrote:
On Thu, Dec 17, 2015 at 12:37:13PM +, Tvrtko Ursulin wrote:
-static void i915_vma_close(struct i915_vma *vma)
Can't find this in this series?
Should be the previous patch (9/11: Release vma when the handle is
closed) that hooks in gem_object_close
This patch adds drm flag bits for aspect ratio information
Currently drm flag bits don't have field for mode's picture
aspect ratio. This field will help the driver to pick mode with
right aspect ratio, and help in setting right VIC field in avi
infoframes.
Signed-off-by: Shashank Sharma
---
in
Currently DRM framework doesn't parse aspect ratio of a videomode
while converting it from a umode->kmode or viceversa. This causes
modeset of CEA modes with incorrect aspect ratio.
While running HDMI complaince, tests (like 7-27) expect the DUT
to apply the mode as per the VIC, but as driver does
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch adds DRM flags for the new aspect ratios
in the existing aspect ratio flags.
Signed-off-by: Shashank Sharma
---
include/uapi/drm/drm_mode.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/dr
Current DRM layer functions dont parse aspect ratio information
while converting a user mode->kernel mode or viceversa. This
causes modeset to pick mode with wrong aspect ratio, eventually
cauing failures in HDMI compliance test cases, due to wrong VIC.
This patch adds aspect ratio information in
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch adds support for these aspect ratios in
I915 driver, at various places.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_modes.c | 12
drivers/gpu/drm/i915/intel_hdmi.c | 6 ++
driver
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.
Signed-off-by: Shashank Sharma
---
drivers/video/hdmi.c | 4
include/linux/hdmi.h | 2 ++
2 files changed, 6 insertions(+)
diff -
Hi,
On 14/12/15 11:36, Chris Wilson wrote:
In order to prevent a leak of the vma on shared objects, we need to
hook into the object_close callback to destroy the vma on the object for
this file. However, if we destroyed that vma immediately we may cause
unexpected application stalls as we try t
On Thu, Dec 17, 2015 at 01:46:58PM +, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 14/12/15 11:36, Chris Wilson wrote:
> >In order to prevent a leak of the vma on shared objects, we need to
> >hook into the object_close callback to destroy the vma on the object for
> >this file. However, if we destro
On 14/12/15 11:36, Chris Wilson wrote:
When the user closes the context mark it and the dependent address space
as closed. As we use an asynchronous destruct method, this has two purposes.
First it allows us to flag the closed context and detect internal errors if
we to create any new objects f
On Thu, Dec 17, 2015 at 01:46:58PM +, Tvrtko Ursulin wrote:
> > list_for_each_entry_safe(vma, next, &obj->vma_list, obj_link) {
> >-int ret;
> >-
> > vma->pin_count = 0;
> >-ret = i915_vma_unbind(vma);
> >-if (WARN_ON(ret == -ERESTARTSYS)) {
>
On Thu, Dec 17, 2015 at 02:15:52PM +, Tvrtko Ursulin wrote:
> >+static void i915_ppgtt_close(struct i915_address_space *vm)
> >+{
> >+struct list_head *phases[] = {
> >+&vm->active_list,
> >+&vm->inactive_list,
> >+&vm->unbound_list,
> >+NULL,
On 17/12/15 14:21, Chris Wilson wrote:
On Thu, Dec 17, 2015 at 01:46:58PM +, Tvrtko Ursulin wrote:
list_for_each_entry_safe(vma, next, &obj->vma_list, obj_link) {
- int ret;
-
vma->pin_count = 0;
- ret = i915_vma_unbind(vma);
-
On 17/12/15 14:26, Chris Wilson wrote:
On Thu, Dec 17, 2015 at 02:15:52PM +, Tvrtko Ursulin wrote:
+static void i915_ppgtt_close(struct i915_address_space *vm)
+{
+ struct list_head *phases[] = {
+ &vm->active_list,
+ &vm->inactive_list,
+ &vm
On ti, 2015-12-15 at 20:10 +0200, Imre Deak wrote:
> This is v4 of [1]. It has the following changes:
> - fix module reload that got broken in v3 due to removal of HAS_RUNTIME_PM
> (added patch 1-3 + revised patch 4)
> - disable the wakeref asserts in the IRQ handlers and RPS work too
> (revis
== Summary ==
• Testing [v2] drm/i915: Introduce drm_i915_gem_request_active for request
tracking
• Testing [02/11] drm/i915: Refactor activity tracking for requests
WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather
than BUG() or BUG_ON()
#680: FILE: drivers/gpu/
== Summary ==
• Testing drm/i915: edp resume/On time optimization.
WARNING: Duplicate signature
#17:
Signed-off-by: Abhay Kumar
WARNING: line over 100 characters
#60: FILE: drivers/gpu/drm/i915/intel_dp.c:2055:
+ panel_power_off_duration =
(intel_dp->panel_power_on_timestamp.tv_sec-i
Since commit 940aece471bd ("drm/i915/vlv: Valleyview support
for forcewake Individual power wells.") we have only taken
media engine forcewake correctly on reads, but only taken render
engine forcewake on media engine writes and omitted the media
domain.
This asymmetry might have caused unstable b
On 12/17/2015 07:14 AM, Mika Kuoppala wrote:
> Since commit 940aece471bd ("drm/i915/vlv: Valleyview support
> for forcewake Individual power wells.") we have only taken
> media engine forcewake correctly on reads, but only taken render
> engine forcewake on media engine writes and omitted the media
On Thu, Dec 17, 2015 at 05:14:54PM +0200, Mika Kuoppala wrote:
> Since commit 940aece471bd ("drm/i915/vlv: Valleyview support
> for forcewake Individual power wells.") we have only taken
> media engine forcewake correctly on reads, but only taken render
> engine forcewake on media engine writes and
On Thu, Dec 17, 2015 at 05:39:39PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 17, 2015 at 05:14:54PM +0200, Mika Kuoppala wrote:
> > Since commit 940aece471bd ("drm/i915/vlv: Valleyview support
> > for forcewake Individual power wells.") we have only taken
> > media engine forcewake correctly on rea
== Summary ==
Built on 8463389e40c3815b2e9b052f34145b1d728975be drm-intel-nightly:
2015y-12m-17d-14h-39m-21s UTC integration manifest
Test igt@kms_pipe_crc_basic@read-crc-pipe-c-frame-sequence on bdw-nuci7
dmesg-warn -> pass
Test igt@kms_flip@basic-flip-vs-dpms on bsw-nuc-2 pass -> dmesg-warn
T
On Thu, Dec 10, 2015 at 05:41:30PM +0100, Takashi Iwai wrote:
> On Thu, 10 Dec 2015 17:36:04 +0100,
> Ville Syrjälä wrote:
> >
> > On Fri, Dec 04, 2015 at 04:05:26PM +, Chris Wilson wrote:
> > > A long time ago (before 3.14) we relied on a permanent pinning of the
> > > ifbdev to lock the fb i
== Summary ==
Built on 8463389e40c3815b2e9b052f34145b1d728975be drm-intel-nightly:
2015y-12m-17d-14h-39m-21s UTC integration manifest
Test igt@kms_flip@basic-flip-vs-wf_vblank on snb-x220t dmesg-warn -> pass
Test igt@kms_flip@basic-flip-vs-wf_vblank on bsw-nuc-2 pass -> dmesg-warn
Test igt@kms_p
This test enables testing of :
* degamma LUTs
* csc matrix
* gamma LUTs
Signed-off-by: Lionel Landwerlin
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/kms_color.c | 611 +
3 files changed, 613 insertions(+)
create
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 3ea9915..781851c 100644
--- a/lib/igt_fb.c
+++
Hi there,
Here are a few patches for testing the color management.
This tests only support split degamma/gamma mode. I believe we could
add the additional modes (10/12bits) tests on top of that.
I will also provide additional legacy gamma tests on top of this to
make sure we don't break the exis
Signed-off-by: Lionel Landwerlin
---
lib/igt_kms.c | 40
lib/igt_kms.h | 9 -
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index eeed468..1f37489 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -12
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 5d5a95c..eeed468 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1004,6 +1004,7 @@ void igt_display_init(igt_display_t *display, int
Since
commit 357597e51dd1aa3cf764d322abf89217e3dcd7bb
Author: Imre Deak
Date: Tue Nov 10 06:12:22 2015 +0200
drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers
this file is writeable also on platforms without RPM support, but
userspace (at least IGT) depends on this fil
On Thu, Dec 17, 2015 at 07:04:33PM +0200, Imre Deak wrote:
> Since
>
> commit 357597e51dd1aa3cf764d322abf89217e3dcd7bb
> Author: Imre Deak
> Date: Tue Nov 10 06:12:22 2015 +0200
>
> drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers
>
> this file is writeable also on pl
On to, 2015-12-17 at 17:19 +, Chris Wilson wrote:
> On Thu, Dec 17, 2015 at 07:04:33PM +0200, Imre Deak wrote:
> > Since
> >
> > commit 357597e51dd1aa3cf764d322abf89217e3dcd7bb
> > Author: Imre Deak
> > Date: Tue Nov 10 06:12:22 2015 +0200
> >
> > drm/i915: remove HAS_RUNTIME_PM check
On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> From: Maarten Lankhorst
>
> This allows users of dma fences to create a android fence.
>
> v2: Added kerneldoc. (Tvrtko Ursulin).
>
> v4: Updated comments from review feedback my Maarten.
>
> Signed-off-by: Maarten Lankhorst
> Signed-
On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> From: Maarten Lankhorst
>
> Debug output assumes all sync points are built on top of Android sync points
> and when we start creating them from dma-fences will NULL ptr deref unless
> taught about this.
>
> v4: Corrected patch ownership.
On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The sync framework is now used by the i915 driver. Therefore it can be
> moved out of staging and into the regular tree. Also, the public
> interfaces can actually be made public and exported.
>
> v3: New patch fo
On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The sync code has a facility for dumping current state information via
> debugfs. It also has a way to re-use the same code for dumping to the
> kernel log on an internal error. However, the redirection was rather
== Summary ==
Built on ac2305b6c91b9a84cc12566016ece257c3ebcba3 drm-intel-nightly:
2015y-12m-17d-16h-19m-23s UTC integration manifest
Test igt@kms_flip@basic-flip-vs-wf_vblank on bsw-nuc-2 pass -> dmesg-warn
Test igt@kms_flip@basic-flip-vs-wf_vblank on skl-i7k-2 dmesg-fail -> dmesg-warn
Test igt
On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The fence object used inside the request structure requires a sequence
> number. Although this is not used by the i915 driver itself, it could
> potentially be used by non-i915 code if the fence is passed outside o
It is unclear if this is even required on BXT.
v2: Make sure to set the default value to false. Uncertain how my compiler
doesn't complain with v1.
Cc: Imre Deak
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_lrc.c | 16
1 file changed, 8 insertions(+), 8 deletions
On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> There is a construct in the linux kernel called 'struct fence' that is
> intended to keep track of work that is executed on hardware. I.e. it
> solves the basic problem that the drivers 'struct
> drm_i915_gem_reque
Some modules, like i915.ko, use swappable objects and may try to swap
them out under memory pressure (via the shrinker). Before doing so,
they want to check using get_nr_swap_pages() to see if any swap space
is available as otherwise they will waste time purging the object from
the device without r
As we add the VMA to the request early, it may be cancelled during
execbuf reservation. This will leave the context object pointing to a
dangling request; i915_wait_request() simply skips the wait and so we
may unbind the object whilst it is still active.
We can partially prevent such atrocity by
On 12/16/2015 11:39 PM, Chris Wilson wrote:
On Wed, Dec 16, 2015 at 01:40:53PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> GuC supports different scheduling policies for its four internal
> queues. Currently these have been set to the same default values
> as KMD_NORMAL queue.
>
> Part
From: Shashank Sharma
Color Management is an extension to DRM framework to allow hardware color
correction and enhancement capabilities.
DRM color manager supports these color properties:
1. "ctm": Color transformation matrix property, where a
color transformation matrix of 9 correction value
Hi,
Here is an update on the color management serie by Shashank.
This one squashes things a bit to make it a bit easier to review.
This also includes a number of fixes,
for Braswell :
- Read the right values from the degamma blob.
for Broadwell :
- Always reset the lut index when writing th
From: Shashank Sharma
Implement degamma, csc and gamma steps on CHV.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/i915_drv.c| 5 +-
drivers/gpu/drm/i915/i915_drv.h| 2 +
d
From: Shashank Sharma
In plane enabling sequence, plane gamma bit is by default enabled.
Plane gamma gets higher priority than pipe gamma, if both enabled.
This patch disables plane gamma from sequence. If required, plane
gamma can be enabled via the color manager drm interface.
Signed-off-by:
From: Shashank Sharma
This patch adds set property interface for intel CRTC. This
interface will be used for set operation on any DRM properties.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff -
From: Shashank Sharma
Register cm_coeff_after_ctm_property & cm_coeff_before_ctm_property
indicating the size of the LUT to be supplied to palette_after_ctm &
palette_before_ctm and also register the ctm property to enable color
correction matrix.
Signed-off-by: Shashank Sharma
Signed-off-by: K
From: Shashank Sharma
Implement degamma, csc and gamma steps on BDW+.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_drv.c| 14 +
drivers/gpu/drm/i915/i915_reg.h| 43 ++-
drivers/gpu/drm/i915/intel_color_manager.c | 451 +++
From: Alex Dai
The GuC firmware uses this for various purposes. The ADS itself is
a chunk of memory created by driver to share with GuC. Its members
are usually addresses telling where GuC to access them, including
things like scheduler policies, register list that will be saved
and restored duri
On 17/12/15 12:27, Chris Wilson wrote:
On Thu, Dec 17, 2015 at 11:09:54AM +, Nick Hoath wrote:
On 16/12/2015 19:30, Chris Wilson wrote:
On Wed, Dec 16, 2015 at 07:22:52PM +, Dave Gordon wrote:
On 16/12/15 18:57, Chris Wilson wrote:
On Wed, Dec 16, 2015 at 06:36:49PM +, Dave Gordon
Wakeref series introduced multiple WARN_ONCE clauses which might be
triggered from several sources (hangcheck or cache flusing for example),
this series adds an i915.debug option to make them always WARN which is
useful in the CI.
Had to reorder i915_params to get rid of circular include dependenc
Avoid flooding end users kernel log with warnings and mark recurring
warnings as such. This is a case when multiple code paths trigger a
warning and only displaying it once masks multiple errors in CI.
Cc: Imre Deak
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
dri
Move all the bool variables to the end as per the comment.
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_params.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index a341525..a74
Otherwise usage in the i915 debug macros yields problems due to
i915_drv.h <-> i915_trace.h <-> intel_drv.h include loops.
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h| 40 ++
drivers/gpu/drm/i915/i915_params.c | 1 +
drivers/gpu/drm/i915/i915_param
Using __stringify(x) instead of #x adds support for macros as
a parameter and reduces runtime overhead.
Slightly increases the .text size but should not matter.
Cc: Rob Clark
Acked-by: Daniel Vetter
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 10 ++
1 file cha
Add helpers to reduce the amount of noise. Use the i915.debug parameter
introduced in the previous patch to decide on whether to display all
debug messages or just ones that are meaningful to end user.
Take for example the CI environment, we want to see all possible warning
messages even though th
Add i915.debug parameter to control output in cases where the debug output
amount will be massive and as such is unsuitable for everyday use, but still
significant in value when solving bugs.
Cc: Chris Wilson
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h| 1 -
drivers/g
1 - 100 of 117 matches
Mail list logo
