tree: git://anongit.freedesktop.org/drm-intel for-linux-next
head: bea4e4a4f831df1c104be60b3caa7205ba1bb4f9
commit: 1d1a9774e40414148ecebbdb713746bfb6f9a561 [4/5] drm/i915: Extend
intel_wait_for_register_fw() with fast timeout
config: x86_64-randconfig-h0-04080942 (attached as .config)
compile
tree: git://anongit.freedesktop.org/drm-intel for-linux-next
head: bea4e4a4f831df1c104be60b3caa7205ba1bb4f9
commit: 1d1a9774e40414148ecebbdb713746bfb6f9a561 [4/5] drm/i915: Extend
intel_wait_for_register_fw() with fast timeout
config: x86_64-randconfig-s1-04080500 (attached as .config)
compile
== Series Details ==
Series: slice shutdown debugfs interface for Gen8/Gen9
URL : https://patchwork.freedesktop.org/series/22705/
State : success
== Summary ==
Series 22705v1 slice shutdown debugfs interface for Gen8/Gen9
https://patchwork.freedesktop.org/api/1.0/series/22705/revisions/1/mbox/
On Thu, 6 Apr 2017, Rodrigo Vivi wrote:
> From: Paulo Zanoni
>
> So don't forget to reserve its stolen memory bits.
>
> v2: Adding right Cc.
>
> Cc: Ingo Molnar
> Cc: H. Peter Anvin
> Cc: Ander Conselvan de Oliveira
> Cc: x...@kernel.org
> Signed-off-by: Paulo Zanoni
> Signed-off-by: Rodri
Starting from Gen8 HW supports dynamic power on/off slices. This
permits to free power budget and may dramatically affect performance.
This patch series suggests an interface (debugfs) to permit user to
setup number of active slices. Interface can be used in performance
investigations targeting sca
Slice shutdown override interface (i915_slice_enabled) permits
to power on/off GPGPU slices in Gen8 and Gen9. This is helpful
in performance investigations amd checking scalability across
hw platforms. Changes to slice number done via this interface
will effect any lrc created after the write and w
BDW supports RCS slices powering on/off. To do that we need make_rpcs
executed on BDW to flash slices configuration.
Change-Id: Ia80b1be329bedc57cc61078ea18ecb3d2580c16a
Signed-off-by: Dmitry Rogozhkin
CC: Tvrtko Ursulin
CC: Zhipeng Gong
CC: Joonas Lahtinen
CC: Chris Wilson
---
drivers/gpu/d
== Series Details ==
Series: drm/i915: Implement dma_buf_ops->kmap
URL : https://patchwork.freedesktop.org/series/22704/
State : success
== Summary ==
Series 22704v1 drm/i915: Implement dma_buf_ops->kmap
https://patchwork.freedesktop.org/api/1.0/series/22704/revisions/1/mbox/
fi-bdw-5557u
Since kmap allows us to block we can pin the pages and use our normal
page lookup routine making the implementation simple.
Testcase: igt/drv_selftest/dmabuf
Testcase: igt/prime_rw
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 24 ++
drivers/gpu/drm/i915
The idea is to implement read(dmabuf) and write(dambuf) so provide some
tests.
Signed-off-by: Chris Wilson
---
tests/Makefile.sources | 1 +
tests/prime_rw.c | 179 +
2 files changed, 180 insertions(+)
create mode 100644 tests/prime_rw.c
On Fri, Apr 07, 2017 at 04:58:54PM -0400, Sean Paul wrote:
> Hi Dave,
> Here's the last 4.12 pull request for drm-misc-next. It's quite noisy due to
> us
Hi drm-misc committers,
Just a note that any fixes targetting 4.12 should now go through
drm-misc-next-fixes
as drm-misc-next is moving on.
S
Em Qui, 2017-04-06 às 12:15 -0700, Rodrigo Vivi escreveu:
> One of the steps for PLL (un)initialization is to (un)map
> the correspondent DDI that is actually using that PLL.
>
> So, let's do this step following the places already stablished
> and used so far, although spec put this as part of PLL
Hi Dave,
Here's the last 4.12 pull request for drm-misc-next. It's quite noisy due to us
pulling back rc5 in order to pick up some Synopsys media formats that we added
in conjunction with Mauro.
drm-misc-next-2017-04-07:
Last drm-misc-next pull req for 4.12
Core changes:
- fb_helper checkpatch c
== Series Details ==
Series: drm/i915: Use drm_i915_private directly from debugfs (rev2)
URL : https://patchwork.freedesktop.org/series/22695/
State : success
== Summary ==
Series 22695v2 drm/i915: Use drm_i915_private directly from debugfs
https://patchwork.freedesktop.org/api/1.0/series/2269
The void *data passed to debugfs callbacks is actually the
drm_i915_private pointer, so use it thusly and avoid the to_i915(dev)
indirection.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers
On Fri, Apr 07, 2017 at 12:11:18PM -0700, Dmitry Rogozhkin wrote:
>
>
> On 4/7/2017 11:50 AM, Chris Wilson wrote:
> >On Fri, Apr 07, 2017 at 03:41:41AM -0700, Dmitry Rogozhkin wrote:
> >>Slice shutdown override interface (i915_slice_enabled) permits
> >>to power on/off GPGPU slices in Gen8 and Ge
Em Sáb, 2017-04-08 às 03:21 +0800, kbuild test robot escreveu:
> Hi Paulo,
>
> [auto build test ERROR on next-20170405]
> [cannot apply to tip/x86/core v4.9-rc8 v4.9-rc7 v4.9-rc6 v4.11-rc5]
> [if your patch is applied to the wrong git tree, please drop us a
> note to help improve the system]
This
Hi Paulo,
[auto build test ERROR on next-20170405]
[cannot apply to tip/x86/core v4.9-rc8 v4.9-rc7 v4.9-rc6 v4.11-rc5]
[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/Rodrigo-Vivi/x86-gpu-CNL-use
On 4/7/2017 11:50 AM, Chris Wilson wrote:
On Fri, Apr 07, 2017 at 03:41:41AM -0700, Dmitry Rogozhkin wrote:
Slice shutdown override interface (i915_slice_enabled) permits
to power on/off GPGPU slices in Gen8 and Gen9. This is helpful
in performance investigations amd checking scalability acros
On 04/07/2017 10:11 AM, Chris Wilson wrote:
On Fri, Apr 07, 2017 at 06:23:14PM +0200, Michal Wajdeczko wrote:
On Fri, Apr 07, 2017 at 02:15:47AM -0700, Oscar Mateo wrote:
Not really needed, but makes the next change a little bit more compact.
v2:
- Use zero-based numbering for engine name
== Series Details ==
Series: drm/i915: Use drm_i915_private directly from debugfs
URL : https://patchwork.freedesktop.org/series/22695/
State : failure
== Summary ==
LD [M] drivers/ssb/ssb.o
LD drivers/rtc/built-in.o
LD [M] drivers/usb/serial/usbserial.o
LD lib/raid6/raid6_
== Series Details ==
Series: drm/i915: add slice shutdown debugfs interface
URL : https://patchwork.freedesktop.org/series/22694/
State : success
== Summary ==
Series 22694v1 drm/i915: add slice shutdown debugfs interface
https://patchwork.freedesktop.org/api/1.0/series/22694/revisions/1/mbox/
Hi Rodrigo,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.11-rc5 next-20170407]
[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/Rodrigo-Vivi/drm-i915-cnl-Wa-to
On Fri, Apr 07, 2017 at 03:41:41AM -0700, Dmitry Rogozhkin wrote:
> Slice shutdown override interface (i915_slice_enabled) permits
> to power on/off GPGPU slices in Gen8 and Gen9. This is helpful
> in performance investigations amd checking scalability across
> hw platforms.
>
> Change-Id: I4f2fe5
The void *data passed to debugfs callbacks is actually the
drm_i915_private pointer, so use it thusly and avoid the to_i915(dev)
indirection.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/
Hi Rodrigo,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.11-rc5]
[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/Rodrigo-Vivi/drm-i915-cnp-add-CNP-gmbus-suppor
Slice shutdown override interface (i915_slice_enabled) permits
to power on/off GPGPU slices in Gen8 and Gen9. This is helpful
in performance investigations amd checking scalability across
hw platforms.
Change-Id: I4f2fe5fefb8d1df4519fd0eb58237759c7d1a930
Signed-off-by: Dmitry Rogozhkin
CC: Tvrtko
On Fri, Apr 07, 2017 at 06:26:03PM +0100, Chris Wilson wrote:
> Hmm. Thinking about it more, using _wait_for() at all here is pointless.
>
> You just want to do something like,
>
> if (fast_timeout_us > 10)
> fast_timeout_us = 10;
>
> So
>
> - ret = _wait_for(done, fast_time
== Series Details ==
Series: HDMI YCBCR output handling in DRM layer
URL : https://patchwork.freedesktop.org/series/22684/
State : success
== Summary ==
Series 22684v1 HDMI YCBCR output handling in DRM layer
https://patchwork.freedesktop.org/api/1.0/series/22684/revisions/1/mbox/
Test gem_exe
On Fri, Apr 07, 2017 at 06:48:17PM +0200, Daniel Vetter wrote:
> I thought I've fixed this, but maybe not. Anyway, clearly broken, and
> easy fix.
>
> Cc: Tony Lindgren
> Reported-by: Tony Lindgren
> Fixes: b95ff0319a82 ("drm: Remove drm_modeset_(un)lock_crtc")
> Cc: Harry Wentland
> Cc: Maarte
On Fri, Apr 07, 2017 at 04:01:44PM +, Michal Wajdeczko wrote:
> In some cases we may want to spend more time in atomic wait than
> hardcoded 2us. Let's add additional fast timeout parameter to allow
> flexible configuration of atomic timeout before switching into heavy wait.
> Add also possibil
On Fri, Apr 07, 2017 at 06:23:14PM +0200, Michal Wajdeczko wrote:
> On Fri, Apr 07, 2017 at 02:15:47AM -0700, Oscar Mateo wrote:
> > Not really needed, but makes the next change a little bit more compact.
> >
> > v2:
> > - Use zero-based numbering for engine names: xcs0, xcs1.. xcsN (Tvrtko,
>
Reviewed-by: Daniel Stone
[mobile email formatting apology here]
On Fri, 7 Apr 2017 at 5:48 pm, Daniel Vetter wrote:
> I thought I've fixed this, but maybe not. Anyway, clearly broken, and
> easy fix.
>
> Cc: Tony Lindgren
> Reported-by: Tony Lindgren
> Fixes: b95ff0319a82 ("drm: Remove drm_
Hi Dave,
drm-intel-next-2017-04-03:
Last 4.12 feature pile:
GVT updates:
- Add mdev attribute group for per-vgpu info
- Time slice based vGPU scheduling QoS support (Gao Ping)
- Initial KBL support for E3 server (Han Xu)
- other misc.
i915:
- lots and lots of small fixes and improvements all ove
== Series Details ==
Series: Classify the engines in class + instance (rev6)
URL : https://patchwork.freedesktop.org/series/22535/
State : success
== Summary ==
Series 22535v6 Classify the engines in class + instance
https://patchwork.freedesktop.org/api/1.0/series/22535/revisions/6/mbox/
Tes
I thought I've fixed this, but maybe not. Anyway, clearly broken, and
easy fix.
Cc: Tony Lindgren
Reported-by: Tony Lindgren
Fixes: b95ff0319a82 ("drm: Remove drm_modeset_(un)lock_crtc")
Cc: Harry Wentland
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: David Airli
HDMI source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.
As this patch series is adding support for HDMI output modes
other than RGB, this patch adds a function in DRM layer, to
add the output colorspace information in the AVI i
To support ycbcr HDMI output, we need a pipe CSC block to
do the RGB->YCBCR conversion, as the blender output is in RGB.
Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.
This function adds a csc handler, t
To get a ycbcr420 output from intel platforms, there are two
major steps:
- RGB->YCBCR conversion using a pipe CSC.
- Program PIPE_MISC register to generate a ycbcr420 output.
- Scaling down YCBCR444 samples to YCBCR420 samples using a pipe
scaler.
This patch:
- Does scaler allocation for HDMI y
HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
- RGB
- YCBCR 444
- YCBCR 422
- YCBCR 420
This patch adds a drm property, using which, a userspace
can specify its preference, for the HDMI outp
CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.
Cc: Ville Syrjälä
Cc: Jose Abreu
Signed-off-by: Sha
This patch adds support for HDMI ycbcr outputs in i915 layer.
HDMI output mode is a connector property, this patch checks if
source and sink can support the HDMI output type selected by user.
And if they both can, it commits the hdmi output type into crtc state,
for further staging in driver.
Cc:
When HDMI output is other than RGB, we have to load the
corresponding colorspace of output mode. This patch fills
the colorspace of AVI infoframe as per the HDMI output mode.
Cc: Ville Syrjala
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_hdmi.c
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onw
HDMI 2.0 spec adds support for ycbcr420 subsampled output.
CEA-861-F adds two new blocks in EDID, to provide information about
sink's support for ycbcr420 output.
One of these new blocks is: ycbcr420 vcb
- ycbcr420 video capability data (vcb) block: video modes which can be
support in ycbcr420 o
This patch series adds DRM layer support for YCBCR HDMI output handling.
The target HDMI YCBCR outputs are:
- YCBCR444
- YCBCR422
- YCBCR420
As YCBCR420 output is added in HDMI 2.0, this patch series also
contain few patches to handle new EDID extention blocks, added
for YCBCR420 modes (CEA-861-F)
From: Jose Abreu
HDMI 2.0 spec adds support for ycbcr420 subsampled output.
CEA-861-F adds two new blocks in EDID, to provide information about
sink's support for ycbcr420 output.
These new blocks are:
- ycbcr420 video data (vdb) block: video modes which can be supported
only in ycbcr420 outpu
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if
On Fri, Apr 07, 2017 at 02:34:54AM -0700, Oscar Mateo wrote:
> There are some properties that logically belong to the engine class, and some
> that belong to the engine instance. Make it explicit.
>
> v2: Commit message (Tvrtko)
>
> v3:
> - Rebased
> - Exec/uabi id should be per instance (Chr
== Series Details ==
Series: Classify the engines in class + instance (rev5)
URL : https://patchwork.freedesktop.org/series/22535/
State : success
== Summary ==
Series 22535v5 Classify the engines in class + instance
https://patchwork.freedesktop.org/api/1.0/series/22535/revisions/5/mbox/
fi-
There are some properties that logically belong to the engine class, and some
that belong to the engine instance. Make it explicit.
v2: Commit message (Tvrtko)
v3:
- Rebased
- Exec/uabi id should be per instance (Chris)
v4:
- Rebased
- Avoid re-ordering fields for smaller diff (Tvrtko)
On Fri, Apr 07, 2017 at 02:15:48AM -0700, Oscar Mateo wrote:
> There are some properties that logically belong to the engine class, and some
> that belong to the engine instance. Make it explicit.
>
> v2: Commit message (Tvrtko)
>
> v3:
> - Rebased
> - Exec/uabi id should be per instance (Chr
On Fri, Apr 07, 2017 at 02:15:47AM -0700, Oscar Mateo wrote:
> Not really needed, but makes the next change a little bit more compact.
>
> v2:
> - Use zero-based numbering for engine names: xcs0, xcs1.. xcsN (Tvrtko,
> Chris)
> - Make sure the mock engine name is null-terminated (Tvrtko, Chri
On Fri, Apr 07, 2017 at 02:15:45AM -0700, Oscar Mateo wrote:
> From: Daniele Ceraolo Spurio
>
> In such a way that vcs and vcs2 are just two different instances (0 and 1)
> of the same engine class (VIDEO_DECODE_CLASS).
>
> v2: Align the instance types (Tvrtko)
>
> v3: Don't use enums for bspec
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Extend
intel_wait_for_register_fw() with fast timeout
URL : https://patchwork.freedesktop.org/series/22678/
State : success
== Summary ==
Series 22678v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/s
On Fri, Apr 07, 2017 at 04:01:45PM +, Michal Wajdeczko wrote:
> Waiting for the response status in scratch register can be done
> using our generic function. Let's use it.
>
> v2: rebased
>
> Signed-off-by: Michal Wajdeczko
> Suggested-by: Tvrtko Ursulin
> Cc: Tvrtko Ursulin
> Cc: Joonas L
If we needed to do something different for the init functions, we could
always look at the engine instance to make the distinction. But, in any
case, the two functions are virtually identical already (please notice
that BSD2_RING is only used from gen8 onwards).
With this, the init functions depen
Not really needed, but makes the next change a little bit more compact.
v2:
- Use zero-based numbering for engine names: xcs0, xcs1.. xcsN (Tvrtko, Chris)
- Make sure the mock engine name is null-terminated (Tvrtko, Chris)
v3: Because I'm stupid (Chris)
v4: Verify engine name wasn't truncate
There are some properties that logically belong to the engine class, and some
that belong to the engine instance. Make it explicit.
v2: Commit message (Tvrtko)
v3:
- Rebased
- Exec/uabi id should be per instance (Chris)
v4:
- Rebased
- Avoid re-ordering fields for smaller diff (Tvrtko)
From: Daniele Ceraolo Spurio
Technically speaking, the context size is per engine class, not per
instance.
v2: Add MISSING_CASE (Tvrtko)
v3: Rebased
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Oscar Ma
This refactoring helps simplify a few things here and there.
Daniele Ceraolo Spurio (2):
drm/i915: Classify the engines in class + instance
drm/i915: Use the engine class to get the context size
Oscar Mateo (3):
drm/i915: Use the same vfunc for BSD2 ring init
drm/i915: Generate the engine
From: Daniele Ceraolo Spurio
In such a way that vcs and vcs2 are just two different instances (0 and 1)
of the same engine class (VIDEO_DECODE_CLASS).
v2: Align the instance types (Tvrtko)
v3: Don't use enums for bspec-defined stuff (Michal)
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Waiting for the response status in scratch register can be done
using our generic function. Let's use it.
v2: rebased
Signed-off-by: Michal Wajdeczko
Suggested-by: Tvrtko Ursulin
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_uc.c | 26 +++
In some cases we may want to spend more time in atomic wait than
hardcoded 2us. Let's add additional fast timeout parameter to allow
flexible configuration of atomic timeout before switching into heavy wait.
Add also possibility to return registry value to avoid extra read.
v2: use explicit fast t
On Fri, Apr 07, 2017 at 03:06:00PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 07, 2017 at 11:02:11AM +0100, Chris Wilson wrote:
> > On Fri, Apr 07, 2017 at 01:23:44AM +0200, Andrea Arcangeli wrote:
> > > Waiting a RCU grace period only guarantees the work gets queued, but
> > > until after the qu
On 07/04/2017 15:10, Michal Wajdeczko wrote:
On Fri, Apr 07, 2017 at 02:58:17PM +0100, Tvrtko Ursulin wrote:
On 07/04/2017 14:32, Michal Wajdeczko wrote:
In some cases we may want to spend more time in atomic wait than
hardcoded 2us. Let's add additional hint parameter to allow extending
inte
On Fri, Apr 07, 2017 at 02:52:25PM +0100, Tvrtko Ursulin wrote:
>
> On 07/04/2017 14:32, Michal Wajdeczko wrote:
> >There is no need to specify timeout as unsigned long since this parameter
> >will be consumed by usecs_to_jiffies() which expects unsigned int only.
> >
> >Signed-off-by: Michal Wajd
On Thu, Apr 06, 2017 at 12:15:02PM -0700, Rodrigo Vivi wrote:
> As for BXT, PP_DIVISOR was removed from CNP PCH and power
> cycle delay has been moved to PP_CONTROL.
>
> Cc: Jani Nikula
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_dp.c | 10 +-
> 1 file changed, 5 in
On Fri, Apr 07, 2017 at 01:32:12PM +, Michal Wajdeczko wrote:
> Waiting for the response status in scratch register can be done
> using our generic function that waits for the expected register
> state. Since completion of the GuC commands can take longer than
> 2us mark that wait as bit slower
On Fri, Apr 07, 2017 at 04:10:29PM +0200, Michal Wajdeczko wrote:
> On Fri, Apr 07, 2017 at 02:58:17PM +0100, Tvrtko Ursulin wrote:
> >
> > On 07/04/2017 14:32, Michal Wajdeczko wrote:
> > > In some cases we may want to spend more time in atomic wait than
> > > hardcoded 2us. Let's add additional
On Fri, Apr 07, 2017 at 03:32:30PM +0200, Andrea Arcangeli wrote:
> Hello Joonas,
> I kind I prefer my patch, just cleaned up with the
> synchronize_rcu_expedited under if (unlock) { mutex_unlock;
> synchronize_rcu... }.
Here a cleaned up version below using "unlock" instead of checking the
mutex
On Fri, Apr 07, 2017 at 01:32:11PM +, Michal Wajdeczko wrote:
> In some cases we may want to spend more time in atomic wait than
> hardcoded 2us. Let's add additional hint parameter to allow extending
> internal atomic timeout to 10us before switching into heavy wait.
Examples? I know the 2us
On Thu, Apr 06, 2017 at 12:15:00PM -0700, Rodrigo Vivi wrote:
> Backlight support on Cannonpoint is a lot
> likely Broxton, but with only one controller (0).
This being the PCH backlight obviously. I guess we still don't have any
use for the CPU backlight?
Oh, since the utility pin is on the CPU
On Fri, Apr 07, 2017 at 02:58:17PM +0100, Tvrtko Ursulin wrote:
>
> On 07/04/2017 14:32, Michal Wajdeczko wrote:
> > In some cases we may want to spend more time in atomic wait than
> > hardcoded 2us. Let's add additional hint parameter to allow extending
> > internal atomic timeout to 10us before
On 07/04/2017 14:32, Michal Wajdeczko wrote:
> In some cases we may want to spend more time in atomic wait than
> hardcoded 2us. Let's add additional hint parameter to allow extending
> internal atomic timeout to 10us before switching into heavy wait.
>
> Signed-off-by: Michal Wajdeczko
> Sugges
On 07/04/2017 14:32, Michal Wajdeczko wrote:
There is no need to specify timeout as unsigned long since this parameter
will be consumed by usecs_to_jiffies() which expects unsigned int only.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_dr
== Series Details ==
Series: series starting with [1/3] drm/i915: Fix type of timeout_ms parameter
in intel_wait_for_register_fw()
URL : https://patchwork.freedesktop.org/series/22669/
State : warning
== Summary ==
Series 22669v1 Series without cover letter
https://patchwork.freedesktop.org/a
On Thu, Apr 06, 2017 at 12:14:59PM -0700, Rodrigo Vivi wrote:
> RAWCLK_FREQ register has changed for platforms with CNP+.
>
> [29:26] This field provides the denominator for the fractional
> part of the microsecond counter divider. The numerator
> is fixed at 1. Program this field to
There is no need to specify timeout as unsigned long since this parameter
will be consumed by usecs_to_jiffies() which expects unsigned int only.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_uncor
Waiting for the response status in scratch register can be done
using our generic function that waits for the expected register
state. Since completion of the GuC commands can take longer than
2us mark that wait as bit slower to extend atomic wait to 10us.
Signed-off-by: Michal Wajdeczko
Suggeste
Hello Joonas,
On Fri, Apr 07, 2017 at 01:49:34PM +0300, Joonas Lahtinen wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> index 2978acd..129ed30 100644
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_ge
In some cases we may want to spend more time in atomic wait than
hardcoded 2us. Let's add additional hint parameter to allow extending
internal atomic timeout to 10us before switching into heavy wait.
Signed-off-by: Michal Wajdeczko
Suggested-by: Tvrtko Ursulin
Cc: Tvrtko Ursulin
Cc: Joonas Lah
On Fri, Apr 07, 2017 at 02:15:26PM +0100, Daniel Stone wrote:
> DRM_EVENT_CONTEXT_VERSION is the latest context version supported by
> whatever version of libdrm is present. igt was blindly asserting it
> supported whatever version that may be, even if it actually didn't.
>
> With libdrm 2.4.78, s
On Fri, 2017-04-07 at 16:19 +0300, Ville Syrjälä wrote:
> On Thu, Apr 06, 2017 at 05:54:26PM -0700, Rodrigo Vivi wrote:
> > Current VBT available for pre-production machines
> > tells that we need to use alternate pin. But if we use it
> > we end up needing to define a different table.
> >
> > How
On Thu, Apr 06, 2017 at 05:54:26PM -0700, Rodrigo Vivi wrote:
> Current VBT available for pre-production machines
> tells that we need to use alternate pin. But if we use it
> we end up needing to define a different table.
>
> However if we respect the spec, ignore the VBT for now
> we get a more
DRM_EVENT_CONTEXT_VERSION is the latest context version supported by
whatever version of libdrm is present. igt was blindly asserting it
supported whatever version that may be, even if it actually didn't.
With libdrm 2.4.78, setting a higher context version than 2 will attempt
to call the page_fli
On Fri, Apr 07, 2017 at 10:58:38AM +0100, Chris Wilson wrote:
> On Fri, Apr 07, 2017 at 01:23:47AM +0200, Andrea Arcangeli wrote:
> > Insist to run llist_del_all() until the free_list is found empty, this
> > may avoid having to schedule more workqueues.
>
> The work will already be scheduled (eve
On Fri, Apr 07, 2017 at 11:02:11AM +0100, Chris Wilson wrote:
> On Fri, Apr 07, 2017 at 01:23:44AM +0200, Andrea Arcangeli wrote:
> > Waiting a RCU grace period only guarantees the work gets queued, but
> > until after the queued workqueue returns, there's no guarantee the
> > memory was actually f
On Fri, Apr 07, 2017 at 02:23:58PM +0300, Joonas Lahtinen wrote:
> On pe, 2017-04-07 at 11:25 +0100, Chris Wilson wrote:
> > As we may have very many objects to free, check to see if the task needs
> > to be rescheduled whilst freeing them.
> >
> > Suggested-by: Andrea Arcangeli
> > Signed-off-by
Thanks for the review, pushing series.
On pe, 2017-04-07 at 11:25 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: Don't call
> synchronize_rcu_expedited under struct_mutex
> URL : https://patchwork.freedesktop.org/series/22652/
> State : success
On Fri, Apr 07, 2017 at 01:49:35PM +0300, Joonas Lahtinen wrote:
> By using the same structure for both interruptible and
> uninterruptible locking in shrinker code, combined with the
> information that mm.interruptible is only being written to, the
> code can be greatly simplified.
>
> Also remov
On Fri, Apr 07, 2017 at 02:22:00PM +0300, Joonas Lahtinen wrote:
> On pe, 2017-04-07 at 11:25 +0100, Chris Wilson wrote:
> > As we call into the shrinker during freeze, we may have freed more
> > object since we idled during i915_gem_suspend. Make sure we flush the
> > i915_gem_free_objects worker
== Series Details ==
Series: series starting with [1/2] drm/i915: Don't call
synchronize_rcu_expedited under struct_mutex
URL : https://patchwork.freedesktop.org/series/22652/
State : success
== Summary ==
Series 22652v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/se
On pe, 2017-04-07 at 11:25 +0100, Chris Wilson wrote:
> As we may have very many objects to free, check to see if the task needs
> to be rescheduled whilst freeing them.
>
> Suggested-by: Andrea Arcangeli
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
Regard
On pe, 2017-04-07 at 11:25 +0100, Chris Wilson wrote:
> Before freeing the next batch of objects from the worker, check if the
> worker's timeslice has expired and if so, defer the next batch to the
> next invocation of the worker.
>
> Suggested-by: Andrea Arcangeli
> Signed-off-by: Chris Wilson
On pe, 2017-04-07 at 11:25 +0100, Chris Wilson wrote:
> As we call into the shrinker during freeze, we may have freed more
> object since we idled during i915_gem_suspend. Make sure we flush the
> i915_gem_free_objects worker prior to saving the unwanted pages into the
> hibernation image.
>
> Sig
On pe, 2017-04-07 at 11:25 +0100, Chris Wilson wrote:
> The shrinker is prepared to be called unlock (and with struct_mutex held
> for DIRECT_RECLAIM) so we can skip acquiring the struct_mutex prior to
> calling the shrinking during freeze. This improves our ability to shrink
> as we can be more ag
On Thu, Apr 06, 2017 at 08:00:15AM -0700, Oscar Mateo wrote:
> There are some properties that logically belong to the engine class, and some
> that belong to the engine instance. Make it explicit.
>
> v2: Commit message (Tvrtko)
>
> v3:
> - Rebased
> - Exec/uabi id should be per instance (Chr
By using the same structure for both interruptible and
uninterruptible locking in shrinker code, combined with the
information that mm.interruptible is only being written to, the
code can be greatly simplified.
Also removing the i915_gem_ prefix from the locking functions so
that nobody in their w
Only call synchronize_rcu_expedited after unlocking struct_mutex to
avoid deadlock because the workqueues depend on struct_mutex.
From original patch by Andrea:
synchronize_rcu/synchronize_sched/synchronize_rcu_expedited() will
hang until its own workqueues are run. The i915 gem workqueues will
w
1 - 100 of 134 matches
Mail list logo
