Re:Re: nouveau page_flip function implement not wait vblank, which cause screen garbage
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 the frontbuffer
context when it is rendering, am I right?
At 2011-10-25 13:45:29,"Maarten Maathuis" wrote:
>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 the vbltest program, it prints "60HZ" which indicated the
>> implementation of drmWaitVBlank() and drm_vblank_wait() is correct.
>> But when I run modetest with option " -v -s 12:1280x1024" , it prints high
>> fresh rate up to "150 HZ" . I examing the code , and found that no waiting
>> vblank operation is processed in nouveau_crtc_ page_flip() function. The
>> screen produced lots of garbage and blink very much.
>> int
>> nouveau_crtc_page_flip(struct drm_crtc *crtc, struct drm_framebuffer *fb,
>> struct drm_pending_vblank_event *event)
>> {
>> ..
>> }
>> I study the i915 intel_crtc_page_flip implementation.
>> static int intel_crtc_page_flip(stru ct drm_crtc *crtc,
>> struct drm_framebuffer *fb,
>> struct drm_pending_vblank_event *event)
>> {
>> ..
>>
>> ret = drm_vblank_get(dev, intel_crtc->pipe);
>> if (ret)
>> goto cleanup_objs;
>>
>> work->pending_flip_obj = obj;
>>
>> work->enable_stall_check = true;
>>
>> /* Block clients from rendering to the new back buffer until
>> * the flip occurs and the object is no longer visible.
>> */
>> atomic_add(1 << intel_crtc->plane, &work->old_fb_obj->pending_flip);
>>
>> ret = dev_priv->display.queue_flip(dev, crtc, fb, obj);
>> &am p;nb sp; if (ret)
>> goto cleanup_pending;
>> ..
>> }
>>
>> after vblank irq acquired, the interrupt isr will wakup the runqueue.
>> 6159 static void do_intel_finish_page_flip(struct drm_device *dev,
>> 6160 struct drm_crtc *crtc)
>> 6161 {
>> ..
>> 6211 list_add_tail(&e->base.link,
>> 6212 &e->base.file_priv->event_list);
>> 6213 wake_up_interruptible(&e->base.file_priv->event_wait);
>> 6214 }
>> 6215
>> 6216 drm_vblank_put(dev, intel_crtc->pipe);
>> 6217
>>
>>
>> Is there anyone use the same driver and foun d this issues can tell me "is
>> it a bug"?
>>
>> Thanks!
>>
>>
>>
>>
>>
>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
>
>It seems to be, the actual page flipping is done by software method
>(see nv04_graph_mthd_page_flip). There is one thing i'm unsure about
>and that is that we wait for the rendering to be done to the current
>frontbuffer and not the current backbuffer (this is only done if the
>page flip channel is different than the rendering channel). Maybe
>someone else can comment on that.
>
>--
>Far away from the primal instinct, the song seems to fade away, the
>river get wider between your thoughts and the things we do and say.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
DRM planes and new fb creation ioctl
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 well, so I'm just going to push them out. (Note IVB support is still missing a few bits for scaling and such; I'll fix those up when I get back home and can test on IVB again.) One change you may notice from the last set is that I've removed the 'zpos' parameter. Plane blending and z ordering is very chipset specific (it even varies between Intel chipsets), so exposing it through a device specific ioctl is probably a better plan. By default, planes should just overlay the primary plane; a device specific ioctl (none available yet, but I have some planned for i915) can provide more flexibility. To recap previous posts, this patchset provides a few new interfaces: - addfb2 - a new FB creation ioctl that lets you specify a surface format, as defined by a fourcc code from the video4linux headers (libdrm will wrap these in DRM_ macros for portability) - planes - ioctls for fetching plane info and attaching an fb to a plane; note there's no separate flip ioctl for planes, just use setplane to update the fb The testdisplay.c program in intel-gpu-tools has support for testing these interfaces, and I'll be fixing up and pushing the xf86-video-intel support soon as well, so you can use either as a reference for how the new interfaces work. Thanks, Jesse ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/11] drm: add plane support
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 +
include/drm/drm.h |3 +
include/drm/drm_crtc.h | 71 +-
include/drm/drm_mode.h | 33 ++
5 files changed, 343 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fe738f0..0e129b1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -535,6 +535,48 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
}
EXPORT_SYMBOL(drm_encoder_cleanup);
+void drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
+ unsigned long possible_crtcs,
+ const struct drm_plane_funcs *funcs,
+ uint32_t *formats, uint32_t format_count)
+{
+ mutex_lock(&dev->mode_config.mutex);
+
+ plane->dev = dev;
+ drm_mode_object_get(dev, &plane->base, DRM_MODE_OBJECT_PLANE);
+ plane->funcs = funcs;
+ plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
+ GFP_KERNEL);
+ if (!plane->format_types) {
+ DRM_DEBUG_KMS("out of memory when allocating plane\n");
+ drm_mode_object_put(dev, &plane->base);
+ return;
+ }
+
+ memcpy(plane->format_types, formats, format_count);
+ plane->format_count = format_count;
+ plane->possible_crtcs = possible_crtcs;
+
+ list_add_tail(&plane->head, &dev->mode_config.plane_list);
+ dev->mode_config.num_plane++;
+
+ mutex_unlock(&dev->mode_config.mutex);
+}
+EXPORT_SYMBOL(drm_plane_init);
+
+void drm_plane_cleanup(struct drm_plane *plane)
+{
+ struct drm_device *dev = plane->dev;
+
+ mutex_lock(&dev->mode_config.mutex);
+ kfree(plane->format_types);
+ drm_mode_object_put(dev, &plane->base);
+ list_del(&plane->head);
+ dev->mode_config.num_plane--;
+ mutex_unlock(&dev->mode_config.mutex);
+}
+EXPORT_SYMBOL(drm_plane_cleanup);
+
/**
* drm_mode_create - create a new display mode
* @dev: DRM device
@@ -866,6 +908,7 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(&dev->mode_config.encoder_list);
INIT_LIST_HEAD(&dev->mode_config.property_list);
INIT_LIST_HEAD(&dev->mode_config.property_blob_list);
+ INIT_LIST_HEAD(&dev->mode_config.plane_list);
idr_init(&dev->mode_config.crtc_idr);
mutex_lock(&dev->mode_config.mutex);
@@ -1466,6 +1509,193 @@ out:
}
/**
+ * drm_mode_getplane_res - get plane info
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Return an plane count and set of IDs.
+ */
+int drm_mode_getplane_res(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_get_plane_res *plane_resp = data;
+ struct drm_mode_config *config;
+ struct drm_plane *plane;
+ uint32_t __user *plane_ptr;
+ int copied = 0, ret = 0;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ mutex_lock(&dev->mode_config.mutex);
+ config = &dev->mode_config;
+
+ /*
+* This ioctl is called twice, once to determine how much space is
+* needed, and the 2nd time to fill it.
+*/
+ if (config->num_plane &&
+ (plane_resp->count_planes >= config->num_plane)) {
+ plane_ptr = (uint32_t *)(unsigned long)plane_resp->plane_id_ptr;
+
+ list_for_each_entry(plane, &config->plane_list, head) {
+ if (put_user(plane->base.id, plane_ptr + copied)) {
+ ret = -EFAULT;
+ goto out;
+ }
+ copied++;
+ }
+ }
+ plane_resp->count_planes = config->num_plane;
+
+out:
+ mutex_unlock(&dev->mode_config.mutex);
+ return ret;
+}
+
+/**
+ * drm_mode_getplane - get plane info
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Return plane info, including formats supported, gamma size, any
+ * current fb, etc.
+ */
+int drm_mode_getplane(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_get_plane *plane_resp = data;
+ struct drm_mode_object *obj;
+ struct drm_plane *plane;
+ uint32_t __user *format_ptr;
+ int ret = 0;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ mutex_lock(&dev->mode_config.mutex);
+ obj = drm_mode_object_find(dev, plane_resp->plane_id,
+ DRM_MODE_OBJECT_PLANE);
+ if (!obj) {
+ ret
[PATCH 02/11] drm: add an fb creation ioctl that takes a pixel format
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| 71 -
drivers/gpu/drm/drm_crtc_helper.c |3 +-
drivers/gpu/drm/drm_drv.c |1 +
drivers/gpu/drm/i915/intel_display.c |9 ++--
drivers/gpu/drm/i915/intel_drv.h |2 +-
drivers/gpu/drm/i915/intel_fb.c |3 +-
drivers/gpu/drm/nouveau/nouveau_display.c |4 +-
drivers/gpu/drm/radeon/radeon_display.c |4 +-
drivers/gpu/drm/radeon/radeon_fb.c|5 +-
drivers/gpu/drm/radeon/radeon_mode.h |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |2 +-
drivers/staging/gma500/framebuffer.c |2 +-
include/drm/drm.h |1 +
include/drm/drm_crtc.h|6 ++-
include/drm/drm_crtc_helper.h |2 +-
include/drm/drm_mode.h| 14 ++
16 files changed, 112 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 0e129b1..a30b9d4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1909,7 +1909,76 @@ out:
int drm_mode_addfb(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
- struct drm_mode_fb_cmd *r = data;
+ struct drm_mode_fb_cmd *or = data;
+ struct drm_mode_fb_cmd2 r;
+ struct drm_mode_config *config = &dev->mode_config;
+ struct drm_framebuffer *fb;
+ int ret = 0;
+
+ /* Use new struct with format internally */
+ r.fb_id = or->fb_id;
+ r.width = or->width;
+ r.height = or->height;
+ r.pitch = or->pitch;
+ r.bpp = or->bpp;
+ r.depth = or->depth;
+ r.pixel_format = 0;
+ r.handle = or->handle;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ if ((config->min_width > r.width) || (r.width > config->max_width)) {
+ DRM_ERROR("mode new framebuffer width not within limits\n");
+ return -EINVAL;
+ }
+ if ((config->min_height > r.height) || (r.height > config->max_height))
{
+ DRM_ERROR("mode new framebuffer height not within limits\n");
+ return -EINVAL;
+ }
+
+ mutex_lock(&dev->mode_config.mutex);
+
+ /* TODO check buffer is sufficiently large */
+ /* TODO setup destructor callback */
+
+ fb = dev->mode_config.funcs->fb_create(dev, file_priv, &r);
+ if (IS_ERR(fb)) {
+ DRM_ERROR("could not create framebuffer\n");
+ ret = PTR_ERR(fb);
+ goto out;
+ }
+
+ or->fb_id = fb->base.id;
+ list_add(&fb->filp_head, &file_priv->fbs);
+ DRM_DEBUG_KMS("[FB:%d]\n", fb->base.id);
+
+out:
+ mutex_unlock(&dev->mode_config.mutex);
+ return ret;
+}
+
+/**
+ * drm_mode_addfb2 - add an FB to the graphics configuration
+ * @inode: inode from the ioctl
+ * @filp: file * from the ioctl
+ * @cmd: cmd from ioctl
+ * @arg: arg from ioctl
+ *
+ * LOCKING:
+ * Takes mode config lock.
+ *
+ * Add a new FB to the specified CRTC, given a user request with format.
+ *
+ * Called by the user via ioctl.
+ *
+ * RETURNS:
+ * Zero on success, errno on failure.
+ */
+int drm_mode_addfb2(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+ struct drm_mode_fb_cmd2 *r = data;
struct drm_mode_config *config = &dev->mode_config;
struct drm_framebuffer *fb;
int ret = 0;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index f88a9b2..77c7293 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -806,13 +806,14 @@ void drm_helper_connector_dpms(struct drm_connector
*connector, int mode)
EXPORT_SYMBOL(drm_helper_connector_dpms);
int drm_helper_mode_fill_fb_struct(struct drm_framebuffer *fb,
- struct drm_mode_fb_cmd *mode_cmd)
+ struct drm_mode_fb_cmd2 *mode_cmd)
{
fb->width = mode_cmd->width;
fb->height = mode_cmd->height;
fb->pitch = mode_cmd->pitch;
fb->bits_per_pixel = mode_cmd->bpp;
fb->depth = mode_cmd->depth;
+ fb->pixel_format = mode_cmd->pixel_format;
return 0;
}
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 15da618..f24b9b6 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -152,6 +152,7 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb,
[PATCH 05/11] drm/i915: move pin & fence for plane past potential error paths
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..e583bd0 100644 --- a/drivers/gpu/drm/i915/intel_overlay2.c +++ b/drivers/gpu/drm/i915/intel_overlay2.c @@ -62,9 +62,6 @@ intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, old_obj = intel_plane->obj; mutex_lock(&dev->struct_mutex); - ret = intel_pin_and_fence_fb_obj(dev, obj, NULL); - if (ret) - goto out_unlock; dvscntr = I915_READ(reg); @@ -104,6 +101,10 @@ intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, goto out_unlock; } + ret = intel_pin_and_fence_fb_obj(dev, obj, NULL); + if (ret) + goto out_unlock; + intel_plane->obj = obj; dvscntr |= DVS_TILED; -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/11] drm/i915: rename existing overlay support to "legacy"
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 | 12 ++--
drivers/gpu/drm/i915/i915_irq.c |2 +-
drivers/gpu/drm/i915/intel_display.c |2 +-
drivers/gpu/drm/i915/intel_drv.h |4 +-
drivers/gpu/drm/i915/intel_overlay.c | 126 +-
6 files changed, 74 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8e95d66..b6d0bbc 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -825,7 +825,7 @@ static int i915_error_state(struct seq_file *m, void
*unused)
}
if (error->overlay)
- intel_overlay_print_error_state(m, error->overlay);
+ intel_legacy_overlay_print_error_state(m, error->overlay);
if (error->display)
intel_display_print_error_state(m, dev, error->display);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 06a37f4..b96c174 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -118,8 +118,8 @@ struct intel_opregion {
};
#define OPREGION_SIZE(8*1024)
-struct intel_overlay;
-struct intel_overlay_error_state;
+struct intel_legacy_overlay;
+struct intel_legacy_overlay_error_state;
struct drm_i915_master_private {
drm_local_map_t *sarea;
@@ -191,7 +191,7 @@ struct drm_i915_error_state {
u32 cache_level:2;
} *active_bo, *pinned_bo;
u32 active_bo_count, pinned_bo_count;
- struct intel_overlay_error_state *overlay;
+ struct intel_legacy_overlay_error_state *overlay;
struct intel_display_error_state *display;
};
@@ -343,7 +343,7 @@ typedef struct drm_i915_private {
struct intel_opregion opregion;
/* overlay */
- struct intel_overlay *overlay;
+ struct intel_legacy_overlay *overlay;
/* LVDS info */
int backlight_level; /* restore backlight to this value */
@@ -1309,8 +1309,8 @@ extern int intel_trans_dp_port_sel(struct drm_crtc *crtc);
/* overlay */
#ifdef CONFIG_DEBUG_FS
-extern struct intel_overlay_error_state
*intel_overlay_capture_error_state(struct drm_device *dev);
-extern void intel_overlay_print_error_state(struct seq_file *m, struct
intel_overlay_error_state *error);
+extern struct intel_legacy_overlay_error_state
*intel_legacy_overlay_capture_error_state(struct drm_device *dev);
+extern void intel_legacy_overlay_print_error_state(struct seq_file *m, struct
intel_legacy_overlay_error_state *error);
extern struct intel_display_error_state
*intel_display_capture_error_state(struct drm_device *dev);
extern void intel_display_print_error_state(struct seq_file *m,
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 9ee2729..36f2837 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -998,7 +998,7 @@ static void i915_capture_error_state(struct drm_device *dev)
do_gettimeofday(&error->time);
- error->overlay = intel_overlay_capture_error_state(dev);
+ error->overlay = intel_legacy_overlay_capture_error_state(dev);
error->display = intel_display_capture_error_state(dev);
spin_lock_irqsave(&dev_priv->error_lock, flags);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b1ae70b..e748338 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3180,7 +3180,7 @@ static void intel_crtc_dpms_overlay(struct intel_crtc
*intel_crtc, bool enable)
mutex_lock(&dev->struct_mutex);
dev_priv->mm.interruptible = false;
- (void) intel_overlay_switch_off(intel_crtc->overlay);
+ (void) intel_legacy_overlay_switch_off(intel_crtc->overlay);
dev_priv->mm.interruptible = true;
mutex_unlock(&dev->struct_mutex);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 23c5622..467fb4a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -161,7 +161,7 @@ struct intel_crtc {
bool busy; /* is scanout buffer being updated frequently? */
struct timer_list idle_timer;
bool lowfreq_avail;
- struct intel_overlay *overlay;
+ struct intel_legacy_overlay *overlay;
struct intel_unpin_work *unpin_work;
int fdi_lanes;
@@ -370,7 +370,7 @@ extern void intel_finish_page_flip_plane(struct drm_device
*dev, int plane);
extern void intel_setup_overlay(struct drm_device *dev);
extern void intel_cleanup_overlay(struct drm_device *dev);
-extern int intel_over
[PATCH 04/11] drm/i915: add SNB video sprite support
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 +
drivers/gpu/drm/i915/intel_display.c | 25 +++-
drivers/gpu/drm/i915/intel_drv.h | 14 +++
drivers/gpu/drm/i915/intel_fb.c |6 +
drivers/gpu/drm/i915/intel_overlay2.c | 203 +
6 files changed, 294 insertions(+), 7 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_overlay2.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0ae6a7c..6193471 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -28,6 +28,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \
intel_dvo.o \
intel_ringbuffer.o \
intel_overlay.o \
+ intel_overlay2.o \
intel_opregion.o \
dvo_ch7xxx.o \
dvo_ch7017.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5a09416..7b128d4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2666,6 +2666,58 @@
#define _DSPBSURF 0x7119C
#define _DSPBTILEOFF 0x711A4
+/* Sprite A control */
+#define _DVSACNTR 0x72180
+#define DVS_ENABLE (1<<31)
+#define DVS_GAMMA_ENABLE (1<<30)
+#define DVS_PIXFORMAT_MASK (3<<25)
+#define DVS_FORMAT_YUV422(0<<25)
+#define DVS_FORMAT_RGBX101010(1<<25)
+#define DVS_FORMAT_RGBX888 (2<<25)
+#define DVS_FORMAT_RGBX161616(3<<25)
+#define DVS_SOURCE_KEY (1<<22)
+#define DVS_RGB_ORDER_RGBX (1<<20)
+#define DVS_YUV_BYTE_ORDER_MASK (3<<16)
+#define DVS_YUV_ORDER_YUYV (0<<16)
+#define DVS_YUV_ORDER_UYVY (1<<16)
+#define DVS_YUV_ORDER_YVYU (2<<16)
+#define DVS_YUV_ORDER_VYUY (3<<16)
+#define DVS_DEST_KEY (1<<2)
+#define DVS_TRICKLE_FEED_DISABLE (1<<14)
+#define DVS_TILED(1<<10)
+#define _DVSASTRIDE0x72188
+#define _DVSAPOS 0x7218c
+#define _DVSASIZE 0x72190
+#define _DVSAKEYVAL0x72194
+#define _DVSAKEYMSK0x72198
+#define _DVSASURF 0x7219c
+#define _DVSAKEYMAXVAL 0x721a0
+#define _DVSATILEOFF 0x721a4
+#define _DVSASURFLIVE 0x721ac
+#define _DVSASCALE 0x72204
+#define _DVSAGAMC 0x72300
+
+#define _DVSBCNTR 0x73180
+#define _DVSBSTRIDE0x73188
+#define _DVSBPOS 0x7318c
+#define _DVSBSIZE 0x73190
+#define _DVSBKEYVAL0x73194
+#define _DVSBKEYMSK0x73198
+#define _DVSBSURF 0x7319c
+#define _DVSBKEYMAXVAL 0x731a0
+#define _DVSBTILEOFF 0x731a4
+#define _DVSBSURFLIVE 0x731ac
+#define _DVSBSCALE 0x73204
+#define _DVSBGAMC 0x73300
+
+#define DVSCNTR(pipe) _PIPE(pipe, _DVSACNTR, _DVSBCNTR)
+#define DVSSTRIDE(pipe) _PIPE(pipe, _DVSASTRIDE, _DVSBSTRIDE)
+#define DVSPOS(pipe) _PIPE(pipe, _DVSAPOS, _DVSBPOS)
+#define DVSSURF(pipe) _PIPE(pipe, _DVSASURF, _DVSBSURF)
+#define DVSSIZE(pipe) _PIPE(pipe, _DVSASIZE, _DVSBSIZE)
+#define DVSSCALE(pipe) _PIPE(pipe, _DVSASCALE, _DVSBSCALE)
+#define DVSTILEOFF(pipe) _PIPE(pipe, _DVSATILEOFF, _DVSBTILEOFF)
+
/* VBIOS regs */
#define VGACNTRL 0x71400
# define VGA_DISP_DISABLE (1 << 31)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e748338..4f599ce 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -915,8 +915,8 @@ static void assert_panel_unlocked(struct drm_i915_private
*dev_priv,
pipe_name(pipe));
}
-static void assert_pipe(struct drm_i915_private *dev_priv,
- enum pipe pipe, bool state)
+void assert_pipe(struct drm_i915_private *dev_priv,
+enum pipe pipe, bool state)
{
int reg;
u32 val;
@@ -929,8 +929,6 @@ static void assert_pipe(struct drm_i915_private *dev_priv,
"pipe %c assertion failure (expected %s, current %s)\n",
pipe_name(pipe), state_string(state), state_string(cur_state));
}
-#define assert_pipe_enabled(d, p) assert_pipe(d, p, true)
-#define assert_pipe_disabled(d, p) assert_pipe(d, p, false)
static void assert_plane_enabled(struct drm_i915_private *dev_priv,
enum plane plane)
@@ -4439,7 +4437,8 @@ static void ironlake_update_wm(struct drm_device *dev)
ILK_LP0_CURSOR_LATENCY,
&plane_wm, &cursor_wm)) {
I915_WRITE(WM0_PIPEA_ILK,
- (plane_wm << WM0_PIPE_PLANE_SHIFT) | cursor_wm);
+ (plane_wm << WM0_
[PATCH 08/11] drm/i915: overlay watermark hack
---
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/i915/intel_display.c
@@ -4521,7 +4521,8 @@ static void sandybridge_update_wm(struct drm_device *dev)
&sandybridge_cursor_wm_info, latency,
&plane_wm, &cursor_wm)) {
I915_WRITE(WM0_PIPEA_ILK,
- (plane_wm << WM0_PIPE_PLANE_SHIFT) | cursor_wm);
+ (plane_wm << WM0_PIPE_PLANE_SHIFT) |
+ (plane_wm << WM0_PIPE_SPRITE_SHIFT) | cursor_wm);
DRM_DEBUG_KMS("FIFO watermarks For pipe A -"
" plane %d, " "cursor: %d\n",
plane_wm, cursor_wm);
@@ -4533,7 +4534,8 @@ static void sandybridge_update_wm(struct drm_device *dev)
&sandybridge_cursor_wm_info, latency,
&plane_wm, &cursor_wm)) {
I915_WRITE(WM0_PIPEB_ILK,
- (plane_wm << WM0_PIPE_PLANE_SHIFT) | cursor_wm);
+ (plane_wm << WM0_PIPE_PLANE_SHIFT) |
+ (plane_wm << WM0_PIPE_SPRITE_SHIFT) | cursor_wm);
DRM_DEBUG_KMS("FIFO watermarks For pipe B -"
" plane %d, cursor: %d\n",
plane_wm, cursor_wm);
@@ -4587,11 +4589,6 @@ static void sandybridge_update_wm(struct drm_device *dev)
(plane_wm << WM1_LP_SR_SHIFT) |
cursor_wm);
-#if 0
- I915_WRITE(WM1S_LP_ILK,
- WM1S_LP_EN |
-#endif
-
/* WM2 */
if (!ironlake_compute_srwm(dev, 2, enabled,
SNB_READ_WM2_LATENCY() * 500,
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/11] drm/i915: plane teardown fixes
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 a/drivers/gpu/drm/i915/intel_overlay2.c b/drivers/gpu/drm/i915/intel_overlay2.c index e583bd0..861e09e 100644 --- a/drivers/gpu/drm/i915/intel_overlay2.c +++ b/drivers/gpu/drm/i915/intel_overlay2.c @@ -149,12 +149,18 @@ intel_disable_plane(struct drm_plane *plane) mutex_lock(&dev->struct_mutex); + if (!intel_plane->obj) + goto out_unlock; + ret = i915_gem_object_finish_gpu(intel_plane->obj); if (ret) goto out_unlock; + i915_gem_object_unpin(intel_plane->obj); out_unlock: + intel_plane->obj = NULL; + I915_WRITE(DVSCNTR(pipe), I915_READ(DVSCNTR(pipe)) & ~DVS_ENABLE); I915_WRITE(DVSSURF(pipe), 0); POSTING_READ(DVSSURF(pipe)); -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/11] drm/i915: enable new overlay code on IVB too
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/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7b128d4..71496b8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2718,6 +2718,65 @@
#define DVSSCALE(pipe) _PIPE(pipe, _DVSASCALE, _DVSBSCALE)
#define DVSTILEOFF(pipe) _PIPE(pipe, _DVSATILEOFF, _DVSBTILEOFF)
+#define _SPRA_CTL 0x70280
+#define SPRITE_ENABLE(1<<31)
+#define SPRITE_GAMMA_ENABLE (1<<30)
+#define SPRITE_PIXFORMAT_MASK(7<<25)
+#define SPRITE_FORMAT_YUV422 (0<<25)
+#define SPRITE_FORMAT_RGBX101010 (1<<25)
+#define SPRITE_FORMAT_RGBX888(2<<25)
+#define SPRITE_FORMAT_RGBX161616 (3<<25)
+#define SPRITE_FORMAT_YUV444 (4<<25)
+#define SPRITE_FORMAT_XBGR101010 (5<<25)
+#define SPRITE_CSC_ENABLE(1<<24)
+#define SPRITE_SOURCE_KEY(1<<22)
+#define SPRITE_RGB_ORDER_RGBX(1<<20) /* only for 888 and
161616 */
+#define SPRITE_YUV_TO_RGB_CSC_DISABLE(1<<19)
+#define SPRITE_YUV_CSC_FORMAT_BT709 (1<<18) /* 0 is BT601 */
+#define SPRITE_YUV_BYTE_ORDER_MASK (3<<16)
+#define SPRITE_YUV_ORDER_YUYV(0<<16)
+#define SPRITE_YUV_ORDER_UYVY(1<<16)
+#define SPRITE_YUV_ORDER_YVYU(2<<16)
+#define SPRITE_YUV_ORDER_VYUY(3<<16)
+#define SPRITE_TRICKLE_FEED_DISABLE (1<<14)
+#define SPRITE_INT_GAMMA_ENABLE (1<<13)
+#define SPRITE_TILED (1<<10)
+#define SPRITE_DEST_KEY (1<<2)
+#define _SPRA_STRIDE 0x70288
+#define _SPRA_POS 0x7028c
+#define _SPRA_SIZE 0x70290
+#define _SPRA_KEYVAL 0x70294
+#define _SPRA_KEYMSK 0x70298
+#define _SPRA_SURF 0x7029c
+#define _SPRA_KEYMAX 0x702a0
+#define _SPRA_TILEOFF 0x702a4
+#define _SPRA_SCALE0x70304
+#define _SPRA_GAMC 0x70400
+
+#define _SPRB_CTL 0x70280
+#define _SPRB_STRIDE 0x70288
+#define _SPRB_POS 0x7028c
+#define _SPRB_SIZE 0x70290
+#define _SPRB_KEYVAL 0x70294
+#define _SPRB_KEYMSK 0x70298
+#define _SPRB_SURF 0x7029c
+#define _SPRB_KEYMAX 0x702a0
+#define _SPRB_TILEOFF 0x702a4
+#define _SPRB_SCALE0x70304
+#define _SPRB_GAMC 0x70400
+
+#define SPRCTL(pipe) _PIPE(pipe, _SPRA_CTL, _SPRB_CTL)
+#define SPRSTRIDE(pipe) _PIPE(pipe, _SPRA_STRIDE, _SPRB_STRIDE)
+#define SPRPOS(pipe) _PIPE(pipe, _SPRA_POS, _SPRB_POS)
+#define SPRSIZE(pipe) _PIPE(pipe, _SPRA_SIZE, _SPRB_SIZE)
+#define SPRKEYVAL(pipe) _PIPE(pipe, _SPRA_KEYVAL, _SPRB_KEYVAL)
+#define SPRKEYMSK(pipe) _PIPE(pipe, _SPRA_KEYMSK, _SPRB_KEYMSK)
+#define SPRSURF(pipe) _PIPE(pipe, _SPRA_SURF, _SPRB_SURF)
+#define SPRKEYMAX(pipe) _PIPE(pipe, _SPRA_KEYMAX, _SPRB_KEYMAX)
+#define SPRTILEOFF(pipe) _PIPE(pipe, _SPRA_TILEOFF, _SPRB_TILEOFF)
+#define SPRSCALE(pipe) _PIPE(pipe, _SPRA_SCALE, _SPRB_SCALE)
+#define SPRGAMC(pipe) _PIPE(pipe, _SPRA_GAMC, _SPRB_GAMC)
+
/* VBIOS regs */
#define VGACNTRL 0x71400
# define VGA_DISP_DISABLE (1 << 31)
diff --git a/drivers/gpu/drm/i915/intel_overlay2.c
b/drivers/gpu/drm/i915/intel_overlay2.c
index 861e09e..61b1a2f 100644
--- a/drivers/gpu/drm/i915/intel_overlay2.c
+++ b/drivers/gpu/drm/i915/intel_overlay2.c
@@ -36,7 +36,116 @@
#include "i915_drv.h"
static int
-intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
+ivb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
+ struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h)
+{
+ struct drm_device *dev = plane->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ struct intel_framebuffer *intel_fb;
+ struct drm_i915_gem_object *obj, *old_obj;
+ int pipe = intel_plane->pipe;
+ unsigned long start, offset;
+ u32 sprctl;
+ u32 reg = SPRCTL(pipe);
+ int ret = 0;
+ int x = src_x >> 16, y = src_y >> 16;
+
+ assert_pipe_enabled(dev_priv, pipe);
+
+ intel_fb = to_intel_framebuffer(fb);
+ obj = intel_fb->obj;
+
+ old_obj = intel_plane->obj;
+
+ mutex_lock(&dev->struct_mutex);
+
+ sprctl = I915_READ(reg);
+
+ /* Mask out pixel format bits in case we change it */
+ sprctl &= ~(SPRITE_DEST_KEY | SPRITE_SOURCE_KEY);
+ sprctl
[PATCH 09/11] drm/i915: fix overlay fb object handling
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 changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay2.c
b/drivers/gpu/drm/i915/intel_overlay2.c
index 61b1a2f..8876857 100644
--- a/drivers/gpu/drm/i915/intel_overlay2.c
+++ b/drivers/gpu/drm/i915/intel_overlay2.c
@@ -35,6 +35,18 @@
#include "i915_drm.h"
#include "i915_drv.h"
+/*
+ * Note on refcounting:
+ * When the user creates an fb for the GEM object to be used for the plane,
+ * a ref is taken on the object. However, if the application exits before
+ * disabling the plane, the DRM close handling will free all the fbs and
+ * unless we take a ref on the object, it will be destroyed before the
+ * plane disable hook is called, causing obvious trouble with our efforts
+ * to look up and unpin the object. So we take a ref after we move the
+ * object to the display plane so it won't be destroyed until our disable
+ * hook is called and we drop our private reference.
+ */
+
static int
ivb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
struct drm_framebuffer *fb, int crtc_x, int crtc_y,
@@ -106,6 +118,8 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
if (ret)
goto out_unlock;
+ drm_gem_object_reference(&obj->base);
+
intel_plane->obj = obj;
sprctl |= SPRITE_TILED;
@@ -117,9 +131,6 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
start = obj->gtt_offset;
offset = y * fb->pitch + x * (fb->bits_per_pixel / 8);
- DRM_ERROR("enabling sprite, pos %d,%d, size %dx%d\n",
- crtc_x, crtc_y, fb->width, fb->height);
-
I915_WRITE(SPRSTRIDE(pipe), fb->pitch);
I915_WRITE(SPRPOS(pipe), (crtc_y << 16) | crtc_x);
I915_WRITE(SPRTILEOFF(pipe), (y << 16) | x);
@@ -215,6 +226,8 @@ snb_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
if (ret)
goto out_unlock;
+ drm_gem_object_reference(&obj->base);
+
intel_plane->obj = obj;
dvscntr |= DVS_TILED;
@@ -260,13 +273,15 @@ ivb_disable_plane(struct drm_plane *plane)
if (!intel_plane->obj)
goto out_unlock;
-#if 0
+
ret = i915_gem_object_finish_gpu(intel_plane->obj);
if (ret)
goto out_unlock;
i915_gem_object_unpin(intel_plane->obj);
-#endif
+
+ drm_gem_object_reference(&intel_plane->obj->base);
+
out_unlock:
intel_plane->obj = NULL;
@@ -299,6 +314,8 @@ snb_disable_plane(struct drm_plane *plane)
i915_gem_object_unpin(intel_plane->obj);
+ drm_gem_object_reference(&intel_plane->obj->base);
+
out_unlock:
intel_plane->obj = NULL;
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/11] drm/i915: add sprite scaling support
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(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 71496b8..8cbda0b 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2695,6 +2695,11 @@ #define _DVSATILEOFF 0x721a4 #define _DVSASURFLIVE 0x721ac #define _DVSASCALE 0x72204 +#define DVS_SCALE_ENABLE (1<<31) +#define DVS_FILTER_MASK (3<<29) +#define DVS_FILTER_MEDIUM(0<<29) +#define DVS_FILTER_ENHANCING (1<<29) +#define DVS_FILTER_SOFTENING (2<<29) #define _DVSAGAMC 0x72300 #define _DVSBCNTR 0x73180 diff --git a/drivers/gpu/drm/i915/intel_overlay2.c b/drivers/gpu/drm/i915/intel_overlay2.c index 90c4f59..61594b6 100644 --- a/drivers/gpu/drm/i915/intel_overlay2.c +++ b/drivers/gpu/drm/i915/intel_overlay2.c @@ -169,7 +169,7 @@ snb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, struct drm_i915_gem_object *obj, *old_obj; int pipe = intel_plane->pipe; unsigned long start, offset; - u32 dvscntr; + u32 dvscntr, dvsscale = 0; u32 reg = DVSCNTR(pipe); int ret = 0; int x = src_x >> 16, y = src_y >> 16; @@ -185,6 +185,13 @@ snb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, if (crtc_x >= active_w || crtc_y >= active_h) return -EINVAL; + /* +* We can take a larger source and scale it down, but +* only so much... 16x is the max on SNB. +*/ + if (((src_w * src_h) / (crtc_w * crtc_h)) > 16) + return -EINVAL; + /* Clamp the width & height into the visible area */ if (crtc_x + crtc_w > active_w) crtc_w = active_w - crtc_x - 1; @@ -249,11 +256,14 @@ snb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, start = obj->gtt_offset; offset = y * fb->pitch + x * (fb->bits_per_pixel / 8); + if (crtc_w != src_w || crtc_h != src_h) + dvsscale = DVS_SCALE_ENABLE | (src_h << 16) | src_w; + I915_WRITE(DVSSTRIDE(pipe), fb->pitch); I915_WRITE(DVSPOS(pipe), (crtc_y << 16) | crtc_x); I915_WRITE(DVSTILEOFF(pipe), (y << 16) | x); I915_WRITE(DVSSIZE(pipe), (crtc_h << 16) | crtc_w); - I915_WRITE(DVSSCALE(pipe), 0); + I915_WRITE(DVSSCALE(pipe), dvsscale); I915_WRITE(reg, dvscntr); I915_WRITE(DVSSURF(pipe), start); POSTING_READ(DVSSURF(pipe)); -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/11] drm/i915: clamp sprite to viewable area
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 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_overlay2.c b/drivers/gpu/drm/i915/intel_overlay2.c index 8876857..90c4f59 100644 --- a/drivers/gpu/drm/i915/intel_overlay2.c +++ b/drivers/gpu/drm/i915/intel_overlay2.c @@ -173,6 +173,7 @@ snb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, u32 reg = DVSCNTR(pipe); int ret = 0; int x = src_x >> 16, y = src_y >> 16; + int active_w = crtc->mode.hdisplay, active_h = crtc->mode.vdisplay; assert_pipe_enabled(dev_priv, pipe); @@ -181,6 +182,15 @@ snb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, old_obj = intel_plane->obj; + if (crtc_x >= active_w || crtc_y >= active_h) + return -EINVAL; + + /* Clamp the width & height into the visible area */ + if (crtc_x + crtc_w > active_w) + crtc_w = active_w - crtc_x - 1; + if (crtc_y + crtc_h > active_h) + crtc_h = active_h - crtc_y - 1; + mutex_lock(&dev->struct_mutex); dvscntr = I915_READ(reg); @@ -242,7 +252,7 @@ snb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, I915_WRITE(DVSSTRIDE(pipe), fb->pitch); I915_WRITE(DVSPOS(pipe), (crtc_y << 16) | crtc_x); I915_WRITE(DVSTILEOFF(pipe), (y << 16) | x); - I915_WRITE(DVSSIZE(pipe), (fb->height << 16) | fb->width); + I915_WRITE(DVSSIZE(pipe), (crtc_h << 16) | crtc_w); I915_WRITE(DVSSCALE(pipe), 0); I915_WRITE(reg, dvscntr); I915_WRITE(DVSSURF(pipe), start); -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm: add plane support
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 +++-
drivers/gpu/drm/drm_drv.c |3 +
include/drm/drm.h |3 +
include/drm/drm_crtc.h | 71 +-
include/drm/drm_mode.h | 33 ++
5 files changed, 343 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fe738f0..0e129b1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -535,6 +535,48 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
}
EXPORT_SYMBOL(drm_encoder_cleanup);
+void drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
+ unsigned long possible_crtcs,
+ const struct drm_plane_funcs *funcs,
+ uint32_t *formats, uint32_t format_count)
+{
+ mutex_lock(&dev->mode_config.mutex);
+
+ plane->dev = dev;
+ drm_mode_object_get(dev,&plane->base, DRM_MODE_OBJECT_PLANE);
+ plane->funcs = funcs;
+ plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
+ GFP_KERNEL);
+ if (!plane->format_types) {
+ DRM_DEBUG_KMS("out of memory when allocating plane\n");
+ drm_mode_object_put(dev,&plane->base);
+ return;
+ }
+
+ memcpy(plane->format_types, formats, format_count);
+ plane->format_count = format_count;
+ plane->possible_crtcs = possible_crtcs;
+
+ list_add_tail(&plane->head,&dev->mode_config.plane_list);
+ dev->mode_config.num_plane++;
+
+ mutex_unlock(&dev->mode_config.mutex);
+}
+EXPORT_SYMBOL(drm_plane_init);
+
+void drm_plane_cleanup(struct drm_plane *plane)
+{
+ struct drm_device *dev = plane->dev;
+
+ mutex_lock(&dev->mode_config.mutex);
+ kfree(plane->format_types);
+ drm_mode_object_put(dev,&plane->base);
+ list_del(&plane->head);
+ dev->mode_config.num_plane--;
+ mutex_unlock(&dev->mode_config.mutex);
+}
+EXPORT_SYMBOL(drm_plane_cleanup);
+
/**
* drm_mode_create - create a new display mode
* @dev: DRM device
@@ -866,6 +908,7 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(&dev->mode_config.encoder_list);
INIT_LIST_HEAD(&dev->mode_config.property_list);
INIT_LIST_HEAD(&dev->mode_config.property_blob_list);
+ INIT_LIST_HEAD(&dev->mode_config.plane_list);
idr_init(&dev->mode_config.crtc_idr);
mutex_lock(&dev->mode_config.mutex);
@@ -1466,6 +1509,193 @@ out:
}
/**
+ * drm_mode_getplane_res - get plane info
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Return an plane count and set of IDs.
+ */
+int drm_mode_getplane_res(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_get_plane_res *plane_resp = data;
+ struct drm_mode_config *config;
+ struct drm_plane *plane;
+ uint32_t __user *plane_ptr;
+ int copied = 0, ret = 0;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ mutex_lock(&dev->mode_config.mutex);
+ config =&dev->mode_config;
+
+ /*
+* This ioctl is called twice, once to determine how much space is
+* needed, and the 2nd time to fill it.
+*/
+ if (config->num_plane&&
+ (plane_resp->count_planes>= config->num_plane)) {
+ plane_ptr = (uint32_t *)(unsigned long)plane_resp->plane_id_ptr;
+
+ list_for_each_entry(plane,&config->plane_list, head) {
+ if (put_user(plane->base.id, plane_ptr + copied)) {
+ ret = -EFAULT;
+ goto out;
+ }
+ copied++;
+ }
+ }
+ plane_resp->count_planes = config->num_plane;
+
+out:
+ mutex_unlock(&dev->mode_config.mutex);
+ return ret;
+}
+
+/**
+ * drm_mode_getplane - get plane info
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Return plane info, including formats supported, gamma size, any
+ * current fb, etc.
+ */
+int drm_mode_getplane(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_get_plane *plane_resp = data;
+ struct drm_mode_object *obj;
+ struct drm_plane *plane;
+ uint32_t __user *format_ptr;
+ int ret = 0;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ mutex_lock(&dev->mode_config.mutex);
+ obj = drm_mode_object_find(dev, plane_resp->plane_id,
+ DRM_MODE_OBJECT_PLANE
Re: DRM planes and new fb creation ioctl
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 the remaining issues I'm aware of on SNB platforms and things are working well, so I'm just going to push them out. (Note IVB support is still missing a few bits for scaling and such; I'll fix those up when I get back home and can test on IVB again.) One change you may notice from the last set is that I've removed the 'zpos' parameter. Plane blending and z ordering is very chipset specific (it even varies between Intel chipsets), so exposing it through a device specific ioctl is probably a better plan. But i think zpos is essential parameter of plane. If plane doesn't support it, drm driver cannot know user wants to use which overlay, so i wonder what it meant DRM_IOCTL_MODE_SETPLANE zpos is absent . If use device specific ioctl, should implement device specific ioctl for DRM_IOCTL_MODE_SETPLANE? By default, planes should just overlay the primary plane; a device specific ioctl (none available yet, but I have some planned for i915) can provide more flexibility. Could you explain what is the primary plane? Is it same as the overlay handled by crtc? It confuses a bit when one overlay is handled by crtc and plane at the same time. To recap previous posts, this patchset provides a few new interfaces: - addfb2 - a new FB creation ioctl that lets you specify a surface format, as defined by a fourcc code from the video4linux headers (libdrm will wrap these in DRM_ macros for portability) - planes - ioctls for fetching plane info and attaching an fb to a plane; note there's no separate flip ioctl for planes, just use setplane to update the fb The testdisplay.c program in intel-gpu-tools has support for testing these interfaces, and I'll be fixing up and pushing the xf86-video-intel support soon as well, so you can use either as a reference for how the new interfaces work. Thanks, Jesse ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM planes and new fb creation ioctl
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 like > > they're ok. I've also fixed all the remaining issues I'm aware of > > on SNB platforms and things are working well, so I'm just going to > > push them out. (Note IVB support is still missing a few bits for > > scaling and such; I'll fix those up when I get back home and can > > test on IVB again.) > > > > One change you may notice from the last set is that I've removed the > > 'zpos' parameter. Plane blending and z ordering is very chipset > > specific (it even varies between Intel chipsets), so exposing it > > through a device specific ioctl is probably a better plan. > > But i think zpos is essential parameter of plane. If plane doesn't > support it, drm driver cannot know user wants to use which overlay, > so i wonder what it meant DRM_IOCTL_MODE_SETPLANE zpos is absent . Setplane is just for attaching a new fb. The order, keying, or whatever else your plane blender can support can be set with a device specific ioctl before or after the setplane call (probably before to avoid any flashing or bad frames). > If use device specific ioctl, should implement device specific ioctl > for DRM_IOCTL_MODE_SETPLANE? You could if you needed, but I don't think it's strictly necessary. > >By default, planes > > should just overlay the primary plane; a device specific ioctl (none > > available yet, but I have some planned for i915) can provide more > > flexibility. > > Could you explain what is the primary plane? Is it same as the overlay > handled by crtc? It confuses a bit when one overlay is handled by crtc > and plane at the same time. Yeah, it is a little confusing. When I refer to the primary, I'm referring to the plane bound to the CRTC. I'm fine if someone wants to break that out, I think it would make sense. I just didn't want to write the compat code that would be required for that scheme. :) But these patches definitely don't preclude it, and I don't think these interfaces will need changes if we ever move to a pipe/plane split at the userland level. Thanks, Jesse ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm: add plane support
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
> > + * @crtc_x: x position of plane (relative to pipe base)
> > + * @crtc_y: y position of plane
> > + * @x: x offset into fb
> > + * @y: y offset into fb
> Above 4 members don't be used.
Oops yeah, I'll fix up the comments.
> > +
> > +struct drm_mode_get_plane {
> > + __u64 format_type_ptr;
> > + __u32 plane_id;
> > +
> > + __u32 crtc_id;
> > + __u32 fb_id;
> > +
> > + __u32 possible_crtcs;
> > + __u32 gamma_size;
> > +
> > + __u32 count_format_types;
> > +};
>
> I wonder why doesn't give to user crtc_x, crtc_y, crtc_w, crtc_h
> information?
It could, but the caller should already know was my thinking. Would
you like those bits returned?
Jesse
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] DRM planes and new fb creation ioctl
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 remaining issues I'm aware of on SNB > platforms and things are working well, so I'm just going to push them > out. (Note IVB support is still missing a few bits for scaling and > such; I'll fix those up when I get back home and can test on IVB > again.) Btw, ignore 3-11, I forgot to collapse them when I collapsed the core fixes. Updated intel specific patch will be coming shortly (with a fix for the unpin vs disable ordering danvet pointed out). Jesse ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: add SNB video sprite support
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/Makefile |1 + drivers/gpu/drm/i915/i915_reg.h | 116 ++ drivers/gpu/drm/i915/intel_display.c | 26 ++- drivers/gpu/drm/i915/intel_drv.h | 14 ++ drivers/gpu/drm/i915/intel_fb.c |6 + drivers/gpu/drm/i915/intel_overlay2.c | 393 + 6 files changed, 547 insertions(+), 9 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_overlay2.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 0ae6a7c..6193471 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -28,6 +28,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \ intel_dvo.o \ intel_ringbuffer.o \ intel_overlay.o \ + intel_overlay2.o \ intel_opregion.o \ dvo_ch7xxx.o \ dvo_ch7017.o \ diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 5a09416..8cbda0b 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2666,6 +2666,122 @@ #define _DSPBSURF 0x7119C #define _DSPBTILEOFF 0x711A4 +/* Sprite A control */ +#define _DVSACNTR 0x72180 +#define DVS_ENABLE (1<<31) +#define DVS_GAMMA_ENABLE (1<<30) +#define DVS_PIXFORMAT_MASK (3<<25) +#define DVS_FORMAT_YUV422(0<<25) +#define DVS_FORMAT_RGBX101010(1<<25) +#define DVS_FORMAT_RGBX888 (2<<25) +#define DVS_FORMAT_RGBX161616(3<<25) +#define DVS_SOURCE_KEY (1<<22) +#define DVS_RGB_ORDER_RGBX (1<<20) +#define DVS_YUV_BYTE_ORDER_MASK (3<<16) +#define DVS_YUV_ORDER_YUYV (0<<16) +#define DVS_YUV_ORDER_UYVY (1<<16) +#define DVS_YUV_ORDER_YVYU (2<<16) +#define DVS_YUV_ORDER_VYUY (3<<16) +#define DVS_DEST_KEY (1<<2) +#define DVS_TRICKLE_FEED_DISABLE (1<<14) +#define DVS_TILED(1<<10) +#define _DVSASTRIDE0x72188 +#define _DVSAPOS 0x7218c +#define _DVSASIZE 0x72190 +#define _DVSAKEYVAL0x72194 +#define _DVSAKEYMSK0x72198 +#define _DVSASURF 0x7219c +#define _DVSAKEYMAXVAL 0x721a0 +#define _DVSATILEOFF 0x721a4 +#define _DVSASURFLIVE 0x721ac +#define _DVSASCALE 0x72204 +#define DVS_SCALE_ENABLE (1<<31) +#define DVS_FILTER_MASK (3<<29) +#define DVS_FILTER_MEDIUM(0<<29) +#define DVS_FILTER_ENHANCING (1<<29) +#define DVS_FILTER_SOFTENING (2<<29) +#define _DVSAGAMC 0x72300 + +#define _DVSBCNTR 0x73180 +#define _DVSBSTRIDE0x73188 +#define _DVSBPOS 0x7318c +#define _DVSBSIZE 0x73190 +#define _DVSBKEYVAL0x73194 +#define _DVSBKEYMSK0x73198 +#define _DVSBSURF 0x7319c +#define _DVSBKEYMAXVAL 0x731a0 +#define _DVSBTILEOFF 0x731a4 +#define _DVSBSURFLIVE 0x731ac +#define _DVSBSCALE 0x73204 +#define _DVSBGAMC 0x73300 + +#define DVSCNTR(pipe) _PIPE(pipe, _DVSACNTR, _DVSBCNTR) +#define DVSSTRIDE(pipe) _PIPE(pipe, _DVSASTRIDE, _DVSBSTRIDE) +#define DVSPOS(pipe) _PIPE(pipe, _DVSAPOS, _DVSBPOS) +#define DVSSURF(pipe) _PIPE(pipe, _DVSASURF, _DVSBSURF) +#define DVSSIZE(pipe) _PIPE(pipe, _DVSASIZE, _DVSBSIZE) +#define DVSSCALE(pipe) _PIPE(pipe, _DVSASCALE, _DVSBSCALE) +#define DVSTILEOFF(pipe) _PIPE(pipe, _DVSATILEOFF, _DVSBTILEOFF) + +#define _SPRA_CTL 0x70280 +#define SPRITE_ENABLE(1<<31) +#define SPRITE_GAMMA_ENABLE (1<<30) +#define SPRITE_PIXFORMAT_MASK(7<<25) +#define SPRITE_FORMAT_YUV422 (0<<25) +#define SPRITE_FORMAT_RGBX101010 (1<<25) +#define SPRITE_FORMAT_RGBX888(2<<25) +#define SPRITE_FORMAT_RGBX161616 (3<<25) +#define SPRITE_FORMAT_YUV444 (4<<25) +#define SPRITE_FORMAT_XBGR101010 (5<<25) +#define SPRITE_CSC_ENABLE(1<<24) +#define SPRITE_SOURCE_KEY(1<<22) +#define SPRITE_RGB_ORDER_RGBX(1<<20) /* only for 888 and 161616 */ +#define SPRITE_YUV_TO_RGB_CSC_DISABLE(1<<19) +#define SPRITE_YUV_CSC_FORMAT_BT709 (1<<18) /* 0 is BT601 */ +#define SPRITE_YUV_BYTE_ORDER_MASK (3<<16) +#define SPRITE_YUV_ORDER_YUYV(0<<16) +#define SPRITE_YUV_ORDER_UYVY(1<<16) +#define SPRITE_YUV_ORDER_YVYU(2<<16) +#define SPRITE_YUV_ORDER_VYUY(3<<16) +#define SPRITE_TRICKLE_FEED_DISABLE (1<<14) +#define SPRITE_INT_GAMMA_ENABLE (1<<13) +#define SPRITE_TILED (1<<10) +#define SPRITE_DEST_KEY
[PATCH] drm/i915: add SNB video sprite support
From 13efc0a405d522aad8250fce2dbd05fefb8b8ab0 Mon Sep 17 00:00:00 2001 From: Jesse Barnes 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 as well. So add support for them using the new DRM core overlay support functions. v2: collapse patches v3: no really, fix disable ordering Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/Makefile |1 + drivers/gpu/drm/i915/i915_reg.h | 116 ++ drivers/gpu/drm/i915/intel_display.c | 26 ++- drivers/gpu/drm/i915/intel_drv.h | 14 ++ drivers/gpu/drm/i915/intel_fb.c |6 + drivers/gpu/drm/i915/intel_overlay2.c | 395 + 6 files changed, 549 insertions(+), 9 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_overlay2.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 0ae6a7c..6193471 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -28,6 +28,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \ intel_dvo.o \ intel_ringbuffer.o \ intel_overlay.o \ + intel_overlay2.o \ intel_opregion.o \ dvo_ch7xxx.o \ dvo_ch7017.o \ diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 5a09416..8cbda0b 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2666,6 +2666,122 @@ #define _DSPBSURF 0x7119C #define _DSPBTILEOFF 0x711A4 +/* Sprite A control */ +#define _DVSACNTR 0x72180 +#define DVS_ENABLE (1<<31) +#define DVS_GAMMA_ENABLE (1<<30) +#define DVS_PIXFORMAT_MASK (3<<25) +#define DVS_FORMAT_YUV422(0<<25) +#define DVS_FORMAT_RGBX101010(1<<25) +#define DVS_FORMAT_RGBX888 (2<<25) +#define DVS_FORMAT_RGBX161616(3<<25) +#define DVS_SOURCE_KEY (1<<22) +#define DVS_RGB_ORDER_RGBX (1<<20) +#define DVS_YUV_BYTE_ORDER_MASK (3<<16) +#define DVS_YUV_ORDER_YUYV (0<<16) +#define DVS_YUV_ORDER_UYVY (1<<16) +#define DVS_YUV_ORDER_YVYU (2<<16) +#define DVS_YUV_ORDER_VYUY (3<<16) +#define DVS_DEST_KEY (1<<2) +#define DVS_TRICKLE_FEED_DISABLE (1<<14) +#define DVS_TILED(1<<10) +#define _DVSASTRIDE0x72188 +#define _DVSAPOS 0x7218c +#define _DVSASIZE 0x72190 +#define _DVSAKEYVAL0x72194 +#define _DVSAKEYMSK0x72198 +#define _DVSASURF 0x7219c +#define _DVSAKEYMAXVAL 0x721a0 +#define _DVSATILEOFF 0x721a4 +#define _DVSASURFLIVE 0x721ac +#define _DVSASCALE 0x72204 +#define DVS_SCALE_ENABLE (1<<31) +#define DVS_FILTER_MASK (3<<29) +#define DVS_FILTER_MEDIUM(0<<29) +#define DVS_FILTER_ENHANCING (1<<29) +#define DVS_FILTER_SOFTENING (2<<29) +#define _DVSAGAMC 0x72300 + +#define _DVSBCNTR 0x73180 +#define _DVSBSTRIDE0x73188 +#define _DVSBPOS 0x7318c +#define _DVSBSIZE 0x73190 +#define _DVSBKEYVAL0x73194 +#define _DVSBKEYMSK0x73198 +#define _DVSBSURF 0x7319c +#define _DVSBKEYMAXVAL 0x731a0 +#define _DVSBTILEOFF 0x731a4 +#define _DVSBSURFLIVE 0x731ac +#define _DVSBSCALE 0x73204 +#define _DVSBGAMC 0x73300 + +#define DVSCNTR(pipe) _PIPE(pipe, _DVSACNTR, _DVSBCNTR) +#define DVSSTRIDE(pipe) _PIPE(pipe, _DVSASTRIDE, _DVSBSTRIDE) +#define DVSPOS(pipe) _PIPE(pipe, _DVSAPOS, _DVSBPOS) +#define DVSSURF(pipe) _PIPE(pipe, _DVSASURF, _DVSBSURF) +#define DVSSIZE(pipe) _PIPE(pipe, _DVSASIZE, _DVSBSIZE) +#define DVSSCALE(pipe) _PIPE(pipe, _DVSASCALE, _DVSBSCALE) +#define DVSTILEOFF(pipe) _PIPE(pipe, _DVSATILEOFF, _DVSBTILEOFF) + +#define _SPRA_CTL 0x70280 +#define SPRITE_ENABLE(1<<31) +#define SPRITE_GAMMA_ENABLE (1<<30) +#define SPRITE_PIXFORMAT_MASK(7<<25) +#define SPRITE_FORMAT_YUV422 (0<<25) +#define SPRITE_FORMAT_RGBX101010 (1<<25) +#define SPRITE_FORMAT_RGBX888(2<<25) +#define SPRITE_FORMAT_RGBX161616 (3<<25) +#define SPRITE_FORMAT_YUV444 (4<<25) +#define SPRITE_FORMAT_XBGR101010 (5<<25) +#define SPRITE_CSC_ENABLE(1<<24) +#define SPRITE_SOURCE_KEY(1<<22) +#define SPRITE_RGB_ORDER_RGBX(1<<20) /* only for 888 and 161616 */ +#define SPRITE_YUV_TO_RGB_CSC_DISABLE(1<<19) +#define SPRITE_YUV_CSC_FORMAT_BT709 (1<<18) /* 0 is BT601 */ +#define SPRITE_YUV_BYTE_ORDER_MASK (3<<16) +#define SPRITE_YUV_ORDER_YUYV(0<<16) +#define SPRITE_YUV_ORDER_UYVY(1<<16) +#define SPRITE_YUV_ORDER_YVYU(2<<16) +#define SPRITE_YUV_ORDER_VYUY(3<
Re: [PATCH 01/11] drm: add plane support
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 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 the corresponding pointer needs to hold a ref onto the underlying backing storage (like e.g. for pageflip on the to-be-flipped-out fb as long as it might still be scanned out). We need proper refcounting for these ... But for now this patch is missing the plane cleanup in drm_framebuffer_cleanup. Otherwise I think going with just the src and dst rect for set_plane is about the only sensible thing given the crazy hw out there. But I lack the knowledge about that kind of hw (and video stuff in general), so I'll refrain from slapping my r-b on these two. Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau page_flip function implement not wait vblank, which cause screen garbage
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 to support non-vsync'ed vblank as well, and for vsync'ed blits we had to think about a different mechanism for vblank synchronization anyway, so I figured it didn't make that much sense to force vblank synchronization directly from the pageflip ioctl. >> >> 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 the vbltest program, it prints "60HZ" which indicated the >> implementation of drmWaitVBlank() and drm_vblank_wait() is correct. >> But when I run modetest with option " -v -s 12:1280x1024" , it prints high >> fresh rate up to "150 HZ" . I examing the code , and found that no waiting >> vblank operation is processed in nouveau_crtc_ page_flip() function. The >> screen produced lots of garbage and blink very much. That's fine if by "garbage" you just mean it's tearing like crazy. >>[...] > > It seems to be, the actual page flipping is done by software method > (see nv04_graph_mthd_page_flip). There is one thing i'm unsure about > and that is that we wait for the rendering to be done to the current > frontbuffer and not the current backbuffer (this is only done if the > page flip channel is different than the rendering channel). Maybe > someone else can comment on that. There's no need to wait for the backbuffer rendering to end because the pageflip is always pushed through the last channel that has queued rendering to it, so, the "waiting" is actually done by the GPU. The waiting to the current frontbuffer (which in most cases is going to be a cross-channel barrier instead of actual CPU waiting) 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. pgpGCtyUWX8Et.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau page_flip function implement not wait vblank, which cause screen garbage
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 to > support non-vsync'ed vblank as well, and for vsync'ed blits we had to > think about a different mechanism for vblank synchronization anyway, so > I figured it didn't make that much sense to force vblank synchronization > directly from the pageflip ioctl. +1 I deliberately didn't flip 1 bit in the NV50/NVC0 page flipping code for this as well. The interface IMO is flawed. Though, that said, we really should look at doing something properly for this, a lot of people do want tear-free goodness. Ben. > > >> > >> 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 the vbltest program, it prints "60HZ" which indicated the > >> implementation of drmWaitVBlank() and drm_vblank_wait() is correct. > >> But when I run modetest with option " -v -s 12:1280x1024" , it prints > >> high > >> fresh rate up to "150 HZ" . I examing the code , and found that no waiting > >> vblank operation is processed in nouveau_crtc_ page_flip() function. The > >> screen produced lots of garbage and blink very much. > > That's fine if by "garbage" you just mean it's tearing like crazy. > > >>[...] > > > > It seems to be, the actual page flipping is done by software method > > (see nv04_graph_mthd_page_flip). There is one thing i'm unsure about > > and that is that we wait for the rendering to be done to the current > > frontbuffer and not the current backbuffer (this is only done if the > > page flip channel is different than the rendering channel). Maybe > > someone else can comment on that. > > There's no need to wait for the backbuffer rendering to end because the > pageflip is always pushed through the last channel that has queued > rendering to it, so, the "waiting" is actually done by the GPU. The > waiting to the current frontbuffer (which in most cases is going to be a > cross-channel barrier instead of actual CPU waiting) 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. > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] DRM: omapdrm DRM/KMS driver for TI OMAP platforms
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
> HDMI, DVI, and various types of LCD panels. And it implements GEM
> support for buffer allocation (for KMS as well as offscreen buffers
> used by the xf86-video-omap userspace xorg driver).
>
> The driver maps CRTCs to overlays, encoders to overlay-managers, and
> connectors to dssdev's. Note that this arrangement might change slightly
> when support for drm_plane overlays is added.
>
> For GEM support, non-scanout buffers are using the shmem backed pages
> provided by GEM core (In drm_gem_object_init()). In the case of scanout
> buffers, which need to be physically contiguous, those are allocated
> with CMA and use drm_gem_private_object_init().
>
> See userspace xorg driver:
> git://github.com/robclark/xf86-video-omap.git
>
> Refer to this link for CMA (Continuous Memory Allocator):
> http://lkml.org/lkml/2011/8/19/302
>
> Links to previous versions of the patch:
> v1: http://lwn.net/Articles/458137/
> v2: http://lwn.net/Articles/459397/
>
> History:
>
> v4: bit of rework of encoder/connector _dpms() code, modeset_init()
> rework to not use nested functions, update TODO.txt
> v3: minor cleanups, improved error handling for dev_load(), some minor
> API changes that will be needed later for tiled buffer support
> v2: replace omap_vram with CMA for scanout buffer allocation, remove
> unneeded functions, use dma_addr_t for physical addresses, error
> handling cleanup, refactor attach/detach pages into common drm
> functions, split non-userspace-facing API into omap_priv.h, remove
> plugin API
>
> v1: original
>
> Signed-off-by: Rob Clark
I think this has already seen way too many iterations for a simple
-staging merge ... ;-)
Reviewed-by: Daniel Vetter (for -staging)
> + /* if we couldn't find another connected connector, lets start
> + * looking at the unconnected connectors:
> + *
> + * note: it might not be immediately apparent, but thanks to
> + * the !mgr check in both this loop and the one above, the only
> + * way to enter this loop is with *j == priv->num_connectors,
> + * so idx can never go negative.
> + */
> + while (*j < 2 * priv->num_connectors && !mgr) {
This loop here is still pretty ... strange. Might want to clean that up as
the first patch when merged. Why no just a simple?
for (j = 0; j < num_connectors; j++)
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Give up on edid retries when i2c bus is not responding
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 that bus is not responding, it is mostly pointless
to keep re-trying those attempts over and over again until we reach final
number of retries.
This change should fix
https://bugs.freedesktop.org/show_bug.cgi?id=41059 and improve overall
edid detection timing by 10-30% in most cases, and by a much larger margin
in case of phantom outputs.
v2: added a module parameter to control this behavior. The idea came from
discussion with Jean Delvare.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/drm_edid.c |5 +
drivers/gpu/drm/drm_stub.c |5 +
include/drm/drmP.h |2 ++
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7425e5c..c7426ab 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -265,6 +265,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
unsigned char *buf,
}
};
ret = i2c_transfer(adapter, msgs, 2);
+ if (drm_ignore_unresponsive_edid && ret == -ENXIO) {
+ DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
+ adapter->name);
+ break;
+ }
} while (ret != 2 && --retries);
return ret == 2 ? 0 : -1;
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 6d7b083..b1013fe 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -46,16 +46,21 @@ EXPORT_SYMBOL(drm_vblank_offdelay);
unsigned int drm_timestamp_precision = 20; /* Default to 20 usecs. */
EXPORT_SYMBOL(drm_timestamp_precision);
+unsigned int drm_ignore_unresponsive_edid = 1; /* Ignore non-responding edid
by default */
+EXPORT_SYMBOL(drm_ignore_unresponsive_edid);
+
MODULE_AUTHOR(CORE_AUTHOR);
MODULE_DESCRIPTION(CORE_DESC);
MODULE_LICENSE("GPL and additional rights");
MODULE_PARM_DESC(debug, "Enable debug output");
MODULE_PARM_DESC(vblankoffdelay, "Delay until vblank irq auto-disable
[msecs]");
MODULE_PARM_DESC(timestamp_precision_usec, "Max. error on timestamps [usecs]");
+MODULE_PARM_DESC(ignore_unresponsive_edid, "Automatically ignore outputs which
do not provide EDID after 3 attempts");
module_param_named(debug, drm_debug, int, 0600);
module_param_named(vblankoffdelay, drm_vblank_offdelay, int, 0600);
module_param_named(timestamp_precision_usec, drm_timestamp_precision, int,
0600);
+module_param_named(ignore_unresponsive_edid, drm_ignore_unresponsive_edid,
int, 0600);
struct idr drm_minors_idr;
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 9b7c2bb..d7b0286 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1465,6 +1465,8 @@ extern unsigned int drm_debug;
extern unsigned int drm_vblank_offdelay;
extern unsigned int drm_timestamp_precision;
+extern unsigned int drm_ignore_unresponsive_edid;
+
extern struct class *drm_class;
extern struct proc_dir_entry *drm_proc_root;
extern struct dentry *drm_debugfs_root;
--
1.7.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm: add plane support
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. > > > > Signed-off-by: Jesse Barnes > > 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 the > corresponding pointer needs to hold a ref onto the underlying backing > storage (like e.g. for pageflip on the to-be-flipped-out fb as long > as it might still be scanned out). > > We need proper refcounting for these ... But for now this patch is > missing the plane cleanup in drm_framebuffer_cleanup. Ah yeah that's a better place for the disable plane call I currently have in the intel specific code... I'll fix up and test. > Otherwise I think going with just the src and dst rect for set_plane > is about the only sensible thing given the crazy hw out there. But I > lack the knowledge about that kind of hw (and video stuff in > general), so I'll refrain from slapping my r-b on these two. Yeah, I think the drivers just need to be able to calculate the scaling level from the params and program them into whatever regs they happen to have (on Intel fortunately the scaling is figured out by hw when we program in the source & dest values, subject to some restrictions). Thanks, Jesse ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm: add plane support
> 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 the corresponding > pointer needs to hold a ref onto the underlying backing storage (like > e.g. for pageflip on the to-be-flipped-out fb as long as it might still > be scanned out). > > We need proper refcounting for these ... But for now this patch is missing > the plane cleanup in drm_framebuffer_cleanup. I'd rather we fixed the framebuffer kref stuff as part of doing this rather than have a poorer API because of something we have to fix anyway. It shouldn't be *that* hard to fix, at least for this kind of use case. Resize locking, fb moving etc are ugly issues, refcount shouldn't be, and the tty layer also refcounts so we can only have the fb objects themselves to worry about as we can defer fb destruction to tty close or drm last unref even for those with consoles on them. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm: add plane support
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 that atm > > - drivers that hold onto fbs after the kms core drops the > > corresponding pointer needs to hold a ref onto the underlying > > backing storage (like e.g. for pageflip on the to-be-flipped-out fb > > as long as it might still be scanned out). > > > > We need proper refcounting for these ... But for now this patch is > > missing the plane cleanup in drm_framebuffer_cleanup. > > I'd rather we fixed the framebuffer kref stuff as part of doing this > rather than have a poorer API because of something we have to fix > anyway. > > It shouldn't be *that* hard to fix, at least for this kind of use > case. Resize locking, fb moving etc are ugly issues, refcount > shouldn't be, and the tty layer also refcounts so we can only have > the fb objects themselves to worry about as we can defer fb > destruction to tty close or drm last unref even for those with > consoles on them. Oh it doesn't affect the userspace API so I don't think it's urgent. But I agree, it would be nice to clean up fb management a bit... Any volunteers? :) Thanks, Jesse ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm: add plane support
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 that atm > > - drivers that hold onto fbs after the kms core drops the corresponding > > pointer needs to hold a ref onto the underlying backing storage (like > > e.g. for pageflip on the to-be-flipped-out fb as long as it might still > > be scanned out). > > > > We need proper refcounting for these ... But for now this patch is missing > > the plane cleanup in drm_framebuffer_cleanup. > > I'd rather we fixed the framebuffer kref stuff as part of doing this > rather than have a poorer API because of something we have to fix anyway. Imo we should do things piece by piece. Fixing up drm fb refcounting is imo a rather low-prio thing for core drm. And I've already asked Rob Clarke whether he can clean up some of the confiusion in the kms framebuffer->destroy() functions. > It shouldn't be *that* hard to fix, at least for this kind of use > case. Resize locking, fb moving etc are ugly issues, refcount shouldn't > be, and the tty layer also refcounts so we can only have the fb objects > themselves to worry about as we can defer fb destruction to tty close or I'm talking solely about kms framebuffers. I.e. completely orthogonal to any issues you're seeing wrt kms<->linux fb subsystem integration. Or I'm completely misunderstanding you here ... -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42117] R200 driver performance, UMS, all mesa versions from 7.6
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=1, mode=1 '\001') at r200_swtcl.c:678 #1 0xb63b2dbd in r200WrapRunPipeline (ctx=0x8381c10) at r200_state.c:2449 #2 0xb648f1ee in _tnl_draw_prims (ctx=0x8381c10, arrays=0x83c5804, prim=0x83c42d8, nr_prims=1, ib=0x0, min_index=0, max_index=3) at tnl/t_draw.c:478 #3 0xb648f4f9 in _tnl_vbo_draw_prims (ctx=0x8381c10, arrays=0x83c5804, prim=0x83c42d8, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3) at tnl/t_draw.c:384 #4 0xb648709f in vbo_exec_vtx_flush (exec=0x83c41a8, unmap=1 '\001') at vbo/vbo_exec_draw.c:384 #5 0xb6484d50 in vbo_exec_FlushVertices_internal (ctx=0x8381c10, unmap=1 '\001') at vbo/vbo_exec_api.c:872 #6 0xb6484f3b in vbo_exec_FlushVertices (ctx=0x8381c10, flags=1) at vbo/vbo_exec_api.c:906 #7 0xb646995c in _mesa_BindTexture (target=3553, texName=92) at main/texobj.c:1058 #8 0x080612bb in draw_sky (pos=...) at course_render.cpp:377 #9 0x0808ca8b in Racing::loop (this=0x929dde0, timeStep=9.9982e-14) at racing.cpp:375 #10 0x0807592b in main_loop () at loop.cpp:178 #11 0x08095f75 in winsys_process_events () at winsys.cpp:304 #12 0x08076444 in main (argc=1, argv=0xbf845c24) at main.cpp:307 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42117] R200 driver performance, UMS, all mesa versions from 7.6
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. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm: add plane support
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/drm/drm_crtc.c
index a30b9d4..0cc2077 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1923,7 +1923,8 @@ int drm_mode_addfb(struct drm_device *dev,
r.bpp = or->bpp;
r.depth = or->depth;
r.pixel_format = 0;
- r.handle = or->handle;
+ r.handle_count = 1;
+ r.handles = (u64)&or->handle;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cd7e04d..2c7f200 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7619,8 +7619,9 @@ intel_user_framebuffer_create(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd)
{
struct drm_i915_gem_object *obj;
+ u32 *handles = (u32 *)mode_cmd->handles;
- obj = to_intel_bo(drm_gem_object_lookup(dev, filp, mode_cmd->handle));
+ obj = to_intel_bo(drm_gem_object_lookup(dev, filp, handles[0]));
if (&obj->base == NULL)
return ERR_PTR(-ENOENT);
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 7a428a9..cb9b868 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -128,9 +128,10 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
{
struct nouveau_framebuffer *nouveau_fb;
struct drm_gem_object *gem;
+ u32 *handles = (u32 *)mode_cmd->handles;
int ret;
- gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handle);
+ gem = drm_gem_object_lookup(dev, file_priv, handles);
if (!gem)
return ERR_PTR(-ENOENT);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index ae803f8..63a6d91 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1128,11 +1128,12 @@ radeon_user_framebuffer_create(struct drm_device *dev,
{
struct drm_gem_object *obj;
struct radeon_framebuffer *radeon_fb;
+ u32 *handles = (u32 *)mode_cmd->handles;
- obj = drm_gem_object_lookup(dev, file_priv, mode_cmd->handle);
+ obj = drm_gem_object_lookup(dev, file_priv, handles[0]);
if (obj == NULL) {
dev_err(&dev->pdev->dev, "No GEM object associated to handle
0x%08X, "
- "can't create framebuffer\n", mode_cmd->handle);
+ "can't create framebuffer\n", handles[0]);
return ERR_PTR(-ENOENT);
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 2a1b802..0ad7456 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -866,7 +866,7 @@ static struct drm_framebuffer *vmw_kms_fb_create(struct
drm_device *dev,
*/
ret = vmw_user_surface_lookup_handle(dev_priv, tfile,
-mode_cmd->handle, &surface);
+mode_cmd->handles[0], &surface);
if (ret)
goto try_dmabuf;
diff --git a/drivers/staging/gma500/framebuffer.c
b/drivers/staging/gma500/framebuffer.c
index 85f47d5..ee91ffe 100644
--- a/drivers/staging/gma500/framebuffer.c
+++ b/drivers/staging/gma500/framebuffer.c
@@ -496,7 +496,7 @@ static struct drm_framebuffer *psb_user_framebuffer_create
* Find the GEM object and thus the gtt range object that is
* to back this space
*/
- obj = drm_gem_object_lookup(dev, filp, cmd->handle);
+ obj = drm_gem_object_lookup(dev, filp, cmd->handles[0]);
if (obj == NULL)
return ERR_PTR(-ENOENT);
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;
__u32 pixel_format; /* fourcc code from videodev2.h */
- /* driver specific handle */
- __u32 handle;
+ __u32 handle_count;
+ /* driver specific buffer object handle array */
+ __u64 handles;
};
#define DRM_MODE_FB_DIRTY_ANNOTATE_COPY 0x01
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42175] RV730: Display errors in glxgears & WebGL
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 able to bisect the change that fixed it on the master branch. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/radeon: no need to check all relocs for dublicates
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_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index fae00c0..7b6e98a 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -58,7 +58,7 @@ int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
duplicate = false;
r = (struct drm_radeon_cs_reloc *)&chunk->kdata[i*4];
- for (j = 0; j < p->nrelocs; j++) {
+ for (j = 0; j < i; j++) {
if (r->handle == p->relocs[j].handle) {
p->relocs_ptr[i] = &p->relocs[j];
duplicate = true;
@@ -84,7 +84,8 @@ int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
p->relocs[i].flags = r->flags;
radeon_bo_list_add_object(&p->relocs[i].lobj,
&p->validated);
- }
+ } else
+ p->relocs[i].handle = 0;
}
return radeon_bo_list_validate(&p->validated);
}
--
1.7.5.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/radeon: fix debugfs handling
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 changed, 23 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index c1e056b..c052406 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -881,6 +881,11 @@ void radeon_test_moves(struct radeon_device *rdev);
/*
* Debugfs
*/
+struct radeon_debugfs {
+struct drm_info_list*files;
+unsignednum_files;
+};
+
int radeon_debugfs_add_files(struct radeon_device *rdev,
struct drm_info_list *files,
unsigned nfiles);
@@ -1243,6 +1248,9 @@ struct radeon_device {
struct drm_file *cmask_filp;
/* i2c buses */
struct radeon_i2c_chan *i2c_bus[RADEON_MAX_I2C_BUS];
+ /* debugfs */
+ struct radeon_debugfs debugfs[RADEON_DEBUGFS_MAX_NUM_FILES];
+ unsigneddebugfs_count;
};
int radeon_device_init(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index b51e157..13ac46c 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -977,33 +977,29 @@ int radeon_gpu_reset(struct radeon_device *rdev)
/*
* Debugfs
*/
-struct radeon_debugfs {
- struct drm_info_list*files;
- unsignednum_files;
-};
-static struct radeon_debugfs _radeon_debugfs[RADEON_DEBUGFS_MAX_NUM_FILES];
-static unsigned _radeon_debugfs_count = 0;
-
int radeon_debugfs_add_files(struct radeon_device *rdev,
struct drm_info_list *files,
unsigned nfiles)
{
unsigned i;
- for (i = 0; i < _radeon_debugfs_count; i++) {
- if (_radeon_debugfs[i].files == files) {
+ for (i = 0; i < rdev->debugfs_count; i++) {
+ if (rdev->debugfs[i].files == files) {
/* Already registered */
return 0;
}
}
- if ((_radeon_debugfs_count + nfiles) > RADEON_DEBUGFS_MAX_NUM_FILES) {
- DRM_ERROR("Reached maximum number of debugfs files.\n");
- DRM_ERROR("Report so we increase
RADEON_DEBUGFS_MAX_NUM_FILES.\n");
+
+ i = rdev->debugfs_count + 1;
+ if (i > RADEON_DEBUGFS_MAX_NUM_FILES) {
+ DRM_ERROR("Reached maximum number of debugfs components.\n");
+ DRM_ERROR("Report so we increase "
+ "RADEON_DEBUGFS_MAX_COMPONENTS.\n");
return -EINVAL;
}
- _radeon_debugfs[_radeon_debugfs_count].files = files;
- _radeon_debugfs[_radeon_debugfs_count].num_files = nfiles;
- _radeon_debugfs_count++;
+ rdev->debugfs[rdev->debugfs_count].files = files;
+ rdev->debugfs[rdev->debugfs_count].num_files = nfiles;
+ rdev->debugfs_count = i;
#if defined(CONFIG_DEBUG_FS)
drm_debugfs_create_files(files, nfiles,
rdev->ddev->control->debugfs_root,
@@ -1023,11 +1019,12 @@ int radeon_debugfs_init(struct drm_minor *minor)
void radeon_debugfs_cleanup(struct drm_minor *minor)
{
+struct radeon_device *rdev = minor->dev->dev_private;
unsigned i;
- for (i = 0; i < _radeon_debugfs_count; i++) {
- drm_debugfs_remove_files(_radeon_debugfs[i].files,
-_radeon_debugfs[i].num_files, minor);
+ for (i = 0; i < rdev->debugfs_count; i++) {
+ drm_debugfs_remove_files(rdev->debugfs[i].files,
+rdev->debugfs[i].num_files, minor);
}
}
#endif
--
1.7.5.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/radeon: fix a spelling mistake
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/radeon_ring.c |2 +-
4 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index c052406..f84e95c 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -198,7 +198,7 @@ struct radeon_fence_driver {
wait_queue_head_t queue;
rwlock_tlock;
struct list_headcreated;
- struct list_heademited;
+ struct list_heademitted;
struct list_headsignaled;
boolinitialized;
};
@@ -209,7 +209,7 @@ struct radeon_fence {
struct list_headlist;
/* protected by radeon_fence.lock */
uint32_tseq;
- boolemited;
+ boolemitted;
boolsignaled;
};
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 7fd4e3e..0bb7148 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -74,7 +74,7 @@ int radeon_fence_emit(struct radeon_device *rdev, struct
radeon_fence *fence)
unsigned long irq_flags;
write_lock_irqsave(&rdev->fence_drv.lock, irq_flags);
- if (fence->emited) {
+ if (fence->emitted) {
write_unlock_irqrestore(&rdev->fence_drv.lock, irq_flags);
return 0;
}
@@ -88,8 +88,8 @@ int radeon_fence_emit(struct radeon_device *rdev, struct
radeon_fence *fence)
radeon_fence_ring_emit(rdev, fence);
trace_radeon_fence_emit(rdev->ddev, fence->seq);
- fence->emited = true;
- list_move_tail(&fence->list, &rdev->fence_drv.emited);
+ fence->emitted = true;
+ list_move_tail(&fence->list, &rdev->fence_drv.emitted);
write_unlock_irqrestore(&rdev->fence_drv.lock, irq_flags);
return 0;
}
@@ -129,7 +129,7 @@ static bool radeon_fence_poll_locked(struct radeon_device
*rdev)
return false;
}
n = NULL;
- list_for_each(i, &rdev->fence_drv.emited) {
+ list_for_each(i, &rdev->fence_drv.emitted) {
fence = list_entry(i, struct radeon_fence, list);
if (fence->seq == seq) {
n = i;
@@ -145,7 +145,7 @@ static bool radeon_fence_poll_locked(struct radeon_device
*rdev)
fence = list_entry(i, struct radeon_fence, list);
fence->signaled = true;
i = n;
- } while (i != &rdev->fence_drv.emited);
+ } while (i != &rdev->fence_drv.emitted);
wake = true;
}
return wake;
@@ -159,7 +159,7 @@ static void radeon_fence_destroy(struct kref *kref)
fence = container_of(kref, struct radeon_fence, kref);
write_lock_irqsave(&fence->rdev->fence_drv.lock, irq_flags);
list_del(&fence->list);
- fence->emited = false;
+ fence->emitted = false;
write_unlock_irqrestore(&fence->rdev->fence_drv.lock, irq_flags);
kfree(fence);
}
@@ -174,7 +174,7 @@ int radeon_fence_create(struct radeon_device *rdev, struct
radeon_fence **fence)
}
kref_init(&((*fence)->kref));
(*fence)->rdev = rdev;
- (*fence)->emited = false;
+ (*fence)->emitted = false;
(*fence)->signaled = false;
(*fence)->seq = 0;
INIT_LIST_HEAD(&(*fence)->list);
@@ -203,8 +203,8 @@ bool radeon_fence_signaled(struct radeon_fence *fence)
if (fence->rdev->shutdown) {
signaled = true;
}
- if (!fence->emited) {
- WARN(1, "Querying an unemited fence : %p !\n", fence);
+ if (!fence->emitted) {
+ WARN(1, "Querying an unemitted fence : %p !\n", fence);
signaled = true;
}
if (!signaled) {
@@ -295,11 +295,11 @@ int radeon_fence_wait_next(struct radeon_device *rdev)
return 0;
}
write_lock_irqsave(&rdev->fence_drv.lock, irq_flags);
- if (list_empty(&rdev->fence_drv.emited)) {
+ if (list_empty(&rdev->fence_drv.emitted)) {
write_unlock_irqrestore(&rdev->fence_drv.lock, irq_flags);
return 0;
}
- fence = list_entry(rdev->fence_drv.emited.next,
+ fence = list_entry(rdev->fence_drv.emitted.next,
struct radeon_fence, list);
radeon_fence_ref(fence);
write_unlock_irqrestore(&rdev->fence_drv.lock, irq_flags);
@@ -318,11 +318,11 @
[Bug 42175] RV730: Display errors in glxgears & WebGL
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 bisection required. The bug was fixed by this commit: "r600g: set correct tiling flags in depth info" http://cgit.freedesktop.org/mesa/mesa/commit/?id=faa16dc456f1f910eef24eaa23889be806b513b7 which I just verified by re-compiling mesa with the reversed patch applied. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42117] R200 driver performance, UMS, all mesa versions from 7.6
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 validation fails because it's either over the vram or gart limit. Not sure the calculation there is really fully correct for non-kms, but you could check the limit values used for these (radeonScreen->gartTextures.size and radeonScreen->texSize[0], should be the same as csm->gart_limit and csm->vram_limit in radeon_cs_do_space_check()) - both values actually come from the ddx. Maybe your gart setting is too low. As Alex said though we should fix tiling for the kms case. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm: add plane support
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;
> __u32 pixel_format; /* fourcc code from videodev2.h */
> - /* driver specific handle */
> - __u32 handle;
> + __u32 handle_count;
> + /* driver specific buffer object handle array */
> + __u64 handles;
> };
Ok, after a bit of discussion with Jakob on IRC, this is what we arrived at:
1) It would be nice to have the option for multi-planar formats to be
able to use one single buffer object, or one buffer object per plane.
In the case of one buffer per plane, the order is dictated by the
fourcc.
2) We do need per-plane stride for some formats, in particular I420
which is a bit ambiguous otherwise (ie. is the stride of the U and V
planes half the stride as the Y plane, or the same?)
3) Maybe we need per-plane offsets, but I think this case could be
handled by just using one bo per plane, so left it out
4) bpp/depth are redundant w/ the pixel_format. Just in case, as a
future placeholder, and inspired by 'struct v4l2_pix_format', add a
priv field. Although making the field big enough to hold a pointer if
absolutely really needed.
struct drm_mode_fb_cmd2 {
__u32 fb_id;
__u32 width, height;
__u32 pixel_format; /* fourcc code from videodev2.h */
__u64 priv; /* private data, depends on pixelformat */
/* in case of planar formats, either one buffer object,
* or one buffer object per plane, is allowed. In the
* case per-plane bo's, the order is dictated by the
* fourcc.. ie. NV12 (http://fourcc.org/yuv.php#NV12)
* is described as:
*
* YUV 4:2:0 image with a plane of 8 bit Y samples
* followed by an interleaved U/V plane containing
* 8 bit 2x2 subsampled colour difference samples.
*
* So it would consist of Y as first buffer and UV as
* second buffer. In the case that only a single bo
* is used then buffer[1].handle should be zero. (But
* a plane specific pitch could still be specified.)
*/
struct {
__u32 pitch;
/* driver specific handle */
__u32 handle;
} buffer[16];
};
BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm: add plane support
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 +272,9 @@ struct drm_mode_fb_cmd2 {
> > __u32 bpp;
> > __u32 depth;
> > __u32 pixel_format; /* fourcc code from videodev2.h */
> > - /* driver specific handle */
> > - __u32 handle;
> > + __u32 handle_count;
> > + /* driver specific buffer object handle array */
> > + __u64 handles;
> > };
>
>
> Ok, after a bit of discussion with Jakob on IRC, this is what we arrived at:
>
> 1) It would be nice to have the option for multi-planar formats to be
> able to use one single buffer object, or one buffer object per plane.
> In the case of one buffer per plane, the order is dictated by the
> fourcc.
>
> 2) We do need per-plane stride for some formats, in particular I420
> which is a bit ambiguous otherwise (ie. is the stride of the U and V
> planes half the stride as the Y plane, or the same?)
>
> 3) Maybe we need per-plane offsets, but I think this case could be
> handled by just using one bo per plane, so left it out
>
> 4) bpp/depth are redundant w/ the pixel_format. Just in case, as a
> future placeholder, and inspired by 'struct v4l2_pix_format', add a
> priv field. Although making the field big enough to hold a pointer if
> absolutely really needed.
>
> struct drm_mode_fb_cmd2 {
> __u32 fb_id;
> __u32 width, height;
> __u32 pixel_format; /* fourcc code from videodev2.h */
> __u64 priv; /* private data, depends on pixelformat */
>
> /* in case of planar formats, either one buffer object,
>* or one buffer object per plane, is allowed. In the
>* case per-plane bo's, the order is dictated by the
>* fourcc.. ie. NV12 (http://fourcc.org/yuv.php#NV12)
>* is described as:
>*
>* YUV 4:2:0 image with a plane of 8 bit Y samples
>* followed by an interleaved U/V plane containing
>* 8 bit 2x2 subsampled colour difference samples.
>*
>* So it would consist of Y as first buffer and UV as
>* second buffer. In the case that only a single bo
>* is used then buffer[1].handle should be zero. (But
>* a plane specific pitch could still be specified.)
>*/
> struct {
> __u32 pitch;
> /* driver specific handle */
> __u32 handle;
Why not just add a
__u32 offset;
__u32 rsvd;
and call it a day. This thing is pretty big already, so that bloat doesn't
matter that much. Maybe spec that buffer[0].offset must be zero. With that
you can also do I420 with the following layout
+---+
|YYY|
|YYY|
|YYY|
|YYY|
+---+---+
|UUU|VVV|
|UUU|VVV|
+---+---+
i.e. stride_U == stride_V, with their lines meshed into one line.
-Daniel
> } buffer[16];
> };
>
>
> BR,
> -R
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42117] R200 driver performance, UMS, all mesa versions from 7.6
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. rcommonInitCmdBuf (rmesa=0x837c8d8) at radeon_common.c:1297 1297radeon_cs_set_limit(rmesa->cmdbuf.cs, RADEON_GEM_DOMAIN_GTT, rmesa->radeonScreen->gartTextures.size); (gdb) print rmesa->radeonScreen->texSize[0] $7 = 109051904 (gdb) print rmesa->radeonScreen->gartTextures.size $8 = 5111808 values equal to this from Xlog bash-4.1$ cat /var/log/Xorg.0.log |grep textures [42.691] (II) RADEON(0): Using 5 MB for GART textures [42.691] (II) RADEON(0): Will use 106496 kb for textures at offset 0x180 bash-4.1$ cat /var/log/Xorg.0.log |grep GART [42.691] (II) RADEON(0): Using 8 MB GART aperture [42.691] (II) RADEON(0): Using 5 MB for GART textures [42.716] (II) RADEON(0): [agp] GART texture map handle = 0xe0302000 [42.717] (II) RADEON(0): [agp] GART Texture map mapped at 0xae7fd000 [42.964] (II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808 radeon_cs_do_space_check() - gdb with breakpoint to it never stops/breaks -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm: add plane support
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/drm/drm_mode.h
>> > +++ b/include/drm/drm_mode.h
>> > @@ -272,8 +272,9 @@ struct drm_mode_fb_cmd2 {
>> > __u32 bpp;
>> > __u32 depth;
>> > __u32 pixel_format; /* fourcc code from videodev2.h */
>> > - /* driver specific handle */
>> > - __u32 handle;
>> > + __u32 handle_count;
>> > + /* driver specific buffer object handle array */
>> > + __u64 handles;
>> > };
>>
>>
>> Ok, after a bit of discussion with Jakob on IRC, this is what we arrived at:
>>
>> 1) It would be nice to have the option for multi-planar formats to be
>> able to use one single buffer object, or one buffer object per plane.
>> In the case of one buffer per plane, the order is dictated by the
>> fourcc.
>>
>> 2) We do need per-plane stride for some formats, in particular I420
>> which is a bit ambiguous otherwise (ie. is the stride of the U and V
>> planes half the stride as the Y plane, or the same?)
>>
>> 3) Maybe we need per-plane offsets, but I think this case could be
>> handled by just using one bo per plane, so left it out
>>
>> 4) bpp/depth are redundant w/ the pixel_format. Just in case, as a
>> future placeholder, and inspired by 'struct v4l2_pix_format', add a
>> priv field. Although making the field big enough to hold a pointer if
>> absolutely really needed.
>>
>> struct drm_mode_fb_cmd2 {
>> __u32 fb_id;
>> __u32 width, height;
>> __u32 pixel_format; /* fourcc code from videodev2.h */
>> __u64 priv; /* private data, depends on pixelformat */
>>
>> /* in case of planar formats, either one buffer object,
>> * or one buffer object per plane, is allowed. In the
>> * case per-plane bo's, the order is dictated by the
>> * fourcc.. ie. NV12 (http://fourcc.org/yuv.php#NV12)
>> * is described as:
>> *
>> * YUV 4:2:0 image with a plane of 8 bit Y samples
>> * followed by an interleaved U/V plane containing
>> * 8 bit 2x2 subsampled colour difference samples.
>> *
>> * So it would consist of Y as first buffer and UV as
>> * second buffer. In the case that only a single bo
>> * is used then buffer[1].handle should be zero. (But
>> * a plane specific pitch could still be specified.)
>> */
>> struct {
>> __u32 pitch;
>> /* driver specific handle */
>> __u32 handle;
>
> Why not just add a
> __u32 offset;
> __u32 rsvd;
> and call it a day. This thing is pretty big already, so that bloat doesn't
> matter that much. Maybe spec that buffer[0].offset must be zero. With that
> you can also do I420 with the following layout
> +---+
> |YYY|
> |YYY|
> |YYY|
> |YYY|
> +---+---+
> |UUU|VVV|
> |UUU|VVV|
> +---+---+
>
> i.e. stride_U == stride_V, with their lines meshed into one line.
> -Daniel
>
I've no objection to an offset field.. I was mostly just trying to
avoid that we keep adding things until we get XvImageFormatValues..
We should either add an offset plus pad field as Daniel suggested, or
at least add a u64 reserved field which could be made into made into
an offset field later if needed.
OTOH, is the format you described *really* still I420?
BR,
-R
>> } buffer[16];
>> };
>>
>>
>> BR,
>> -R
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Mail: dan...@ffwll.ch
> Mobile: +41 (0)79 365 57 48
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41698] [r300g] Flickering user interface in WoW
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 and it coincides with me no longer reverting the problem patch. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] vmwgfx: Reinstate the update_layout ioctl
We need to redefine a connector as "connected" if it matches a window
in the host preferred GUI layout.
Otherwise "smart" window managers would turn on Xorg outputs that we don't
want to be on.
This reinstates the update_layout and adds the following information to
the modesetting system.
a) Connection status <-> Equivalent to real hardware connection status
b) Preferred mode <-> Equivalent to real hardware reading EDID
c) Host window position <-> Equivalent to a real hardware scanout address
dynamic register.
It should be noted that there is no assumption here about what should be
displayed and where. Only how to access the host windows.
This also bumps minor to signal availability of the new IOCTL.
Based on code originally written by Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |6 +++
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |6 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 66 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |9 -
include/drm/vmwgfx_drm.h| 51 +--
5 files changed, 107 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index b8eb8cd..0bc20c1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -103,6 +103,9 @@
#define DRM_IOCTL_VMW_PRESENT_READBACK \
DRM_IOW(DRM_COMMAND_BASE + DRM_VMW_PRESENT_READBACK,\
struct drm_vmw_present_readback_arg)
+#define DRM_IOCTL_VMW_UPDATE_LAYOUT\
+ DRM_IOW(DRM_COMMAND_BASE + DRM_VMW_UPDATE_LAYOUT, \
+struct drm_vmw_update_layout_arg)
/**
* The core DRM version of this macro doesn't account for
@@ -165,6 +168,9 @@ static struct drm_ioctl_desc vmw_ioctls[] = {
VMW_IOCTL_DEF(VMW_PRESENT_READBACK,
vmw_present_readback_ioctl,
DRM_MASTER | DRM_AUTH | DRM_UNLOCKED),
+ VMW_IOCTL_DEF(VMW_UPDATE_LAYOUT,
+ vmw_kms_update_layout_ioctl,
+ DRM_MASTER | DRM_UNLOCKED),
};
static struct pci_device_id vmw_pci_id_list[] = {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 30589d0..8cca91a 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 VMWGFX_DRIVER_MAJOR 2
-#define VMWGFX_DRIVER_MINOR 2
+#define VMWGFX_DRIVER_MINOR 3
#define VMWGFX_DRIVER_PATCHLEVEL 0
#define VMWGFX_FILE_PAGE_OFFSET 0x0010
#define VMWGFX_FIFO_STATIC_SIZE (1024*1024)
@@ -633,6 +633,8 @@ int vmw_kms_readback(struct vmw_private *dev_priv,
struct drm_vmw_fence_rep __user *user_fence_rep,
struct drm_vmw_rect *clips,
uint32_t num_clips);
+int vmw_kms_update_layout_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
/**
* Overlay control - vmwgfx_overlay.c
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 8b14dfd..f9a0f98 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1517,6 +1517,8 @@ int vmw_du_update_layout(struct vmw_private *dev_priv,
unsigned num,
du->pref_width = rects[du->unit].w;
du->pref_height = rects[du->unit].h;
du->pref_active = true;
+ du->gui_x = rects[du->unit].x;
+ du->gui_y = rects[du->unit].y;
} else {
du->pref_width = 800;
du->pref_height = 600;
@@ -1572,12 +1574,14 @@ vmw_du_connector_detect(struct drm_connector
*connector, bool force)
uint32_t num_displays;
struct drm_device *dev = connector->dev;
struct vmw_private *dev_priv = vmw_priv(dev);
+ struct vmw_display_unit *du = vmw_connector_to_du(connector);
mutex_lock(&dev_priv->hw_mutex);
num_displays = vmw_read(dev_priv, SVGA_REG_NUM_DISPLAYS);
mutex_unlock(&dev_priv->hw_mutex);
- return ((vmw_connector_to_du(connector)->unit < num_displays) ?
+ return ((vmw_connector_to_du(connector)->unit < num_displays &&
+du->pref_active) ?
connector_status_connected : connector_status_disconnected);
}
@@ -1723,3 +1727,63 @@ int vmw_du_connector_set_property(struct drm_connector
*connector,
{
return 0;
}
+
+
+int vmw_kms_update_layout_ioctl(struct drm_device *dev, void *data,
+
[PATCH] drm/radeon/kms: remove useless radeon_ddc_dump()
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 of extra DDC probing.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_display.c | 33 ---
1 files changed, 0 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 6adb3e5..4998736 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -33,8 +33,6 @@
#include "drm_crtc_helper.h"
#include "drm_edid.h"
-static int radeon_ddc_dump(struct drm_connector *connector);
-
static void avivo_crtc_load_lut(struct drm_crtc *crtc)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
@@ -669,7 +667,6 @@ static void radeon_print_display_setup(struct drm_device
*dev)
static bool radeon_setup_enc_conn(struct drm_device *dev)
{
struct radeon_device *rdev = dev->dev_private;
- struct drm_connector *drm_connector;
bool ret = false;
if (rdev->bios) {
@@ -689,8 +686,6 @@ static bool radeon_setup_enc_conn(struct drm_device *dev)
if (ret) {
radeon_setup_encoder_clones(dev);
radeon_print_display_setup(dev);
- list_for_each_entry(drm_connector,
&dev->mode_config.connector_list, head)
- radeon_ddc_dump(drm_connector);
}
return ret;
@@ -743,34 +738,6 @@ int radeon_ddc_get_modes(struct radeon_connector
*radeon_connector)
return 0;
}
-static int radeon_ddc_dump(struct drm_connector *connector)
-{
- struct edid *edid;
- struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
- int ret = 0;
-
- /* on hw with routers, select right port */
- if (radeon_connector->router.ddc_valid)
- radeon_router_select_ddc_port(radeon_connector);
-
- if (!radeon_connector->ddc_bus)
- return -1;
- edid = drm_get_edid(connector, &radeon_connector->ddc_bus->adapter);
- /* Log EDID retrieval status here. In particular with regard to
-* connectors with requires_extended_probe flag set, that will prevent
-* function radeon_dvi_detect() to fetch EDID on this connector,
-* as long as there is no valid EDID header found */
- if (edid) {
- DRM_INFO("Radeon display connector %s: Found valid EDID",
- drm_get_connector_name(connector));
- kfree(edid);
- } else {
- DRM_INFO("Radeon display connector %s: No monitor connected or
invalid EDID",
- drm_get_connector_name(connector));
- }
- return ret;
-}
-
/* avivo */
static void avivo_get_fb_div(struct radeon_pll *pll,
u32 target_clock,
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/radeon/kms: rework texture cache flush in r6xx+ blit code
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 +-
drivers/gpu/drm/radeon/radeon.h |2 +-
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
index dcf11bb..879f733 100644
--- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
+++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
@@ -174,7 +174,7 @@ set_vtx_resource(struct radeon_device *rdev, u64 gpu_addr)
static void
set_tex_resource(struct radeon_device *rdev,
int format, int w, int h, int pitch,
-u64 gpu_addr)
+u64 gpu_addr, u32 size)
{
u32 sq_tex_resource_word0, sq_tex_resource_word1;
u32 sq_tex_resource_word4, sq_tex_resource_word7;
@@ -196,6 +196,9 @@ set_tex_resource(struct radeon_device *rdev,
sq_tex_resource_word7 = format |
S__SQ_CONSTANT_TYPE(SQ_TEX_VTX_VALID_TEXTURE);
+ cp_set_surface_sync(rdev,
+ PACKET3_TC_ACTION_ENA, size, gpu_addr);
+
radeon_ring_write(rdev, PACKET3(PACKET3_SET_RESOURCE, 8));
radeon_ring_write(rdev, 0);
radeon_ring_write(rdev, sq_tex_resource_word0);
diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c
b/drivers/gpu/drm/radeon/r600_blit_kms.c
index c4cf130..ff36532 100644
--- a/drivers/gpu/drm/radeon/r600_blit_kms.c
+++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
@@ -201,7 +201,7 @@ set_vtx_resource(struct radeon_device *rdev, u64 gpu_addr)
static void
set_tex_resource(struct radeon_device *rdev,
int format, int w, int h, int pitch,
-u64 gpu_addr)
+u64 gpu_addr, u32 size)
{
uint32_t sq_tex_resource_word0, sq_tex_resource_word1,
sq_tex_resource_word4;
@@ -222,6 +222,9 @@ set_tex_resource(struct radeon_device *rdev,
S_038010_DST_SEL_Z(SQ_SEL_Z) |
S_038010_DST_SEL_W(SQ_SEL_W);
+ cp_set_surface_sync(rdev,
+ PACKET3_TC_ACTION_ENA, size, gpu_addr);
+
radeon_ring_write(rdev, PACKET3(PACKET3_SET_RESOURCE, 7));
radeon_ring_write(rdev, 0);
radeon_ring_write(rdev, sq_tex_resource_word0);
@@ -760,10 +763,7 @@ void r600_kms_blit_copy(struct radeon_device *rdev,
vb[11] = i2f(h);
rdev->r600_blit.primitives.set_tex_resource(rdev, FMT_8_8_8_8,
- w, h, w,
src_gpu_addr);
- rdev->r600_blit.primitives.cp_set_surface_sync(rdev,
-
PACKET3_TC_ACTION_ENA,
- size_in_bytes,
src_gpu_addr);
+ w, h, w,
src_gpu_addr, size_in_bytes);
rdev->r600_blit.primitives.set_render_target(rdev,
COLOR_8_8_8_8,
w, h,
dst_gpu_addr);
rdev->r600_blit.primitives.set_scissors(rdev, 0, 0, w, h);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index aa11ae8..c16724f 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -585,7 +585,7 @@ struct r600_blit_cp_primitives {
void (*set_vtx_resource)(struct radeon_device *rdev, u64 gpu_addr);
void (*set_tex_resource)(struct radeon_device *rdev,
int format, int w, int h, int pitch,
-u64 gpu_addr);
+u64 gpu_addr, u32 size);
void (*set_scissors)(struct radeon_device *rdev, int x1, int y1,
int x2, int y2);
void (*draw_auto)(struct radeon_device *rdev);
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon/kms/cayman/blit: specify CP_COHER_CNTL2 with surface_sync
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 --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
index 879f733..551e76f 100644
--- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
+++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
@@ -94,6 +94,15 @@ cp_set_surface_sync(struct radeon_device *rdev,
else
cp_coher_size = ((size + 255) >> 8);
+ if (rdev->family >= CHIP_CAYMAN) {
+ /* CP_COHER_CNTL2 has to be set manually when submitting a
surface_sync
+* to the RB directly. For IBs, the CP programs this as part of
the
+* surface_sync packet.
+*/
+ radeon_ring_write(rdev, PACKET3(PACKET3_SET_CONFIG_REG, 1));
+ radeon_ring_write(rdev, (0x85e8 - PACKET3_SET_CONFIG_REG_START)
>> 2);
+ radeon_ring_write(rdev, 0); /* CP_COHER_CNTL2 */
+ }
radeon_ring_write(rdev, PACKET3(PACKET3_SURFACE_SYNC, 3));
radeon_ring_write(rdev, sync_type);
radeon_ring_write(rdev, cp_coher_size);
@@ -621,6 +630,8 @@ int evergreen_blit_init(struct radeon_device *rdev)
rdev->r600_blit.ring_size_common += 10; /* fence emit for done copy */
rdev->r600_blit.ring_size_per_loop = 74;
+ if (rdev->family >= CHIP_CAYMAN)
+ rdev->r600_blit.ring_size_per_loop += 9; /* additional DWs for
surface sync */
rdev->r600_blit.max_dim = 16384;
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm: add plane support
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 mode object
+ * @crtc_x: x position of plane (relative to pipe base)
+ * @crtc_y: y position of plane
+ * @x: x offset into fb
+ * @y: y offset into fb
Above 4 members don't be used.
Oops yeah, I'll fix up the comments.
+
+struct drm_mode_get_plane {
+ __u64 format_type_ptr;
+ __u32 plane_id;
+
+ __u32 crtc_id;
+ __u32 fb_id;
+
+ __u32 possible_crtcs;
+ __u32 gamma_size;
+
+ __u32 count_format_types;
+};
I wonder why doesn't give to user crtc_x, crtc_y, crtc_w, crtc_h
information?
It could, but the caller should already know was my thinking. Would
you like those bits returned?
I saw such codes in initial your RFC patch version so i just have
wondered why it is removed. It can be added later if needs.
Thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM planes and new fb creation ioctl
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 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 well, so I'm just going to push them out. (Note IVB support is still missing a few bits for scaling and such; I'll fix those up when I get back home and can test on IVB again.) One change you may notice from the last set is that I've removed the 'zpos' parameter. Plane blending and z ordering is very chipset specific (it even varies between Intel chipsets), so exposing it through a device specific ioctl is probably a better plan. But i think zpos is essential parameter of plane. If plane doesn't support it, drm driver cannot know user wants to use which overlay, so i wonder what it meant DRM_IOCTL_MODE_SETPLANE zpos is absent . Setplane is just for attaching a new fb. The order, keying, or whatever else your plane blender can support can be set with a device specific ioctl before or after the setplane call (probably before to avoid any flashing or bad frames). OK, i see. Thanks. If use device specific ioctl, should implement device specific ioctl for DRM_IOCTL_MODE_SETPLANE? You could if you needed, but I don't think it's strictly necessary. By default, planes should just overlay the primary plane; a device specific ioctl (none available yet, but I have some planned for i915) can provide more flexibility. Could you explain what is the primary plane? Is it same as the overlay handled by crtc? It confuses a bit when one overlay is handled by crtc and plane at the same time. Yeah, it is a little confusing. When I refer to the primary, I'm referring to the plane bound to the CRTC. I'm fine if someone wants to break that out, I think it would make sense. I just didn't want to write the compat code that would be required for that scheme. :) But these patches definitely don't preclude it, and I don't think these interfaces will need changes if we ever move to a pipe/plane split at the userland level. Could you have the policy about fb of overlay? For example, user attaches the fb of plane to the overlay already using by CRTC, then output of overlay will be changed to the fb of plane from fb of CRTC. And if user detaches the fb of plane, the overlay again should output the fb of CRTC? or just be disabled? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
drm/fb_helper: prevent some troubles waiting to happen
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 variety of AMD cards that I have. I don't have other GPUs handy. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/fb_helper: make sure crtc_count is consistent
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 |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f7c6854..feac888 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -466,10 +466,18 @@ int drm_fb_helper_init(struct drm_device *dev,
i = 0;
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
+ if (i >= crtc_count) {
+ DRM_DEBUG("crtc count set by the gpu reached\n");
+ break;
+ }
fb_helper->crtc_info[i].crtc_id = crtc->base.id;
fb_helper->crtc_info[i].mode_set.crtc = crtc;
i++;
}
+ if (i < fb_helper->crtc_count) {
+ DRM_DEBUG("crtc count known by the drm reached\n");
+ fb_helper->crtc_count = i;
+ }
fb_helper->conn_limit = max_conn_count;
return 0;
out_free:
--
1.7.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/fb_helper: honor the limit on number of connectors per crtc
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 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index feac888..19e28e9 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1333,6 +1333,11 @@ static void drm_setup_crtcs(struct drm_fb_helper
*fb_helper)
modeset = &fb_crtc->mode_set;
if (mode && fb_crtc) {
+ if (modeset->num_connectors >= fb_helper->conn_limit) {
+ DRM_DEBUG("max number of connectors reached for
crtc %d\n",
+ fb_crtc->crtc_id);
+ break;
+ }
DRM_DEBUG_KMS("desired mode %s set on crtc %d\n",
mode->name,
fb_crtc->mode_set.crtc->base.id);
fb_crtc->desired_mode = mode;
--
1.7.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
drm: fix one flawed mutex grab and remove some spurious mutex grabs
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 explanation. The third one: [PATCH 3/3] drm: do not sleep on vblank while holding a mutex is more serious and clears a clog that can occur if multiple processes call drm_wait_vblank as explained in patch commit message. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: no need to hold global mutex for static data
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_drv.c b/drivers/gpu/drm/drm_drv.c
index 7a87e08..e159f17 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -60,14 +60,14 @@ static int drm_version(struct drm_device *dev, void *data,
/** Ioctl table */
static struct drm_ioctl_desc drm_ioctls[] = {
- DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version, 0),
+ DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0),
DRM_IOCTL_DEF(DRM_IOCTL_GET_MAGIC, drm_getmagic, 0),
DRM_IOCTL_DEF(DRM_IOCTL_IRQ_BUSID, drm_irq_by_busid,
DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_GET_MAP, drm_getmap, 0),
DRM_IOCTL_DEF(DRM_IOCTL_GET_CLIENT, drm_getclient, 0),
DRM_IOCTL_DEF(DRM_IOCTL_GET_STATS, drm_getstats, 0),
- DRM_IOCTL_DEF(DRM_IOCTL_GET_CAP, drm_getcap, 0),
+ DRM_IOCTL_DEF(DRM_IOCTL_GET_CAP, drm_getcap, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_SET_VERSION, drm_setversion, DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_SET_UNIQUE, drm_setunique,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
--
1.7.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm: make DRM_UNLOCKED ioctls with their own mutex
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/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index e159f17..dbabcb0 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -64,9 +64,9 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0),
DRM_IOCTL_DEF(DRM_IOCTL_GET_MAGIC, drm_getmagic, 0),
DRM_IOCTL_DEF(DRM_IOCTL_IRQ_BUSID, drm_irq_by_busid,
DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_IOCTL_GET_MAP, drm_getmap, 0),
- DRM_IOCTL_DEF(DRM_IOCTL_GET_CLIENT, drm_getclient, 0),
- DRM_IOCTL_DEF(DRM_IOCTL_GET_STATS, drm_getstats, 0),
+ DRM_IOCTL_DEF(DRM_IOCTL_GET_MAP, drm_getmap, DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_GET_CLIENT, drm_getclient, DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_GET_STATS, drm_getstats, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_GET_CAP, drm_getcap, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_SET_VERSION, drm_setversion, DRM_MASTER),
--
1.7.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm: do not sleep on vblank while holding a mutex
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.
fix it, but making drm_wait_vblank DRM_UNLOCKED call and
then grabbing the mutex inside the drm_wait_vblank function
and only for the duration of the critical section (i.e.,
from first manipulation of vblank sequence number until
putting the task in the wait queue).
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_drv.c |2 +-
drivers/gpu/drm/drm_irq.c | 16 +++-
include/drm/drm_os_linux.h | 25 +
3 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index dbabcb0..dc0eb0b 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -124,7 +124,7 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_SG_ALLOC, drm_sg_alloc_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_SG_FREE, drm_sg_free,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_IOCTL_WAIT_VBLANK, drm_wait_vblank, 0),
+ DRM_IOCTL_DEF(DRM_IOCTL_WAIT_VBLANK, drm_wait_vblank, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODESET_CTL, drm_modeset_ctl, 0),
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3830e9e..d85d604 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1191,6 +1191,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
DRM_DEBUG("failed to acquire vblank counter, %d\n", ret);
return ret;
}
+ mutex_lock(&drm_global_mutex);
seq = drm_vblank_count(dev, crtc);
switch (vblwait->request.type & _DRM_VBLANK_TYPES_MASK) {
@@ -1200,12 +1201,15 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
case _DRM_VBLANK_ABSOLUTE:
break;
default:
+ mutex_unlock(&drm_global_mutex);
ret = -EINVAL;
goto done;
}
- if (flags & _DRM_VBLANK_EVENT)
+ if (flags & _DRM_VBLANK_EVENT) {
+ mutex_unlock(&drm_global_mutex);
return drm_queue_vblank_event(dev, crtc, vblwait, file_priv);
+ }
if ((flags & _DRM_VBLANK_NEXTONMISS) &&
(seq - vblwait->request.sequence) <= (1<<23)) {
@@ -1215,10 +1219,12 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
DRM_DEBUG("waiting on vblank count %d, crtc %d\n",
vblwait->request.sequence, crtc);
dev->last_vblank_wait[crtc] = vblwait->request.sequence;
- DRM_WAIT_ON(ret, dev->vbl_queue[crtc], 3 * DRM_HZ,
- (((drm_vblank_count(dev, crtc) -
- vblwait->request.sequence) <= (1 << 23)) ||
-!dev->irq_enabled));
+ /* DRM_WAIT_ON_LOCKED will release drm_global_mutex */
+ /* before going to sleep */
+ DRM_WAIT_ON_LOCKED(ret, dev->vbl_queue[crtc], 3 * DRM_HZ,
+ (((drm_vblank_count(dev, crtc) -
+ vblwait->request.sequence) <= (1 << 23)) ||
+ !dev->irq_enabled));
if (ret != -EINTR) {
struct timeval now;
diff --git a/include/drm/drm_os_linux.h b/include/drm/drm_os_linux.h
index 3933691..fc6aaf4 100644
--- a/include/drm/drm_os_linux.h
+++ b/include/drm/drm_os_linux.h
@@ -123,5 +123,30 @@ do {
\
remove_wait_queue(&(queue), &entry);\
} while (0)
+#define DRM_WAIT_ON_LOCKED( ret, queue, timeout, condition ) \
+do { \
+ DECLARE_WAITQUEUE(entry, current); \
+ unsigned long end = jiffies + (timeout);\
+ add_wait_queue(&(queue), &entry); \
+ mutex_unlock(&drm_global_mutex);\
+ \
+ for (;;) { \
+ __set_current_state(TASK_INTERRUPTIBLE);\
+ if (condition) \
+ break; \
+ if (time_after_eq(jiffies, end)) { \
+ ret = -EBUSY; \
+ break; \
+ } \
+ schedule_timeout((HZ/100 > 1) ? HZ/100 : 1);\
+ if (signal_pending(current)) { \
+ ret = -EINTR; \
+ break;
drm/radeon/kms: a few nits
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 that is used only by r100 ASICs, but make the code more correct (strictly speaking). The second patch: [PATCH 2/3] drm/radeon/kms: fix the crtc number check makes the crtc number check consistent with the way it is done in the rest of the driver code without affecting the functionality. It was actually sent a few months ago and reviewed, but apparently forgotten (cf. http://lists.freedesktop.org/archives/dri-devel/2011-May/010935.html) The third patch: [PATCH 3/3] drm/radeon/kms: use num_crtc instead of hard-coded value Prevents a possible trouble waiting to happen if AMD ever makes a GPU with more than 6 CRTCs. I don't know what's cooking in their kitchen but if such a GPU ever comes out, this will prevent at least one regression ;-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/radeon/kms: use crtc-specific dpms functions in prepare and commit
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(-)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index 41a5d48..0690a5b 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -1036,8 +1036,11 @@ static void radeon_crtc_prepare(struct drm_crtc *crtc)
* The hardware wedges sometimes if you reconfigure one CRTC
* whilst another is running (see fdo bug #24611).
*/
- list_for_each_entry(crtci, &dev->mode_config.crtc_list, head)
- radeon_crtc_dpms(crtci, DRM_MODE_DPMS_OFF);
+ list_for_each_entry(crtci, &dev->mode_config.crtc_list, head) {
+ struct drm_crtc_helper_funcs *crtc_funcs =
crtci->helper_private;
+ if (crtc_funcs->dpms)
+ crtc_funcs->dpms(crtci, DRM_MODE_DPMS_OFF);
+ }
}
static void radeon_crtc_commit(struct drm_crtc *crtc)
@@ -1049,8 +1052,11 @@ static void radeon_crtc_commit(struct drm_crtc *crtc)
* Reenable the CRTCs that should be running.
*/
list_for_each_entry(crtci, &dev->mode_config.crtc_list, head) {
- if (crtci->enabled)
- radeon_crtc_dpms(crtci, DRM_MODE_DPMS_ON);
+ if (crtci->enabled) {
+ struct drm_crtc_helper_funcs *crtc_funcs =
crtci->helper_private;
+ if (crtc_funcs->dpms)
+ crtc_funcs->dpms(crtci, DRM_MODE_DPMS_ON);
+ }
}
}
--
1.7.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/radeon/kms: use num_crtc instead of hard-coded value 6
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 than 6 CRTCs, this is still OK because
higher numbers won't be looked at)
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_irq_kms.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 9ec830c..a0f9d24 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -69,7 +69,7 @@ void radeon_driver_irq_preinstall_kms(struct drm_device *dev)
rdev->irq.gui_idle = false;
for (i = 0; i < rdev->num_crtc; i++)
rdev->irq.crtc_vblank_int[i] = false;
- for (i = 0; i < 6; i++) {
+ for (i = 0; i < rdev->num_crtc; i++) {
rdev->irq.hpd[i] = false;
rdev->irq.pflip[i] = false;
}
@@ -101,7 +101,7 @@ void radeon_driver_irq_uninstall_kms(struct drm_device *dev)
rdev->irq.gui_idle = false;
for (i = 0; i < rdev->num_crtc; i++)
rdev->irq.crtc_vblank_int[i] = false;
- for (i = 0; i < 6; i++) {
+ for (i = 0; i < rdev->num_crtc; i++) {
rdev->irq.hpd[i] = false;
rdev->irq.pflip[i] = false;
}
--
1.7.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/radeon/kms: fix the crtc number check
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/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index a749c26..540a9ee 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -347,7 +347,7 @@ int radeon_get_vblank_timestamp_kms(struct drm_device *dev,
int crtc,
struct drm_crtc *drmcrtc;
struct radeon_device *rdev = dev->dev_private;
- if (crtc < 0 || crtc >= dev->num_crtcs) {
+ if (crtc < 0 || crtc >= rdev->num_crtc) {
DRM_ERROR("Invalid crtc %d\n", crtc);
return -EINVAL;
}
--
1.7.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm: add plane support
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_MODE_OBJECT_FB 0xfbfbfbfb
#define DRM_MODE_OBJECT_BLOB 0x
+#define DRM_MODE_OBJECT_PLANE 0x
struct drm_mode_object {
uint32_t id;
@@ -278,6 +279,7 @@ struct drm_crtc;
struct drm_connector;
struct drm_encoder;
struct drm_pending_vblank_event;
+struct drm_plane;
/**
* drm_crtc_funcs - control CRTCs for a given device
@@ -536,6 +538,58 @@ struct drm_connector {
};
/**
+ * drm_plane_funcs - driver plane control functions
+ * @update_plane: update the plane configuration
+ */
+struct drm_plane_funcs {
+ int (*update_plane)(struct drm_plane *plane,
+ struct drm_crtc *crtc, struct drm_framebuffer *fb,
+ int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h);
+ int (*disable_plane)(struct drm_plane *plane);
+};
How about add destroy() function and call it in
drm_mode_config_cleanup()?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] CHROMIUM: i915: Add DMI override to skip CRT initialization on ZGB
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=chrome-os-partner:117
TEST=Check PORT_HOTPLUG_EN to see if hotplug interrupt is disabled.
Run the following command as root, specifically looking at bit 9:
mmio_read32 $[$(pci_read32 0 2 0 0x10) + 0x61110] = 0x
Change-Id: Id8240f9fb31d058d8d79ee72f7b4615c43893f5a
Reviewed-on: http://gerrit.chromium.org/gerrit/1390
Reviewed-by: Olof Johansson
Tested-by: Duncan Laurie
---
drivers/gpu/drm/i915/intel_crt.c | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 0979d88..c1ecbfd 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -24,6 +24,7 @@
* Eric Anholt
*/
+#include
#include
#include
#include "drmP.h"
@@ -544,6 +545,24 @@ static const struct drm_encoder_funcs intel_crt_enc_funcs
= {
.destroy = intel_encoder_destroy,
};
+static int __init intel_no_crt_dmi_callback(const struct dmi_system_id *id)
+{
+ DRM_DEBUG_KMS("Skipping CRT initialization for %s\n", id->ident);
+ return 1;
+}
+
+static const struct dmi_system_id intel_no_crt[] = {
+ {
+ .callback = intel_no_crt_dmi_callback,
+ .ident = "ACER ZGB",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ACER"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "ZGB"),
+ },
+ },
+ { }
+};
+
void intel_crt_init(struct drm_device *dev)
{
struct drm_connector *connector;
@@ -551,6 +570,10 @@ void intel_crt_init(struct drm_device *dev)
struct intel_connector *intel_connector;
struct drm_i915_private *dev_priv = dev->dev_private;
+ /* Skip machines without VGA that falsely report hotplug events */
+ if (dmi_check_system(intel_no_crt))
+ return;
+
crt = kzalloc(sizeof(struct intel_crt), GFP_KERNEL);
if (!crt)
return;
--
1.7.5.3.367.ga9930
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: add a CS ioctl flag not to rewrite tiling flags in the CS
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 there are two contexts sharing the same mipmapped tiled texture.
One context wants to render into the first mipmap and the other one
wants to render into the last mipmap. As you probably know, the hardware
has a MACRO_SWITCH feature, which turns off macro tiling for small mipmaps,
but that only applies to samplers.
(at least on r300-r500, though later hardware likely behaves the same)
So we want to just re-set the tiling flags before rendering (writing
packets), right? ... No. The contexts run in parallel, so they may
set the tiling flags simultaneously and then fire their command streams
also simultaneously. The last one setting the flags wins, the other one
loses.
Another problem is when one context wants to render into the first and
the last mipmap in one CS. Impossible. It must flush before changing
tiling flags and do the rendering into the smaller mipmaps in another CS.
Yet another problem is that writing copy_blit in userspace would be a mess
involving re-setting tiling flags to please the kernel, and causing races
with other contexts at the same time.
The only way out of this is to send tiling flags with each CS, ideally
with each relocation. But we already do that through the registers.
So let's just use what we have in the registers.
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/evergreen_cs.c | 92 +---
drivers/gpu/drm/radeon/r300.c | 94 ++---
drivers/gpu/drm/radeon/r600_cs.c | 26 ++
drivers/gpu/drm/radeon/radeon.h |3 +-
drivers/gpu/drm/radeon/radeon_cs.c| 11 -
drivers/gpu/drm/radeon/radeon_drv.c |3 +-
include/drm/radeon_drm.h |4 ++
7 files changed, 135 insertions(+), 98 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index a134790..86b060c 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -508,21 +508,23 @@ static inline int evergreen_cs_check_reg(struct
radeon_cs_parser *p, u32 reg, u3
}
break;
case DB_Z_INFO:
- r = evergreen_cs_packet_next_reloc(p, &reloc);
- if (r) {
- dev_warn(p->dev, "bad SET_CONTEXT_REG "
- "0x%04X\n", reg);
- return -EINVAL;
- }
track->db_z_info = radeon_get_ib_value(p, idx);
- ib[idx] &= ~Z_ARRAY_MODE(0xf);
- track->db_z_info &= ~Z_ARRAY_MODE(0xf);
- if (reloc->lobj.tiling_flags & RADEON_TILING_MACRO) {
- ib[idx] |= Z_ARRAY_MODE(ARRAY_2D_TILED_THIN1);
- track->db_z_info |= Z_ARRAY_MODE(ARRAY_2D_TILED_THIN1);
- } else {
- ib[idx] |= Z_ARRAY_MODE(ARRAY_1D_TILED_THIN1);
- track->db_z_info |= Z_ARRAY_MODE(ARRAY_1D_TILED_THIN1);
+ if (!p->keep_tiling_flags) {
+ r = evergreen_cs_packet_next_reloc(p, &reloc);
+ if (r) {
+ dev_warn(p->dev, "bad SET_CONTEXT_REG "
+ "0x%04X\n", reg);
+ return -EINVAL;
+ }
+ ib[idx] &= ~Z_ARRAY_MODE(0xf);
+ track->db_z_info &= ~Z_ARRAY_MODE(0xf);
+ if (reloc->lobj.tiling_flags & RADEON_TILING_MACRO) {
+ ib[idx] |= Z_ARRAY_MODE(ARRAY_2D_TILED_THIN1);
+ track->db_z_info |=
Z_ARRAY_MODE(ARRAY_2D_TILED_THIN1);
+ } else {
+ ib[idx] |= Z_ARRAY_MODE(ARRAY_1D_TILED_THIN1);
+ track->db_z_info |=
Z_ARRAY_MODE(ARRAY_1D_TILED_THIN1);
+ }
}
break;
case DB_STENCIL_INFO:
@@ -635,40 +637,44 @@ static inline int evergreen_cs_check_reg(struct
radeon_cs_parser *p, u32 reg, u3
case CB_COLOR5_INFO:
case CB_COLOR6_INFO:
case CB_COLOR7_INFO:
- r = evergreen_cs_packet_next_reloc(p, &reloc);
- if (r) {
- dev_warn(p->dev, "bad SET_CONTEXT_REG "
- "0x%04X\n", reg);
- return -EINVAL;
- }
tmp = (reg - CB_COLOR0_INFO) / 0x3c;
track->cb_color_info[tmp] = radeon_get_ib_value(p, idx);
- if (reloc->lobj.tiling_flags & RADEON_TILING_MACRO) {
- ib[idx] |= CB_ARRAY_M
[Bug 42117] R200 driver performance, UMS, all mesa versions from 7.6
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 there, could be from several functions. But these ums pieces are going to get away very soon so chances someone going to fix it are slim. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 42175] RV730: Display errors in glxgears & WebGL
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: --- You are the assignee for the bug.
nouveau page_flip function implement not wait vblank, which cause screen garbage
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 the vbltest program, it prints "60HZ" which indicated the
implementation of drmWaitVBlank() and drm_vblank_wait() is correct.
But when I run modetest with option " -v -s 12:1280x1024" , it prints high
fresh rate up to "150 HZ" . I examing the code , and found that no waiting
vblank operation is processed in nouveau_crtc_page_flip() function. The screen
produced lots of garbage and blink very much.
int
nouveau_crtc_page_flip(struct drm_crtc *crtc, struct drm_framebuffer *fb,
struct drm_pending_vblank_event *event)
{
..
}
I study the i915 intel_crtc_page_flip implementation.
static int intel_crtc_page_flip(stru ct drm_crtc *crtc,
struct drm_framebuffer *fb,
struct drm_pending_vblank_event *event)
{
..
ret = drm_vblank_get(dev, intel_crtc->pipe);
if (ret)
goto cleanup_objs;
work->pending_flip_obj = obj;
work->enable_stall_check = true;
/* Block clients from rendering to the new back buffer until
* the flip occurs and the object is no longer visible.
*/
atomic_add(1 << intel_crtc->plane, &work->old_fb_obj->pending_flip);
ret = dev_priv->display.queue_flip(dev, crtc, fb, obj);
&nb sp; if (ret)
goto cleanup_pending;
..
}
after vblank irq acquired, the interrupt isr will wakup the runqueue.
6159 static void do_intel_finish_page_flip(struct drm_device *dev,
6160 struct drm_crtc *crtc)
6161 {
..
6211 list_add_tail(&e->base.link,
6212 &e->base.file_priv->event_list);
6213 wake_up_interruptible(&e->base.file_priv->event_wait);
6214 }
6215
6216 drm_vblank_put(dev, intel_crtc->pipe);
6217
Is there anyone use the same driver 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>
nouveau page_flip function implement not wait vblank, which cause screen garbage
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 the vbltest program, it prints? "60HZ"? which indicated the
> implementation of drmWaitVBlank() and drm_vblank_wait()? is correct.
> ? But when I run modetest with option " -v -s 12:1280x1024" , it prints high
> fresh rate up to "150 HZ" .? I examing the code , and found that no waiting
> vblank operation is processed in nouveau_crtc_ page_flip() function. The
> screen? produced lots of garbage and blink very much.
> ?int
> nouveau_crtc_page_flip(struct drm_crtc *crtc, struct drm_framebuffer *fb,
> ?? struct drm_pending_vblank_event *event)
> {
> ..
> }
> I study the i915 intel_crtc_page_flip implementation.
> static int intel_crtc_page_flip(stru ct drm_crtc *crtc,
> ??? struct drm_framebuffer *fb,
> ??? struct drm_pending_vblank_event *event)
> {
> ..
>
> ??? ret = drm_vblank_get(dev, intel_crtc->pipe);
> ??? if (ret)
> ??? goto cleanup_objs;
>
> ??? work->pending_flip_obj = obj;
>
> ??? work->enable_stall_check = true;
>
> ??? /* Block clients from rendering to the new back buffer until
> * the flip occurs and the object is no longer visible.
> */
> ??? atomic_add(1 << intel_crtc->plane, &work->old_fb_obj->pending_flip);
>
> ??? ret = dev_priv->display.queue_flip(dev, crtc, fb, obj);
> ?&am p;nb sp;? if (ret)
> ??? goto cleanup_pending;
> ..
> }
>
> after vblank irq acquired, the interrupt isr will wakup the runqueue.
> 6159 static void do_intel_finish_page_flip(struct drm_device *dev,
> 6160?? struct drm_crtc *crtc)
> 6161 {
> ..
> 6211 list_add_tail(&e->base.link,
> 6212?? &e->base.file_priv->event_list);
> 6213 wake_up_interruptible(&e->base.file_priv->event_wait);
> 6214 }
> 6215
> 6216 drm_vblank_put(dev, intel_crtc->pipe);
> 6217
>
>
> Is there anyone use the same? driver and foun d this issues can tell me "is
> it a bug"?
>
> Thanks!
>
>
>
>
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
It seems to be, the actual page flipping is done by software method
(see nv04_graph_mthd_page_flip). There is one thing i'm unsure about
and that is that we wait for the rendering to be done to the current
frontbuffer and not the current backbuffer (this is only done if the
page flip channel is different than the rendering channel). Maybe
someone else can comment on that.
--
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
nouveau page_flip function implement not wait vblank, which cause screen garbage
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 the frontbuffer
context when it is rendering, am I right?
At 2011-10-25 13:45:29,"Maarten Maathuis" wrote:
>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 the vbltest program, it prints? "60HZ"? which indicated the
>> implementation of drmWaitVBlank() and drm_vblank_wait()? is correct.
>> ? But when I run modetest with option " -v -s 12:1280x1024" , it prints high
>> fresh rate up to "150 HZ" .? I examing the code , and found that no waiting
>> vblank operation is processed in nouveau_crtc_ page_flip() function. The
>> screen? produced lots of garbage and blink very much.
>> ?int
>> nouveau_crtc_page_flip(struct drm_crtc *crtc, struct drm_framebuffer *fb,
>> ?? struct drm_pending_vblank_event *event)
>> {
>> ..
>> }
>> I study the i915 intel_crtc_page_flip implementation.
>> static int intel_crtc_page_flip(stru ct drm_crtc *crtc,
>> ??? struct drm_framebuffer *fb,
>> ??? struct drm_pending_vblank_event *event)
>> {
>> ..
>>
>> ??? ret = drm_vblank_get(dev, intel_crtc->pipe);
>> ??? if (ret)
>> ??? goto cleanup_objs;
>>
>> ??? work->pending_flip_obj = obj;
>>
>> ??? work->enable_stall_check = true;
>>
>> ??? /* Block clients from rendering to the new back buffer until
>> * the flip occurs and the object is no longer visible.
>> */
>> ??? atomic_add(1 << intel_crtc->plane, &work->old_fb_obj->pending_flip);
>>
>> ??? ret = dev_priv->display.queue_flip(dev, crtc, fb, obj);
>> ?&am p;nb sp;? if (ret)
>> ??? goto cleanup_pending;
>> ..
>> }
>>
>> after vblank irq acquired, the interrupt isr will wakup the runqueue.
>> 6159 static void do_intel_finish_page_flip(struct drm_device *dev,
>> 6160?? struct drm_crtc *crtc)
>> 6161 {
>> ..
>> 6211 list_add_tail(&e->base.link,
>> 6212?? &e->base.file_priv->event_list);
>> 6213 wake_up_interruptible(&e->base.file_priv->event_wait);
>> 6214 }
>> 6215
>> 6216 drm_vblank_put(dev, intel_crtc->pipe);
>> 6217
>>
>>
>> Is there anyone use the same? driver and foun d this issues can tell me "is
>> it a bug"?
>>
>> Thanks!
>>
>>
>>
>>
>>
>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
>
>It seems to be, the actual page flipping is done by software method
>(see nv04_graph_mthd_page_flip). There is one thing i'm unsure about
>and that is that we wait for the rendering to be done to the current
>frontbuffer and not the current backbuffer (this is only done if the
>page flip channel is different than the rendering channel). Maybe
>someone else can comment on that.
>
>--
>Far away from the primal instinct, the song seems to fade away, the
>river get wider between your thoughts and the things we do and say.
DRM planes and new fb creation ioctl
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 well, so I'm just going to push them out. (Note IVB support is still missing a few bits for scaling and such; I'll fix those up when I get back home and can test on IVB again.) One change you may notice from the last set is that I've removed the 'zpos' parameter. Plane blending and z ordering is very chipset specific (it even varies between Intel chipsets), so exposing it through a device specific ioctl is probably a better plan. By default, planes should just overlay the primary plane; a device specific ioctl (none available yet, but I have some planned for i915) can provide more flexibility. To recap previous posts, this patchset provides a few new interfaces: - addfb2 - a new FB creation ioctl that lets you specify a surface format, as defined by a fourcc code from the video4linux headers (libdrm will wrap these in DRM_ macros for portability) - planes - ioctls for fetching plane info and attaching an fb to a plane; note there's no separate flip ioctl for planes, just use setplane to update the fb The testdisplay.c program in intel-gpu-tools has support for testing these interfaces, and I'll be fixing up and pushing the xf86-video-intel support soon as well, so you can use either as a reference for how the new interfaces work. Thanks, Jesse
[PATCH 01/11] drm: add plane support
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 +
include/drm/drm.h |3 +
include/drm/drm_crtc.h | 71 +-
include/drm/drm_mode.h | 33 ++
5 files changed, 343 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fe738f0..0e129b1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -535,6 +535,48 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
}
EXPORT_SYMBOL(drm_encoder_cleanup);
+void drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
+ unsigned long possible_crtcs,
+ const struct drm_plane_funcs *funcs,
+ uint32_t *formats, uint32_t format_count)
+{
+ mutex_lock(&dev->mode_config.mutex);
+
+ plane->dev = dev;
+ drm_mode_object_get(dev, &plane->base, DRM_MODE_OBJECT_PLANE);
+ plane->funcs = funcs;
+ plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
+ GFP_KERNEL);
+ if (!plane->format_types) {
+ DRM_DEBUG_KMS("out of memory when allocating plane\n");
+ drm_mode_object_put(dev, &plane->base);
+ return;
+ }
+
+ memcpy(plane->format_types, formats, format_count);
+ plane->format_count = format_count;
+ plane->possible_crtcs = possible_crtcs;
+
+ list_add_tail(&plane->head, &dev->mode_config.plane_list);
+ dev->mode_config.num_plane++;
+
+ mutex_unlock(&dev->mode_config.mutex);
+}
+EXPORT_SYMBOL(drm_plane_init);
+
+void drm_plane_cleanup(struct drm_plane *plane)
+{
+ struct drm_device *dev = plane->dev;
+
+ mutex_lock(&dev->mode_config.mutex);
+ kfree(plane->format_types);
+ drm_mode_object_put(dev, &plane->base);
+ list_del(&plane->head);
+ dev->mode_config.num_plane--;
+ mutex_unlock(&dev->mode_config.mutex);
+}
+EXPORT_SYMBOL(drm_plane_cleanup);
+
/**
* drm_mode_create - create a new display mode
* @dev: DRM device
@@ -866,6 +908,7 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(&dev->mode_config.encoder_list);
INIT_LIST_HEAD(&dev->mode_config.property_list);
INIT_LIST_HEAD(&dev->mode_config.property_blob_list);
+ INIT_LIST_HEAD(&dev->mode_config.plane_list);
idr_init(&dev->mode_config.crtc_idr);
mutex_lock(&dev->mode_config.mutex);
@@ -1466,6 +1509,193 @@ out:
}
/**
+ * drm_mode_getplane_res - get plane info
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Return an plane count and set of IDs.
+ */
+int drm_mode_getplane_res(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_get_plane_res *plane_resp = data;
+ struct drm_mode_config *config;
+ struct drm_plane *plane;
+ uint32_t __user *plane_ptr;
+ int copied = 0, ret = 0;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ mutex_lock(&dev->mode_config.mutex);
+ config = &dev->mode_config;
+
+ /*
+* This ioctl is called twice, once to determine how much space is
+* needed, and the 2nd time to fill it.
+*/
+ if (config->num_plane &&
+ (plane_resp->count_planes >= config->num_plane)) {
+ plane_ptr = (uint32_t *)(unsigned long)plane_resp->plane_id_ptr;
+
+ list_for_each_entry(plane, &config->plane_list, head) {
+ if (put_user(plane->base.id, plane_ptr + copied)) {
+ ret = -EFAULT;
+ goto out;
+ }
+ copied++;
+ }
+ }
+ plane_resp->count_planes = config->num_plane;
+
+out:
+ mutex_unlock(&dev->mode_config.mutex);
+ return ret;
+}
+
+/**
+ * drm_mode_getplane - get plane info
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Return plane info, including formats supported, gamma size, any
+ * current fb, etc.
+ */
+int drm_mode_getplane(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_get_plane *plane_resp = data;
+ struct drm_mode_object *obj;
+ struct drm_plane *plane;
+ uint32_t __user *format_ptr;
+ int ret = 0;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ mutex_lock(&dev->mode_config.mutex);
+ obj = drm_mode_object_find(dev, plane_resp->plane_id,
+ DRM_MODE_OBJECT_PLANE);
+ if (!obj) {
+ ret =
[PATCH 02/11] drm: add an fb creation ioctl that takes a pixel format
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| 71 -
drivers/gpu/drm/drm_crtc_helper.c |3 +-
drivers/gpu/drm/drm_drv.c |1 +
drivers/gpu/drm/i915/intel_display.c |9 ++--
drivers/gpu/drm/i915/intel_drv.h |2 +-
drivers/gpu/drm/i915/intel_fb.c |3 +-
drivers/gpu/drm/nouveau/nouveau_display.c |4 +-
drivers/gpu/drm/radeon/radeon_display.c |4 +-
drivers/gpu/drm/radeon/radeon_fb.c|5 +-
drivers/gpu/drm/radeon/radeon_mode.h |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |2 +-
drivers/staging/gma500/framebuffer.c |2 +-
include/drm/drm.h |1 +
include/drm/drm_crtc.h|6 ++-
include/drm/drm_crtc_helper.h |2 +-
include/drm/drm_mode.h| 14 ++
16 files changed, 112 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 0e129b1..a30b9d4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1909,7 +1909,76 @@ out:
int drm_mode_addfb(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
- struct drm_mode_fb_cmd *r = data;
+ struct drm_mode_fb_cmd *or = data;
+ struct drm_mode_fb_cmd2 r;
+ struct drm_mode_config *config = &dev->mode_config;
+ struct drm_framebuffer *fb;
+ int ret = 0;
+
+ /* Use new struct with format internally */
+ r.fb_id = or->fb_id;
+ r.width = or->width;
+ r.height = or->height;
+ r.pitch = or->pitch;
+ r.bpp = or->bpp;
+ r.depth = or->depth;
+ r.pixel_format = 0;
+ r.handle = or->handle;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ if ((config->min_width > r.width) || (r.width > config->max_width)) {
+ DRM_ERROR("mode new framebuffer width not within limits\n");
+ return -EINVAL;
+ }
+ if ((config->min_height > r.height) || (r.height > config->max_height))
{
+ DRM_ERROR("mode new framebuffer height not within limits\n");
+ return -EINVAL;
+ }
+
+ mutex_lock(&dev->mode_config.mutex);
+
+ /* TODO check buffer is sufficiently large */
+ /* TODO setup destructor callback */
+
+ fb = dev->mode_config.funcs->fb_create(dev, file_priv, &r);
+ if (IS_ERR(fb)) {
+ DRM_ERROR("could not create framebuffer\n");
+ ret = PTR_ERR(fb);
+ goto out;
+ }
+
+ or->fb_id = fb->base.id;
+ list_add(&fb->filp_head, &file_priv->fbs);
+ DRM_DEBUG_KMS("[FB:%d]\n", fb->base.id);
+
+out:
+ mutex_unlock(&dev->mode_config.mutex);
+ return ret;
+}
+
+/**
+ * drm_mode_addfb2 - add an FB to the graphics configuration
+ * @inode: inode from the ioctl
+ * @filp: file * from the ioctl
+ * @cmd: cmd from ioctl
+ * @arg: arg from ioctl
+ *
+ * LOCKING:
+ * Takes mode config lock.
+ *
+ * Add a new FB to the specified CRTC, given a user request with format.
+ *
+ * Called by the user via ioctl.
+ *
+ * RETURNS:
+ * Zero on success, errno on failure.
+ */
+int drm_mode_addfb2(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+ struct drm_mode_fb_cmd2 *r = data;
struct drm_mode_config *config = &dev->mode_config;
struct drm_framebuffer *fb;
int ret = 0;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index f88a9b2..77c7293 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -806,13 +806,14 @@ void drm_helper_connector_dpms(struct drm_connector
*connector, int mode)
EXPORT_SYMBOL(drm_helper_connector_dpms);
int drm_helper_mode_fill_fb_struct(struct drm_framebuffer *fb,
- struct drm_mode_fb_cmd *mode_cmd)
+ struct drm_mode_fb_cmd2 *mode_cmd)
{
fb->width = mode_cmd->width;
fb->height = mode_cmd->height;
fb->pitch = mode_cmd->pitch;
fb->bits_per_pixel = mode_cmd->bpp;
fb->depth = mode_cmd->depth;
+ fb->pixel_format = mode_cmd->pixel_format;
return 0;
}
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 15da618..f24b9b6 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -152,6 +152,7 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb,
D
[PATCH 05/11] drm/i915: move pin & fence for plane past potential error paths
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..e583bd0 100644 --- a/drivers/gpu/drm/i915/intel_overlay2.c +++ b/drivers/gpu/drm/i915/intel_overlay2.c @@ -62,9 +62,6 @@ intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, old_obj = intel_plane->obj; mutex_lock(&dev->struct_mutex); - ret = intel_pin_and_fence_fb_obj(dev, obj, NULL); - if (ret) - goto out_unlock; dvscntr = I915_READ(reg); @@ -104,6 +101,10 @@ intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, goto out_unlock; } + ret = intel_pin_and_fence_fb_obj(dev, obj, NULL); + if (ret) + goto out_unlock; + intel_plane->obj = obj; dvscntr |= DVS_TILED; -- 1.7.4.1
[PATCH 03/11] drm/i915: rename existing overlay support to "legacy"
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 | 12 ++--
drivers/gpu/drm/i915/i915_irq.c |2 +-
drivers/gpu/drm/i915/intel_display.c |2 +-
drivers/gpu/drm/i915/intel_drv.h |4 +-
drivers/gpu/drm/i915/intel_overlay.c | 126 +-
6 files changed, 74 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8e95d66..b6d0bbc 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -825,7 +825,7 @@ static int i915_error_state(struct seq_file *m, void
*unused)
}
if (error->overlay)
- intel_overlay_print_error_state(m, error->overlay);
+ intel_legacy_overlay_print_error_state(m, error->overlay);
if (error->display)
intel_display_print_error_state(m, dev, error->display);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 06a37f4..b96c174 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -118,8 +118,8 @@ struct intel_opregion {
};
#define OPREGION_SIZE(8*1024)
-struct intel_overlay;
-struct intel_overlay_error_state;
+struct intel_legacy_overlay;
+struct intel_legacy_overlay_error_state;
struct drm_i915_master_private {
drm_local_map_t *sarea;
@@ -191,7 +191,7 @@ struct drm_i915_error_state {
u32 cache_level:2;
} *active_bo, *pinned_bo;
u32 active_bo_count, pinned_bo_count;
- struct intel_overlay_error_state *overlay;
+ struct intel_legacy_overlay_error_state *overlay;
struct intel_display_error_state *display;
};
@@ -343,7 +343,7 @@ typedef struct drm_i915_private {
struct intel_opregion opregion;
/* overlay */
- struct intel_overlay *overlay;
+ struct intel_legacy_overlay *overlay;
/* LVDS info */
int backlight_level; /* restore backlight to this value */
@@ -1309,8 +1309,8 @@ extern int intel_trans_dp_port_sel(struct drm_crtc *crtc);
/* overlay */
#ifdef CONFIG_DEBUG_FS
-extern struct intel_overlay_error_state
*intel_overlay_capture_error_state(struct drm_device *dev);
-extern void intel_overlay_print_error_state(struct seq_file *m, struct
intel_overlay_error_state *error);
+extern struct intel_legacy_overlay_error_state
*intel_legacy_overlay_capture_error_state(struct drm_device *dev);
+extern void intel_legacy_overlay_print_error_state(struct seq_file *m, struct
intel_legacy_overlay_error_state *error);
extern struct intel_display_error_state
*intel_display_capture_error_state(struct drm_device *dev);
extern void intel_display_print_error_state(struct seq_file *m,
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 9ee2729..36f2837 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -998,7 +998,7 @@ static void i915_capture_error_state(struct drm_device *dev)
do_gettimeofday(&error->time);
- error->overlay = intel_overlay_capture_error_state(dev);
+ error->overlay = intel_legacy_overlay_capture_error_state(dev);
error->display = intel_display_capture_error_state(dev);
spin_lock_irqsave(&dev_priv->error_lock, flags);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b1ae70b..e748338 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3180,7 +3180,7 @@ static void intel_crtc_dpms_overlay(struct intel_crtc
*intel_crtc, bool enable)
mutex_lock(&dev->struct_mutex);
dev_priv->mm.interruptible = false;
- (void) intel_overlay_switch_off(intel_crtc->overlay);
+ (void) intel_legacy_overlay_switch_off(intel_crtc->overlay);
dev_priv->mm.interruptible = true;
mutex_unlock(&dev->struct_mutex);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 23c5622..467fb4a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -161,7 +161,7 @@ struct intel_crtc {
bool busy; /* is scanout buffer being updated frequently? */
struct timer_list idle_timer;
bool lowfreq_avail;
- struct intel_overlay *overlay;
+ struct intel_legacy_overlay *overlay;
struct intel_unpin_work *unpin_work;
int fdi_lanes;
@@ -370,7 +370,7 @@ extern void intel_finish_page_flip_plane(struct drm_device
*dev, int plane);
extern void intel_setup_overlay(struct drm_device *dev);
extern void intel_cleanup_overlay(struct drm_device *dev);
-extern int intel_overlay_switch_off(
[PATCH 04/11] drm/i915: add SNB video sprite support
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 +
drivers/gpu/drm/i915/intel_display.c | 25 +++-
drivers/gpu/drm/i915/intel_drv.h | 14 +++
drivers/gpu/drm/i915/intel_fb.c |6 +
drivers/gpu/drm/i915/intel_overlay2.c | 203 +
6 files changed, 294 insertions(+), 7 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_overlay2.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0ae6a7c..6193471 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -28,6 +28,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \
intel_dvo.o \
intel_ringbuffer.o \
intel_overlay.o \
+ intel_overlay2.o \
intel_opregion.o \
dvo_ch7xxx.o \
dvo_ch7017.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5a09416..7b128d4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2666,6 +2666,58 @@
#define _DSPBSURF 0x7119C
#define _DSPBTILEOFF 0x711A4
+/* Sprite A control */
+#define _DVSACNTR 0x72180
+#define DVS_ENABLE (1<<31)
+#define DVS_GAMMA_ENABLE (1<<30)
+#define DVS_PIXFORMAT_MASK (3<<25)
+#define DVS_FORMAT_YUV422(0<<25)
+#define DVS_FORMAT_RGBX101010(1<<25)
+#define DVS_FORMAT_RGBX888 (2<<25)
+#define DVS_FORMAT_RGBX161616(3<<25)
+#define DVS_SOURCE_KEY (1<<22)
+#define DVS_RGB_ORDER_RGBX (1<<20)
+#define DVS_YUV_BYTE_ORDER_MASK (3<<16)
+#define DVS_YUV_ORDER_YUYV (0<<16)
+#define DVS_YUV_ORDER_UYVY (1<<16)
+#define DVS_YUV_ORDER_YVYU (2<<16)
+#define DVS_YUV_ORDER_VYUY (3<<16)
+#define DVS_DEST_KEY (1<<2)
+#define DVS_TRICKLE_FEED_DISABLE (1<<14)
+#define DVS_TILED(1<<10)
+#define _DVSASTRIDE0x72188
+#define _DVSAPOS 0x7218c
+#define _DVSASIZE 0x72190
+#define _DVSAKEYVAL0x72194
+#define _DVSAKEYMSK0x72198
+#define _DVSASURF 0x7219c
+#define _DVSAKEYMAXVAL 0x721a0
+#define _DVSATILEOFF 0x721a4
+#define _DVSASURFLIVE 0x721ac
+#define _DVSASCALE 0x72204
+#define _DVSAGAMC 0x72300
+
+#define _DVSBCNTR 0x73180
+#define _DVSBSTRIDE0x73188
+#define _DVSBPOS 0x7318c
+#define _DVSBSIZE 0x73190
+#define _DVSBKEYVAL0x73194
+#define _DVSBKEYMSK0x73198
+#define _DVSBSURF 0x7319c
+#define _DVSBKEYMAXVAL 0x731a0
+#define _DVSBTILEOFF 0x731a4
+#define _DVSBSURFLIVE 0x731ac
+#define _DVSBSCALE 0x73204
+#define _DVSBGAMC 0x73300
+
+#define DVSCNTR(pipe) _PIPE(pipe, _DVSACNTR, _DVSBCNTR)
+#define DVSSTRIDE(pipe) _PIPE(pipe, _DVSASTRIDE, _DVSBSTRIDE)
+#define DVSPOS(pipe) _PIPE(pipe, _DVSAPOS, _DVSBPOS)
+#define DVSSURF(pipe) _PIPE(pipe, _DVSASURF, _DVSBSURF)
+#define DVSSIZE(pipe) _PIPE(pipe, _DVSASIZE, _DVSBSIZE)
+#define DVSSCALE(pipe) _PIPE(pipe, _DVSASCALE, _DVSBSCALE)
+#define DVSTILEOFF(pipe) _PIPE(pipe, _DVSATILEOFF, _DVSBTILEOFF)
+
/* VBIOS regs */
#define VGACNTRL 0x71400
# define VGA_DISP_DISABLE (1 << 31)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e748338..4f599ce 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -915,8 +915,8 @@ static void assert_panel_unlocked(struct drm_i915_private
*dev_priv,
pipe_name(pipe));
}
-static void assert_pipe(struct drm_i915_private *dev_priv,
- enum pipe pipe, bool state)
+void assert_pipe(struct drm_i915_private *dev_priv,
+enum pipe pipe, bool state)
{
int reg;
u32 val;
@@ -929,8 +929,6 @@ static void assert_pipe(struct drm_i915_private *dev_priv,
"pipe %c assertion failure (expected %s, current %s)\n",
pipe_name(pipe), state_string(state), state_string(cur_state));
}
-#define assert_pipe_enabled(d, p) assert_pipe(d, p, true)
-#define assert_pipe_disabled(d, p) assert_pipe(d, p, false)
static void assert_plane_enabled(struct drm_i915_private *dev_priv,
enum plane plane)
@@ -4439,7 +4437,8 @@ static void ironlake_update_wm(struct drm_device *dev)
ILK_LP0_CURSOR_LATENCY,
&plane_wm, &cursor_wm)) {
I915_WRITE(WM0_PIPEA_ILK,
- (plane_wm << WM0_PIPE_PLANE_SHIFT) | cursor_wm);
+ (plane_wm << WM0_PIP
[PATCH 08/11] drm/i915: overlay watermark hack
---
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/i915/intel_display.c
@@ -4521,7 +4521,8 @@ static void sandybridge_update_wm(struct drm_device *dev)
&sandybridge_cursor_wm_info, latency,
&plane_wm, &cursor_wm)) {
I915_WRITE(WM0_PIPEA_ILK,
- (plane_wm << WM0_PIPE_PLANE_SHIFT) | cursor_wm);
+ (plane_wm << WM0_PIPE_PLANE_SHIFT) |
+ (plane_wm << WM0_PIPE_SPRITE_SHIFT) | cursor_wm);
DRM_DEBUG_KMS("FIFO watermarks For pipe A -"
" plane %d, " "cursor: %d\n",
plane_wm, cursor_wm);
@@ -4533,7 +4534,8 @@ static void sandybridge_update_wm(struct drm_device *dev)
&sandybridge_cursor_wm_info, latency,
&plane_wm, &cursor_wm)) {
I915_WRITE(WM0_PIPEB_ILK,
- (plane_wm << WM0_PIPE_PLANE_SHIFT) | cursor_wm);
+ (plane_wm << WM0_PIPE_PLANE_SHIFT) |
+ (plane_wm << WM0_PIPE_SPRITE_SHIFT) | cursor_wm);
DRM_DEBUG_KMS("FIFO watermarks For pipe B -"
" plane %d, cursor: %d\n",
plane_wm, cursor_wm);
@@ -4587,11 +4589,6 @@ static void sandybridge_update_wm(struct drm_device *dev)
(plane_wm << WM1_LP_SR_SHIFT) |
cursor_wm);
-#if 0
- I915_WRITE(WM1S_LP_ILK,
- WM1S_LP_EN |
-#endif
-
/* WM2 */
if (!ironlake_compute_srwm(dev, 2, enabled,
SNB_READ_WM2_LATENCY() * 500,
--
1.7.4.1
[PATCH 06/11] drm/i915: plane teardown fixes
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 a/drivers/gpu/drm/i915/intel_overlay2.c b/drivers/gpu/drm/i915/intel_overlay2.c index e583bd0..861e09e 100644 --- a/drivers/gpu/drm/i915/intel_overlay2.c +++ b/drivers/gpu/drm/i915/intel_overlay2.c @@ -149,12 +149,18 @@ intel_disable_plane(struct drm_plane *plane) mutex_lock(&dev->struct_mutex); + if (!intel_plane->obj) + goto out_unlock; + ret = i915_gem_object_finish_gpu(intel_plane->obj); if (ret) goto out_unlock; + i915_gem_object_unpin(intel_plane->obj); out_unlock: + intel_plane->obj = NULL; + I915_WRITE(DVSCNTR(pipe), I915_READ(DVSCNTR(pipe)) & ~DVS_ENABLE); I915_WRITE(DVSSURF(pipe), 0); POSTING_READ(DVSSURF(pipe)); -- 1.7.4.1
[PATCH 07/11] drm/i915: enable new overlay code on IVB too
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/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7b128d4..71496b8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2718,6 +2718,65 @@
#define DVSSCALE(pipe) _PIPE(pipe, _DVSASCALE, _DVSBSCALE)
#define DVSTILEOFF(pipe) _PIPE(pipe, _DVSATILEOFF, _DVSBTILEOFF)
+#define _SPRA_CTL 0x70280
+#define SPRITE_ENABLE(1<<31)
+#define SPRITE_GAMMA_ENABLE (1<<30)
+#define SPRITE_PIXFORMAT_MASK(7<<25)
+#define SPRITE_FORMAT_YUV422 (0<<25)
+#define SPRITE_FORMAT_RGBX101010 (1<<25)
+#define SPRITE_FORMAT_RGBX888(2<<25)
+#define SPRITE_FORMAT_RGBX161616 (3<<25)
+#define SPRITE_FORMAT_YUV444 (4<<25)
+#define SPRITE_FORMAT_XBGR101010 (5<<25)
+#define SPRITE_CSC_ENABLE(1<<24)
+#define SPRITE_SOURCE_KEY(1<<22)
+#define SPRITE_RGB_ORDER_RGBX(1<<20) /* only for 888 and
161616 */
+#define SPRITE_YUV_TO_RGB_CSC_DISABLE(1<<19)
+#define SPRITE_YUV_CSC_FORMAT_BT709 (1<<18) /* 0 is BT601 */
+#define SPRITE_YUV_BYTE_ORDER_MASK (3<<16)
+#define SPRITE_YUV_ORDER_YUYV(0<<16)
+#define SPRITE_YUV_ORDER_UYVY(1<<16)
+#define SPRITE_YUV_ORDER_YVYU(2<<16)
+#define SPRITE_YUV_ORDER_VYUY(3<<16)
+#define SPRITE_TRICKLE_FEED_DISABLE (1<<14)
+#define SPRITE_INT_GAMMA_ENABLE (1<<13)
+#define SPRITE_TILED (1<<10)
+#define SPRITE_DEST_KEY (1<<2)
+#define _SPRA_STRIDE 0x70288
+#define _SPRA_POS 0x7028c
+#define _SPRA_SIZE 0x70290
+#define _SPRA_KEYVAL 0x70294
+#define _SPRA_KEYMSK 0x70298
+#define _SPRA_SURF 0x7029c
+#define _SPRA_KEYMAX 0x702a0
+#define _SPRA_TILEOFF 0x702a4
+#define _SPRA_SCALE0x70304
+#define _SPRA_GAMC 0x70400
+
+#define _SPRB_CTL 0x70280
+#define _SPRB_STRIDE 0x70288
+#define _SPRB_POS 0x7028c
+#define _SPRB_SIZE 0x70290
+#define _SPRB_KEYVAL 0x70294
+#define _SPRB_KEYMSK 0x70298
+#define _SPRB_SURF 0x7029c
+#define _SPRB_KEYMAX 0x702a0
+#define _SPRB_TILEOFF 0x702a4
+#define _SPRB_SCALE0x70304
+#define _SPRB_GAMC 0x70400
+
+#define SPRCTL(pipe) _PIPE(pipe, _SPRA_CTL, _SPRB_CTL)
+#define SPRSTRIDE(pipe) _PIPE(pipe, _SPRA_STRIDE, _SPRB_STRIDE)
+#define SPRPOS(pipe) _PIPE(pipe, _SPRA_POS, _SPRB_POS)
+#define SPRSIZE(pipe) _PIPE(pipe, _SPRA_SIZE, _SPRB_SIZE)
+#define SPRKEYVAL(pipe) _PIPE(pipe, _SPRA_KEYVAL, _SPRB_KEYVAL)
+#define SPRKEYMSK(pipe) _PIPE(pipe, _SPRA_KEYMSK, _SPRB_KEYMSK)
+#define SPRSURF(pipe) _PIPE(pipe, _SPRA_SURF, _SPRB_SURF)
+#define SPRKEYMAX(pipe) _PIPE(pipe, _SPRA_KEYMAX, _SPRB_KEYMAX)
+#define SPRTILEOFF(pipe) _PIPE(pipe, _SPRA_TILEOFF, _SPRB_TILEOFF)
+#define SPRSCALE(pipe) _PIPE(pipe, _SPRA_SCALE, _SPRB_SCALE)
+#define SPRGAMC(pipe) _PIPE(pipe, _SPRA_GAMC, _SPRB_GAMC)
+
/* VBIOS regs */
#define VGACNTRL 0x71400
# define VGA_DISP_DISABLE (1 << 31)
diff --git a/drivers/gpu/drm/i915/intel_overlay2.c
b/drivers/gpu/drm/i915/intel_overlay2.c
index 861e09e..61b1a2f 100644
--- a/drivers/gpu/drm/i915/intel_overlay2.c
+++ b/drivers/gpu/drm/i915/intel_overlay2.c
@@ -36,7 +36,116 @@
#include "i915_drv.h"
static int
-intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
+ivb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
+ struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h)
+{
+ struct drm_device *dev = plane->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ struct intel_framebuffer *intel_fb;
+ struct drm_i915_gem_object *obj, *old_obj;
+ int pipe = intel_plane->pipe;
+ unsigned long start, offset;
+ u32 sprctl;
+ u32 reg = SPRCTL(pipe);
+ int ret = 0;
+ int x = src_x >> 16, y = src_y >> 16;
+
+ assert_pipe_enabled(dev_priv, pipe);
+
+ intel_fb = to_intel_framebuffer(fb);
+ obj = intel_fb->obj;
+
+ old_obj = intel_plane->obj;
+
+ mutex_lock(&dev->struct_mutex);
+
+ sprctl = I915_READ(reg);
+
+ /* Mask out pixel format bits in case we change it */
+ sprctl &= ~(SPRITE_DEST_KEY | SPRITE_SOURCE_KEY);
+ sprctl &=
[PATCH 09/11] drm/i915: fix overlay fb object handling
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 changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay2.c
b/drivers/gpu/drm/i915/intel_overlay2.c
index 61b1a2f..8876857 100644
--- a/drivers/gpu/drm/i915/intel_overlay2.c
+++ b/drivers/gpu/drm/i915/intel_overlay2.c
@@ -35,6 +35,18 @@
#include "i915_drm.h"
#include "i915_drv.h"
+/*
+ * Note on refcounting:
+ * When the user creates an fb for the GEM object to be used for the plane,
+ * a ref is taken on the object. However, if the application exits before
+ * disabling the plane, the DRM close handling will free all the fbs and
+ * unless we take a ref on the object, it will be destroyed before the
+ * plane disable hook is called, causing obvious trouble with our efforts
+ * to look up and unpin the object. So we take a ref after we move the
+ * object to the display plane so it won't be destroyed until our disable
+ * hook is called and we drop our private reference.
+ */
+
static int
ivb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
struct drm_framebuffer *fb, int crtc_x, int crtc_y,
@@ -106,6 +118,8 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
if (ret)
goto out_unlock;
+ drm_gem_object_reference(&obj->base);
+
intel_plane->obj = obj;
sprctl |= SPRITE_TILED;
@@ -117,9 +131,6 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
start = obj->gtt_offset;
offset = y * fb->pitch + x * (fb->bits_per_pixel / 8);
- DRM_ERROR("enabling sprite, pos %d,%d, size %dx%d\n",
- crtc_x, crtc_y, fb->width, fb->height);
-
I915_WRITE(SPRSTRIDE(pipe), fb->pitch);
I915_WRITE(SPRPOS(pipe), (crtc_y << 16) | crtc_x);
I915_WRITE(SPRTILEOFF(pipe), (y << 16) | x);
@@ -215,6 +226,8 @@ snb_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
if (ret)
goto out_unlock;
+ drm_gem_object_reference(&obj->base);
+
intel_plane->obj = obj;
dvscntr |= DVS_TILED;
@@ -260,13 +273,15 @@ ivb_disable_plane(struct drm_plane *plane)
if (!intel_plane->obj)
goto out_unlock;
-#if 0
+
ret = i915_gem_object_finish_gpu(intel_plane->obj);
if (ret)
goto out_unlock;
i915_gem_object_unpin(intel_plane->obj);
-#endif
+
+ drm_gem_object_reference(&intel_plane->obj->base);
+
out_unlock:
intel_plane->obj = NULL;
@@ -299,6 +314,8 @@ snb_disable_plane(struct drm_plane *plane)
i915_gem_object_unpin(intel_plane->obj);
+ drm_gem_object_reference(&intel_plane->obj->base);
+
out_unlock:
intel_plane->obj = NULL;
--
1.7.4.1
[PATCH 11/11] drm/i915: add sprite scaling support
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(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 71496b8..8cbda0b 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2695,6 +2695,11 @@ #define _DVSATILEOFF 0x721a4 #define _DVSASURFLIVE 0x721ac #define _DVSASCALE 0x72204 +#define DVS_SCALE_ENABLE (1<<31) +#define DVS_FILTER_MASK (3<<29) +#define DVS_FILTER_MEDIUM(0<<29) +#define DVS_FILTER_ENHANCING (1<<29) +#define DVS_FILTER_SOFTENING (2<<29) #define _DVSAGAMC 0x72300 #define _DVSBCNTR 0x73180 diff --git a/drivers/gpu/drm/i915/intel_overlay2.c b/drivers/gpu/drm/i915/intel_overlay2.c index 90c4f59..61594b6 100644 --- a/drivers/gpu/drm/i915/intel_overlay2.c +++ b/drivers/gpu/drm/i915/intel_overlay2.c @@ -169,7 +169,7 @@ snb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, struct drm_i915_gem_object *obj, *old_obj; int pipe = intel_plane->pipe; unsigned long start, offset; - u32 dvscntr; + u32 dvscntr, dvsscale = 0; u32 reg = DVSCNTR(pipe); int ret = 0; int x = src_x >> 16, y = src_y >> 16; @@ -185,6 +185,13 @@ snb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, if (crtc_x >= active_w || crtc_y >= active_h) return -EINVAL; + /* +* We can take a larger source and scale it down, but +* only so much... 16x is the max on SNB. +*/ + if (((src_w * src_h) / (crtc_w * crtc_h)) > 16) + return -EINVAL; + /* Clamp the width & height into the visible area */ if (crtc_x + crtc_w > active_w) crtc_w = active_w - crtc_x - 1; @@ -249,11 +256,14 @@ snb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, start = obj->gtt_offset; offset = y * fb->pitch + x * (fb->bits_per_pixel / 8); + if (crtc_w != src_w || crtc_h != src_h) + dvsscale = DVS_SCALE_ENABLE | (src_h << 16) | src_w; + I915_WRITE(DVSSTRIDE(pipe), fb->pitch); I915_WRITE(DVSPOS(pipe), (crtc_y << 16) | crtc_x); I915_WRITE(DVSTILEOFF(pipe), (y << 16) | x); I915_WRITE(DVSSIZE(pipe), (crtc_h << 16) | crtc_w); - I915_WRITE(DVSSCALE(pipe), 0); + I915_WRITE(DVSSCALE(pipe), dvsscale); I915_WRITE(reg, dvscntr); I915_WRITE(DVSSURF(pipe), start); POSTING_READ(DVSSURF(pipe)); -- 1.7.4.1
[PATCH 10/11] drm/i915: clamp sprite to viewable area
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 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_overlay2.c b/drivers/gpu/drm/i915/intel_overlay2.c index 8876857..90c4f59 100644 --- a/drivers/gpu/drm/i915/intel_overlay2.c +++ b/drivers/gpu/drm/i915/intel_overlay2.c @@ -173,6 +173,7 @@ snb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, u32 reg = DVSCNTR(pipe); int ret = 0; int x = src_x >> 16, y = src_y >> 16; + int active_w = crtc->mode.hdisplay, active_h = crtc->mode.vdisplay; assert_pipe_enabled(dev_priv, pipe); @@ -181,6 +182,15 @@ snb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, old_obj = intel_plane->obj; + if (crtc_x >= active_w || crtc_y >= active_h) + return -EINVAL; + + /* Clamp the width & height into the visible area */ + if (crtc_x + crtc_w > active_w) + crtc_w = active_w - crtc_x - 1; + if (crtc_y + crtc_h > active_h) + crtc_h = active_h - crtc_y - 1; + mutex_lock(&dev->struct_mutex); dvscntr = I915_READ(reg); @@ -242,7 +252,7 @@ snb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, I915_WRITE(DVSSTRIDE(pipe), fb->pitch); I915_WRITE(DVSPOS(pipe), (crtc_y << 16) | crtc_x); I915_WRITE(DVSTILEOFF(pipe), (y << 16) | x); - I915_WRITE(DVSSIZE(pipe), (fb->height << 16) | fb->width); + I915_WRITE(DVSSIZE(pipe), (crtc_h << 16) | crtc_w); I915_WRITE(DVSSCALE(pipe), 0); I915_WRITE(reg, dvscntr); I915_WRITE(DVSSURF(pipe), start); -- 1.7.4.1
[PATCH 01/11] drm: add plane support
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
> +++-
> drivers/gpu/drm/drm_drv.c |3 +
> include/drm/drm.h |3 +
> include/drm/drm_crtc.h | 71 +-
> include/drm/drm_mode.h | 33 ++
> 5 files changed, 343 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index fe738f0..0e129b1 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -535,6 +535,48 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
> }
> EXPORT_SYMBOL(drm_encoder_cleanup);
>
> +void drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
> + unsigned long possible_crtcs,
> + const struct drm_plane_funcs *funcs,
> + uint32_t *formats, uint32_t format_count)
> +{
> + mutex_lock(&dev->mode_config.mutex);
> +
> + plane->dev = dev;
> + drm_mode_object_get(dev,&plane->base, DRM_MODE_OBJECT_PLANE);
> + plane->funcs = funcs;
> + plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
> + GFP_KERNEL);
> + if (!plane->format_types) {
> + DRM_DEBUG_KMS("out of memory when allocating plane\n");
> + drm_mode_object_put(dev,&plane->base);
> + return;
> + }
> +
> + memcpy(plane->format_types, formats, format_count);
> + plane->format_count = format_count;
> + plane->possible_crtcs = possible_crtcs;
> +
> + list_add_tail(&plane->head,&dev->mode_config.plane_list);
> + dev->mode_config.num_plane++;
> +
> + mutex_unlock(&dev->mode_config.mutex);
> +}
> +EXPORT_SYMBOL(drm_plane_init);
> +
> +void drm_plane_cleanup(struct drm_plane *plane)
> +{
> + struct drm_device *dev = plane->dev;
> +
> + mutex_lock(&dev->mode_config.mutex);
> + kfree(plane->format_types);
> + drm_mode_object_put(dev,&plane->base);
> + list_del(&plane->head);
> + dev->mode_config.num_plane--;
> + mutex_unlock(&dev->mode_config.mutex);
> +}
> +EXPORT_SYMBOL(drm_plane_cleanup);
> +
> /**
>* drm_mode_create - create a new display mode
>* @dev: DRM device
> @@ -866,6 +908,7 @@ void drm_mode_config_init(struct drm_device *dev)
> INIT_LIST_HEAD(&dev->mode_config.encoder_list);
> INIT_LIST_HEAD(&dev->mode_config.property_list);
> INIT_LIST_HEAD(&dev->mode_config.property_blob_list);
> + INIT_LIST_HEAD(&dev->mode_config.plane_list);
> idr_init(&dev->mode_config.crtc_idr);
>
> mutex_lock(&dev->mode_config.mutex);
> @@ -1466,6 +1509,193 @@ out:
> }
>
> /**
> + * drm_mode_getplane_res - get plane info
> + * @dev: DRM device
> + * @data: ioctl data
> + * @file_priv: DRM file info
> + *
> + * Return an plane count and set of IDs.
> + */
> +int drm_mode_getplane_res(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> +{
> + struct drm_mode_get_plane_res *plane_resp = data;
> + struct drm_mode_config *config;
> + struct drm_plane *plane;
> + uint32_t __user *plane_ptr;
> + int copied = 0, ret = 0;
> +
> + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + return -EINVAL;
> +
> + mutex_lock(&dev->mode_config.mutex);
> + config =&dev->mode_config;
> +
> + /*
> + * This ioctl is called twice, once to determine how much space is
> + * needed, and the 2nd time to fill it.
> + */
> + if (config->num_plane&&
> + (plane_resp->count_planes>= config->num_plane)) {
> + plane_ptr = (uint32_t *)(unsigned long)plane_resp->plane_id_ptr;
> +
> + list_for_each_entry(plane,&config->plane_list, head) {
> + if (put_user(plane->base.id, plane_ptr + copied)) {
> + ret = -EFAULT;
> + goto out;
> + }
> + copied++;
> + }
> + }
> + plane_resp->count_planes = config->num_plane;
> +
> +out:
> + mutex_unlock(&dev->mode_config.mutex);
> + return ret;
> +}
> +
> +/**
> + * drm_mode_getplane - get plane info
> + * @dev: DRM device
> + * @data: ioctl data
> + * @file_priv: DRM file info
> + *
> + * Return plane info, including formats supported, gamma size, any
> + * current fb, etc.
> + */
> +int drm_mode_getplane(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> +{
> + struct drm_mode_get_plane *plane_resp = data;
> + struct drm_mode_object *obj;
> + struct drm_plane *plane;
> + uint32_t __user *format_ptr;
> + int ret = 0;
> +
> + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + return -EINVAL;
> +
> + mutex_loc
DRM planes and new fb creation ioctl
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 the remaining issues I'm aware of on SNB platforms and things > are working well, so I'm just going to push them out. (Note IVB support > is still missing a few bits for scaling and such; I'll fix those up when > I get back home and can test on IVB again.) > > One change you may notice from the last set is that I've removed the > 'zpos' parameter. Plane blending and z ordering is very chipset > specific (it even varies between Intel chipsets), so exposing it through > a device specific ioctl is probably a better plan. But i think zpos is essential parameter of plane. If plane doesn't support it, drm driver cannot know user wants to use which overlay, so i wonder what it meant DRM_IOCTL_MODE_SETPLANE zpos is absent . If use device specific ioctl, should implement device specific ioctl for DRM_IOCTL_MODE_SETPLANE? >By default, planes > should just overlay the primary plane; a device specific ioctl (none > available yet, but I have some planned for i915) can provide more > flexibility. Could you explain what is the primary plane? Is it same as the overlay handled by crtc? It confuses a bit when one overlay is handled by crtc and plane at the same time. > > To recap previous posts, this patchset provides a few new interfaces: >- addfb2 - a new FB creation ioctl that lets you specify a surface > format, as defined by a fourcc code from the video4linux headers > (libdrm will wrap these in DRM_ macros for portability) >- planes - ioctls for fetching plane info and attaching an fb to a > plane; note there's no separate flip ioctl for planes, just use > setplane to update the fb > > The testdisplay.c program in intel-gpu-tools has support for testing > these interfaces, and I'll be fixing up and pushing the > xf86-video-intel support soon as well, so you can use either as a > reference for how the new interfaces work. > > Thanks, > Jesse > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
DRM planes and new fb creation ioctl
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 like > > they're ok. I've also fixed all the remaining issues I'm aware of > > on SNB platforms and things are working well, so I'm just going to > > push them out. (Note IVB support is still missing a few bits for > > scaling and such; I'll fix those up when I get back home and can > > test on IVB again.) > > > > One change you may notice from the last set is that I've removed the > > 'zpos' parameter. Plane blending and z ordering is very chipset > > specific (it even varies between Intel chipsets), so exposing it > > through a device specific ioctl is probably a better plan. > > But i think zpos is essential parameter of plane. If plane doesn't > support it, drm driver cannot know user wants to use which overlay, > so i wonder what it meant DRM_IOCTL_MODE_SETPLANE zpos is absent . Setplane is just for attaching a new fb. The order, keying, or whatever else your plane blender can support can be set with a device specific ioctl before or after the setplane call (probably before to avoid any flashing or bad frames). > If use device specific ioctl, should implement device specific ioctl > for DRM_IOCTL_MODE_SETPLANE? You could if you needed, but I don't think it's strictly necessary. > >By default, planes > > should just overlay the primary plane; a device specific ioctl (none > > available yet, but I have some planned for i915) can provide more > > flexibility. > > Could you explain what is the primary plane? Is it same as the overlay > handled by crtc? It confuses a bit when one overlay is handled by crtc > and plane at the same time. Yeah, it is a little confusing. When I refer to the primary, I'm referring to the plane bound to the CRTC. I'm fine if someone wants to break that out, I think it would make sense. I just didn't want to write the compat code that would be required for that scheme. :) But these patches definitely don't preclude it, and I don't think these interfaces will need changes if we ever move to a pipe/plane split at the userland level. Thanks, Jesse
[PATCH 01/11] drm: add plane support
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
> > + * @crtc_x: x position of plane (relative to pipe base)
> > + * @crtc_y: y position of plane
> > + * @x: x offset into fb
> > + * @y: y offset into fb
> Above 4 members don't be used.
Oops yeah, I'll fix up the comments.
> > +
> > +struct drm_mode_get_plane {
> > + __u64 format_type_ptr;
> > + __u32 plane_id;
> > +
> > + __u32 crtc_id;
> > + __u32 fb_id;
> > +
> > + __u32 possible_crtcs;
> > + __u32 gamma_size;
> > +
> > + __u32 count_format_types;
> > +};
>
> I wonder why doesn't give to user crtc_x, crtc_y, crtc_w, crtc_h
> information?
It could, but the caller should already know was my thinking. Would
you like those bits returned?
Jesse
[Intel-gfx] DRM planes and new fb creation ioctl
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 remaining issues I'm aware of on SNB > platforms and things are working well, so I'm just going to push them > out. (Note IVB support is still missing a few bits for scaling and > such; I'll fix those up when I get back home and can test on IVB > again.) Btw, ignore 3-11, I forgot to collapse them when I collapsed the core fixes. Updated intel specific patch will be coming shortly (with a fix for the unpin vs disable ordering danvet pointed out). Jesse
[PATCH] drm/i915: add SNB video sprite support
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/Makefile |1 + drivers/gpu/drm/i915/i915_reg.h | 116 ++ drivers/gpu/drm/i915/intel_display.c | 26 ++- drivers/gpu/drm/i915/intel_drv.h | 14 ++ drivers/gpu/drm/i915/intel_fb.c |6 + drivers/gpu/drm/i915/intel_overlay2.c | 393 + 6 files changed, 547 insertions(+), 9 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_overlay2.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 0ae6a7c..6193471 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -28,6 +28,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \ intel_dvo.o \ intel_ringbuffer.o \ intel_overlay.o \ + intel_overlay2.o \ intel_opregion.o \ dvo_ch7xxx.o \ dvo_ch7017.o \ diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 5a09416..8cbda0b 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2666,6 +2666,122 @@ #define _DSPBSURF 0x7119C #define _DSPBTILEOFF 0x711A4 +/* Sprite A control */ +#define _DVSACNTR 0x72180 +#define DVS_ENABLE (1<<31) +#define DVS_GAMMA_ENABLE (1<<30) +#define DVS_PIXFORMAT_MASK (3<<25) +#define DVS_FORMAT_YUV422(0<<25) +#define DVS_FORMAT_RGBX101010(1<<25) +#define DVS_FORMAT_RGBX888 (2<<25) +#define DVS_FORMAT_RGBX161616(3<<25) +#define DVS_SOURCE_KEY (1<<22) +#define DVS_RGB_ORDER_RGBX (1<<20) +#define DVS_YUV_BYTE_ORDER_MASK (3<<16) +#define DVS_YUV_ORDER_YUYV (0<<16) +#define DVS_YUV_ORDER_UYVY (1<<16) +#define DVS_YUV_ORDER_YVYU (2<<16) +#define DVS_YUV_ORDER_VYUY (3<<16) +#define DVS_DEST_KEY (1<<2) +#define DVS_TRICKLE_FEED_DISABLE (1<<14) +#define DVS_TILED(1<<10) +#define _DVSASTRIDE0x72188 +#define _DVSAPOS 0x7218c +#define _DVSASIZE 0x72190 +#define _DVSAKEYVAL0x72194 +#define _DVSAKEYMSK0x72198 +#define _DVSASURF 0x7219c +#define _DVSAKEYMAXVAL 0x721a0 +#define _DVSATILEOFF 0x721a4 +#define _DVSASURFLIVE 0x721ac +#define _DVSASCALE 0x72204 +#define DVS_SCALE_ENABLE (1<<31) +#define DVS_FILTER_MASK (3<<29) +#define DVS_FILTER_MEDIUM(0<<29) +#define DVS_FILTER_ENHANCING (1<<29) +#define DVS_FILTER_SOFTENING (2<<29) +#define _DVSAGAMC 0x72300 + +#define _DVSBCNTR 0x73180 +#define _DVSBSTRIDE0x73188 +#define _DVSBPOS 0x7318c +#define _DVSBSIZE 0x73190 +#define _DVSBKEYVAL0x73194 +#define _DVSBKEYMSK0x73198 +#define _DVSBSURF 0x7319c +#define _DVSBKEYMAXVAL 0x731a0 +#define _DVSBTILEOFF 0x731a4 +#define _DVSBSURFLIVE 0x731ac +#define _DVSBSCALE 0x73204 +#define _DVSBGAMC 0x73300 + +#define DVSCNTR(pipe) _PIPE(pipe, _DVSACNTR, _DVSBCNTR) +#define DVSSTRIDE(pipe) _PIPE(pipe, _DVSASTRIDE, _DVSBSTRIDE) +#define DVSPOS(pipe) _PIPE(pipe, _DVSAPOS, _DVSBPOS) +#define DVSSURF(pipe) _PIPE(pipe, _DVSASURF, _DVSBSURF) +#define DVSSIZE(pipe) _PIPE(pipe, _DVSASIZE, _DVSBSIZE) +#define DVSSCALE(pipe) _PIPE(pipe, _DVSASCALE, _DVSBSCALE) +#define DVSTILEOFF(pipe) _PIPE(pipe, _DVSATILEOFF, _DVSBTILEOFF) + +#define _SPRA_CTL 0x70280 +#define SPRITE_ENABLE(1<<31) +#define SPRITE_GAMMA_ENABLE (1<<30) +#define SPRITE_PIXFORMAT_MASK(7<<25) +#define SPRITE_FORMAT_YUV422 (0<<25) +#define SPRITE_FORMAT_RGBX101010 (1<<25) +#define SPRITE_FORMAT_RGBX888(2<<25) +#define SPRITE_FORMAT_RGBX161616 (3<<25) +#define SPRITE_FORMAT_YUV444 (4<<25) +#define SPRITE_FORMAT_XBGR101010 (5<<25) +#define SPRITE_CSC_ENABLE(1<<24) +#define SPRITE_SOURCE_KEY(1<<22) +#define SPRITE_RGB_ORDER_RGBX(1<<20) /* only for 888 and 161616 */ +#define SPRITE_YUV_TO_RGB_CSC_DISABLE(1<<19) +#define SPRITE_YUV_CSC_FORMAT_BT709 (1<<18) /* 0 is BT601 */ +#define SPRITE_YUV_BYTE_ORDER_MASK (3<<16) +#define SPRITE_YUV_ORDER_YUYV(0<<16) +#define SPRITE_YUV_ORDER_UYVY(1<<16) +#define SPRITE_YUV_ORDER_YVYU(2<<16) +#define SPRITE_YUV_ORDER_VYUY(3<<16) +#define SPRITE_TRICKLE_FEED_DISABLE (1<<14) +#define SPRITE_INT_GAMMA_ENABLE (1<<13) +#define SPRITE_TILED (1<<10) +#define SPRITE_DEST_KEY
[PATCH] drm/i915: add SNB video sprite support
[PATCH 01/11] drm: add plane support
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 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 the corresponding pointer needs to hold a ref onto the underlying backing storage (like e.g. for pageflip on the to-be-flipped-out fb as long as it might still be scanned out). We need proper refcounting for these ... But for now this patch is missing the plane cleanup in drm_framebuffer_cleanup. Otherwise I think going with just the src and dst rect for set_plane is about the only sensible thing given the crazy hw out there. But I lack the knowledge about that kind of hw (and video stuff in general), so I'll refrain from slapping my r-b on these two. Cheers, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
nouveau page_flip function implement not wait vblank, which cause screen garbage
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 to support non-vsync'ed vblank as well, and for vsync'ed blits we had to think about a different mechanism for vblank synchronization anyway, so I figured it didn't make that much sense to force vblank synchronization directly from the pageflip ioctl. >> >> 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 the vbltest program, it prints? "60HZ"? which indicated the >> implementation of drmWaitVBlank() and drm_vblank_wait()? is correct. >> ? But when I run modetest with option " -v -s 12:1280x1024" , it prints high >> fresh rate up to "150 HZ" .? I examing the code , and found that no waiting >> vblank operation is processed in nouveau_crtc_ page_flip() function. The >> screen? produced lots of garbage and blink very much. That's fine if by "garbage" you just mean it's tearing like crazy. >>[...] > > It seems to be, the actual page flipping is done by software method > (see nv04_graph_mthd_page_flip). There is one thing i'm unsure about > and that is that we wait for the rendering to be done to the current > frontbuffer and not the current backbuffer (this is only done if the > page flip channel is different than the rendering channel). Maybe > someone else can comment on that. There's no need to wait for the backbuffer rendering to end because the pageflip is always pushed through the last channel that has queued rendering to it, so, the "waiting" is actually done by the GPU. The waiting to the current frontbuffer (which in most cases is going to be a cross-channel barrier instead of actual CPU waiting) 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>
nouveau page_flip function implement not wait vblank, which cause screen garbage
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 to > support non-vsync'ed vblank as well, and for vsync'ed blits we had to > think about a different mechanism for vblank synchronization anyway, so > I figured it didn't make that much sense to force vblank synchronization > directly from the pageflip ioctl. +1 I deliberately didn't flip 1 bit in the NV50/NVC0 page flipping code for this as well. The interface IMO is flawed. Though, that said, we really should look at doing something properly for this, a lot of people do want tear-free goodness. Ben. > > >> > >> 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 the vbltest program, it prints "60HZ" which indicated the > >> implementation of drmWaitVBlank() and drm_vblank_wait() is correct. > >> But when I run modetest with option " -v -s 12:1280x1024" , it prints > >> high > >> fresh rate up to "150 HZ" . I examing the code , and found that no waiting > >> vblank operation is processed in nouveau_crtc_ page_flip() function. The > >> screen produced lots of garbage and blink very much. > > That's fine if by "garbage" you just mean it's tearing like crazy. > > >>[...] > > > > It seems to be, the actual page flipping is done by software method > > (see nv04_graph_mthd_page_flip). There is one thing i'm unsure about > > and that is that we wait for the rendering to be done to the current > > frontbuffer and not the current backbuffer (this is only done if the > > page flip channel is different than the rendering channel). Maybe > > someone else can comment on that. > > There's no need to wait for the backbuffer rendering to end because the > pageflip is always pushed through the last channel that has queued > rendering to it, so, the "waiting" is actually done by the GPU. The > waiting to the current frontbuffer (which in most cases is going to be a > cross-channel barrier instead of actual CPU waiting) 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. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] DRM: omapdrm DRM/KMS driver for TI OMAP platforms
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
> HDMI, DVI, and various types of LCD panels. And it implements GEM
> support for buffer allocation (for KMS as well as offscreen buffers
> used by the xf86-video-omap userspace xorg driver).
>
> The driver maps CRTCs to overlays, encoders to overlay-managers, and
> connectors to dssdev's. Note that this arrangement might change slightly
> when support for drm_plane overlays is added.
>
> For GEM support, non-scanout buffers are using the shmem backed pages
> provided by GEM core (In drm_gem_object_init()). In the case of scanout
> buffers, which need to be physically contiguous, those are allocated
> with CMA and use drm_gem_private_object_init().
>
> See userspace xorg driver:
> git://github.com/robclark/xf86-video-omap.git
>
> Refer to this link for CMA (Continuous Memory Allocator):
> http://lkml.org/lkml/2011/8/19/302
>
> Links to previous versions of the patch:
> v1: http://lwn.net/Articles/458137/
> v2: http://lwn.net/Articles/459397/
>
> History:
>
> v4: bit of rework of encoder/connector _dpms() code, modeset_init()
> rework to not use nested functions, update TODO.txt
> v3: minor cleanups, improved error handling for dev_load(), some minor
> API changes that will be needed later for tiled buffer support
> v2: replace omap_vram with CMA for scanout buffer allocation, remove
> unneeded functions, use dma_addr_t for physical addresses, error
> handling cleanup, refactor attach/detach pages into common drm
> functions, split non-userspace-facing API into omap_priv.h, remove
> plugin API
>
> v1: original
>
> Signed-off-by: Rob Clark
I think this has already seen way too many iterations for a simple
-staging merge ... ;-)
Reviewed-by: Daniel Vetter (for -staging)
> + /* if we couldn't find another connected connector, lets start
> + * looking at the unconnected connectors:
> + *
> + * note: it might not be immediately apparent, but thanks to
> + * the !mgr check in both this loop and the one above, the only
> + * way to enter this loop is with *j == priv->num_connectors,
> + * so idx can never go negative.
> + */
> + while (*j < 2 * priv->num_connectors && !mgr) {
This loop here is still pretty ... strange. Might want to clean that up as
the first patch when merged. Why no just a simple?
for (j = 0; j < num_connectors; j++)
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
[PATCH] Give up on edid retries when i2c bus is not responding
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 that bus is not responding, it is mostly pointless
to keep re-trying those attempts over and over again until we reach final
number of retries.
This change should fix
https://bugs.freedesktop.org/show_bug.cgi?id=41059 and improve overall
edid detection timing by 10-30% in most cases, and by a much larger margin
in case of phantom outputs.
v2: added a module parameter to control this behavior. The idea came from
discussion with Jean Delvare.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/drm_edid.c |5 +
drivers/gpu/drm/drm_stub.c |5 +
include/drm/drmP.h |2 ++
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7425e5c..c7426ab 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -265,6 +265,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
unsigned char *buf,
}
};
ret = i2c_transfer(adapter, msgs, 2);
+ if (drm_ignore_unresponsive_edid && ret == -ENXIO) {
+ DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
+ adapter->name);
+ break;
+ }
} while (ret != 2 && --retries);
return ret == 2 ? 0 : -1;
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 6d7b083..b1013fe 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -46,16 +46,21 @@ EXPORT_SYMBOL(drm_vblank_offdelay);
unsigned int drm_timestamp_precision = 20; /* Default to 20 usecs. */
EXPORT_SYMBOL(drm_timestamp_precision);
+unsigned int drm_ignore_unresponsive_edid = 1; /* Ignore non-responding edid
by default */
+EXPORT_SYMBOL(drm_ignore_unresponsive_edid);
+
MODULE_AUTHOR(CORE_AUTHOR);
MODULE_DESCRIPTION(CORE_DESC);
MODULE_LICENSE("GPL and additional rights");
MODULE_PARM_DESC(debug, "Enable debug output");
MODULE_PARM_DESC(vblankoffdelay, "Delay until vblank irq auto-disable
[msecs]");
MODULE_PARM_DESC(timestamp_precision_usec, "Max. error on timestamps [usecs]");
+MODULE_PARM_DESC(ignore_unresponsive_edid, "Automatically ignore outputs which
do not provide EDID after 3 attempts");
module_param_named(debug, drm_debug, int, 0600);
module_param_named(vblankoffdelay, drm_vblank_offdelay, int, 0600);
module_param_named(timestamp_precision_usec, drm_timestamp_precision, int,
0600);
+module_param_named(ignore_unresponsive_edid, drm_ignore_unresponsive_edid,
int, 0600);
struct idr drm_minors_idr;
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 9b7c2bb..d7b0286 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1465,6 +1465,8 @@ extern unsigned int drm_debug;
extern unsigned int drm_vblank_offdelay;
extern unsigned int drm_timestamp_precision;
+extern unsigned int drm_ignore_unresponsive_edid;
+
extern struct class *drm_class;
extern struct proc_dir_entry *drm_proc_root;
extern struct dentry *drm_debugfs_root;
--
1.7.7
[PATCH 01/11] drm: add plane support
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. > > > > Signed-off-by: Jesse Barnes > > 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 the > corresponding pointer needs to hold a ref onto the underlying backing > storage (like e.g. for pageflip on the to-be-flipped-out fb as long > as it might still be scanned out). > > We need proper refcounting for these ... But for now this patch is > missing the plane cleanup in drm_framebuffer_cleanup. Ah yeah that's a better place for the disable plane call I currently have in the intel specific code... I'll fix up and test. > Otherwise I think going with just the src and dst rect for set_plane > is about the only sensible thing given the crazy hw out there. But I > lack the knowledge about that kind of hw (and video stuff in > general), so I'll refrain from slapping my r-b on these two. Yeah, I think the drivers just need to be able to calculate the scaling level from the params and program them into whatever regs they happen to have (on Intel fortunately the scaling is figured out by hw when we program in the source & dest values, subject to some restrictions). Thanks, Jesse
[PATCH 01/11] drm: add plane support
> 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 the corresponding > pointer needs to hold a ref onto the underlying backing storage (like > e.g. for pageflip on the to-be-flipped-out fb as long as it might still > be scanned out). > > We need proper refcounting for these ... But for now this patch is missing > the plane cleanup in drm_framebuffer_cleanup. I'd rather we fixed the framebuffer kref stuff as part of doing this rather than have a poorer API because of something we have to fix anyway. It shouldn't be *that* hard to fix, at least for this kind of use case. Resize locking, fb moving etc are ugly issues, refcount shouldn't be, and the tty layer also refcounts so we can only have the fb objects themselves to worry about as we can defer fb destruction to tty close or drm last unref even for those with consoles on them. Alan
[PATCH 01/11] drm: add plane support
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 that atm > > - drivers that hold onto fbs after the kms core drops the > > corresponding pointer needs to hold a ref onto the underlying > > backing storage (like e.g. for pageflip on the to-be-flipped-out fb > > as long as it might still be scanned out). > > > > We need proper refcounting for these ... But for now this patch is > > missing the plane cleanup in drm_framebuffer_cleanup. > > I'd rather we fixed the framebuffer kref stuff as part of doing this > rather than have a poorer API because of something we have to fix > anyway. > > It shouldn't be *that* hard to fix, at least for this kind of use > case. Resize locking, fb moving etc are ugly issues, refcount > shouldn't be, and the tty layer also refcounts so we can only have > the fb objects themselves to worry about as we can defer fb > destruction to tty close or drm last unref even for those with > consoles on them. Oh it doesn't affect the userspace API so I don't think it's urgent. But I agree, it would be nice to clean up fb management a bit... Any volunteers? :) Thanks, Jesse
[PATCH 01/11] drm: add plane support
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 that atm > > - drivers that hold onto fbs after the kms core drops the corresponding > > pointer needs to hold a ref onto the underlying backing storage (like > > e.g. for pageflip on the to-be-flipped-out fb as long as it might still > > be scanned out). > > > > We need proper refcounting for these ... But for now this patch is missing > > the plane cleanup in drm_framebuffer_cleanup. > > I'd rather we fixed the framebuffer kref stuff as part of doing this > rather than have a poorer API because of something we have to fix anyway. Imo we should do things piece by piece. Fixing up drm fb refcounting is imo a rather low-prio thing for core drm. And I've already asked Rob Clarke whether he can clean up some of the confiusion in the kms framebuffer->destroy() functions. > It shouldn't be *that* hard to fix, at least for this kind of use > case. Resize locking, fb moving etc are ugly issues, refcount shouldn't > be, and the tty layer also refcounts so we can only have the fb objects > themselves to worry about as we can defer fb destruction to tty close or I'm talking solely about kms framebuffers. I.e. completely orthogonal to any issues you're seeing wrt kms<->linux fb subsystem integration. Or I'm completely misunderstanding you here ... -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[Bug 42117] R200 driver performance, UMS, all mesa versions from 7.6
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=1, mode=1 '\001') at r200_swtcl.c:678 #1 0xb63b2dbd in r200WrapRunPipeline (ctx=0x8381c10) at r200_state.c:2449 #2 0xb648f1ee in _tnl_draw_prims (ctx=0x8381c10, arrays=0x83c5804, prim=0x83c42d8, nr_prims=1, ib=0x0, min_index=0, max_index=3) at tnl/t_draw.c:478 #3 0xb648f4f9 in _tnl_vbo_draw_prims (ctx=0x8381c10, arrays=0x83c5804, prim=0x83c42d8, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3) at tnl/t_draw.c:384 #4 0xb648709f in vbo_exec_vtx_flush (exec=0x83c41a8, unmap=1 '\001') at vbo/vbo_exec_draw.c:384 #5 0xb6484d50 in vbo_exec_FlushVertices_internal (ctx=0x8381c10, unmap=1 '\001') at vbo/vbo_exec_api.c:872 #6 0xb6484f3b in vbo_exec_FlushVertices (ctx=0x8381c10, flags=1) at vbo/vbo_exec_api.c:906 #7 0xb646995c in _mesa_BindTexture (target=3553, texName=92) at main/texobj.c:1058 #8 0x080612bb in draw_sky (pos=...) at course_render.cpp:377 #9 0x0808ca8b in Racing::loop (this=0x929dde0, timeStep=9.9982e-14) at racing.cpp:375 #10 0x0807592b in main_loop () at loop.cpp:178 #11 0x08095f75 in winsys_process_events () at winsys.cpp:304 #12 0x08076444 in main (argc=1, argv=0xbf845c24) at main.cpp:307 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 42117] R200 driver performance, UMS, all mesa versions from 7.6
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. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 01/11] drm: add plane support
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/drm/drm_crtc.c
index a30b9d4..0cc2077 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1923,7 +1923,8 @@ int drm_mode_addfb(struct drm_device *dev,
r.bpp = or->bpp;
r.depth = or->depth;
r.pixel_format = 0;
- r.handle = or->handle;
+ r.handle_count = 1;
+ r.handles = (u64)&or->handle;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cd7e04d..2c7f200 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7619,8 +7619,9 @@ intel_user_framebuffer_create(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd)
{
struct drm_i915_gem_object *obj;
+ u32 *handles = (u32 *)mode_cmd->handles;
- obj = to_intel_bo(drm_gem_object_lookup(dev, filp, mode_cmd->handle));
+ obj = to_intel_bo(drm_gem_object_lookup(dev, filp, handles[0]));
if (&obj->base == NULL)
return ERR_PTR(-ENOENT);
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 7a428a9..cb9b868 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -128,9 +128,10 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
{
struct nouveau_framebuffer *nouveau_fb;
struct drm_gem_object *gem;
+ u32 *handles = (u32 *)mode_cmd->handles;
int ret;
- gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handle);
+ gem = drm_gem_object_lookup(dev, file_priv, handles);
if (!gem)
return ERR_PTR(-ENOENT);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index ae803f8..63a6d91 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1128,11 +1128,12 @@ radeon_user_framebuffer_create(struct drm_device *dev,
{
struct drm_gem_object *obj;
struct radeon_framebuffer *radeon_fb;
+ u32 *handles = (u32 *)mode_cmd->handles;
- obj = drm_gem_object_lookup(dev, file_priv, mode_cmd->handle);
+ obj = drm_gem_object_lookup(dev, file_priv, handles[0]);
if (obj == NULL) {
dev_err(&dev->pdev->dev, "No GEM object associated to handle
0x%08X, "
- "can't create framebuffer\n", mode_cmd->handle);
+ "can't create framebuffer\n", handles[0]);
return ERR_PTR(-ENOENT);
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 2a1b802..0ad7456 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -866,7 +866,7 @@ static struct drm_framebuffer *vmw_kms_fb_create(struct
drm_device *dev,
*/
ret = vmw_user_surface_lookup_handle(dev_priv, tfile,
-mode_cmd->handle, &surface);
+mode_cmd->handles[0], &surface);
if (ret)
goto try_dmabuf;
diff --git a/drivers/staging/gma500/framebuffer.c
b/drivers/staging/gma500/framebuffer.c
index 85f47d5..ee91ffe 100644
--- a/drivers/staging/gma500/framebuffer.c
+++ b/drivers/staging/gma500/framebuffer.c
@@ -496,7 +496,7 @@ static struct drm_framebuffer *psb_user_framebuffer_create
* Find the GEM object and thus the gtt range object that is
* to back this space
*/
- obj = drm_gem_object_lookup(dev, filp, cmd->handle);
+ obj = drm_gem_object_lookup(dev, filp, cmd->handles[0]);
if (obj == NULL)
return ERR_PTR(-ENOENT);
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;
__u32 pixel_format; /* fourcc code from videodev2.h */
- /* driver specific handle */
- __u32 handle;
+ __u32 handle_count;
+ /* driver specific buffer object handle array */
+ __u64 handles;
};
#define DRM_MODE_FB_DIRTY_ANNOTATE_COPY 0x01
[Bug 42175] RV730: Display errors in glxgears & WebGL
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 able to bisect the change that fixed it on the master branch. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
