On Fri, Jun 06, 2014 at 08:38:36AM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> Bunch of stuff for 3.16 still:
> - Mipi dsi panel support for byt. Finally! From Shobhit&others. I've
> squeezed this in since it's a regression compared to vbios and we've
> been ridiculed about it a bit too often .
Hi
On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> Otherwise the loop will never stop since we don't make any
> forward progress. Noticed while breaking this accidentally
> in a painful attempt to make vga_con unregistering work.
>
> With this patch we'll bail out on the first attempt, whi
Hi
On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> I don't fully understand the magic of the vt register/unregister
> logic, but apparently everything but the inital console (as set
> in the conswitchp pointer) is marked with FLAG_MODULE. Which means
> if something unregistered the boot vt
Hi
On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> A bunch of issues:
> - We should not kick out the default console (which is tracked in
> conswitchp), so check for that.
> - Add better error codes so callers can differentiate between "something
> went wrong" and "your driver isn't re
Hi
On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> Touching the VGA resources on an IVB EFI machine causes hard hangs when
> we then kick out the efifb. Ouch.
>
> Apparently this also prevents unclaimed register errors on hsw and
> hard machine hangs on my i855gm when trying to unbind fbco
On Fri, Jun 06, 2014 at 09:28:03AM +0200, David Herrmann wrote:
> Hi
>
> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> > Touching the VGA resources on an IVB EFI machine causes hard hangs when
> > we then kick out the efifb. Ouch.
> >
> > Apparently this also prevents unclaimed register
On Fri, Jun 06, 2014 at 09:16:13AM +0200, David Herrmann wrote:
> Hi
>
> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> > I don't fully understand the magic of the vt register/unregister
> > logic, but apparently everything but the inital console (as set
> > in the conswitchp pointer) is
On Fri, Jun 06, 2014 at 09:24:35AM +0200, David Herrmann wrote:
> Hi
>
> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> > A bunch of issues:
> > - We should not kick out the default console (which is tracked in
> > conswitchp), so check for that.
> > - Add better error codes so callers
On Thu, Jun 05, 2014 at 01:49:34PM -0700, Jesse Barnes wrote:
> This may take awhile (~10ms), and we don't need to make noise about it.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=75244
> Tested-by: huax...@intel.com
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/int
On Thu, Jun 05, 2014 at 05:02:31PM -0700, Matt Roper wrote:
> On Thu, Jun 05, 2014 at 07:16:03PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Make the intel_{enable,disable}_primary_hw_plane() simply call
> > .update_primary_plane(), thus eliminating the rmw from th
On Thu, Jun 05, 2014 at 11:33:55PM +0200, Thomas Richter wrote:
> Update on the 830MG Updates:
>
> As Ville already said, resume from "suspend-to-ram" is broken. No
> surprise, old broken bios. However, there is a big difference between
> the kernel with the pipe-A quirk disabled, and the one wi
Hi
On Fri, Jun 6, 2014 at 9:56 AM, Daniel Vetter wrote:
> On Fri, Jun 06, 2014 at 09:24:35AM +0200, David Herrmann wrote:
>> Hi
>>
>> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
>> > A bunch of issues:
>> > - We should not kick out the default console (which is tracked in
>> > conswit
On Fri, Jun 06, 2014 at 08:22:08AM +0200, Daniel Vetter wrote:
> Otherwise we incur an unsightly WARNING. The mutex locking is a bit
> overkill, but it curbs races and eventially we might grow a locking
> check in the vblank wait code to make sure the right crtc lock is
> held.
>
> This is fallout
Now that we have a release hook into i915_gem_object_free, we can move
the explicit call to the internal stolen function and hook it up
throught the callback instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 1 -
drivers/gpu/drm/i915/i915_gem.c| 1 -
dri
If a semaphore is waiting on another ring, which in turn happens to be
waiting on the first ring, but that second semaphore has been signalled,
we will be able to kick the second ring and so can treat the first ring
as a valid WAIT and not as HUNG.
v2: Be paranoid and cap the potential recursion d
On Fri, Jun 06, 2014 at 11:57:10AM +0300, Ville Syrjälä wrote:
> On Fri, Jun 06, 2014 at 08:22:08AM +0200, Daniel Vetter wrote:
> > Otherwise we incur an unsightly WARNING. The mutex locking is a bit
> > overkill, but it curbs races and eventially we might grow a locking
> > check in the vblank wai
It causes black screen on bootup and is approximately 100x slower than
running with FBC disabled, so the GPU runs at a high frequency for much
longer - completely contrary to the power saving claims. It also still
has mutex deadlocks in multi-head scenarios, which can lead to a
system/X lockup. The
On Fri, Jun 06, 2014 at 10:47:25AM +0200, David Herrmann wrote:
> Hi
>
> On Fri, Jun 6, 2014 at 9:56 AM, Daniel Vetter wrote:
> > On Fri, Jun 06, 2014 at 09:24:35AM +0200, David Herrmann wrote:
> >> Hi
> >>
> >> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter
> >> wrote:
> >> > A bunch of issues:
On Thu, 05 Jun 2014, Daniel Vetter wrote:
> On Wed, Jun 04, 2014 at 03:29:41PM -0700, clinton.a.tay...@intel.com wrote:
>> From: Clint Taylor
>>
>> Remove OUI read function from the lower half interrupt handler. Upon
>> closing the eDP panel lid an HPD interrupt is generated. The lower half
>> h
I don't fully understand the magic of the vt register/unregister
logic, but apparently everything but the inital console (as set
in the conswitchp pointer) is marked with FLAG_MODULE. Which means
if something unregistered the boot vt driver (e.g. i915.ko kicking
out vga_con) there's nothing left wh
Atm, the forcewake refcount will be incorrectly set to zero during
system suspend if there is any reference held via the
i915_forcewake_user debugfs entry.
Fix this by simply not zeroing the sw counters during suspend and
restoring the original state using them. Note that the only other
places whe
If the timer putting the last forcewake refcount was pending and we
canceled it, we'll leak the corresponding forcewake and RPM references.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_uncore.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/
On Fri, Jun 06, 2014 at 12:59:38PM +0300, Imre Deak wrote:
> If the timer putting the last forcewake refcount was pending and we
> canceled it, we'll leak the corresponding forcewake and RPM references.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 13 ++---
>
Chris Wilson writes:
> If a semaphore is waiting on another ring, which in turn happens to be
> waiting on the first ring, but that second semaphore has been signalled,
> we will be able to kick the second ring and so can treat the first ring
> as a valid WAIT and not as HUNG.
>
> v2: Be paranoid
If the timer putting the last forcewake refcount was pending and we
canceled it, we'll leak the corresponding forcewake and RPM references.
v2:
- do the ptr casting at the caller instead of adding a separate helper
for this (Chris)
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_uncor
On Thu, 05 Jun 2014, Jesse Barnes wrote:
> Some machines may have a broken VBT or no VBT at all, but we still want
> to use SSC there. So check for it and keep it enabled if we see it
> already on. Based on an earlier fix from Kristian.
>
> v2: honor modparam if set too (Daniel)
> read out a
On Fri, Jun 06, 2014 at 02:04:21PM +0300, Jani Nikula wrote:
> Do we have any need to differentiate between this and what VBT has? We
> could just treat dev_priv->vbt as "VBT or what BIOS did", and do
> dev_priv->vbt.lvds_use_ssc = true; here, possibly with a
> DRM_DEBUG_KMS. It would simplify code
On Fri, Jun 06, 2014 at 02:04:37PM +0300, Imre Deak wrote:
> If the timer putting the last forcewake refcount was pending and we
> canceled it, we'll leak the corresponding forcewake and RPM references.
>
> v2:
> - do the ptr casting at the caller instead of adding a separate helper
> for this (
On Thu, 05 Jun 2014, Jesse Barnes wrote:
> Let them eat mincemeat pie.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_params.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.
Even though we should not try to use 4+GiB GTTs on 32-bit systems, by
using a local variable we can future proof the code whilst making it
easier to read.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 23 ++-
1 file changed, 10 insertions(+),
On Thu, 2014-06-05 at 16:58 +0200, Daniel Vetter wrote:
> The global gtt is setup up in 2 parts, so we need to be careful
> with the cleanup. For consistency shovel it all into the ->cleanup
> callback, like with ppgtt.
>
> Noticed because it blew up in the out_gtt: cleanup code while
> fiddling w
On Tue, 20 May 2014, Jesse Barnes wrote:
> On Tue, 29 Apr 2014 23:30:49 +0300
> Jani Nikula wrote:
>
>> Historically we've exposed the full backlight PWM duty cycle range to
>> the userspace, in the name of "mechanism, not policy". However, it turns
>> out there are both panels and board designs
Hi,
On 06/05/2014 10:24 PM, Chris Wilson wrote:
> On Thu, Jun 05, 2014 at 09:08:33PM +0200, Hans de Goede wrote:
>> Note that it is read after the framebuffer has been resized and a new mode
>> has been set on "pipe 0 using LVDS1", could this perhaps cause the 0 to be
>> read when using actual_bri
Hi,
On 06/05/2014 10:24 PM, Chris Wilson wrote:
> On Thu, Jun 05, 2014 at 09:08:33PM +0200, Hans de Goede wrote:
>> Note that it is read after the framebuffer has been resized and a new mode
>> has been set on "pipe 0 using LVDS1", could this perhaps cause the 0 to be
>> read when using actual_bri
On Fri, Jun 06, 2014 at 04:37:36PM +0200, Hans de Goede wrote:
> Hi,
>
> On 06/05/2014 10:24 PM, Chris Wilson wrote:
> > On Thu, Jun 05, 2014 at 09:08:33PM +0200, Hans de Goede wrote:
> >> Note that it is read after the framebuffer has been resized and a new mode
> >> has been set on "pipe 0 using
On Fri, 6 Jun 2014 11:29:24 +0300
Ville Syrjälä wrote:
> On Thu, Jun 05, 2014 at 01:49:34PM -0700, Jesse Barnes wrote:
> > This may take awhile (~10ms), and we don't need to make noise about it.
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=75244
> > Tested-by: huax...@intel.c
On Fri, May 30, 2014 at 04:22:10PM -0700, Tom.O'rou...@intel.com wrote:
> From: Tom O'Rourke
>
> Add Broadwell support to i915_frequency_info
> and extend i915_max|min_freq_get|set to (gen >= 6).
>
> v2: generalized support for i915_max|min_freq_get|set (Daniel).
>
> Signed-off-by: Tom O'Rourke
Tomi/Jean can you please ack merging this through drm-intel trees? It
just exports the vga and dummy consoles so that i915 can do what it
needs to do.
Thanks, Daniel
On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> Touching the VGA resources on an IVB EFI machine causes hard hangs when
> w
On Wed, Jun 04, 2014 at 06:58:47PM +0200, Sedat Dilek wrote:
> How do I see if DRI3 is enabled for mesa on my SandyBridge intel-gfxcard?
>
> glxinfo log-file attached...
>
> $ LC_ALL=C LIBGL_DEBUG=verbose glxinfo 2> /dev/null > /tmp/glxinfo.txt
You threw out the information you wanted by red
On Fri, Jun 06, 2014 at 11:40:50AM +0200, Daniel Vetter wrote:
> On Fri, Jun 06, 2014 at 10:47:25AM +0200, David Herrmann wrote:
> > Hi
> >
> > On Fri, Jun 6, 2014 at 9:56 AM, Daniel Vetter wrote:
> > > On Fri, Jun 06, 2014 at 09:24:35AM +0200, David Herrmann wrote:
> > >> Hi
> > >>
> > >> On Thu
On Fri, Jun 06, 2014 at 10:37:11AM +0100, Chris Wilson wrote:
> It causes black screen on bootup and is approximately 100x slower than
> running with FBC disabled, so the GPU runs at a high frequency for much
> longer - completely contrary to the power saving claims. It also still
> has mutex deadl
On Fri, Jun 06, 2014 at 10:22:54AM +0100, Chris Wilson wrote:
> Now that we have a release hook into i915_gem_object_free, we can move
> the explicit call to the internal stolen function and hook it up
> throught the callback instead.
>
> Signed-off-by: Chris Wilson
Oh, pretty!
Queued for -next
On Thu, Jun 05, 2014 at 08:48:37AM -0700, Jesse Barnes wrote:
> In digging into the async crtc stuff, I found it was going to be really
> difficult to prevent other functions from getting clobbered by a delayed
> crtc enable or disable. Daniel's work to remove a bunch of the
> ->mode_set callbacks
On 06/05/2014 02:26 AM, Daniel Vetter wrote:
On Wed, Jun 04, 2014 at 03:29:41PM -0700, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
Remove OUI read function from the lower half interrupt handler. Upon
closing the eDP panel lid an HPD interrupt is generated. The lower half
handler calls
On Thu, Jun 05, 2014 at 09:43:12PM +0100, Chris Wilson wrote:
> On Thu, Jun 05, 2014 at 07:15:50PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Using names initializers when filling out the watermark structs
> > saves you from having go look up the struct definition
On Thu, Jun 05, 2014 at 07:15:52PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Certain DVO chips (ns2501 for example) don't like to be accessed unless
> the PLL is running. Simply skip the DVO get_hw_state if the DVO port
> is disabled.
>
> Signed-off-by: Ville Syrjälä
On Thu, Jun 05, 2014 at 07:15:53PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On Fujitsu-Siememens S6010 the ns2501 chip is hooked up to DVOB instead
> of DVOC.
>
> FIXME: Maybe need to dig out the correct DVO port from VBT
Well we could have 2 match structs for dvoc
On Thu, Jun 05, 2014 at 07:15:58PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> My Fujitsu-Siemens Lifebook S6010 definitely has a VGA connector, but
> the VBT says different. Ignore the VBT for 830M since it seems such
> old machines would generally have a VGA connector.
On Fri, 6 Jun 2014 18:36:46 +0200
Daniel Vetter wrote:
> On Thu, Jun 05, 2014 at 08:48:37AM -0700, Jesse Barnes wrote:
> > In digging into the async crtc stuff, I found it was going to be really
> > difficult to prevent other functions from getting clobbered by a delayed
> > crtc enable or disabl
On Fri, May 30, 2014 at 04:22:10PM -0700, Tom.O'rou...@intel.com wrote:
> From: Tom O'Rourke
>
> Add Broadwell support to i915_frequency_info
> and extend i915_max|min_freq_get|set to (gen >= 6).
>
> v2: generalized support for i915_max|min_freq_get|set (Daniel).
>
> Signed-off-by: Tom O'Rourke
On Fri, Jun 06, 2014 at 08:22:08AM +0200, Daniel Vetter wrote:
> + mutex_lock(&crtc->base.mutex);
> + if (crtc->active)
> + intel_wait_for_vblank(dev, pipe);
> + mutex_unlock(&crtc->base.mutex);
drivers/gpu/drm/i915/i915_debugfs.c: In functio
On Thu, Jun 05, 2014 at 08:31:47PM +0300, Imre Deak wrote:
> Jesse noticed that the punit communication needed to query the VLV power
> well status can cause substantial delays. Since we can query the state
> frequently, for example during I2C transfers, maintain a cached version
> of the HW state
pipe_name() returns an ascii character.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 088fe93..27975c3 100644
--- a/drivers/gp
Hi Ville, hi others,
As Ville already said, resume from "suspend-to-ram" is broken. No
surprise, old broken bios. However, there is a big difference between
the kernel with the pipe-A quirk disabled, and the one with pipe-a and
pipe-b quirks enabled: If resumed without the quirk, the display is
On Thu, Jun 05, 2014 at 10:40:29AM -0700, Clint Taylor wrote:
> On 06/05/2014 02:26 AM, Daniel Vetter wrote:
> >On Wed, Jun 04, 2014 at 03:29:41PM -0700, clinton.a.tay...@intel.com wrote:
> >>From: Clint Taylor
> >>
> >>Remove OUI read function from the lower half interrupt handler. Upon
> >>closi
On Fri, 2014-06-06 at 19:19 +0200, Daniel Vetter wrote:
> On Thu, Jun 05, 2014 at 08:31:47PM +0300, Imre Deak wrote:
> > Jesse noticed that the punit communication needed to query the VLV power
> > well status can cause substantial delays. Since we can query the state
> > frequently, for example du
On Fri, 06 Jun 2014, Damien Lespiau wrote:
> pipe_name() returns an ascii character.
Reviewed-by: Jani Nikula
After all these fixes... maybe we should make it a string? It could take
EDP into account too. For a rainy day.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_
On Fri, Jun 06, 2014 at 06:18:01PM +0100, Damien Lespiau wrote:
> On Fri, Jun 06, 2014 at 08:22:08AM +0200, Daniel Vetter wrote:
> > + mutex_lock(&crtc->base.mutex);
> > + if (crtc->active)
> > + intel_wait_for_vblank(dev, pipe);
> > + mutex_unlock(&c
On Fri, Jun 06, 2014 at 06:22:06PM +0100, Damien Lespiau wrote:
> pipe_name() returns an ascii character.
>
> Signed-off-by: Damien Lespiau
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
On Fri, Jun 06, 2014 at 12:08:43PM +0100, Chris Wilson wrote:
> On Fri, Jun 06, 2014 at 02:04:37PM +0300, Imre Deak wrote:
> > If the timer putting the last forcewake refcount was pending and we
> > canceled it, we'll leak the corresponding forcewake and RPM references.
> >
> > v2:
> > - do the pt
On Fri, Jun 06, 2014 at 08:37:48PM +0300, Imre Deak wrote:
> On Fri, 2014-06-06 at 19:19 +0200, Daniel Vetter wrote:
> > On Thu, Jun 05, 2014 at 08:31:47PM +0300, Imre Deak wrote:
> > > Jesse noticed that the punit communication needed to query the VLV power
> > > well status can cause substantial
On 06/06/2014 02:41 AM, Jani Nikula wrote:
On Thu, 05 Jun 2014, Daniel Vetter wrote:
On Wed, Jun 04, 2014 at 03:29:41PM -0700, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
Remove OUI read function from the lower half interrupt handler. Upon
closing the eDP panel lid an HPD interrupt
On Fri, 2014-06-06 at 19:46 +0200, Daniel Vetter wrote:
> On Fri, Jun 06, 2014 at 12:08:43PM +0100, Chris Wilson wrote:
> > On Fri, Jun 06, 2014 at 02:04:37PM +0300, Imre Deak wrote:
> > > If the timer putting the last forcewake refcount was pending and we
> > > canceled it, we'll leak the correspo
From: Ville Syrjälä
My Fujitsu-Siemens Lifebook S6010 definitely has a VGA connector, but
the VBT says different. Ignore the VBT for 830M since it seems such
old machines would generally have a VGA connector.
This is a regression caused by:
commit 9c2a03c2a194c086949f25d332937ac8dc4d9f7e
Autho
From: Ville Syrjälä
Move the entire DSPCNTR register setup into the .update_primary_plane()
functions. That's where it belongs anyway and it'll also help 830M which
has the extra problem that plane registers reads will return the value
latched at the last vblank, not the value that was last writt
From: Ville Syrjälä
Make the intel_{enable,disable}_primary_hw_plane() simply call
.update_primary_plane(), thus eliminating the rmw from these functions
which should help the poor old 830M.
Now we can also remove the .update_primary_plane() from the
.crtc_enable() hooks because we end up callin
From: Ville Syrjälä
My Fujistsu-Siemens Lifebook S6010 doesn't like to resume from
S3 unless VGACNTR has been restore to the original value. The BIOS
value in this case was 0x0124008E. Setting the "VGA disable" bit
doesn't interfere with the S3 resume fortunately.
Signed-off-by: Ville Syrjälä
-
From: Ville Syrjälä
Disable double wide even if the pipe quirk compels us to leave the
pipe running. Double wide has certain implications for the plane
assignments so best keep it off.
Also helps resuming from S3 on the Fujitsu-Siemens Lifebook S6010
when double wide was enabled prior to suspend
From: Ville Syrjälä
Just pass the intel_crtc around instead of dev_priv+pipe.
Also make intel_wait_for_pipe_off() static since it's only used in
intel_display.c.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 37 +---
drivers/gpu/drm/i9
On Fri, Jun 6, 2014 at 5:47 PM, Jamey Sharp wrote:
> On Wed, Jun 04, 2014 at 06:58:47PM +0200, Sedat Dilek wrote:
>> How do I see if DRI3 is enabled for mesa on my SandyBridge intel-gfxcard?
>>
>> glxinfo log-file attached...
>>
>> $ LC_ALL=C LIBGL_DEBUG=verbose glxinfo 2> /dev/null > /tmp/glx
On Fri, 06 Jun 2014, Clint Taylor wrote:
> On 06/06/2014 02:41 AM, Jani Nikula wrote:
>> On Thu, 05 Jun 2014, Daniel Vetter wrote:
>>> On Wed, Jun 04, 2014 at 03:29:41PM -0700, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
Remove OUI read function from the lower half interr
On Fri, Jun 06, 2014 at 07:24:02PM +0200, Thomas Richter wrote:
> Hi Ville, hi others,
>
> >> As Ville already said, resume from "suspend-to-ram" is broken. No
> >> surprise, old broken bios. However, there is a big difference between
> >> the kernel with the pipe-A quirk disabled, and the one wit
On Fri, Jun 06, 2014 at 10:44:12PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> My Fujitsu-Siemens Lifebook S6010 definitely has a VGA connector, but
> the VBT says different. Ignore the VBT for 830M since it seems such
> old machines would generally have a VGA connector.
On 7 June 2014 05:54, Jani Nikula wrote:
> On Fri, 06 Jun 2014, Clint Taylor wrote:
>> On 06/06/2014 02:41 AM, Jani Nikula wrote:
>>> On Thu, 05 Jun 2014, Daniel Vetter wrote:
On Wed, Jun 04, 2014 at 03:29:41PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> R
On Fri, Jun 06, 2014 at 09:38:26PM +0300, Imre Deak wrote:
> On Fri, 2014-06-06 at 19:46 +0200, Daniel Vetter wrote:
> > On Fri, Jun 06, 2014 at 12:08:43PM +0100, Chris Wilson wrote:
> > > On Fri, Jun 06, 2014 at 02:04:37PM +0300, Imre Deak wrote:
> > > > If the timer putting the last forcewake ref
On Sat, Jun 07, 2014 at 06:14:42AM +1000, Dave Airlie wrote:
> My edp panel bits are all cut-n-paste anyways. maybe we should hold the
> edp on for long periods around that whole probing.
We have a delayed put on the edp panel power. So keeping it just around
the bits where we need it doesn't have
On Fri, 2014-06-06 at 22:15 +0200, Daniel Vetter wrote:
> On Fri, Jun 06, 2014 at 09:38:26PM +0300, Imre Deak wrote:
> > On Fri, 2014-06-06 at 19:46 +0200, Daniel Vetter wrote:
> > > On Fri, Jun 06, 2014 at 12:08:43PM +0100, Chris Wilson wrote:
> > > > On Fri, Jun 06, 2014 at 02:04:37PM +0300, Imre
On Fri, Jun 06, 2014 at 08:51:31AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Jun 06, 2014 at 11:40:50AM +0200, Daniel Vetter wrote:
> > On Fri, Jun 06, 2014 at 10:47:25AM +0200, David Herrmann wrote:
> > > Hi
> > >
> > > On Fri, Jun 6, 2014 at 9:56 AM, Daniel Vetter wrote:
> > > > On Fri, Jun 06
Hi all,
New -testing cycle with cool stuff, first one for 3.17:
- rps/turbo support for chv (Deepak)
- some other straggling chv patches (Ville)
- proper universal plane conversion for the primary plane (Matt Roper)
- ppgtt on vlv from Jesse
- pile of cleanups, little fixes for insane corner cases
On Fri, Jun 06, 2014 at 11:19:28PM +0300, Imre Deak wrote:
> On Fri, 2014-06-06 at 22:15 +0200, Daniel Vetter wrote:
> > On Fri, Jun 06, 2014 at 09:38:26PM +0300, Imre Deak wrote:
> > > On Fri, 2014-06-06 at 19:46 +0200, Daniel Vetter wrote:
> > > > On Fri, Jun 06, 2014 at 12:08:43PM +0100, Chris W
On Fri, 2014-06-06 at 22:35 +0200, Daniel Vetter wrote:
> On Fri, Jun 06, 2014 at 11:19:28PM +0300, Imre Deak wrote:
> > On Fri, 2014-06-06 at 22:15 +0200, Daniel Vetter wrote:
> > > On Fri, Jun 06, 2014 at 09:38:26PM +0300, Imre Deak wrote:
> > > > On Fri, 2014-06-06 at 19:46 +0200, Daniel Vetter
On Fri, Jun 6, 2014 at 10:44 PM, Imre Deak wrote:
> Let's say that forcewake timer is pending, holding the runtime pm ref.
> System suspend is called - it's not prevented by either this ref or the
> above autosuspend delay - in the suspend handler we eventually call
> force_wake_reset which cancel
Am 06.06.2014 22:08, schrieb Ville Syrjälä:
Yup, I flashed the bios last week with version 1.07, the latest I could
find on the Fujitsu pages. It was 1.06 before, though I did not observe
any difference between 1.06 and 1.07 with respect to the broken resume
operation.
1.07 is what have as wel
On Fri, 6 Jun 2014 22:44:12 +0300
wrote:
> From: Ville Syrjälä
>
> My Fujitsu-Siemens Lifebook S6010 definitely has a VGA connector, but
> the VBT says different. Ignore the VBT for 830M since it seems such
> old machines would generally have a VGA connector.
>
> This is a regression caused by
On Fri, Jun 06, 2014 at 11:09:53PM +0200, Thomas Richter wrote:
> Am 06.06.2014 22:08, schrieb Ville Syrjälä:
> >> Maybe the bios configuration between yours and mine is different?
> >
> > I tried disabling everything extra from the BIOS. No dice.
>
> As said, only with the pipe a quirk removed...
On Fri, Jun 06, 2014 at 06:57:43PM +0200, Daniel Vetter wrote:
> On Thu, Jun 05, 2014 at 07:15:53PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > On Fujitsu-Siememens S6010 the ns2501 chip is hooked up to DVOB instead
> > of DVOC.
> >
> > FIXME: Maybe need to dig ou
From: Ville Syrjälä
Disable double wide even if the pipe quirk compels us to leave the
pipe running. Double wide has certain implications for the plane
assignments so best keep it off.
Also helps resuming from S3 on the Fujitsu-Siemens Lifebook S6010
when double wide was enabled prior to suspend
On Fri, Jun 6, 2014 at 11:15 PM, Bob Paauwe wrote:
>> + /* Fujitsu-Siemens Lifebook S6010 VBT lies */
>> + if (IS_I830(dev))
>> + return true;
>
> My old D945GNT board with a 945G and really old BIOS also has a VBT
> that lies about this.
I guess someone needs to dig out vbt d
On Sat, 7 Jun 2014 00:23:08 +0200
Daniel Vetter wrote:
> On Fri, Jun 6, 2014 at 11:15 PM, Bob Paauwe wrote:
> >> + /* Fujitsu-Siemens Lifebook S6010 VBT lies */
> >> + if (IS_I830(dev))
> >> + return true;
> >
> > My old D945GNT board with a 945G and really old BIOS also has
89 matches
Mail list logo
