== Series Details ==
Series: drm/i915: intel_dp_link_is_valid() should only return status of link
URL : https://patchwork.freedesktop.org/series/9737/
State : failure
== Summary ==
Series 9737v1 drm/i915: intel_dp_link_is_valid() should only return status of
link
http://patchwork.freedesktop.
== Series Details ==
Series: drm/i915/skl: Add support for the SAGV, fix underrun hangs
URL : https://patchwork.freedesktop.org/series/9736/
State : failure
== Summary ==
Series 9736v1 drm/i915/skl: Add support for the SAGV, fix underrun hangs
http://patchwork.freedesktop.org/api/1.0/series/97
== Series Details ==
Series: drm/i915/guc: symbolic names for user load/submission preferences
URL : https://patchwork.freedesktop.org/series/9724/
State : failure
== Summary ==
Series 9724v1 drm/i915/guc: symbolic names for user load/submission preferences
http://patchwork.freedesktop.org/api
Intel_dp_link_is_valid() function reads the Link status registers
and returns a boolean to indicate link is valid or not.
If the link has lost lock and is not valid any more, it is
retrained outside the function else no previously trained link
is retained.
v2: Changed the function name from intel_
On Sat, Jul 02, 2016 at 11:29:05AM +0200, Lukas Wunner wrote:
> On Fri, Jul 01, 2016 at 03:47:56PM -0700, Manasi Navare wrote:
> > Intel_dp_check_link_status() function reads the Link status registers
> > and returns a boolean to indicate link is good or bad.
> > If the link is bad, it is retrained
On Fri, Jul 01, 2016 at 05:35:25PM -0700, Rodrigo Vivi wrote:
> On Fri, Jul 1, 2016 at 3:47 PM, Manasi Navare
> wrote:
> > Intel_dp_check_link_status() function reads the Link status registers
> > and returns a boolean to indicate link is good or bad.
> > If the link is bad, it is retrained outsi
Just posting this so it's on the ML.
NAK on this patch, this causes leftover cursors on SKL. Additionally, there's a
noticeable lag every time I move the cursor from one monitor to another, and the
flickering from the broken watermarks still happens.
On Thu, 2016-07-07 at 11:37 -0700, Matt Roper
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full
On Mon, Jul 11, 2016 at 06:12:40PM +0100, Dave Gordon wrote:
> The existing code that accesses the "enable_guc_loading" and
> "enable_guc_submission" parameters uses explicit numerical
> values for the various possibilities, including in some cases
> relying on boolean 0/1 mapping to specific value
This is a reminder of this series.
On 2016-06-29 07:22 AM, robert.f...@collabora.com wrote:
From: Robert Foss
igt_crtc_prop_names and igt_atomic_crtc_properties have different orders of
properties, which is fixed in this patch.
Signed-off-by: Robert Foss
---
lib/igt_kms.c | 2 +-
1 file c
Some downgraded from DRM_ERROR() to DRM_WARN(), some eliminated,
and a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN().
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_guc_loader.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drive
Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/
We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common under
The existing code that accesses the "enable_guc_loading" and
"enable_guc_submission" parameters uses explicit numerical
values for the various possibilities, including in some cases
relying on boolean 0/1 mapping to specific values (which could
be confusing for maintainers).
So this patch just pro
Chris Wilson writes:
> Now that the last couple of hacks have been removed from the runtime
> powermanagement users, we can fully enable the asserts.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_drv.h | 7 ---
> 1 file changed, 7 deletions
On Mon, Jul 11, 2016 at 12:10:40PM -0300, Gustavo Padovan wrote:
> 2016-07-11 Chris Wilson :
>
> > vGEM buffers are useful for passing data between software clients and
> > hardware renders. By allowing the user to create and attach fences to
> > the exported vGEM buffers (on the dma-buf), the use
2016-07-11 Chris Wilson :
> vGEM buffers are useful for passing data between software clients and
> hardware renders. By allowing the user to create and attach fences to
> the exported vGEM buffers (on the dma-buf), the user can implement a
> deferred renderer and queue hardware operations like fl
== Series Details ==
Series: drm/i915: fix wrong ifdef condition for mutex owner (rev2)
URL : https://patchwork.freedesktop.org/series/9718/
State : failure
== Summary ==
Series 9718v2 drm/i915: fix wrong ifdef condition for mutex owner
http://patchwork.freedesktop.org/api/1.0/series/9718/revi
On Mon, Jul 11, 2016 at 05:14:22PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Some hardware requires a valid render context before it can initiate
> > rc6 power gating of the GPU; the default state of the GPU is not
> > sufficient and may lead to undefined behaviour. The first execu
On 7/11/2016 7:13 PM, Tvrtko Ursulin wrote:
On 11/07/16 14:38, Goel, Akash wrote:
On 7/11/2016 6:53 PM, Tvrtko Ursulin wrote:
On 11/07/16 14:15, Goel, Akash wrote:
On 7/11/2016 4:00 PM, Tvrtko Ursulin wrote:
+static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv,
u32 gt_i
Chris Wilson writes:
> Some hardware requires a valid render context before it can initiate
> rc6 power gating of the GPU; the default state of the GPU is not
> sufficient and may lead to undefined behaviour. The first execution of
> any batch will load the "golden render state", at which point i
Chris Wilson writes:
> Instead of flushing the outstanding enabling, remember the requested
> frequency to apply when the powersave work runs.
>
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 30 ++--
== Series Details ==
Series: series starting with [1/3] drm/vgem: Fix mmaping
URL : https://patchwork.freedesktop.org/series/9716/
State : failure
== Summary ==
Series 9716v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/9716/revisions/1/mbox
Test drv_module_relo
On ma, 2016-07-11 at 14:50 +0100, ch...@chris-wilson.co.uk wrote:
> On Mon, Jul 11, 2016 at 04:24:50PM +0300, Imre Deak wrote:
> > On ma, 2016-07-11 at 13:55 +0100, ch...@chris-wilson.co.uk wrote:
> > > And then you get random changes in the firmare whilst bisecting
> > > the
> > > kernel.
> >
> >
On Mon, Jul 11, 2016 at 04:24:50PM +0300, Imre Deak wrote:
> On ma, 2016-07-11 at 13:55 +0100, ch...@chris-wilson.co.uk wrote:
> > And then you get random changes in the firmare whilst bisecting the
> > kernel.
>
> What do you mean random? During bisecting we want to load the firmware
> version th
In commit 7608a43d8f2e ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER when
appropriate") the owner field in the mutex was updated from being
dependent upon CONFIG_SMP to using optimistic spin. Update our peek
function to suite.
Fixes:7608a43d8f2e ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER...")
Reporte
On 11/07/16 14:38, Goel, Akash wrote:
On 7/11/2016 6:53 PM, Tvrtko Ursulin wrote:
On 11/07/16 14:15, Goel, Akash wrote:
On 7/11/2016 4:00 PM, Tvrtko Ursulin wrote:
+static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv,
u32 gt_iir)
+{
+if (gt_iir & GEN9_GUC_TO_HOST_INT_E
Chris Wilson writes:
> As these RPS frequency values are part of our userspace interface, they
> must be established before that userspace interface is registered.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_pm.c | 98
> +
> 1 file
On 7/11/2016 6:53 PM, Tvrtko Ursulin wrote:
On 11/07/16 14:15, Goel, Akash wrote:
On 7/11/2016 4:00 PM, Tvrtko Ursulin wrote:
+static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv,
u32 gt_iir)
+{
+if (gt_iir & GEN9_GUC_TO_HOST_INT_EVENT) {
+spin_lock(&dev_priv->
Chris Wilson writes:
> Move the overclocking max frequency detection alongside the regular
> frequency detection, before we expose the undefined value to userspace.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_pm.c | 24 +++-
> 1 file changed, 15 insert
Got compiling error if disabling MUTEX_SPIN_ON_OWNER and DEBUG_MUTEXES:
drivers/gpu/drm/i915/i915_gem_shrinker.c:44:14: error: 'struct mutex' has
no member named 'owner'.
Signed-off-by: Hong Liu
---
drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On ma, 2016-07-11 at 13:55 +0100, ch...@chris-wilson.co.uk wrote:
> On Mon, Jul 11, 2016 at 03:45:21PM +0300, Imre Deak wrote:
> > On ma, 2016-07-11 at 13:39 +0100, ch...@chris-wilson.co.uk wrote:
> > > On Mon, Jul 11, 2016 at 02:23:48PM +0300, Imre Deak wrote:
> > > > On to, 2016-07-07 at 17:57 +0
On 11/07/16 14:15, Goel, Akash wrote:
On 7/11/2016 4:00 PM, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
There are certain types of interrupts which Host can recieve from GuC.
GuC ukernel sends an interrupt to Host for certain events, like for
On 7/11/2016 4:00 PM, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
There are certain types of interrupts which Host can recieve from GuC.
GuC ukernel sends an interrupt to Host for certain events, like for
example retrieve/consume the logs gen
On Mon, Jul 11, 2016 at 03:55:35PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Mon, Jul 11, 2016 at 02:39:19PM +0300, Mika Kuoppala wrote:
> >> What should be the rules for boost_freq? With this change it can
> >> be over max_freq_softlimit and thus will break pm_rps.
> >
> > The
vGEM buffers are useful for passing data between software clients and
hardware renders. By allowing the user to create and attach fences to
the exported vGEM buffers (on the dma-buf), the user can implement a
deferred renderer and queue hardware operations like flipping and then
signal the buffer r
Just a quick resend of the existing vgem patches, all 3 have been acked,
but only the first 2 have reviews. The third involves both new ioctl and
dma-buf/fences, so perhaps people have been reluctant... But now is a
good time! These patches are exercised by intel-gpu-tools (or will be once
the new
Enable the standard GEM dma-buf interface provided by the DRM core, but
only for exporting the VGEM object. This allows passing around the VGEM
objects created from the dumb interface and using them as sources
elsewhere. Creating a VGEM object for a foriegn handle is not supported.
v2: With additi
The vGEM mmap code has bitrotted slightly and now immediately BUGs.
Since vGEM was last updated, there are new core GEM facilities to
provide more common functions, so let's use those here.
v2: drm_gem_free_mmap_offset() is performed from
drm_gem_object_release() so we can remove the redundant cal
On 11/07/16 13:11, Goel, Akash wrote:
On 7/11/2016 5:20 PM, Tvrtko Ursulin wrote:
On 11/07/16 12:41, Goel, Akash wrote:
On 7/11/2016 3:07 PM, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
b/drivers/gpu/drm/i915/i915_guc_submission.c
index
On Mon, Jul 11, 2016 at 03:45:21PM +0300, Imre Deak wrote:
> On ma, 2016-07-11 at 13:39 +0100, ch...@chris-wilson.co.uk wrote:
> > On Mon, Jul 11, 2016 at 02:23:48PM +0300, Imre Deak wrote:
> > > On to, 2016-07-07 at 17:57 +0300, Mika Kuoppala wrote:
> > > > "Vivi, Rodrigo" writes:
> > > >
> > >
Chris Wilson writes:
> On Mon, Jul 11, 2016 at 02:39:19PM +0300, Mika Kuoppala wrote:
>> What should be the rules for boost_freq? With this change it can
>> be over max_freq_softlimit and thus will break pm_rps.
>
> The point is to be an independent variable that the user can set in
> addition to
On Mon, Jul 11, 2016 at 03:21:37PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Let's ensure that we cannot run indefinitely without the hangcheck
> > worker being queued. We removed it from being kicked on every request
> > because we were kicking it a few millions times in every han
On ma, 2016-07-11 at 13:39 +0100, ch...@chris-wilson.co.uk wrote:
> On Mon, Jul 11, 2016 at 02:23:48PM +0300, Imre Deak wrote:
> > On to, 2016-07-07 at 17:57 +0300, Mika Kuoppala wrote:
> > > "Vivi, Rodrigo" writes:
> > >
> > > > Nak.
> > > >
> > > > I don't intend to update the symbolic links o
On Mon, Jul 11, 2016 at 02:23:48PM +0300, Imre Deak wrote:
> On to, 2016-07-07 at 17:57 +0300, Mika Kuoppala wrote:
> > "Vivi, Rodrigo" writes:
> >
> > > Nak.
> > >
> > > I don't intend to update the symbolic links on linux-firmware.git
> > > repository anymore so if we receive a new minor versi
Chris Wilson writes:
> Let's ensure that we cannot run indefinitely without the hangcheck
> worker being queued. We removed it from being kicked on every request
> because we were kicking it a few millions times in every hangcheck
> interval and only once is necessary! However, that leaves us wit
On 7/11/2016 5:20 PM, Tvrtko Ursulin wrote:
On 11/07/16 12:41, Goel, Akash wrote:
On 7/11/2016 3:07 PM, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2112e02..8a9a0cb 100644
--- a/drivers/gp
On 11/07/16 12:41, Goel, Akash wrote:
On 7/11/2016 3:07 PM, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2112e02..8a9a0cb 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/
On Mon, Jul 11, 2016 at 02:39:19PM +0300, Mika Kuoppala wrote:
> What should be the rules for boost_freq? With this change it can
> be over max_freq_softlimit and thus will break pm_rps.
The point is to be an independent variable that the user can set in
addition to max freq, just like the cpu tur
Chris Wilson writes:
> Never go to sleep waiting on the GPU without first ensuring that we will
> get woken up.
>
> We have a choice of queuing the hangcheck before every schedule() or the
> first time we wakeup. In order to simply accommodate both the signaler
> and the ordinary waiter, move the
On 7/11/2016 3:07 PM, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2112e02..8a9a0cb 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@
Chris Wilson writes:
> To allow the user finer control over waitboosting, allow them to set the
> frequency we request for the boost. This also them allows to effectively
> disable the boosting by setting the boost request to a low frequency.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/
On to, 2016-07-07 at 17:57 +0300, Mika Kuoppala wrote:
> "Vivi, Rodrigo" writes:
>
> > Nak.
> >
> > I don't intend to update the symbolic links on linux-firmware.git
> > repository anymore so if we receive a new minor version update we
> > are
> > not going to load.
> >
> > I was the one advoca
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
There are certain types of interrupts which Host can recieve from GuC.
GuC ukernel sends an interrupt to Host for certain events, like for
example retrieve/consume the logs generated by ukernel.
This patch adds support to r
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Akash Goel
So far PM IER/IIR/IMR registers were being used only for Turbo related
interrupts. But interrupts coming from GuC also use the same set.
As a precursor to supporting GuC interrupts, added new low level routines
so as to allow shar
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
GuC Log buffer allocation was tied up with verbosity level module param
i915.guc_log_level. User would be given a provision to enable firmware
logging at runtime, through a host2guc action, and not necessarily during
Driver
Hi all,
New -testing cycle with cool stuff:
- select igt testing depencies for CONFIG_DRM_I915_DEBUG (Chris)
- track outputs in crtc state and clean up all our ad-hoc connector/encoder
walking in modest code (Ville)
- demidlayer drm_device/drm_i915_private (Chris Wilson)
- thundering herd fix fr
57 matches
Mail list logo
