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 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, 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, 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
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, 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: 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
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
== 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
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
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
== 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
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
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.
> >>
>
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
== 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
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 [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
== 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
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: 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 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
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 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 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 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 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 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 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
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 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
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
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, 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
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
== 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
== 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
101 - 137 of 137 matches
Mail list logo
