every once a while ...).
--
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.ke
| 14 ++--
21 files changed, 260 insertions(+), 177 deletions(-)
--
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 majo
On Thu, Nov 29, 2012 at 11:12:00AM +0100, Daniel Vetter wrote:
> Besides the big item of lifting the "preliminary hw support" tag from the
> Haswell code, just small bits&pieces all over:
> - Leftover Haswell patches and some fixes from Paulo
> - LyncPoint PCH support
s/gpu/drm/i915/dvo_tfp410.c
> CC [M] drivers/gpu/drm/i915/dvo_tfp410.o
> CHECK drivers/gpu/drm/i915/dvo_sil164.c
> CC [M] drivers/gpu/drm/i915/dvo_sil164.o
> CHECK drivers/gpu/drm/i915/dvo_ns2501.c
> CC [M] drivers/gpu/drm/i915/dvo_ns2501.o
> CHECK drivers/gpu/drm/i9
o? We need
to know this since stable rules 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
with the new code ...). 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
--
t;> So tell me, which case can result in a NULL arg?
>> 1. user size == drv_size // better not be this one
>> 2. user size < driver size
>> 3. user size > driver size
>>
>> It seems to me we still must [simply] be missing something in our
>> parameter valid
27;s his
patch. 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 bod
e
in ironlake_set_m_n? 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 l
> > > > > nobody cared" during boot, not when I boot with the ATI card.
> > > >
> > > > Confirming this. After a lot of hassle, I have bisected this reliably to
> > > >
> > > > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918
Another pesky BIOS which changes the display state behind our back on lid
closing! Should be duct-tapped over with
commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
Author: Daniel Vetter
Date: Fri Nov 23 18:16:34 2012 +0100
drm/i915: force restore on lid open
which is in 3.8.
Cheers, Daniel
m commits 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
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 afte
On Mon, Mar 18, 2013 at 11:05 AM, Daniel Vetter wrote:
> Hi Greg&all,
>
> 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
t; > 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 an
ait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset)) &
> + (GMBUS_SATOER | gmbus2_status),
> + 50);
> + return ret;
> + }
> /* Important: The hw handles only the first bit, so set only one! Since
>* we also
5_gem_init(dev);
> if (ret)
> - goto cleanup_irq;
> + goto cleanup_gem_stolen;
> +
> + intel_modeset_gem_init(dev);
>
> INIT_WORK(&dev_priv->console_resume_work, intel_console_resume);
>
> - intel_modeset_gem_init(dev)
lephant in the room.
Signed-off-by: Jiri Kosina (v1)
Acked-by: Chris Wilson (v1)
References: https://lkml.org/lkml/2013/3/8/325
Signed-off-by: Daniel Vetter
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from th
On Tue, Mar 19, 2013 at 4:38 PM, Alan Stern wrote:
> On Tue, 19 Mar 2013, Daniel Vetter wrote:
>
>> For reference below the updated commit message.
>>
>> Cheers, Daniel
>>
>> Author: Jiri Kosina
>> Date: Tue Mar 19 09:56:57 2013 +0100
>
>>
&
igned-off-by: Jiri Kosina
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 test different tricks quickly without
rebooting. Really useful.
Acked-by: Daniel Vetter
Tha
On Sat, Feb 02, 2013 at 05:20:18PM -0800, Tejun Heo wrote:
> Convert to the much saner new idr interface.
>
> Only compile tested.
>
> Signed-off-by: Tejun Heo
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-de...@lists.freedesktop.org
> ---
> This patch depends
> fence_excl could be used for write access(may need buffer sync like
> > blocking) and read access for the fence_shared(may not need buffer
> > sync). I'm not sure that I understand these two things correctly so
> > could you please give me more comments for them?
> Correct,
d = 1;
> - return NOTIFY_OK;
> + /* do modeset on next lid open event */
> + dev_priv->modeset = MODESET_ON_LID_OPEN;
> + goto exit;
> }
>
> - if (!dev_priv->modeset_on_lid)
> - retur
em(intel_no_modeset_on_lid))
> - return NOTIFY_OK;
> + goto exit;
> if (!acpi_lid_open()) {
> - dev_priv->modeset_on_lid = 1;
> - return NOTIFY_OK;
> + /* do modeset on next lid open event */
> + dev_p
fore updating the fence parameter
drm/i915: Only apply the mb() when flushing the GTT domain during a finish
drm/i915: Only run idle processing from i915_gem_retire_requests_worker
Daniel Vetter (21):
drm/i915: wake up all pageflip waiters
drm/i915: Allow userspace to hint that
@ static int intelfb_create(struct intel_fbdev *ifbdev,
> }
> info->screen_size = size;
>
> + /* This driver doesn't need a VT switch to restore the mode on resume */
> + info->skip_vt_switch = true;
> +
> // memset(info->screen_base, 0, size);
Fol
; > Any chance for an r-b on the PM one at least? Then Daniel could
> > probably push this through drm-intel-next.
>
> Done.
Thanks, I've merged the first two patches to drm-intel-next, the i915 one
still needs a bit of care imo.
-Daniel
--
Daniel Vetter
Software Engin
rks for me.
> >
> > Is that patch or any other fix being picked up? It's over three weeks
> > now and I'm still seeing those BUGs with the latest 3.8-rc.
> >
>
> None that I'm aware of.
Either this one
https://patchwork.kernel.org/patch/209450
_iter_start((iter), (sg), (pgoffset));\
> + (iter)->page; (iter)->page = drm_sg_iter_next(iter))
Again, for the initialization I'd go with page numbers, not an offset in
bytes.
>
> /* ATI PCIGART support (ati_pcigart.h) */
> extern int drm_ati_pcigar
latforms 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 De
grab 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 l
it ...
In any way I think that all three approaches should fit into the
proposed interfaces, so we should be able to do something sane here.
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
Softwar
(due to all those trylocks). So in case we ever switch the
deadlock/backoff algo ww_ would be a bit misleading.
Otoh reservation_ 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_detecti
tel_panel_actually_set_backlight(dev, dev_priv->backlight_level);
> -if (!intel_panel_get_backlight(dev))
> -intel_panel_actually_set_backlight(dev,
> dev_priv->backlight.level);
> ++dev_priv->backlight.enabled = true;
> ++intel_panel_actually_set_backlight(dev, dev_priv->backligh
of a task for deadlock-breaking with
-EAGAIN. The problem is that through PI boosting or normal rt-prio changes
while tasks are trying to acquire ww_mutexes you can create acyclic loops
in the blocked-on graph of ww_mutexes after the fact and so cause
deadlocks. So we've convinced ourselves th
On Thu, Apr 4, 2013 at 3:31 PM, Daniel Vetter 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
>>
On Thu, Apr 4, 2013 at 6:38 PM, 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.
>
> No, imagine the following:
>
> struc
On Thu, Apr 4, 2013 at 6:49 PM, Peter Zijlstra 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
just the '-bpp' and not a full mode, but I haven't
tested. Look for cmdline_mode->bpp_specified in drm_fb_helper.c and the
relevant parsing code in drm_mode_parse_command_line_for_connector in
drm_modes.c
If that doesn't work for you, I think it's better to extend/fix it than
On Tue, Jan 29, 2013 at 10:57 AM, Takashi Iwai wrote:
> At Tue, 29 Jan 2013 10:53:50 +0100,
> Daniel Vetter wrote:
>>
>> On Tue, Jan 29, 2013 at 09:29:17AM +0100, Takashi Iwai wrote:
>> > Add a new option, bpp, to specify the default bpp value.
>> &
On Mon, Jan 28, 2013 at 06:06:38PM +0800, Zhang Rui wrote:
> On Mon, 2013-01-28 at 09:31 +0100, Daniel Vetter wrote:
> > On Mon, Jan 28, 2013 at 3:36 AM, Zhang Rui wrote:
> > >> Given that this essentially requires users to manually set this module
> > >> optio
or otherwise userspace could trick the kernel into creating
a circular fence chain. This wouldn't deadlock the kernel, since
everything is async, but it'll nicely deadlock the gpus involved.
Hence why we need ticketing locks to get dma_buf fences off the
ground.
Maybe wait for
somehow both are fixed with the locking. I'm a bit confused
how these issues could cause failures in the flip tests, but alas:
Tested-by: Lu Hua (for all three patches).
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from th
o be built-in if enabled, imo the sane choice (no
one's bothering with config_vt=m either, after all).
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 linu
this issue...
Linus was the guy who shot down the patches for 3.9 since one of the
earlier iterations caused instant deadlocks - I've been pushing them
to merge them ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe
esktop.org/~airlied/linux/log/?h=fbcon-locking-fixes
though I have a small bikeshed on his last patch pending.
-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-ke
s still useful, just to document the assumptions of the interface. Dave?
-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
i915_gem_gtt.c
> @@ -773,7 +773,7 @@ static int gen6_gmch_probe(struct drm_device *dev,
> return ret;
> }
>
> -void gen6_gmch_remove(struct drm_device *dev)
> +static void gen6_gmch_remove(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->
ew fbdev guys at fosdem (some at least should be
there). Certainly a long-term thing, but comments from whomever gets
volunteered to shepherd fbcon would be great.
Cheers, Daniel
1: http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg33535.html
--
Daniel Vetter
Software Engineer, Intel
need to wait for any still outstanding exclusive
fences attached to the dma_buf. But you _can_ attach more than one
non-exclusive fence to a dma_buf at the same time, and so e.g. read a
buffer objects from different engines concurrently.
There's been some talk whether we also need a non-exclusi
t dr
> int i = 0;
> handle = DEVICE_ACPI_HANDLE(&dev->pdev->dev);
> - if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &acpi_dev)))
> + if (!handle || acpi_bus_get_device(handle, &acpi_dev))
> return;
> if (acpi_
s, I'd be happy.
Rob and Maarten are working on some howtos and documentation with
example code, I guess it'd be best to wait a bit until we have that.
Or just review the existing stuff Rob just posted and reply with
questions there.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, I
-off-by: Dave Airlie
>
> Thanks!
>
> Regards,
> - Sedat
>
> [1] http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsu
On Fri, Feb 01, 2013 at 10:14:20AM +0900, Yasuaki Ishimatsu wrote:
> 2013/02/01 9:53, Yasuaki Ishimatsu wrote:
> >2013/02/01 9:50, Yasuaki Ishimatsu wrote:
> >>2013/01/31 19:03, Daniel Vetter wrote:
> >>>On Thu, Jan 31, 2013 at 12:27:26PM +0900, Yasuaki Ishimatsu w
On Wed, Jan 23, 2013 at 05:25:09PM +0100, Daniel Vetter wrote:
> One of the early return cases missed the mutex unlocking. Hilarity
> ensued.
>
> This regression has been introduced in
>
> commit 7b24056be6db7ce907baffdd4cf142ab774ea60c
> Author: Daniel Vetter
> Date:
0x74/0x140
> [ 73.321091] [] dpm_run_callback.isra.3+0x3c/0x80
> [ 73.321096] [] __device_suspend+0xe5/0x200
> [ 73.321102] [] async_suspend+0x1f/0xa0
> [ 73.321107] [] async_run_entry_fn+0x92/0x1c0
> [ 73.321113] [] process_one_work+0x208/0x750
> [ 73.321142] [] worker_thread+0x160
ruct fb_info *info,
> *
> * Maps a virtual console @unit to a frame buffer device
> * @newidx.
> + *
> + * This should be called with the console lock held.
> */
> static int set_con2fb_map(int unit, int newidx, int user)
> {
What about throwing a WARN_CONSOLE_UNLOCKE
ds us events before the resume code has
completed ... If that's indeed intentional, we could delay the
handling a bit until at least the i915 resume code completed.
- Judging from the diff context you're not on the latest 3.8-rc
codebase - we've applied a few fixes to this lid hack
ep the drm fbdev emulation helper code around,
since quite a few people use that to run older userspace (and even
report some bugs, e.g. mplayer on the linux console played some tricks
we needed to catch). And so end up with two pieces of code who's main
job is to paint console output onto the s
t kind of synchronization, where a notifier
callback can be called from a different device's resume callbacks,
which is someplace completely unrelated in the device-tree? Or any
anti-patterns to avoid?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http:
ing to make this solid, since currently
dev_priv->modeset_on_lid updates can race with our lid notifier
handler. Let me think about this a bit more.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: s
all_chain+0xf/0x11
> [ 489.832359] [] fb_notifier_call_chain+0x16/0x18
> [ 489.832362] [] fb_set_suspend+0x22/0x4b
> [ 489.832365] [] ? console_lock+0x64/0x66
> [ 489.832368] [] store_fbstate+0x4e/0x71
> [ 489.832372] [] dev_attr_store+0x13/0x1f
> [ 489.832375] [] sysfs_writ
On Tue, Feb 19, 2013 at 3:01 AM, Stephen Rothwell wrote:
> On Fri, 15 Feb 2013 08:16:26 -0800 Jesse Barnes
> wrote:
>>
>> On Fri, 15 Feb 2013 10:30:16 +0100
>> Daniel Vetter wrote:
>>
>> > On Fri, Feb 15, 2013 at 3:37 AM, Stephen Rothwell
>> >
ly works.
Starts to smell like a bog-standard i915 black screen bug (albeit with
a strange cause for the regression). Can you please boot the broken
kernels again with drm.debug=0xe and grab the complete dmesg?
Depending upon how long it takes for your wifi to get up, you might
need to extend th
On Wed, Feb 20, 2013 at 8:45 PM, Chris Li wrote:
> On Wed, Feb 20, 2013 at 2:57 AM, Daniel Vetter wrote:
>
>> Starts to smell like a bog-standard i915 black screen bug (albeit with
>> a strange cause for the regression). Can you please boot the broken
>> kernels again wit
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
> Cc: Daniel Vetter
Squashed into the debugfs patch which introduced this regression, thanks
for the quick
drm-intel tree.
>
> I have reverted that commit for today.
Should be fixed now, thanks 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
ether we should
> just collapse the two variables into one, but the current 'max - count'
> is more idiomatic and so preferrable.
> Reviewed-by: Chris Wilson
Picked up for -fixes, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79
On Wed, Mar 13, 2013 at 9:28 PM, Daniel Vetter 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
of pipes in the error state dump
Daniel Vetter (11):
drm/i915: add missing gen2 pipe A quirk entries
drm/i915/ns2501: kill pll A enabling hack
drm/i915: rip out the overlay pipe A workaround
drm/i915: prepare load-detect pipe code for dpms changes
drm/i915: drop intel_enc
rt of the driver. Please upgrade to
the latest mesa (maybe even try git). If you can still reproduce this (and
you've figured out a way to reliably reproduce this), please file a bug
on bugs.freedesktop.org agains mesa -> intel/i965.
Thanks, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
rm/i915: Change forcewake timeout to 2ms
drm/i915: Never read FORCEWAKE
drm/i915: Enable some sysfs stuff without CONFIG_PM
Chris Wilson (1):
drm/i915: Convert remaining debugfs iterators over rings to
for_each_ring()
Daniel Vetter (66):
drm/ips: move drps/ips/ilk related var
7;s udl code I'd say - the drm-intel-next
tree here simply includes a few drm-next patches already. Dave?
-Daniel
>
>
> I've attached my config & the diff between what is attached and the
> result of make oldconfig. Let me know if there is any other info that
> would hel
it so
> that if the maximum PWM value cannot be determined, then the backlight
> will not be registered.
>
> Tested on MacbookPro8,3.
>
> Signed-off-by: Grant Likely
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Matthew Garrett
> Cc: David Woodhouse
I've
I never had any trouble there - a
> few reboots just now with a vanilla 3.5.4 image were
> successful as expected. Meanwhile I have upgraded to 3.6, zero issues as well.
So 3.5 and later really don't seem to have any issue with this patch.
I'm as puzzled as ever. Thanks for testing
ver a
> landscape not too high above the earth)
> b) Hack the drivers aperture / vram sizes to something small, so
> that you can see that the eviction code gets hit.
> c) Adjust the memory limits in TTM sysfs memory accounting (You can
> write and change on the fly), so that you ca
On Sat, Sep 22, 2012 at 10:06 PM, 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, sinc
ld be nice, since the patches have been floating for a while by now
...
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
On Wed, Oct 3, 2012 at 9:45 AM, Thomas Hellstrom 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:
>>>>
>>>&g
ock/unlock cycle in wait_unreserve should do what we
want.
And to properly annotate the ttm reserve paths we could just add an
unconditional wait_unreserve call at the beginning like you suggested
(maybe with #ifdef CONFIG_PROVE_LOCKING in case ppl freak out about
the added atomic read in the
0x8c/0x8c
> [4.267058] [] kernel_thread_helper+0x4/0x10
> [4.267065] [] ? finish_task_switch+0x38/0xb0
> [4.267070] [] ? __switch_to+0x19c/0x426
> [4.267076] [] ? retint_restore_args+0xe/0xe
> [4.267082] [] ? start_kernel+0x3b3/0x3b3
> [4.267087]
t, can you try the drm-intel-fixes branch from
http://cgit.freedesktop.org/~danvet/drm-intel or a bit more risky, latest
upstream git? That contains a completely rewritten modeset code, which
might fix this already. To fix the breakage on 3.6 I guess we need a
bisect - at least I don't have any
on this once I get the time. or if anybody has a patch I can
> test.
Can you please rehand your machine, 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
Softw
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
t; diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index fe71425..da50cd4 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -358,6 +358,7 @@ struct intel_dp {
> int backlight_on_delay;
>
?h=ilk-wa-pile
>> -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
--
Dani
and VLV
drm/i915: 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: d
l issues due to that rework (and some ancient
bugs on top) when either the i915 driver or the bios did something
nefarious ...
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
--
t 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
ration it
fails or succeeds.
So I have no suggestions for what could help your system and what should
get backported, since the current code is still broken.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this l
On Wed, Jul 25, 2012 at 01:55:59PM +0200, Daniel Vetter wrote:
> On Wed, Jul 25, 2012 at 12:57 PM, Maciej Rutecki
> wrote:
> > On środa, 25 lipca 2012 o 11:29:28 Daniel Vetter wrote:
> >> On Wed, Jul 25, 2012 at 10:54:25AM +0200, Maciej Rutecki wrote:
> >> > O
t;queue));
*** DEADLOCK ***
v2: Mark the lockdep_map static, noticed by Jani Nikula.
Cc: Dave Airlie
Cc: Thomas Gleixner
Cc: Alan Cox
Cc: Peter Zijlstra
Signed-off-by: Daniel Vetter
---
kernel/printk.c |9 +
1 file changed, 9 insertions(+)
diff --git a/kernel/printk.c b/kernel/pri
u32 enable_bits = SDVO_ENABLE;
>
> - if (intel_hdmi->has_audio)
> - enable_bits |= SDVO_AUDIO_ENABLE;
> + enable_bits |= SDVO_AUDIO_ENABLE;
>
> temp = I915_READ(intel_hdmi->sdvox_reg);
>
> --
> 1.7.10.280.gaa39
>
> --
>
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 its
On Mon, Sep 24, 2012 at 2:24 PM, Peter Zijlstra 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 logbuf
le is a power-of-two
drm/i915: Wrap external 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: rob
on a witch hunt for 600MB's in my system.
$ 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
won't be conflicts on the early-quirks file; that's not
> touch too often...
Just noticed that these patches aren't in -next yet - somehow I've thought
they'd go in in through the x86 tree.
Ingo et al: Should I merge these through drm-intel-next or will you pick
them up?
Fabio Estevam
Yeah, just ripping out the imxdrm->references stuff will restore imx, but
of course all the funny races are still fundamentally there. So we still
rely on userspace being really careful to obey the right module loading
sequence and not start any drm client before that has all c
ease queue up
commit 1062b81598bc00e2f6620e6f3788f8f8df2f01e7
Author: Daniel Vetter
Date: Tue Sep 10 11:44:30 2013 +0200
drm/i915/tv: clear adjusted_mode.flags
for stable kernels? Right now we seem to get about one dupe per day of
this report ;-)
/me wondered why they kept on coming u
1 - 100 of 3914 matches
Mail list logo
