--- a/drivers/gpu/drm/vmwgfx/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 VMWG
From: Duncan Laurie
This is the method used to override LVDS in intel_lvds and appears to be
an effective way to ensure that the driver does not enable VGA hotplug.
This is the same patch from 2.6.32 kernel in R12 but ported to 2.6.38,
will send upstream next.
Signed-off-by: Duncan Laurie
BUG
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 tha
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
---
drivers/gpu/drm/radeon/radeon_kms.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/dr
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
---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
dif
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 t
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 DRM
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
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
magnitude
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
---
drivers/gpu/drm/drm_drv.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drive
drm_getcap and drm_version ioctls only reads static data,
there is no need to protect them with drm_global_mutex,
so make them DRM_UNLOCKED
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_drv.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dr
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 explanati
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
---
drivers/gpu/drm/drm_fb_helper.c |5 +
1 files changed, 5 inser
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
---
drivers/gpu/drm/drm_fb_helper.c |
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 var
On Tue, Oct 25, 2011 at 11:43:09AM -0500, Rob Clark wrote:
> On Tue, Oct 25, 2011 at 9:09 AM, Jesse Barnes
> 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 +2
https://bugs.freedesktop.org/show_bug.cgi?id=41698
--- Comment #7 from Chris Rankin 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 first GPU lockup in a while
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #11 from Michal 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 line number informatio
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
> fixed
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
---
drivers/gpu/drm/radeon/radeon_kms.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/dr
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 tha
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
---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
dif
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 t
From: Alex Deucher
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
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff
From: Alex Deucher
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
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c |5 -
drivers/gpu/drm/radeon/r600_blit_kms.c | 10 +--
From: Alex Deucher
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 loading as it avoids a
bunch o
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
magnitude
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
---
drivers/gpu/drm/drm_drv.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drive
drm_getcap and drm_version ioctls only reads static data,
there is no need to protect them with drm_global_mutex,
so make them DRM_UNLOCKED
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_drv.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dr
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 explanati
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
---
drivers/gpu/drm/drm_fb_helper.c |5 +
1 files changed, 5 inser
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
---
drivers/gpu/drm/drm_fb_helper.c |
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 var
10/25/2011 08:13 PM, Jesse Barnes 쓴 글:
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
10/25/2011 08:18 PM, Jesse Barnes 쓴 글:
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
Better fix it before this obvious typo spreads even more.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_fence.c | 34
drivers/gpu/drm/radeon/radeon_pm.c|4 +-
drivers/gpu/drm/radeon/rad
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 a/drivers/gpu/drm/radeon/radeon_c
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
---
drivers/gpu/drm/radeon/radeon.h|8 +++
drivers/gpu/drm/radeon/radeon_device.c | 33 ++-
2 files
From: Alex Deucher
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
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff
From: Alex Deucher
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
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c |5 -
drivers/gpu/drm/radeon/r600_blit_kms.c | 10 +--
From: Alex Deucher
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 loading as it avoids a
bunch o
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 b/drivers/gpu/dr
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #10 from Roland Scheidegger 2011-10-25
08:58:41 PDT ---
So the fallback must come from r200ValidateState() - which in turn means
r200ValidateBuffers() and that means radeon_cs_space_check_with_bo() is
failing.
So seems like validatio
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
> > d
From: Duncan Laurie
This is the method used to override LVDS in intel_lvds and appears to be
an effective way to ensure that the driver does not enable VGA hotplug.
This is the same patch from 2.6.32 kernel in R12 but ported to 2.6.38,
will send upstream next.
Signed-off-by: Duncan Laurie
BUG
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 t
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
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #7 from Stefan 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 branch.
No bis
On Tue, Oct 25, 2011 at 2:41 PM, Daniel Vetter 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
>> wrote:
>> > diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
>> > index 34a0d22..dafe8df 100644
>> > --- a/include/dr
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 be
100644
--- a/drivers/gpu/drm/vmwgfx/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 VMWG
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
> HDM
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.
> >
> > Signe
> 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 dro
) is necessary for
the (rare) case where 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, 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 handli
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 buffer
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, bit=
https://bugs.freedesktop.org/show_bug.cgi?id=41698
--- Comment #7 from Chris Rankin 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 first GPU lockup in a while
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
---
drivers/gpu/drm/i915/Makef
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 remaini
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, Oct 25, 2011 at 2:41 PM, Daniel Vetter 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
>> wrote:
>> > diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
>> > index 34a0d22..dafe8df 100644
>> > --- a/include/dr
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 li
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #11 from Michal 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 line number information
On Tue, Oct 25, 2011 at 11:43:09AM -0500, Rob Clark wrote:
> On Tue, Oct 25, 2011 at 9:09 AM, Jesse Barnes
> 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 +2
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
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 chang
---
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
+++ b/drivers/gpu/drm/i9
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 a/d
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 --git
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 2e38b15..e583
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 | 52
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 |
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
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 |3
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 w
On Tue, Oct 25, 2011 at 9:09 AM, Jesse Barnes
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;
> ? ? ? ?__u32 dept
river and foun d this 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>
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 tha
On Tue, Oct 25, 2011 at 9:09 AM, Jesse Barnes 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;
> __u32 depth
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #10 from Roland Scheidegger 2011-10-25
08:58:41 PDT ---
So the fallback must come from r200ValidateState() - which in turn means
r200ValidateBuffers() and that means radeon_cs_space_check_with_bo() is
failing.
So seems like validatio
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #7 from Stefan 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 branch.
No bis
Better fix it before this obvious typo spreads even more.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_fence.c | 34
drivers/gpu/drm/radeon/radeon_pm.c|4 +-
drivers/gpu/drm/radeon/rad
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
---
drivers/gpu/drm/radeon/radeon.h|8 +++
drivers/gpu/drm/radeon/radeon_device.c | 33 ++-
2 files
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 a/drivers/gpu/drm/radeon/radeon_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 be
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 th
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 b/drivers/gpu/dr
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 buffer.
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, bit=
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
> > d
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 t
> 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 dro
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.
> >
> > Signe
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 tha
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
> HDM
1 - 100 of 126 matches
Mail list logo
