On 07/08/17 09:14, Michal Wajdeczko wrote:
Flags bits are different in G2H message.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Oscar Mateo
Cc: Kelvin Gardiner
Matches GuC defines, so:
Reviewed-by: Daniele Ceraolo Spurio
-Daniele
---
drivers/gpu/drm/i915/intel_g
On 26 July 2017 at 14:25, Chris Wilson wrote:
> We use WC pages for coherent writes into the ppGTT on !llc
> architectuures. However, to create a WC page requires a stop_machine(),
architectures
> i.e. is very slow. To compensate we currently keep a per-vm cache of
> recently freed pages, but we
On 07/08/17 09:14, Michal Wajdeczko wrote:
During debug we may want to investigate all communication
from the Guc. Add proper tracing macros in debug config.
v2: convert remaining DRM_DEBUG into new CT_DEBUG (Michal)
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/intel_guc_ct.c |
On 7 August 2017 at 18:20, Lionel Landwerlin
wrote:
> We don't have flex eu counters on HSW, so don't try to program for
> thoses.
>
> Reported-by: CI \o/
> Fixes: 609cb5e30b4 ("tests/perf: add tests to verify create/destroy userspace
> configs")
> Signed-off-by: Lionel Landwerlin
Crumbs...
Rev
On Mon, 7 Aug 2017 08:11:43 +
"Zhang, Tina" wrote:
> After going through the previous discussions, here are some summaries may be
> related to the current discussion:
> 1. How does user mode figure the device capabilities between region and
> dma-buf?
> VFIO_DEVICE_GET_REGION_INFO could tel
On 8/7/2017 5:19 AM, Chris Wilson wrote:
During a global reset, we disable the irq. As we disable the irq, the
hardware may be raising a GT interrupt that we then ignore, leaving it
pending in the GTIIR. After the reset, we then re-enable the irq,
triggering the pending interrupt. However, that i
== Series Details ==
Series: tests/perf: fix userspace configs issues on HSW
URL : https://patchwork.freedesktop.org/series/28463/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
79d6f77fa1ff33f198d954a3c7f1028322fcce52 tests/perf: follow up build fix
with
On Thu, Aug 3, 2017 at 11:58 AM, Chris Wilson
wrote:
> From: Jason Ekstrand
>
> This commit adds support for waiting on or signaling DRM syncobjs as
> part of execbuf. It does so by hijacking the currently unused cliprects
> pointer to instead point to an array of i915_gem_exec_fence structs
>
We don't have flex eu counters on HSW, so don't try to program for
thoses.
Reported-by: CI \o/
Fixes: 609cb5e30b4 ("tests/perf: add tests to verify create/destroy userspace
configs")
Signed-off-by: Lionel Landwerlin
---
tests/perf.c | 29 ++---
1 file changed, 18 inserti
On Mon, Aug 07, 2017 at 08:55:00AM -0700, Jim Bride wrote:
> On Fri, Aug 04, 2017 at 10:29:33AM +0300, Jani Nikula wrote:
> > On Thu, 03 Aug 2017, Jim Bride wrote:
> > > On Fri, Jul 14, 2017 at 12:34:28PM +0300, Jani Nikula wrote:
> > >> On Wed, 12 Jul 2017, Chris Wilson wrote:
> > >> > Quoting D
On 8/7/2017 9:14 AM, Michal Wajdeczko wrote:
GuC may return additional data in the command status response.
Format and meaning of this data is action specific.
We will use this non-negative data as a new success return value.
Currently used actions don't return data that way yet.
v2: fix prohibi
== Series Details ==
Series: drm/i915/renderstate: Sandybridge golden renderstate is b0rked
URL : https://patchwork.freedesktop.org/series/28461/
State : success
== Summary ==
Series 28461v1 drm/i915/renderstate: Sandybridge golden renderstate is b0rked
https://patchwork.freedesktop.org/api/1.
On 8/7/2017 8:33 AM, Daniel Vetter wrote:
On Thu, Aug 03, 2017 at 12:44:40PM -0700, Michel Thierry wrote:
On 7/20/2017 10:57 AM, Daniel Vetter wrote:
Blocking in a worker is ok, that's what the unbound_wq is for. And it
unifies the paths between the blocking and nonblocking commit, giving
me ju
good idea.
On Mon, Aug 7, 2017 at 9:10 AM, Daniel Vetter wrote:
> On Fri, Aug 04, 2017 at 01:38:36PM +0300, Jani Nikula wrote:
>> This is not to try to force a new style; this is my interpretation of
>> what the most common existing style is.
>>
>> With hopes I don't need to answer so many quest
In the null state batch, we try to load the CC_STATE_POINTERS, but pass
in a pointer to invalid state for the color-calc and depth-stencil
state. In the rendercopy batch this was imported from, the 1024 offset
used is known to be 64bytes of zeroes. Tweaking the
gen6_null_state_batch to point those
== Series Details ==
Series: drm/i915/guc: Support for Guc responses and requests
URL : https://patchwork.freedesktop.org/series/28393/
State : failure
== Summary ==
Series 28393v1 drm/i915/guc: Support for Guc responses and requests
https://patchwork.freedesktop.org/api/1.0/series/28393/revis
Quoting Daniel Vetter (2017-08-07 17:26:56)
> On Fri, Aug 04, 2017 at 06:05:10PM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2017-08-04 17:07:22)
> > > We now have full (or a lot at least) igt running in beta CI, and snb
> > > blt hangs are really unhappy:
> > >
> > > - drv_hangman@error
On Fri, Aug 04, 2017 at 06:05:10PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2017-08-04 17:07:22)
> > We now have full (or a lot at least) igt running in beta CI, and snb
> > blt hangs are really unhappy:
> >
> > - drv_hangman@error-state-capture-blt and gem_exec_capture@capture-blt
> >
On Mon, Aug 07, 2017 at 12:43:58PM +0100, Chris Wilson wrote:
> This was supposed to be a mask of all known rings, but it is being used
> by execbuffer to filter out invalid rings, and so is instead mapping high
> unused values onto valid rings. Instead of a mask of all known rings,
> we need it to
On Fri, Aug 04, 2017 at 11:23:18AM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Current 50ms max threshold timing for an EDID read is very close to the
> actual time for a 2 block HDMI EDID read of 48ms. Any delay like a clock
> stretch by the EDID eeprom will cause this test
On Fri, Aug 04, 2017 at 03:30:30PM -0300, Paulo Zanoni wrote:
> Em Sex, 2017-08-04 às 18:21 +0200, Daniel Vetter escreveu:
> > I guess this was done to have a better indication of which testcase
> > and function failed, but igt nowadays dumps an entire stacktrace.
>
> But we may have multiple do_a
This is just for CI testing, *** DO NOT MERGE ***
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 14e2c2e..4a4c378 100
GuC may return not only small data encoded in the status dword,
but can also append additional data into the response message.
We will copy this extra data into provided buffer, and use
number of received data dwords as new success return value.
v2: fix timeout and checkpatch warnings (Michal)
Si
During debug we may want to investigate all communication
from the Guc. Add proper tracing macros in debug config.
v2: convert remaining DRM_DEBUG into new CT_DEBUG (Michal)
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/intel_guc_ct.c | 41 +++--
1 fil
With enabled CT, instead of programming SCRATCH 15 register with the
Guc to host message, Guc will send us unsolicited CT message.
Content of the first payload dword of this request has the same
format as data expected in the above scratch register.
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
We will need them in G2H communication to properly handle
responses and requests from the Guc.
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Cc: Daniele Ceraolo Spurio
Cc: Michel Thierry
---
drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
drivers/gpu/drm/i915/intel_uc.c| 2 +-
Requests are read from CT in the irq handler, but actual processing
will be done in the work thread. Processing of specific actions will
be added in the upcoming patches.
v2: don't use GEM_BUG_ON (Chris)
don't kmalloc too large buffer (Michal)
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
From: Oscar Mateo
This function, symmetrical to the send(), will handle Guc2Host message
interrupts (which at the moment still only covers requests to flush
the GuC logs).
Cc: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Signed-off-by: Oscar Mateo
Signed-off-by: Michal Wajdeczko
---
drivers/
GuC can respond to our commands not only by updating SEND buffer
descriptor, but can send us message over RECV buffer. Additionally
Guc can also send us unsolicited requests over RECV buffer.
Lets start reading those messages and make placeholders for actual
response/request handlers.
v2: misc imp
In next patch we will introduce another way of waiting for the response
that will use RECV buffer. To avoid misleading names, rename old wait
function to reflect the fact that it is based on descriptor update.
v2: fix comment style (Michal)
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i9
To allow future code reuse. While here, fix comment style.
Suggested-by: Oscar Mateo
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Cc: Sagar Arun Kamble
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_irq.c | 33 ++---
drivers/gpu/drm/i915/intel_uc.c |
Flags bits are different in G2H message.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Oscar Mateo
Cc: Kelvin Gardiner
---
drivers/gpu/drm/i915/intel_guc_fwif.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif
From: Oscar Mateo
To allow future code reuse.
Cc: Sagar Arun Kamble
Cc: Daniele Ceraolo Spurio
Signed-off-by: Oscar Mateo
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/intel_guc_log.c | 8
drivers/gpu/drm/i915/intel_uc.c | 6 +-
drivers/gpu/drm/i915/intel_uc.h
In addition to already returned small data encoded in the status MMIO,
GuC may write more additional data in remaining MMIO regs. Lets copy
all that regs into optionally provided response buffer.
v2: new line (Michel)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Oscar Mateo
R
In the previous patch we have changed signature of the send function
pointer but we didn't modify signature of the corresponding helper
function to minimize number of required changes. Let's add separate
helper to expose new functionality but still hide underlying details.
v2: enforce response buf
This is a preparation step for the upcoming patches.
We already can return some small data decoded from the command
status, but we will need more in the future.
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Daniele Ceraolo Spurio
Reviewed-by: Michel Thierry
---
drive
With this series we will be able to receive more data from the Guc.
New Guc firmware will be required to actually use that feature.
v2: misc improvements after review + HAX
Michal Wajdeczko (14):
drm/i915/guc: Add support for data reporting in GuC responses
drm/i915/guc: Prepare send() functi
GuC may return additional data in the command status response.
Format and meaning of this data is action specific.
We will use this non-negative data as a new success return value.
Currently used actions don't return data that way yet.
v2: fix prohibited space after '~' (Michel)
update commit
On Fri, Aug 04, 2017 at 03:03:48PM +0100, Lionel Landwerlin wrote:
> This function is not part of the driver anymore.
>
> Signed-off-by: Lionel Landwerlin
Fixes: 90f4fcd56bda ("drm/i915: Remove forced stop ring on suspend/unload")
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_l
On Fri, Aug 04, 2017 at 01:38:36PM +0300, Jani Nikula wrote:
> This is not to try to force a new style; this is my interpretation of
> what the most common existing style is.
>
> With hopes I don't need to answer so many questions about style going
> forward.
>
> Cc: Daniel Vetter
> Signed-off-b
On Fri, Aug 04, 2017 at 06:38:02PM +, Pandiyan, Dhinakaran wrote:
>
>
>
> On Thu, 2017-08-03 at 11:07 -0700, Rodrigo Vivi wrote:
> > On Tue, Jul 18, 2017 at 2:34 PM, Jim Bride
> > wrote:
> > > According to the eDP spec, when the count field in TEST_SINK_MISC
> > > increments then the six b
On Fri, Aug 04, 2017 at 10:29:33AM +0300, Jani Nikula wrote:
> On Thu, 03 Aug 2017, Jim Bride wrote:
> > On Fri, Jul 14, 2017 at 12:34:28PM +0300, Jani Nikula wrote:
> >> On Wed, 12 Jul 2017, Chris Wilson wrote:
> >> > Quoting Dhinakaran Pandiyan (2017-07-12 09:47:25)
> >> >> On Tuesday, July 11,
On Fri, Aug 04, 2017 at 07:56:11AM -0700, Jason Ekstrand wrote:
> On August 4, 2017 2:59:56 AM Daniel Stone wrote:
>
> > Hi Jason,
> >
> > On 4 August 2017 at 01:52, Jason Ekstrand wrote:
> > > Previously, the test used the old 64x64 convention that Ville introduced
> > > for CCS tiles and not
On Fri, Aug 04, 2017 at 09:43:41AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> To the best of my recollection the page flipping test was added
> simply to start exercising page flips with 90/270 rotation.
>
> There is no need to do 60 flips which can take quite some time,
> because w
On Mon, Aug 07, 2017 at 10:59:55AM +0100, Chris Wilson wrote:
> Quoting Maarten Lankhorst (2017-08-07 10:45:38)
> > Op 04-08-17 om 09:50 schreef Chris Wilson:
> > > Quoting Maarten Lankhorst (2017-08-02 11:29:17)
> > >> Export 2 functions, igt_signal_helper_get_num and
> > >> igt_signal_helper_get_
On Thu, Aug 03, 2017 at 12:35:48PM -0700, Michel Thierry wrote:
> Hi,
>
> First sorry about the delay...
>
> On 7/20/2017 10:57 AM, Daniel Vetter wrote:
> > There's no reason to entirely wedge the gpu, for the minimal deadlock
> > bugfix we only need to unbreak/decouple the atomic commit from the
On Thu, Aug 03, 2017 at 12:44:40PM -0700, Michel Thierry wrote:
> On 7/20/2017 10:57 AM, Daniel Vetter wrote:
> > Blocking in a worker is ok, that's what the unbound_wq is for. And it
> > unifies the paths between the blocking and nonblocking commit, giving
> > me just one path where I have to impl
Em Seg, 2017-08-07 às 06:51 +, Lofstedt, Marta escreveu:
> > -Original Message-
> > From: Zanoni, Paulo R
> > Sent: Friday, August 4, 2017 9:56 PM
> > To: Lofstedt, Marta ; intel-
> > g...@lists.freedesktop.org
> > Cc: Latvala, Petri
> > Subject: Re: [PATCH i-g-t] tests/kms_frontbuffer
Chris Wilson writes:
> The idea behind using an illegal instruction was to hang the GPU must
> faster than simply using the recursive batch. However, we stopped doing
> so on gen8+ as the CS parser was much laxer and allowed the illegal
> command through but still interpreted the packet length (j
== Series Details ==
Series: series starting with [Intel-gfx,1/2] igt/gem_exec_capture: Wait for
batch to execute before triggering reset
URL : https://patchwork.freedesktop.org/series/28452/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
79d6f77fa1ff33f19
== Series Details ==
Series: drm/i915: Clear lost context-switch interrupts across reset
URL : https://patchwork.freedesktop.org/series/28450/
State : success
== Summary ==
Series 28450v1 drm/i915: Clear lost context-switch interrupts across reset
https://patchwork.freedesktop.org/api/1.0/seri
The idea behind using an illegal instruction was to hang the GPU must
faster than simply using the recursive batch. However, we stopped doing
so on gen8+ as the CS parser was much laxer and allowed the illegal
command through but still interpreted the packet length (jumping over
the recursive batch
Signed-off-by: Chris Wilson
---
tests/gem_exec_capture.c | 65
1 file changed, 49 insertions(+), 16 deletions(-)
diff --git a/tests/gem_exec_capture.c b/tests/gem_exec_capture.c
index f8f43d29..a73ece5d 100644
--- a/tests/gem_exec_capture.c
+++ b/
Signed-off-by: Petri Latvala
---
tools/intel_gpu_top.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 7848876..3fe77f7 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -513,7 +513,7 @@ int main(int argc, cha
During a global reset, we disable the irq. As we disable the irq, the
hardware may be raising a GT interrupt that we then ignore, leaving it
pending in the GTIIR. After the reset, we then re-enable the irq,
triggering the pending interrupt. However, that interrupt was for the
stale state from befor
== Series Details ==
Series: drm/i915: Convert gen4- watermarks to atomic. (rev2)
URL : https://patchwork.freedesktop.org/series/23954/
State : failure
== Summary ==
Series 23954v2 drm/i915: Convert gen4- watermarks to atomic.
https://patchwork.freedesktop.org/api/1.0/series/23954/revisions/2/
This was supposed to be a mask of all known rings, but it is being used
by execbuffer to filter out invalid rings, and so is instead mapping high
unused values onto valid rings. Instead of a mask of all known rings,
we need it to be the mask of all possible rings.
Fixes: 549f7365820a ("drm/i915: E
On Wed, Aug 02, 2017 at 07:54:17PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Signed-off-by: Gustavo Padovan
Reviewed-by: Arkadiusz Hiler
and pushed, thanks!
--
Cheers,
Arek
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Monday, August 7, 2017 7:13 PM
> To: Dong, Chuanxiao ; intel-
> g...@lists.freedesktop.org; Joonas Lahtinen
>
> Subject: RE: a potential dead loop in intel_lrc_irq_handler
>
> Quoting Dong, Chuanxiao (2017
On Fri, Aug 04, 2017 at 04:38:51PM +0200, Daniel Vetter wrote:
> Some distros have huge rlimits and then the test takes forever, or
> worse oom, or even worse, takse down the entire machine (which is
> shouldn't be able to, but oh well, oom handling in linux).
>
> Make sure we have a consistent rl
Quoting Dong, Chuanxiao (2017-08-07 11:31:57)
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > GPU reset -> clears CSB head/tail
> But the GPU reset will make CSB_head = 0 and CSB_tail = 7.
Experience says otherwise, but the issue of the delayed interrupt
We're already calculating the watermarks correctly, now we have to
program them too.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_pm.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/
The gen3 watermark calculations are converted to atomic,
but the wm update calls are still done through the legacy
functions.
This will make it easier to bisect things if they go wrong.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 3 +-
drivers/gpu/drm/i915/inte
Pineview seems to have different watermarks from the other
platforms and are calculated separately.
With the change to atomic, cxsr is automatically disabled for
intermediate watermarks when required. This will fix
fd.org bug #101597 as a nice side effect.
Changes since v1:
- Fix deadlock in pnv_
With the atomic watermark calculations calculate intermediary watermark
values and update the watermarks atomically.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.h | 5 ++
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 103 +
Gen4 watermark is handled same as gen3-. Calculate
the optimal watermarks atomically first, and program
it in the legacy helper.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_pm.c | 136
1 file changed, 95 insertions(+), 41 deletions(-)
Use crtc->active directly instead. This is still not completely
optimal and needs fixing, but it's about as good as using
intel_crtc_active.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 19 ---
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gp
The legacy watermark infrastructure is now unused, so remove it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_atomic.c | 2 -
drivers/gpu/drm/i915/intel_display.c | 74 ++--
drivers/gpu/drm/i915/int
Calculate watermarks for gen4 and lower atomically. This has been tested
on the pineview system in CI. It fixes bug 101597, which is a vblank wait
timed out when running kms_pipe_crc_basic. The changes to CXSR will allow
the test to pass.
Maarten Lankhorst (7):
drm/i915: Calculate gen3- watermar
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Monday, August 7, 2017 5:56 PM
> To: Dong, Chuanxiao ; intel-
> g...@lists.freedesktop.org; Joonas Lahtinen
>
> Subject: Re: a potential dead loop in intel_lrc_irq_handler
>
> Quoting Dong, Chuanxiao (2017
Quoting Maarten Lankhorst (2017-08-07 10:45:38)
> Op 04-08-17 om 09:50 schreef Chris Wilson:
> > Quoting Maarten Lankhorst (2017-08-02 11:29:17)
> >> Export 2 functions, igt_signal_helper_get_num and
> >> igt_signal_helper_get_hz.
> >>
> >> This will allow tests to measure how much time in a test w
Quoting Dong, Chuanxiao (2017-08-07 10:41:29)
> Hello,
>
> Found there might be a corner case for intel_lrc_irq_handler() in a dead
> loop, want to understand if this can be real or not.
>
> The scenario is like:
> 1. Write wedged to trigger a GPU reset;
This is dangerous full stop, but even w
Op 04-08-17 om 09:50 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2017-08-02 11:29:17)
>> Export 2 functions, igt_signal_helper_get_num and
>> igt_signal_helper_get_hz.
>>
>> This will allow tests to measure how much time in a test was spent
>> in a uninterruptible state, which is useful when
Hello,
Found there might be a corner case for intel_lrc_irq_handler() in a dead loop,
want to understand if this can be real or not.
The scenario is like:
1. Write wedged to trigger a GPU reset;
2. meanwhile, there is one ongoing request in port[0], and its context switch
interrupt is generated
On Fri, Aug 04, 2017 at 09:23:28AM +0100, Chris Wilson wrote:
> After an event is sent, we try to copy it into the user buffer of the
> first waiter in drm_read() and if the user buffer doesn't have enough
> room we put it back onto the list. However, we didn't wake up any
> subsequent waiter, so t
On Thu, Aug 3, 2017 at 5:52 PM, Cihangir Akturk wrote:
> On Thu, Aug 03, 2017 at 02:49:03PM +0200, Daniel Vetter wrote:
>> On Thu, Aug 03, 2017 at 03:26:01PM +0300, Jani Nikula wrote:
>> > On Thu, 03 Aug 2017, Cihangir Akturk wrote:
>> > > drm_*_reference() and drm_*_unreference() functions are j
After about a month and a few attempts it's clear that my rr-cache gc
logic is busted. When copying stuff back&forth between the git branch
and git's rr-cache dir, something somewhere (or maybe it's git rerere
itself) touches all files and wreaks the timestamps.
End result is that over this month,
On Thu, Aug 3, 2017 at 2:44 PM, Jani Nikula wrote:
> On Thu, 27 Jul 2017, Daniel Vetter wrote:
>> It's a bit silly to have to spec both -d and -f to see what dim would
>> all complain about. And dry-run should never cause bad side-effects.
>
> Ack.
>
> We don't do dry-run all that well in general
On Mon, 07 Aug 2017, Zhenyu Wang wrote:
> Hi, this is gvt fixes for 4.13-rc5, there're two regression fixes for
> MMIO handle 65f9f6febf12, and two important vGPU reset fixes.
Pulled to drm-intel-fixes, thanks.
BR,
Jani.
>
> Thanks
> --
> The following changes since commit 26a201a2ba82a801973ce
Op 04-08-17 om 09:50 schreef Mika Kahola:
> On Wed, 2017-08-02 at 12:29 +0200, Maarten Lankhorst wrote:
>> To make sure that we have test exposure when allowing atomic ioctl's
>> to
>> fail interruptibly, we add a test that will fail to lock the
>> mutexes until the fence is signaled.
>>
>> If the
Op 04-08-17 om 10:07 schreef Mika Kahola:
> On Wed, 2017-08-02 at 12:29 +0200, Maarten Lankhorst wrote:
>> With the conversion to atomic, this is already handled in the core.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> lib/igt_kms.c | 15 ---
>> lib/igt_kms.h | 1 -
>> 2 files c
On ti, 2017-07-25 at 17:28 +0800, Tina Zhang wrote:
> GEM proxy is a kind of GEM, whose backing physical memory is pinned
> and produced by guest VM and is used by host as read only. With GEM
> proxy, host is able to access guest physical memory through GEM object
> interface. As GEM proxy is such
After going through the previous discussions, here are some summaries may be
related to the current discussion:
1. How does user mode figure the device capabilities between region and dma-buf?
VFIO_DEVICE_GET_REGION_INFO could tell if the mdev supports region case.
Otherwise, the mdev supports dm
Hi, this is gvt fixes for 4.13-rc5, there're two regression fixes for
MMIO handle 65f9f6febf12, and two important vGPU reset fixes.
Thanks
--
The following changes since commit 26a201a2ba82a801973ce29e1004b64742e81e7e:
drm/i915/gvt: Extend KBL platform support in GVT-g (2017-07-25 12:39:41 +08
84 matches
Mail list logo
