On Tue, 21 Feb 2017, Chris Wilson wrote:
> On Tue, Feb 21, 2017 at 06:40:25PM +0200, Jani Nikula wrote:
>> Sometimes it would be most enlightening to debug systems by replacing
>> the VBT to be used. For example, in the referenced bug the BIOS provides
>> different VBT depending on the boot mode (
> -Original Message-
> From: Deak, Imre
> Sent: Wednesday, February 22, 2017 3:54 PM
> To: Li, Weinan Z
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: check status and reply value both
> in skl_pcode_try_request()
>
[Your MUA messed up the quoting, FTFY below.]
On Wed, 22 Feb 2017, "Navare, Manasi D" wrote:
> > On Fri, 17 Feb 2017, Manasi Navare wrote:
> >> Display stream compression is supported on DP 1.4 DP devices. This
> >> patch adds the corersponding DPCD register definitions for DSC.
> >>
> >> v2:
On 21/02/2017 15:01, Joonas Lahtinen wrote:
On pe, 2017-02-17 at 15:10 +, Chris Wilson wrote:
The object already stores (computed on the fly) the index to dma address
so use it instead of reallocating a large temporary array every time we
bind a rotated framebuffer.
Signed-off-by: Chris Wi
On Wed, Feb 22, 2017 at 08:29:06AM +, Tvrtko Ursulin wrote:
>
> On 21/02/2017 15:01, Joonas Lahtinen wrote:
> >On pe, 2017-02-17 at 15:10 +, Chris Wilson wrote:
> >>The object already stores (computed on the fly) the index to dma address
> >>so use it instead of reallocating a large tempor
On Wed, Feb 22, 2017 at 10:15:12AM +0200, Jani Nikula wrote:
> On Tue, 21 Feb 2017, Chris Wilson wrote:
> > On Tue, Feb 21, 2017 at 06:40:25PM +0200, Jani Nikula wrote:
> >> Sometimes it would be most enlightening to debug systems by replacing
> >> the VBT to be used. For example, in the reference
On Wed, Feb 22, 2017 at 10:17:21AM +0200, Li, Weinan Z wrote:
> > -Original Message-
> > From: Deak, Imre
> > Sent: Wednesday, February 22, 2017 3:54 PM
> > To: Li, Weinan Z
> > Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] dr
On Wed, Feb 22, 2017 at 07:52:01AM +, Tvrtko Ursulin wrote:
>
> On 21/02/2017 18:48, Imre Deak wrote:
> >On Tue, Feb 21, 2017 at 05:01:58PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>Elevate task scheduling policy to realtime when polling on PCODE
> >>to guarantee a good p
For use in the next patch, take the current is-coherent helper and add
it to i915_gem_object.h
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/i915_gem.c | 20 ++--
2 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/
Generalise the skip for physical and stolen objects by skipping anything
we do not have a valid address for inside the sg.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drive
The change_domain tracepoint has been inaccurate for a few years - it
doesn't fully capture the domains, especially with userspace bypassing
them. It is defunct, misleading and time to be removed.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c| 30 ---
Setting retire=true is identical to using origin=ORIGIN_CS, so make the
same simplification for intel_fb_obj_flush() as already employed for
intel_fb_obj_invalidate().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 12 ++--
drivers/gpu/drm/i915/i915_gem_clflus
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c| 41 +-
drivers/gpu/drm/i915/i915_gem_object.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 9 ++--
3 files changed, 30 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i9
Flushing the cachelines for an object is slow, can be as much as 100ms
for a large framebuffer. We currently do this under the struct_mutex BKL
on execution or on pageflip. But now with the ability to add fences to
obj->resv for both flips and execbuf (and we naturally wait on the fence
before CPU
On Wed, Feb 22, 2017 at 09:41:18AM +, Chris Wilson wrote:
Reason goes here.
We have three different paths by which userspace wants to flush the
display plane (i.e. objects with obj->pin_display). Use a common helper
to identify those paths and to simplify a later change.
-Chris
--
Chris Wil
From: Tvrtko Ursulin
Given a log file created via perf with some interesting trace
events enabled, this tool can generate the timeline graph of
requests getting queued, their dependencies resolved, sent to
the GPU for executing and finally completed.
This can be useful when analyzing certain cla
On Tue, 21 Feb 2017, Chris Wilson wrote:
> Handling the dynamic charp module parameter requires us to copy it for
> the error state, or remember to lock it when reading (in case it used
> with 0600).
>
> v2: Use __always_inline and __builtin_strcmp
>
> Signed-off-by: Chris Wilson
> Reviewed-by: J
On Wed, Feb 22, 2017 at 10:03:33AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Given a log file created via perf with some interesting trace
> events enabled, this tool can generate the timeline graph of
> requests getting queued, their dependencies resolved, sent to
> the GPU for exe
On Wed, Feb 22, 2017 at 12:06:35PM +0200, Jani Nikula wrote:
> On Tue, 21 Feb 2017, Chris Wilson wrote:
> > Handling the dynamic charp module parameter requires us to copy it for
> > the error state, or remember to lock it when reading (in case it used
> > with 0600).
> >
> > v2: Use __always_inli
On Thu, Feb 16, 2017 at 07:35:59AM +, Chris Wilson wrote:
> On Thu, Feb 16, 2017 at 02:36:40PM +0800, Chuanxiao Dong wrote:
> > When not using GuC submission, the ring buffer size for GVT context is
> > 512KB which is the max size. When switching to GuC submission, the ring
> > buffer size is r
For our fake dma objects we can leak the underlying gem object if we
fail to pin our "backing storage".
[ 39.952618]
=
[ 39.952625] BUG mock_object (Tainted: G U ): Objects remaining
in mock_object on __k
== Series Details ==
Series: series starting with [v3,1/6] drm/i915: Remove change_domain tracepoint
URL : https://patchwork.freedesktop.org/series/20047/
State : success
== Summary ==
Series 20047v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20047/revisions/1
Geminilake has a third sprite plane (or fourth universal plane) that is
independent from the cursor. Make sure that for_each_plane_id_on_crtc()
is aware of that extra plane so that the watermark code takes it into
account.
Fixes: e9c9882556fc ("drm/i915/glk: Configure number of sprite planes prope
Geminilake can output two pixels per clock, and that affects the maximum
scaling factor for its scalers. Take that into account and avoid the
following warning:
WARNING: CPU: 1 PID: 593 at drivers/gpu/drm/i915/intel_display.c:13223
skl_max_scale.part.129+0x78/0x80 [i915]
WARN_ON_ONCE(!crtc_clock
On ke, 2017-02-22 at 10:11 +, Chris Wilson wrote:
> On Wed, Feb 22, 2017 at 12:06:35PM +0200, Jani Nikula wrote:
> >
> > > > On Tue, 21 Feb 2017, Chris Wilson wrote:
> > >
> > > Handling the dynamic charp module parameter requires us to copy it for
> > > the error state, or remember to lock
Geminilake scalers can do 7x7 filtering for all supported input sizes,
so it doesn't need the "high quality" mode programming, which was
actually removed from that platform.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_atomic.c | 14 --
drivers/gpu/drm/
A few fixes to the plane and scaling code for Geminilake.
Ander Conselvan de Oliveira (3):
drm/i915/glk: Fix watermark computations for third sprite plane
drm/i915/glk: Fix maximum scaling factor for Geminilake scalers
drm/i915/glk: Fix Geminilake scalers mode programming
drivers/gpu/drm/i
On ke, 2017-02-22 at 09:41 +, Chris Wilson wrote:
> The change_domain tracepoint has been inaccurate for a few years - it
> doesn't fully capture the domains, especially with userspace bypassing
> them. It is defunct, misleading and time to be removed.
>
> Signed-off-by: Chris Wilson
Reviewe
On Wed, 22 Feb 2017, Chris Wilson wrote:
> On Wed, Feb 22, 2017 at 12:06:35PM +0200, Jani Nikula wrote:
>> On Tue, 21 Feb 2017, Chris Wilson wrote:
>> > Handling the dynamic charp module parameter requires us to copy it for
>> > the error state, or remember to lock it when reading (in case it use
On Wed, Feb 22, 2017 at 12:29:11PM +0200, Joonas Lahtinen wrote:
> On ke, 2017-02-22 at 10:11 +, Chris Wilson wrote:
> > On Wed, Feb 22, 2017 at 12:06:35PM +0200, Jani Nikula wrote:
> > >
> > > > > On Tue, 21 Feb 2017, Chris Wilson wrote:
> > > >
> > > > Handling the dynamic charp module par
On Wed, Feb 22, 2017 at 12:30:38PM +0200, Jani Nikula wrote:
> On Wed, 22 Feb 2017, Chris Wilson wrote:
> > On Wed, Feb 22, 2017 at 12:06:35PM +0200, Jani Nikula wrote:
> >> On Tue, 21 Feb 2017, Chris Wilson wrote:
> >> > Handling the dynamic charp module parameter requires us to copy it for
> >>
== Series Details ==
Series: drm/i915/selftests: don't leak the gem object
URL : https://patchwork.freedesktop.org/series/20050/
State : success
== Summary ==
Series 20050v1 drm/i915/selftests: don't leak the gem object
https://patchwork.freedesktop.org/api/1.0/series/20050/revisions/1/mbox/
Add the message from your reply.
On ke, 2017-02-22 at 09:41 +, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> @@ -1613,23 +1613,16 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void
> *data,
> {
> struct drm_i915_gem_sw_finish *args = data;
> struct drm_i915_gem_ob
On ke, 2017-02-22 at 09:41 +, Chris Wilson wrote:
> Flushing the cachelines for an object is slow, can be as much as 100ms
> for a large framebuffer. We currently do this under the struct_mutex BKL
> on execution or on pageflip. But now with the ability to add fences to
> obj->resv for both fli
On ke, 2017-02-22 at 09:41 +, Chris Wilson wrote:
> For use in the next patch, take the current is-coherent helper and add
> it to i915_gem_object.h
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporat
On Wed, Feb 22, 2017 at 10:52:24AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/selftests: don't leak the gem object
> URL : https://patchwork.freedesktop.org/series/20050/
> State : success
>
> == Summary ==
>
> Series 20050v1 drm/i915/selftests: don't leak the gem obje
On ke, 2017-02-22 at 09:41 +, Chris Wilson wrote:
> Setting retire=true is identical to using origin=ORIGIN_CS, so make the
> same simplification for intel_fb_obj_flush() as already employed for
> intel_fb_obj_invalidate().
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regar
On ma, 2017-02-20 at 14:34 -0800, Ceraolo Spurio, Daniele wrote:
>
> On 2/17/2017 3:43 PM, Kelvin Gardiner wrote:
> >
> > The reply bit of the ring mode register is only valid on Gen 8.
>
> s/reply/replay. Also, from the specs it looks like this bit is reserved
> in Gen8 production steppings, s
On ma, 2017-02-20 at 12:47 +, Chris Wilson wrote:
> Testing with concurrent GGTT accesses no longer show the coherency
> problems from yonder, commit 5bab6f60cb4d ("drm/i915: Serialise updates
> to GGTT with access through GGTT on Braswell"). My presumption is that
> the root cause was more lik
On Wed, Feb 22, 2017 at 01:27:41PM +0200, Joonas Lahtinen wrote:
> On ma, 2017-02-20 at 12:47 +, Chris Wilson wrote:
> > Testing with concurrent GGTT accesses no longer show the coherency
> > problems from yonder, commit 5bab6f60cb4d ("drm/i915: Serialise updates
> > to GGTT with access through
Flushing the cachelines for an object is slow, can be as much as 100ms
for a large framebuffer. We currently do this under the struct_mutex BKL
on execution or on pageflip. But now with the ability to add fences to
obj->resv for both flips and execbuf (and we naturally wait on the fence
before CPU
Setting retire=true is identical to using origin=ORIGIN_CS, so make the
same simplification to intel_fb_obj_flush() as already employed for
intel_fb_obj_invalidate().
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 12 ++--
drivers
Generalise the skip for physical and stolen objects by skipping anything
we do not have a valid address for inside the sg.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drive
The change_domain tracepoint has been inaccurate for a few years - it
doesn't fully capture the domains, especially with userspace bypassing
them. It is defunct, misleading and time to be removed.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c
For use in the next patch, take the current is-coherent helper and add
it to i915_gem_object.h
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/i915_gem.c | 20 ++--
2 files changed, 12 insertions(+),
We have three different paths by which userspace wants to flush the
display plane (i.e. objects with obj->pin_display). Use a common helper
to identify those paths and to simplify a later change.
v2: Include the conditional in the name, i915_gem_object_flush_if_display
Signed-off-by: Chris Wilson
Hi,
Seems like there were couple too many steps away from "just reordering
code", and indeed it's not working with GuC enabled, so have to spend
some time to see why.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
__
Same seqno series as before addressing comments last time and adding r-b
where given. Functionally the same as before, but I would like to land
this soonish as it eliminates one debugging BUG_ON that CI keeps
hitting, though I am pretty sure that is just a datarace...
-Chris
__
It had only one callsite and existed to keep the code clearer. Now
having shared the wait-on-error between phases and with plans to change
the wait-for-execute in the next few patches, remove the out of line
wait loop and move it into the main body of i915_wait_request.
Signed-off-by: Chris Wilson
Move the companion functions next to each other.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 161 +++-
1 file changed, 77 insertions(+), 84 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_ge
Replace the global device seqno with one for each engine, and account
for in-flight seqno on each separately. This is consistent with
dma-fence as each timeline has separate fence-contexts for each engine
and a seqno is only ordered within a fence-context (i.e. seqno do not
need to be ordered wrt
On reflection, we are only using the execute fence as a waitqueue on the
global_seqno and not using it for dependency tracking between fences
(unlike the submit and dma fences). By only treating it as a waitqueue,
we can then treat it similar to the other waitqueues during submit,
making the code s
Add ourselves to the gpu error waitqueue earlier on, even before we
determine we have to wait on the seqno. This is so that we can then
share the waitqueue between stages in subsequent patches.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu
A request is assigned a global seqno only when it is on the hardware
execution queue. The global seqno can be used to maintain a list of
requests on the same engine in retirement order, for example for
constructing a priority queue for waiting. Prior to its execution, or
if it is subsequently remov
Use a local variable to avoid having to type out the full name of the
gpu_error wait_queue.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_request.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
The plan in the near-future is to allow requests to be removed from the
signaler. We can no longer then rely on holding a reference to the
request for the duration it is in the signaling tree, and instead must
obtain a reference to the request for the current operation using RCU.
Signed-off-by: Ch
If we preempt a request and remove it from the execution queue, we need
to undo its global seqno and restart any waiters.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 71 +---
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
2 files chang
Add a mock selftest to preempt a request and check that we cancel it,
requeue the request and then complete its execution.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/i915_gem_request.c | 59 +++
drivers/gpu/drm/i915/selftests/mock_request.c | 19 ++
As we handoff the GPU reset to the waiter, we need to check we don't
miss a wakeup if it has already been sent prior to us starting the wait.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers
Now that the code is getting simpler, we can reduce the indentation when
waiting for the global_seqno.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 41 +++--
1 file changed, 18 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i
If we change the wait_queue_t from using the autoremove_wake_function to
the default_wake_function, we no longer have to restore the wait_queue_t
entry on the wait_queue_head_t list after being woken up by it, as we
are unusual in sleeping multiple times on the same wait_queue_t.
Signed-off-by: Ch
After the request is cancelled, we then need to remove it from the
global execution timeline and return it to the context timeline, the
inverse of submit_request().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c| 58 +-
drivers/gpu/drm/i91
Combine the common code for the pair of waiters into a single function.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i9
Op 21-02-17 om 16:23 schreef Patchwork:
> == Series Details ==
>
> Series: drm/atomic: Make drm_framebuffer_remove atomic, again.
> URL : https://patchwork.freedesktop.org/series/20008/
> State : failure
>
> == Summary ==
>
> Series 20008v1 drm/atomic: Make drm_framebuffer_remove atomic, again.
>
On Wed, 2017-02-22 at 10:10 +, Chris Wilson wrote:
> On Wed, Feb 22, 2017 at 10:03:33AM +, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Given a log file created via perf with some interesting trace
> > events enabled, this tool can generate the timeline graph of
> > requests get
On Tue, Feb 21, 2017 at 06:22:02PM +, Chris Wilson wrote:
> On Baytrail, we manually calculate busyness over the evaluation interval
> to avoid issues with miscaluations with RC6 enabled. However, it turns
> out that the DOWN_EI interrupt generator is completely bust - it
> operates in two mode
On Baytrail, we manually calculate busyness over the evaluation interval
to avoid issues with miscaluations with RC6 enabled. However, it turns
out that the DOWN_EI interrupt generator is completely bust - it
operates in two modes, continuous or never. Neither of which are
conducive to good behavio
== Series Details ==
Series: GLK plane/scaling fixes
URL : https://patchwork.freedesktop.org/series/20051/
State : success
== Summary ==
Series 20051v1 GLK plane/scaling fixes
https://patchwork.freedesktop.org/api/1.0/series/20051/revisions/1/mbox/
fi-bdw-5557u total:253 pass:242 dwarn:
Patch title s/reeerve/reserve/.
On ke, 2017-02-22 at 11:45 +, Chris Wilson wrote:
> Move the companion functions next to each other.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
On 22/02/2017 11:45, Chris Wilson wrote:
Replace the global device seqno with one for each engine, and account
for in-flight seqno on each separately. This is consistent with
dma-fence as each timeline has separate fence-contexts for each engine
and a seqno is only ordered within a fence-context
On 22/02/2017 11:46, Chris Wilson wrote:
A request is assigned a global seqno only when it is on the hardware
execution queue. The global seqno can be used to maintain a list of
requests on the same engine in retirement order, for example for
constructing a priority queue for waiting. Prior to i
On 22/02/2017 11:46, Chris Wilson wrote:
The plan in the near-future is to allow requests to be removed from the
signaler. We can no longer then rely on holding a reference to the
request for the duration it is in the signaling tree, and instead must
obtain a reference to the request for the cur
On Fri, Feb 17, 2017 at 02:43:05PM +, Tvrtko Ursulin wrote:
>
> On 14/02/2017 09:54, Chris Wilson wrote:
> >@@ -947,7 +948,11 @@ bool __i915_spin_request(const struct
> >drm_i915_gem_request *req,
> >
> > timeout_us += local_clock_us(&cpu);
> > do {
> >-if (__i915_gem_requ
Trying to have subject_verb_object ordering and more descriptive names,
the intel_huc_init() and intel_guc_init() functions are renamed:
* `intel_guc` is the subject, so those functions now take intel_guc
structure, instead of the dev_priv
* fetch is the verb
* fw is the object which better
GuC historically has two "startup" functions called _init() and _setup()
Then HuC came with it's _init() and _load().
This commit renames intel_guc_setup() and intel_huc_load() to
*uc_init_hw() as they called from the i915_gem_init_hw().
The aim is to be consistent in that entry points called du
Current version of intel_guc_init_hw() does a lot:
- cares about submission
- loads huc
- implement WA
This change offloads some of the logic to intel_uc_load(), which now
cares about the above.
v2: rename guc_hw_reset and fix typo in define name (M. Wajdeczko)
v3: rename once again
Cc: Anush
intel_uc_fw_fetch() is confusingly named in the light of recent changes.
It's also in the wrong place - 'guc_loader.h' - it's used for both guc
and huc, which was reflected in name, but not it's location, so let's
move it to 'intel_uc.c'.
We can make a intel_uc_fw callback out of it, to avoid lea
Let intel_guc_fetch_fw() focus on determining and fetching the correct
firmware.
This patch introduces intel_uc_sanitize_options() that is called from
intel_sanitize_options().
Then, if we have GuC, we can call intel_guc_fetch_fw() conditionally and
we do not have to do the internal checks.
v2:
Externs are implicit and we generally try to avoid them.
Cc: Michal Wajdeczko
Signed-off-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/intel_uc.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
ind
Used to obtain "dev_priv" from huc struct pointer.
We already have similar thing for guc.
Cc: Michal Wajdeczko
Signed-off-by: Arkadiusz Hiler
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv
Currently fw->path values can represent one of three possible states:
1) NULL - device without the uC
2) '\0' - device with the uC but have no firmware
3) else - device with the uC and we have firmware
Second case is used only to WARN at a later stage.
We can WARN right away and merge cases 1
General GuC/HuC cleanup simplifying logic, and moving chunks around, as the area
got pretty rusty.
A lot of logic were extracted from intel_guc_load() to other functions - it not
only did handle the actual loading but had WA implementations and had the code
thatenabled submission baked it.
This i
On Wed, Feb 22, 2017 at 12:29:00PM +, Tvrtko Ursulin wrote:
>
> On 22/02/2017 11:46, Chris Wilson wrote:
> >A request is assigned a global seqno only when it is on the hardware
> >execution queue. The global seqno can be used to maintain a list of
> >requests on the same engine in retirement o
== Series Details ==
Series: series starting with [CI,1/6] drm/i915: Remove change_domain tracepoint
URL : https://patchwork.freedesktop.org/series/20055/
State : success
== Summary ==
Series 20055v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20055/revisions/1
On Wed, Feb 22, 2017 at 01:41:25PM +0100, Arkadiusz Hiler wrote:
> Currently fw->path values can represent one of three possible states:
>
> 1) NULL - device without the uC
> 2) '\0' - device with the uC but have no firmware
> 3) else - device with the uC and we have firmware
>
> Second case i
Handle DRM_DP_DUAL_MODE_LSPCON in drm_dp_get_dual_mode_type_name(),
otherwise a call to that function can theoretically trigger a WARN.
Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
Cc: Shashank Sharma
Cc: Rodrigo Vivi
Cc: Dave Airlie
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc:
On Wed, Feb 22, 2017 at 12:52:22PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [CI,1/6] drm/i915: Remove change_domain
> tracepoint
> URL : https://patchwork.freedesktop.org/series/20055/
> State : success
>
> == Summary ==
>
> Series 20055v1 Series without
HDMI 2.0 spec defines a method to reduce the RF footprint while
operating at higher pixel clocks, which is called Scrambling.
Scrambling can be controlled over a new set of I2C registers
which are accessible over existing DDC I2C lines, called SCDC
register set.
This patch series contains 6 patche
From: Thierry Reding
This patch implements a small function that finds if a
given CEA db is hdmi-forum vendor specific data block
or not.
V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
Signed-off-by: Thierry Reding
Signed-off-by: Shashank Sharma
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/
From: Thierry Reding
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.
This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.
V2: Rebase.
V3: Added
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDM
HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
than 340 MHz. This patch adds few new functions in drm layer for
core drivers to enable/disable scrambling.
This patch adds:
- A function to detect scrambling support parsing HF-VSDB
- A function to check scrambling status runtime
Geminilake has a native HDMI 2.0 controller, which is capable of
driving clocks upto 594Mhz. This patch updates the max tmds clock
limit for the same.
V2: rebase
V3: rebase
V4: added r-b from Ander
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
Reviewed-by: Ander Conselvan De Ol
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.
V
On 22/02/2017 11:46, Chris Wilson wrote:
If we preempt a request and remove it from the execution queue, we need
to undo its global seqno and restart any waiters.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 71 +---
drivers/gpu/drm/i9
At the first glace, I thought LSPCON is type2 HDMI only, then I realized
not really for us (:-))
Reviewed-by: Shashank Sharma
Regards
Shashank
On 2/22/2017 6:29 PM, Ander Conselvan de Oliveira wrote:
Handle DRM_DP_DUAL_MODE_LSPCON in drm_dp_get_dual_mode_type_name(),
otherwise a call to that f
On 22/02/2017 12:45, Chris Wilson wrote:
On Wed, Feb 22, 2017 at 12:29:00PM +, Tvrtko Ursulin wrote:
On 22/02/2017 11:46, Chris Wilson wrote:
A request is assigned a global seqno only when it is on the hardware
execution queue. The global seqno can be used to maintain a list of
requests o
== Series Details ==
Series: series starting with [v2,01/15] drm/i915: Keep a global seqno per-engine
URL : https://patchwork.freedesktop.org/series/20056/
State : failure
== Summary ==
Series 20056v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20056/revisions/
On 22/02/2017 11:46, Chris Wilson wrote:
After the request is cancelled, we then need to remove it from the
global execution timeline and return it to the context timeline, the
inverse of submit_request().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c| 58
On ke, 2017-02-22 at 10:21 +, Matthew Auld wrote:
> For our fake dma objects we can leak the underlying gem object if we
> fail to pin our "backing storage".
>
> [ 39.952618]
> =
> [ 39.952625] BUG mock_object (Ta
1 - 100 of 219 matches
Mail list logo
