== Series Details ==
Series: drm/i915/ilk: Disable SSC for DPLLs if we're not using it
URL : https://patchwork.freedesktop.org/series/7582/
State : failure
== Summary ==
Series 7582v1 drm/i915/ilk: Disable SSC for DPLLs if we're not using it
http://patchwork.freedesktop.org/api/1.0/series/7582
== Series Details ==
Series: drm/i915/guc: Disable automatic GuC firmware loading
URL : https://patchwork.freedesktop.org/series/7577/
State : failure
== Summary ==
Series 7577v1 drm/i915/guc: Disable automatic GuC firmware loading
http://patchwork.freedesktop.org/api/1.0/series/7577/revisions
On Mon, 2016-05-23 at 10:42 -0700, Jim Bride wrote:
> On Mon, May 23, 2016 at 11:22:17AM +0300, Ander Conselvan De Oliveira wrote:
> >
> > On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> > >
> > > From: Jim Bride
> > >
> > > For DP compliance we need to be able to control the output c
On Mon, May 23, 2016 at 06:09:31PM +0200, Maarten Lankhorst wrote:
> Op 23-05-16 om 17:43 schreef Chris Wilson:
> > On Mon, May 23, 2016 at 05:09:05PM +0200, Maarten Lankhorst wrote:
> >> Op 23-05-16 om 16:25 schreef Chris Wilson:
> >>> On Mon, May 23, 2016 at 03:37:41PM +0200, Maarten Lankhorst wr
Thanks to Ville Syrjälä for pointing me towards the cause of this issue.
Unfortunately one of the sideaffects of having the refclk for a DPLL set
to SSC is that as long as it's set to SSC, the GPU will prevent us from
powering down any of the pipes or transcoders using it. A couple of
BIOSes enabl
On Mon, 2016-05-23 at 21:06 +0300, Ville Syrjälä wrote:
> On Fri, May 20, 2016 at 05:36:40PM -0400, Lyude wrote:
> >
> > We no longer call ilk_audio_codec_enable() while we have vblanks
> > disabled. As such, we can finally fix this and stop the occasional pipe
> > underruns I'm seeing on this Del
On Mon, May 23, 2016 at 02:56:54PM -0400, Lyude wrote:
> Thanks to Ville Syrjälä for pointing me towards the cause of this issue.
>
> Unfortunately one of the sideaffects of having the refclk for a DPLL
> set to SSC is that as long as it's set to SSC, the GPU will prevent us
> from powering down a
Thanks to Ville Syrjälä for pointing me towards the cause of this issue.
Unfortunately one of the sideaffects of having the refclk for a DPLL
set to SSC is that as long as it's set to SSC, the GPU will prevent us
from powering down any of the pipes or transcoders using it. A couple of
BIOSes, desp
On Fri, May 13, 2016 at 11:41:19PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Here's my second installment of SKL+ cdclk stuff. I've picked up Clint's
> latest
> SKL/KBL cdclk patch and expanded on it quite a bit. After this series we're
> capable of actually changing
On Thu, May 19, 2016 at 10:49:23PM +0300, Imre Deak wrote:
> On Mon, 2016-05-16 at 16:59 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Like with cdclk, the DMC is supposed to manage dbuf enabling/disabling.
> > Let's make sure it has correctly restored the dbuf state
On Thu, May 19, 2016 at 06:48:37PM +0300, Imre Deak wrote:
> On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > SKL and BXT have the same snippets of code for enabling disabling the
> > DBUF. Extract those into helpers and move the calls from
>
On Thu, May 19, 2016 at 06:43:32PM +0300, Imre Deak wrote:
> On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Currently we initialize cdclk on SKL from two different places,
> > depending on whether it's during driver init or resume. Let's
> >
On 2016-05-23 10:49, Jani Nikula wrote:
> On Mon, 23 May 2016, Oliver Leitner wrote:
>> I am having a problem on my HP Compaq 610 Laptop with its built in intel
>> graphics chip. It is causing me a kernel Panic.
>
> There is no kernel panic in your dmesg. There is a WARNING with a
> backtrace.
>
On Fri, May 20, 2016 at 05:36:40PM -0400, Lyude wrote:
> We no longer call ilk_audio_codec_enable() while we have vblanks
> disabled. As such, we can finally fix this and stop the occasional pipe
> underruns I'm seeing on this Dell OptiPlex 990.
Hmm. Are you still getting underruns on -nightly?
I
On Mon, May 23, 2016 at 11:22:17AM +0300, Ander Conselvan De Oliveira wrote:
> On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> > From: Jim Bride
> >
> > For DP compliance we need to be able to control the output color
> > type for the pipe associated with the DP port. To do this we rely
On Sat, May 14, 2016 at 05:25:57AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: SKL/KBL/BXT cdclk stuff
> URL : https://patchwork.freedesktop.org/series/7169/
> State : failure
>
> == Summary ==
>
> Series 7169v1 drm/i915: SKL/KBL/BXT cdclk stuff
> http://patchwork.free
== Series Details ==
Series: series starting with [1/4] drm/i915: Introduce
intel_release_shared_dpll()
URL : https://patchwork.freedesktop.org/series/7467/
State : failure
== Summary ==
Series 7467v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7467/revisions/1
On Fri, May 20, 2016 at 04:06:17PM +0300, David Weinehall wrote:
> On Sat, May 07, 2016 at 09:18:24PM +0300, Ville Syrjälä wrote:
> > On Fri, May 06, 2016 at 09:22:49PM +0100, Chris Wilson wrote:
> > > On Fri, May 06, 2016 at 09:35:55PM +0300, ville.syrj...@linux.intel.com
> > > wrote:
> > > > @@
== Series Details ==
Series: drm/i915: Fix NULL pointer deference when out of PLLs in IVB
URL : https://patchwork.freedesktop.org/series/7458/
State : failure
== Summary ==
Series 7458v1 drm/i915: Fix NULL pointer deference when out of PLLs in IVB
http://patchwork.freedesktop.org/api/1.0/serie
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: Never fully mask the the EI up
rps interrupt on SNB/IVB (rev2)
URL : https://patchwork.freedesktop.org/series/7572/
State : warning
== Summary ==
Series 7572v2 Series without cover letter
http://patchwork.freedesktop.org/api
Op 23-05-16 om 17:43 schreef Chris Wilson:
> On Mon, May 23, 2016 at 05:09:05PM +0200, Maarten Lankhorst wrote:
>> Op 23-05-16 om 16:25 schreef Chris Wilson:
>>> On Mon, May 23, 2016 at 03:37:41PM +0200, Maarten Lankhorst wrote:
With nonblocking unpin there can be many cursor pins before they'
== Series Details ==
Series: series starting with [1/2] drm/i915/opregion: Convert to using native
drm_i915_private
URL : https://patchwork.freedesktop.org/series/7571/
State : success
== Summary ==
Series 7571v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7571
On Mon, May 23, 2016 at 05:44:28PM +0300, Jani Nikula wrote:
> On Mon, 23 May 2016, Mark Kettenis wrote:
> >> From: Jani Nikula
> >> Date: Mon, 23 May 2016 17:04:48 +0300
> >>
> >> On Thu, 19 May 2016, ville.syrj...@linux.intel.com wrote:
> >> > From: Ville Syrjälä
> >> >
> >> > We've never act
On Mon, May 23, 2016 at 05:09:05PM +0200, Maarten Lankhorst wrote:
> Op 23-05-16 om 16:25 schreef Chris Wilson:
> > On Mon, May 23, 2016 at 03:37:41PM +0200, Maarten Lankhorst wrote:
> >> With nonblocking unpin there can be many cursor pins before they're
> >> cleared by the next page flip.
> >>
>
From: Tvrtko Ursulin
New GuC code is logging errors at runtime suspend and resume which
causes CI testing to log "orange" status. Default to not trying to
load the firmware until this is resolved.
Example of the log:
[drm] RC6 on
[drm:intel_runtime_suspend] Suspending device
[drm:host2guc_ac
== Series Details ==
Series: drm/i915: Wait for flips to complete before returning.
URL : https://patchwork.freedesktop.org/series/7569/
State : failure
== Summary ==
Series 7569v1 drm/i915: Wait for flips to complete before returning.
http://patchwork.freedesktop.org/api/1.0/series/7569/revis
On Mon, May 23, 2016 at 05:42:49PM +0300, Jani Nikula wrote:
> On Mon, 23 May 2016, Chris Wilson wrote:
> > Current intel_opregion_init is called during the driver registration
> > phase and intel_opregion_fini from the unregistration phase. Rename the
> > functions show that this is clear from th
Op 23-05-16 om 16:25 schreef Chris Wilson:
> On Mon, May 23, 2016 at 03:37:41PM +0200, Maarten Lankhorst wrote:
>> With nonblocking unpin there can be many cursor pins before they're
>> cleared by the next page flip.
>>
>> Fix this by extending pin_count to the full 32-bit to prevent a
>> WARN_ON(v
== Series Details ==
Series: drm/i915: Wait for flips to complete before returning.
URL : https://patchwork.freedesktop.org/series/7569/
State : warning
== Summary ==
Series 7569v1 drm/i915: Wait for flips to complete before returning.
http://patchwork.freedesktop.org/api/1.0/series/7569/revis
Thanks Daniel and Joonas. : p See my replies below.
> -Original Message-
> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Monday, May 23, 2016 5:18 PM
> To: Joonas Lahtinen
> Cc: Wang, Zhi A ; Vetter, Daniel
> ; intel-gfx@lists.freedeskto
> From: Jani Nikula
> Date: Mon, 23 May 2016 17:04:48 +0300
>
> On Thu, 19 May 2016, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We've never actually enabled or unmasked the GSE interrupt on BDW+,
> > even though the interrupt handler was always prepared for it.
> > Le
On Mon, 23 May 2016, Mark Kettenis wrote:
>> From: Jani Nikula
>> Date: Mon, 23 May 2016 17:04:48 +0300
>>
>> On Thu, 19 May 2016, ville.syrj...@linux.intel.com wrote:
>> > From: Ville Syrjälä
>> >
>> > We've never actually enabled or unmasked the GSE interrupt on BDW+,
>> > even though the int
From: Ville Syrjälä
SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck
in an infinite batch buffer loop. The GPU apparently hogs something
critical and CPUs start to lose interrupts and whatnot. We can keep
the system limping along by unmasking some interrupts in
GEN6_PMINTRMSK
On Mon, 23 May 2016, Chris Wilson wrote:
> Current intel_opregion_init is called during the driver registration
> phase and intel_opregion_fini from the unregistration phase. Rename the
> functions show that this is clear from their names. The phases tell us
> what we expect the existing hw state
On Mon, 23 May 2016, Chris Wilson wrote:
> Prefer passing struct drm_i915_private to internal interfaces as this
> saves us having to dance between drm_device and our native struct. The
> savings hare are small (only 70 bytes of unrequired dancing), but
> progressive!
>
> Signed-off-by: Chris Wils
On Mon, May 23, 2016 at 03:30:04PM +0100, Chris Wilson wrote:
> On Mon, May 23, 2016 at 05:09:41PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck
> > in an infinite batch buffer loop. The GPU appare
On Mon, May 23, 2016 at 05:09:43PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On SNB (at least) it's dangeruopus to hang the GPU with an infinite
> batch buffer loop while RPS is disabled. The only thing that keeps
> the system going in such circumstances are the intern
On Mon, May 23, 2016 at 05:09:42PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Based on my observations GPU reset doesn't clobber the RPS state, so
> frobbing with RPS around GPU reset seems rather pointless. Just get
> rid of it.
>
> Signed-off-by: Ville Syrjälä
Test
== Series Details ==
Series: series starting with [v2,01/11] drm/i915: Rename struct intel_context
(rev2)
URL : https://patchwork.freedesktop.org/series/7564/
State : failure
== Summary ==
Series 7564v2 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7564/revisions
On Mon, May 23, 2016 at 05:09:41PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck
> in an infinite batch buffer loop. The GPU apparently hogs something
> critical and CPUs start to lose interrupts and wha
On Mon, 23 May 2016, Chris wrote:
> On Mon, 2016-05-23 at 11:06 +0300, Jani Nikula wrote:
>> On Fri, 20 May 2016, Chris wrote:
>> > I'm still seeing this periodically, previous to today it happened on
>> > April 24th. Doesn't matter what I'm doing the video will freeze however
>> > the cursor wil
On Mon, May 23, 2016 at 03:37:41PM +0200, Maarten Lankhorst wrote:
> With nonblocking unpin there can be many cursor pins before they're
> cleared by the next page flip.
>
> Fix this by extending pin_count to the full 32-bit to prevent a
> WARN_ON(vma->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUN
On Mon, May 23, 2016 at 4:16 PM, Joonas Lahtinen
wrote:
> On ma, 2016-05-23 at 07:03 +, Wang, Zhi A wrote:
>> Hi Guys:
>> I'm trying to make GVT-g as a sub-module of i915 in the next
>> version patchset. The basic idea is to introduce a "gvt-g pre-enabled
>> state" in i915. I think it should
From: Ville Syrjälä
Based on my observations GPU reset doesn't clobber the RPS state, so
frobbing with RPS around GPU reset seems rather pointless. Just get
rid of it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 11 ---
drivers/gpu/drm/i915/intel_drv.h | 1 -
d
On ma, 2016-05-23 at 07:03 +, Wang, Zhi A wrote:
> Hi Guys:
> I'm trying to make GVT-g as a sub-module of i915 in the next
> version patchset. The basic idea is to introduce a "gvt-g pre-enabled
> state" in i915. I think it should be a kernel option.
>
Could not the GGTT partitioning be do
From: Ville Syrjälä
On SNB (at least) it's dangeruopus to hang the GPU with an infinite
batch buffer loop while RPS is disabled. The only thing that keeps
the system going in such circumstances are the internal RPS timers,
so we should never feed the GPU with RPS disabled unless we want to
risk a
On Mon, 2016-05-23 at 11:06 +0300, Jani Nikula wrote:
> On Fri, 20 May 2016, Chris wrote:
> > I'm still seeing this periodically, previous to today it happened on
> > April 24th. Doesn't matter what I'm doing the video will freeze however
> > the cursor will still move. Only option is to SSH in to
From: Ville Syrjälä
SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck
in an infinite batch buffer loop. The GPU apparently hogs something
critical and CPUs start to lose interrupts and whatnot. We can keep
the system limping along by unmasking some interrupts in
GEN6_PMINTRMSK
This reverts commit d55dbd06bb5e1399aba9ab5227465339d1bbefff.
It lacks a description, removes the flip trace point,
doesn't handle -EBUSY if a flip is already queued
and needs to be redone.
Signed-off-by: Maarten Lankhorst
Cc: Ville Syrjälä
---
Patch 3/2 which CI probably doesn't handle correct
Current intel_opregion_init is called during the driver registration
phase and intel_opregion_fini from the unregistration phase. Rename the
functions show that this is clear from their names. The phases tell us
what we expect the existing hw state to be, e.g. whether interrupts are
still enabled e
Prefer passing struct drm_i915_private to internal interfaces as this
saves us having to dance between drm_device and our native struct. The
savings hare are small (only 70 bytes of unrequired dancing), but
progressive!
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_d
On Thu, 19 May 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We've never actually enabled or unmasked the GSE interrupt on BDW+,
> even though the interrupt handler was always prepared for it.
> Let's enable it and see what happens.
>
> Credit to Mark Kettenis who fixed this
Hi,
[auto build test ERROR on next-20160523]
[cannot apply to drm-intel/for-linux-next v4.6-rc7 v4.6-rc6 v4.6-rc5 v4.6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915
Doing a page flip right after setcrtc would fail because part of the update is
run
asynchronously. This is a regression and is caused kms_flip to fails without
the atomic page flip patch, and kms_frontbuffer_tracking to fail on
ro-bdw-i7-5600u.
Signed-off-by: Maarten Lankhorst
---
Oops, strippe
Hi,
[auto build test ERROR on next-20160523]
[cannot apply to drm-intel/for-linux-next v4.6-rc7 v4.6-rc6 v4.6-rc5 v4.6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915
Doing a page flip right after setcrtc would fail because part of the update is
run
asynchronously. This is a regression and is caused kms_flip to fails without
the atomic page flip patch, and kms_frontbuffer_tracking to fail on
ro-bdw-i7-5600u.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/
With nonblocking unpin there can be many cursor pins before they're
cleared by the next page flip.
Fix this by extending pin_count to the full 32-bit to prevent a
WARN_ON(vma->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT)
Cc: Ville Syrjälä
Reported-by: Chris Wilson
Signed-off-by: Maarten Lank
Some small fixes to make CI more happy.
First is a fix to make all blocking calls wait for update to complete, so any
call
done right doesn't have to block on it or return -EBUSY.
pin_count was limited to 15, so many cursor updates in a single vblank would
cause it to reach the limit
and a warn
On 20/05/16 12:15, Patchwork wrote:
== Series Details ==
Series: Enable GuC submission (rev3)
URL : https://patchwork.freedesktop.org/series/7153/
State : failure
== Summary ==
Series 7153v3 Enable GuC submission
http://patchwork.freedesktop.org/api/1.0/series/7153/revisions/3/mbox
Test dr
On 20/05/2016 11:42, Tvrtko Ursulin wrote:
From: Dave Gordon
Split the function of "enable_guc_submission" into two separate
options. The new one ("enable_guc_loading") controls only the
*fetching and loading* of the GuC firmware image. The existing
one is redefined to control only the *use* o
One of the uses for i915_gem_objects is pin-pointing leaks. For this, we
can compare the number of allocated objects and who owns them, a
discrepancy here often indicates a kernel bug. One allocator of unreported
objects is for backing context objects, so include those in the listing.
v2: Take fil
From: Ville Syrjälä
Allocate 8 distinct looking fbs for the basic flip test, and while
flipping, check that the crc for each frame is as expected. If we
were to present the wrong framebuffer by accident, this should catch it.
v2: Just igt_warn() instead of igt_require() for unique crc check (Dan
On Mon, May 23, 2016 at 01:31:25PM +0100, Tvrtko Ursulin wrote:
>
> On 23/05/16 12:34, Chris Wilson wrote:
>
> Blah blah blah, this, for that, etc... commit message ofc. :)
>
> >Signed-off-by: Chris Wilson
> >Cc: Tvrtko Ursulin
> >Cc: Joonas Lahtinen
> >---
> > drivers/gpu/drm/i915/i915_debu
On 23/05/16 12:34, Chris Wilson wrote:
Blah blah blah, this, for that, etc... commit message ofc. :)
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 35 +++
1 file changed, 35 insertions(+)
diff
On 23/05/16 13:16, Chris Wilson wrote:
On Mon, May 23, 2016 at 01:09:02PM +0100, Tvrtko Ursulin wrote:
@@ -426,6 +401,26 @@ int i915_gem_context_init(struct drm_device *dev)
return PTR_ERR(ctx);
}
+ if (ctx->legacy_hw_ctx.rcs_state) {
+ int ret;
+
+
Noticed while discussing CRC tests with Ville that this was totally
wrong.
v2: Ville pointed out that it only does not block when opened using
igt_pipe_crc_new_nonblocking. Still different from
igt_pipe_crc_collect_crc, which will always block.
v3: Fix type (Ville).
Cc: Ville Syrjälä
Acked-by:
On 23/05/16 12:34, Chris Wilson wrote:
Print the context's owner (via the pid under file_priv) under debugfs.
In doing so, we must be careful that the filp is not accessed after it
is freed (notified via i915_gem_context_close).
v2: Mark the file_priv as closed.
Signed-off-by: Chris Wilson
Cc
On Mon, May 23, 2016 at 01:09:02PM +0100, Tvrtko Ursulin wrote:
> >@@ -426,6 +401,26 @@ int i915_gem_context_init(struct drm_device *dev)
> > return PTR_ERR(ctx);
> > }
> >
> >+if (ctx->legacy_hw_ctx.rcs_state) {
> >+int ret;
> >+
> >+/* We may need to do
On Mon, May 23, 2016 at 01:50:47PM +0300, Mika Kahola wrote:
> Read from DPCD receiver capability field the max allowed
> pixel clock and bits per component for DP to VGA converter.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/drm_dp_helper.c | 46
> ++
On 23/05/16 12:34, Chris Wilson wrote:
Rather than have every context ask "am I owned by the kernel? pin!",
move that logic into the creator of the kernel context, in order to
improve code comprehension.
v2: Throw away the user_handle on failure to allocate the ppgtt.
Signed-off-by: Chris Wils
== Series Details ==
Series: series starting with [v2,01/11] drm/i915: Rename struct intel_context
URL : https://patchwork.freedesktop.org/series/7564/
State : success
== Summary ==
Series 7564v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7564/revisions/1/mbox
On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> This video pattern test function gets invoked through the
> compliance test handler on a HPD short pulse if the test type is
> set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
> reads to read the requested test pattern, video p
From: Ville Syrjälä
Allocate 8 distinct looking fbs for the basic flip test, and while
flipping, check that the crc for each frame is as expected. If we
were to present the wrong framebuffer by accident, this should catch it.
Signed-off-by: Ville Syrjälä
---
tests/kms_flip.c | 126
Just move the kernel_context member of drm_i915_private next to the
engines it is associated with.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h| 3 +--
drivers/gpu/drm/i915/i915_guc_submission.c
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 30cb26fe2fa9..3d14
i915_gem_context_get() is a very simple wrapper around idr_find(), so
simple that it would be smaller to do the lookup inline. Also we use the
verb 'lookup' to return a pointer from a handle, freeing 'get' to imply
obtaining a reference to the context.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursul
Rather than have every context ask "am I owned by the kernel? pin!",
move that logic into the creator of the kernel context, in order to
improve code comprehension.
v2: Throw away the user_handle on failure to allocate the ppgtt.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtine
We want to give a name to the currently anonymous per-engine struct
inside the context, so that we can assign it to a local variable and
save clumsy typing. The name we have chosen is intel_context as it
reflects the HW facing portion of the context state (the logical context
state, the registers,
Pack the integers and related types together inside the struct.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/
Markup the functions that require the caller to hold struct_mutex with
lockdep_assert_held(). In the hopefully not-too-distant future we will
split the struct_mutex up, and in doing so we need to be sure that we
know what it protects - here the lockdep annotations are invaluable.
Signed-off-by: Ch
Print the context's owner (via the pid under file_priv) under debugfs.
In doing so, we must be careful that the filp is not accessed after it
is freed (notified via i915_gem_context_close).
v2: Mark the file_priv as closed.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
Our goal is to rename the anonymous per-engine struct beneath the
current intel_context. However, after a lively debate resolving around
the confusion between intel_context_engine and intel_engine_context, the
realisation is that the two structs target different users. The outer
struct is API / use
struct intel_context contains two substructs, one for the legacy RCS and
one for every execlists engine. Since legacy RCS is a subset of the
execlists engine support, just combine the two substructs.
v2: Only pin the default context for legacy mode (the object only exists
for legacy, but adding i9
The essence of this series is to just rename the anonymous struct inside
intel_context. But since it involves churn, I added some sweetner into
the miex (and more churn)!
[PATCH v2 04/11] drm/i915: Rename i915_gem_context_reference/unreference()
Long term plan is to migrate all of our reference
As these are wrappers around kref_get/kref_put() it is preferable to
follow the naming convention and use the same verb get/put in our
wrapper names for manipulating a reference to the context.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv
== Series Details ==
Series: drm/i915: DP branch devices (rev3)
URL : https://patchwork.freedesktop.org/series/6658/
State : success
== Summary ==
Series 6658v3 drm/i915: DP branch devices
http://patchwork.freedesktop.org/api/1.0/series/6658/revisions/3/mbox
Test gem_exec_flush:
Subgr
On Mon, May 23, 2016 at 11:55:16AM +0100, Tvrtko Ursulin wrote:
>
> On 23/05/16 11:17, Chris Wilson wrote:
> >On Mon, May 23, 2016 at 10:26:39AM +0100, Tvrtko Ursulin wrote:
> >>>@@ -385,20 +384,18 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
> >>>* for now who owns a GuC cl
On 23/05/16 11:17, Chris Wilson wrote:
On Mon, May 23, 2016 at 10:26:39AM +0100, Tvrtko Ursulin wrote:
@@ -385,20 +384,18 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
* for now who owns a GuC client. But for future owner of GuC
* client, need to make
SW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x50A.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 5 +
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel
For DP branch devices DPCD register may define the max supported
pixel rate for VGA dongles. This patch adds a check if DPCD register
value is less than current setting for pixel rate.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 22 ++
include/drm/drm_dp_
HW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x509.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 5 +
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel
Read from DPCD receiver capability field for the
DP to Wireless converter. The only supported wireless
technology on DP1.3 spec is WiGig display extension. If WiGig
display extension is present, then read out the
- number of wde tx on device
- the number of wde txs that can be concurrently activ
Read device ID for DisplayPort branch devices. The device
ID is defined in DPCD register 0x503 and it is mandatory field
for DP branch devices.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 8 insertions(+)
dif
Read from DPCD receiver capability field for DP to HDMI
converter. The features for DP to HDMI converter are
- max TMDS characther clock rate
- max bits per component
- support for conversion from 3D frame sequential to frame pack
- support for YCBCR422 pass through
- support for YCBCR420 pas
Read from DPCD receiver capability field for the
DP++ devices. The features are
- max TMDS charachter clock
- max bits per component
- support for conversion from 3D frame sequential to
frame pack
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 4
include/drm/drm_dp
Read DisplayPort branch device info from through debugfs
interface.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/i915_debugfs.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debug
Prep work to improve DP branch device handling.
Filter out a mode that exceeds the max pixel rate setting
for DP to VGA dongle. This is defined in DPCD register 0x81
if detailed cap info i.e. info field is 4 bytes long and
it is available for DP downstream port.
The register defines the pixel rat
Read from DPCD receiver capability field for the following
features:
- max TMDS clock rate
- max bits per component
- single or dual link support
- high color depth support
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 5 +
include/drm/drm_dp_helper.h | 14 +++
Read from DPCD receiver capability field the max allowed
pixel clock and bits per component for DP to VGA converter.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 46
drivers/gpu/drm/i915/intel_drv.h | 2 ++
include/drm/drm_dp_helper.
Prep work for DP branch device handling
This series of patches reads DPCD register 0x80h for receiver
capabilities for DP branch devices. The branch device types are
converters for the following standards
- DP to VGA
- DP to DVI
- DP to HDMI
- DP++ dual mode
- Wireless WiGig
DPCD register
1 - 100 of 137 matches
Mail list logo
