It seems that nv04_graph_mthd_page_flip() was called from isr , and page_flip
ioctl only send a NV_SW_PAGE_FLIP pushbuffer bo to gem. If you don't want the
screen show garbage you must make sure not to change frontbuffer or backbuffer
in GPU when nv_set_crtc_base() is called, and not change
I've given up waiting for someone to implement support for these ioctls
on another platform before they're merged, but I have received a lot of
feedback on the interfaces, and it sounds like they're ok. I've also
fixed all the remaining issues I'm aware of on SNB platforms and things
are working
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_crtc.c | 236 +++-
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
This avoids the need to unpin on the error path.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_overlay2.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay2.c
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/Makefile |1 +
Make sure the object exists (it may not if the plane was previously disabled)
and make sure we zero it out in the disable path to avoid trouble later.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_overlay2.c |6 ++
1 files changed, 6 insertions(+), 0
Split things out a little and add the IVB reg definitions.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h | 59
drivers/gpu/drm/i915/intel_overlay2.c | 168 ++--
2 files changed, 216 insertions(+), 11
To avoid the object being destroyed before our disable hook is called,
take a private reference on it. This will guarantee that we can still
access the object at disable time.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_overlay2.c | 27
If the source and destination size are different, try to scale the sprite on the
corresponding CRTC.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |5 +
drivers/gpu/drm/i915/intel_overlay2.c | 14 --
2 files changed, 17
If we try to scan a sprite outside of the parent CRTC area, the display
engine will underflow and potentially blank the framebuffer. So clamp
the position + size to the viewable area.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_overlay2.c | 12
10/25/2011 06:46 PM, Jesse Barnes 쓴 글:
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnesjbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_crtc.c | 236
Hi, Jesse.
Thanks for posting.
10/25/2011 06:46 PM, Jesse Barnes 쓴 글:
I've given up waiting for someone to implement support for these ioctls
on another platform before they're merged, but I have received a lot of
feedback on the interfaces, and it sounds like they're ok. I've also
fixed all
On Tue, 25 Oct 2011 19:47:13 +0900
Joonyoung Shim jy0922.s...@samsung.com wrote:
10/25/2011 06:46 PM, Jesse Barnes 쓴 글:
I've given up waiting for someone to implement support for these
ioctls on another platform before they're merged, but I have
received a lot of feedback on the interfaces,
On Tue, 25 Oct 2011 11:46:55 +0200
Jesse Barnes jbar...@virtuousgeek.org wrote:
I've given up waiting for someone to implement support for these
ioctls on another platform before they're merged, but I have received
a lot of feedback on the interfaces, and it sounds like they're ok.
I've also
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
v2: collapse patches and fix plane disable vs unpin ordering bug
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
From 13efc0a405d522aad8250fce2dbd05fefb8b8ab0 Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Fri, 22 Apr 2011 14:55:33 -0700
Subject: [PATCH] drm/i915: add SNB video sprite support
The video sprites support various video surface formats natively and can
handle scaling
On Tue, Oct 25, 2011 at 11:46:56AM +0200, Jesse Barnes wrote:
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
As discussed with Jesse
Maarten Maathuis madman2...@gmail.com writes:
2011/10/25 chris wwzbw...@163.com:
Can anyone give a suggestion, is wait-vblank fully implemented in
page_flip() for nouveau drm driver?
It's intentionally not implemented. The reason is that I wanted to
support non-vsync'ed vblank as well, and
On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
Maarten Maathuis madman2...@gmail.com writes:
2011/10/25 chris wwzbw...@163.com:
Can anyone give a suggestion, is wait-vblank fully implemented in
page_flip() for nouveau drm driver?
It's intentionally not implemented. The
On Sun, Oct 23, 2011 at 05:35:28PM -0500, Rob Clark wrote:
From: Rob Clark r...@ti.com
A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
and omap_vout (v4l2 display) drivers in the past, this driver uses the
DSS2 driver to access the display hardware, including support
This allows to avoid talking to a non-responding bus repeatedly until we
finally timeout after 15 attempts. We can do this by catching the -ENXIO
error, provided by i2c_algo_bit:bit_doAddress call.
Within the bit_doAddress we already try 3 times to get the edid data, so
if the routine tells us
On Tue, 25 Oct 2011 13:58:55 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Oct 25, 2011 at 11:46:56AM +0200, Jesse Barnes wrote:
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the
core KMS code.
As discussed with Jesse on irc, drm fb handling is fragile. Current rules:
- fbs are not reference counted, hence when destroying we need to disable
all crtcs (and now also planes) that use them. drm_framebuffer_cleanup
does that atm
- drivers that hold onto fbs after the kms core drops
On Tue, 25 Oct 2011 14:26:07 +0100
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
As discussed with Jesse on irc, drm fb handling is fragile. Current
rules:
- fbs are not reference counted, hence when destroying we need to
disable all crtcs (and now also planes) that use them.
On Tue, Oct 25, 2011 at 02:26:07PM +0100, Alan Cox wrote:
As discussed with Jesse on irc, drm fb handling is fragile. Current rules:
- fbs are not reference counted, hence when destroying we need to disable
all crtcs (and now also planes) that use them. drm_framebuffer_cleanup
does
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #8 from Michal majkel...@interia.pl 2011-10-25 06:50:55 PDT ---
Breakpoint 1, r200Fallback (ctx=0x8381c10, bit=1, mode=1 '\001')
at r200_swtcl.c:678
678r200ContextPtr rmesa = R200_CONTEXT(ctx);
(gdb) where
#0 r200Fallback
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #9 from Alex Deucher ag...@yahoo.com 2011-10-25 06:57:01 PDT ---
It should be much easier to add tiled support to radeon and r200 with KMS after
we drop DRI1 support since we can just blit to a linear buffer if the CPU needs
to access
Here's a diff I can roll in if it looks ok. It adds the ability to
specify multiple handles for a single fb to better accommodate planar
configs. I think Rob has convinced me that this is a good idea...
comments appreciated.
Thanks,
Jesse
diff --git a/drivers/gpu/drm/drm_crtc.c
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #6 from Michel Dänzer mic...@daenzer.net 2011-10-25 08:00:08 PDT
---
(In reply to comment #5)
Mesa 7.12-devel (git-faa16dc) Works. No crash, no picture errors.
What about the current 7.11 branch? If that still shows the display
Only check the previusly checked relocs for
dublicates. Also leaving the handle uninitialized
isn't such a good idea.
Signed-off-by: Christian König deathsim...@vodafone.de
---
drivers/gpu/drm/radeon/radeon_cs.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git
Having registered debugfs files globally causes
the files to not show up on the second, third
etc.. card in the system.
Signed-off-by: Christian König deathsim...@vodafone.de
---
drivers/gpu/drm/radeon/radeon.h|8 +++
drivers/gpu/drm/radeon/radeon_device.c | 33
Better fix it before this obvious typo spreads even more.
Signed-off-by: Christian König deathsim...@vodafone.de
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_fence.c | 34
drivers/gpu/drm/radeon/radeon_pm.c|4 +-
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #7 from Stefan kde...@vogtner.de 2011-10-25 08:16:45 PDT ---
(In reply to comment #6)
What about the current 7.11 branch? If that still shows the display errors,
you
should be able to bisect the change that fixed it on the master
On Tue, Oct 25, 2011 at 9:09 AM, Jesse Barnes jbar...@virtuousgeek.org wrote:
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 34a0d22..dafe8df 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -272,8 +272,9 @@ struct drm_mode_fb_cmd2 {
__u32 bpp;
On Tue, Oct 25, 2011 at 11:43:09AM -0500, Rob Clark wrote:
On Tue, Oct 25, 2011 at 9:09 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 34a0d22..dafe8df 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #11 from Michal majkel...@interia.pl 2011-10-25 12:54:08 PDT ---
Breakpoint 1, 0xb7e07f93 in radeon_cs_set_limit () from
/usr/lib/libdrm_radeon.so.1
(gdb) s
Single stepping until exit from function radeon_cs_set_limit,
which has no
On Tue, Oct 25, 2011 at 2:41 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Oct 25, 2011 at 11:43:09AM -0500, Rob Clark wrote:
On Tue, Oct 25, 2011 at 9:09 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 34a0d22..dafe8df
https://bugs.freedesktop.org/show_bug.cgi?id=41698
--- Comment #7 from Chris Rankin ranki...@googlemail.com 2011-10-25 13:35:56
PDT ---
Created attachment 52764
-- https://bugs.freedesktop.org/attachment.cgi?id=52764
Trace after GPU lockup
I'm not sure if this is related, but this is the
/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -40,9 +40,9 @@
#include ttm/ttm_module.h
#include vmwgfx_fence.h
-#define VMWGFX_DRIVER_DATE 20111008
+#define VMWGFX_DRIVER_DATE 20111025
#define VMWGFX_DRIVER_MAJOR 2
-#define VMWGFX_DRIVER_MINOR 2
+#define VMWGFX_DRIVER_MINOR 3
#define
From: Alex Deucher alexander.deuc...@amd.com
The function didn't work with DP, eDP, or DP bridge
connectors and thus confused users as it lead them to
believe nothing was connected or the EDID was invalid
when in fact is was, just on the aux bus rather an i2c.
It should also speed up module
From: Alex Deucher alexander.deuc...@amd.com
Move the TC flush before the texture setup to match mesa and
the ddx. Also, move the TC flush into the texture setup
function.
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c |5 -
From: Alex Deucher alexander.deuc...@amd.com
CP_COHER_CNTL2 has to be programmed manually when submitting packets
to the ring directly rather than programmed via an IB.
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 11 +++
1
10/25/2011 08:18 PM, Jesse Barnes 쓴 글:
On Tue, 25 Oct 2011 19:53:02 +0900
Joonyoung Shimjy0922.s...@samsung.com wrote:
+/**
+ * drm_plane - central DRM plane control structure
+ * @dev: DRM device this plane belongs to
+ * @kdev: kernel device
+ * @attr: kdev attributes
+ * @head: for list
10/25/2011 08:13 PM, Jesse Barnes 쓴 글:
On Tue, 25 Oct 2011 19:47:13 +0900
Joonyoung Shimjy0922.s...@samsung.com wrote:
10/25/2011 06:46 PM, Jesse Barnes 쓴 글:
I've given up waiting for someone to implement support for these
ioctls on another platform before they're merged, but I have
received
The following two patches address potential problems that I
called troubles waiting to happen in this note
http://lists.freedesktop.org/archives/dri-devel/2011-October/015412.html
I didn't hear anyone take on my question, so I figured I would just send
the patches. I tested the patches on a
stop adding crtcs from dev-mode_config.crtc_list
to crtc_info array if gpu driver specifies (by mistake
or with a reason) fewer crtcs in crtc_count parameter
also, correct crtc_count value if gpu driver
specifies too many crtcs
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
gpu driver can specify the limit on the number of connectors
that a given crtc can use. Add a check to make sure this limit
is honored when building a list of connectors associated
with a crtc.
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/drm_fb_helper.c |5
The following three patches remove unecessary locks around ioctls
in drm module.
First two:
[PATCH 1/3] drm: no need to hold global mutex for static data
[PATCH 2/3] drm: make DRM_UNLOCKED ioctls with their own mutex
are rather trivial and straight forward and probably do not
need much
drm_getmap, drm_getclient and drm_getstats are all
protected with their own mutex (dev-struct_mutex)
no need to hold global mutex; make them DRM_UNLOCKED
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/drm_drv.c |6 +++---
1 files changed, 3 insertions(+), 3
holding the drm_global_mutex in drm_wait_vblank and then
going to sleep (via DRM_WAIT_ON) is a bad idea in general
because it can block other processes that may issue ioctls
that also grab drm_global_mutex. Blocking can occur until
next vblank which is in the tens of microseconds order of
The following three patches address various minor nits. They are all safe
and I have been running with them for several months on a wide variety
of AMD GPUs
The first patch:
[PATCH 1/3] drm/radeon/kms: use crtc-specific dpms functions in
does not change the functionality and affects the function
it's better that radeon_crtc_commit and radeon_crtc_prepare call
crtc-specific dpms functions instead of hard-coding them to
radeon_crtc_dpms.
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 14 ++
1 files changed, 10
radeon_driver_irq_preinstall_kms and radeon_driver_irq_uninstall_kms
hard code the loop to 6 which happens to be the current maximum
number of crtcs; if one day an ASIC with more crtcs comes out, this
is a trouble waiting to happen. it's better to use num_crtc instead
(for ASICs that have fewer
the crtc check in radeon_get_vblank_timestamp_kms should be against
the num_crtc field in radeon_device not against num_crtcs in drm_device
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/radeon_kms.c |2 +-
1 files changed, 1 insertions(+), 1
10/25/2011 06:46 PM, Jesse Barnes 쓴 글:
[snip]
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8020798..d7f03aa 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -44,6 +44,7 @@ struct drm_framebuffer;
#define DRM_MODE_OBJECT_PROPERTY 0xb0b0b0b0
#define
https://bugs.freedesktop.org/show_bug.cgi?id=41698
--- Comment #5 from Marek Ol??k 2011-10-24 16:18:42 PDT
---
Created attachment 52721
--> https://bugs.freedesktop.org/attachment.cgi?id=52721
possible fix
Can you try this patch?
--
Configure bugmail:
On Fri, Oct 7, 2011 at 19:20, Michael Witten wrote:
> Date: Fri, 16 Sep 2011 20:45:30 +
>
> The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
> specify the size of an array, each element of which looks
> like this:
>
> ?struct radeon_debugfs {
> ? ? ? ? ?struct drm_info_list ?
This adds a new optional chunk to the CS ioctl that specifies optional flags
to the CS parser. Why this is useful is explained below. Note that some regs
no longer need the NOP relocation packet if this feature is enabled.
Tested on r300g and r600g with this flag disabled and enabled.
Assume
https://bugs.freedesktop.org/show_bug.cgi?id=41668
--- Comment #14 from dmotd 2011-10-24
16:46:17 PDT ---
(In reply to comment #13)
> Try the following options in the kernel command line in grub:
> pci=nomsi
> noapic
> irqpoll
> and see if any of them help.
I have been running my machine with
https://bugs.freedesktop.org/show_bug.cgi?id=41668
--- Comment #15 from Alex Deucher 2011-10-24 16:47:39 PDT
---
(In reply to comment #14)
> (In reply to comment #13)
> > Try the following options in the kernel command line in grub:
> > pci=nomsi
> > noapic
> > irqpoll
> > and see if any of
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #7 from Roland Scheidegger 2011-10-24
17:03:22 PDT ---
Yes that's a fallback. Not sure why it would trigger texture mode fallback.
You could try attaching a debugger and see where r200Fallback gets that true
mode bit and work from
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #5 from Stefan 2011-10-24 17:32:00 PDT ---
Mesa 7.12-devel (git-faa16dc) Works. No crash, no picture errors.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because:
s issues can tell me "is it
a bug"?
Thanks!
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111025/d214d3c9/attachment.html>
2011/10/25 chris :
> Can anyone give a suggestion, is wait-vblank fully implemented in
> page_flip() for nouveau drm driver?
>
>
> At 2011-10-24 14:30:55,chris? wrote:
>
> Dear,
>
> I use NVidia Geforce 7300GT graphics card in my PC, and Linux 3.1rc4 kernel
> code, git drm 2.4.36.
> ? When I run
It seems that nv04_graph_mthd_page_flip() was called from isr , and page_flip
ioctl only send a NV_SW_PAGE_FLIP pushbuffer bo to gem. If you don't want the
screen show garbage you must make sure not to change frontbuffer or backbuffer
in GPU when nv_set_crtc_base() is called, and not change
I've given up waiting for someone to implement support for these ioctls
on another platform before they're merged, but I have received a lot of
feedback on the interfaces, and it sounds like they're ok. I've also
fixed all the remaining issues I'm aware of on SNB platforms and things
are working
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 236 +++-
drivers/gpu/drm/drm_drv.c |
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
This avoids the need to unpin on the error path.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_overlay2.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay2.c
b/drivers/gpu/drm/i915/intel_overlay2.c
index
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h |
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4f599ce..cd7e04d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++
Make sure the object exists (it may not if the plane was previously disabled)
and make sure we zero it out in the disable path to avoid trouble later.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_overlay2.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff
Split things out a little and add the IVB reg definitions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h | 59
drivers/gpu/drm/i915/intel_overlay2.c | 168 ++--
2 files changed, 216 insertions(+), 11 deletions(-)
diff --git
To avoid the object being destroyed before our disable hook is called,
take a private reference on it. This will guarantee that we can still
access the object at disable time.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_overlay2.c | 27 ++-
1 files
If the source and destination size are different, try to scale the sprite on the
corresponding CRTC.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h |5 +
drivers/gpu/drm/i915/intel_overlay2.c | 14 --
2 files changed, 17 insertions(+), 2 deletions(-)
If we try to scan a sprite outside of the parent CRTC area, the display
engine will underflow and potentially blank the framebuffer. So clamp
the position + size to the viewable area.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_overlay2.c | 12 +++-
1 files changed, 11
10/25/2011 06:46 PM, Jesse Barnes ? ?:
> Planes are a bit like half-CRTCs. They have a location and fb, but
> don't drive outputs directly. Add support for handling them to the core
> KMS code.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/drm_crtc.c | 236
>
Hi, Jesse.
Thanks for posting.
10/25/2011 06:46 PM, Jesse Barnes ? ?:
> I've given up waiting for someone to implement support for these ioctls
> on another platform before they're merged, but I have received a lot of
> feedback on the interfaces, and it sounds like they're ok. I've also
>
On Tue, 25 Oct 2011 19:47:13 +0900
Joonyoung Shim wrote:
> 10/25/2011 06:46 PM, Jesse Barnes ? ?:
> > I've given up waiting for someone to implement support for these
> > ioctls on another platform before they're merged, but I have
> > received a lot of feedback on the interfaces, and it sounds
On Tue, 25 Oct 2011 19:53:02 +0900
Joonyoung Shim wrote:
> > +/**
> > + * drm_plane - central DRM plane control structure
> > + * @dev: DRM device this plane belongs to
> > + * @kdev: kernel device
> > + * @attr: kdev attributes
> > + * @head: for list management
> > + * @base: base mode object
>
On Tue, 25 Oct 2011 11:46:55 +0200
Jesse Barnes wrote:
> I've given up waiting for someone to implement support for these
> ioctls on another platform before they're merged, but I have received
> a lot of feedback on the interfaces, and it sounds like they're ok.
> I've also fixed all the
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
v2: collapse patches and fix plane disable vs unpin ordering bug
Signed-off-by: Jesse Barnes
---
On Tue, Oct 25, 2011 at 11:46:56AM +0200, Jesse Barnes wrote:
> Planes are a bit like half-CRTCs. They have a location and fb, but
> don't drive outputs directly. Add support for handling them to the core
> KMS code.
>
> Signed-off-by: Jesse Barnes
As discussed with Jesse on irc, drm fb
you have several channels trying to render to the
same pageflipped drawable, to make sure that the flips are properly
synchronized with respect each other.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111025/a694d095/attachment.pgp>
On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
> Maarten Maathuis writes:
>
> > 2011/10/25 chris :
> >> Can anyone give a suggestion, is wait-vblank fully implemented in
> >> page_flip() for nouveau drm driver?
> >>
>
> It's intentionally not implemented. The reason is that I wanted
On Sun, Oct 23, 2011 at 05:35:28PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev)
> and omap_vout (v4l2 display) drivers in the past, this driver uses the
> DSS2 driver to access the display hardware, including support for
>
This allows to avoid talking to a non-responding bus repeatedly until we
finally timeout after 15 attempts. We can do this by catching the -ENXIO
error, provided by i2c_algo_bit:bit_doAddress call.
Within the bit_doAddress we already try 3 times to get the edid data, so
if the routine tells us
On Tue, 25 Oct 2011 13:58:55 +0200
Daniel Vetter wrote:
> On Tue, Oct 25, 2011 at 11:46:56AM +0200, Jesse Barnes wrote:
> > Planes are a bit like half-CRTCs. They have a location and fb, but
> > don't drive outputs directly. Add support for handling them to the
> > core KMS code.
> >
> >
> As discussed with Jesse on irc, drm fb handling is fragile. Current rules:
> - fbs are not reference counted, hence when destroying we need to disable
> all crtcs (and now also planes) that use them. drm_framebuffer_cleanup
> does that atm
> - drivers that hold onto fbs after the kms core
On Tue, 25 Oct 2011 14:26:07 +0100
Alan Cox wrote:
> > As discussed with Jesse on irc, drm fb handling is fragile. Current
> > rules:
> > - fbs are not reference counted, hence when destroying we need to
> > disable all crtcs (and now also planes) that use them.
> > drm_framebuffer_cleanup does
On Tue, Oct 25, 2011 at 02:26:07PM +0100, Alan Cox wrote:
> > As discussed with Jesse on irc, drm fb handling is fragile. Current rules:
> > - fbs are not reference counted, hence when destroying we need to disable
> > all crtcs (and now also planes) that use them. drm_framebuffer_cleanup
> >
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #8 from Michal 2011-10-25 06:50:55 PDT ---
Breakpoint 1, r200Fallback (ctx=0x8381c10, bit=1, mode=1 '\001')
at r200_swtcl.c:678
678r200ContextPtr rmesa = R200_CONTEXT(ctx);
(gdb) where
#0 r200Fallback (ctx=0x8381c10,
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #9 from Alex Deucher 2011-10-25 06:57:01 PDT
---
It should be much easier to add tiled support to radeon and r200 with KMS after
we drop DRI1 support since we can just blit to a linear buffer if the CPU needs
to access a tiled
Here's a diff I can roll in if it looks ok. It adds the ability to
specify multiple handles for a single fb to better accommodate planar
configs. I think Rob has convinced me that this is a good idea...
comments appreciated.
Thanks,
Jesse
diff --git a/drivers/gpu/drm/drm_crtc.c
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #6 from Michel D?nzer 2011-10-25 08:00:08
PDT ---
(In reply to comment #5)
> Mesa 7.12-devel (git-faa16dc) Works. No crash, no picture errors.
What about the current 7.11 branch? If that still shows the display errors, you
should
Only check the previusly checked relocs for
dublicates. Also leaving the handle uninitialized
isn't such a good idea.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_cs.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git
1 - 100 of 124 matches
Mail list logo
