Hey,
Op 11-01-16 om 19:27 schreef Matt Roper:
> sanitize_watermarks() does not properly handle errors returned by
> drm_atomic_helper_duplicate_state(). Make failures drop locks before
> returning. We also change the lock of connection_mutex to a
> drm_modeset_lock_all_ctx() to make sure any EDE
== Summary ==
Built on a90796840c30dac6d9907439bf98d1d08046c49d drm-intel-nightly:
2016y-01m-11d-17h-22m-54s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (skl-i5k-2) UNSTABLE
Test kms_pipe_crc_basic:
Subgroup hang
== Summary ==
Built on a90796840c30dac6d9907439bf98d1d08046c49d drm-intel-nightly:
2016y-01m-11d-17h-22m-54s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (bdw-nuci7)
pass -> DMESG-WARN (skl-i7k-2) UN
>-Original Message-
>From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>Sent: Monday, January 11, 2016 8:07 PM
>To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>Subject: Re: [PATCH 5/7] drm/i915/dp: Add methods to update link train params
>
>On Fri, 2015-12-11 at 15:09 +0530
On Tue, 12 Jan 2016, Jonathan Corbet wrote:
> In my mind, there's clearly no good that can come from (further) delaying
> something that works in favor of an "it would be nice" that may never
> even exist. So I'm currently thinking that I'll pull this into the docs
> tree once the merge window is
Hi Daniel,
It seems your patch is exactly same as below my one I posted before,
http://www.spinics.net/lists/dri-devel/msg97922.html
Anyway, it's ok if this patch can go to mainline.
Acked-by: Inki Dae
2016년 01월 12일 06:41에 Daniel Vetter 이(가) 쓴 글:
> The core takes care of this now. And since kf
> From: akash.g...@intel.com
> Sent: Saturday, January 09, 2016 7:32 PM
>
[...]
>
> There is a provision to keep TR-TT Tables in virtual space, where the pages of
> TRTT tables will be mapped to PPGTT. This is the adopted mode, as in this mode
> UMD will have a full control on TR-TT management,
On Mon, 11 Jan 2016, Lukas Wunner wrote:
> Hi,
>
> On Mon, Jan 11, 2016 at 09:54:36PM +0200, Jani Nikula wrote:
>> Hi all, first real patches since the RFC at [1].
>>
>> The VBT is a monster and it keeps growing. Originally we've extracted
>> bits and pieces out of there, and added them cleanly t
> From: john.c.harri...@intel.com
> Sent: Tuesday, January 12, 2016 2:42 AM
>
> From: John Harrison
>
> Implemented a batch buffer submission scheduler for the i915 DRM driver.
>
> The general theory of operation is that when batch buffers are
> submitted to the driver, the execbuffer() code as
> -Original Message-
> From: Daniel Stone [mailto:dan...@fooishbar.org]
> Sent: Wednesday, December 23, 2015 1:37 AM
> To: Kannan, Vandana
> Cc: intel-gfx; Konduru, Chandra; Murthy, Arun R
> Subject: Re: [Intel-gfx] [RFC 2/2] drm/i915: Render decompression support for
> Gen9
>
> Hi Vandana
On Mon, Jan 11, 2016 at 06:42:31PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> A later patch in this series re-organises the batch buffer submission
> code. Part of that is to reduce the scope of a pm_get/put pair.
> Specifically, they previously wrapped the entire submissio
On Sat, 12 Dec 2015 12:13:45 +0100
Daniel Vetter wrote:
> I just figured there's no way this could get it, and I'd
> much rather improve the docs themselves than trying to convince core
> kernel folks that this might be useful.
So I'm not quite sure why you figured that; I never said it, certain
On Mon, Jan 11, 2016 at 06:42:29PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Implemented a batch buffer submission scheduler for the i915 DRM driver.
I've lost track of the number of patches that are a result of not having
per-context seqno and could be eliminated.
> Th
On Mon, Jan 11, 2016 at 04:02:09PM +, Dave Gordon wrote:
> IIRC the original version of this WARN (in intel_lr_context_descriptor()
> above) was added with the GuC submission code, because the context
> descriptor as used in execlist code is a 64-bit value, but the GuC
> requires that all the u
On Mon, Jan 11, 2016 at 06:42:47PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The scheduler can cause batch buffers, and hence requests, to be
> submitted to the ring out of order and asynchronously to their
> submission to the driver. Thus at the point of waiting for the
>
On 01/11/2016 11:10 AM, John Harrison wrote:
> On 08/01/2016 22:46, Chris Wilson wrote:
>> On Fri, Jan 08, 2016 at 06:47:26PM +, john.c.harri...@intel.com wrote:
>>> +void i915_gem_request_notify(struct intel_engine_cs *ring, bool
>>> fence_locked)
>>> +{
>>> +struct drm_i915_gem_request *
On Mon, Jan 11, 2016 at 02:47:33PM -0800, Jesse Barnes wrote:
> On 01/11/2016 11:03 AM, John Harrison wrote:
> > On 08/01/2016 22:05, Chris Wilson wrote:
> >> On Fri, Jan 08, 2016 at 06:47:24PM +, john.c.harri...@intel.com wrote:
> >>> From: John Harrison
> >>>
> >>> The fence object used insi
From: Abhay Kumar
Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12)
if this time is already spent in suspend/poweron time.
v2: Use CLOCK_BOOTTIME and remove jiffies for panel power cycle
delay calculation(Ville).
v3: Addressing Ville review comment.
Cc: Ville Syrjälä
On Mon, Jan 11, 2016 at 05:32:27PM +, Tvrtko Ursulin wrote:
> >+struct i915_gem_active {
> >+struct drm_i915_gem_request *request;
> >+};
> >+
> >+static inline void
> >+i915_gem_request_mark_active(struct drm_i915_gem_request *request,
> >+ struct i915_gem_active *a
On 01/11/2016 11:03 AM, John Harrison wrote:
> On 08/01/2016 22:05, Chris Wilson wrote:
>> On Fri, Jan 08, 2016 at 06:47:24PM +, john.c.harri...@intel.com wrote:
>>> From: John Harrison
>>>
>>> The fence object used inside the request structure requires a sequence
>>> number. Although this is
On 01/08/2016 10:47 AM, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The change to the implementation of i915_gem_request_completed() means
> that the lazy coherency flag is no longer used. This can now be
> removed to simplify the interface.
>
> For: VIZ-5190
> Signed-off-by: John
On 01/11/2016 11:03 AM, John Harrison wrote:
> On 08/01/2016 21:59, Chris Wilson wrote:
>> On Fri, Jan 08, 2016 at 06:47:22PM +, john.c.harri...@intel.com wrote:
>>> From: John Harrison
>>>
>>> There is a construct in the linux kernel called 'struct fence' that is
>>> intended to keep track of
On Mon, Jan 11, 2016 at 06:42:50PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> It can be useful to be able to disable certain features (e.g. the
> entire scheduler) via a module parameter for debugging purposes. A
> parameter has the advantage of not being a compile time swi
On Mon, Jan 11, 2016 at 06:42:39PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> MMIO flips are the preferred mechanism now but more importantly,
Says who?
> pipe
> based flips cause issues for the scheduler. Specifically, submitting
> work to the rings around the side of th
On Mon, Jan 11, 2016 at 06:42:49PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> When requesting that all GPU work is completed, it is now necessary to
> get the scheduler involved in order to flush out work that queued and
> not yet submitted.
But why is this needed over and
On Mon, Jan 11, 2016 at 06:42:41PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The scheduler needs to know when requests have completed so that it
> can keep its own internal state up to date and can submit new requests
> to the hardware from its queue.
Why would you reuse
On Mon, Jan 11, 2016 at 09:31:03PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 21, 2015 at 07:31:17AM -0800, Matt Roper wrote:
> > In commit
> >
> > commit 024c9045221fe45482863c47c4b4c47d37f97cbf
> > Author: Matt Roper
> > Date: Thu Sep 24 15:53:11 2015 -0700
> >
> >
On Mon, Jan 11, 2016 at 06:42:37PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> A major point of the GPU scheduler is that it re-orders batch buffers
> after they have been submitted to the driver. This leads to requests
> completing out of order. In turn, this means that the
On Mon, Jan 11, 2016 at 06:43:07PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The scheduler has always tracked batch buffer dependencies based on
> DRM object usage. This means that it will not submit a batch on one
> ring that has outstanding dependencies still executing o
On Mon, Jan 11, 2016 at 06:42:35PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The seqno value cannot always be used when debugging issues via trace
> points. This is because it can be reset back to start, especially
> during TDR type tests. Also, when the scheduler arrives
On Mon, Jan 11, 2016 at 06:42:33PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Split the execbuffer() function in half. The first half collects and
> validates all the information required to process the batch buffer. It
> also does all the object pinning, relocations, activ
From: Clint Taylor
Add reboot notifier for all platforms. This guarantees T12 delay
compliance during reboot cycles when pre-os enables the panel within
500ms.
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/intel_dp.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
d
From: Alex Dai
Add debugfs entry for HuC loading status check.
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915/i915_debugfs.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/
From: Alex Dai
The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915/i915_guc_submission.c | 65 ++
drivers/gpu/drm/i915/intel_guc_fwif.h
From: Alex Dai
This is to rework previous patch:
commit 9f9e539f90bcecfdc7b3679d337b7a62d4313205
Author: Daniel Vetter
Date: Fri Oct 23 11:10:59 2015 +0200
drm/i915: Shut up GuC errors when it's disabled
There is the case where GuC loading is needed even GuC submission
is disabled. For
From: Alex Dai
HuC firmware css header has almost exactly same definition as GuC
firmware except for the sw_version. Also, add a new member fw_type
into intel_uc_fw to indicate what kind of fw it is. So, the loader
will pull right sw_version from header.
Signed-off-by: Alex Dai
Signed-off-by: P
From: Alex Dai
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915
From: Alex Dai
This series of patches is to enable HuC firmware loading and authentication.
The GuC loader and css_header are unified for HuC loading.
Alex Dai (6):
drm/i915/guc: Make the GuC fw loading helper functions general
drm/i915/guc: Bypass fw loading gracefully if GuC is not support
From: Alex Dai
Rename some of the GuC fw loading code to make them more general. We
will utilize them for HuC loading as well.
s/intel_guc_fw/intel_uc_fw/g
s/GUC_FIRMWARE/UC_FIRMWARE/g
Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw' either
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
v2: Fixup misplaced hunks.
Cc: Rob Clark
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher (v1)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 20
dri
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
v2: Fixup misplaced hunk.
Cc: Eric Anholt
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher (v1)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vc4/vc4_crtc.c | 20
drivers/
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
Cc: Laurent Pinchart
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Reviewed-by: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 20 --
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
v2: I've completely missed eaction->fpriv_head and all the related
code. We need to nuke that too to avoid accidentally deferencing the
freed-up vmwgfx-private fpriv.
v3: Also remove vmw_fpriv->fence_
Use them in the core vblank code and exynos/vmwgfx drivers.
Note that the difference between wake_up_all and _interruptible in
vmwgfx doesn't matter since the only waiter is the core code in
drm_fops.c. And that is interruptible.
v2: Adjust existing kerneldoc too.
Reviewed-by: Alex Deucher (v1)
There's really no reason to not do so, instead of replicating this
for every use-case and every driver. Now we can't just nuke the events,
since that would still mean that all drm_event users would need to know
when that has happened, since calling e.g. drm_send_event isn't allowed
any more. Instea
Doesn't do anything, but annoys when auditing them all.
Cc: Jianwei Wang
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.
The core code now takes care of unlinking drm_events from the file in
a generic way, so this code isn't needed any more.
For those wondering where the drm_vblank_put went to: With the new
logic events only get unlinked, but still exist. Hence any resources
(like vblank counters) don't need to be r
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
v2: I've completely missed eaction->fpriv_head and all the related
code. We need to nuke that too to avoid accidentally deferencing the
freed-up vmwgfx-private fpriv.
v3: Also remove vmw_fpriv->fence_
So this one is special, since it tries to prevent races when userspace
crashes simply by disabling the vblank machinery. Well except that imx
always has vblanks enabled, and the disable_vblank hook actually just
tries to cancel a pending pageflip. Without any locking whatsoever. Of
course this is w
I'm auditing them all, empty ones just confuse ...
Cc: Patrik Jakobsson
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/psb_drv.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu
The only thing this did was cancle pending flip events, and the core
takes care of that now.
Cc: Boris Brezillon
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 18 --
drivers/gpu/drm/atmel-hlcd
The core takes care of that now.
v2: Fixup misplaced hunk.
Cc: Thierry Reding
Cc: Terje Bergström
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/tegra/dc.c | 17 -
drivers/gpu/drm/tegra/drm.c | 3 ---
drivers/gpu/drm/tegra
They only complete the page flip events to avoid oops when the drm
file closes. The core takes care of that now and we can remove this
code.
Cc: Rob Clark
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 7 ---
d
An attempt at not spreading out the file_priv->event_space stuff out
quite so far and wide. And I think fixes something in ipp_get_event()
that is broken (or if they are doing something more weird/subtle, then
breaks it in a fun way).
Based upon a patch from Rob Clark, rebased and polished.
v2:
Cc: Rob Clark
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 32
1 file changed, 8 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
b/drivers/gpu/drm/v
The compiler will do this, but the void hits when grepping all the
hooks for a subsystem wide audit are slightly annoying. So remove them
for next time around.
Cc: Russell King
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/armada/armada_drv.
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
v2: Fixup misplaced hunk.
Cc: Laurent Pinchart
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher (v1)
Reviewed-by: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/shmobile/shmob
Now that the drm core unlinks/disarms events there's no need to do so
ourselves anymore. Nuke the code.
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 2 --
drivers/gpu/drm/i915/intel_display.c | 21
The core takes care of this now. And since kfree(NULL) is ok we can
simplify the function even further now.
Cc: Inki Dae
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
1 file changed, 14 deletions(
Again since the core takes care of this we can remove them. While at
it also remove the postclose hook, it's empty.
v2: Laurent pointed me at even more code to delete.
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
d
Also fixes a bug in IPP with not correctly checking/allocating for
space in the event space. Not a too serious bug since it's not a
real ringbuffer, just a limit to avoid too much kernel allocations.
Cc: Rob Clark
Cc: Inki Dae
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Dan
Just prep work before I throw more drm_event refactorings on top.
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/gpu.tmpl | 48 +--
drivers/gpu/drm/drm_fops.c | 129 ++---
include/drm/
Hi all,
Mostly just small changes from review feedback (plus a few misplaced hunks,
silly me). Plus an attempt at better kerneldoc to explain how this works. Since
that caused questions both from Thomas and Laurent let me explain things also
here:
Currently anyone using drm_events (vblank code, a
On Mon, Jan 11, 2016 at 05:15:54PM +, Tvrtko Ursulin wrote:
> > Is that not what was written? I take it my telepathy isn't working
> > again.
>
> Sorry not a new loop, new case in a old loop. This is the hunk I think
> is not helping readability:
>
> @@ -869,11 +967,29 @@ i915_gem_gtt_pwrite_
Hi,
On 5 January 2016 at 10:23, Daniel Vetter wrote:
> On Wed, Dec 23, 2015 at 09:47:00AM +, Daniel Stone wrote:
>> It's not even a legacy vs. atomic thing, this can happen in
>> pure-atomic as well. Same as the render-compression plane property
>> that I just replied to here as well.
>>
>> -
Hi,
On Mon, Jan 11, 2016 at 09:54:36PM +0200, Jani Nikula wrote:
> Hi all, first real patches since the RFC at [1].
>
> The VBT is a monster and it keeps growing. Originally we've extracted
> bits and pieces out of there, and added them cleanly to our own
> structures in dev_priv->vbt, with our o
On 11/01/16 09:16, Chris Wilson wrote:
By using the same address for storing the HWS on every platform, we can
remove the platform specific vfuncs and reduce the get-seqno routine to
a single read of a cached memory location.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c
Hide knowledge about VBT child devices in intel_bios.c.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_bios.c | 33 -
drivers/gpu/drm/i915/intel_dsi.c | 23 ++-
3 files changed, 47 insertio
Hide knowledge about VBT child devices in intel_bios.c.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 33 +
drivers/gpu/drm/i915/intel_dp.c | 21 +
3 files changed, 35 insertions(
We've been accumulating code across the driver that depends on the VBT
specific structures and defines. The VBT is an uncontrollable
beast. Encourage encapsulation of the VBT data by hiding the structures
and defines in a private header only to be included from intel_bios.c.
Signed-off-by: Jani Ni
Use the connector type instead of VBT directly to decide which backlight
mechanism to use on VLV/CHV. (Indirectly, this is the same thing, but
hides the VBT use.)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Hi all, first real patches since the RFC at [1].
The VBT is a monster and it keeps growing. Originally we've extracted
bits and pieces out of there, and added them cleanly to our own
structures in dev_priv->vbt, with our own macros. Later on we've been
slipping and we have copied stuff from VBT ve
Hide knowledge about VBT child devices in intel_bios.c.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 50
drivers/gpu/drm/i915/intel_lvds.c | 53 +--
3 files ch
Hide knowledge about VBT child devices in intel_bios.c.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 38 ++
drivers/gpu/drm/i915/intel_tv.c | 43 +--
3 files chan
On 11/01/16 08:38, Daniel Vetter wrote:
On Fri, Jan 08, 2016 at 11:29:44AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
We are not allowed to call i915_gem_obj_ggtt_offset from irq
context without the big kernel lock held.
LRCA lifetime is well defined so cache it so it can be looked up
On Mon, Dec 21, 2015 at 07:31:17AM -0800, Matt Roper wrote:
> In commit
>
> commit 024c9045221fe45482863c47c4b4c47d37f97cbf
> Author: Matt Roper
> Date: Thu Sep 24 15:53:11 2015 -0700
>
> drm/i915/skl: Eliminate usage of pipe_wm_parameters from
> SKL-style
On 08/01/2016 22:47, Chris Wilson wrote:
On Fri, Jan 08, 2016 at 06:47:21PM +, john.c.harri...@intel.com wrote:
[Patches against drm-intel-nightly tree fetched 17/11/2015]
Branch url?
Not sure what you mean. The branch is 'drm-intel-nightly' from the DRM
intel git repository (git://anong
gmux is a microcontroller built into dual GPU MacBook Pros.
On pre-retina MBPs, if we're the inactive GPU, we need apple-gmux
to temporarily switch DDC so that we can probe the panel's EDID.
The checks for CONFIG_VGA_ARB and CONFIG_VGA_SWITCHEROO are necessary
because if either of them is disabled
The pre-retina MacBook Pro uses an LVDS panel and a gmux controller
to switch the panel between its two GPUs. The panel mode in VBIOS
is notoriously bogus on these machines and some models have no
VBIOS at all.
Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS
if the vga_switcheroo h
On 08/01/2016 22:46, Chris Wilson wrote:
On Fri, Jan 08, 2016 at 06:47:26PM +, john.c.harri...@intel.com wrote:
+void i915_gem_request_notify(struct intel_engine_cs *ring, bool fence_locked)
+{
+ struct drm_i915_gem_request *req, *req_next;
+ unsigned long flags;
u32 seqn
Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5.
The main obstacle on these machines is that the panel mode in VBIOS
is bogus. Fortunately gmux can switch DDC independently from the
display, thereby allowing the inactive GPU to probe the panel's EDID.
In short, vga_switcheroo
On 08/01/2016 22:08, Chris Wilson wrote:
On Fri, Jan 08, 2016 at 06:47:25PM +, john.c.harri...@intel.com wrote:
From: John Harrison
The request structure is reference counted. When the count reached
zero, the request was immediately freed and all associated objects
were unrefereced/unalloc
On 08/01/2016 22:05, Chris Wilson wrote:
On Fri, Jan 08, 2016 at 06:47:24PM +, john.c.harri...@intel.com wrote:
From: John Harrison
The fence object used inside the request structure requires a sequence
number. Although this is not used by the i915 driver itself, it could
potentially be us
On 08/01/2016 21:59, Chris Wilson wrote:
On Fri, Jan 08, 2016 at 06:47:22PM +, john.c.harri...@intel.com wrote:
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that is
intended to keep track of work that is executed on hardware. I.e. it
solves the basic p
From: Ville Syrjälä
Restore the lost phys status page cleanup.
Fixes the following splat with DMA_API_DEBUG=y:
WARNING: CPU: 0 PID: 21615 at ../lib/dma-debug.c:974
dma_debug_device_change+0x190/0x1f0()
pci :00:02.0: DMA-API: device driver has pending DMA allocations while
released from de
From: John Harrison
There are various parameters within the scheduler which can be tuned
to improve performance, reduce memory footprint, etc. This change adds
support for altering these via debugfs.
v2: Updated for priorities now being signed values.
For: VIZ-1587
Signed-off-by: John Harrison
From: John Harrison
It can be useful to be able to disable certain features (e.g. the
entire scheduler) via a module parameter for debugging purposes. A
parameter has the advantage of not being a compile time switch but
without implying that it can be changed dynamically at runtime.
For: VIZ-158
From: John Harrison
It is useful for know what the scheduler is doing for both debugging
and performance analysis purposes. This change adds a bunch of
counters and such that keep track of various scheduler operations
(batches submitted, completed, flush requests, etc.). The data can
then be read
From: John Harrison
When the seqno wraps around zero, the entire GPU is forced to be idle
for some reason (possibly only to work around issues with hardware
semaphores but no-one seems too sure!). This causes a problem if the
force idle occurs at an inopportune moment such as in the middle of
sub
From: John Harrison
It is useful to be able to see what seqnos have actually popped out of
the hardware when viewing the scheduler status.
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_scheduler.c | 10 ++
drivers/gpu/drm/i915/i915_scheduler.h | 1 +
2 files
From: John Harrison
The scheduler needs to know when requests have completed so that it
can keep its own internal state up to date and can submit new requests
to the hardware from its queue.
v2: Updated due to changes in request handling. The operation is now
reversed from before. Rather than th
From: Dave Gordon
Added an interface for user land applications/libraries/services to
set their GPU scheduler priority. This extends the existing context
parameter IOCTL interface to add a scheduler priority parameter. The
range is +/-1023 with +ve numbers meaning higher priority. Only
system pro
From: John Harrison
Hardware sempahores require seqno values to be continuously
incrementing. However, the scheduler's reordering of batch buffers
means that the seqno values going through the hardware could be out of
order. Thus semaphores can not be used.
On the other hand, the scheduler super
From: John Harrison
If a given context submits too many hanging batch buffers then it will
be banned and no further batch buffers will be accepted for it.
However, it is possible that a large number of buffers may already
have been accepted and are sat in the scheduler waiting to be
executed. Thi
From: John Harrison
When debugging batch buffer submission issues, it is useful to be able
to see what the current state of the scheduler is. This change adds
functions for decoding the internal scheduler state and reporting it.
v3: Updated a debug message with the new state_str() function.
v4:
From: John Harrison
The scheduler decouples the submission of batch buffers to the driver
from their subsequent submission to the hardware. This means that an
application which is continuously submitting buffers as fast as it can
could potentialy flood the driver. To prevent this, the driver now
From: John Harrison
Added a facility for triggering the scheduler state dump via a debugfs
entry.
v2: New patch in series.
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_debugfs.c | 33 +
drivers/gpu/drm/i915/i915_scheduler.c | 9 ++
From: John Harrison
The scheduler decouples the submission of batch buffers to the driver
with submission of batch buffers to the hardware. Thus it is possible
for an application to close its DRM file handle while there is still
work outstanding. That means the scheduler needs to know about file
From: John Harrison
One of the major purposes of the GPU scheduler is to avoid stalling
the CPU when the GPU is busy and unable to accept more work. This
change adds support to the ring submission code to allow a ring space
check to be performed before attempting to submit a batch buffer to
the h
From: John Harrison
When requesting that all GPU work is completed, it is now necessary to
get the scheduler involved in order to flush out work that queued and
not yet submitted.
v2: Updated to add support for flushing the scheduler queue by time
stamp rather than just doing a blanket flush.
v
1 - 100 of 450 matches
Mail list logo
