== Series Details ==
Series: drm/i915/skl: Fix redundant cursor update, fix cursor underruns
URL : https://patchwork.freedesktop.org/series/9940/
State : success
== Summary ==
Series 9940v1 drm/i915/skl: Fix redundant cursor update, fix cursor underruns
http://patchwork.freedesktop.org/api/1.0
Hi,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.7-rc7 next-20160715]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Lionel-Landwerlin/drm-i915-Set-legacy
At long last, the time has finally come for Skylake users to plug their
external displays back in.
During intel_atomic_commit() on Skylake, we've actually been arming the
registers to update the cursor information twice instead of just once.
Once in i9xx_update_cursor(), and once in skl_wm_flush_p
On Fri, Jul 15, 2016 at 3:08 AM, Shobhit Kumar wrote:
>
> On Fri, Jul 15, 2016 at 2:33 PM, Shobhit Kumar
> wrote:
> > On devices that have MIPI DSI panel control and PWM control comming from
> > CRC PMIC, we need the gpio and pwm exported from the intel_soc_pmic
> > driver. Defer probing for lat
On Fri, Jul 15, 2016 at 09:47:59PM +0200, Daniel Vetter wrote:
> Was forgotten when adding them all over. 0-day should complain about
> new missing kernel-doc, not sure why that wasn't caught/fixed.
>
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drm_crtc.h | 26
On Fri, Jul 15, 2016 at 09:48:06PM +0200, Daniel Vetter wrote:
> Fairly minimal, there's still lots of functions without any docs, and
> which aren't static. But probably we want to first clean this up some more.
>
> - Drop the bogus const. Marking argument pointers themselves (instead of
> what
On Fri, Jul 15, 2016 at 09:48:03PM +0200, Daniel Vetter wrote:
> Just replicates whether the list is empty or not. Nuke code
> to avoid writing docs for it!
>
> Cc: Dave Airlie
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
Unless Dave to planned to use it elsewhere, tx_msg_downq is
The drm_irq docs want one function from drmP.h, but that one is a
serious mess. Extract it, and while at it improve the docs a bit.
There's a bit a header loop issue since core data structures like
drm_device and drm_driver aren't in their own headers yet, which means
the drm_irq.h include in drmP.
Not sure why so much slips through when 0day is catching these. Hopefully
the much faster sphinx toolchain helps in unlazying people.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_vgpu.c | 3 ++-
drivers/gpu/drm/i915/intel_fbc.c |
Just replicates whether the list is empty or not. Nuke code
to avoid writing docs for it!
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
include/drm/drm_dp_mst_helper.h | 1 -
2 files changed, 3 insertions(+), 11 deletions(-)
d
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_mst_topology.c | 1 +
include/drm/drm_dp_mst_helper.h | 140 --
2 files changed, 117 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/d
Never added when the DP validation code was added.
Signed-off-by: Daniel Vetter
---
include/drm/drm_dp_helper.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 4d85cf2874af..72dee1213268 100644
--- a/incl
I'm fed up with the warning noise from kernel-doc.
Aside: I stumbled over dirty_info_property, which is only set by udl
and qxl. But we have a _lot_ more drivers implementing a dirty
callback on framebuffers. Not entirely sure what the ABI is supposed
to be here, but it seems confusing for sure.
Fairly minimal, there's still lots of functions without any docs, and
which aren't static. But probably we want to first clean this up some more.
- Drop the bogus const. Marking argument pointers themselves (instead of
what they point at) as const provides roughly 0 value. And it's confusing,
This is unfortunately not all the sphinx noise when building the gpu
documentations. But the remaining warnings have completely bogus line
and probably also file sources, and I just can't find them.
Probably some serious debuggging of the line annotations in the
sphinx/kernel-doc toolchain needed
We need :: before, blank lines around and indentation with 4 _additional_
spaces to make it work. Also, don't use @param in code snippets, it results
in confusion.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_uncore.c | 12
1 file changed, 8 insertions(+), 4 deletions
Was forgotten when adding them all over. 0-day should complain about
new missing kernel-doc, not sure why that wasn't caught/fixed.
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
include/drm/drm_crtc.h | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --
Right now there's nothing, and kernel-doc produces a warning because
of that. Remove it until we need it for a clean build.
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/gpu/drm-kms.rst b/D
On 07/15/2016 11:36 AM, Bish, Jim wrote:
On Fri, 2016-07-15 at 10:34 -0500, Larry Finger wrote:
On 07/15/2016 09:43 AM, Ville Syrjälä wrote:
On Fri, Jul 15, 2016 at 04:27:27PM +0200, Daniel Vetter wrote:
On Fri, Jul 15, 2016 at 8:55 AM, Linus Torvalds
wrote:
On Thu, 14 Jul 2016, Larry Fin
On Fri, 2016-07-15 at 10:34 -0500, Larry Finger wrote:
> On 07/15/2016 09:43 AM, Ville Syrjälä wrote:
> >
> > On Fri, Jul 15, 2016 at 04:27:27PM +0200, Daniel Vetter wrote:
> > >
> > > On Fri, Jul 15, 2016 at 8:55 AM, Linus Torvalds
> > > wrote:
> > > >
> > > > On Thu, 14 Jul 2016, Larry Finger
On 7/15/2016 5:01 PM, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Chris Wilson
vmaps has a provision for controlling the page protection bits, with
which
we can use to control the mapping type, e.g. WB, WC, UC or even WT.
To allow the caller to choose their ma
On 7/15/2016 8:37 PM, Tvrtko Ursulin wrote:
On 15/07/16 15:42, Goel, Akash wrote:
On 7/15/2016 5:27 PM, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Akash Goel
In cases where GuC generate logs at a very high rate, correspondingly
the rate of flush interrupts
On Fri, 15 Jul 2016 14:59:02 +0100
Lionel Landwerlin wrote:
> From: Bob Paauwe
>
> The i915 driver is now using atomic properties and atomic commit
> to handle the legacy set gamma IOCTL. However, if the driver is
> configured without atomic (nuclear_pageflip = false), it won't
> update the leg
On 7/15/2016 5:21 PM, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Akash Goel
GuC firmware sends an interrupt to flush the log buffer when it
becomes half full. GuC firmware also tracks how many times the
buffer overflowed.
It would be useful to maintain a stat
On 7/15/2016 5:10 PM, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Akash Goel
With the addition of new Host2GuC actions related to GuC logging, there
is a need of a lock to serialize them, as they can execute concurrently
with each other and also with other exi
On 7/15/2016 4:45 PM, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Akash Goel
On recieving the log buffer flush interrupt from GuC firmware, Driver
stores the snapshot of the log buffer in a local buffer, from which
Userspace can pull the logs. By default Drive
So, the issue is that i-g-t will not build on our builder system, with
the current version of librm-intel. It just happens to work because I
took the liberity of upgrading the entire system, a while ago.
No build, no newer i-g-t, no tests, no CI.
There are a few of _PINNED macros defined by Chris
On 07/15/2016 09:43 AM, Ville Syrjälä wrote:
On Fri, Jul 15, 2016 at 04:27:27PM +0200, Daniel Vetter wrote:
On Fri, Jul 15, 2016 at 8:55 AM, Linus Torvalds
wrote:
On Thu, 14 Jul 2016, Larry Finger wrote:
To anyone keeping track of regressions in kernel 4.7, I call your attention to
https://bu
On 15/07/16 15:42, Goel, Akash wrote:
On 7/15/2016 5:27 PM, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Akash Goel
In cases where GuC generate logs at a very high rate, correspondingly
the rate of flush interrupts is also very high.
So far total 8 pages were a
On 07/15/2016 09:43 AM, Ville Syrjälä wrote:
On Fri, Jul 15, 2016 at 04:27:27PM +0200, Daniel Vetter wrote:
On Fri, Jul 15, 2016 at 8:55 AM, Linus Torvalds
wrote:
On Thu, 14 Jul 2016, Larry Finger wrote:
To anyone keeping track of regressions in kernel 4.7, I call your attention to
https://bu
On Fri, Jul 15, 2016 at 04:27:27PM +0200, Daniel Vetter wrote:
> On Fri, Jul 15, 2016 at 8:55 AM, Linus Torvalds
> wrote:
> > On Thu, 14 Jul 2016, Larry Finger wrote:
> >> To anyone keeping track of regressions in kernel 4.7, I call your
> >> attention to
> >> https://bugs.freedesktop.org/show_bu
On 7/15/2016 5:27 PM, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Akash Goel
In cases where GuC generate logs at a very high rate, correspondingly
the rate of flush interrupts is also very high.
So far total 8 pages were allocated for storing both ISR & DPC lo
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/evict: Always switch away from
the current context
URL : https://patchwork.freedesktop.org/series/9932/
State : failure
== Summary ==
Series 9932v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/9
On Fri, Jul 15, 2016 at 8:55 AM, Linus Torvalds
wrote:
> On Thu, 14 Jul 2016, Larry Finger wrote:
>> To anyone keeping track of regressions in kernel 4.7, I call your attention
>> to
>> https://bugs.freedesktop.org/show_bug.cgi?id=96675.
>>
>> This bug causes driver i915 to fail to connect to the
== Series Details ==
Series: drm/i915:gen9: restrict WaC6DisallowByGfxPause
URL : https://patchwork.freedesktop.org/series/9930/
State : failure
== Summary ==
Series 9930v1 drm/i915:gen9: restrict WaC6DisallowByGfxPause
http://patchwork.freedesktop.org/api/1.0/series/9930/revisions/1/mbox
Tes
Signed-off-by: Lionel Landwerlin
---
tests/Makefile.sources |2 +-
tests/kms_pipe_color.c | 1184 --
tests/kms_pipe_color_basic.c | 1184 ++
3 files changed, 1185 insertions(+), 1185 deletions(-)
dele
From: Bob Paauwe
The i915 driver is now using atomic properties and atomic commit
to handle the legacy set gamma IOCTL. However, if the driver is
configured without atomic (nuclear_pageflip = false), it won't
update the legacy properties for degamma_lut, gamma_lut and ctm
leaving them out of sync
Before suspend, and especially before building the hibernation image, we
need to context image to be coherent in memory. To do this we require
that we perform a context switch to a disposable context (i.e. the
dev_priv->kernel_context) - when that switch is complete, all other
context images will b
Currently execlists is exempt from emitting a request to switch each
ring away from the current context over to the dev_priv->kernel_context
(for whatever reason, just under execlists the GGTT is unlikely to be as
fragmented, however the switch may help in some extreme cases). Extract
the switcher
From: Tim Gore
WaC6DisallowByGfxPause is currently applied unconditionally
but is not required in all revisions.
References: HSD#2133391
Signed-off-by: Tim Gore
---
drivers/gpu/drm/i915/intel_guc_loader.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i9
Chris Wilson writes:
> Currently execlists is exempt from emitting a request to switch each
> ring away from the current context over to the dev_priv->kernel_context
> (for whatever reason, just under execlists the GGTT is unlikely to be as
> fragmented, however the switch may help in some extrem
On 29/06/16 17:00, Chris Wilson wrote:
On Wed, Jun 29, 2016 at 04:41:58PM +0100, Tvrtko Ursulin wrote:
On 29/06/16 16:34, Chris Wilson wrote:
On Wed, Jun 29, 2016 at 04:09:31PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Replace per-engine initialization with a common half-programati
On Fri, Jul 15, 2016 at 01:03:40PM +0100, Chris Wilson wrote:
> Before suspend, and especially before building the hibernation image, we
> need to context image to be coherent in memory. To do this we require
> that we perform a context switch to a disposable context (i.e. the
> dev_priv->kernel_co
On Fri, Jul 15, 2016 at 02:08:17PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Since commit a6f766f39751 ("drm/i915: Limit ring synchronisation (sw
> > sempahores) RPS boosts") and commit bcafc4e38b6a ("drm/i915: Limit mmio
> > flip RPS boosts") we have limited the waitboosting for s
== Series Details ==
Series: series starting with [1/2] drm/i915/evict: Always switch away from the
current context (rev2)
URL : https://patchwork.freedesktop.org/series/9926/
State : failure
== Summary ==
Series 9926v2 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/seri
Chris Wilson writes:
> Since commit a6f766f39751 ("drm/i915: Limit ring synchronisation (sw
> sempahores) RPS boosts") and commit bcafc4e38b6a ("drm/i915: Limit mmio
> flip RPS boosts") we have limited the waitboosting for semaphores and
> flips. Ideally we do not want to boost in either of these
Chris Wilson writes:
> We want to restrict waitboosting to known process contexts, where we can
> track which clients are receiving waitboosts and prevent excessive power
> wasting. For fence_wait() we do not have any client tracking and so that
> leaves it open to abuse.
>
> v2: Hide the IS_ERR_
On pe, 2016-07-15 at 12:49 +0100, Chris Wilson wrote:
> On Fri, Jul 15, 2016 at 12:08:05PM +0100, Chris Wilson wrote:
> >
> > On Fri, Jul 15, 2016 at 01:47:34PM +0300, Joonas Lahtinen wrote:
> > >
> > > On pe, 2016-07-15 at 11:11 +0100, Chris Wilson wrote:
> > > >
> > > > +#define NO_WAITBOOST E
Before suspend, and especially before building the hibernation image, we
need to context image to be coherent in memory. To do this we require
that we perform a context switch to a disposable context (i.e. the
dev_priv->kernel_context) - when that switch is complete, all other
context images will b
Currently execlists is exempt from emitting a request to switch each
ring away from the current context over to the dev_priv->kernel_context
(for whatever reason, just under execlists the GGTT is unlikely to be as
fragmented, however the switch may help in some extreme cases). Extract
the switcher
Before suspend, and especially before building the hibernation image, we
need to context image to be coherent in memory. To do this we require
that we perform a context switch to a disposable context (i.e. the
dev_priv->kernel_context) - when that switch is complete, all other
context images will b
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Akash Goel
In cases where GuC generate logs at a very high rate, correspondingly
the rate of flush interrupts is also very high.
So far total 8 pages were allocated for storing both ISR & DPC logs.
As per the half-full draining protocol foll
We want to restrict waitboosting to known process contexts, where we can
track which clients are receiving waitboosts and prevent excessive power
wasting. For fence_wait() we do not have any client tracking and so that
leaves it open to abuse.
v2: Hide the IS_ERR_OR_NULL testing for special client
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Akash Goel
GuC firmware sends an interrupt to flush the log buffer when it
becomes half full. GuC firmware also tracks how many times the
buffer overflowed.
It would be useful to maintain a statistics of how many flush
interrupts were receiv
On Fri, Jul 15, 2016 at 12:08:05PM +0100, Chris Wilson wrote:
> On Fri, Jul 15, 2016 at 01:47:34PM +0300, Joonas Lahtinen wrote:
> > On pe, 2016-07-15 at 11:11 +0100, Chris Wilson wrote:
> > > +#define NO_WAITBOOST ERR_PTR(-1)
> >
> > This does not seem to be a very common idiom in kernel, just ad
On Fri, Jul 15, 2016 at 12:31:23PM +0100, Tvrtko Ursulin wrote:
[snip good ideas, leaving the questions]
> > /**
> > * i915_gem_object_unpin_map - releases an earlier mapping
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 8f50919..c431b40 100644
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Akash Goel
With the addition of new Host2GuC actions related to GuC logging, there
is a need of a lock to serialize them, as they can execute concurrently
with each other and also with other existing actions.
After which patch in this seri
On Fri, Jul 15, 2016 at 12:07:42PM +0100, Damien Lespiau wrote:
> Depending how the gcc was compiled it may be necessary to enable SSE4
> instructions explicitly. Otherwise:
>
> CC gem_gtt_speed.o
> In file included from gem_gtt_speed.c:54:0:
> /usr/lib/gcc/x86_64-linux-gnu/4.8/include/smm
Chris Wilson writes:
> A foreign dma-buf does not share our cache domain tracking, and we rely
> on the producer ensuring cache coherency. Marking them as being in the
> CPU domain is incorrect.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 ++
> 1 file chan
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Chris Wilson
vmaps has a provision for controlling the page protection bits, with which
we can use to control the mapping type, e.g. WB, WC, UC or even WT.
To allow the caller to choose their mapping type, we add a parameter to
i915_gem_obje
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Akash Goel
On recieving the log buffer flush interrupt from GuC firmware, Driver
stores the snapshot of the log buffer in a local buffer, from which
Userspace can pull the logs. By default Driver store, up to, 4 snapshots
of the log buffer i
On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote:
> This is the only time PIPE_ANY was used to mean something other than
> unassign this output from a pipe. Without this PIPE_ANY can be aliased
> to PIPE_NONE.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Ander Conselvan de Oliveir
On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote:
> This will allow us to find a matching encoder based on a pipe only.
>
> Signed-off-by: Maarten Lankhorst
> ---
> lib/igt_kms.c | 97 +-
> -
> 1 file changed, 61 insertions(+), 36
== Series Details ==
Series: drm/i915: Set legacy properties when using legacy gamma set IOCTL.
(rev3)
URL : https://patchwork.freedesktop.org/series/5466/
State : failure
== Summary ==
LD drivers/tty/vt/built-in.o
LD drivers/video/fbdev/core/built-in.o
LD drivers/usb/cor
On Fri, Jul 15, 2016 at 01:41:33PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Before suspend, and especially before building the hibernation image, we
> > need to context image to be coherent in memory. To do this we require
> > that we perform a context switch to a disposable conte
On Thu, Jul 14, 2016 at 06:48:26PM +0100, Chris Wilson wrote:
> On Thu, Jul 14, 2016 at 06:44:59PM +0100, Chris Wilson wrote:
> > On Thu, Jul 14, 2016 at 06:31:37PM +0100, Damien Lespiau wrote:
> > > Depending how the gcc was compiled it may be necessary to enable SSE4
> > > instructions explicitly
Chris Wilson writes:
> Since commit a6f766f39751 ("drm/i915: Limit ring synchronisation (sw
> sempahores) RPS boosts") and commit bcafc4e38b6a ("drm/i915: Limit mmio
> flip RPS boosts") we have limited the waitboosting for semaphores and
> flips. Ideally we do not want to boost in either of these
On Fri, Jul 15, 2016 at 01:47:34PM +0300, Joonas Lahtinen wrote:
> On pe, 2016-07-15 at 11:11 +0100, Chris Wilson wrote:
> > +#define NO_WAITBOOST ERR_PTR(-1)
>
> This does not seem to be a very common idiom in kernel, just add flags
> maybe.
I find the special values for the client (including th
Depending how the gcc was compiled it may be necessary to enable SSE4
instructions explicitly. Otherwise:
CC gem_gtt_speed.o
In file included from gem_gtt_speed.c:54:0:
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/smmintrin.h:31:3: error: #error
"SSE4.1 instruction set not enabled"
# error
On Fri, Jul 15, 2016 at 01:49:44PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > We want to restrict waitboosting to known process contexts, where we can
> > track which clients are receiving waitboosts and prevent excessive power
> > wasting. For fence_wait() we do not have any client
== Series Details ==
Series: Color management fixed for 4.7
URL : https://patchwork.freedesktop.org/series/9924/
State : failure
== Summary ==
LD drivers/scsi/built-in.o
CC drivers/usb/host/xhci-trace.o
CC drivers/video/fbdev/core/cfbfillrect.o
LD drivers/tty/vt/bui
From: Bob Paauwe
The i915 driver is now using atomic properties and atomic commit
to handle the legacy set gamma IOCTL. However, if the driver is
configured without atomic (nuclear_pageflip = false), it won't
update the legacy properties for degamma_lut, gamma_lut and ctm
leaving them out of sync
Nightly has gone through some atomic reverts, we just need a single
patch to fix the remaining color management issues.
Cheers,
Lionel
Bob Paauwe (1):
drm/i915: Set legacy properties when using legacy gamma set IOCTL.
drivers/gpu/drm/i915/intel_display.c | 39
The i915 driver checks for color management properties changes as part
of a plane update. Therefore a color management update must imply a
plane update, otherwise we never update the transformation matrixes
and degamma/gamma LUTs.
v2: add comment about moving the commit of color management registe
From: Bob Paauwe
The i915 driver is now using atomic properties and atomic commit
to handle the legacy set gamma IOCTL. However, if the driver is
configured without atomic (nuclear_pageflip = false), it won't
update the legacy properties for degamma_lut, gamma_lut and ctm
leaving them out of sync
A couple of fixes are needed to fix commit issues with color
management properties.
Cheers,
Lionel
Bob Paauwe (1):
drm/i915: Set legacy properties when using legacy gamma set IOCTL.
(v2)
Lionel Landwerlin (1):
drm/i915: add missing condition for committing planes on crtc
drivers/gpu/d
Chris Wilson writes:
> We want to restrict waitboosting to known process contexts, where we can
> track which clients are receiving waitboosts and prevent excessive power
> wasting. For fence_wait() we do not have any client tracking and so that
> leaves it open to abuse.
>
> Signed-off-by: Chris
== Series Details ==
Series: series starting with [1/9] drm/i915: Flush logical context image out to
memory upon suspend
URL : https://patchwork.freedesktop.org/series/9922/
State : failure
== Summary ==
Series 9922v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series
On Fri, Jul 15, 2016 at 11:37:41AM +0100, Arun Siluvery wrote:
> On 15/07/2016 08:08, Yang Rong wrote:
> >Update kernel interface with new I915_GETPARAM ioctl entries for
> >pooled EU and min no. of eus in a pool. Add a wrapping function
> >for each parameter. Userspace drivers need these values wh
On pe, 2016-07-15 at 11:11 +0100, Chris Wilson wrote:
> +#define NO_WAITBOOST ERR_PTR(-1)
This does not seem to be a very common idiom in kernel, just add flags
maybe.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
Chris Wilson writes:
> Migrate the request operations out of the main body of i915_gem.c and
> into their own C file for easier expansion.
>
> v2: Move __i915_add_request() across as well
>
> Signed-off-by: Chris Wilson
Acked-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/Makefile
Chris Wilson writes:
> Before suspend, and especially before building the hibernation image, we
> need to context image to be coherent in memory. To do this we require
> that we perform a context switch to a disposable context (i.e. the
> dev_priv->kernel_context) - when that switch is complete,
On pe, 2016-07-15 at 11:11 +0100, Chris Wilson wrote:
> Migrate the request operations out of the main body of i915_gem.c and
> into their own C file for easier expansion.
>
> v2: Move __i915_add_request() across as well
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/Makefile
On Fri, Jul 15, 2016 at 10:40 AM, Chris Wilson wrote:
> On Fri, Jul 15, 2016 at 08:00:25AM +0200, Sedat Dilek wrote:
>> Hi,
>>
>> I see the below call-trace with latest d-i-n, guess latest linux-next
>> will cause same issues.
>> ( Beyond this, there exist also a build failure which me and Stephen
On 15/07/2016 08:08, Yang Rong wrote:
Update kernel interface with new I915_GETPARAM ioctl entries for
pooled EU and min no. of eus in a pool. Add a wrapping function
for each parameter. Userspace drivers need these values when decide
the thread count. This kernel enabled pooled eu by default for
dma-buf provides a generic fence class for interoperation between
drivers. Internally we use the request structure as a fence, and so with
only a little bit of interfacing we can rebase those requests on top of
dma-buf fences. This will allow us, in the future, to pass those fences
back to userspac
Since commit a6f766f39751 ("drm/i915: Limit ring synchronisation (sw
sempahores) RPS boosts") and commit bcafc4e38b6a ("drm/i915: Limit mmio
flip RPS boosts") we have limited the waitboosting for semaphores and
flips. Ideally we do not want to boost in either of these instances as no
consumer is wa
A foreign dma-buf does not share our cache domain tracking, and we rely
on the producer ensuring cache coherency. Marking them as being in the
CPU domain is incorrect.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/dri
We want to restrict waitboosting to known process contexts, where we can
track which clients are receiving waitboosts and prevent excessive power
wasting. For fence_wait() we do not have any client tracking and so that
leaves it open to abuse.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915
When transitioning to the GTT or CPU domain we wait on all rendering
from i915 to complete (with the optimisation of allowing concurrent read
access by both the GPU and client). We don't yet ensure all rendering
from third parties (tracked by implicit fences on the dma-buf) is
complete. Since impli
Migrate the request operations out of the main body of i915_gem.c and
into their own C file for easier expansion.
v2: Move __i915_add_request() across as well
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.h | 209 +
Following a GPU reset upon hang, we retire all the requests and then
mark them all as complete. If we mark them as complete first, we both
keep the normal retirement order (completed first then retired) and
provide a small optimisation for concurrent lookups.
Signed-off-by: Chris Wilson
Reviewed-
Before suspend, and especially before building the hibernation image, we
need to context image to be coherent in memory. To do this we require
that we perform a context switch to a disposable context (i.e. the
dev_priv->kernel_context) - when that switch is complete, all other
context images will b
In order to keep the memory allocated for requests reasonably tight, try
to reuse the oldest request (so long as it is completed and has no
external references) for the next allocation.
v2: Throw in a comment to hopefully make sure no one mistakes the
optimistic retirement of the oldest request fo
This is the minimal conversion to derive struct i915_gem_request from
dma-buf fences. They are still only used privately (i.e. the requests
are not attached to the dma-buf or any reservation object so not exposed
to any other driver or userspace) and so we defer the issue of RCU
access to the reque
I looked for a match on https://bugs.freedesktop.org/query.cgi but found
nothing looking like a close match that hadn't been marked fixed or
duplicate.
This is happening on a Dell Optiplex 780 in every openSUSE boot at least
as far back as kernel 3.16 in v13.2, but is not evident in v13.1 running
I suspect this might be at root in these threads:
https://lists.freedesktop.org/archives/intel-gfx/2016-March/089805.html
https://lists.freedesktop.org/archives/intel-gfx/2016-June/097652.html
Felix Miata composed on 2016-07-15 05:43 (UTC-0400):
I looked for a match on https://bugs.freedesktop.
== Series Details ==
Series: drm/i915: Return -EPROBE_DEFER if we cannot get GPIO or PWM in dsi_init
URL : https://patchwork.freedesktop.org/series/9918/
State : warning
== Summary ==
Series 9918v1 drm/i915: Return -EPROBE_DEFER if we cannot get GPIO or PWM in
dsi_init
http://patchwork.freede
== Series Details ==
Series: drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl) (rev2)
URL : https://patchwork.freedesktop.org/series/9757/
State : failure
== Summary ==
Series 9757v2 drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)
http://patchwork.freedesktop.org/api/1.0/
On Fri, Jul 15, 2016 at 2:33 PM, Shobhit Kumar wrote:
> On devices that have MIPI DSI panel control and PWM control comming from
> CRC PMIC, we need the gpio and pwm exported from the intel_soc_pmic
> driver. Defer probing for later in case we fail to get these devices.
>
> v2: Rebased on latest d
1 - 100 of 111 matches
Mail list logo
