On Sun, Apr 22, 2012 at 5:51 AM, Linus Torvalds
wrote:
> David & co, any ideas?
I've been asking Ben about this, I might have to use a bit more pressure,
It would be worth bisecting drivers/gpu/drm only, I doubt its going to
be outside that area.
Dave.
__
On 04/20/2012 09:45 AM, Tomasz Stanislawski wrote:
> Hello everyone,
> This patchset adds support for DMABUF [2] importing to V4L2 stack.
> The support for DMABUF exporting was moved to separate patchset
> due to dependency on patches for DMA mapping redesign by
> Marek Szyprowski [4].
Would it be
EDID vendor IDs are always 3 characters long (4 with the terminating
0). It doesn't make any sense to have a (possibly 8-byte) pointer
to the ID string in the quirk structure.
Signed-off-by: Ian Pilcher
---
drivers/gpu/drm/drm_edid.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
On 2012-04-22 08:26 +0100, Dave Airlie wrote:
> I've been asking Ben about this, I might have to use a bit more pressure,
>
> It would be worth bisecting drivers/gpu/drm only, I doubt its going to
> be outside that area.
Since the original bisection was restricted to drivers/gpu, and there
appear
On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> Nick, I realize you had trouble with a bisection already, but it might
> really be worth trying again. Do a
>
> git bisect visualize
>
> and try to pick a good commit (avoding the problems you hit) when you
> hit a problem, and then do
>
>
On Sun, Apr 22, 2012 at 18:40, Nick Bowler wrote:
> (Aside: is there a way to run "git bisect skip" without causing a new
> working tree to be immediately checked out? When I'm going to be
> picking the next commit manually anyway, having git bisect checkout a
> new tree arbitrarily, potentially
Hi Dave
You applied the following patch which breaks fbdev-egl backend:
http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/state_trackers/egl/fbdev/native_fbdev.c?id=b60120608f6ddf4098bc324363197c979ee04cb7
It doesn't compile anymore. I appended the correct fix below. I also
CC'ed mesa-dev
Nouveau, in normal circumstances, does not need device lock for every ioctl,
but incoming "gpu reset" code needs exclusive access to the device.
This commit adds drm_driver flag which turns on read lock ioctl encapsulation.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/drm_drv.c |6
Wait loop can be interrupted by signal, so if signals are raised
periodically (e.g. SIGALRM) this loop may never finish. Use
emission time as a base for fence timeout.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_fence.c |5 -
1 files changed, 4 insertions(+), 1 dele
We need this for lockup recovery.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_bo.c |9 +++--
drivers/gpu/drm/nouveau/nouveau_drv.h |6 +++---
drivers/gpu/drm/nouveau/nouveau_vm.c | 20 ++--
drivers/gpu/drm/nouveau/nouveau_vm.h | 18 +++
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nv50_graph.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c
b/drivers/gpu/drm/nouveau/nv50_graph.c
index 6899547..a61853f 100644
--- a/drivers/gpu/drm/nouveau/nv50_graph.c
Overall idea:
Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
handle them at ioctl level, reset the GPU and repeat last ioctl.
GPU reset is done by doing suspend / resume cycle with few tweaks:
- CPU-only bo eviction
- ignoring vm flush / fence timeouts
- shortening waits
On 2012-04-22 12:40 -0400, Nick Bowler wrote:
> On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> > Nick, I realize you had trouble with a bisection already, but it might
> > really be worth trying again. Do a
> >
> > git bisect visualize
> >
> > and try to pick a good commit (avoding the pr
https://bugs.freedesktop.org/show_bug.cgi?id=39782
--- Comment #11 from Tom Stellard 2012-04-22 18:10:00 PDT
---
(In reply to comment #10)
> Created attachment 57314 [details]
> xvmc log obtained via RADEON_DEBUG=all
>
> Having a similar problem on a R420.
> When using mplayer -vo xvmc to play
On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
> On 2012-04-22 12:40 -0400, Nick Bowler wrote:
> > On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> > > Nick, I realize you had trouble with a bisection already, but it might
> > > really be worth trying again. Do a
> > >
> > > gi
On Sun, 2012-04-22 at 08:26 +0100, Dave Airlie wrote:
> On Sun, Apr 22, 2012 at 5:51 AM, Linus Torvalds
> wrote:
> > David & co, any ideas?
>
> I've been asking Ben about this, I might have to use a bit more pressure,
I unfortunately haven't yet had any ideas which could be useful aside
from cont
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #45 from Alexandre Demers 2012-04-22
22:56:08 PDT ---
I'm now working with a 3.4-rc4 kernel. I activated ColorTiling2D. However, it
didn't change anything.
On the other hand, if you have the hardware under hand, I want to let you kn
On Sun, Apr 22, 2012 at 5:51 AM, Linus Torvalds
wrote:
> David & co, any ideas?
I've been asking Ben about this, I might have to use a bit more pressure,
It would be worth bisecting drivers/gpu/drm only, I doubt its going to
be outside that area.
Dave.
EDID vendor IDs are always 3 characters long (4 with the terminating
0). It doesn't make any sense to have a (possibly 8-byte) pointer
to the ID string in the quirk structure.
Signed-off-by: Ian Pilcher
---
drivers/gpu/drm/drm_edid.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
On 2012-04-22 08:26 +0100, Dave Airlie wrote:
> I've been asking Ben about this, I might have to use a bit more pressure,
>
> It would be worth bisecting drivers/gpu/drm only, I doubt its going to
> be outside that area.
Since the original bisection was restricted to drivers/gpu, and there
appear
On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> Nick, I realize you had trouble with a bisection already, but it might
> really be worth trying again. Do a
>
> git bisect visualize
>
> and try to pick a good commit (avoding the problems you hit) when you
> hit a problem, and then do
>
>
On Sun, Apr 22, 2012 at 18:40, Nick Bowler wrote:
> (Aside: is there a way to run "git bisect skip" without causing a new
> working tree to be immediately checked out? ?When I'm going to be
> picking the next commit manually anyway, having git bisect checkout a
> new tree arbitrarily, potentially
Hi Dave
You applied the following patch which breaks fbdev-egl backend:
http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/state_trackers/egl/fbdev/native_fbdev.c?id=b60120608f6ddf4098bc324363197c979ee04cb7
It doesn't compile anymore. I appended the correct fix below. I also
CC'ed mesa-dev
On 2012-04-22 12:40 -0400, Nick Bowler wrote:
> On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> > Nick, I realize you had trouble with a bisection already, but it might
> > really be worth trying again. Do a
> >
> > git bisect visualize
> >
> > and try to pick a good commit (avoding the pr
On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
> On 2012-04-22 12:40 -0400, Nick Bowler wrote:
> > On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> > > Nick, I realize you had trouble with a bisection already, but it might
> > > really be worth trying again. Do a
> > >
> > > gi
25 matches
Mail list logo
