* hammer because it was busy doing stuff when something else generated
> memory
> + * pressure. This doesn't seem particularly wise...
> + */
As opposed to triggering an OOM? The choice was between custom code for
a hopefully rare code path in a situation of last resort, or first
impleme
On Sun, Mar 17, 2013 at 08:50:03PM +0100, Daniel Vetter wrote:
> On Sat, Mar 16, 2013 at 11:19 AM, Chris Wilson
> wrote:
> > If *userspace* doesn't request either IOC_IN | IOC_OUT in their ioctl
> > command (which are seperate from the ioctl number), then kdata is set to
On Mon, Mar 18, 2013 at 07:42:58AM +1000, Dave Airlie wrote:
> On Mon, Mar 18, 2013 at 7:40 AM, Chris Wilson
> wrote:
> > On Sun, Mar 17, 2013 at 08:50:03PM +0100, Daniel Vetter wrote:
> >> On Sat, Mar 16, 2013 at 11:19 AM, Chris Wilson
> >> wrote:
> >>
If we do not complete the writes to the GMBUS registers, they remain
active for an indefinite period of time afterwards, even causing
spurious interrupts on gm45.
Signed-off-by: Chris Wilson
Link: http://lkml.kernel.org/r/alpine.lnx.2.00.1303151424140.9...@pobox.suse.cz
Cc: Shawn Starr
Cc: Jiri
On Mon, Mar 18, 2013 at 12:51:45PM +0100, Jiri Kosina wrote:
> On Mon, 18 Mar 2013, Chris Wilson wrote:
>
> > If we do not complete the writes to the GMBUS registers, they remain
> > active for an indefinite period of time afterwards, even causing
> > spurious interrupts
up to the normal return code that chooses the
appropriate return value based on gmbus2.
How about just using:
if (!HAS_GMBUS_IRQ(dev_priv->dev)) gmbus4_irq_en = 0;
and the existing wait loop?
> + return ret;
> + }
> /* Important: The hw handles only the first bi
nt
> bodly claims that the race is small enough to avoid the dreaded "nobody
> cared" message. Looks like gmbus is good at hitting that race - on newer
> chips it already brought up a similar race in handling pch interrupts.
>
> Can you please give the below patch a whir
On Tue, Mar 19, 2013 at 09:56:57AM +0100, Jiri Kosina wrote:
> On Mon, 18 Mar 2013, Chris Wilson wrote:
>
> > > +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> > > void
> > > intel_i2c_reset(struct drm_device *dev)
> > > {
> > &g
7;t describe how the fb gets corrupted, so it is impossible to
guess the likely cause. When in doubt, please attach a photograph of
the corruption.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
On Mon, Feb 25, 2013 at 04:43:12PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Mon, Feb 25, 2013 at 02:39:18PM +0000, Chris Wilson wrote:
> > On Mon, Feb 25, 2013 at 04:24:11PM +0200, Felipe Balbi wrote:
> > > Hi folks,
> > >
> > > I have a Dell e6410 whose
On Mon, Feb 25, 2013 at 04:56:22PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Mon, Feb 25, 2013 at 02:49:07PM +0000, Chris Wilson wrote:
> > That looks like https://bugzilla.freedesktop.org/show_bug.cgi?id=60391
> > which is fixed by
> >
> > commit da88a5f
e) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR("dp aux hw did not signal timeout (has irq: %i),
status=%08x!\n",
+ has_aux_irq, status);
+ }
#undef C
return status;
--
Chris Wilson, Intel Open Source Techno
om: Patrik Jakobsson
> >
> > commit 4f7dfb6788dd022446847fbbfbe45e13bedb5be2 upstream.
> Is this really stable material? It fixes no known issues and the bug
> report seems to be a different problem.
https://bugs.freedesktop.org/show_bug.cgi?id=59066 is a genuine bug
fixed.
-Chris
--
C
al timeout (has irq:
%i), status=%08x!\n",
+ has_aux_irq, status);
+ }
You applied
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR("dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n",
+
In order to prevent a potential NULL deference with hostile userspace,
we need to check whether the ioctl was passed an invalid args pointer.
Reported-by: Tommi Rantala
Link:
http://lkml.kernel.org/r/ca+ydwtpubvbwxbt-tdgpuvj1eu7itmcho_2b3w13hkd5+jw...@mail.gmail.com
Signed-off-by: Chris Wilson
On Thu, Mar 14, 2013 at 09:50:04PM -0700, Ben Widawsky wrote:
> On Thu, Mar 14, 2013 at 12:59:57PM +0000, Chris Wilson wrote:
> > In order to prevent a potential NULL deference with hostile userspace,
> > we need to check whether the ioctl was passed an invalid args pointer.
>
On Fri, Mar 15, 2013 at 09:36:07AM -0700, Ben Widawsky wrote:
> On Fri, Mar 15, 2013 at 08:24:03AM +0000, Chris Wilson wrote:
> > That's what I thought too. Looking at the stack trace, the empirical
> > evidence is that we need the check.
> > -Chris
>
> I think
On Fri, Mar 15, 2013 at 04:49:42PM -0700, Ben Widawsky wrote:
> On Fri, Mar 15, 2013 at 10:06:19PM +0000, Chris Wilson wrote:
> > On Fri, Mar 15, 2013 at 09:36:07AM -0700, Ben Widawsky wrote:
> > > On Fri, Mar 15, 2013 at 08:24:03AM +, Chris Wilson wrote:
> > >
form.
>
> Tested on MacbookPro8,3. Without this patch both the intel_backlight and
> gmux_backlight devices get registered and userspace doesn't know which
> it should use.
Userspace is informed throught the backlight/type property.
-Chris
--
Chris Wilson, Intel Open Source Techno
On Fri, 14 Sep 2012 14:12:19 +0100, David Woodhouse wrote:
> On Fri, 2012-09-14 at 14:09 +0100, Grant Likely wrote:
> > On Fri, Sep 14, 2012 at 2:01 PM, Chris Wilson
> > wrote:
> > > On Fri, 14 Sep 2012 13:57:06 +0100, Grant Likely
> > > wrote:
> > >
d
http://cgit.freedesktop.org/~danvet/drm/log/?h=ilk-wa-pile of which I
think
http://cgit.freedesktop.org/~danvet/drm/commit/?h=ilk-wa-pile&id=0d5fed2de763b49bb1a90140758153481f043757
is the missing ingredient.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe fro
am compiling a kernel with this patch based on current git now.
> Should I still use the above kernel cmd argument (i915...rc6=0)
> or try without it?
Without any rc6 parameter would be best. But if rc6=0 wasn't the
solution for you, then I may have identified the wrong w/a. Can I ask
o access this thing. Can you please file a
> bug report on bugs.freedesktop.org and attach it there?
No worries, it is another ILK hang similar to the ones reported earlier
- it just seems the ring stops advancing. Hopefully it is a missing w/a
from http://cgit.freedesktop.org/~danvet/drm/log/?
it.
If your have the option, can you switch the ddx between using SNA and
UXA. They stress different paths through the driver which may provide a
lue. Thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux
On Tue, 30 Oct 2012 09:39:43 +0900, Norbert Preining wrote:
> Hi Chris,
>
> On So, 28 Okt 2012, Chris Wilson wrote:
> > Yeah, looks like we have another issue to contend with, so can you
> > please file a bug on bugzilla.freedesktop.org (or bugzilla.kernel.org)
> > so
is attached.
>
> Any ideas?
It's a bug in the ddx, that was fixed in 2.14.902 (2011-03-29).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
appens on e.g. shared buffer objects - in i915 we have just one lock
> > and so suffer quite a bit more from contention. So no idea how much
> > removing the yield would hurt.
>
> If 'sane' userspace is never supposed to do this, then only insane
> userspace is going t
pms(to_intel_encoder(connector->encoder), mode);
intel_modeset_check_state(connector->dev);
}
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel
d whatnot).
Using a rotated framebuffer would disable pageflipping, and prevent the
historically common glitches when flipping. (Historically? That's
hysterical!)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-
ged
> in 3.5-rc1 and is responsible for these bugs that can reliably be
> triggered :
>
> 1b50247a8ddde4af5aaa0e6bc125615372ce6c16 is the first bad commit
> commit 1b50247a8ddde4af5aaa0e6bc125615372ce6c16
> Author: Chris Wilson
> Date: Tue Apr 24 15:47:30 2012 +0100
moved the list of pinned inactive
> objects (1b50247a) has uncovered another long-time bug.
More likely X is segfaulting for another reason altogether. Can you
please attach the stacktrace (with symbols!) and see if another
bisection is required?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
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 FAQ at http://www.tux.org/lkml/
On Sat, 6 Oct 2012 10:20:16 +0200, Willy Tarreau wrote:
> Hi Chris,
>
> On Sat, Oct 06, 2012 at 09:04:34AM +0100, Chris Wilson wrote:
> > > The crash happens here in i915_gem_entervt_ioctl() :
> > >
> > > 3659 BUG_ON(!list_empty(&de
On Sat, 6 Oct 2012 10:42:58 +0200, Willy Tarreau wrote:
> On Sat, Oct 06, 2012 at 09:24:35AM +0100, Chris Wilson wrote:
> > More likely X is segfaulting for another reason altogether. Can you
> > please attach the stacktrace (with symbols!) and see if another
> > bisection
On Sat, 6 Oct 2012 11:17:08 +0200, Willy Tarreau wrote:
> On Sat, Oct 06, 2012 at 10:04:00AM +0100, Chris Wilson wrote:
> > On Sat, 6 Oct 2012 10:42:58 +0200, Willy Tarreau wrote:
> > > On Sat, Oct 06, 2012 at 09:24:35AM +0100, Chris Wilson wrote:
> > > > More likel
n the growing petition to get real errorcodes
back to userspace!
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
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://vge
eed
* to set it here already despite that we pass it down the callchain.
However, until that confusion is unravelled, reverting b0a2658ac, seems
the most sensible approach.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubs
Prevent a divide-by-zero by consistently treating an 'active' CRTC
without a mode set as actually disabled.
---
drivers/gpu/drm/i915/intel_pm.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel
this style of error since the dawn of time. The error means
that the CPU accessed an invalid PTE - so the most likely a missing mb
or chipset flush.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux
> backlight if there's no other backlight driver by default.
There are machines, such as the pnv netbook on my desk, on which
intel_backlight does nothing and the only control is through
acpi_backlight0. Generalising expected behaviour based on one firmware
implementation is fraugh
lv, hsw).
Based on that reasoning and that waking the GPU up here has no negative
consequences, and so long as all paths are fixed, I am happy to give this
an Acked-by: Chris Wilson
Also, we need to reapply the w/a after a Function Level Reset, in other
words we do need to repeat the init_cloc
thesis and make the transistion steps clearer.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
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/majordo
(struct drm_device *dev)
+{
INIT_DELAYED_WORK(&dev_priv->rps.delayed_resume_work,
intel_gen6_powersave_work);
}
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
this patch would fix anything - I
> >>> think you'd always see an oops when you'd hit this bug instead of just
> >>> a bit of corruption.
> >>
> >> Ok, I think it's time to throw in the towel a bit. I've dropped
> >>
> >>
>
] Server terminated with error (1). Closing log file.
Please attach the full Xorg.0.log so that I can make a few guesses.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to m
On Thu, Jul 25, 2013 at 06:35:10PM +0200, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 6:31 PM, Chris Wilson
> wrote:
> > On Thu, Jul 25, 2013 at 06:11:18PM +0200, Sedat Dilek wrote:
> >> Might be OT, but I cannot use my X graphics stack containing
> >> libdrm-2.
On Thu, Jul 25, 2013 at 07:15:03PM +0200, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 7:01 PM, Chris Wilson
> wrote:
> > Basically boils down to either an object allocation failure or mmaping
> > failure. I think dmesg with drm.debug=7 is the next step.
>
> Attached
On Thu, Jul 25, 2013 at 07:52:22PM +0200, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 7:26 PM, Chris Wilson
> wrote:
> > On Thu, Jul 25, 2013 at 07:15:03PM +0200, Sedat Dilek wrote:
> >> On Thu, Jul 25, 2013 at 7:01 PM, Chris Wilson
> >> wrote:
> >> >
PAGE_SHIFT;
@@ -1655,6 +1664,7 @@ out:
drm_gem_object_unreference(&obj->base);
unlock:
mutex_unlock(&dev->struct_mutex);
+ DRM_DEBUG_DRIVER("done, ret=%d\n", ret);
return ret;
}
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from
DRM_DEBUG_DRIVER("Failed to allocate mmap offset (ret=%d)\n",
ret);
goto out;
+ }
*offset = drm_vma_node_offset_addr(&obj->base.vma_node);
@@ -1558,6 +1567,7 @@ out:
drm_gem_object_unreference(&obj->base);
unlock:
mutex_unlock(&dev-
el_glamor_create_screen_resources(screen))
+ if (!intel_glamor_create_screen_resources(screen)) {
+ ErrorF("bang: %d\n", __LINE__);
return FALSE;
+ }
return TRUE;
}
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe
ErrorF("%s:%d bang, errno=%d\n", __func__, __LINE__, -ret);
return FALSE;
+ }
pixmap = screen->GetScreenPixmap(screen);
intel_set_pixmap_bo(pixmap, bo);
which is most likely to report EINVAL (22)?
-Chris
--
Chris Wilson, Intel Open Sourc
r ordering
is correct. Alternatively, if we discard the clean C99 code, both the
kernel struct pci_device_id and libpciaccess's struct pci_match_data are
the same - and I can just use i915_pciids.h directly. My perference is
to keep using C99 in the kernel as it makes the header much more
re
Hmm, interesting licence block in i915_pciids.h - our claim to
grant licence but TG disclaims liability.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.
seem
to be tidier to also use 0x3 << 16 instead of PCI_BASE_CLASS_DISPLAY << 16.
I would leave PCI_ANY_ID as a symbolic value though.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Fri, Jul 26, 2013 at 01:21:07AM +0200, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 11:52 PM, Chris Wilson
> wrote:
> > On Thu, Jul 25, 2013 at 10:07:02PM +0200, Sedat Dilek wrote:
> >> What means the bang line?
> >>
> >> [54.564] (II) GLX: In
rce
conflicts).
Hmm, though we only started checking for map failures in 2.20.10 - which
would explain why going back to the older ddx masks the issue. And yes,
this means we do require a kernel bisect - or some passing inspiron.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
>
> Now, really w/ promised attachment.
Yes, same failure (GTT mmaps) but at a later point, and UXA has no
fallback plan.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
() will align the object as required by fence */
- alignment = 0;
+ alignment = 256 * 1024;
break;
case I915_TILING_Y:
/* Despite that we check this in framebuffer_init userspace can
--
Chris Wilson, Intel Open Source Technology Centre
--
On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
> After a logout from my "BROKEN" Unity-2D session - the login-screen
> for LightDM seems to be OK.
> Then entering my Unity-2D desktop is OK - no screen corruptions.
What hardware and display do you have?
-Chri
On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson
> wrote:
> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
> >> After a logout from my "BROKEN" Unity-2D session - the login-screen
bad commit
> > commit 5456fe3882812aba251886e36fe55bfefb8e8829
> > Author: Chris Wilson
> > Date: Thu Aug 8 14:41:07 2013 +0100
> >
> > drm/i915: Allocate LLC ringbuffers from stolen
> >
> > As stolen objects now behave identically (wrt to default LLC cacheing)
&g
On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek wrote:
> > On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson
> > wrote:
> >> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
> >>> On Tue,
On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
> Files attached.
Can you also please attach a full dmesg so I can check for anything
unusual?
Thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscri
On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson
> wrote:
> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
> >> Files attached.
> >
> > Can you also please attach a full dmesg so I c
On Tue, Aug 13, 2013 at 10:16:10PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson
> wrote:
> > On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
> >> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson
> >> wrote:
> >> >
On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson
> wrote:
> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson
> >> wrote:
> >> >
t; References: https://lkml.org/lkml/2013/3/16/60
> Cc: Tomas Melin
> Cc: Richard Cochran
> Cc: Chris Wilson
> Cc: sta...@vger.kernel.org
> Signed-off-by: Daniel Vetter
I'm happy that you are not touching any paths other than mentioned in
the changelog, and that I think being
ff-by: Daniel Vetter
Signed-off-by: Dave Airlie
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
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://vg
her of which may return NULL. However, only kmap_atomic() is
documented as being guaranteed to return a valid value. If we could
have a similar definitive statement for kmap(), we can then cleanup
quite a bit of redundant error handling.
-Chris
--
Chris Wilson, Intel Open Source Technology
pe: Type of access: %VERIFY_READ or %VERIFY_WRITE. Note that
*%VERIFY_WRITE is a superset of %VERIFY_READ - if it is safe
*to write to a block, it is always safe to read from it.
* @addr: User space pointer to start of block to check
* @size: Size of block to check
*/
-Chris
ont in validate_exec_list() so that the error condition is
always hit and that the limits are applied consistently to all
execbuffers.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
Something more like:
/* We need to check that we can read the entire relocation array, but
* as we may need to update the presumed_offsets upon execution, we
* need to check now for full write access.
*/
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list:
ser passing garbage and hitting an oom. And
total_relocs is preferrable to total, which also leads us to think more
carefully about the error condition. I think the check should be against
INT_MAX / sizeof(struct reloc_entry) for consistency with our other
guard against overflows whilst allocating.
-Chris
On Mon, Mar 11, 2013 at 03:25:59PM -0700, Kees Cook wrote:
> On Mon, Mar 11, 2013 at 3:00 PM, Chris Wilson
> wrote:
> > On Mon, Mar 11, 2013 at 02:23:29PM -0700, Kees Cook wrote:
> >> It is possible to wrap the counter used to allocate the buffer for
> >> relocat
4GiB anyway. Or you can help address the underlying
issue of figuring out how we can derive the location of the stolen
memory which is reserved by the BIOS but not communicated to the OS.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line
to validate_exec_list
>
> Signed-off-by: Kees Cook
> Reported-by: Pinkie Pie
> Cc: sta...@vger.kernel.org
Looks good to me. The only bikeshed that remains is whether we should
just collapse the two variables into one, but the current 'max - count'
is more idiomatic and so pre
On Wed, 22 Aug 2012 16:40:57 -0700, Tejun Heo wrote:
> This is an equivalent conversion and will ease scheduled removal of
> WQ_NON_REENTRANT.
>
> Signed-off-by: Tejun Heo
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe fr
he latest protections, which is good
because it's usually a bo leak of some sort. First stop is to check
xrestop, /sys/kernel/debug/dri/0/i915_gem_objects and
intel-gpu-tools/scripts/who.sh
That will undoubtably reveal a large number of objects being held by the
X server...
-Chris
-
pace is failing to prepare the GPU to execute a WAIT_FOR_EVENT
command, which it can only try if the kernel allows execution of
privileged batch buffers.
Option "SwapbuffersWait" "false" in xorg.conf will prevent the ddx from
issuing the hanging command sequence. It is not clea
ad out the modeset hw state at load and resume time
but then combined with
commit b0a2658acb5bf9ca86b4aab011b7106de3af0add
Author: Daniel Vetter
Date: Tue Dec 18 09:37:54 2012 +0100
drm/i915: don't disable disconnected outputs
it finally started oopsing.
Signed-off-by: Chris Wilson
Repo
niel will send it on. I hope before he does so, he will clarify the
changelog to note that it is just papering over the issue. If the
conjecture is right, it will not prevent that path from triggering the
hang, nor does it prevent other eviction paths from potentially causing
the same issue.
-Chris
Hi all,
On Sat, 6 Jan 2007, Chris Wilson wrote:
Forwarded to lkml as suggested by Alan Stern. Please copy any replies to me,
as I'm not on the list (too much traffic, sorry!).
Ping? It's been two weeks.
Cheers, Chris.
On Fri, 5 Jan 2007, Alan Stern wrote:
On Sat, 6 Jan 2
Hi all,
Forwarded to lkml as suggested by Alan Stern. Please copy any replies to
me, as I'm not on the list (too much traffic, sorry!).
On Fri, 5 Jan 2007, Alan Stern wrote:
On Sat, 6 Jan 2007, Chris Wilson wrote:
I keep getting the following errors:
Jan 5 23:48:38 gcc kernel: i
generate smaller code.
Signed-off-by: Chris Wilson
Cc: "Paul E. McKenney"
Cc: Andrew Morton
Cc: Dan Williams
Cc: Jan Kara
Cc: Josef Bacik
Cc: linux-kernel@vger.kernel.org
---
include/linux/list.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/linu
ess, which should include waiting upon rendering.
(Some drivers may need to do more work to ensure that the dma-buf mmap
is coherent as well as complete.)
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro
reducing the call size for DRM_DEBUG is a definite improvement.
Reviewed-by: Chris Wilson
>
> Miscellanea:
>
> o Convert args... to ##__VA_ARGS__
> o The equivalent DRM_DEV_ macros are rarely used and not
> worth conversion
Today. I would rather see us to migrate to DRM_DE
as delme, kernel log as delme2. Nothing too
> suspicious :-(.
[ 234.547] (EE) intel(0): failed to set mode: Permission denied
upon resume.
There is a VT switch so there should be a DropMaster, SetMaster combo
across resume, but that didn't flag any errors. I couldn't see any sign
of logi
On Thu, Aug 04, 2016 at 06:18:53PM -0300, Gustavo Padovan wrote:
> 2016-08-03 Chris Wilson :
>
> > On Tue, Jul 12, 2016 at 03:08:45PM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan
> > >
> > > Signalling doesn't need to be enabled at sync
unction return a struct fence pointer referencing the fence(s) in the
> Sync
> +File.
+ The returned reference is owned by the caller and must be disposed of
afterwards using fence_put(). In case of error, a NULL is returned
instead.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
llback()
>
> v4: use user bit from fence flags (comment from Chris Wilson)
>
> Signed-off-by: Gustavo Padovan
> ---
> + if (!test_and_set_bit(POLL_ENABLED, &sync_file->fence->flags)) {
> + if (fence_add_callback(sync_file->fence,
On Fri, Aug 05, 2016 at 08:28:15AM +0100, Chris Wilson wrote:
> On Thu, Aug 04, 2016 at 11:24:14PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Signalling doesn't need to be enabled at sync_file creation, it is only
> > required if userspace wai
like:
> - connector_status (as tracked by probe helpers)
> - anything in the edid changes (when setting it
> drm_mode_connector_update_edid_property)
> - other changes (like sink state changes in dpcd or whatever)
>
> That way userspace would be able to reliably spot such changes and do a
> new modeset.
Yes, please. I have had similar wishes for state changes and overall
modeset counters.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_helper]
> [1.356038] [] ? drm_modeset_unlock_all+0x66/0xc0 [drm]
> [1.356038] [] cirrus_fbdev_init+0xa0/0xb0 [cirrus]
> [1.356038] [] cirrus_modeset_init+0x18b/0x1e0 [cirrus]
> [1.356038] [] cirrus_driver_load+0xbc/0x100 [cirrus]
> [1.356038] [] drm_dev_register+0xa9/0xd0 [drm]
locks do not have their class-keys yet - for them the key
* is the lock object itself:
*/
if (unlikely(!lock->key))
lock->key = (void *)lock;
this is the right choice for .key (as lock here is the dep_map).
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
rect as io-mapping.h is not the right header
for iounmap() - that is #include (pulling in )
which is (and was) already present.
So the root cause here is arch/um not supplying enough stubs? But in the
meantime, do you mind removing the incorrect include now that you have a
w/a to keep 0day quiet? :)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_IOMEM (i.e. disabling building under
arch/um). My desire to remove the unneed include to io-mapping is to
simplify verification of changes to io-mapping.h
Signed-off-by: Chris Wilson
Cc: Linus Walleij
Cc: Alexandre Courbot
Cc: linux-g...@vger.kernel.org
---
drivers/gpio/gpiolib-of.c | 1 -
1 file
: Eli Cohen
Date: Sun Jul 7 17:25:49 2013 +0300
mlx5: Add driver for Mellanox Connect-IB adapters
which looks like a copy across from the Mellanox ethernet driver.
Signed-off-by: Chris Wilson
Cc: Eli Cohen
Cc: Jack Morgenstein
Cc: Or Gerlitz
Cc: Matan Barak
Cc: Leon Romanovsky
Cc: Doug
On Wed, Aug 24, 2016 at 12:15:50AM +0300, Leon Romanovsky wrote:
> On Tue, Aug 23, 2016 at 09:16:26PM +0100, Chris Wilson wrote:
> > This file does not use any structs or functions defined by io-mapping.h
> > (nor does it directly use iomap, ioremap, iounamp or friends). Remove it
On Wed, Aug 24, 2016 at 01:55:28PM +0200, Linus Walleij wrote:
> On Tue, Aug 23, 2016 at 10:32 PM, Chris Wilson
> wrote:
>
> > The io-mapping.h include arose from the need to workaround an arch/um
> > compile failure:
> >
> >drivers/gpio/gpio-mpc8
Quoting Daniel Vetter (2017-06-21 16:08:54)
> So back when the i915 power well support landed in
>
> commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
> Author: Wang Xingchao
> Date: Thu May 30 22:07:10 2013 +0800
>
> ALSA: hda - Add power-welll support for haswell HDA
>
> the logic to hand
1 - 100 of 747 matches
Mail list logo
