The docs say this is required for Gen7, and since the bit was added for
Gen6, we are also setting it there pit pf paranoia. Particularly as
Chris points out, if PIPE_CONTROL counts as a 3d state packet.
This was found through doc inspection by Ken and applies to Gen6+;
It is currently hanging Dan
I think Chris was pointing out the following, hopefully I caught his
meaning right.
dev_priv keeps track of the current addressing mode that gets set at
execbuffer time. Unfortunately the existing code was doing this before
acquiring struct_mutex which leaves a race with another thread also
doing
clean up some code using the existing eb structure.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 108 ++--
1 files changed, 54 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/
Simple refactor.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 78 +---
1 files changed, 47 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index cc69861
I find this to be easier to understand.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 3693e8
Some refactors, a bug fixes (found through refactoring), as well as
setting a bit because the docs says so. That bit is hanging Daniel's
machine, so we may want to hold off on the last patch for now.
This patch series is in preparation for some other work I'm doing in
this area of the code. I thin
On Tue, 2011-10-11 at 13:22 +0200, Daniel Vetter wrote:
> Can you open a bug at fdo with the usual details (dont forget lspci
> -nn) and all the things we've already gathered/tried.
Bug #41705.
--
Bojan
___
Intel-gfx mailing list
Intel-gfx@lists.freed
On Tue, 2011-10-11 at 13:31 +0200, Daniel Vetter wrote:
> Do you have the intel_ips module loaded?
I do.
> If so, does the corruption still occur if you never ever load it?
Will have to test.
--
Bojan
___
Intel-gfx mailing list
Intel-gfx@lists.free
On Tue, 11 Oct 2011 23:41:09 +0200
Daniel Vetter wrote:
> From: Kenneth Graunke
>
> "STALL_AT_SCOREBOARD" is much clearer than "STALL_EN" now that there are
> several different kinds of stalls. Also, "INSTRUCTION_CACHE_INVALIDATE"
> is a lot easier to understand at a glance than the terse "IS_
The series looks good, Daniel. Thanks for cleaning it up!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
From: Jesse Barnes
Signed-off-by: Jesse Barnes
Signed-off-by: Kenneth Graunke
[danvet: this seems to fix cairo-perf-trace hangs on my snb]
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h |5 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 136
From: Kenneth Graunke
"STALL_AT_SCOREBOARD" is much clearer than "STALL_EN" now that there are
several different kinds of stalls. Also, "INSTRUCTION_CACHE_INVALIDATE"
is a lot easier to understand at a glance than the terse "IS_FLUSH."
Signed-off-by: Kenneth Graunke
[danvet: use INVALIDATE for
From: Kenneth Graunke
Not all PIPE_CONTROLs have a length of 2, so remove it from the #define
and make each invocation specify the desired length.
Signed-off-by: Kenneth Graunke
[danvet: implement style suggestion from Ben Widawsdy]
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_r
On Tue, 11 Oct 2011 11:53:56 -0700, Jesse Barnes
wrote:
> Keith can you pick this up?
Yup, I'll make it work.
--
keith.pack...@intel.com
pgpEirXYXMjwW.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http:/
2011/10/11 Олег Герман :
> How can I help, to push this fix to upsteam?
Already submitted as a proper patch to intel-gfx with your tested-by, see:
Message-Id: <1318346871-3042-1-git-send-email-daniel.vet...@ffwll.ch>
Cheers, Daniel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 -
Is it complete solution or temporary workaround?
How can I help, to push this fix to upsteam?
2011/10/11 Олег Герман :
> yep, i just commented-out this line in ubuntu kernel
> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=drivers/gpu/drm/i915/intel_display.c;h=e917c7b853bc62f88
On Tue, 11 Oct 2011 16:39:10 +0200
Daniel Vetter wrote:
> If our semaphore logic gets confused and we have a ring stuck waiting
> for one, there's a decent chance it'll just execute garbage when being
> kicked. Also, kicking the ring obscures the place where the error
> first occured, making erro
Based on a patch by Ben Widawsky, but with different colors
for the bikeshed.
In contrast to Ben's patch this one doesn't add the fault regs.
Afaics they're for the optional page fault support which
- we're not enabling
- and which seems to be unsupported by the hw team. Recent bspec
lacks tons
On Tue, 11 Oct 2011 14:13:16 +0200, Lukas Hejtmanek
wrote:
> Hi,
>
> I have SNB chip, with git driver 5913c90967091124e7c7b262782f0e99cf400eab,
> 3.1-rc9 kernel. I noticed that refresh of notification area or e.g., xosview
> refresh is linked with flashing. Looks like background exposing is syn
On Tue, 11 Oct 2011 12:33:05 -0700, Ben Widawsky wrote:
> On Tue, 11 Oct 2011 12:30:36 -0700
> Ben Widawsky wrote:
>
> > On Tue, 11 Oct 2011 12:18:15 -0700
> > Kenneth Graunke wrote:
> > >
> > > I might only enable this on Gen7 for now, unless it actually fixes
> > > something on Sandybridge.
On Tue, 11 Oct 2011 12:30:36 -0700
Ben Widawsky wrote:
> On Tue, 11 Oct 2011 12:18:15 -0700
> Kenneth Graunke wrote:
> >
> > I might only enable this on Gen7 for now, unless it actually fixes
> > something on Sandybridge. It's not listed as required for Gen6.
>
> I would prefer to keep for ge
Oops, git send-email fail, please ignore this double-post.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, 11 Oct 2011 12:18:15 -0700
Kenneth Graunke wrote:
> On 10/11/2011 11:31 AM, Ben Widawsky wrote:
> > This will strongly order synchronization commands with respect to 3d
> > state and 3d primitive commands. AFAIK, this shouldn't impact anything
> > as these sync commands are all for privil
On Tue, 11 Oct 2011 12:02:58 -0400, Adam Jackson wrote:
> On 10/11/11 11:27 AM, Daniel Vetter wrote:
> > i'm getting tempted to just disable temporal
> > Approved.
> > apparently it makes the screen look pulse-y which is worse
> > than the disease.
> >
> > References:
> > http://lists.freed
On Tue, 11 Oct 2011 19:30:12 +0200, Daniel Vetter
wrote:
> Based on a patch by Ben Widawsky, but with different colors
> for the bikeshed.
>
> In contrast to Ben's patch this one doesn't add the fault regs.
> Afaics they're for the optional page fault support which
> - we're not enabling
> - and
On 10/11/2011 11:31 AM, Ben Widawsky wrote:
> This will strongly order synchronization commands with respect to 3d
> state and 3d primitive commands. AFAIK, this shouldn't impact anything
> as these sync commands are all for privileged (or ppgtt) batches only,
> so user space should not be relying
On Tue, 11 Oct 2011 11:31:56 -0700, Ben Widawsky wrote:
> This will strongly order synchronization commands with respect to 3d
> state and 3d primitive commands. AFAIK, this shouldn't impact anything
> as these sync commands are all for privileged (or ppgtt) batches only,
> so user space should no
On Tue, 11 Oct 2011 11:31:55 -0700, Ben Widawsky wrote:
> clean up some code using the existing eb structure.
>
> There is a tiny hunk here related to setting eb->cliprects which is not
> really useful yet, but will be in the future.
You're scaring me! In the current incarnation there is no way
On Tue, 11 Oct 2011 11:31:54 -0700, Ben Widawsky wrote:
> Signed-off-by: Ben Widawsky
Nice clean up. Reveals we have a bug if the reservation is interrupted
though. The actual loading of the register should be delayed until we
are about to dispatch the execbuffer (and so won't be interferred by
On Tue, 11 Oct 2011 11:39:36 -0700
Ben Widawsky wrote:
> On Tue, 11 Oct 2011 10:20:04 -0700
> Jesse Barnes wrote:
>
> > On Tue, 11 Oct 2011 13:09:17 +0200
> > Daniel Vetter wrote:
> >
> > > Switching to PIPE_CONTROL with the snb workaround seems to fix the hangs I
> > > see when running cairo
On Tue, 11 Oct 2011 11:31:56 -0700
Ben Widawsky wrote:
> This will strongly order synchronization commands with respect to 3d
> state and 3d primitive commands. AFAIK, this shouldn't impact anything
> as these sync commands are all for privileged (or ppgtt) batches only,
> so user space should n
On Tue, 11 Oct 2011 10:20:04 -0700
Jesse Barnes wrote:
> On Tue, 11 Oct 2011 13:09:17 +0200
> Daniel Vetter wrote:
>
> > Switching to PIPE_CONTROL with the snb workaround seems to fix the hangs I
> > see when running cairo-perf-traces.
> >
> > Tested-by: Daniel Vetter
>
> Ah wow, so it actua
This will strongly order synchronization commands with respect to 3d
state and 3d primitive commands. AFAIK, this shouldn't impact anything
as these sync commands are all for privileged (or ppgtt) batches only,
so user space should not be relying on this, and the kernel wouldn't be
relying on 3d st
clean up some code using the existing eb structure.
There is a tiny hunk here related to setting eb->cliprects which is not
really useful yet, but will be in the future.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 112 ++--
1 files chang
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 74
1 files changed, 43 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 89f7429..5a16f22 100644
-
The first two patches are a prelude to some more heavy duty work I am
doing on the execbuffer path. I think these are pretty benign, and
helpful to me so I wanted to get these out now.
The third patch is something Ken found recently which intermixes with
this cleanup, so I figured I'd put that in
Based on a patch by Ben Widawsky, but with different colors
for the bikeshed.
In contrast to Ben's patch this one doesn't add the fault regs.
Afaics they're for the optional page fault support which
- we're not enabling
- and which seems to be unsupported by the hw team. Recent bspec
lacks tons
... and add a helpr function for the places where we want a flag.
This way we can use ring->id to index into arrays.
v2: Resurrect the missing beautification-space Chris Wilson noted.
I'm moving this space around because I'll reuse ring_str in the next
patch.
Signed-off-by: Daniel Vetter
---
d
In the pre-gem days with non-existing hangcheck and gpu reset code,
this timeout of 3 seconds was pretty important to avoid stuck
processes.
But now we have the hangcheck code in gem that goes to great length
to ensure that the gpu is really dead before declaring it wedged.
So there's no need for
In the pre-gem days with non-existing hangcheck and gpu reset code,
this timeout of 3 seconds was pretty important to avoid stuck
processes.
But now we have the hangcheck code in gem that goes to great length
to ensure that the gpu is really dead before declaring it wedged.
So there's no need for
At the point where we check, we can't do much about the failure, but it
can aid debugging. Note that the auto-train override bit will be reset
as part of normal mode setting with this patch if a pipe ever does get
stuck, but that's consistent with the workaround for CPT provided by the
hardware te
On Tue, 11 Oct 2011 12:42:22 -0400
Adam Jackson wrote:
> On 10/11/11 12:16 PM, Jesse Barnes wrote:
> > On Tue, 11 Oct 2011 10:10:24 -0400 Adam Jackson wrote:
> >> It still seems entirely magical and probably wrong in some situations.
> >> And I'm thrilled to see that PPT is functionally differen
On 10/11/11 12:16 PM, Jesse Barnes wrote:
On Tue, 11 Oct 2011 10:10:24 -0400 Adam Jackson wrote:
It still seems entirely magical and probably wrong in some situations.
And I'm thrilled to see that PPT is functionally different from CPT
(seriously, stop doing that) instead of just moving bit def
On Tue, 11 Oct 2011 09:40:18 -0700, Jesse Barnes
wrote:
> Ok just got confirmation that always setting the composite bit is safe
> on IVB per the specs we provide to board designers (i.e. they're
> required to make composite sync work, and fsync/lsync is optional).
Thanks. That sounds conclusiv
On Tue, 11 Oct 2011 13:09:17 +0200
Daniel Vetter wrote:
> Switching to PIPE_CONTROL with the snb workaround seems to fix the hangs I
> see when running cairo-perf-traces.
>
> Tested-by: Daniel Vetter
Ah wow, so it actually fixes a bug. Let's get this upstream soon then;
Ben do you want to re-
On Tue, 11 Oct 2011 10:10:24 -0400
Adam Jackson wrote:
> On 10/10/11 7:22 PM, Keith Packard wrote:
> > On Mon, 10 Oct 2011 14:28:52 -0700, Jesse Barnes
> > wrote:
> >
> >> It's needed for 3 pipe support as well as just regular functionality
> >> (e.g. DisplayPort).
> >
> > Any explanation on ho
On Tue, 11 Oct 2011 10:10:24 -0400
Adam Jackson wrote:
> On 10/10/11 7:22 PM, Keith Packard wrote:
> > On Mon, 10 Oct 2011 14:28:52 -0700, Jesse Barnes
> > wrote:
> >
> >> It's needed for 3 pipe support as well as just regular functionality
> >> (e.g. DisplayPort).
> >
> > Any explanation on ho
On Tue, Oct 11, 2011 at 12:51:02PM -0300, Eugeni Dodonov wrote:
> On Tue, Oct 11, 2011 at 09:24, Bojan Smojver wrote:
>
> > --- Original message ---
> >
> >> From: Daniel Vetter
> >>
> >
> > Ok, this is bug thread is getting a bit unwindy. And I am running low on
> >> ideas. Can you open
On 10/11/11 11:27 AM, Daniel Vetter wrote:
i'm getting tempted to just disable temporal
Approved.
apparently it makes the screen look pulse-y which is worse
than the disease.
References:
http://lists.freedesktop.org/archives/intel-gfx/2011-October/012545.html
Tested-by: Олег Герман
Cc: Ad
On Tue, 11 Oct 2011 16:39:14 +0200, Daniel Vetter
wrote:
> Based on a patch by Ben Widawsky, but with different colors
> for the bikeshed.
>
> In contrast to Ben's patch this one doesn't add the fault regs.
> Afaics they're for the optional page fault support which
> - we're not enabling
> - and
On Tue, 11 Oct 2011 16:39:13 +0200, Daniel Vetter
wrote:
> The code already got unwindy and we want to dump more per-ring
^ unwieldly
> registers.
>
> Only functional change is that we now also capture the video
> ring registers on ilk.
>
> Signed-off-by: Daniel Vetter
On Tue, 11 Oct 2011 16:39:12 +0200, Daniel Vetter
wrote:
> ... and add a helpr function for the places where we want a flag.
>
> This way we can use ring->id to index into arrays.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_debugfs.c|8
> drivers/gp
On Tue, 11 Oct 2011 16:39:11 +0200, Daniel Vetter
wrote:
> In the pre-gem days with non-existing hangcheck and gpu reset code,
> this timeout of 3 seconds was pretty important to avoid stuck
> processes.
>
> But now we have the hangcheck code in gem that goes to great length
> to ensure that the
On Tue, Oct 11, 2011 at 09:24, Bojan Smojver wrote:
> --- Original message ---
>
>> From: Daniel Vetter
>>
>
> Ok, this is bug thread is getting a bit unwindy. And I am running low on
>> ideas. Can you open a bug at fdo with the usual details (dont forget lspci
>> -nn) and all the things
On Tue, 11 Oct 2011 16:39:10 +0200, Daniel Vetter
wrote:
> If our semaphore logic gets confused and we have a ring stuck waiting
> for one, there's a decent chance it'll just execute garbage when being
> kicked. Also, kicking the ring obscures the place where the error
> first occured, making err
... and add a helpr function for the places where we want a flag.
This way we can use ring->id to index into arrays.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c|8
drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 ++--
drivers/gpu/drm/i915/i915_irq
Based on a patch by Ben Widawsky, but with different colors
for the bikeshed.
In contrast to Ben's patch this one doesn't add the fault regs.
Afaics they're for the optional page fault support which
- we're not enabling
- and which seems to be unsupported by the hw team. Recent bspec
lacks tons
The code already got unwindy and we want to dump more per-ring
registers.
Only functional change is that we now also capture the video
ring registers on ilk.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 55 +---
drivers/gpu/drm/i915/i915_drv.h
In the pre-gem days with non-existing hangcheck and gpu reset code,
this timeout of 3 seconds was pretty important to avoid stuck
processes.
But now we have the hangcheck code in gem that goes to great length
to ensure that the gpu is really dead before declaring it wedged.
So there's no need for
If our semaphore logic gets confused and we have a ring stuck waiting
for one, there's a decent chance it'll just execute garbage when being
kicked. Also, kicking the ring obscures the place where the error
first occured, making error_state decoding much harder.
So drop this an let gpu reset handl
From: Ben Widawsky
This was pulled out of the per ring error handling patch series as it
actually fixes two issues, and bikeshedding appears to be going on
there.
First, remove setting hangcheck_count when we do notify ring. While it
seems counterintuitive to be setting up a timer to catch hangc
i'm getting tempted to just disable temporal
Approved.
apparently it makes the screen look pulse-y which is worse
than the disease.
References:
http://lists.freedesktop.org/archives/intel-gfx/2011-October/012545.html
Tested-by: Олег Герман
Cc: Adam Jackson
Signed-off-by: Daniel Vetter
---
On 10/10/11 7:22 PM, Keith Packard wrote:
On Mon, 10 Oct 2011 14:28:52 -0700, Jesse Barnes
wrote:
It's needed for 3 pipe support as well as just regular functionality
(e.g. DisplayPort).
Any explanation on how you get sync without this? As in, why did this
ever work?
To a first approximat
On 10/11/11 4:59 AM, Daniel Vetter wrote:
... not DISPLAY_VGA, because we ignore the VGA subclass with our
class_mask.
It confused me until Chris Wilson clued me up.
Signed-off-by: Daniel Vetter
Reviewed-by: Adam Jackson
- ajax
___
Intel-gfx mail
> Under certain circumstances, an IOTLB flush never completes and the hardware
> just locks up. The fix is meant to idle the GPU both before and after
> any unmap occurs, which should prevent the possibity to hang.
One comment below, noticed by building it for RHEL6.
>
> +/* Certain Gen5 chipset
--- Original message ---
From: Daniel Vetter
Another thing to check: Do you have the intel_ips module loaded? If so,
does the corruption still occur if you never ever load it?
Will check in the morning.
--
Bojan
___
Intel-gfx mailing lis
--- Original message ---
From: Daniel Vetter
Ok, this is bug thread is getting a bit unwindy. And I am running low on
ideas. Can you open a bug at fdo with the usual details (dont forget
lspci
-nn) and all the things we've already gathered/tried.
Shall do.
--
Bojan
__
Hi,
I have SNB chip, with git driver 5913c90967091124e7c7b262782f0e99cf400eab,
3.1-rc9 kernel. I noticed that refresh of notification area or e.g., xosview
refresh is linked with flashing. Looks like background exposing is synced with
vertical refresh so it is visible and disturbing.
This behav
On Tue, Oct 11, 2011 at 01:22:09PM +0200, Daniel Vetter wrote:
> On Tue, Oct 11, 2011 at 10:02:18PM +1100, Bojan Smojver wrote:
> > On Tue, 2011-10-11 at 20:42 +1100, Bojan Smojver wrote:
> > > Shall do.
> >
> > Sent the files to your e-mail address. Ended in a crash.
>
> Ok, this is bug thread i
On Tue, Oct 11, 2011 at 10:02:18PM +1100, Bojan Smojver wrote:
> On Tue, 2011-10-11 at 20:42 +1100, Bojan Smojver wrote:
> > Shall do.
>
> Sent the files to your e-mail address. Ended in a crash.
Ok, this is bug thread is getting a bit unwindy. And I am running low on
ideas. Can you open a bug at
Switching to PIPE_CONTROL with the snb workaround seems to fix the hangs I
see when running cairo-perf-traces.
Tested-by: Daniel Vetter
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freede
On Tue, 2011-10-11 at 20:42 +1100, Bojan Smojver wrote:
> Shall do.
Sent the files to your e-mail address. Ended in a crash.
--
Bojan
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Oct 11, 2011 at 01:50:34PM +0400, Олег Герман wrote:
> > I'd wager this is dithering gone wrong. Can you boot with drm.debug=0xe
> > and attach the full dmesg? Also please attach xrandr --verbose.
>
> also bug is not reproduced on external monitors
Can you try the below patch, please?
-Da
On Tue, 2011-10-11 at 12:39 +0200, Daniel Vetter wrote:
> Probably drop it. This checks for a rather different kind of bug.
OK.
--
Bojan
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Oct 11, 2011 at 08:55:26PM +1100, Bojan Smojver wrote:
> --- Original message ---
> >From: Daniel Vetter
>
> >memmap=2M#512M memmap=2M#1024M
> >
> >added to your boot cmdline?
>
> One question: should I keep the patch thar replaces freeze/thaw with
> suspend/resume when testing or
--- Original message ---
From: Daniel Vetter
memmap=2M#512M memmap=2M#1024M
added to your boot cmdline?
One question: should I keep the patch thar replaces freeze/thaw with
suspend/resume when testing or not?
--
Bojan
___
Intel-gfx ma
> I'd wager this is dithering gone wrong. Can you boot with drm.debug=0xe
> and attach the full dmesg? Also please attach xrandr --verbose.
also bug is not reproduced on external monitors
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://
--- Original message ---
From: Daniel Vetter
Ok, we have a new idea. Can you boot your kernel with
memmap=2M#512M memmap=2M#1024M
added to your boot cmdline? Also please attach the full dmesg after
boot (only the boot messages matter) both with and without these
options.
Shall do.
On Mon, Oct 10, 2011 at 13:23, Bojan Smojver wrote:
> On Mon, 2011-10-10 at 21:37 +1100, Bojan Smojver wrote:
>> Let me repeat my tests using nomodeset.
>
> I just repeated 67 hibernate/thaw cycles with nomodeset, which took
> almost an hour. I'm writing this e-mail from that thawed session. No
>
... not DISPLAY_VGA, because we ignore the VGA subclass with our
class_mask.
It confused me until Chris Wilson clued me up.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
Dear all,
i'm new here, and as a Chinese, i may make some mistakes in English, sorry
for that.
i just have started to program in c++, and i want to port the intel HD
Graphics driver for the unix platform, such as FreeBSD and MAC os, but here
is the problem, i have no idea how to do at all, so, i'
On Mon, Oct 10, 2011 at 9:53 PM, Chris Wilson wrote:
> On Mon, 10 Oct 2011 22:32:38 +0200, Tempura San wrote:
> Non-text part: multipart/mixed
>> This would be great, but...
>>
>> I have just tested the patches and it really messes up the system.
>>
>> On the first boot I got a shell and was able
On Thu, 29 Sep 2011 18:09:32 -0700, Keith Packard wrote:
> Ok, so I've split all of the changes into bite-sized pieces so that
> they should make sense individually now. I've also added the same
> asynchronous power control to the panel power, this reduces the
> module load time down to about 700m
83 matches
Mail list logo
