: Don't try to use SPR_SCALE when we don't have a sprite scaler
drm/i915: VLV does not have a sprite scaler
Daniel Vetter (24):
drm/i915: s/DRM_IRQ_ARGS/int irq, void *arg
drm/i915: move hpd handling to (ibx|cpt)_irq_handler
drm/i915: don't save/restore DP regs for kms
drm
...
I've rechecked the git log and otherwise there's nothing else which
pops up that would fit VT-switching/hibernate going bad but the
modeset rework.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send
without a suspend/resume cycle (since
that's only fixed later on), should otherwise work.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
***
v2: Mark the lockdep_map static, noticed by Jani Nikula.
Cc: Dave Airlie airl...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Alan Cox a...@lxorguk.ukuu.org.uk
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
kernel/printk.c |9
-sdvox_reg);
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Sat, Sep 22, 2012 at 01:06:29PM -0700, Greg KH wrote:
On Sat, Sep 22, 2012 at 07:52:11PM +0200, Daniel Vetter wrote:
Dave Airlie recently discovered a locking bug in the fbcon layer,
where a timer_del_sync (for the blinking cursor) deadlocks with the
timer itself, since both (want
On Mon, Sep 24, 2012 at 2:24 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, 2012-09-24 at 14:17 +0200, Peter Zijlstra wrote:
On Tue, 2012-09-18 at 01:03 +0200, Daniel Vetter wrote:
- In the printk code there's a special trylock, only used to kick off
the logbuffer printk'ing
callers to IPS state with appropriate locks
Daniel Vetter (12):
drm/i915: rip out early dp port write for gm45/ilk
drm/i915: add encoder-pre_enable/post_disable
drm/i915: clean up the cpu edp pll special case
drm/i915: robustify edp_pll_on/off
drm/i915: rip out dp port
wrong.
Daniel, do you agree with this?
Yeah, seems like the sanest thing to do given the situation and lack
of any understanding what's actually going on.
/me goes back to screaming silently
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Wed, Oct 3, 2012 at 9:45 AM, Thomas Hellstrom thellst...@vmware.com wrote:
On 10/02/2012 10:03 AM, Daniel Vetter wrote:
On Tue, Oct 02, 2012 at 08:46:32AM +0200, Thomas Hellstrom wrote:
On 10/01/2012 11:47 AM, Maarten Lankhorst wrote:
I was doing a evil hack where I 'released' lru_lock
).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
] ? start_kernel+0x3b3/0x3b3
[4.267087] [81471330] ? gs_change+0xb/0xb
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
here.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
applied to drm-intel-next, thanks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
));
mutex_unlock(dev-struct_mutex);
ret = drm_irq_install(dev);
--
1.7.2.1.45.g54fbc
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
, and then grab the i915_error_state
from debugfs? That contains the gpu hang dump we need to diagnose things.
And the bisect would obviously be awesome.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list
On Thu, Oct 4, 2012 at 4:56 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
This should help: https://patchwork.kernel.org/patch/1436231/
It's not merged yet since it cause a black screen on resume on one of
my really old machines. Issue isn't new at all, but the new modeset
code is _much_
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
the way
up like this, I get nothing but no signal after leaving BIOS mode. Turning
the tv on/off, cable plug/unplug does not help.
Can you please boot in that configuration on latest kernel with
drm.debug=0xe added to your kernel cmdline and then attach the
complete dmesg?
Thanks, Daniel
--
Daniel
it there?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
; /* for eDP */
struct delayed_work panel_vdd_work;
bool want_panel_vdd;
struct edid *edid; /* cached EDID for eDP */
--
1.7.7.3
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send
-Chris
well if this means building libdrm etc.. then thats not a problem, more time
consuming if anything. perhaps an *.rpm that I can test to see?
It's not libdrm, the above is just a kernel git tree with a bunch of
ironlake workarounds.
-Daniel
--
Daniel Vetter
Software Engineer, Intel
.
$ git checkout origin/ilk-wa-pile
... and you have the right branch checked out. No need for pitchforks
and witch hunts ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux
in one of the ECC bytes
(since the hw creates it), so we need our own packing code there.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
in such a fashion, so ideas highly welcome. QA people are
cc'ed, and hopefully I haven't missed anyone else on the cc list.
Yours, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux
;
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
=
+ ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP);
return drm_get_pci_dev(pdev, ent, driver);
}
Yours, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
by
accident to the intel graphics? You can check that with lspci -k
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
-Hartman gre...@linuxfoundation.org
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers
On Mon, Oct 15, 2012 at 5:11 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Oct 15, 2012 at 10:11:22AM +0200, Daniel Vetter wrote:
Hi Gregstable-team,
The below patch papers over a graphics corruption issue in 3.5/3.6. The
regression happened due to pwrite tunings in 3.5, which made
that would allocate the dma_buf at the right spot for
all cases, but I think we should consider this to not draw ourselves
into an ugly api corner.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send
On Mon, Oct 15, 2012 at 5:11 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Oct 15, 2012 at 10:11:22AM +0200, Daniel Vetter wrote:
Hi Gregstable-team,
The below patch papers over a graphics corruption issue in 3.5/3.6. The
regression happened due to pwrite tunings in 3.5, which made
: linuxify create_hw_context()
Chris Wilson (2):
drm/i915: Group the GT routines together in both code and vtable
drm/i915: Implement w/a for sporadic read failures on waking from rc6
Daniel Vetter (15):
drm/i915: wrap up gt powersave enabling functions
drm/i915: make enable
is new in -rc6 is the
cause of this or whether we have a bigger problem with the i915 driver
crashing in 3.5-rc.
Thanks, Daniel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
please to that?
Thanks, Daniel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
-...@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
/i915: Resurrect ring kicking for semaphores, selectively
Damien Lespiau (1):
drm/i915: Remove platforms in the preliminary_hw_support description
Daniel Vetter (4):
drm/i915: gen2 has no tv out support
Merge tag 'v3.9-rc3' into drm-intel-next-queued
style nit: Align function
On Mon, Apr 15, 2013 at 09:56:29AM +0200, Daniel Vetter wrote:
Hi Dave,
Since I expect Linus to open the merge window in about a week I guess this
is the last i915 feature pull for 3.10. Highlights:
Updated testing tree for -next. Highlights:
- Corner case fixes discovered with static
On Wed, Apr 10, 2013 at 12:28 AM, Steven Rostedt rost...@goodmis.org wrote:
On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
The thing is now that you're not expected to hold these locks for a
long
time - if you need
of state protected
with mutexes, which all potentially affects the panic handler. So I've
given up on that for now ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
, and I'm still unhappy with all current naming
proposals ;-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On Thu, Apr 4, 2013 at 3:31 PM, Daniel Vetter dan...@ffwll.ch wrote:
In this case when O blocks Y isn't actually blocked, so our
TASK_DEADLOCK wakeup doesn't actually achieve anything.
This means we also have to track (task) state so that once Y tries to
acquire A (creating the actual
On Thu, Apr 4, 2013 at 6:38 PM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the
wait
times of older task.
No, imagine the following:
struct ww_mutex A, B;
struct mutex C
On Thu, Apr 4, 2013 at 6:49 PM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
We've discussed this approach of using (rt-prio, age) instead of just
age
to determine the the oldness of a task for deadlock-breaking with
-EAGAIN. The problem
, and anyone who
signed-off on them in order to get their approval as well?
thanks,
greg k-h
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
:(
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 08, 2013 at 12:39:24PM +0200, Peter Zijlstra wrote:
On Thu, 2013-04-04 at 18:56 +0200, Daniel Vetter wrote:
Presuming I'm still following we should be able to fix this with the
new sleep state TASK_DEADLOCK and a flag somewhere in the thread info
(let's call it PF_GTFO
On Tue, Apr 09, 2013 at 02:54:34PM +0300, Tomas Melin wrote:
On Mon, 18 Mar 2013 09:32:51 +0100, Daniel Vetter wrote:
On Sat, Mar 16, 2013 at 01:28:50PM +0100, Richard Cochran wrote:
I have an Acer Aspire One netbook, and on it I get the following
warning when closing and opening
On Tue, Apr 09, 2013 at 03:21:35PM +0200, Richard Cochran wrote:
On Tue, Apr 09, 2013 at 02:50:03PM +0200, Daniel Vetter wrote:
This should be fixed with the above mentioned patch. The issue is that the
bios fumbles around with the output configuration behind our backs, so the
new
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 34 +++---
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8809813..2959fb8
On Wed, Apr 10, 2013 at 12:27 AM, Steven Rostedt rost...@goodmis.org wrote:
On Thu, Apr 04, 2013 at 06:38:36PM +0200, Peter Zijlstra wrote:
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the
wait
times of older task
On Tue, Apr 09, 2013 at 06:28:08PM -0400, Steven Rostedt wrote:
On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
The thing is now that you're not expected to hold these locks for a
long
time - if you need
On Mon, Apr 08, 2013 at 01:50:26PM +0200, Daniel Vetter wrote:
On Mon, Apr 08, 2013 at 12:39:24PM +0200, Peter Zijlstra wrote:
On Thu, 2013-04-04 at 18:56 +0200, Daniel Vetter wrote:
Presuming I'm still following we should be able to fix this with the
new sleep state TASK_DEADLOCK
On Wed, Apr 10, 2013 at 01:59:02PM +0200, Richard Cochran wrote:
On Tue, Apr 09, 2013 at 09:51:30PM +0200, Daniel Vetter wrote:
It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable
On Wed, Apr 10, 2013 at 7:27 PM, Richard Cochran
richardcoch...@gmail.com wrote:
On Wed, Apr 10, 2013 at 02:07:24PM +0200, Daniel Vetter wrote:
It's written against drm-intel-next-queued at
http://cgit.freedesktop.org/~danvet/drm-intel
I've thought that it should apply pretty cleanly
On Thu, Apr 11, 2013 at 7:52 PM, Richard Cochran
richardcoch...@gmail.com wrote:
On Wed, Apr 10, 2013 at 10:03:25PM +0200, Daniel Vetter wrote:
That patch should crash at all, so this is not expected. Can you pls
check whether plain drm-intel-nightly is broken, too?
I did try drm-intel
Wilson ch...@chris-wilson.co.uk
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers
On Thu, Apr 11, 2013 at 08:17:42PM +0100, Chris Wilson wrote:
On Thu, Apr 11, 2013 at 08:22:50PM +0200, Daniel Vetter wrote:
It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable
On Sun, Mar 31, 2013 at 9:55 PM, Jiri Kosina jkos...@suse.cz wrote:
On Thu, 21 Mar 2013, Daniel Vetter wrote:
Indeed, this is pretty useful and allowed me to quickly reproduce that
phantom irq on my gm45. Thanks to module reloading we can even reset the
kernel's irq disabling logic and so
in the preliminary_hw_support description
Daniel Vetter (4):
drm/i915: gen2 has no tv out support
Merge tag 'v3.9-rc3' into drm-intel-next-queued
style nit: Align function parameter continuation properly.
drm/i915: fixup pd vs pt confusion in gen6 ppgtt code
Imre Deak (5):
drm: handle
a
lock simply do a blocking wait. So ticket/reservation in Maartens
patches is the analog of timestamp/transaction.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
.
But since I have pretty much zero clue about rt I have no idea which
of the first two approaches would be preferable.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
is just what it's used for in graphics-land, so not
that much better. I don't really have a good idea for what this is
besides mutexes_with_magic_deadlock_detection_and_backoff. Which is a
bit long.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
intel_panel_init_backlight(struct drm_device *dev)
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Mon, Mar 11, 2013 at 10:46:31PM -0700, Kees Cook wrote:
This replaces the open-coded divisions in the debugfs code by calls
to do_div().
Signed-off-by: Kees Cook keesc...@chromium.org
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Squashed into the debugfs patch which introduced
for the report (and my apologies for the
little screw-up).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
- count'
is more idiomatic and so preferrable.
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Picked up for -fixes, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line
On Wed, Mar 13, 2013 at 9:28 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Mar 12, 2013 at 09:07:46AM +, Chris Wilson wrote:
On Mon, Mar 11, 2013 at 05:31:45PM -0700, Kees Cook wrote:
It is possible to wrap the counter used to allocate the buffer for
relocation copies. This could lead
mandate that a regression is fixed on
upstream first. Once that's figured out we can backport a fix (if
3.9-rc works) or start working on a fix for 3.8-rc kernels first and
backport afterwards.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http
...). And
the commit above doesn't really change much in the code itself but it
does change the order (and timing) of the different enable/disable
codepaths.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from
need these checks everywhere? Or at least a
fixup in drm core proper?
And I think we need to add trinity to our test setup eventually ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line
. To assign proper blame please cc: relevant people when sending out
reverts.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
? And if you have the regressing commit a little
citation to assign the blame (it's probably me) would be good.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
28c70f162a315bdcfbe0bf940a740ef8bfb918d6
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Sat Dec 1 13:53:45 2012 +0100
drm/i915: use the gmbus irq for waits
Adding Daniel, Imre and Daniel to CC while I will try to figure out
what's
changes the display state behind our back on lid
closing! Should be duct-tapped over with
commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Fri Nov 23 18:16:34 2012 +0100
drm/i915: force restore on lid open
which is in 3.8.
Cheers, Daniel
to revert:
15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9 drm/i915: enable irqs earlier
when resuming
52d7ecedac3f96fb562cb482c139015372728638 drm/i915: reorder setup
sequence to have irqs for output setup
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http
On Mon, Mar 18, 2013 at 10:29:16AM +0100, Takashi Iwai wrote:
At Sun, 17 Mar 2013 23:12:03 +0100,
Daniel Vetter wrote:
On Tue, Mar 12, 2013 at 04:32:28PM +0100, Takashi Iwai wrote:
The eDP output on HP Z1 is still broken when X is started even after
fixing the infinite link-train loop
On Mon, Mar 18, 2013 at 11:05 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Hi Gregall,
So a recent stable backport to fix rc6 on ilk (which is disabled by
default and with dubious power savings at best, unlike rc6 on snb and
later) totally blew up all over the place:
https
16 at all.
that device is using
i915 :00:02.0: irq 44 for MSI/MSI-X
so can you try to boot with pci=nomsi?
Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
interrupts go away.
My understanding from the other mail is that DAniel Vetter already has
signal, we
* need to wake up periodically and check that ourselves. */
--
Jiri Kosina
SUSE Labs
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
= drm_irq_install(dev);
+ if (ret)
+ goto cleanup_gem;
/* Always safe in the mode setting case. */
/* FIXME: do pre/post-mode set stuff in core KMS code */
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe
this particular
elephant in the room.
Signed-off-by: Jiri Kosina jkos...@suse.cz (v1)
Acked-by: Chris Wilson ch...@chris-wilson.co.uk (v1)
References: https://lkml.org/lkml/2013/3/8/325
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
--
Daniel Vetter
Software Engineer, Intel
On Tue, Mar 19, 2013 at 4:38 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 19 Mar 2013, Daniel Vetter wrote:
For reference below the updated commit message.
Cheers, Daniel
Author: Jiri Kosina jkos...@suse.cz
Date: Tue Mar 19 09:56:57 2013 +0100
drm/i915: stop using GMBUS
different tricks quickly without
rebooting. Really useful.
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
Thanks, Daniel
---
drivers/misc/Kconfig |8 ++
drivers/misc/Makefile|1 +
drivers/misc/dummy-irq.c | 59
++
3 files
drm/i915: write backlight harder
The first commit affects no matter whether power well is on or off.
It brings the eDP output always blank.
Can you please attach the xrandr output and drm.debug=0xe dmesg from
booting for that hsw eDP machine quickly?
Thanks, Daniel
--
Daniel Vetter
Software
like to ditch the
dummy page hack we're currently using (i.e. patch 2).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe
Vetter daniel.vet...@ffwll.ch
Later investigations showed that there _is_ lockdep support, it just
doesn't work. Maarten's patch here boils the failure scenario down to
its essence.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
for stolen objects
Both patches are Reviewed-by: Damien Lespiau damien.lesp...@intel.com
Both patches merged, with Imre's missing sob line rectified on the 2nd
one.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list
On Tue, Mar 26, 2013 at 12:57:42PM -0700, Andrew Morton wrote:
On Tue, 26 Mar 2013 15:50:20 +0100 Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Mar 26, 2013 at 03:14:17PM +0200, Imre Deak wrote:
When adding sg_page_iter I haven't thought properly through the use case
for sg lists w/o
power
And so disabled by default. So I hope that regression is bearable,
feel free to beat the drm/i915 guys as usual for their failings ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line
memory for the gfx devices is at on gen2. But tbh I don't mind if we just
keep the #if 0 code around. For all newer platforms we can get at that
offset through mch bar registers, so I don't really care.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http
On Sun, Mar 10, 2013 at 02:22:48PM +0200, Mihnea Dobrescu-Balaur wrote:
Signed-off-by: Mihnea Dobrescu-Balaur mihne...@gmail.com
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe
...@chromium.org
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Queued for -next, thanks for the patch. When sending drm/i915 patches,
please also cc intel-...@lists.freedesktop.org (it's open for
non-subscribers non without nagging you're mail is in the moderation
queue replies).
Thanks, Daniel
---
drivers/gpu
On Mon, Mar 11, 2013 at 02:37:35PM -0700, Kees Cook wrote:
This clarifies the comment above the access_ok check so a missing
VERIFY_READ doesn't alarm anyone.
Signed-off-by: Kees Cook keesc...@chromium.org
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
v2:
- rewrote comment, thanks
...@vger.kernel.org
Picked up for -fixes, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
to the code in
the past few years ;-) Together with our tendecy to track all bug reports
in bugzilla that leads to the oddball useless commit entry in a bug.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from
(DP_TP_CTL(port)) DP_TP_CTL_ENABLE) {
val = I915_READ(DDI_BUF_CTL(port));
--
1.7.9.5
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
1 - 100 of 6575 matches
Mail list logo
