[PATCH v2] drm/exynos: separated subdrv_probe function into two parts.
Changelog v2:
fixed the issue that when sub driver is probed, no kms drivers such as
fimd or hdmi are failed. no kms drivers have no manager so if manager is
null then encoder and connector creation should be ignored.
Changelog v1:
this patch separates exynos_drm_subdrv_probe function into sub driver's probe
call
and encoder/connector creation so that exynos drm core module can take exception
when some operation was failed properly.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 100 -
1 files changed, 69 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 84dd099..7b0432b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -34,33 +34,15 @@
static LIST_HEAD(exynos_drm_subdrv_list);
-static int exynos_drm_subdrv_probe(struct drm_device *dev,
+static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
struct drm_encoder *encoder;
struct drm_connector *connector;
+ int ret;
DRM_DEBUG_DRIVER("%s\n", __FILE__);
- if (subdrv->probe) {
- int ret;
-
- /*
-* this probe callback would be called by sub driver
-* after setting of all resources to this sub driver,
-* such as clock, irq and register map are done or by load()
-* of exynos drm driver.
-*
-* P.S. note that this driver is considered for modularization.
-*/
- ret = subdrv->probe(dev, subdrv->dev);
- if (ret)
- return ret;
- }
-
- if (!subdrv->manager)
- return 0;
-
subdrv->manager->dev = subdrv->dev;
/* create and initialize a encoder for this sub driver. */
@@ -78,24 +60,22 @@ static int exynos_drm_subdrv_probe(struct drm_device *dev,
connector = exynos_drm_connector_create(dev, encoder);
if (!connector) {
DRM_ERROR("failed to create connector\n");
- encoder->funcs->destroy(encoder);
- return -EFAULT;
+ ret = -EFAULT;
+ goto err_destroy_encoder;
}
subdrv->encoder = encoder;
subdrv->connector = connector;
return 0;
+
+err_destroy_encoder:
+ encoder->funcs->destroy(encoder);
+ return ret;
}
-static void exynos_drm_subdrv_remove(struct drm_device *dev,
- struct exynos_drm_subdrv *subdrv)
+static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv *subdrv)
{
- DRM_DEBUG_DRIVER("%s\n", __FILE__);
-
- if (subdrv->remove)
- subdrv->remove(dev);
-
if (subdrv->encoder) {
struct drm_encoder *encoder = subdrv->encoder;
encoder->funcs->destroy(encoder);
@@ -109,9 +89,43 @@ static void exynos_drm_subdrv_remove(struct drm_device *dev,
}
}
+static int exynos_drm_subdrv_probe(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+ if (subdrv->probe) {
+ int ret;
+
+ subdrv->drm_dev = dev;
+
+ /*
+* this probe callback would be called by sub driver
+* after setting of all resources to this sub driver,
+* such as clock, irq and register map are done or by load()
+* of exynos drm driver.
+*
+* P.S. note that this driver is considered for modularization.
+*/
+ ret = subdrv->probe(dev, subdrv->dev);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static void exynos_drm_subdrv_remove(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+ DRM_DEBUG_DRIVER("%s\n", __FILE__);
+
+ if (subdrv->remove)
+ subdrv->remove(dev, subdrv->dev);
+}
+
int exynos_drm_device_register(struct drm_device *dev)
{
struct exynos_drm_subdrv *subdrv, *n;
+ unsigned int fine_cnt = 0;
int err;
DRM_DEBUG_DRIVER("%s\n", __FILE__);
@@ -120,14 +134,36 @@ int exynos_drm_device_register(struct drm_device *dev)
return -EINVAL;
list_for_each_entry_safe(subdrv, n, &exynos_drm_subdrv_list, list) {
- subdrv->drm_dev = dev;
err = exynos_drm_subdrv_probe(dev, subdrv);
if (err) {
DRM_DEBUG("exynos drm subdrv probe failed.\n");
list_del(&subdrv->list);
+ continue;
+ }
+
+ /*
+* if manager is null then it means that this sub driver
+
[PATCH 10/10] drm/exynos: update crtc to plane safely
if old_crtc isn't same as encoder->crtc then it means that
user changed crtc id to another one so a plane to old_crtc
should be disabled so that current plane can be updated safely
and plane->crtc should be set to new crtc(encoder->crtc)
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 59 +-
1 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 98d5576..80a649b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -45,6 +45,7 @@
* @dpms: store the encoder dpms value.
*/
struct exynos_drm_encoder {
+ struct drm_crtc *old_crtc;
struct drm_encoder drm_encoder;
struct exynos_drm_manager *manager;
int dpms;
@@ -124,22 +125,74 @@ exynos_drm_encoder_mode_fixup(struct drm_encoder *encoder,
return true;
}
+static void disable_plane_to_crtc(struct drm_device *dev,
+ struct drm_crtc *old_crtc,
+ struct drm_crtc *new_crtc)
+{
+ struct drm_plane *plane;
+
+ /*
+* if old_crtc isn't same as encoder->crtc then it means that
+* user changed crtc id to another one so the plane to old_crtc
+* should be disabled and plane->crtc should be set to new_crtc
+* (encoder->crtc)
+*/
+ list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
+ if (plane->crtc == old_crtc) {
+ /*
+* do not change below call order.
+*
+* plane->funcs->disable_plane call checks
+* if encoder->crtc is same as plane->crtc and if same
+* then overlay_ops->disable callback will be called
+* to diasble current hw overlay so plane->crtc should
+* have new_crtc because new_crtc was set to
+* encoder->crtc in advance.
+*/
+ plane->crtc = new_crtc;
+ plane->funcs->disable_plane(plane);
+ }
+ }
+}
+
static void exynos_drm_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
struct drm_device *dev = encoder->dev;
struct drm_connector *connector;
- struct exynos_drm_manager *manager = exynos_drm_get_manager(encoder);
- struct exynos_drm_manager_ops *manager_ops = manager->ops;
+ struct exynos_drm_manager *manager;
+ struct exynos_drm_manager_ops *manager_ops;
DRM_DEBUG_KMS("%s\n", __FILE__);
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
- if (connector->encoder == encoder)
+ if (connector->encoder == encoder) {
+ struct exynos_drm_encoder *exynos_encoder;
+
+ exynos_encoder = to_exynos_encoder(encoder);
+
+ if (exynos_encoder->old_crtc != encoder->crtc &&
+ exynos_encoder->old_crtc) {
+
+ /*
+* disable a plane to old crtc and change
+* crtc of the plane to new one.
+*/
+ disable_plane_to_crtc(dev,
+ exynos_encoder->old_crtc,
+ encoder->crtc);
+ }
+
+ manager = exynos_drm_get_manager(encoder);
+ manager_ops = manager->ops;
+
if (manager_ops && manager_ops->mode_set)
manager_ops->mode_set(manager->dev,
adjusted_mode);
+
+ exynos_encoder->old_crtc = encoder->crtc;
+ }
}
}
--
1.7.4.1
[PATCH 09/10] drm/exynos: check NV12M format specific to Exynos properly
this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
functions to get/set the buffer count from/to exynos_drm_fb structure.
if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
to drm framebuffer refering to mode_cmd->handles and offsets.
but when booted, the buffer count will always be 1 because pixel
format of console framebuffer is RGB format.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 65 +++-
drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 +++--
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
4 files changed, 73 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 4ccfe43..98f8b83 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -41,10 +41,12 @@
* exynos specific framebuffer structure.
*
* @fb: drm framebuffer obejct.
+ * @buf_cnt: a buffer count to drm framebuffer.
* @exynos_gem_obj: array of exynos specific gem object containing a gem
object.
*/
struct exynos_drm_fb {
struct drm_framebuffer fb;
+ unsigned intbuf_cnt;
struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
};
@@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs exynos_drm_fb_funcs = {
.dirty = exynos_drm_fb_dirty,
};
+void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
+ unsigned int cnt)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ exynos_fb->buf_cnt = cnt;
+}
+
+unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ return exynos_fb->buf_cnt;
+}
+
struct drm_framebuffer *
exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
@@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
return &exynos_fb->fb;
}
+static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ unsigned int cnt = 0;
+
+ if (mode_cmd->pixel_format != DRM_FORMAT_NV12)
+ return drm_format_num_planes(mode_cmd->pixel_format);
+
+ while (cnt != MAX_FB_BUFFER) {
+ if (!mode_cmd->handles[cnt])
+ break;
+ cnt++;
+ }
+
+ /*
+* check if NV12 or NV12M.
+*
+* NV12
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base1, offsets[1] = Y_size
+*
+* NV12M
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base2, offsets[1] = 0
+*/
+ if (cnt == 2) {
+ /*
+* in case of NV12 format, offsets[1] is not 0 and
+* handles[0] is same as handles[1].
+*/
+ if (mode_cmd->offsets[1] &&
+ mode_cmd->handles[0] == mode_cmd->handles[1])
+ cnt = 1;
+ }
+
+ return cnt;
+}
+
static struct drm_framebuffer *
exynos_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
struct drm_mode_fb_cmd2 *mode_cmd)
@@ -134,7 +192,6 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
struct drm_gem_object *obj;
struct drm_framebuffer *fb;
struct exynos_drm_fb *exynos_fb;
- int nr;
int i;
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -152,9 +209,11 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
}
exynos_fb = to_exynos_fb(fb);
- nr = exynos_drm_format_num_buffers(fb->pixel_format);
+ exynos_fb->buf_cnt = exynos_drm_format_num_buffers(mode_cmd);
+
+ DRM_DEBUG_KMS("buf_cnt = %d\n", exynos_fb->buf_cnt);
- for (i = 1; i < nr; i++) {
+ for (i = 1; i < exynos_fb->buf_cnt; i++) {
obj = drm_gem_object_lookup(dev, file_priv,
mode_cmd->handles[i]);
if (!obj) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h
b/drivers/gpu/drm/exynos/exynos_drm_fb.h
index 5082375..96262e5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h
@@ -28,19 +28,6 @@
#ifndef _EXYNOS_DRM_FB_H_
#define _EXYNOS_DRM_FB_H
-static inline int exynos_drm_format_num_buffers(uint32_t format)
-{
- switch (format) {
- case DRM_FORMAT_NV12:
- case DRM_FORMAT_NV12MT:
- return 2;
- case DRM_FORMAT_YUV420:
- return 3;
- default:
- return 1;
- }
-}
-
struct drm_framebuffer *
exynos_drm_framebuffer_init(struct drm_devi
[PATCH 08/10] drm/exynos: make sure that hardware overlay for hdmi is disabled
the values set to registers will be updated into real registers
at vsync so dma operation could be malfunctioned when accessed
to memory after gem buffer was released. this patch makes sure
that hw overlay is disabled before the gem buffer is released.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 11 +++
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |1 +
drivers/gpu/drm/exynos/exynos_mixer.c| 13 +
3 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 3fdf0b6..0584132 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -274,10 +274,21 @@ static void drm_mixer_disable(struct device *subdrv_dev,
int zpos)
ctx->enabled[win] = false;
}
+static void drm_mixer_wait_for_vblank(struct device *subdrv_dev)
+{
+ struct drm_hdmi_context *ctx = to_context(subdrv_dev);
+
+ DRM_DEBUG_KMS("%s\n", __FILE__);
+
+ if (mixer_ops && mixer_ops->wait_for_vblank)
+ mixer_ops->wait_for_vblank(ctx->mixer_ctx->ctx);
+}
+
static struct exynos_drm_overlay_ops drm_hdmi_overlay_ops = {
.mode_set = drm_mixer_mode_set,
.commit = drm_mixer_commit,
.disable = drm_mixer_disable,
+ .wait_for_vblank = drm_mixer_wait_for_vblank,
};
static struct exynos_drm_manager hdmi_manager = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index a91c420..d9f9e9f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -67,6 +67,7 @@ struct exynos_mixer_ops {
void (*dpms)(void *ctx, int mode);
/* overlay */
+ void (*wait_for_vblank)(void *ctx);
void (*win_mode_set)(void *ctx, struct exynos_drm_overlay *overlay);
void (*win_commit)(void *ctx, int zpos);
void (*win_disable)(void *ctx, int zpos);
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 30fcc12..ba3be9b 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -726,6 +726,18 @@ static void mixer_dpms(void *ctx, int mode)
}
}
+static void mixer_wait_for_vblank(void *ctx)
+{
+ struct mixer_context *mixer_ctx = ctx;
+ struct mixer_resources *res = &mixer_ctx->mixer_res;
+ int ret;
+
+ ret = wait_for((mixer_reg_read(res, MXR_INT_STATUS) &
+ MXR_INT_STATUS_VSYNC), 50);
+ if (ret < 0)
+ DRM_DEBUG_KMS("vblank wait timed out.\n");
+}
+
static void mixer_win_mode_set(void *ctx,
struct exynos_drm_overlay *overlay)
{
@@ -818,6 +830,7 @@ static struct exynos_mixer_ops mixer_ops = {
.dpms = mixer_dpms,
/* overlay */
+ .wait_for_vblank= mixer_wait_for_vblank,
.win_mode_set = mixer_win_mode_set,
.win_commit = mixer_win_commit,
.win_disable= mixer_win_disable,
--
1.7.4.1
[PATCH 07/10] drm/exynos: make sure that hardware overlay for fimd is disabled
the values set to registers will be updated into real registers
at vsync so dma operation could be malfunctioned when accessed
to memory after gem buffer was released. this patch makes sure
that hw overlay is disabled before the gem buffer is released.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0ec9d86..2378d80 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -570,10 +570,22 @@ static void fimd_win_disable(struct device *dev, int zpos)
win_data->enabled = false;
}
+static void fimd_wait_for_vblank(struct device *dev)
+{
+ struct fimd_context *ctx = get_fimd_context(dev);
+ int ret;
+
+ ret = wait_for((__raw_readl(ctx->regs + VIDCON1) &
+ VIDCON1_VSTATUS_BACKPORCH), 50);
+ if (ret < 0)
+ DRM_DEBUG_KMS("vblank wait timed out.\n");
+}
+
static struct exynos_drm_overlay_ops fimd_overlay_ops = {
.mode_set = fimd_win_mode_set,
.commit = fimd_win_commit,
.disable = fimd_win_disable,
+ .wait_for_vblank = fimd_wait_for_vblank,
};
static struct exynos_drm_manager fimd_manager = {
--
1.7.4.1
[PATCH 06/10] drm/exynos: add wait_for_vblank callback interface.
this interface can be used to make sure that hardware overlay is disabled
to avoid that memory region is accessed by dma after gem buffer was released.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 17 +
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 10 ++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 24c45d8..00e4bdc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -37,6 +37,20 @@
#define MAX_FB_BUFFER 4
#define DEFAULT_ZPOS -1
+#define _wait_for(COND, MS) ({ \
+ unsigned long timeout__ = jiffies + msecs_to_jiffies(MS); \
+ int ret__ = 0; \
+ while (!(COND)) { \
+ if (time_after(jiffies, timeout__)) { \
+ ret__ = -ETIMEDOUT; \
+ break; \
+ } \
+ } \
+ ret__; \
+})
+
+#define wait_for(COND, MS) _wait_for(COND, MS)
+
struct drm_device;
struct exynos_drm_overlay;
struct drm_connector;
@@ -61,6 +75,8 @@ enum exynos_drm_output_type {
* @commit: apply hardware specific overlay data to registers.
* @enable: enable hardware specific overlay.
* @disable: disable hardware specific overlay.
+ * @wait_for_vblank: wait for vblank interrupt to make sure that
+ * dma transfer is completed.
*/
struct exynos_drm_overlay_ops {
void (*mode_set)(struct device *subdrv_dev,
@@ -68,6 +84,7 @@ struct exynos_drm_overlay_ops {
void (*commit)(struct device *subdrv_dev, int zpos);
void (*enable)(struct device *subdrv_dev, int zpos);
void (*disable)(struct device *subdrv_dev, int zpos);
+ void (*wait_for_vblank)(struct device *subdrv_dev);
};
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 08ba62f..98d5576 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -430,4 +430,14 @@ void exynos_drm_encoder_plane_disable(struct drm_encoder
*encoder, void *data)
if (overlay_ops && overlay_ops->disable)
overlay_ops->disable(manager->dev, zpos);
+
+ /*
+* wait for vblank interrupt
+* - with iommu, the dma operation could induce page fault
+* when accessed to memory after gem buffer was released so
+* make sure that the dma operation is completed before releasing
+* the gem bufer.
+*/
+ if (overlay_ops->wait_for_vblank)
+ overlay_ops->wait_for_vblank(manager->dev);
}
--
1.7.4.1
[PATCH 05/10] drm/exynos: fixed duplicated mode setting.
this patch fixes that when drm_crtc_helper_set_mode() is called,
mode data for hardware overlay and conntroller are updated two times.
for example, in case that drm_crtc_helper_set_mode() is called,
overlay_ops->commit() and manager_ops->commit() callbacks can be called
two times, first at drm_crtc_helper_set_mode() and second
at drm_helper_connector_dpms().
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 41 -
drivers/gpu/drm/exynos/exynos_drm_connector.h |2 +
drivers/gpu/drm/exynos/exynos_drm_crtc.c |3 +-
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 30 +++---
4 files changed, 62 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index d956819..1fadc22 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -40,6 +40,7 @@ struct exynos_drm_connector {
struct drm_connectordrm_connector;
uint32_tencoder_id;
struct exynos_drm_manager *manager;
+ uint32_tdpms;
};
/* convert exynos_video_timings to drm_display_mode */
@@ -226,6 +227,43 @@ static struct drm_connector_helper_funcs
exynos_connector_helper_funcs = {
.best_encoder = exynos_drm_best_encoder,
};
+void exynos_drm_display_power(struct drm_connector *connector, int mode)
+{
+ struct drm_encoder *encoder = connector->encoder;
+ struct exynos_drm_connector *exynos_connector;
+ struct exynos_drm_manager *manager = exynos_drm_get_manager(encoder);
+ struct exynos_drm_display_ops *display_ops = manager->display_ops;
+
+ exynos_connector = to_exynos_connector(connector);
+
+ if (exynos_connector->dpms == mode) {
+ DRM_DEBUG_KMS("desired dpms mode is same as previous one.\n");
+ return;
+ }
+
+ if (display_ops && display_ops->power_on)
+ display_ops->power_on(manager->dev, mode);
+
+ exynos_connector->dpms = mode;
+}
+
+static void exynos_drm_connector_dpms(struct drm_connector *connector,
+ int mode)
+{
+ DRM_DEBUG_KMS("%s\n", __FILE__);
+
+ /*
+* in case that drm_crtc_helper_set_mode() is called,
+* encoder/crtc->funcs->dpms() will be just returned
+* because they already were DRM_MODE_DPMS_ON so only
+* exynos_drm_display_power() will be called.
+*/
+ drm_helper_connector_dpms(connector, mode);
+
+ exynos_drm_display_power(connector, mode);
+
+}
+
static int exynos_drm_connector_fill_modes(struct drm_connector *connector,
unsigned int max_width, unsigned int max_height)
{
@@ -285,7 +323,7 @@ static void exynos_drm_connector_destroy(struct
drm_connector *connector)
}
static struct drm_connector_funcs exynos_connector_funcs = {
- .dpms = drm_helper_connector_dpms,
+ .dpms = exynos_drm_connector_dpms,
.fill_modes = exynos_drm_connector_fill_modes,
.detect = exynos_drm_connector_detect,
.destroy= exynos_drm_connector_destroy,
@@ -334,6 +372,7 @@ struct drm_connector *exynos_drm_connector_create(struct
drm_device *dev,
exynos_connector->encoder_id = encoder->base.id;
exynos_connector->manager = manager;
+ exynos_connector->dpms = DRM_MODE_DPMS_OFF;
connector->encoder = encoder;
err = drm_mode_connector_attach_encoder(connector, encoder);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.h
b/drivers/gpu/drm/exynos/exynos_drm_connector.h
index 1c7b2b5..40a55c2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.h
@@ -31,4 +31,6 @@
struct drm_connector *exynos_drm_connector_create(struct drm_device *dev,
struct drm_encoder *encoder);
+void exynos_drm_display_power(struct drm_connector *connector, int mode);
+
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index abb1e2f..b612bf5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -97,6 +97,7 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
DRM_DEBUG_KMS("%s\n", __FILE__);
+ exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
exynos_plane_commit(exynos_crtc->plane);
exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
}
@@ -126,8 +127,6 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
DRM_DEBUG_KMS("%s\n", __FILE__);
- exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
-
/*
* copy the mode data adjusted by mode_fixup() into crtc->mode
* so that hardware can be seet to proper mode.
diff --git
[PATCH 04/10] drm/exynos: separeated fimd_power_on into some parts.
this patch separetes fimd_power_on into fimd_activate and fimd_clock and
fimd_activate function will call fimd_clock to control fimd power and
vsync interrupt.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 60 --
1 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 47396e1..0ec9d86 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -747,16 +747,10 @@ static void fimd_clear_win(struct fimd_context *ctx, int
win)
writel(val, ctx->regs + SHADOWCON);
}
-static int fimd_power_on(struct fimd_context *ctx, bool enable)
+static int fimd_clock(struct fimd_context *ctx, bool enable)
{
- struct exynos_drm_subdrv *subdrv = &ctx->subdrv;
- struct device *dev = subdrv->dev;
-
DRM_DEBUG_KMS("%s\n", __FILE__);
- if (enable != false && enable != true)
- return -EINVAL;
-
if (enable) {
int ret;
@@ -769,18 +763,31 @@ static int fimd_power_on(struct fimd_context *ctx, bool
enable)
clk_disable(ctx->bus_clk);
return ret;
}
+ } else {
+ clk_disable(ctx->lcd_clk);
+ clk_disable(ctx->bus_clk);
+ }
- ctx->suspended = false;
+ return 0;
+}
+
+static int fimd_activate(struct fimd_context *ctx, bool enable)
+{
+ if (enable) {
+ int ret;
+ struct device *dev = ctx->subdrv.dev;
+
+ ret = fimd_clock(ctx, true);
+ if (ret < 0)
+ return ret;
/* if vblank was enabled status, enable it again. */
if (test_and_clear_bit(0, &ctx->irq_flags))
fimd_enable_vblank(dev);
- fimd_apply(dev);
+ ctx->suspended = false;
} else {
- clk_disable(ctx->lcd_clk);
- clk_disable(ctx->bus_clk);
-
+ fimd_clock(ctx, false);
ctx->suspended = true;
}
@@ -930,15 +937,15 @@ static int fimd_suspend(struct device *dev)
{
struct fimd_context *ctx = get_fimd_context(dev);
- if (pm_runtime_suspended(dev))
- return 0;
-
/*
* do not use pm_runtime_suspend(). if pm_runtime_suspend() is
* called here, an error would be returned by that interface
* because the usage_count of pm runtime is more than 1.
*/
- return fimd_power_on(ctx, false);
+ if (!pm_runtime_suspended(dev))
+ return fimd_activate(ctx, false);
+
+ return 0;
}
static int fimd_resume(struct device *dev)
@@ -950,8 +957,21 @@ static int fimd_resume(struct device *dev)
* of pm runtime would still be 1 so in this case, fimd driver
* should be on directly not drawing on pm runtime interface.
*/
- if (!pm_runtime_suspended(dev))
- return fimd_power_on(ctx, true);
+ if (pm_runtime_suspended(dev)) {
+ int ret;
+
+ ret = fimd_activate(ctx, false);
+ if (ret < 0)
+ return ret;
+
+ /*
+* in case of dpms on(standby), fimd_apply function will
+* be called by encoder's dpms callback to update fimd's
+* registers but in case of sleep wakeup, it's not.
+* so fimd_apply function should be called at here.
+*/
+ fimd_apply(dev);
+ }
return 0;
}
@@ -964,7 +984,7 @@ static int fimd_runtime_suspend(struct device *dev)
DRM_DEBUG_KMS("%s\n", __FILE__);
- return fimd_power_on(ctx, false);
+ return fimd_activate(ctx, false);
}
static int fimd_runtime_resume(struct device *dev)
@@ -973,7 +993,7 @@ static int fimd_runtime_resume(struct device *dev)
DRM_DEBUG_KMS("%s\n", __FILE__);
- return fimd_power_on(ctx, true);
+ return fimd_activate(ctx, true);
}
#endif
--
1.7.4.1
[PATCH 03/10] drm/exynos: fixed page align bug.
do not align in page unit at dumb creation. the align is done by exynos_drm_gem_create() to be called commonly. Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_gem.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c index da4e3ca..a38051c 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c @@ -662,7 +662,7 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv, */ args->pitch = args->width * ((args->bpp + 7) / 8); - args->size = PAGE_ALIGN(args->pitch * args->height); + args->size = args->pitch * args->height; exynos_gem_obj = exynos_drm_gem_create(dev, args->flags, args->size); if (IS_ERR(exynos_gem_obj)) -- 1.7.4.1
[PATCH 02/10] drm/exynos: separated subdrv_probe function into two parts.
this patch separates exynos_drm_subdrv_probe function into sub driver's probe
call
and encoder/connector creation so that exynos drm core module can take exception
when some operation was failed properly.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 93 +-
1 files changed, 65 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 84dd099..1c8d5fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -34,30 +34,15 @@
static LIST_HEAD(exynos_drm_subdrv_list);
-static int exynos_drm_subdrv_probe(struct drm_device *dev,
+static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
struct drm_encoder *encoder;
struct drm_connector *connector;
+ int ret;
DRM_DEBUG_DRIVER("%s\n", __FILE__);
- if (subdrv->probe) {
- int ret;
-
- /*
-* this probe callback would be called by sub driver
-* after setting of all resources to this sub driver,
-* such as clock, irq and register map are done or by load()
-* of exynos drm driver.
-*
-* P.S. note that this driver is considered for modularization.
-*/
- ret = subdrv->probe(dev, subdrv->dev);
- if (ret)
- return ret;
- }
-
if (!subdrv->manager)
return 0;
@@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct drm_device *dev,
connector = exynos_drm_connector_create(dev, encoder);
if (!connector) {
DRM_ERROR("failed to create connector\n");
- encoder->funcs->destroy(encoder);
- return -EFAULT;
+ ret = -EFAULT;
+ goto err_destroy_encoder;
}
subdrv->encoder = encoder;
subdrv->connector = connector;
return 0;
+
+err_destroy_encoder:
+ encoder->funcs->destroy(encoder);
+ return ret;
}
-static void exynos_drm_subdrv_remove(struct drm_device *dev,
- struct exynos_drm_subdrv *subdrv)
+static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv *subdrv)
{
- DRM_DEBUG_DRIVER("%s\n", __FILE__);
-
- if (subdrv->remove)
- subdrv->remove(dev);
-
if (subdrv->encoder) {
struct drm_encoder *encoder = subdrv->encoder;
encoder->funcs->destroy(encoder);
@@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct drm_device *dev,
}
}
+static int exynos_drm_subdrv_probe(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+ if (subdrv->probe) {
+ int ret;
+
+ subdrv->drm_dev = dev;
+
+ /*
+* this probe callback would be called by sub driver
+* after setting of all resources to this sub driver,
+* such as clock, irq and register map are done or by load()
+* of exynos drm driver.
+*
+* P.S. note that this driver is considered for modularization.
+*/
+ ret = subdrv->probe(dev, subdrv->dev);
+ if (ret)
+ return ret;
+ }
+
+ if (!subdrv->manager)
+ return -EINVAL;
+
+ subdrv->manager->dev = subdrv->dev;
+
+ return 0;
+}
+
+static void exynos_drm_subdrv_remove(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+ DRM_DEBUG_DRIVER("%s\n", __FILE__);
+
+ if (subdrv->remove)
+ subdrv->remove(dev, subdrv->dev);
+}
+
int exynos_drm_device_register(struct drm_device *dev)
{
struct exynos_drm_subdrv *subdrv, *n;
+ unsigned int fine_cnt = 0;
int err;
DRM_DEBUG_DRIVER("%s\n", __FILE__);
@@ -120,14 +142,27 @@ int exynos_drm_device_register(struct drm_device *dev)
return -EINVAL;
list_for_each_entry_safe(subdrv, n, &exynos_drm_subdrv_list, list) {
- subdrv->drm_dev = dev;
err = exynos_drm_subdrv_probe(dev, subdrv);
if (err) {
DRM_DEBUG("exynos drm subdrv probe failed.\n");
list_del(&subdrv->list);
+ continue;
}
+
+ err = exynos_drm_create_enc_conn(dev, subdrv);
+ if (err) {
+ DRM_DEBUG("failed to create encoder and connector.\n");
+ exynos_drm_subdrv_remove(dev, subdrv);
+ list_del(&subdrv->list);
+ continue;
+ }
+
+
[PATCH 01/10] drm/exynos: added device object to subdrv's remove callback as argument
when remove callback of exynos_drm_subdrv is called, it could need
device object for sub driver to control things specific to hw such as
runtime pm.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.h |2 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index e22704b..24c45d8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -266,7 +266,7 @@ struct exynos_drm_subdrv {
struct exynos_drm_manager *manager;
int (*probe)(struct drm_device *drm_dev, struct device *dev);
- void (*remove)(struct drm_device *dev);
+ void (*remove)(struct drm_device *drm_dev, struct device *dev);
int (*open)(struct drm_device *drm_dev, struct device *dev,
struct drm_file *file);
void (*close)(struct drm_device *drm_dev, struct device *dev,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index b19cd93..47396e1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -678,7 +678,7 @@ static int fimd_subdrv_probe(struct drm_device *drm_dev,
struct device *dev)
return 0;
}
-static void fimd_subdrv_remove(struct drm_device *drm_dev)
+static void fimd_subdrv_remove(struct drm_device *drm_dev, struct device *dev)
{
DRM_DEBUG_KMS("%s\n", __FILE__);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 537027a..f900da0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -466,7 +466,7 @@ static int vidi_subdrv_probe(struct drm_device *drm_dev,
struct device *dev)
return 0;
}
-static void vidi_subdrv_remove(struct drm_device *drm_dev)
+static void vidi_subdrv_remove(struct drm_device *drm_dev, struct device *dev)
{
DRM_DEBUG_KMS("%s\n", __FILE__);
--
1.7.4.1
[PATCH 00/10 v2] updated exynos-drm-fixes
Hello all, Changelog v2: . fixed duplicated mode setting. - this patch includes below three patches of v1 and fixes the issue that drm_helper_connector_dpms() isn't called. http://www.spinics.net/lists/dri-devel/msg26427.html http://www.spinics.net/lists/dri-devel/msg26428.html http://www.spinics.net/lists/dri-devel/msg26430.html . removed below two patches of v1 and the patch for changing context name of hdmi and mixer will be updated for code consistency later because now hdmi module still use "hdata" term as context name in other functions. http://www.spinics.net/lists/dri-devel/msg26434.html http://www.spinics.net/lists/dri-devel/msg26435.html . fixed below patch of v1 so that drm_format_num_planes() is called http://www.spinics.net/lists/dri-devel/msg26432.html . separated below patch of v1 into exynos drm framework and device specific parts. http://www.spinics.net/lists/dri-devel/msg26431.html Changelog v1: This patch set fixes the following: . fixed page align - page align is done by exynos_drm_gem_create() so do not align in page unit at exynos_drm_gem_dumb_create(). . removed unnecessary dpms call - encoder's mode_set callback isn't specific to hardware so it doesn't need to call exynos_drm_encoder_dpms() . control display power at connector module - it doesn't need that display power is controlled by encoder's dpms so moves it into connector module so that the display power can be controlled by connector's dpms properly. . make sure that hardware overlay for fimd and hdmi is disabled - the values set to registers will be updated into real registers at vsync so dma operation could be malfunctioned when accessed to memory after gem buffer was released. this patch makes sure that hw overlay is disabled before the gem buffer is released. . check NV12M format specific to Exynos properly - this patch adds buf_cnt variable in exynos_drm_fb structure and that means a buffer count to drm framebuffer and also adds two functions to get/set the buffer count from/to exynos_drm_fb structure. if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count to drm framebuffer refering to mode_cmd->handles and offsets. but when booted, the buffer count will always be 1 because pixel format of console framebuffer is RGB format. . updated crtc to plane safely - if old_crtc isn't same as encoder->crtc then it means that user changed crtc id to another one so a plane to old_crtc should be disabled so that current plane can be updated safely and plane->crtc should be set to new crtc(encoder->crtc) And code clean like below: . separated fimd_power_on into some parts - separated fimd_power_on into fimd_activate and fimd_clock functions and fimd_activate function will call fimd_clock to control fimd power and vsync interrupt. . separated subdrv->probe call and encoder/connector creation - with this patch, exynos drm core module can take exception when some operation was failed properly. . changed context name of hdmi and mixer - changed ctx variable name in exynos_drm_hdmi_context structure to client because the use of ctx variable name makes it confused. . fixed build warning Thanks. Inki Dae (10): drm/exynos: added device object to subdrv's remove callback as argument drm/exynos: separated subdrv_probe function into two parts. drm/exynos: fixed page align bug. drm/exynos: separeated fimd_power_on into some parts. drm/exynos: fixed duplicated mode setting. drm/exynos: add wait_for_vblank callback interface. drm/exynos: make sure that hardware overlay for fimd is disabled drm/exynos: make sure that hardware overlay for hdmi is disabled drm/exynos: check NV12M format specific to Exynos properly drm/exynos: update crtc to plane safely drivers/gpu/drm/exynos/exynos_drm_connector.c | 41 ++- drivers/gpu/drm/exynos/exynos_drm_connector.h |2 + drivers/gpu/drm/exynos/exynos_drm_core.c | 93 --- drivers/gpu/drm/exynos/exynos_drm_crtc.c |3 +- drivers/gpu/drm/exynos/exynos_drm_drv.h | 19 +- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 99 + drivers/gpu/drm/exynos/exynos_drm_fb.c| 65 +++- drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 ++--- drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 74 +- drivers/gpu/drm/exynos/exynos_drm_gem.c |2 +- drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 11 +++ drivers/gpu/drm/exynos/exynos_drm_hdmi.h |1 + drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c |2 +- drivers/gpu/drm/exynos/exynos_mixer.c | 13 +++ 16 files changed, 364 insertions(+), 86 deletions(-) -- 1.7.4.1
radeon testing
On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
> > I just tested the rebased acpi_patches branch: ACPI part works fine, but
> > I see a big slow down during radeon driver initialization when the
> > screen goes black for a couple of seconds (with 3.5.0 + acpi patches the
> > screen just flickers during boot). With initcall_debug I see:
> >
> > [2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552
> > ...
> > [5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after
> > 3102147 usecs
> >
> > For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not
> > very
> > informative, I'll try and get more info...
>
> Can you bisect?
I've put in some printk, this is the result:
[2.403138] evergreen_mc_program
[2.403196] evergreen_mc_stop
...
[4.268491] evergreen_mc_resume done
[4.268548] evergreen_mc_program done
This is the patch:
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1349,6 +1349,8 @@ void evergreen_mc_program(struct radeon_device *rdev)
u32 tmp;
int i, j;
+ printk(KERN_INFO "%s\n", __func__);
+
/* Initialize HDP */
for (i = 0, j = 0; i < 32; i++, j += 0x18) {
WREG32((0x2c14 + j), 0x);
@@ -1359,10 +1361,14 @@ void evergreen_mc_program(struct radeon_device *rdev)
}
WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0);
+ printk(KERN_INFO "evergreen_mc_stop\n");
evergreen_mc_stop(rdev, &save);
+// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
}
+// printk(KERN_INFO "evergreen_mc_wait_for_idle done\n");
+
/* Lockout access through VGA aperture*/
WREG32(VGA_HDP_CONTROL, VGA_MEMORY_DISABLE);
/* Update configuration */
@@ -1411,10 +1417,13 @@ void evergreen_mc_program(struct radeon_device *rdev)
WREG32(MC_VM_AGP_TOP, 0x0FFF);
WREG32(MC_VM_AGP_BOT, 0x0FFF);
}
+// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
}
+// printk(KERN_INFO "evergreen_mc_resume\n");
evergreen_mc_resume(rdev, &save);
+ printk(KERN_INFO "evergreen_mc_resume done\n");
/* we need to own VRAM, so turn off the VGA renderer here
* to stop it overwriting our objects */
rv515_vga_render_disable(rdev);
Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
the machine. The likely culprit is commit 023e188e:
commit 023e188ec102330eb05ad264f675e869637478eb
Author: Alex Deucher
Date: Wed Aug 15 17:18:42 2012 -0400
drm/radeon: properly handle mc_stop/mc_resume on evergreen+
- Stop the displays from accessing the FB
- Block CPU access
- Turn off MC client access
This should fix issues some users have seen, especially
with UEFI, when changing the MC FB location that result
in hangs or display corruption.
I haven't tried backing out the commit yet, but looking at the diff I
see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
but evergreen_mc_program is called way before IRQ is set up. Is the
vblank counter running? Looks like we just hitting the timeout here...
Luca
[Bug 31862] 3.4(and earlier): White text blocks shown during boot-up
https://bugzilla.kernel.org/show_bug.cgi?id=31862 Alan changed: What|Removed |Added Summary|2.6.39.3 (and earlier): |3.4(and earlier): White |White text blocks shown |text blocks shown during |during boot-up |boot-up -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 31862] 2.6.39.3 (and earlier): White text blocks shown during boot-up
https://bugzilla.kernel.org/show_bug.cgi?id=31862 Alan changed: What|Removed |Added Status|REOPENED|NEEDINFO Component|Other |Video(DRI - non Intel) AssignedTo|other_other at kernel-bugs.osd |drivers_video-dri at kernel-bu |l.org |gs.osdl.org Product|Other |Drivers --- Comment #3 from Alan 2012-08-20 21:14:47 --- Because nothing had happened since 2011 and because it appeared to be to do with the userspace. Just having a general prune of old bugs - not particularly picking on yours Now it's re-opened and known current hopefully it'll shake a branch or two. Do you only see the white rectangles during dracut or do they appear in X or console too ? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] drm/ttm: remove EBUSY handling in ttm_execbuf_util
Hey, Op 20-08-12 17:15, Jerome Glisse schreef: > On Mon, Aug 20, 2012 at 9:42 AM, Maarten Lankhorst > wrote: >> How is this different from just calling with no_wait == false? >> As far as I can tell, both paths end up with the same result.. >> >> Signed-off-by: Maarten Lankhorst > NAK this seriously modify the behavior. The ttm_eu_del_from_lru_locked > part is important. It must happen with lru lock held and without any > dropping of this lock prior to wait for bo unreserve. > You're right, I missed the part where it removed those, causing the later patch to be wrong too. However I still think the code can be made more readable. Wouldn't it be better if it used the unlocked variants instead? It would save a lot of extra list traversals, and you could drop removed, reserved and put_count from ttm_validate_buffer. ~Maarten
[PATCH v2] drm/exynos: add wait_for_vblank callback interface.
Changelog v2:
fixed comments.
Changelog v1:
this interface can be used to make sure that hardware overlay is disabled
to avoid that memory region is accessed by dma after gem buffer was released.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 17 +
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 10 ++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 24c45d8..eec77aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -37,6 +37,20 @@
#define MAX_FB_BUFFER 4
#define DEFAULT_ZPOS -1
+#define _wait_for(COND, MS) ({ \
+ unsigned long timeout__ = jiffies + msecs_to_jiffies(MS); \
+ int ret__ = 0; \
+ while (!(COND)) { \
+ if (time_after(jiffies, timeout__)) { \
+ ret__ = -ETIMEDOUT; \
+ break; \
+ } \
+ } \
+ ret__; \
+})
+
+#define wait_for(COND, MS) _wait_for(COND, MS)
+
struct drm_device;
struct exynos_drm_overlay;
struct drm_connector;
@@ -61,6 +75,8 @@ enum exynos_drm_output_type {
* @commit: apply hardware specific overlay data to registers.
* @enable: enable hardware specific overlay.
* @disable: disable hardware specific overlay.
+ * @wait_for_vblank: wait for vblank interrupt to make sure that
+ * hardware overlay is disabled.
*/
struct exynos_drm_overlay_ops {
void (*mode_set)(struct device *subdrv_dev,
@@ -68,6 +84,7 @@ struct exynos_drm_overlay_ops {
void (*commit)(struct device *subdrv_dev, int zpos);
void (*enable)(struct device *subdrv_dev, int zpos);
void (*disable)(struct device *subdrv_dev, int zpos);
+ void (*wait_for_vblank)(struct device *subdrv_dev);
};
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 08ba62f..f453116 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -430,4 +430,14 @@ void exynos_drm_encoder_plane_disable(struct drm_encoder
*encoder, void *data)
if (overlay_ops && overlay_ops->disable)
overlay_ops->disable(manager->dev, zpos);
+
+ /*
+* wait for vblank interrupt
+* - this makes sure that hardware overlay is disabled to avoid
+* for the dma accesses to memory after gem buffer was released
+* because the setting for disabling the overlay will be updated
+* at vsync.
+*/
+ if (overlay_ops->wait_for_vblank)
+ overlay_ops->wait_for_vblank(manager->dev);
}
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On 08/20/2012 05:23 PM, Dave Airlie wrote: > On Tue, Aug 21, 2012 at 8:45 AM, Randy Dunlap wrote: >> On 08/19/2012 10:22 PM, Dave Airlie wrote: >> >>> On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap wrote: On 08/17/12 15:55, Dave Airlie wrote: > On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote: >> On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap >> wrote: >>> On 08/17/2012 03:25 PM, Justin M. Forbes wrote: >>> for , we have verified cases on inteldrmfb, radeondrmfb, and cirrusdrmfb. This is the last message displayed before the system hangs. This seems to be hitting a large number of users in Fedora, though certainly not everyone. This started happening with the 3.5 updates, and is still an issue. It appears to be a race condition, because various things have allowed boot to continue for some users, though there is no clear work around. Has anyone else run across this? Any ideas. For more background we have the following bugs: inteldrmfb: https://bugzilla.redhat.com/show_bug.cgi?id=843826 radeondrmfb: https://bugzilla.redhat.com/show_bug.cgi?id=845745 cirrusdrmfb : https://bugzilla.redhat.com/show_bug.cgi?id=843860 It should be noted that the conflicting fb hw usage message is not new, it has been around for a while, but this is the last message seen before the hang. >>> >>> >>> Hi, (adding dri-devel mailing list) >>> >>> >>> I started seeing this problem on 3.5-rc6. >>> >>> AFAICT, the system is not actually hung, it's just that no output >>> is showing up on the real (physical) output device (display) -- it's >>> going somewhere else (or to the bit bucket). >>> >> >> Can we bisect this at all? I guess I'll have to try again. My first attempt did not prove anything, I think because the conflict does not happen 100% of the time (i.e., it feels like a timing problem). >> I worry the intel one will bisect to where we moved the conflict >> resolution earlier, but I'd like to see if applying that patch earlier >> causes the issue, since radeon has it. Do you know of a specific commit that I could revert and test? >>> >>> 9f846a16d213523fbe6daea17e20df6b8ac5a1e5 >>> >>> might work, but it just changes the timing mostly. >>> >>> also testing 3.4 with that on top would be good. >> >> >> That commit doesn't apply cleanly to 3.4, but reverting >> it on 3.5-rc6 (where I first saw the problem) allows me to boot >> 3.5-rc6 multiple times without a problem. >> >> Maybe Justin can get more stable testing done also.. > > Randy do you have a vga= on your kernel command line? Ah, yes: "vga=ask" -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On 08/20/2012 05:23 PM, Dave Airlie wrote: > On Tue, Aug 21, 2012 at 8:45 AM, Randy Dunlap wrote: >> On 08/19/2012 10:22 PM, Dave Airlie wrote: >> >>> On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap >>> wrote: On 08/17/12 15:55, Dave Airlie wrote: > On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote: >> On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap >> wrote: >>> On 08/17/2012 03:25 PM, Justin M. Forbes wrote: >>> for , we have verified cases on inteldrmfb, radeondrmfb, and cirrusdrmfb. This is the last message displayed before the system hangs. This seems to be hitting a large number of users in Fedora, though certainly not everyone. This started happening with the 3.5 updates, and is still an issue. It appears to be a race condition, because various things have allowed boot to continue for some users, though there is no clear work around. Has anyone else run across this? Any ideas. For more background we have the following bugs: inteldrmfb: https://bugzilla.redhat.com/show_bug.cgi?id=843826 radeondrmfb: https://bugzilla.redhat.com/show_bug.cgi?id=845745 cirrusdrmfb : https://bugzilla.redhat.com/show_bug.cgi?id=843860 It should be noted that the conflicting fb hw usage message is not new, it has been around for a while, but this is the last message seen before the hang. >>> >>> >>> Hi, (adding dri-devel mailing list) >>> >>> >>> I started seeing this problem on 3.5-rc6. >>> >>> AFAICT, the system is not actually hung, it's just that no output >>> is showing up on the real (physical) output device (display) -- it's >>> going somewhere else (or to the bit bucket). >>> >> >> Can we bisect this at all? I guess I'll have to try again. My first attempt did not prove anything, I think because the conflict does not happen 100% of the time (i.e., it feels like a timing problem). >> I worry the intel one will bisect to where we moved the conflict >> resolution earlier, but I'd like to see if applying that patch earlier >> causes the issue, since radeon has it. Do you know of a specific commit that I could revert and test? >>> >>> 9f846a16d213523fbe6daea17e20df6b8ac5a1e5 >>> >>> might work, but it just changes the timing mostly. >>> >>> also testing 3.4 with that on top would be good. >> >> >> That commit doesn't apply cleanly to 3.4, but reverting >> it on 3.5-rc6 (where I first saw the problem) allows me to boot >> 3.5-rc6 multiple times without a problem. >> >> Maybe Justin can get more stable testing done also.. > > Randy do you have a vga= on your kernel command line? Ah, yes: "vga=ask" -- ~Randy
Re: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On Tue, Aug 21, 2012 at 8:45 AM, Randy Dunlap wrote: > On 08/19/2012 10:22 PM, Dave Airlie wrote: > >> On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap wrote: >>> On 08/17/12 15:55, Dave Airlie wrote: >>> On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote: > On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap > wrote: >> On 08/17/2012 03:25 PM, Justin M. Forbes wrote: >> >>> for , we have verified cases on inteldrmfb, radeondrmfb, and >>> cirrusdrmfb. >>> >>> This is the last message displayed before the system hangs. This seems >>> to be hitting a large number of users in Fedora, though certainly not >>> everyone. This started happening with the 3.5 updates, and is still an >>> issue. It appears to be a race condition, because various things have >>> allowed boot to continue for some users, though there is no clear work >>> around. Has anyone else run across this? Any ideas. For more >>> background we have the following bugs: >>> >>> inteldrmfb: >>> https://bugzilla.redhat.com/show_bug.cgi?id=843826 >>> >>> radeondrmfb: >>> https://bugzilla.redhat.com/show_bug.cgi?id=845745 >>> >>> cirrusdrmfb : >>> https://bugzilla.redhat.com/show_bug.cgi?id=843860 >>> >>> It should be noted that the conflicting fb hw usage message is not new, >>> it has been around for a while, but this is the last message seen before >>> the hang. >> >> >> Hi, (adding dri-devel mailing list) >> >> >> I started seeing this problem on 3.5-rc6. >> >> AFAICT, the system is not actually hung, it's just that no output >> is showing up on the real (physical) output device (display) -- it's >> going somewhere else (or to the bit bucket). >> > > Can we bisect this at all? >>> >>> I guess I'll have to try again. My first attempt did not >>> prove anything, I think because the conflict does not happen >>> 100% of the time (i.e., it feels like a timing problem). >>> > I worry the intel one will bisect to where we moved the conflict > resolution earlier, but I'd like to see if applying that patch earlier > causes the issue, since radeon has it. >>> >>> Do you know of a specific commit that I could revert and test? >> >> 9f846a16d213523fbe6daea17e20df6b8ac5a1e5 >> >> might work, but it just changes the timing mostly. >> >> also testing 3.4 with that on top would be good. > > > That commit doesn't apply cleanly to 3.4, but reverting > it on 3.5-rc6 (where I first saw the problem) allows me to boot > 3.5-rc6 multiple times without a problem. > > Maybe Justin can get more stable testing done also.. Randy do you have a vga= on your kernel command line? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 7/7] drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready
On Mon, Aug 20, 2012 at 11:24:44AM -0500, Seth Forshee wrote: > I'm not sure how we support both of these cases without doing something > more like what I originally proposed, i.e. registering the LVDS > connector even if it doesn't look like a panel is attached. I still > honestly favor that approach, although it does come with its own set of > challenges. > > The only other option I can come up with is to reprobe LVDS after > switcheroo and add the connector at that time. I haven't investigated > this option in detail, but at first glance it looks like there are at > least some places where DRM isn't prepared to cope with adding > connectors after initialization. Well, one option is to identify whether the hardware is switcheroo capable without the use of the switcheroo driver. It looks like we can do that in the majority of cases - Apple is the only special case I can see, and that one's a fairly easy workaround. -- Matthew Garrett | mjg59 at srcf.ucam.org
[PATCH] radeon: align r600 msaa buffers to a multiple of macrotile size * num samples
I am not sure whether this is needed, but better be safe than sorry. --- radeon/radeon_surface.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c index 98f4aaf..4118a37 100644 --- a/radeon/radeon_surface.c +++ b/radeon/radeon_surface.c @@ -356,7 +356,7 @@ static int r6_surface_init_2d(struct radeon_surface_manager *surf_man, surf->bo_alignment = MAX2(surf_man->hw_info.num_pipes * surf_man->hw_info.num_banks * - surf->bpe * 64, + surf->nsamples * surf->bpe * 64, xalign * yalign * surf->nsamples * surf->bpe); } -- 1.7.9.5
[RFC PATCH 7/7] drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready
On Mon, Aug 20, 2012 at 10:56:33AM -0500, Seth Forshee wrote: > On Mon, Aug 20, 2012 at 04:36:40PM +0100, Matthew Garrett wrote: > > Won't this break the multiple cards with independent outputs case? > > Yes, if they don't have a switcheroo handler. I only have experience > with one such machine, which had optimus graphics. My recollection is > that it did have a switcheroo handler, which was only capable of > controlling power to the discrete card. So if I have a desktop machine and install two graphics cards? -- Matthew Garrett | mjg59 at srcf.ucam.org
[RFC PATCH 7/7] drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready
On Mon, Aug 20, 2012 at 10:31:04AM -0500, Seth Forshee wrote: > + /* > + * For secondary graphics devices shouldn't be initialized > + * until the handler and primary graphics device have been > + * registered with vga_switcheroo. > + * > + * FIXME: Is vga_default_device() reliable enough for this > + * purpose? > + * > + * FIXME: If vga_switcheroo is disabled secondary devices > + * never gets initialized. Is this okay? Maybe it is, since > + * we can't switch to the secondary GPU anyway. > + */ Won't this break the multiple cards with independent outputs case? -- Matthew Garrett | mjg59 at srcf.ucam.org
[PATCH] drm/ttm: cleanup ttm_execbuf_util.c slightly more
The removed member is unneeded, an extra pass is done after all
buffers have been reserved. The behavior stays the same even without
the removed member, but this makes the code slightly more readable.
Depends on previous 2 execbuf-util patches.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 69 +++-
1 file changed, 24 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 4e7b596..a545bc9 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -32,7 +32,7 @@
#include
#include
-static void ttm_eu_backoff_reservation_locked(struct list_head *list)
+static void ttm_eu_backoff_reservation_locked(struct list_head *list, bool
removed)
{
struct ttm_validate_buffer *entry;
@@ -41,43 +41,13 @@ static void ttm_eu_backoff_reservation_locked(struct
list_head *list)
if (!entry->reserved)
continue;
- if (entry->removed) {
- ttm_bo_add_to_lru(bo);
- entry->removed = false;
-
- }
entry->reserved = false;
- atomic_set(&bo->reserved, 0);
- wake_up_all(&bo->event_queue);
- }
-}
-
-static void ttm_eu_del_from_lru_locked(struct list_head *list)
-{
- struct ttm_validate_buffer *entry;
-
- list_for_each_entry(entry, list, head) {
- struct ttm_buffer_object *bo = entry->bo;
- if (!entry->reserved)
- continue;
- if (!entry->removed) {
- entry->put_count = ttm_bo_del_from_lru(bo);
- entry->removed = true;
- }
- }
-}
-
-static void ttm_eu_list_ref_sub(struct list_head *list)
-{
- struct ttm_validate_buffer *entry;
-
- list_for_each_entry(entry, list, head) {
- struct ttm_buffer_object *bo = entry->bo;
-
- if (entry->put_count) {
- ttm_bo_list_ref_sub(bo, entry->put_count, true);
- entry->put_count = 0;
+ if (removed) {
+ ttm_bo_unreserve_locked(bo);
+ } else {
+ atomic_set(&bo->reserved, 0);
+ wake_up_all(&bo->event_queue);
}
}
}
@@ -93,7 +63,7 @@ void ttm_eu_backoff_reservation(struct list_head *list)
entry = list_first_entry(list, struct ttm_validate_buffer, head);
glob = entry->bo->glob;
spin_lock(&glob->lru_lock);
- ttm_eu_backoff_reservation_locked(list);
+ ttm_eu_backoff_reservation_locked(list, true);
spin_unlock(&glob->lru_lock);
}
EXPORT_SYMBOL(ttm_eu_backoff_reservation);
@@ -122,8 +92,6 @@ int ttm_eu_reserve_buffers(struct list_head *list)
list_for_each_entry(entry, list, head) {
entry->reserved = false;
- entry->put_count = 0;
- entry->removed = false;
}
entry = list_first_entry(list, struct ttm_validate_buffer, head);
@@ -141,26 +109,37 @@ retry:
case 0:
break;
case -EAGAIN:
- ttm_eu_backoff_reservation_locked(list);
+ ttm_eu_backoff_reservation_locked(list, false);
spin_unlock(&glob->lru_lock);
- ttm_eu_list_ref_sub(list);
ret = ttm_bo_wait_unreserved(bo, true);
if (unlikely(ret != 0))
return ret;
goto retry;
default:
- ttm_eu_backoff_reservation_locked(list);
+ ttm_eu_backoff_reservation_locked(list, false);
spin_unlock(&glob->lru_lock);
- ttm_eu_list_ref_sub(list);
return ret;
}
entry->reserved = true;
}
- ttm_eu_del_from_lru_locked(list);
+ list_for_each_entry(entry, list, head) {
+ struct ttm_buffer_object *bo = entry->bo;
+
+ entry->put_count = ttm_bo_del_from_lru(bo);
+ }
+
spin_unlock(&glob->lru_lock);
- ttm_eu_list_ref_sub(list);
+
+ list_for_each_entry(entry, list, head) {
+ struct ttm_buffer_object *bo = entry->bo;
+
+ if (entry->put_count) {
+ ttm_bo_list_ref_sub(bo, entry->put_count, true);
+ entry->put_count = 0;
+ }
+ }
return 0;
}
diff --git a/include/drm/ttm/ttm_execbuf_util.h
b/include/drm/ttm/ttm_execbuf_util.h
index 26cc7f9..0ef7c95 100644
--- a/include/drm/ttm/ttm_execbuf_util.h
+++ b/include/drm/ttm/ttm_execbuf_util.h
@@ -42,7 +42,6 @@
* @new_sync_obj_arg: New sync_obj_arg for @bo, to be used once
* addin
[PATCH 11/13] drm/exynos: changed context name of hdmi and mixer
2012/8/20 InKi Dae :
> 2012/8/20 Joonyoung Shim :
>> On 08/20/2012 03:17 PM, InKi Dae wrote:
>>>
>>> 2012/8/20 Joonyoung Shim :
On 08/20/2012 11:29 AM, InKi Dae wrote:
>
> 2012/8/20 Joonyoung Shim :
>>
>> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>>
>>> this patch changes ctx variable name in exynos_drm_hdmi_context
>>> structure to client because the use of ctx variable makes it confused.
>>
>>
>> I don't prefer "client" name. This is not client and server
>> relationship.
>>
> Okay, give me your opinion. which one do you prefer?
Just "data".
>>> It's not clear. "data" is so comprehensive just use "child_ctx". we
>>> already use "parent_ctx" as the context of exynos_drm_hdmi module.
>>
>>
>> Actually, i prefer "data" term than "ctx" term. Anyway i want to focus
>> why this problem is occurred because i think that codes are some ugly. I
>> think we first need to consider to solve this situation using code
>> redesign, structure change and etc.
>>
>
> calm down and focus on the use of term. this is so minor and this is
> not related to design issue.
>
and it's not important whether you prefer this term or not. if the use
of "data" term is logical enough then we will use it otherwise
"child_ctx" so give me your comment why you don't prefer "child_ctx"
term. actually, now hdmi codes use "hdata" term as context's instance
but other use "ctx" term. as I mentioned before, I gave you my opinion
that "data" term is so comprehensive so I DON'T PREFER "data" term.
>> Thanks.
>>
>>
>>>
Thanks.
>>> Signed-off-by: Inki Dae
>>> Signed-off-by: Kyungmin Park
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 38
>>> +++---
>>> drivers/gpu/drm/exynos/exynos_drm_hdmi.h |4 +-
>>> drivers/gpu/drm/exynos/exynos_hdmi.c | 12
>>> drivers/gpu/drm/exynos/exynos_mixer.c|8 +++---
>>> 4 files changed, 31 insertions(+), 31 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>>> index 3fdf0b6..bced38e 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>>> @@ -64,7 +64,7 @@ static bool drm_hdmi_is_connected(struct device
>>> *dev)
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> if (hdmi_ops && hdmi_ops->is_connected)
>>> - return hdmi_ops->is_connected(ctx->hdmi_ctx->ctx);
>>> + return hdmi_ops->is_connected(ctx->hdmi_ctx->client);
>>> return false;
>>> }
>>> @@ -77,8 +77,8 @@ static int drm_hdmi_get_edid(struct device *dev,
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> if (hdmi_ops && hdmi_ops->get_edid)
>>> - return hdmi_ops->get_edid(ctx->hdmi_ctx->ctx,
>>> connector,
>>> edid,
>>> - len);
>>> + return hdmi_ops->get_edid(ctx->hdmi_ctx->client,
>>> connector,
>>> + edid, len);
>>> return 0;
>>> }
>>> @@ -90,7 +90,7 @@ static int drm_hdmi_check_timing(struct device *dev,
>>> void *timing)
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> if (hdmi_ops && hdmi_ops->check_timing)
>>> - return hdmi_ops->check_timing(ctx->hdmi_ctx->ctx,
>>> timing);
>>> + return hdmi_ops->check_timing(ctx->hdmi_ctx->client,
>>> timing);
>>> return 0;
>>> }
>>> @@ -102,7 +102,7 @@ static int drm_hdmi_power_on(struct device *dev,
>>> int
>>> mode)
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> if (hdmi_ops && hdmi_ops->power_on)
>>> - return hdmi_ops->power_on(ctx->hdmi_ctx->ctx, mode);
>>> + return hdmi_ops->power_on(ctx->hdmi_ctx->client,
>>> mode);
>>> return 0;
>>> }
>>> @@ -124,7 +124,7 @@ static int drm_hdmi_enable_vblank(struct device
>>> *subdrv_dev)
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> if (mixer_ops && mixer_ops->enable_vblank)
>>> - return mixer_ops->enable_vblank(ctx->mixer_ctx->ctx,
>>> + return
>>> mixer_ops->enable_vblank(ctx->mixer_ctx->client,
>>> manager->pipe);
>>> return 0;
>>> @@ -137,12 +137,12 @@ static void drm_hdmi_disable_vblank(struct
>>> device
>>> *subdrv_dev)
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> if (mixer_ops && mixer_ops->disable_vblank)
>>> - return mixer_ops->disable_vblank(ctx->mixer_ctx->ctx);
>>> + return
>>> mixer_ops->disable_vblank(ctx->mixer_ctx->client);
>>> }
>>>
Re: [RFC 0/5] Generic panel framework
Hi Tomi, On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote: > On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote: > > Hi Tomi, > > > > mipi-dbi-bus might not belong to include/video/panel/ though, as it can be > > used for non-panel devices (at least in theory). The future mipi-dsi-bus > > certainly will. > > They are both display busses. So while they could be used for anything, > I find it quite unlikely as there are much better alternatives for > generic bus needs. My point is that they could be used for display devices other than panels. This is especially true for DSI, as there are DSI to HDMI converters. Technically speaking that's also true for DBI, as DBI chips convert from DBI to DPI, but we can group both the DBI-to-DPI chip and the panel in a single panel object. > > Would you be able to send incremental patches on top of v2 to implement > > the solution you have in mind ? It would be neat if you could also > > implement mipi- dsi-bus for the OMAP DSS and test the code with a real > > device :-) > > Yes, I'd like to try this out on OMAP, both DBI and DSI. However, I fear > it'll be quite complex due to the dependencies all around we have in the > current driver. We're working on simplifying things so that it'll be > easier to try thing like the panel framework, though, so we're going in > the right direction. If you want the panel framework to support your use cases I'm afraid you will need to work on that ;-) > > > Generally about locks, if we define that panel ops may only be called > > > exclusively, does it simplify things? I think we can make such > > > requirements, as there should be only one display framework that handles > > > the panel. Then we don't need locking for things like enable/disable. > > > > Pushing locking to callers would indeed simplify panel drivers, but we > > need to make sure we won't need to expose a panel to several callers in > > the future. > > I have a feeling that would be a bad idea. > > Display related stuff are quite sensitive to any delays, so any extra > transactions over, say, DSI bus could cause a noticeable glitch on the > screen. I'm not sure what are all the possible ops that a panel can > offer, but I think all that affect the display or could cause delays > should be handled by one controlling entity (drm or such). The > controlling entity needs to handle locking anyway, so in that sense I > don't think it's an extra burden for it. > > The things that come to my mind that could possibly cause calls to the > panel outside drm: debugfs, sysfs, audio, backlight. Of those, I think > backlight should go through drm. Audio, no idea. debugfs and sysfs > locking needs to be handled by the panel driver, and they are a bit > problematic as I guess having them requires full locking. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: init lockup timeout on ring init
On Mon, 2012-08-20 at 15:38 +0200, Christian K?nig wrote:
> Reset the lockup timeout on ring (re-)initialisation.
>
> Otherwise we get error messages like this on gpu resets:
> [ 1559.949177] radeon :01:00.0: GPU lockup CP stall for more than
> 1482270msec
>
> Signed-off-by: Christian K?nig
> cc: stable at kernel.org
> ---
> drivers/gpu/drm/radeon/radeon_ring.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
> b/drivers/gpu/drm/radeon/radeon_ring.c
> index ec79b37..43c431a 100644
> --- a/drivers/gpu/drm/radeon/radeon_ring.c
> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
> @@ -706,6 +706,7 @@ int radeon_ring_init(struct radeon_device *rdev, struct
> radeon_ring *ring, unsig
> if (radeon_debugfs_ring_init(rdev, ring)) {
> DRM_ERROR("Failed to register debugfs file for rings !\n");
> }
> + radeon_ring_lockup_update(ring);
> return 0;
> }
Reviewed-by: Michel D?nzer
--
Earthling Michel D?nzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
[PATCH 3/3] drm/mgag200: remove unused validate_sequence
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/mgag200/mgag200_drv.h |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 6f13b35..d22cbbf 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -195,7 +195,6 @@ struct mga_device {
struct drm_global_reference mem_global_ref;
struct ttm_bo_global_ref bo_global_ref;
struct ttm_bo_device bdev;
- atomic_t validate_sequence;
} ttm;
u32 reg_1e24; /* SE model number */
[PATCH 2/3] drm/cirrus: Remove unused validate_sequence
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/cirrus/cirrus_drv.h |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h
b/drivers/gpu/drm/cirrus/cirrus_drv.h
index 64ea597..5d04564 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.h
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
@@ -143,7 +143,6 @@ struct cirrus_device {
struct drm_global_reference mem_global_ref;
struct ttm_bo_global_ref bo_global_ref;
struct ttm_bo_device bdev;
- atomic_t validate_sequence;
} ttm;
bool mm_inited;
};
[PATCH 1/3] drm/ast: remove unused validate_sequence
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/ast/ast_drv.h |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index d4af9ed..20a437f 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -94,7 +94,6 @@ struct ast_private {
struct drm_global_reference mem_global_ref;
struct ttm_bo_global_ref bo_global_ref;
struct ttm_bo_device bdev;
- atomic_t validate_sequence;
} ttm;
struct drm_gem_object *cursor_cache;
[Bug 33912] [RV515] Kernel .35 onwards, Random X freezes while scrolling
https://bugzilla.kernel.org/show_bug.cgi?id=33912 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||OBSOLETE -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
Re: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On 08/19/2012 10:22 PM, Dave Airlie wrote: > On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap wrote: >> On 08/17/12 15:55, Dave Airlie wrote: >> >>> On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote: On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap wrote: > On 08/17/2012 03:25 PM, Justin M. Forbes wrote: > >> for , we have verified cases on inteldrmfb, radeondrmfb, and >> cirrusdrmfb. >> >> This is the last message displayed before the system hangs. This seems >> to be hitting a large number of users in Fedora, though certainly not >> everyone. This started happening with the 3.5 updates, and is still an >> issue. It appears to be a race condition, because various things have >> allowed boot to continue for some users, though there is no clear work >> around. Has anyone else run across this? Any ideas. For more >> background we have the following bugs: >> >> inteldrmfb: >> https://bugzilla.redhat.com/show_bug.cgi?id=843826 >> >> radeondrmfb: >> https://bugzilla.redhat.com/show_bug.cgi?id=845745 >> >> cirrusdrmfb : >> https://bugzilla.redhat.com/show_bug.cgi?id=843860 >> >> It should be noted that the conflicting fb hw usage message is not new, >> it has been around for a while, but this is the last message seen before >> the hang. > > > Hi, (adding dri-devel mailing list) > > > I started seeing this problem on 3.5-rc6. > > AFAICT, the system is not actually hung, it's just that no output > is showing up on the real (physical) output device (display) -- it's > going somewhere else (or to the bit bucket). > Can we bisect this at all? >> >> I guess I'll have to try again. My first attempt did not >> prove anything, I think because the conflict does not happen >> 100% of the time (i.e., it feels like a timing problem). >> I worry the intel one will bisect to where we moved the conflict resolution earlier, but I'd like to see if applying that patch earlier causes the issue, since radeon has it. >> >> Do you know of a specific commit that I could revert and test? > > 9f846a16d213523fbe6daea17e20df6b8ac5a1e5 > > might work, but it just changes the timing mostly. > > also testing 3.4 with that on top would be good. That commit doesn't apply cleanly to 3.4, but reverting it on 3.5-rc6 (where I first saw the problem) allows me to boot 3.5-rc6 multiple times without a problem. Maybe Justin can get more stable testing done also.. thanks, -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/13] drm/exynos: changed context name of hdmi and mixer
2012/8/20 Joonyoung Shim :
> On 08/20/2012 03:17 PM, InKi Dae wrote:
>>
>> 2012/8/20 Joonyoung Shim :
>>>
>>> On 08/20/2012 11:29 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim :
>
> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>
>> this patch changes ctx variable name in exynos_drm_hdmi_context
>> structure to client because the use of ctx variable makes it confused.
>
>
> I don't prefer "client" name. This is not client and server
> relationship.
>
Okay, give me your opinion. which one do you prefer?
>>>
>>>
>>> Just "data".
>>>
>> It's not clear. "data" is so comprehensive just use "child_ctx". we
>> already use "parent_ctx" as the context of exynos_drm_hdmi module.
>
>
> Actually, i prefer "data" term than "ctx" term. Anyway i want to focus
> why this problem is occurred because i think that codes are some ugly. I
> think we first need to consider to solve this situation using code
> redesign, structure change and etc.
>
calm down and focus on the use of term. this is so minor and this is
not related to design issue.
> Thanks.
>
>
>>
>>> Thanks.
>>>
>>>
>> Signed-off-by: Inki Dae
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 38
>> +++---
>> drivers/gpu/drm/exynos/exynos_drm_hdmi.h |4 +-
>> drivers/gpu/drm/exynos/exynos_hdmi.c | 12
>> drivers/gpu/drm/exynos/exynos_mixer.c|8 +++---
>> 4 files changed, 31 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> index 3fdf0b6..bced38e 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> @@ -64,7 +64,7 @@ static bool drm_hdmi_is_connected(struct device
>> *dev)
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> if (hdmi_ops && hdmi_ops->is_connected)
>> - return hdmi_ops->is_connected(ctx->hdmi_ctx->ctx);
>> + return hdmi_ops->is_connected(ctx->hdmi_ctx->client);
>> return false;
>> }
>> @@ -77,8 +77,8 @@ static int drm_hdmi_get_edid(struct device *dev,
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> if (hdmi_ops && hdmi_ops->get_edid)
>> - return hdmi_ops->get_edid(ctx->hdmi_ctx->ctx,
>> connector,
>> edid,
>> - len);
>> + return hdmi_ops->get_edid(ctx->hdmi_ctx->client,
>> connector,
>> + edid, len);
>> return 0;
>> }
>> @@ -90,7 +90,7 @@ static int drm_hdmi_check_timing(struct device *dev,
>> void *timing)
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> if (hdmi_ops && hdmi_ops->check_timing)
>> - return hdmi_ops->check_timing(ctx->hdmi_ctx->ctx,
>> timing);
>> + return hdmi_ops->check_timing(ctx->hdmi_ctx->client,
>> timing);
>> return 0;
>> }
>> @@ -102,7 +102,7 @@ static int drm_hdmi_power_on(struct device *dev,
>> int
>> mode)
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> if (hdmi_ops && hdmi_ops->power_on)
>> - return hdmi_ops->power_on(ctx->hdmi_ctx->ctx, mode);
>> + return hdmi_ops->power_on(ctx->hdmi_ctx->client,
>> mode);
>> return 0;
>> }
>> @@ -124,7 +124,7 @@ static int drm_hdmi_enable_vblank(struct device
>> *subdrv_dev)
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> if (mixer_ops && mixer_ops->enable_vblank)
>> - return mixer_ops->enable_vblank(ctx->mixer_ctx->ctx,
>> + return
>> mixer_ops->enable_vblank(ctx->mixer_ctx->client,
>> manager->pipe);
>> return 0;
>> @@ -137,12 +137,12 @@ static void drm_hdmi_disable_vblank(struct
>> device
>> *subdrv_dev)
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> if (mixer_ops && mixer_ops->disable_vblank)
>> - return mixer_ops->disable_vblank(ctx->mixer_ctx->ctx);
>> + return
>> mixer_ops->disable_vblank(ctx->mixer_ctx->client);
>> }
>> static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
>> struct drm_connector *connector,
>> - const struct drm_display_mode *mode,
>> + struct drm_display_mode *mode,
>> struct drm_display_mode
>> *adjusted_mode)
>> {
>> struct drm_hdmi_context *ctx = to_context(subdrv_dev);
>> @@ -150,7 +150,7 @@ static void drm_hdmi_mode_fixup(struct device
>> *subdrv_dev,
>>
[Bug 33512] radeon: lots of time spent in atombios_crtc_disable
https://bugzilla.kernel.org/show_bug.cgi?id=33512 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||OBSOLETE -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On 08/19/2012 10:22 PM, Dave Airlie wrote: > On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap wrote: >> On 08/17/12 15:55, Dave Airlie wrote: >> >>> On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote: On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap wrote: > On 08/17/2012 03:25 PM, Justin M. Forbes wrote: > >> for , we have verified cases on inteldrmfb, radeondrmfb, and >> cirrusdrmfb. >> >> This is the last message displayed before the system hangs. This seems >> to be hitting a large number of users in Fedora, though certainly not >> everyone. This started happening with the 3.5 updates, and is still an >> issue. It appears to be a race condition, because various things have >> allowed boot to continue for some users, though there is no clear work >> around. Has anyone else run across this? Any ideas. For more >> background we have the following bugs: >> >> inteldrmfb: >> https://bugzilla.redhat.com/show_bug.cgi?id=843826 >> >> radeondrmfb: >> https://bugzilla.redhat.com/show_bug.cgi?id=845745 >> >> cirrusdrmfb : >> https://bugzilla.redhat.com/show_bug.cgi?id=843860 >> >> It should be noted that the conflicting fb hw usage message is not new, >> it has been around for a while, but this is the last message seen before >> the hang. > > > Hi, (adding dri-devel mailing list) > > > I started seeing this problem on 3.5-rc6. > > AFAICT, the system is not actually hung, it's just that no output > is showing up on the real (physical) output device (display) -- it's > going somewhere else (or to the bit bucket). > Can we bisect this at all? >> >> I guess I'll have to try again. My first attempt did not >> prove anything, I think because the conflict does not happen >> 100% of the time (i.e., it feels like a timing problem). >> I worry the intel one will bisect to where we moved the conflict resolution earlier, but I'd like to see if applying that patch earlier causes the issue, since radeon has it. >> >> Do you know of a specific commit that I could revert and test? > > 9f846a16d213523fbe6daea17e20df6b8ac5a1e5 > > might work, but it just changes the timing mostly. > > also testing 3.4 with that on top would be good. That commit doesn't apply cleanly to 3.4, but reverting it on 3.5-rc6 (where I first saw the problem) allows me to boot 3.5-rc6 multiple times without a problem. Maybe Justin can get more stable testing done also.. thanks, -- ~Randy
[PATCH] drm: stop vmgfx driver explosion
From: Alan Cox If you do a page flip with no flags set then event is NULL. If event is NULL then the vmw_gfx driver likes to go digging into NULL and extracts NULL->base.file_priv. On a modern kernel with NULL mapping protection it's just another oops, without it there are some "intriguing" possibilities. What it should do is an open question but that for the driver owners to sort out. Signed-off-by: Alan Cox --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index 6b0078f..c50724b 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c @@ -1688,15 +1688,19 @@ int vmw_du_page_flip(struct drm_crtc *crtc, struct vmw_private *dev_priv = vmw_priv(crtc->dev); struct drm_framebuffer *old_fb = crtc->fb; struct vmw_framebuffer *vfb = vmw_framebuffer_to_vfb(fb); - struct drm_file *file_priv = event->base.file_priv; + struct drm_file *file_priv ; struct vmw_fence_obj *fence = NULL; struct drm_clip_rect clips; int ret; + if (event == NULL) + return -EINVAL; + /* require ScreenObject support for page flipping */ if (!dev_priv->sou_priv) return -ENOSYS; + file_priv = event->base.file_priv; if (!vmw_kms_screen_object_flippable(dev_priv, crtc)) return -EINVAL;
[PATCH] drm/ttm: remove EBUSY handling in ttm_execbuf_util
How is this different from just calling with no_wait == false?
As far as I can tell, both paths end up with the same result..
Signed-off-by: Maarten Lankhorst
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 3f48a46..4e7b596 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -82,22 +82,6 @@ static void ttm_eu_list_ref_sub(struct list_head *list)
}
}
-static int ttm_eu_wait_unreserved_locked(struct list_head *list,
-struct ttm_buffer_object *bo)
-{
- struct ttm_bo_global *glob = bo->glob;
- int ret;
-
- ttm_eu_del_from_lru_locked(list);
- spin_unlock(&glob->lru_lock);
- ret = ttm_bo_wait_unreserved(bo, true);
- spin_lock(&glob->lru_lock);
- if (unlikely(ret != 0))
- ttm_eu_backoff_reservation_locked(list);
- return ret;
-}
-
-
void ttm_eu_backoff_reservation(struct list_head *list)
{
struct ttm_validate_buffer *entry;
@@ -152,19 +136,10 @@ retry:
list_for_each_entry(entry, list, head) {
struct ttm_buffer_object *bo = entry->bo;
-retry_this_bo:
- ret = ttm_bo_reserve_locked(bo, true, true, true, val_seq);
+ ret = ttm_bo_reserve_locked(bo, true, false, true, val_seq);
switch (ret) {
case 0:
break;
- case -EBUSY:
- ret = ttm_eu_wait_unreserved_locked(list, bo);
- if (unlikely(ret != 0)) {
- spin_unlock(&glob->lru_lock);
- ttm_eu_list_ref_sub(list);
- return ret;
- }
- goto retry_this_bo;
case -EAGAIN:
ttm_eu_backoff_reservation_locked(list);
spin_unlock(&glob->lru_lock);
[PATCH] drm/radeon: init lockup timeout on ring init
Reset the lockup timeout on ring (re-)initialisation.
Otherwise we get error messages like this on gpu resets:
[ 1559.949177] radeon :01:00.0: GPU lockup CP stall for more than
1482270msec
Signed-off-by: Christian K?nig
cc: stable at kernel.org
---
drivers/gpu/drm/radeon/radeon_ring.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index ec79b37..43c431a 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -706,6 +706,7 @@ int radeon_ring_init(struct radeon_device *rdev, struct
radeon_ring *ring, unsig
if (radeon_debugfs_ring_init(rdev, ring)) {
DRM_ERROR("Failed to register debugfs file for rings !\n");
}
+ radeon_ring_lockup_update(ring);
return 0;
}
--
1.7.9.5
[PATCH 11/13] drm/exynos: changed context name of hdmi and mixer
On 08/20/2012 03:17 PM, InKi Dae wrote:
> 2012/8/20 Joonyoung Shim :
>> On 08/20/2012 11:29 AM, InKi Dae wrote:
>>> 2012/8/20 Joonyoung Shim :
On 08/17/2012 06:50 PM, Inki Dae wrote:
> this patch changes ctx variable name in exynos_drm_hdmi_context
> structure to client because the use of ctx variable makes it confused.
I don't prefer "client" name. This is not client and server relationship.
>>> Okay, give me your opinion. which one do you prefer?
>>
>> Just "data".
>>
> It's not clear. "data" is so comprehensive just use "child_ctx". we
> already use "parent_ctx" as the context of exynos_drm_hdmi module.
Actually, i prefer "data" term than "ctx" term. Anyway i want to focus
why this problem is occurred because i think that codes are some ugly. I
think we first need to consider to solve this situation using code
redesign, structure change and etc.
Thanks.
>
>> Thanks.
>>
>>
> Signed-off-by: Inki Dae
> Signed-off-by: Kyungmin Park
> ---
> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 38
> +++---
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h |4 +-
> drivers/gpu/drm/exynos/exynos_hdmi.c | 12
> drivers/gpu/drm/exynos/exynos_mixer.c|8 +++---
> 4 files changed, 31 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> index 3fdf0b6..bced38e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> @@ -64,7 +64,7 @@ static bool drm_hdmi_is_connected(struct device *dev)
> DRM_DEBUG_KMS("%s\n", __FILE__);
> if (hdmi_ops && hdmi_ops->is_connected)
> - return hdmi_ops->is_connected(ctx->hdmi_ctx->ctx);
> + return hdmi_ops->is_connected(ctx->hdmi_ctx->client);
> return false;
> }
> @@ -77,8 +77,8 @@ static int drm_hdmi_get_edid(struct device *dev,
> DRM_DEBUG_KMS("%s\n", __FILE__);
> if (hdmi_ops && hdmi_ops->get_edid)
> - return hdmi_ops->get_edid(ctx->hdmi_ctx->ctx, connector,
> edid,
> - len);
> + return hdmi_ops->get_edid(ctx->hdmi_ctx->client,
> connector,
> + edid, len);
> return 0;
> }
> @@ -90,7 +90,7 @@ static int drm_hdmi_check_timing(struct device *dev,
> void *timing)
> DRM_DEBUG_KMS("%s\n", __FILE__);
> if (hdmi_ops && hdmi_ops->check_timing)
> - return hdmi_ops->check_timing(ctx->hdmi_ctx->ctx,
> timing);
> + return hdmi_ops->check_timing(ctx->hdmi_ctx->client,
> timing);
> return 0;
> }
> @@ -102,7 +102,7 @@ static int drm_hdmi_power_on(struct device *dev, int
> mode)
> DRM_DEBUG_KMS("%s\n", __FILE__);
> if (hdmi_ops && hdmi_ops->power_on)
> - return hdmi_ops->power_on(ctx->hdmi_ctx->ctx, mode);
> + return hdmi_ops->power_on(ctx->hdmi_ctx->client, mode);
> return 0;
> }
> @@ -124,7 +124,7 @@ static int drm_hdmi_enable_vblank(struct device
> *subdrv_dev)
> DRM_DEBUG_KMS("%s\n", __FILE__);
> if (mixer_ops && mixer_ops->enable_vblank)
> - return mixer_ops->enable_vblank(ctx->mixer_ctx->ctx,
> + return mixer_ops->enable_vblank(ctx->mixer_ctx->client,
> manager->pipe);
> return 0;
> @@ -137,12 +137,12 @@ static void drm_hdmi_disable_vblank(struct device
> *subdrv_dev)
> DRM_DEBUG_KMS("%s\n", __FILE__);
> if (mixer_ops && mixer_ops->disable_vblank)
> - return mixer_ops->disable_vblank(ctx->mixer_ctx->ctx);
> + return
> mixer_ops->disable_vblank(ctx->mixer_ctx->client);
> }
> static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
> struct drm_connector *connector,
> - const struct drm_display_mode *mode,
> + struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode)
> {
> struct drm_hdmi_context *ctx = to_context(subdrv_dev);
> @@ -150,7 +150,7 @@ static void drm_hdmi_mode_fixup(struct device
> *subdrv_dev,
> DRM_DEBUG_KMS("%s\n", __FILE__);
> if (hdmi_ops && hdmi_ops->mode_fixup)
> - hdmi_ops->mode_fixup(ctx->hdmi_ctx->ctx, connector,
> mode,
> + hdmi_ops->mode_fixup(ctx->hdmi_ctx->client, connector,
> mode,
>adjusted_mode)
drm/ttm: Remove cpu_writers related code
Nobody uses it, so might as well simplify the code some.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 36f4b28..ddfe393 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -141,7 +141,6 @@ static void ttm_bo_release_list(struct kref *list_kref)
BUG_ON(atomic_read(&bo->list_kref.refcount));
BUG_ON(atomic_read(&bo->kref.refcount));
- BUG_ON(atomic_read(&bo->cpu_writers));
BUG_ON(bo->sync_obj != NULL);
BUG_ON(bo->mem.mm_node != NULL);
BUG_ON(!list_empty(&bo->lru));
@@ -1050,16 +1049,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_mem_space);
-int ttm_bo_wait_cpu(struct ttm_buffer_object *bo, bool no_wait)
-{
- if ((atomic_read(&bo->cpu_writers) > 0) && no_wait)
- return -EBUSY;
-
- return wait_event_interruptible(bo->event_queue,
- atomic_read(&bo->cpu_writers) == 0);
-}
-EXPORT_SYMBOL(ttm_bo_wait_cpu);
-
int ttm_bo_move_buffer(struct ttm_buffer_object *bo,
struct ttm_placement *placement,
bool interruptible, bool no_wait_reserve,
@@ -1211,7 +1200,6 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
kref_init(&bo->kref);
kref_init(&bo->list_kref);
- atomic_set(&bo->cpu_writers, 0);
atomic_set(&bo->reserved, 1);
init_waitqueue_head(&bo->event_queue);
INIT_LIST_HEAD(&bo->lru);
@@ -1769,35 +1757,6 @@ int ttm_bo_wait(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_wait);
-int ttm_bo_synccpu_write_grab(struct ttm_buffer_object *bo, bool no_wait)
-{
- struct ttm_bo_device *bdev = bo->bdev;
- int ret = 0;
-
- /*
-* Using ttm_bo_reserve makes sure the lru lists are updated.
-*/
-
- ret = ttm_bo_reserve(bo, true, no_wait, false, 0);
- if (unlikely(ret != 0))
- return ret;
- spin_lock(&bdev->fence_lock);
- ret = ttm_bo_wait(bo, false, true, no_wait);
- spin_unlock(&bdev->fence_lock);
- if (likely(ret == 0))
- atomic_inc(&bo->cpu_writers);
- ttm_bo_unreserve(bo);
- return ret;
-}
-EXPORT_SYMBOL(ttm_bo_synccpu_write_grab);
-
-void ttm_bo_synccpu_write_release(struct ttm_buffer_object *bo)
-{
- if (atomic_dec_and_test(&bo->cpu_writers))
- wake_up_all(&bo->event_queue);
-}
-EXPORT_SYMBOL(ttm_bo_synccpu_write_release);
-
/**
* A buffer object shrink method that tries to swap out the first
* buffer object on the bo_global::swap_lru list.
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index f8187ea..626a3f6 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -439,7 +439,6 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
INIT_LIST_HEAD(&fbo->swap);
INIT_LIST_HEAD(&fbo->io_reserve_lru);
fbo->vm_node = NULL;
- atomic_set(&fbo->cpu_writers, 0);
fbo->sync_obj = driver->sync_obj_ref(bo->sync_obj);
kref_init(&fbo->list_kref);
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 3832fe1..3f48a46 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -181,15 +181,6 @@ retry_this_bo:
}
entry->reserved = true;
- if (unlikely(atomic_read(&bo->cpu_writers) > 0)) {
- ttm_eu_backoff_reservation_locked(list);
- spin_unlock(&glob->lru_lock);
- ttm_eu_list_ref_sub(list);
- ret = ttm_bo_wait_cpu(bo, false);
- if (ret)
- return ret;
- goto retry;
- }
}
ttm_eu_del_from_lru_locked(list);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index e15f2a8..0853162 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -225,12 +225,6 @@ struct ttm_buffer_object {
bool evicted;
/**
-* Members protected by the bo::reserved lock only when written to.
-*/
-
- atomic_t cpu_writers;
-
- /**
* Members protected by the bdev::lru_lock.
*/
@@ -423,31 +417,6 @@ extern void ttm_bo_unlock_delayed_workqueue(struct
ttm_bo_device *bdev,
int resched);
/**
- * ttm_bo_synccpu_write_grab
- *
- * @bo: The buffer object:
- * @no_wait: Return immediately if buffer is busy.
- *
- * Synchronizes a buffer object for CPU RW access. This means
- * blocking command submission that affects the buffer and
- * waiting for buffer idle. This lock is recursive.
- * Returns
- * -EBUSY if the buffer is busy and no_wait is true.
- * -ERESTARTSYS if interrupted by a signal.
- */
-extern int
-ttm_b
[Bug 32162] GPU lockup with RV350, KMS, Compiz, Pageflipping
https://bugzilla.kernel.org/show_bug.cgi?id=32162 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #6 from Alex Deucher 2012-08-20 15:29:25 --- Is this still an issue with a newer kernel? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 32162] GPU lockup with RV350, KMS, Compiz, Pageflipping
https://bugzilla.kernel.org/show_bug.cgi?id=32162 Alan changed: What|Removed |Added Component|Video(AGP) |Video(DRI - non Intel) AssignedTo|airlied at linux.ie|drivers_video-dri at kernel-bu ||gs.osdl.org -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap wrote: > On 08/17/12 15:55, Dave Airlie wrote: > >> On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote: >>> On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap >>> wrote: On 08/17/2012 03:25 PM, Justin M. Forbes wrote: > for , we have verified cases on inteldrmfb, radeondrmfb, and > cirrusdrmfb. > > This is the last message displayed before the system hangs. This seems > to be hitting a large number of users in Fedora, though certainly not > everyone. This started happening with the 3.5 updates, and is still an > issue. It appears to be a race condition, because various things have > allowed boot to continue for some users, though there is no clear work > around. Has anyone else run across this? Any ideas. For more > background we have the following bugs: > > inteldrmfb: > https://bugzilla.redhat.com/show_bug.cgi?id=843826 > > radeondrmfb: > https://bugzilla.redhat.com/show_bug.cgi?id=845745 > > cirrusdrmfb : > https://bugzilla.redhat.com/show_bug.cgi?id=843860 > > It should be noted that the conflicting fb hw usage message is not new, > it has been around for a while, but this is the last message seen before > the hang. Hi, (adding dri-devel mailing list) I started seeing this problem on 3.5-rc6. AFAICT, the system is not actually hung, it's just that no output is showing up on the real (physical) output device (display) -- it's going somewhere else (or to the bit bucket). >>> >>> Can we bisect this at all? > > I guess I'll have to try again. My first attempt did not > prove anything, I think because the conflict does not happen > 100% of the time (i.e., it feels like a timing problem). > >>> I worry the intel one will bisect to where we moved the conflict >>> resolution earlier, but I'd like to see if applying that patch earlier >>> causes the issue, since radeon has it. > > Do you know of a specific commit that I could revert and test? 9f846a16d213523fbe6daea17e20df6b8ac5a1e5 might work, but it just changes the timing mostly. also testing 3.4 with that on top would be good. Dave.
[Bug 32072] 2.6.38 Regression: Nvidia GeForce8400 + i915 = Crash on Boot
https://bugzilla.kernel.org/show_bug.cgi?id=32072 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||INSUFFICIENT_DATA -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 31972] 2.6.38.1: radeon hd 6870: kms, hdmi, signal is correct only for 1-2 seconds
https://bugzilla.kernel.org/show_bug.cgi?id=31972 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||OBSOLETE --- Comment #4 from Alan 2012-08-20 15:18:17 --- If this is still seen with modern kernels please reopen/update thanks -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH 11/13] drm/exynos: changed context name of hdmi and mixer
2012/8/20 Joonyoung Shim :
> On 08/20/2012 11:29 AM, InKi Dae wrote:
>>
>> 2012/8/20 Joonyoung Shim :
>>>
>>> On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch changes ctx variable name in exynos_drm_hdmi_context
structure to client because the use of ctx variable makes it confused.
>>>
>>>
>>> I don't prefer "client" name. This is not client and server relationship.
>>>
>> Okay, give me your opinion. which one do you prefer?
>
>
> Just "data".
>
It's not clear. "data" is so comprehensive just use "child_ctx". we
already use "parent_ctx" as the context of exynos_drm_hdmi module.
> Thanks.
>
>
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 38
+++---
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |4 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 12
drivers/gpu/drm/exynos/exynos_mixer.c|8 +++---
4 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 3fdf0b6..bced38e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -64,7 +64,7 @@ static bool drm_hdmi_is_connected(struct device *dev)
DRM_DEBUG_KMS("%s\n", __FILE__);
if (hdmi_ops && hdmi_ops->is_connected)
- return hdmi_ops->is_connected(ctx->hdmi_ctx->ctx);
+ return hdmi_ops->is_connected(ctx->hdmi_ctx->client);
return false;
}
@@ -77,8 +77,8 @@ static int drm_hdmi_get_edid(struct device *dev,
DRM_DEBUG_KMS("%s\n", __FILE__);
if (hdmi_ops && hdmi_ops->get_edid)
- return hdmi_ops->get_edid(ctx->hdmi_ctx->ctx, connector,
edid,
- len);
+ return hdmi_ops->get_edid(ctx->hdmi_ctx->client,
connector,
+ edid, len);
return 0;
}
@@ -90,7 +90,7 @@ static int drm_hdmi_check_timing(struct device *dev,
void *timing)
DRM_DEBUG_KMS("%s\n", __FILE__);
if (hdmi_ops && hdmi_ops->check_timing)
- return hdmi_ops->check_timing(ctx->hdmi_ctx->ctx,
timing);
+ return hdmi_ops->check_timing(ctx->hdmi_ctx->client,
timing);
return 0;
}
@@ -102,7 +102,7 @@ static int drm_hdmi_power_on(struct device *dev, int
mode)
DRM_DEBUG_KMS("%s\n", __FILE__);
if (hdmi_ops && hdmi_ops->power_on)
- return hdmi_ops->power_on(ctx->hdmi_ctx->ctx, mode);
+ return hdmi_ops->power_on(ctx->hdmi_ctx->client, mode);
return 0;
}
@@ -124,7 +124,7 @@ static int drm_hdmi_enable_vblank(struct device
*subdrv_dev)
DRM_DEBUG_KMS("%s\n", __FILE__);
if (mixer_ops && mixer_ops->enable_vblank)
- return mixer_ops->enable_vblank(ctx->mixer_ctx->ctx,
+ return mixer_ops->enable_vblank(ctx->mixer_ctx->client,
manager->pipe);
return 0;
@@ -137,12 +137,12 @@ static void drm_hdmi_disable_vblank(struct device
*subdrv_dev)
DRM_DEBUG_KMS("%s\n", __FILE__);
if (mixer_ops && mixer_ops->disable_vblank)
- return mixer_ops->disable_vblank(ctx->mixer_ctx->ctx);
+ return
mixer_ops->disable_vblank(ctx->mixer_ctx->client);
}
static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
struct drm_connector *connector,
- const struct drm_display_mode *mode,
+ struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
struct drm_hdmi_context *ctx = to_context(subdrv_dev);
@@ -150,7 +150,7 @@ static void drm_hdmi_mode_fixup(struct device
*subdrv_dev,
DRM_DEBUG_KMS("%s\n", __FILE__);
if (hdmi_ops && hdmi_ops->mode_fixup)
- hdmi_ops->mode_fixup(ctx->hdmi_ctx->ctx, connector,
mode,
+ hdmi_ops->mode_fixup(ctx->hdmi_ctx->client, connector,
mode,
adjusted_mode);
}
@@ -161,7 +161,7 @@ static void drm_hdmi_mode_set(struct device
*subdrv_dev, void *mode)
DRM_DEBUG_KMS("%s\n", __FILE__);
if (hdmi_ops && hdmi_ops->mode_set)
- hdmi_ops->mode_set(ctx->hdmi_ctx->ctx, mode);
+ hdmi_ops->mode_set(ctx->hdmi_ctx->client, mode);
}
static void drm_hdmi_get_max_resol(struct device *s
[Bug 31892] Problems with nouveau on my HP laptop
https://bugzilla.kernel.org/show_bug.cgi?id=31892 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||OBSOLETE -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] drm/radeon/kms: extend the Fujitsu D3003-S2 board connector quirk to cover later silicon stepping
There is a more recent APU stepping with a new PCI ID
shipping in the same board by Fujitsu which needs the
same quirk to correctly mark the back plane connectors.
Signed-off-by: Tvrtko Ursulin
---
radeon_atombios.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index f9c21f9..d67d4f3 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -452,7 +452,7 @@ static bool radeon_atom_apply_quirks(struct drm_device *dev,
}
/* Fujitsu D3003-S2 board lists DVI-I as DVI-D and VGA */
- if ((dev->pdev->device == 0x9802) &&
+ if (((dev->pdev->device == 0x9802) || (dev->pdev->device == 0x9806)) &&
(dev->pdev->subsystem_vendor == 0x1734) &&
(dev->pdev->subsystem_device == 0x11bd)) {
if (*connector_type == DRM_MODE_CONNECTOR_VGA) {
[Bug 31712] GPU lockup CP stall after resume from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=31712 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||OBSOLETE -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 31682] Radeon console output very slow with kms
https://bugzilla.kernel.org/show_bug.cgi?id=31682 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||OBSOLETE --- Comment #5 from Alan 2012-08-20 15:13:08 --- (or use the GART like GMA50 ...) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 31502] Not possible to use KMS with Radeon 9200 anymore
https://bugzilla.kernel.org/show_bug.cgi?id=31502 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 from Alex Deucher 2012-08-20 15:12:02 --- Is this still an issue with newer kernels? If so, can you bisect? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 31502] Not possible to use KMS with Radeon 9200 anymore
https://bugzilla.kernel.org/show_bug.cgi?id=31502 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|Other |Video(DRI - non Intel) AssignedTo|other_other at kernel-bugs.osd |drivers_video-dri at kernel-bu |l.org |gs.osdl.org Product|Other |Drivers -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #16 from Alexandre Demers 2012-08-20 15:05:03 UTC --- (In reply to comment #15) > (In reply to comment #10) > > Well, it seems running it through qapitrace doesn't lock. > > The apitrace looks incomplete: it doesn't contain any actual rendering > operations. I'll rerun it at home tonight. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #15 from Michel D?nzer 2012-08-20 14:59:34 UTC --- (In reply to comment #10) > Well, it seems running it through qapitrace doesn't lock. The apitrace looks incomplete: it doesn't contain any actual rendering operations. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
make VM handling async v2
On Mon, Aug 20, 2012 at 4:08 AM, Christian K?nig wrote: > Second and hopefully last round for this patchset. > > v2: Fix suspend/resume, and incorporate Jeromes comments. Looks good to me. Can you put up a git branch somewhere? Reviewed-by: Alex Deucher > > Cheers, > Christian. > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30922] [radeon] Noisy fan with Radeon R600 and Toshiba Satellite L500-164
https://bugzilla.kernel.org/show_bug.cgi?id=30922 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||OBSOLETE -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 30812] radeon module fails to initialize with modeset=1 on PPC32 with RV280
https://bugzilla.kernel.org/show_bug.cgi?id=30812 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||OBSOLETE -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 46241] Resume to black screen on AMD A8-3500m/Radeon 6620G
https://bugzilla.kernel.org/show_bug.cgi?id=46241 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #6 from Alex Deucher 2012-08-20 14:46:28 --- Looks like a duplicate of: https://bugs.freedesktop.org/show_bug.cgi?id=43829 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH 09/13] drm/exynos: check NV12M format specific to Exynos properly
2012/8/20 Joonyoung Shim :
> On 08/20/2012 02:15 PM, InKi Dae wrote:
>>
>> sorry, again.
>>
>> 2012/8/20 InKi Dae :
>>>
>>> 2012/8/20 Joonyoung Shim :
On 08/20/2012 11:23 AM, InKi Dae wrote:
>
> 2012/8/20 Joonyoung Shim :
>>
>> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>>
>>> this patch adds buf_cnt variable in exynos_drm_fb structure and
>>> that means a buffer count to drm framebuffer and also adds two
>>> functions to get/set the buffer count from/to exynos_drm_fb
>>> structure.
>>> if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
>>> to drm framebuffer refering to mode_cmd->handles and offsets.
>>> but when booted, the buffer count will always be 1 because pixel
>>> format of console framebuffer is RGB format.
>>>
>>> Signed-off-by: Inki Dae
>>> Signed-off-by: Kyungmin Park
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_fb.c| 65
>>> +++-
>>> drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 +++--
>>> drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
>>> drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
>>> 4 files changed, 73 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>>> index 4ccfe43..2d1bc3a 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>>> @@ -41,10 +41,12 @@
>>> * exynos specific framebuffer structure.
>>> *
>>> * @fb: drm framebuffer obejct.
>>> + * @buf_cnt: a buffer count to drm framebuffer.
>>> * @exynos_gem_obj: array of exynos specific gem object
>>> containing a
>>> gem
>>> object.
>>> */
>>> struct exynos_drm_fb {
>>> struct drm_framebuffer fb;
>>> + unsigned intbuf_cnt;
>>> struct exynos_drm_gem_obj
>>> *exynos_gem_obj[MAX_FB_BUFFER];
>>> };
>>> @@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs
>>> exynos_drm_fb_funcs = {
>>> .dirty = exynos_drm_fb_dirty,
>>> };
>>> +void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
>>> + unsigned int cnt)
>>> +{
>>> + struct exynos_drm_fb *exynos_fb;
>>> +
>>> + exynos_fb = to_exynos_fb(fb);
>>> +
>>> + exynos_fb->buf_cnt = cnt;
>>> +}
>>> +
>>> +unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
>>> +{
>>> + struct exynos_drm_fb *exynos_fb;
>>> +
>>> + exynos_fb = to_exynos_fb(fb);
>>> +
>>> + return exynos_fb->buf_cnt;
>>> +}
>>> +
>>> struct drm_framebuffer *
>>> exynos_drm_framebuffer_init(struct drm_device *dev,
>>> struct drm_mode_fb_cmd2 *mode_cmd,
>>> @@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device
>>> *dev,
>>> return &exynos_fb->fb;
>>> }
>>> +static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2
>>> *mode_cmd)
>>> +{
>>> + unsigned int cnt = 0;
>>> +
>>> + if (mode_cmd->pixel_format == DRM_FORMAT_NV12MT)
>>> + return 2;
>>> +
>>> + while (cnt != MAX_FB_BUFFER) {
>>> + if (!mode_cmd->handles[cnt])
>>> + break;
>>> + cnt++;
>>> + }
>>> +
>>> + /*
>>> +* check if NV12 or NV12M.
>>> +*
>>> +* NV12
>>> +* handles[0] = base1, offsets[0] = 0
>>> +* handles[1] = base1, offsets[1] = Y_size
>>> +*
>>> +* NV12M
>>> +* handles[0] = base1, offsets[0] = 0
>>> +* handles[1] = base2, offsets[1] = 0
>>> +*/
>>> + if (cnt == 2) {
>>> + /*
>>> +* in case of NV12 format, offsets[1] is not 0 and
>>> +* handles[0] is same as handles[1].
>>> +*/
>>> + if (mode_cmd->offsets[1] &&
>>> + mode_cmd->handles[0] == mode_cmd->handles[1])
>>> + cnt = 1;
>>> + }
>>> +
>>> + return cnt;
>>> +}
>>
>>
>> No, please don't add specific function. There is already
>> drm_format_num_planes() function
>>
>>
> I know that, but NV12M format is specific to Exynos. for this, we
> already had a discussion and you can refer to below link,
> http://web.archiveorange.com/archive/v/hhSc5JAv767vo7fKZLPf
Yes, but this implementation is not clear, just get plane number using
drm_format_num_planes()
and check handle and offset argument when forma
[PATCH 02/13] drm/exynos: separated subdrv->probe call and encoder/connector creation.
2012/8/20 Joonyoung Shim :
> On 08/20/2012 01:31 PM, InKi Dae wrote:
>>
>> 2012/8/20 Joonyoung Shim :
>>>
>>> On 08/20/2012 10:52 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim :
>
> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>
>> this patch separates sub driver's probe call and encoder/connector
>> creation
>> so that exynos drm core module can take exception when some operation
>> was
>> failed properly.
>
>
> Which exceptions? I don't know this patch gives any benefit to us.
>
previous code didn't take exception when exynos_drm_encoder_create()
is falied.
>>>
>>>
>>> No, it is considered.
>>>
>> where is subdrv->remove() called when exynos_drm_encoder_create() is
>> failed? I think if failed then subdrv->remove() should be called and
>> if exynos_drm_connector_create() is failed then not only
>> encoder->funcs->destory() but also subdrv->remove()
>
>
> OK, but just add subdrv->remove(). Then if it needs, please split function.
>
now exynos_drm_subdrv_probe() creates encoder and connector so it
should be separated into meaningful parts.
>
and for now, exynos_drm_encoder/connector_create functions
was called at exynos_drm_subdrv_probe() so know that this patch is for
code clean by separating them into two parts also.
>>>
>>>
>>> It's ok, but it just splitting.
>>>
>>>
>> Signed-off-by: Inki Dae
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_core.c | 93
>> +-
>> 1 files changed, 65 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
>> b/drivers/gpu/drm/exynos/exynos_drm_core.c
>> index 84dd099..1c8d5fe 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
>> @@ -34,30 +34,15 @@
>> static LIST_HEAD(exynos_drm_subdrv_list);
>> -static int exynos_drm_subdrv_probe(struct drm_device *dev,
>> +static int exynos_drm_create_enc_conn(struct drm_device *dev,
>> struct exynos_drm_subdrv
>> *subdrv)
>> {
>> struct drm_encoder *encoder;
>> struct drm_connector *connector;
>> + int ret;
>> DRM_DEBUG_DRIVER("%s\n", __FILE__);
>> - if (subdrv->probe) {
>> - int ret;
>> -
>> - /*
>> -* this probe callback would be called by sub driver
>> -* after setting of all resources to this sub driver,
>> -* such as clock, irq and register map are done or by
>> load()
>> -* of exynos drm driver.
>> -*
>> -* P.S. note that this driver is considered for
>> modularization.
>> -*/
>> - ret = subdrv->probe(dev, subdrv->dev);
>> - if (ret)
>> - return ret;
>> - }
>> -
>> if (!subdrv->manager)
>> return 0;
>> @@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct
>> drm_device
>> *dev,
>> connector = exynos_drm_connector_create(dev, encoder);
>> if (!connector) {
>> DRM_ERROR("failed to create connector\n");
>> - encoder->funcs->destroy(encoder);
>> - return -EFAULT;
>> + ret = -EFAULT;
>> + goto err_destroy_encoder;
>> }
>> subdrv->encoder = encoder;
>> subdrv->connector = connector;
>> return 0;
>> +
>> +err_destroy_encoder:
>> + encoder->funcs->destroy(encoder);
>> + return ret;
>> }
>> -static void exynos_drm_subdrv_remove(struct drm_device *dev,
>> - struct exynos_drm_subdrv
>> *subdrv)
>> +static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv
>> *subdrv)
>> {
>> - DRM_DEBUG_DRIVER("%s\n", __FILE__);
>> -
>> - if (subdrv->remove)
>> - subdrv->remove(dev);
>> -
>> if (subdrv->encoder) {
>> struct drm_encoder *encoder = subdrv->encoder;
>> encoder->funcs->destroy(encoder);
>> @@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct
>> drm_device
>> *dev,
>> }
>> }
>> +static int exynos_drm_subdrv_probe(struct drm_device *dev,
>> + struct exynos_drm_subdrv
>> *subdrv)
>> +{
>> + if (subdrv->probe) {
>> + int ret;
>> +
>> + subdrv->drm_dev = dev;
>> +
>> + /*
>> +* this probe callback would be called by sub driver
>>
[Bug 46241] Resume to black screen on AMD A8-3500m/Radeon 6620G
https://bugzilla.kernel.org/show_bug.cgi?id=46241 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Kernel Version|Linux version |3.6 |3.6.0-030600rc1-generic | |(apw at gomeisa) (gcc version | |4.6.3 (Ubuntu/Linaro| |4.6.3-1ubuntu5) ) | |#201208022056 SMP Fri Aug 3 | |00:57:36 UTC 2012 | -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[RFC 0/5] Generic panel framework
On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote: > Hi Tomi, > mipi-dbi-bus might not belong to include/video/panel/ though, as it can be > used for non-panel devices (at least in theory). The future mipi-dsi-bus > certainly will. They are both display busses. So while they could be used for anything, I find it quite unlikely as there are much better alternatives for generic bus needs. > Would you be able to send incremental patches on top of v2 to implement the > solution you have in mind ? It would be neat if you could also implement mipi- > dsi-bus for the OMAP DSS and test the code with a real device :-) Yes, I'd like to try this out on OMAP, both DBI and DSI. However, I fear it'll be quite complex due to the dependencies all around we have in the current driver. We're working on simplifying things so that it'll be easier to try thing like the panel framework, though, so we're going in the right direction. > > Generally about locks, if we define that panel ops may only be called > > exclusively, does it simplify things? I think we can make such > > requirements, as there should be only one display framework that handles > > the panel. Then we don't need locking for things like enable/disable. > > Pushing locking to callers would indeed simplify panel drivers, but we need > to > make sure we won't need to expose a panel to several callers in the future. I have a feeling that would be a bad idea. Display related stuff are quite sensitive to any delays, so any extra transactions over, say, DSI bus could cause a noticeable glitch on the screen. I'm not sure what are all the possible ops that a panel can offer, but I think all that affect the display or could cause delays should be handled by one controlling entity (drm or such). The controlling entity needs to handle locking anyway, so in that sense I don't think it's an extra burden for it. The things that come to my mind that could possibly cause calls to the panel outside drm: debugfs, sysfs, audio, backlight. Of those, I think backlight should go through drm. Audio, no idea. debugfs and sysfs locking needs to be handled by the panel driver, and they are a bit problematic as I guess having them requires full locking. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120820/02d5305e/attachment.pgp>
[PATCH] drm/radeon: fix checking of MSAA renderbuffers on r600-r700
On Mon, Aug 20, 2012 at 7:35 AM, Paul Menzel wrote: > Dear Marek, > > > thank you for all your work on MSAA. > > > Am Sonntag, den 19.08.2012, 21:23 +0200 schrieb Marek Ol??k: > > Unfortunately you do not provide any commit message. What is the problem > and what are the symptoms? When was it introduced? How is it solved in > your patch? The MSAA checking was mostly unimplemented on r600-r700. The userspace submits GPU commands and the kernel driver computes how much memory the GPU will access and checks if it's all within buffer bounds the userspace allocated. This patch fixes the computations of the size of MSAA surfaces in memory. Marek
radeon testing
On Thu, Aug 16, 2012 at 11:51:10AM -0400, Alex Deucher wrote: > I've gathered up the various outstanding radeon patches and put them > up in a tree for testing: > http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip > Some of these may end up in -fixes, but most of them are -next > material. I haven't had a chance to go through Christian's last set > of VM patches yet. > > Highlights: > - rom fetch fixes (UEFI, thunderbolt docks) > - major ACPI rework > - backlight control for newer asics Hi Alex, I just tested the rebased acpi_patches branch: ACPI part works fine, but I see a big slow down during radeon driver initialization when the screen goes black for a couple of seconds (with 3.5.0 + acpi patches the screen just flickers during boot). With initcall_debug I see: [2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552 ... [5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 3102147 usecs For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not very informative, I'll try and get more info... Luca -- next part -- [0.00] BIOS-e820: [mem 0xaa99f000-0xaf2befff] usable [0.00] BIOS-e820: [mem 0xaf2bf000-0xaf6befff] reserved [0.00] BIOS-e820: [mem 0xaf6bf000-0xaf7befff] ACPI NVS [0.00] BIOS-e820: [mem 0xaf7bf000-0xaf7fefff] ACPI data [0.00] BIOS-e820: [mem 0xaf7ff000-0xaf7f] usable [0.00] BIOS-e820: [mem 0xaf80-0xafff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfeb0-0xfeb03fff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffd8-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x0001ceff] usable [0.00] NX (Execute Disable) protection: active [0.00] DMI 2.7 present. [0.00] DMI: TOSHIBA SATELLITE L855/Portable PC, BIOS 1.60 04/20/2012 [0.00] e820: update [mem 0x-0x] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x1cf000 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-E7FFF write-protect [0.00] E8000-E write-combining [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask F8000 write-back [0.00] 1 base 08000 mask FC000 write-back [0.00] 2 base 0AF80 mask FFF80 uncachable [0.00] 3 base 0B000 mask FF000 uncachable [0.00] 4 base 0FFC0 mask FFFC0 write-protect [0.00] 5 base 1 mask F write-back [0.00] 6 base 1CF00 mask FFF00 uncachable [0.00] 7 base 1D000 mask FF000 uncachable [0.00] 8 base 1E000 mask FE000 uncachable [0.00] 9 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: last_pfn = 0xaf800 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000fe1b0-0x000fe1bf] mapped at [880fe1b0] [0.00] initial memory mapped: [mem 0x-0x1fff] [0.00] Base memory trampoline at [88097000] 97000 size 24576 [0.00] init_memory_mapping: [mem 0x-0xaf7f] [0.00] [mem 0x-0xaf7f] page 2M [0.00] kernel direct mapping tables up to 0xaf7f @ [mem 0x1fa8-0x1fff] [0.00] init_memory_mapping: [mem 0x1-0x1ceff] [0.00] [mem 0x1-0x1ceff] page 2M [0.00] kernel direct mapping tables up to 0x1ceff @ [mem 0xaf2b6000-0xaf2befff] [0.00] RAMDISK: [mem 0x3763c000-0x37b15fff] [0.00] ACPI: RSDP 000fe020 00024 (v02 TOSINV) [0.00] ACPI: XSDT af7fe210 0009C (v01 TOSINV TOSINV00 0001 0113) [0.00] ACPI: FACP af7fb000 0010C (v05 TOSINV TOSINV00 0001 ACPI 0004) [0.00] ACPI: DSDT af7f 07F66 (v01 TOSINV TOSINV00 ACPI 0004) [0.00] ACPI: FACS af7bb000 00040 [0.00] ACPI: UEFI af7fd000 00236 (v01 TOSINV TOSINV00 0001 ACPI 0004) [0.00] ACPI: ASF! af7fc000 000A5 (v32 TOSINV TOSINV00 0001 ACPI 0004) [0.00] A
[PATCH 09/13] drm/exynos: check NV12M format specific to Exynos properly
On 08/20/2012 02:15 PM, InKi Dae wrote:
> sorry, again.
>
> 2012/8/20 InKi Dae :
>> 2012/8/20 Joonyoung Shim :
>>> On 08/20/2012 11:23 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim :
> On 08/17/2012 06:50 PM, Inki Dae wrote:
>> this patch adds buf_cnt variable in exynos_drm_fb structure and
>> that means a buffer count to drm framebuffer and also adds two
>> functions to get/set the buffer count from/to exynos_drm_fb structure.
>> if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
>> to drm framebuffer refering to mode_cmd->handles and offsets.
>> but when booted, the buffer count will always be 1 because pixel
>> format of console framebuffer is RGB format.
>>
>> Signed-off-by: Inki Dae
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fb.c| 65
>> +++-
>> drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 +++--
>> drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
>> drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
>> 4 files changed, 73 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> index 4ccfe43..2d1bc3a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> @@ -41,10 +41,12 @@
>> * exynos specific framebuffer structure.
>> *
>> * @fb: drm framebuffer obejct.
>> + * @buf_cnt: a buffer count to drm framebuffer.
>> * @exynos_gem_obj: array of exynos specific gem object containing a
>> gem
>> object.
>> */
>> struct exynos_drm_fb {
>> struct drm_framebuffer fb;
>> + unsigned intbuf_cnt;
>> struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
>> };
>> @@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs
>> exynos_drm_fb_funcs = {
>> .dirty = exynos_drm_fb_dirty,
>> };
>> +void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
>> + unsigned int cnt)
>> +{
>> + struct exynos_drm_fb *exynos_fb;
>> +
>> + exynos_fb = to_exynos_fb(fb);
>> +
>> + exynos_fb->buf_cnt = cnt;
>> +}
>> +
>> +unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
>> +{
>> + struct exynos_drm_fb *exynos_fb;
>> +
>> + exynos_fb = to_exynos_fb(fb);
>> +
>> + return exynos_fb->buf_cnt;
>> +}
>> +
>> struct drm_framebuffer *
>> exynos_drm_framebuffer_init(struct drm_device *dev,
>> struct drm_mode_fb_cmd2 *mode_cmd,
>> @@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
>> return &exynos_fb->fb;
>> }
>> +static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2
>> *mode_cmd)
>> +{
>> + unsigned int cnt = 0;
>> +
>> + if (mode_cmd->pixel_format == DRM_FORMAT_NV12MT)
>> + return 2;
>> +
>> + while (cnt != MAX_FB_BUFFER) {
>> + if (!mode_cmd->handles[cnt])
>> + break;
>> + cnt++;
>> + }
>> +
>> + /*
>> +* check if NV12 or NV12M.
>> +*
>> +* NV12
>> +* handles[0] = base1, offsets[0] = 0
>> +* handles[1] = base1, offsets[1] = Y_size
>> +*
>> +* NV12M
>> +* handles[0] = base1, offsets[0] = 0
>> +* handles[1] = base2, offsets[1] = 0
>> +*/
>> + if (cnt == 2) {
>> + /*
>> +* in case of NV12 format, offsets[1] is not 0 and
>> +* handles[0] is same as handles[1].
>> +*/
>> + if (mode_cmd->offsets[1] &&
>> + mode_cmd->handles[0] == mode_cmd->handles[1])
>> + cnt = 1;
>> + }
>> +
>> + return cnt;
>> +}
>
> No, please don't add specific function. There is already
> drm_format_num_planes() function
>
>
I know that, but NV12M format is specific to Exynos. for this, we
already had a discussion and you can refer to below link,
http://web.archiveorange.com/archive/v/hhSc5JAv767vo7fKZLPf
>>>
>>> Yes, but this implementation is not clear, just get plane number using
>>> drm_format_num_planes()
>>> and check handle and offset argument when format is NV12.
>>>
>> drm_format_num_planes() doesn't include NV12MT format type so first
>> that format should be added and then we can get plane count using
>> drm_format_num_planes if not NV12. but if not,
>> exynos_drm_for
[Bug 31862] 3.4(and earlier): White text blocks shown during boot-up
https://bugzilla.kernel.org/show_bug.cgi?id=31862 Alan changed: What|Removed |Added Summary|2.6.39.3 (and earlier): |3.4(and earlier): White |White text blocks shown |text blocks shown during |during boot-up |boot-up -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31862] 2.6.39.3 (and earlier): White text blocks shown during boot-up
https://bugzilla.kernel.org/show_bug.cgi?id=31862 Alan changed: What|Removed |Added Status|REOPENED|NEEDINFO Component|Other |Video(DRI - non Intel) AssignedTo|other_ot...@kernel-bugs.osd |drivers_video-dri@kernel-bu |l.org |gs.osdl.org Product|Other |Drivers --- Comment #3 from Alan 2012-08-20 21:14:47 --- Because nothing had happened since 2011 and because it appeared to be to do with the userspace. Just having a general prune of old bugs - not particularly picking on yours Now it's re-opened and known current hopefully it'll shake a branch or two. Do you only see the white rectangles during dracut or do they appear in X or console too ? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/13] drm/exynos: check NV12M format specific to Exynos properly
sorry, again.
2012/8/20 InKi Dae :
> 2012/8/20 Joonyoung Shim :
>> On 08/20/2012 11:23 AM, InKi Dae wrote:
>>>
>>> 2012/8/20 Joonyoung Shim :
On 08/17/2012 06:50 PM, Inki Dae wrote:
>
> this patch adds buf_cnt variable in exynos_drm_fb structure and
> that means a buffer count to drm framebuffer and also adds two
> functions to get/set the buffer count from/to exynos_drm_fb structure.
> if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
> to drm framebuffer refering to mode_cmd->handles and offsets.
> but when booted, the buffer count will always be 1 because pixel
> format of console framebuffer is RGB format.
>
> Signed-off-by: Inki Dae
> Signed-off-by: Kyungmin Park
> ---
>drivers/gpu/drm/exynos/exynos_drm_fb.c| 65
> +++-
>drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 +++--
>drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
>drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
>4 files changed, 73 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index 4ccfe43..2d1bc3a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -41,10 +41,12 @@
> * exynos specific framebuffer structure.
> *
> * @fb: drm framebuffer obejct.
> + * @buf_cnt: a buffer count to drm framebuffer.
> * @exynos_gem_obj: array of exynos specific gem object containing a
> gem
> object.
> */
>struct exynos_drm_fb {
> struct drm_framebuffer fb;
> + unsigned intbuf_cnt;
> struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
>};
>@@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs
> exynos_drm_fb_funcs = {
> .dirty = exynos_drm_fb_dirty,
>};
>+void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
> + unsigned int cnt)
> +{
> + struct exynos_drm_fb *exynos_fb;
> +
> + exynos_fb = to_exynos_fb(fb);
> +
> + exynos_fb->buf_cnt = cnt;
> +}
> +
> +unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
> +{
> + struct exynos_drm_fb *exynos_fb;
> +
> + exynos_fb = to_exynos_fb(fb);
> +
> + return exynos_fb->buf_cnt;
> +}
> +
>struct drm_framebuffer *
>exynos_drm_framebuffer_init(struct drm_device *dev,
> struct drm_mode_fb_cmd2 *mode_cmd,
> @@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
> return &exynos_fb->fb;
>}
>+static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2
> *mode_cmd)
> +{
> + unsigned int cnt = 0;
> +
> + if (mode_cmd->pixel_format == DRM_FORMAT_NV12MT)
> + return 2;
> +
> + while (cnt != MAX_FB_BUFFER) {
> + if (!mode_cmd->handles[cnt])
> + break;
> + cnt++;
> + }
> +
> + /*
> +* check if NV12 or NV12M.
> +*
> +* NV12
> +* handles[0] = base1, offsets[0] = 0
> +* handles[1] = base1, offsets[1] = Y_size
> +*
> +* NV12M
> +* handles[0] = base1, offsets[0] = 0
> +* handles[1] = base2, offsets[1] = 0
> +*/
> + if (cnt == 2) {
> + /*
> +* in case of NV12 format, offsets[1] is not 0 and
> +* handles[0] is same as handles[1].
> +*/
> + if (mode_cmd->offsets[1] &&
> + mode_cmd->handles[0] == mode_cmd->handles[1])
> + cnt = 1;
> + }
> +
> + return cnt;
> +}
No, please don't add specific function. There is already
drm_format_num_planes() function
>>> I know that, but NV12M format is specific to Exynos. for this, we
>>> already had a discussion and you can refer to below link,
>>> http://web.archiveorange.com/archive/v/hhSc5JAv767vo7fKZLPf
>>
>>
>> Yes, but this implementation is not clear, just get plane number using
>> drm_format_num_planes()
>> and check handle and offset argument when format is NV12.
>>
>
> drm_format_num_planes() doesn't include NV12MT format type so first
> that format should be added and then we can get plane count using
> drm_format_num_planes if not NV12. but if not,
> exynos_drm_format_num_buffers() like below,
>
> if (mode_cmd == DRM_FORMAT_NV12)
>
if (mode_cmd->pixel_format == DRM_FORMAT_NV12)
exynos_fb->buf_cnt = exynos_drm_format_num_
[PATCH 09/13] drm/exynos: check NV12M format specific to Exynos properly
2012/8/20 Joonyoung Shim :
> On 08/20/2012 11:23 AM, InKi Dae wrote:
>>
>> 2012/8/20 Joonyoung Shim :
>>>
>>> On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
functions to get/set the buffer count from/to exynos_drm_fb structure.
if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
to drm framebuffer refering to mode_cmd->handles and offsets.
but when booted, the buffer count will always be 1 because pixel
format of console framebuffer is RGB format.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 65
+++-
drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 +++--
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
4 files changed, 73 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 4ccfe43..2d1bc3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -41,10 +41,12 @@
* exynos specific framebuffer structure.
*
* @fb: drm framebuffer obejct.
+ * @buf_cnt: a buffer count to drm framebuffer.
* @exynos_gem_obj: array of exynos specific gem object containing a
gem
object.
*/
struct exynos_drm_fb {
struct drm_framebuffer fb;
+ unsigned intbuf_cnt;
struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
};
@@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs
exynos_drm_fb_funcs = {
.dirty = exynos_drm_fb_dirty,
};
+void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
+ unsigned int cnt)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ exynos_fb->buf_cnt = cnt;
+}
+
+unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ return exynos_fb->buf_cnt;
+}
+
struct drm_framebuffer *
exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
@@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
return &exynos_fb->fb;
}
+static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2
*mode_cmd)
+{
+ unsigned int cnt = 0;
+
+ if (mode_cmd->pixel_format == DRM_FORMAT_NV12MT)
+ return 2;
+
+ while (cnt != MAX_FB_BUFFER) {
+ if (!mode_cmd->handles[cnt])
+ break;
+ cnt++;
+ }
+
+ /*
+* check if NV12 or NV12M.
+*
+* NV12
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base1, offsets[1] = Y_size
+*
+* NV12M
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base2, offsets[1] = 0
+*/
+ if (cnt == 2) {
+ /*
+* in case of NV12 format, offsets[1] is not 0 and
+* handles[0] is same as handles[1].
+*/
+ if (mode_cmd->offsets[1] &&
+ mode_cmd->handles[0] == mode_cmd->handles[1])
+ cnt = 1;
+ }
+
+ return cnt;
+}
>>>
>>>
>>> No, please don't add specific function. There is already
>>> drm_format_num_planes() function
>>>
>>>
>> I know that, but NV12M format is specific to Exynos. for this, we
>> already had a discussion and you can refer to below link,
>> http://web.archiveorange.com/archive/v/hhSc5JAv767vo7fKZLPf
>
>
> Yes, but this implementation is not clear, just get plane number using
> drm_format_num_planes()
> and check handle and offset argument when format is NV12.
>
drm_format_num_planes() doesn't include NV12MT format type so first
that format should be added and then we can get plane count using
drm_format_num_planes if not NV12. but if not,
exynos_drm_format_num_buffers() like below,
if (mode_cmd == DRM_FORMAT_NV12)
>
+
static struct drm_framebuffer *
exynos_user_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
struct drm_mode_fb_cmd2 *mode_cmd)
@@ -134,7 +192,6 @@ exynos_user_fb_create(struct drm_device *dev, str
[PATCH] drm/ttm: remove EBUSY handling in ttm_execbuf_util
On Mon, Aug 20, 2012 at 1:55 PM, Maarten Lankhorst wrote: > Hey, > > Op 20-08-12 17:15, Jerome Glisse schreef: >> On Mon, Aug 20, 2012 at 9:42 AM, Maarten Lankhorst >> wrote: >>> How is this different from just calling with no_wait == false? >>> As far as I can tell, both paths end up with the same result.. >>> >>> Signed-off-by: Maarten Lankhorst >> NAK this seriously modify the behavior. The ttm_eu_del_from_lru_locked >> part is important. It must happen with lru lock held and without any >> dropping of this lock prior to wait for bo unreserve. >> > > You're right, I missed the part where it removed those, causing the later > patch to be wrong too. However I still think the code can be made more > readable. Wouldn't it be better if it used the unlocked variants instead? > It would save a lot of extra list traversals, and you could drop > removed, reserved and put_count from ttm_validate_buffer. > > ~Maarten > No, as i said the lock can not be drop, i don't see much simplification of this code. Also the path you trying to modify is taken only is some bo is reserved by some other process, which is supposed to be rare event. Cheers, Jerome
[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot
https://bugs.freedesktop.org/show_bug.cgi?id=42373 --- Comment #32 from Alex Deucher 2012-08-20 14:03:44 UTC --- A similar patch is already upstream: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=81ee8fb6b52ec69eeed37fe7943446af1dccecc5 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53512] kernel rejects cs in quake wars
https://bugs.freedesktop.org/show_bug.cgi?id=53512 almos changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from almos 2012-08-20 13:56:19 UTC --- With kernel 3.5.1, libdrm 2.4.38 and mesa git-c51f8e2 I couldn't reproduce this. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 11/13] drm/exynos: changed context name of hdmi and mixer
On 08/20/2012 11:29 AM, InKi Dae wrote:
> 2012/8/20 Joonyoung Shim :
>> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>> this patch changes ctx variable name in exynos_drm_hdmi_context
>>> structure to client because the use of ctx variable makes it confused.
>>
>> I don't prefer "client" name. This is not client and server relationship.
>>
> Okay, give me your opinion. which one do you prefer?
Just "data".
Thanks.
>>> Signed-off-by: Inki Dae
>>> Signed-off-by: Kyungmin Park
>>> ---
>>>drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 38
>>> +++---
>>>drivers/gpu/drm/exynos/exynos_drm_hdmi.h |4 +-
>>>drivers/gpu/drm/exynos/exynos_hdmi.c | 12
>>>drivers/gpu/drm/exynos/exynos_mixer.c|8 +++---
>>>4 files changed, 31 insertions(+), 31 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>>> index 3fdf0b6..bced38e 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>>> @@ -64,7 +64,7 @@ static bool drm_hdmi_is_connected(struct device *dev)
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> if (hdmi_ops && hdmi_ops->is_connected)
>>> - return hdmi_ops->is_connected(ctx->hdmi_ctx->ctx);
>>> + return hdmi_ops->is_connected(ctx->hdmi_ctx->client);
>>> return false;
>>>}
>>> @@ -77,8 +77,8 @@ static int drm_hdmi_get_edid(struct device *dev,
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> if (hdmi_ops && hdmi_ops->get_edid)
>>> - return hdmi_ops->get_edid(ctx->hdmi_ctx->ctx, connector,
>>> edid,
>>> - len);
>>> + return hdmi_ops->get_edid(ctx->hdmi_ctx->client,
>>> connector,
>>> + edid, len);
>>> return 0;
>>>}
>>> @@ -90,7 +90,7 @@ static int drm_hdmi_check_timing(struct device *dev,
>>> void *timing)
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> if (hdmi_ops && hdmi_ops->check_timing)
>>> - return hdmi_ops->check_timing(ctx->hdmi_ctx->ctx, timing);
>>> + return hdmi_ops->check_timing(ctx->hdmi_ctx->client,
>>> timing);
>>> return 0;
>>>}
>>> @@ -102,7 +102,7 @@ static int drm_hdmi_power_on(struct device *dev, int
>>> mode)
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> if (hdmi_ops && hdmi_ops->power_on)
>>> - return hdmi_ops->power_on(ctx->hdmi_ctx->ctx, mode);
>>> + return hdmi_ops->power_on(ctx->hdmi_ctx->client, mode);
>>> return 0;
>>>}
>>> @@ -124,7 +124,7 @@ static int drm_hdmi_enable_vblank(struct device
>>> *subdrv_dev)
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> if (mixer_ops && mixer_ops->enable_vblank)
>>> - return mixer_ops->enable_vblank(ctx->mixer_ctx->ctx,
>>> + return mixer_ops->enable_vblank(ctx->mixer_ctx->client,
>>> manager->pipe);
>>> return 0;
>>> @@ -137,12 +137,12 @@ static void drm_hdmi_disable_vblank(struct device
>>> *subdrv_dev)
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> if (mixer_ops && mixer_ops->disable_vblank)
>>> - return mixer_ops->disable_vblank(ctx->mixer_ctx->ctx);
>>> + return mixer_ops->disable_vblank(ctx->mixer_ctx->client);
>>>}
>>> static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
>>> struct drm_connector *connector,
>>> - const struct drm_display_mode *mode,
>>> + struct drm_display_mode *mode,
>>> struct drm_display_mode *adjusted_mode)
>>>{
>>> struct drm_hdmi_context *ctx = to_context(subdrv_dev);
>>> @@ -150,7 +150,7 @@ static void drm_hdmi_mode_fixup(struct device
>>> *subdrv_dev,
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> if (hdmi_ops && hdmi_ops->mode_fixup)
>>> - hdmi_ops->mode_fixup(ctx->hdmi_ctx->ctx, connector, mode,
>>> + hdmi_ops->mode_fixup(ctx->hdmi_ctx->client, connector,
>>> mode,
>>> adjusted_mode);
>>>}
>>>@@ -161,7 +161,7 @@ static void drm_hdmi_mode_set(struct device
>>> *subdrv_dev, void *mode)
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> if (hdmi_ops && hdmi_ops->mode_set)
>>> - hdmi_ops->mode_set(ctx->hdmi_ctx->ctx, mode);
>>> + hdmi_ops->mode_set(ctx->hdmi_ctx->client, mode);
>>>}
>>> static void drm_hdmi_get_max_resol(struct device *subdrv_dev,
>>> @@ -172,7 +172,7 @@ static void drm_hdmi_get_max_resol(struct device
>>> *subdrv_dev,
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> if (hdmi_ops && hdmi_ops->get_max_resol)
>>> - hdmi_ops->get_max_resol(ctx->hdmi_ctx->ctx, width,
>>> height);
>>> + h
[PATCH 09/13] drm/exynos: check NV12M format specific to Exynos properly
On 08/20/2012 11:23 AM, InKi Dae wrote:
> 2012/8/20 Joonyoung Shim :
>> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>> this patch adds buf_cnt variable in exynos_drm_fb structure and
>>> that means a buffer count to drm framebuffer and also adds two
>>> functions to get/set the buffer count from/to exynos_drm_fb structure.
>>> if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
>>> to drm framebuffer refering to mode_cmd->handles and offsets.
>>> but when booted, the buffer count will always be 1 because pixel
>>> format of console framebuffer is RGB format.
>>>
>>> Signed-off-by: Inki Dae
>>> Signed-off-by: Kyungmin Park
>>> ---
>>>drivers/gpu/drm/exynos/exynos_drm_fb.c| 65
>>> +++-
>>>drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 +++--
>>>drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
>>>drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
>>>4 files changed, 73 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>>> index 4ccfe43..2d1bc3a 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>>> @@ -41,10 +41,12 @@
>>> * exynos specific framebuffer structure.
>>> *
>>> * @fb: drm framebuffer obejct.
>>> + * @buf_cnt: a buffer count to drm framebuffer.
>>> * @exynos_gem_obj: array of exynos specific gem object containing a gem
>>> object.
>>> */
>>>struct exynos_drm_fb {
>>> struct drm_framebuffer fb;
>>> + unsigned intbuf_cnt;
>>> struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
>>>};
>>>@@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs
>>> exynos_drm_fb_funcs = {
>>> .dirty = exynos_drm_fb_dirty,
>>>};
>>>+void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
>>> + unsigned int cnt)
>>> +{
>>> + struct exynos_drm_fb *exynos_fb;
>>> +
>>> + exynos_fb = to_exynos_fb(fb);
>>> +
>>> + exynos_fb->buf_cnt = cnt;
>>> +}
>>> +
>>> +unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
>>> +{
>>> + struct exynos_drm_fb *exynos_fb;
>>> +
>>> + exynos_fb = to_exynos_fb(fb);
>>> +
>>> + return exynos_fb->buf_cnt;
>>> +}
>>> +
>>>struct drm_framebuffer *
>>>exynos_drm_framebuffer_init(struct drm_device *dev,
>>> struct drm_mode_fb_cmd2 *mode_cmd,
>>> @@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
>>> return &exynos_fb->fb;
>>>}
>>>+static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2
>>> *mode_cmd)
>>> +{
>>> + unsigned int cnt = 0;
>>> +
>>> + if (mode_cmd->pixel_format == DRM_FORMAT_NV12MT)
>>> + return 2;
>>> +
>>> + while (cnt != MAX_FB_BUFFER) {
>>> + if (!mode_cmd->handles[cnt])
>>> + break;
>>> + cnt++;
>>> + }
>>> +
>>> + /*
>>> +* check if NV12 or NV12M.
>>> +*
>>> +* NV12
>>> +* handles[0] = base1, offsets[0] = 0
>>> +* handles[1] = base1, offsets[1] = Y_size
>>> +*
>>> +* NV12M
>>> +* handles[0] = base1, offsets[0] = 0
>>> +* handles[1] = base2, offsets[1] = 0
>>> +*/
>>> + if (cnt == 2) {
>>> + /*
>>> +* in case of NV12 format, offsets[1] is not 0 and
>>> +* handles[0] is same as handles[1].
>>> +*/
>>> + if (mode_cmd->offsets[1] &&
>>> + mode_cmd->handles[0] == mode_cmd->handles[1])
>>> + cnt = 1;
>>> + }
>>> +
>>> + return cnt;
>>> +}
>>
>> No, please don't add specific function. There is already
>> drm_format_num_planes() function
>>
>>
> I know that, but NV12M format is specific to Exynos. for this, we
> already had a discussion and you can refer to below link,
> http://web.archiveorange.com/archive/v/hhSc5JAv767vo7fKZLPf
Yes, but this implementation is not clear, just get plane number using
drm_format_num_planes()
and check handle and offset argument when format is NV12.
>>> +
>>>static struct drm_framebuffer *
>>>exynos_user_fb_create(struct drm_device *dev, struct drm_file
>>> *file_priv,
>>>struct drm_mode_fb_cmd2 *mode_cmd)
>>> @@ -134,7 +192,6 @@ exynos_user_fb_create(struct drm_device *dev, struct
>>> drm_file *file_priv,
>>> struct drm_gem_object *obj;
>>> struct drm_framebuffer *fb;
>>> struct exynos_drm_fb *exynos_fb;
>>> - int nr;
>>> int i;
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> @@ -152,9 +209,11 @@ exynos_user_fb_create(struct drm_device *dev, struct
>>> drm_file *file_priv,
>>> }
>>> exynos_fb = to_exynos_fb(fb);
>>> - nr = exynos_drm_format_nu
[PATCH 02/13] drm/exynos: separated subdrv->probe call and encoder/connector creation.
On 08/20/2012 01:31 PM, InKi Dae wrote:
> 2012/8/20 Joonyoung Shim :
>> On 08/20/2012 10:52 AM, InKi Dae wrote:
>>> 2012/8/20 Joonyoung Shim :
On 08/17/2012 06:50 PM, Inki Dae wrote:
> this patch separates sub driver's probe call and encoder/connector
> creation
> so that exynos drm core module can take exception when some operation
> was
> failed properly.
Which exceptions? I don't know this patch gives any benefit to us.
>>> previous code didn't take exception when exynos_drm_encoder_create()
>>> is falied.
>>
>> No, it is considered.
>>
> where is subdrv->remove() called when exynos_drm_encoder_create() is
> failed? I think if failed then subdrv->remove() should be called and
> if exynos_drm_connector_create() is failed then not only
> encoder->funcs->destory() but also subdrv->remove()
OK, but just add subdrv->remove(). Then if it needs, please split function.
>>> and for now, exynos_drm_encoder/connector_create functions
>>> was called at exynos_drm_subdrv_probe() so know that this patch is for
>>> code clean by separating them into two parts also.
>>
>> It's ok, but it just splitting.
>>
>>
> Signed-off-by: Inki Dae
> Signed-off-by: Kyungmin Park
> ---
> drivers/gpu/drm/exynos/exynos_drm_core.c | 93
> +-
> 1 files changed, 65 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
> b/drivers/gpu/drm/exynos/exynos_drm_core.c
> index 84dd099..1c8d5fe 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
> @@ -34,30 +34,15 @@
> static LIST_HEAD(exynos_drm_subdrv_list);
> -static int exynos_drm_subdrv_probe(struct drm_device *dev,
> +static int exynos_drm_create_enc_conn(struct drm_device *dev,
> struct exynos_drm_subdrv
> *subdrv)
> {
> struct drm_encoder *encoder;
> struct drm_connector *connector;
> + int ret;
> DRM_DEBUG_DRIVER("%s\n", __FILE__);
> - if (subdrv->probe) {
> - int ret;
> -
> - /*
> -* this probe callback would be called by sub driver
> -* after setting of all resources to this sub driver,
> -* such as clock, irq and register map are done or by
> load()
> -* of exynos drm driver.
> -*
> -* P.S. note that this driver is considered for
> modularization.
> -*/
> - ret = subdrv->probe(dev, subdrv->dev);
> - if (ret)
> - return ret;
> - }
> -
> if (!subdrv->manager)
> return 0;
> @@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct
> drm_device
> *dev,
> connector = exynos_drm_connector_create(dev, encoder);
> if (!connector) {
> DRM_ERROR("failed to create connector\n");
> - encoder->funcs->destroy(encoder);
> - return -EFAULT;
> + ret = -EFAULT;
> + goto err_destroy_encoder;
> }
> subdrv->encoder = encoder;
> subdrv->connector = connector;
> return 0;
> +
> +err_destroy_encoder:
> + encoder->funcs->destroy(encoder);
> + return ret;
> }
> -static void exynos_drm_subdrv_remove(struct drm_device *dev,
> - struct exynos_drm_subdrv *subdrv)
> +static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv
> *subdrv)
> {
> - DRM_DEBUG_DRIVER("%s\n", __FILE__);
> -
> - if (subdrv->remove)
> - subdrv->remove(dev);
> -
> if (subdrv->encoder) {
> struct drm_encoder *encoder = subdrv->encoder;
> encoder->funcs->destroy(encoder);
> @@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct
> drm_device
> *dev,
> }
> }
> +static int exynos_drm_subdrv_probe(struct drm_device *dev,
> + struct exynos_drm_subdrv
> *subdrv)
> +{
> + if (subdrv->probe) {
> + int ret;
> +
> + subdrv->drm_dev = dev;
> +
> + /*
> +* this probe callback would be called by sub driver
> +* after setting of all resources to this sub driver,
> +* such as clock, irq and register map are done or by
> load()
> +* of exynos drm driver.
> +*
> +* P.S. note that this driver is considered for
> mo
[PATCH 02/13] drm/exynos: separated subdrv->probe call and encoder/connector creation.
2012/8/20 Joonyoung Shim :
> On 08/20/2012 10:52 AM, InKi Dae wrote:
>>
>> 2012/8/20 Joonyoung Shim :
>>>
>>> On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch separates sub driver's probe call and encoder/connector
creation
so that exynos drm core module can take exception when some operation
was
failed properly.
>>>
>>>
>>> Which exceptions? I don't know this patch gives any benefit to us.
>>>
>> previous code didn't take exception when exynos_drm_encoder_create()
>> is falied.
>
>
> No, it is considered.
>
where is subdrv->remove() called when exynos_drm_encoder_create() is
failed? I think if failed then subdrv->remove() should be called and
if exynos_drm_connector_create() is failed then not only
encoder->funcs->destory() but also subdrv->remove()
>
>> and for now, exynos_drm_encoder/connector_create functions
>> was called at exynos_drm_subdrv_probe() so know that this patch is for
>> code clean by separating them into two parts also.
>
>
> It's ok, but it just splitting.
>
>
>>
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 93
+-
1 files changed, 65 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 84dd099..1c8d5fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -34,30 +34,15 @@
static LIST_HEAD(exynos_drm_subdrv_list);
-static int exynos_drm_subdrv_probe(struct drm_device *dev,
+static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv
*subdrv)
{
struct drm_encoder *encoder;
struct drm_connector *connector;
+ int ret;
DRM_DEBUG_DRIVER("%s\n", __FILE__);
- if (subdrv->probe) {
- int ret;
-
- /*
-* this probe callback would be called by sub driver
-* after setting of all resources to this sub driver,
-* such as clock, irq and register map are done or by
load()
-* of exynos drm driver.
-*
-* P.S. note that this driver is considered for
modularization.
-*/
- ret = subdrv->probe(dev, subdrv->dev);
- if (ret)
- return ret;
- }
-
if (!subdrv->manager)
return 0;
@@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct
drm_device
*dev,
connector = exynos_drm_connector_create(dev, encoder);
if (!connector) {
DRM_ERROR("failed to create connector\n");
- encoder->funcs->destroy(encoder);
- return -EFAULT;
+ ret = -EFAULT;
+ goto err_destroy_encoder;
}
subdrv->encoder = encoder;
subdrv->connector = connector;
return 0;
+
+err_destroy_encoder:
+ encoder->funcs->destroy(encoder);
+ return ret;
}
-static void exynos_drm_subdrv_remove(struct drm_device *dev,
- struct exynos_drm_subdrv *subdrv)
+static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv
*subdrv)
{
- DRM_DEBUG_DRIVER("%s\n", __FILE__);
-
- if (subdrv->remove)
- subdrv->remove(dev);
-
if (subdrv->encoder) {
struct drm_encoder *encoder = subdrv->encoder;
encoder->funcs->destroy(encoder);
@@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct
drm_device
*dev,
}
}
+static int exynos_drm_subdrv_probe(struct drm_device *dev,
+ struct exynos_drm_subdrv
*subdrv)
+{
+ if (subdrv->probe) {
+ int ret;
+
+ subdrv->drm_dev = dev;
+
+ /*
+* this probe callback would be called by sub driver
+* after setting of all resources to this sub driver,
+* such as clock, irq and register map are done or by
load()
+* of exynos drm driver.
+*
+* P.S. note that this driver is considered for
modularization.
+*/
+ ret = subdrv->probe(dev, subdrv->dev);
+ if (ret)
+ return ret;
+ }
+
+ if (!subdrv->manager)
+ ret
Re: radeon testing
On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
> > I just tested the rebased acpi_patches branch: ACPI part works fine, but
> > I see a big slow down during radeon driver initialization when the
> > screen goes black for a couple of seconds (with 3.5.0 + acpi patches the
> > screen just flickers during boot). With initcall_debug I see:
> >
> > [2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552
> > ...
> > [5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after
> > 3102147 usecs
> >
> > For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not
> > very
> > informative, I'll try and get more info...
>
> Can you bisect?
I've put in some printk, this is the result:
[2.403138] evergreen_mc_program
[2.403196] evergreen_mc_stop
...
[4.268491] evergreen_mc_resume done
[4.268548] evergreen_mc_program done
This is the patch:
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1349,6 +1349,8 @@ void evergreen_mc_program(struct radeon_device *rdev)
u32 tmp;
int i, j;
+ printk(KERN_INFO "%s\n", __func__);
+
/* Initialize HDP */
for (i = 0, j = 0; i < 32; i++, j += 0x18) {
WREG32((0x2c14 + j), 0x);
@@ -1359,10 +1361,14 @@ void evergreen_mc_program(struct radeon_device *rdev)
}
WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0);
+ printk(KERN_INFO "evergreen_mc_stop\n");
evergreen_mc_stop(rdev, &save);
+// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
}
+// printk(KERN_INFO "evergreen_mc_wait_for_idle done\n");
+
/* Lockout access through VGA aperture*/
WREG32(VGA_HDP_CONTROL, VGA_MEMORY_DISABLE);
/* Update configuration */
@@ -1411,10 +1417,13 @@ void evergreen_mc_program(struct radeon_device *rdev)
WREG32(MC_VM_AGP_TOP, 0x0FFF);
WREG32(MC_VM_AGP_BOT, 0x0FFF);
}
+// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
}
+// printk(KERN_INFO "evergreen_mc_resume\n");
evergreen_mc_resume(rdev, &save);
+ printk(KERN_INFO "evergreen_mc_resume done\n");
/* we need to own VRAM, so turn off the VGA renderer here
* to stop it overwriting our objects */
rv515_vga_render_disable(rdev);
Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
the machine. The likely culprit is commit 023e188e:
commit 023e188ec102330eb05ad264f675e869637478eb
Author: Alex Deucher
Date: Wed Aug 15 17:18:42 2012 -0400
drm/radeon: properly handle mc_stop/mc_resume on evergreen+
- Stop the displays from accessing the FB
- Block CPU access
- Turn off MC client access
This should fix issues some users have seen, especially
with UEFI, when changing the MC FB location that result
in hangs or display corruption.
I haven't tried backing out the commit yet, but looking at the diff I
see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
but evergreen_mc_program is called way before IRQ is set up. Is the
vblank counter running? Looks like we just hitting the timeout here...
Luca
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: make VM handling async v2
On Mon, Aug 20, 2012 at 4:08 AM, Christian König wrote: > Second and hopefully last round for this patchset. > > v2: Fix suspend/resume, and incorporate Jeromes comments. Looks good to me. Can you put up a git branch somewhere? Reviewed-by: Alex Deucher > > Cheers, > Christian. > > ___ > 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
[PATCH 04/13] drm/exynos: use empty function instead of drm_helper_connector_dpms
2012/8/20 Joonyoung Shim :
> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>
>> crtc and encoder's dpms callback will be called before connector's dpms
>> is called so drm_helper_connector_dpms doesn't need to be called.
>
>
> I can't understand this description. I know crtc and encoder dpms are called
> by drm_helper_connector_dpms.
>
Ah, right. there is my missing point. for pm, we need
drm_helper_connector_dpms call. actually, this patch is for avoiding
duplicated call of mode_set but I didn't consider pm.
Thanks.
>
>> Signed-off-by: Inki Dae
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_connector.c |9 -
>> 1 files changed, 8 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
>> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
>> index d956819..65acf0d 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
>> @@ -226,6 +226,13 @@ static struct drm_connector_helper_funcs
>> exynos_connector_helper_funcs = {
>> .best_encoder = exynos_drm_best_encoder,
>> };
>> +static void exynos_drm_connector_dpms(struct drm_connector *connector,
>> int mode)
>> +{
>> + DRM_DEBUG_KMS("%s\n", __FILE__);
>> +
>> + /* drm framework doesn't check NULL. */
>> +}
>> +
>> static int exynos_drm_connector_fill_modes(struct drm_connector
>> *connector,
>> unsigned int max_width, unsigned int
>> max_height)
>> {
>> @@ -285,7 +292,7 @@ static void exynos_drm_connector_destroy(struct
>> drm_connector *connector)
>> }
>> static struct drm_connector_funcs exynos_connector_funcs = {
>> - .dpms = drm_helper_connector_dpms,
>> + .dpms = exynos_drm_connector_dpms,
>> .fill_modes = exynos_drm_connector_fill_modes,
>> .detect = exynos_drm_connector_detect,
>> .destroy= exynos_drm_connector_destroy,
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND] gpu/mfd/usb: Fix USB randconfig problems
On Mon, Aug 20, 2012 at 11:23:16AM -0700, Guenter Roeck wrote: > Fix config warning: > > warning: ( ... && DRM_USB) selects USB which has unmet direct dependencies > (USB_SUPPORT && USB_ARCH_HAS_HCD) > > and build error: > ERROR: "usb_speed_string" [drivers/usb/core/usbcore.ko] undefined! > > by adding the missing dependency on USB_ARCH_HAS_HCD to DRM_UDL and DRM_USB. I'll take this, sorry for the delay. greg k-h
[PATCH 11/13] drm/exynos: changed context name of hdmi and mixer
2012/8/20 Joonyoung Shim :
> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>
>> this patch changes ctx variable name in exynos_drm_hdmi_context
>> structure to client because the use of ctx variable makes it confused.
>
>
> I don't prefer "client" name. This is not client and server relationship.
>
Okay, give me your opinion. which one do you prefer?
>
>>
>> Signed-off-by: Inki Dae
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 38
>> +++---
>> drivers/gpu/drm/exynos/exynos_drm_hdmi.h |4 +-
>> drivers/gpu/drm/exynos/exynos_hdmi.c | 12
>> drivers/gpu/drm/exynos/exynos_mixer.c|8 +++---
>> 4 files changed, 31 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> index 3fdf0b6..bced38e 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> @@ -64,7 +64,7 @@ static bool drm_hdmi_is_connected(struct device *dev)
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> if (hdmi_ops && hdmi_ops->is_connected)
>> - return hdmi_ops->is_connected(ctx->hdmi_ctx->ctx);
>> + return hdmi_ops->is_connected(ctx->hdmi_ctx->client);
>> return false;
>> }
>> @@ -77,8 +77,8 @@ static int drm_hdmi_get_edid(struct device *dev,
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> if (hdmi_ops && hdmi_ops->get_edid)
>> - return hdmi_ops->get_edid(ctx->hdmi_ctx->ctx, connector,
>> edid,
>> - len);
>> + return hdmi_ops->get_edid(ctx->hdmi_ctx->client,
>> connector,
>> + edid, len);
>> return 0;
>> }
>> @@ -90,7 +90,7 @@ static int drm_hdmi_check_timing(struct device *dev,
>> void *timing)
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> if (hdmi_ops && hdmi_ops->check_timing)
>> - return hdmi_ops->check_timing(ctx->hdmi_ctx->ctx, timing);
>> + return hdmi_ops->check_timing(ctx->hdmi_ctx->client,
>> timing);
>> return 0;
>> }
>> @@ -102,7 +102,7 @@ static int drm_hdmi_power_on(struct device *dev, int
>> mode)
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> if (hdmi_ops && hdmi_ops->power_on)
>> - return hdmi_ops->power_on(ctx->hdmi_ctx->ctx, mode);
>> + return hdmi_ops->power_on(ctx->hdmi_ctx->client, mode);
>> return 0;
>> }
>> @@ -124,7 +124,7 @@ static int drm_hdmi_enable_vblank(struct device
>> *subdrv_dev)
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> if (mixer_ops && mixer_ops->enable_vblank)
>> - return mixer_ops->enable_vblank(ctx->mixer_ctx->ctx,
>> + return mixer_ops->enable_vblank(ctx->mixer_ctx->client,
>> manager->pipe);
>> return 0;
>> @@ -137,12 +137,12 @@ static void drm_hdmi_disable_vblank(struct device
>> *subdrv_dev)
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> if (mixer_ops && mixer_ops->disable_vblank)
>> - return mixer_ops->disable_vblank(ctx->mixer_ctx->ctx);
>> + return mixer_ops->disable_vblank(ctx->mixer_ctx->client);
>> }
>> static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
>> struct drm_connector *connector,
>> - const struct drm_display_mode *mode,
>> + struct drm_display_mode *mode,
>> struct drm_display_mode *adjusted_mode)
>> {
>> struct drm_hdmi_context *ctx = to_context(subdrv_dev);
>> @@ -150,7 +150,7 @@ static void drm_hdmi_mode_fixup(struct device
>> *subdrv_dev,
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> if (hdmi_ops && hdmi_ops->mode_fixup)
>> - hdmi_ops->mode_fixup(ctx->hdmi_ctx->ctx, connector, mode,
>> + hdmi_ops->mode_fixup(ctx->hdmi_ctx->client, connector,
>> mode,
>> adjusted_mode);
>> }
>> @@ -161,7 +161,7 @@ static void drm_hdmi_mode_set(struct device
>> *subdrv_dev, void *mode)
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> if (hdmi_ops && hdmi_ops->mode_set)
>> - hdmi_ops->mode_set(ctx->hdmi_ctx->ctx, mode);
>> + hdmi_ops->mode_set(ctx->hdmi_ctx->client, mode);
>> }
>> static void drm_hdmi_get_max_resol(struct device *subdrv_dev,
>> @@ -172,7 +172,7 @@ static void drm_hdmi_get_max_resol(struct device
>> *subdrv_dev,
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> if (hdmi_ops && hdmi_ops->get_max_resol)
>> - hdmi_ops->get_max_resol(ctx->hdmi_ctx->ctx, width,
>> height);
>> + hdmi_ops->get_max_resol(ctx->hdmi_ctx->client, width,
>> height);
>> }
>> static void drm_hdmi_commit(struct device *subdrv_dev)
>> @@ -182,7 +182,7 @@ static void drm_hdmi_commit(struct device *su
[RFC PATCH 7/7] drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready
On Mon, Aug 20, 2012 at 04:57:41PM +0100, Matthew Garrett wrote: > On Mon, Aug 20, 2012 at 10:56:33AM -0500, Seth Forshee wrote: > > On Mon, Aug 20, 2012 at 04:36:40PM +0100, Matthew Garrett wrote: > > > Won't this break the multiple cards with independent outputs case? > > > > Yes, if they don't have a switcheroo handler. I only have experience > > with one such machine, which had optimus graphics. My recollection is > > that it did have a switcheroo handler, which was only capable of > > controlling power to the discrete card. > > So if I have a desktop machine and install two graphics cards? Yeah, that would likely be broken. I'm not sure how we support both of these cases without doing something more like what I originally proposed, i.e. registering the LVDS connector even if it doesn't look like a panel is attached. I still honestly favor that approach, although it does come with its own set of challenges. The only other option I can come up with is to reprobe LVDS after switcheroo and add the connector at that time. I haven't investigated this option in detail, but at first glance it looks like there are at least some places where DRM isn't prepared to cope with adding connectors after initialization.
[PATCH 09/13] drm/exynos: check NV12M format specific to Exynos properly
2012/8/20 Joonyoung Shim :
> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>
>> this patch adds buf_cnt variable in exynos_drm_fb structure and
>> that means a buffer count to drm framebuffer and also adds two
>> functions to get/set the buffer count from/to exynos_drm_fb structure.
>> if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
>> to drm framebuffer refering to mode_cmd->handles and offsets.
>> but when booted, the buffer count will always be 1 because pixel
>> format of console framebuffer is RGB format.
>>
>> Signed-off-by: Inki Dae
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fb.c| 65
>> +++-
>> drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 +++--
>> drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
>> drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
>> 4 files changed, 73 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> index 4ccfe43..2d1bc3a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> @@ -41,10 +41,12 @@
>>* exynos specific framebuffer structure.
>>*
>>* @fb: drm framebuffer obejct.
>> + * @buf_cnt: a buffer count to drm framebuffer.
>>* @exynos_gem_obj: array of exynos specific gem object containing a gem
>> object.
>>*/
>> struct exynos_drm_fb {
>> struct drm_framebuffer fb;
>> + unsigned intbuf_cnt;
>> struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
>> };
>> @@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs
>> exynos_drm_fb_funcs = {
>> .dirty = exynos_drm_fb_dirty,
>> };
>> +void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
>> + unsigned int cnt)
>> +{
>> + struct exynos_drm_fb *exynos_fb;
>> +
>> + exynos_fb = to_exynos_fb(fb);
>> +
>> + exynos_fb->buf_cnt = cnt;
>> +}
>> +
>> +unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
>> +{
>> + struct exynos_drm_fb *exynos_fb;
>> +
>> + exynos_fb = to_exynos_fb(fb);
>> +
>> + return exynos_fb->buf_cnt;
>> +}
>> +
>> struct drm_framebuffer *
>> exynos_drm_framebuffer_init(struct drm_device *dev,
>> struct drm_mode_fb_cmd2 *mode_cmd,
>> @@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
>> return &exynos_fb->fb;
>> }
>> +static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2
>> *mode_cmd)
>> +{
>> + unsigned int cnt = 0;
>> +
>> + if (mode_cmd->pixel_format == DRM_FORMAT_NV12MT)
>> + return 2;
>> +
>> + while (cnt != MAX_FB_BUFFER) {
>> + if (!mode_cmd->handles[cnt])
>> + break;
>> + cnt++;
>> + }
>> +
>> + /*
>> +* check if NV12 or NV12M.
>> +*
>> +* NV12
>> +* handles[0] = base1, offsets[0] = 0
>> +* handles[1] = base1, offsets[1] = Y_size
>> +*
>> +* NV12M
>> +* handles[0] = base1, offsets[0] = 0
>> +* handles[1] = base2, offsets[1] = 0
>> +*/
>> + if (cnt == 2) {
>> + /*
>> +* in case of NV12 format, offsets[1] is not 0 and
>> +* handles[0] is same as handles[1].
>> +*/
>> + if (mode_cmd->offsets[1] &&
>> + mode_cmd->handles[0] == mode_cmd->handles[1])
>> + cnt = 1;
>> + }
>> +
>> + return cnt;
>> +}
>
>
> No, please don't add specific function. There is already
> drm_format_num_planes() function
>
>
I know that, but NV12M format is specific to Exynos. for this, we
already had a discussion and you can refer to below link,
http://web.archiveorange.com/archive/v/hhSc5JAv767vo7fKZLPf
>> +
>> static struct drm_framebuffer *
>> exynos_user_fb_create(struct drm_device *dev, struct drm_file
>> *file_priv,
>> struct drm_mode_fb_cmd2 *mode_cmd)
>> @@ -134,7 +192,6 @@ exynos_user_fb_create(struct drm_device *dev, struct
>> drm_file *file_priv,
>> struct drm_gem_object *obj;
>> struct drm_framebuffer *fb;
>> struct exynos_drm_fb *exynos_fb;
>> - int nr;
>> int i;
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> @@ -152,9 +209,11 @@ exynos_user_fb_create(struct drm_device *dev, struct
>> drm_file *file_priv,
>> }
>> exynos_fb = to_exynos_fb(fb);
>> - nr = exynos_drm_format_num_buffers(fb->pixel_format);
>> + exynos_fb->buf_cnt = exynos_drm_format_num_buffers(mode_cmd);
>> +
>> + DRM_DEBUG_KMS("buf_cnt = %d\n", exynos_fb->buf_cnt);
>> - for (i = 1; i < nr; i++) {
>> + for (i = 1; i < exynos_fb->buf_cnt; i++) {
>> obj = drm_gem_object_lookup(dev, file_priv,
>>
[PATCH RESEND] gpu/mfd/usb: Fix USB randconfig problems
Fix config warning: warning: ( ... && DRM_USB) selects USB which has unmet direct dependencies (USB_SUPPORT && USB_ARCH_HAS_HCD) and build error: ERROR: "usb_speed_string" [drivers/usb/core/usbcore.ko] undefined! by adding the missing dependency on USB_ARCH_HAS_HCD to DRM_UDL and DRM_USB. This exposes: drivers/video/Kconfig:36:error: recursive dependency detected! drivers/video/Kconfig:36: symbol FB is selected by DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_UDL drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI drivers/usb/Kconfig:16: symbol USB_ARCH_HAS_OHCI depends on I2C drivers/i2c/Kconfig:5: symbol I2C is selected by FB_DDC drivers/video/Kconfig:86: symbol FB_DDC is selected by FB_CYBER2000_DDC drivers/video/Kconfig:385: symbol FB_CYBER2000_DDC depends on FB_CYBER2000 drivers/video/Kconfig:373: symbol FB_CYBER2000 depends on FB which is due to drivers/usb/Kconfig: config USB_ARCH_HAS_OHCI ... default y if ARCH_PNX4008 && I2C Fix by dropping I2C from the above dependency; logic is that this is not a platform dependency but a configuration dependency: the _architecture_ still supports USB even is I2C is not selected. This exposes: drivers/video/Kconfig:36:error: recursive dependency detected! drivers/video/Kconfig:36: symbol FB is selected by DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_UDL drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI drivers/usb/Kconfig:17: symbol USB_ARCH_HAS_OHCI depends on MFD_TC6393XB drivers/mfd/Kconfig:396:symbol MFD_TC6393XB depends on GPIOLIB drivers/gpio/Kconfig:35:symbol GPIOLIB is selected by FB_VIA drivers/video/Kconfig:1560: symbol FB_VIA depends on FB which can be fixed by having MFD_TC6393XB select GPIOLIB instead of depending on it. Signed-off-by: Guenter Roeck --- The USB build problem causes 15-20% of my randconfig builds to fail (6 of 36 failures last night). I'll be happy to split the patch into three if it helps to get it accepted. drivers/gpu/drm/Kconfig |1 + drivers/gpu/drm/udl/Kconfig |1 + drivers/mfd/Kconfig |3 ++- drivers/usb/Kconfig |2 +- 4 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 23120c0..90e2808 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -22,6 +22,7 @@ menuconfig DRM config DRM_USB tristate depends on DRM + depends on USB_ARCH_HAS_HCD select USB config DRM_KMS_HELPER diff --git a/drivers/gpu/drm/udl/Kconfig b/drivers/gpu/drm/udl/Kconfig index 0b5e096..56e0bf3 100644 --- a/drivers/gpu/drm/udl/Kconfig +++ b/drivers/gpu/drm/udl/Kconfig @@ -1,6 +1,7 @@ config DRM_UDL tristate "DisplayLink" depends on DRM && EXPERIMENTAL + depends on USB_ARCH_HAS_HCD select DRM_USB select FB_SYS_FILLRECT select FB_SYS_COPYAREA diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index d1facef..b1a1462 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -395,7 +395,8 @@ config MFD_TC6387XB config MFD_TC6393XB bool "Support Toshiba TC6393XB" - depends on GPIOLIB && ARM && HAVE_CLK + depends on ARM && HAVE_CLK + select GPIOLIB select MFD_CORE select MFD_TMIO help diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index a7773a3..7065df6 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -13,7 +13,7 @@ config USB_ARCH_HAS_OHCI default y if PXA3xx default y if ARCH_EP93XX default y if ARCH_AT91 - default y if ARCH_PNX4008 && I2C + default y if ARCH_PNX4008 default y if MFD_TC6393XB default y if ARCH_W90X900 default y if ARCH_DAVINCI_DA8XX -- 1.7.9.7
[PATCH 4/4] drm/radeon: split ATRM support out from the ATPX handler (v3)
From: Alex Deucher
There are systems that use ATRM, but not ATPX.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41265
V2: fix #ifdefs as per Greg's comments
V3: fix it harder
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon.h | 15 -
drivers/gpu/drm/radeon/radeon_atpx_handler.c | 56 +--
drivers/gpu/drm/radeon/radeon_bios.c | 80 -
3 files changed, 77 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 9930419..59a1531 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -142,21 +142,6 @@ struct radeon_device;
/*
* BIOS.
*/
-#define ATRM_BIOS_PAGE 4096
-
-#if defined(CONFIG_VGA_SWITCHEROO)
-bool radeon_atrm_supported(struct pci_dev *pdev);
-int radeon_atrm_get_bios_chunk(uint8_t *bios, int offset, int len);
-#else
-static inline bool radeon_atrm_supported(struct pci_dev *pdev)
-{
- return false;
-}
-
-static inline int radeon_atrm_get_bios_chunk(uint8_t *bios, int offset, int
len){
- return -EINVAL;
-}
-#endif
bool radeon_get_bios(struct radeon_device *rdev);
/*
diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
index 98724fc..2a2cf0b 100644
--- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -30,57 +30,8 @@ static struct radeon_atpx_priv {
/* handle for device - and atpx */
acpi_handle dhandle;
acpi_handle atpx_handle;
- acpi_handle atrm_handle;
} radeon_atpx_priv;
-/* retrieve the ROM in 4k blocks */
-static int radeon_atrm_call(acpi_handle atrm_handle, uint8_t *bios,
- int offset, int len)
-{
- acpi_status status;
- union acpi_object atrm_arg_elements[2], *obj;
- struct acpi_object_list atrm_arg;
- struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL};
-
- atrm_arg.count = 2;
- atrm_arg.pointer = &atrm_arg_elements[0];
-
- atrm_arg_elements[0].type = ACPI_TYPE_INTEGER;
- atrm_arg_elements[0].integer.value = offset;
-
- atrm_arg_elements[1].type = ACPI_TYPE_INTEGER;
- atrm_arg_elements[1].integer.value = len;
-
- status = acpi_evaluate_object(atrm_handle, NULL, &atrm_arg, &buffer);
- if (ACPI_FAILURE(status)) {
- printk("failed to evaluate ATRM got %s\n",
acpi_format_exception(status));
- return -ENODEV;
- }
-
- obj = (union acpi_object *)buffer.pointer;
- memcpy(bios+offset, obj->buffer.pointer, obj->buffer.length);
- len = obj->buffer.length;
- kfree(buffer.pointer);
- return len;
-}
-
-bool radeon_atrm_supported(struct pci_dev *pdev)
-{
- /* get the discrete ROM only via ATRM */
- if (!radeon_atpx_priv.atpx_detected)
- return false;
-
- if (radeon_atpx_priv.dhandle == DEVICE_ACPI_HANDLE(&pdev->dev))
- return false;
- return true;
-}
-
-
-int radeon_atrm_get_bios_chunk(uint8_t *bios, int offset, int len)
-{
- return radeon_atrm_call(radeon_atpx_priv.atrm_handle, bios, offset,
len);
-}
-
static int radeon_atpx_get_version(acpi_handle handle)
{
acpi_status status;
@@ -198,7 +149,7 @@ static int radeon_atpx_power_state(enum
vga_switcheroo_client_id id,
static bool radeon_atpx_pci_probe_handle(struct pci_dev *pdev)
{
- acpi_handle dhandle, atpx_handle, atrm_handle;
+ acpi_handle dhandle, atpx_handle;
acpi_status status;
dhandle = DEVICE_ACPI_HANDLE(&pdev->dev);
@@ -209,13 +160,8 @@ static bool radeon_atpx_pci_probe_handle(struct pci_dev
*pdev)
if (ACPI_FAILURE(status))
return false;
- status = acpi_get_handle(dhandle, "ATRM", &atrm_handle);
- if (ACPI_FAILURE(status))
- return false;
-
radeon_atpx_priv.dhandle = dhandle;
radeon_atpx_priv.atpx_handle = atpx_handle;
- radeon_atpx_priv.atrm_handle = atrm_handle;
return true;
}
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
b/drivers/gpu/drm/radeon/radeon_bios.c
index ab0b2f7..d306cc8 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -99,16 +99,81 @@ static bool radeon_read_bios(struct radeon_device *rdev)
return true;
}
+#ifdef CONFIG_ACPI
/* ATRM is used to get the BIOS on the discrete cards in
* dual-gpu systems.
*/
+/* retrieve the ROM in 4k blocks */
+#define ATRM_BIOS_PAGE 4096
+/**
+ * radeon_atrm_call - fetch a chunk of the vbios
+ *
+ * @atrm_handle: acpi ATRM handle
+ * @bios: vbios image pointer
+ * @offset: offset of vbios image data to fetch
+ * @len: length of vbios image data to fetch
+ *
+ * Executes ATRM to fetch a chunk of the discrete
+ * vbios image on PX systems (all asics).
+ * Returns the length of the buffer fetched.
+ */
+static int radeon_atrm_ca
[PATCH 3/4] drm/radeon: convert radeon vfct code to use acpi_get_table_with_size
From: Alex Deucher
Allows us to verify the table size.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_bios.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
b/drivers/gpu/drm/radeon/radeon_bios.c
index a32232f..ab0b2f7 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -482,13 +482,12 @@ static bool radeon_acpi_vfct_bios(struct radeon_device
*rdev)
{
bool ret = false;
struct acpi_table_header *hdr;
- /* acpi_get_table_with_size is not exported :( */
- acpi_size tbl_size = 0x7fff;
+ acpi_size tbl_size;
UEFI_ACPI_VFCT *vfct;
GOP_VBIOS_CONTENT *vbios;
VFCT_IMAGE_HEADER *vhdr;
- if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, &hdr)))
+ if (!ACPI_SUCCESS(acpi_get_table_with_size("VFCT", 1, &hdr, &tbl_size)))
return false;
if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
DRM_ERROR("ACPI VFCT table present but broken (too short
#1)\n");
@@ -525,7 +524,6 @@ static bool radeon_acpi_vfct_bios(struct radeon_device
*rdev)
ret = !!rdev->bios;
out_unmap:
- /* uh, no idea what to do here... */
return ret;
}
#else
--
1.7.7.5
[PATCH 2/4] ACPI: export symbol acpi_get_table_with_size
From: Alex Deucher We need it in the radeon drm module to fetch and verify the vbios image on UEFI systems. Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/acpi/acpica/tbxface.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/acpi/acpica/tbxface.c b/drivers/acpi/acpica/tbxface.c index ea4c6d5..29e51bc 100644 --- a/drivers/acpi/acpica/tbxface.c +++ b/drivers/acpi/acpica/tbxface.c @@ -387,6 +387,7 @@ acpi_get_table_with_size(char *signature, return (AE_NOT_FOUND); } +ACPI_EXPORT_SYMBOL(acpi_get_table_with_size) acpi_status acpi_get_table(char *signature, -- 1.7.7.5
[PATCH 1/4] drm/radeon: implement ACPI VFCT vbios fetch (v3)
From: David Lamparter
This is required for pure UEFI systems. The vbios is stored
in ACPI rather than at the legacy vga location.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=26891
V2: fix #ifdefs as per Greg's comments
V3: fix it harder
Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_bios.c | 60 ++
1 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
b/drivers/gpu/drm/radeon/radeon_bios.c
index 501f488..a32232f 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -32,6 +32,7 @@
#include
#include
+#include
/*
* BIOS.
*/
@@ -476,6 +477,63 @@ static bool radeon_read_disabled_bios(struct radeon_device
*rdev)
return legacy_read_disabled_bios(rdev);
}
+#ifdef CONFIG_ACPI
+static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
+{
+ bool ret = false;
+ struct acpi_table_header *hdr;
+ /* acpi_get_table_with_size is not exported :( */
+ acpi_size tbl_size = 0x7fff;
+ UEFI_ACPI_VFCT *vfct;
+ GOP_VBIOS_CONTENT *vbios;
+ VFCT_IMAGE_HEADER *vhdr;
+
+ if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, &hdr)))
+ return false;
+ if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
+ DRM_ERROR("ACPI VFCT table present but broken (too short
#1)\n");
+ goto out_unmap;
+ }
+
+ vfct = (UEFI_ACPI_VFCT *)hdr;
+ if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) > tbl_size) {
+ DRM_ERROR("ACPI VFCT table present but broken (too short
#2)\n");
+ goto out_unmap;
+ }
+
+ vbios = (GOP_VBIOS_CONTENT *)((char *)hdr + vfct->VBIOSImageOffset);
+ vhdr = &vbios->VbiosHeader;
+ DRM_INFO("ACPI VFCT contains a BIOS for %02x:%02x.%d %04x:%04x, size
%d\n",
+ vhdr->PCIBus, vhdr->PCIDevice, vhdr->PCIFunction,
+ vhdr->VendorID, vhdr->DeviceID, vhdr->ImageLength);
+
+ if (vhdr->PCIBus != rdev->pdev->bus->number ||
+ vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
+ vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn) ||
+ vhdr->VendorID != rdev->pdev->vendor ||
+ vhdr->DeviceID != rdev->pdev->device) {
+ DRM_INFO("ACPI VFCT table is not for this card\n");
+ goto out_unmap;
+ };
+
+ if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) +
vhdr->ImageLength > tbl_size) {
+ DRM_ERROR("ACPI VFCT image truncated\n");
+ goto out_unmap;
+ }
+
+ rdev->bios = kmemdup(&vbios->VbiosContent, vhdr->ImageLength,
GFP_KERNEL);
+ ret = !!rdev->bios;
+
+out_unmap:
+ /* uh, no idea what to do here... */
+ return ret;
+}
+#else
+static inline bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
+{
+ return false;
+}
+#endif
bool radeon_get_bios(struct radeon_device *rdev)
{
@@ -484,6 +542,8 @@ bool radeon_get_bios(struct radeon_device *rdev)
r = radeon_atrm_get_bios(rdev);
if (r == false)
+ r = radeon_acpi_vfct_bios(rdev);
+ if (r == false)
r = igp_read_bios_from_vram(rdev);
if (r == false)
r = radeon_read_bios(rdev);
--
1.7.7.5
[PATCH] drm/ttm: cleanup ttm_execbuf_util.c slightly more
On Mon, Aug 20, 2012 at 10:36 AM, Maarten Lankhorst
wrote:
> The removed member is unneeded, an extra pass is done after all
> buffers have been reserved. The behavior stays the same even without
> the removed member, but this makes the code slightly more readable.
>
> Depends on previous 2 execbuf-util patches.
>
> Signed-off-by: Maarten Lankhorst
NAK this one modify lru list handling in wrong way, we need to track
lru per object no way around it.
Cheers,
Jerome
> ---
> drivers/gpu/drm/ttm/ttm_execbuf_util.c | 69
> +++-
> 1 file changed, 24 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> index 4e7b596..a545bc9 100644
> --- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> @@ -32,7 +32,7 @@
> #include
> #include
>
> -static void ttm_eu_backoff_reservation_locked(struct list_head *list)
> +static void ttm_eu_backoff_reservation_locked(struct list_head *list, bool
> removed)
> {
> struct ttm_validate_buffer *entry;
>
> @@ -41,43 +41,13 @@ static void ttm_eu_backoff_reservation_locked(struct
> list_head *list)
> if (!entry->reserved)
> continue;
>
> - if (entry->removed) {
> - ttm_bo_add_to_lru(bo);
> - entry->removed = false;
> -
> - }
> entry->reserved = false;
> - atomic_set(&bo->reserved, 0);
> - wake_up_all(&bo->event_queue);
> - }
> -}
> -
> -static void ttm_eu_del_from_lru_locked(struct list_head *list)
> -{
> - struct ttm_validate_buffer *entry;
> -
> - list_for_each_entry(entry, list, head) {
> - struct ttm_buffer_object *bo = entry->bo;
> - if (!entry->reserved)
> - continue;
>
> - if (!entry->removed) {
> - entry->put_count = ttm_bo_del_from_lru(bo);
> - entry->removed = true;
> - }
> - }
> -}
> -
> -static void ttm_eu_list_ref_sub(struct list_head *list)
> -{
> - struct ttm_validate_buffer *entry;
> -
> - list_for_each_entry(entry, list, head) {
> - struct ttm_buffer_object *bo = entry->bo;
> -
> - if (entry->put_count) {
> - ttm_bo_list_ref_sub(bo, entry->put_count, true);
> - entry->put_count = 0;
> + if (removed) {
> + ttm_bo_unreserve_locked(bo);
> + } else {
> + atomic_set(&bo->reserved, 0);
> + wake_up_all(&bo->event_queue);
> }
> }
> }
> @@ -93,7 +63,7 @@ void ttm_eu_backoff_reservation(struct list_head *list)
> entry = list_first_entry(list, struct ttm_validate_buffer, head);
> glob = entry->bo->glob;
> spin_lock(&glob->lru_lock);
> - ttm_eu_backoff_reservation_locked(list);
> + ttm_eu_backoff_reservation_locked(list, true);
> spin_unlock(&glob->lru_lock);
> }
> EXPORT_SYMBOL(ttm_eu_backoff_reservation);
> @@ -122,8 +92,6 @@ int ttm_eu_reserve_buffers(struct list_head *list)
>
> list_for_each_entry(entry, list, head) {
> entry->reserved = false;
> - entry->put_count = 0;
> - entry->removed = false;
> }
>
> entry = list_first_entry(list, struct ttm_validate_buffer, head);
> @@ -141,26 +109,37 @@ retry:
> case 0:
> break;
> case -EAGAIN:
> - ttm_eu_backoff_reservation_locked(list);
> + ttm_eu_backoff_reservation_locked(list, false);
> spin_unlock(&glob->lru_lock);
> - ttm_eu_list_ref_sub(list);
> ret = ttm_bo_wait_unreserved(bo, true);
> if (unlikely(ret != 0))
> return ret;
> goto retry;
> default:
> - ttm_eu_backoff_reservation_locked(list);
> + ttm_eu_backoff_reservation_locked(list, false);
> spin_unlock(&glob->lru_lock);
> - ttm_eu_list_ref_sub(list);
> return ret;
> }
>
> entry->reserved = true;
> }
>
> - ttm_eu_del_from_lru_locked(list);
> + list_for_each_entry(entry, list, head) {
> + struct ttm_buffer_object *bo = entry->bo;
> +
> + entry->put_count = ttm_bo_del_from_lru(bo);
> + }
> +
> spin_unlock(&glob->lru_lock);
> - ttm_eu_list_ref_sub(list);
> +
> + list_for_each_entry(entry, list, head) {
> + struct ttm_buffer_object *bo = entry->bo;
> +
> + if (entry->put_count) {
> +
drm/ttm: Remove cpu_writers related code
On Mon, Aug 20, 2012 at 9:32 AM, Maarten Lankhorst
wrote:
> Nobody uses it, so might as well simplify the code some.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Jerome Glisse
> ---
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 36f4b28..ddfe393 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -141,7 +141,6 @@ static void ttm_bo_release_list(struct kref *list_kref)
>
> BUG_ON(atomic_read(&bo->list_kref.refcount));
> BUG_ON(atomic_read(&bo->kref.refcount));
> - BUG_ON(atomic_read(&bo->cpu_writers));
> BUG_ON(bo->sync_obj != NULL);
> BUG_ON(bo->mem.mm_node != NULL);
> BUG_ON(!list_empty(&bo->lru));
> @@ -1050,16 +1049,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
> }
> EXPORT_SYMBOL(ttm_bo_mem_space);
>
> -int ttm_bo_wait_cpu(struct ttm_buffer_object *bo, bool no_wait)
> -{
> - if ((atomic_read(&bo->cpu_writers) > 0) && no_wait)
> - return -EBUSY;
> -
> - return wait_event_interruptible(bo->event_queue,
> - atomic_read(&bo->cpu_writers) == 0);
> -}
> -EXPORT_SYMBOL(ttm_bo_wait_cpu);
> -
> int ttm_bo_move_buffer(struct ttm_buffer_object *bo,
> struct ttm_placement *placement,
> bool interruptible, bool no_wait_reserve,
> @@ -1211,7 +1200,6 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
>
> kref_init(&bo->kref);
> kref_init(&bo->list_kref);
> - atomic_set(&bo->cpu_writers, 0);
> atomic_set(&bo->reserved, 1);
> init_waitqueue_head(&bo->event_queue);
> INIT_LIST_HEAD(&bo->lru);
> @@ -1769,35 +1757,6 @@ int ttm_bo_wait(struct ttm_buffer_object *bo,
> }
> EXPORT_SYMBOL(ttm_bo_wait);
>
> -int ttm_bo_synccpu_write_grab(struct ttm_buffer_object *bo, bool no_wait)
> -{
> - struct ttm_bo_device *bdev = bo->bdev;
> - int ret = 0;
> -
> - /*
> -* Using ttm_bo_reserve makes sure the lru lists are updated.
> -*/
> -
> - ret = ttm_bo_reserve(bo, true, no_wait, false, 0);
> - if (unlikely(ret != 0))
> - return ret;
> - spin_lock(&bdev->fence_lock);
> - ret = ttm_bo_wait(bo, false, true, no_wait);
> - spin_unlock(&bdev->fence_lock);
> - if (likely(ret == 0))
> - atomic_inc(&bo->cpu_writers);
> - ttm_bo_unreserve(bo);
> - return ret;
> -}
> -EXPORT_SYMBOL(ttm_bo_synccpu_write_grab);
> -
> -void ttm_bo_synccpu_write_release(struct ttm_buffer_object *bo)
> -{
> - if (atomic_dec_and_test(&bo->cpu_writers))
> - wake_up_all(&bo->event_queue);
> -}
> -EXPORT_SYMBOL(ttm_bo_synccpu_write_release);
> -
> /**
> * A buffer object shrink method that tries to swap out the first
> * buffer object on the bo_global::swap_lru list.
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index f8187ea..626a3f6 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -439,7 +439,6 @@ static int ttm_buffer_object_transfer(struct
> ttm_buffer_object *bo,
> INIT_LIST_HEAD(&fbo->swap);
> INIT_LIST_HEAD(&fbo->io_reserve_lru);
> fbo->vm_node = NULL;
> - atomic_set(&fbo->cpu_writers, 0);
>
> fbo->sync_obj = driver->sync_obj_ref(bo->sync_obj);
> kref_init(&fbo->list_kref);
> diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> index 3832fe1..3f48a46 100644
> --- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> @@ -181,15 +181,6 @@ retry_this_bo:
> }
>
> entry->reserved = true;
> - if (unlikely(atomic_read(&bo->cpu_writers) > 0)) {
> - ttm_eu_backoff_reservation_locked(list);
> - spin_unlock(&glob->lru_lock);
> - ttm_eu_list_ref_sub(list);
> - ret = ttm_bo_wait_cpu(bo, false);
> - if (ret)
> - return ret;
> - goto retry;
> - }
> }
>
> ttm_eu_del_from_lru_locked(list);
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index e15f2a8..0853162 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -225,12 +225,6 @@ struct ttm_buffer_object {
> bool evicted;
>
> /**
> -* Members protected by the bo::reserved lock only when written to.
> -*/
> -
> - atomic_t cpu_writers;
> -
> - /**
> * Members protected by the bdev::lru_lock.
> */
>
> @@ -423,31 +417,6 @@ extern void ttm_bo_unlock_delayed_workqueue(struct
> ttm_bo_device *bdev,
> int resched);
>
> /**
> - * ttm_bo_synccpu_write_grab
> - *
> - * @bo: The buffer object:
> - * @no_wait
[PATCH] drm/ttm: remove EBUSY handling in ttm_execbuf_util
On Mon, Aug 20, 2012 at 9:42 AM, Maarten Lankhorst
wrote:
> How is this different from just calling with no_wait == false?
> As far as I can tell, both paths end up with the same result..
>
> Signed-off-by: Maarten Lankhorst
NAK this seriously modify the behavior. The ttm_eu_del_from_lru_locked
part is important. It must happen with lru lock held and without any
dropping of this lock prior to wait for bo unreserve.
Cheers,
Jerome
>
> diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> index 3f48a46..4e7b596 100644
> --- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> @@ -82,22 +82,6 @@ static void ttm_eu_list_ref_sub(struct list_head *list)
> }
> }
>
> -static int ttm_eu_wait_unreserved_locked(struct list_head *list,
> -struct ttm_buffer_object *bo)
> -{
> - struct ttm_bo_global *glob = bo->glob;
> - int ret;
> -
> - ttm_eu_del_from_lru_locked(list);
> - spin_unlock(&glob->lru_lock);
> - ret = ttm_bo_wait_unreserved(bo, true);
> - spin_lock(&glob->lru_lock);
> - if (unlikely(ret != 0))
> - ttm_eu_backoff_reservation_locked(list);
> - return ret;
> -}
> -
> -
> void ttm_eu_backoff_reservation(struct list_head *list)
> {
> struct ttm_validate_buffer *entry;
> @@ -152,19 +136,10 @@ retry:
> list_for_each_entry(entry, list, head) {
> struct ttm_buffer_object *bo = entry->bo;
>
> -retry_this_bo:
> - ret = ttm_bo_reserve_locked(bo, true, true, true, val_seq);
> + ret = ttm_bo_reserve_locked(bo, true, false, true, val_seq);
> switch (ret) {
> case 0:
> break;
> - case -EBUSY:
> - ret = ttm_eu_wait_unreserved_locked(list, bo);
> - if (unlikely(ret != 0)) {
> - spin_unlock(&glob->lru_lock);
> - ttm_eu_list_ref_sub(list);
> - return ret;
> - }
> - goto retry_this_bo;
> case -EAGAIN:
> ttm_eu_backoff_reservation_locked(list);
> spin_unlock(&glob->lru_lock);
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/13] drm/exynos: make sure that hardware overlay for fimd is disabled
On 08/17/2012 06:50 PM, Inki Dae wrote:
> the values set to registers will be updated into real registers
> at vsync so dma operation could be malfunctioned when accessed
> to memory after gem buffer was released. this patch makes sure
> that hw overlay is disabled before the gem buffer is released.
>
> Signed-off-by: Inki Dae
> Signed-off-by: Kyungmin Park
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 17 +
> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 10 ++
> drivers/gpu/drm/exynos/exynos_drm_fimd.c| 12
Please split patch to exynos_drm part and fimd part.
> 3 files changed, 39 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 24c45d8..00e4bdc 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -37,6 +37,20 @@
> #define MAX_FB_BUFFER 4
> #define DEFAULT_ZPOS-1
>
> +#define _wait_for(COND, MS) ({ \
> + unsigned long timeout__ = jiffies + msecs_to_jiffies(MS); \
> + int ret__ = 0; \
> + while (!(COND)) { \
> + if (time_after(jiffies, timeout__)) { \
> + ret__ = -ETIMEDOUT; \
> + break; \
> + } \
> + } \
> + ret__; \
> +})
> +
> +#define wait_for(COND, MS) _wait_for(COND, MS)
> +
> struct drm_device;
> struct exynos_drm_overlay;
> struct drm_connector;
> @@ -61,6 +75,8 @@ enum exynos_drm_output_type {
>* @commit: apply hardware specific overlay data to registers.
>* @enable: enable hardware specific overlay.
>* @disable: disable hardware specific overlay.
> + * @wait_for_vblank: wait for vblank interrupt to make sure that
> + * dma transfer is completed.
>*/
> struct exynos_drm_overlay_ops {
> void (*mode_set)(struct device *subdrv_dev,
> @@ -68,6 +84,7 @@ struct exynos_drm_overlay_ops {
> void (*commit)(struct device *subdrv_dev, int zpos);
> void (*enable)(struct device *subdrv_dev, int zpos);
> void (*disable)(struct device *subdrv_dev, int zpos);
> + void (*wait_for_vblank)(struct device *subdrv_dev);
> };
>
> /*
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> index 7da5714..a562a94 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> @@ -399,4 +399,14 @@ void exynos_drm_encoder_plane_disable(struct drm_encoder
> *encoder, void *data)
>
> if (overlay_ops && overlay_ops->disable)
> overlay_ops->disable(manager->dev, zpos);
> +
> + /*
> + * wait for vblank interrupt
> + * - with iommu, the dma operation could induce page fault
> + * when accessed to memory after gem buffer was released so
> + * make sure that the dma operation is completed before releasing
> + * the gem bufer.
> + */
> + if (overlay_ops->wait_for_vblank)
> + overlay_ops->wait_for_vblank(manager->dev);
> }
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 0ec9d86..2378d80 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -570,10 +570,22 @@ static void fimd_win_disable(struct device *dev, int
> zpos)
> win_data->enabled = false;
> }
>
> +static void fimd_wait_for_vblank(struct device *dev)
> +{
> + struct fimd_context *ctx = get_fimd_context(dev);
> + int ret;
> +
> + ret = wait_for((__raw_readl(ctx->regs + VIDCON1) &
> + VIDCON1_VSTATUS_BACKPORCH), 50);
> + if (ret < 0)
> + DRM_DEBUG_KMS("vblank wait timed out.\n");
> +}
> +
> static struct exynos_drm_overlay_ops fimd_overlay_ops = {
> .mode_set = fimd_win_mode_set,
> .commit = fimd_win_commit,
> .disable = fimd_win_disable,
> + .wait_for_vblank = fimd_wait_for_vblank,
> };
>
> static struct exynos_drm_manager fimd_manager = {
Re: [PATCH] drm/ttm: remove EBUSY handling in ttm_execbuf_util
On Mon, Aug 20, 2012 at 1:55 PM, Maarten Lankhorst wrote: > Hey, > > Op 20-08-12 17:15, Jerome Glisse schreef: >> On Mon, Aug 20, 2012 at 9:42 AM, Maarten Lankhorst >> wrote: >>> How is this different from just calling with no_wait == false? >>> As far as I can tell, both paths end up with the same result.. >>> >>> Signed-off-by: Maarten Lankhorst >> NAK this seriously modify the behavior. The ttm_eu_del_from_lru_locked >> part is important. It must happen with lru lock held and without any >> dropping of this lock prior to wait for bo unreserve. >> > > You're right, I missed the part where it removed those, causing the later > patch to be wrong too. However I still think the code can be made more > readable. Wouldn't it be better if it used the unlocked variants instead? > It would save a lot of extra list traversals, and you could drop > removed, reserved and put_count from ttm_validate_buffer. > > ~Maarten > No, as i said the lock can not be drop, i don't see much simplification of this code. Also the path you trying to modify is taken only is some bo is reserved by some other process, which is supposed to be rare event. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/13] drm/exynos: removed exynos_drm_encoder_dpms call
2012/8/20 Joonyoung Shim :
> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>
>> encoder's mode_set callback isn't specific to hardware so it doesn't
>> need to call exynos_drm_encoder_dpms().
>
>
> Then, where is exynos_drm_encoder_dpms() called?
>
with this patch series, exynos_drm_encoder_dpms() will call apply
callback to set local overlay data to real hardware registers and
exynos_drm_crtc_dpms() will be used to enable/disable fimd or hdmi
power(clock and regulator). actually, previous codes called mode_set
two times so this could make it messed up other display sub devices
such as mDNIe.
>
>>
>> Signed-off-by: Inki Dae
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_encoder.c |2 --
>> 1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> index 2c037cd..3dae250 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> @@ -138,8 +138,6 @@ static void exynos_drm_encoder_mode_set(struct
>> drm_encoder *encoder,
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> - exynos_drm_encoder_dpms(encoder, DRM_MODE_DPMS_ON);
>> -
>> list_for_each_entry(connector, &dev->mode_config.connector_list,
>> head) {
>> if (connector->encoder == encoder)
>> if (manager_ops && manager_ops->mode_set)
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/13] drm/exynos: separated subdrv->probe call and encoder/connector creation.
On 08/20/2012 10:52 AM, InKi Dae wrote:
> 2012/8/20 Joonyoung Shim :
>> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>> this patch separates sub driver's probe call and encoder/connector
>>> creation
>>> so that exynos drm core module can take exception when some operation was
>>> failed properly.
>>
>> Which exceptions? I don't know this patch gives any benefit to us.
>>
> previous code didn't take exception when exynos_drm_encoder_create()
> is falied.
No, it is considered.
> and for now, exynos_drm_encoder/connector_create functions
> was called at exynos_drm_subdrv_probe() so know that this patch is for
> code clean by separating them into two parts also.
It's ok, but it just splitting.
>
>>> Signed-off-by: Inki Dae
>>> Signed-off-by: Kyungmin Park
>>> ---
>>>drivers/gpu/drm/exynos/exynos_drm_core.c | 93
>>> +-
>>>1 files changed, 65 insertions(+), 28 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_core.c
>>> index 84dd099..1c8d5fe 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
>>> @@ -34,30 +34,15 @@
>>> static LIST_HEAD(exynos_drm_subdrv_list);
>>>-static int exynos_drm_subdrv_probe(struct drm_device *dev,
>>> +static int exynos_drm_create_enc_conn(struct drm_device *dev,
>>> struct exynos_drm_subdrv *subdrv)
>>>{
>>> struct drm_encoder *encoder;
>>> struct drm_connector *connector;
>>> + int ret;
>>> DRM_DEBUG_DRIVER("%s\n", __FILE__);
>>>- if (subdrv->probe) {
>>> - int ret;
>>> -
>>> - /*
>>> -* this probe callback would be called by sub driver
>>> -* after setting of all resources to this sub driver,
>>> -* such as clock, irq and register map are done or by
>>> load()
>>> -* of exynos drm driver.
>>> -*
>>> -* P.S. note that this driver is considered for
>>> modularization.
>>> -*/
>>> - ret = subdrv->probe(dev, subdrv->dev);
>>> - if (ret)
>>> - return ret;
>>> - }
>>> -
>>> if (!subdrv->manager)
>>> return 0;
>>>@@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct drm_device
>>> *dev,
>>> connector = exynos_drm_connector_create(dev, encoder);
>>> if (!connector) {
>>> DRM_ERROR("failed to create connector\n");
>>> - encoder->funcs->destroy(encoder);
>>> - return -EFAULT;
>>> + ret = -EFAULT;
>>> + goto err_destroy_encoder;
>>> }
>>> subdrv->encoder = encoder;
>>> subdrv->connector = connector;
>>> return 0;
>>> +
>>> +err_destroy_encoder:
>>> + encoder->funcs->destroy(encoder);
>>> + return ret;
>>>}
>>>-static void exynos_drm_subdrv_remove(struct drm_device *dev,
>>> - struct exynos_drm_subdrv *subdrv)
>>> +static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv *subdrv)
>>>{
>>> - DRM_DEBUG_DRIVER("%s\n", __FILE__);
>>> -
>>> - if (subdrv->remove)
>>> - subdrv->remove(dev);
>>> -
>>> if (subdrv->encoder) {
>>> struct drm_encoder *encoder = subdrv->encoder;
>>> encoder->funcs->destroy(encoder);
>>> @@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct drm_device
>>> *dev,
>>> }
>>>}
>>>+static int exynos_drm_subdrv_probe(struct drm_device *dev,
>>> + struct exynos_drm_subdrv *subdrv)
>>> +{
>>> + if (subdrv->probe) {
>>> + int ret;
>>> +
>>> + subdrv->drm_dev = dev;
>>> +
>>> + /*
>>> +* this probe callback would be called by sub driver
>>> +* after setting of all resources to this sub driver,
>>> +* such as clock, irq and register map are done or by
>>> load()
>>> +* of exynos drm driver.
>>> +*
>>> +* P.S. note that this driver is considered for
>>> modularization.
>>> +*/
>>> + ret = subdrv->probe(dev, subdrv->dev);
>>> + if (ret)
>>> + return ret;
>>> + }
>>> +
>>> + if (!subdrv->manager)
>>> + return -EINVAL;
>>> +
>>> + subdrv->manager->dev = subdrv->dev;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static void exynos_drm_subdrv_remove(struct drm_device *dev,
>>> + struct exynos_drm_subdrv *subdrv)
>>> +{
>>> + DRM_DEBUG_DRIVER("%s\n", __FILE__);
>>> +
>>> + if (subdrv->remove)
>>> + subdrv->remove(dev, subdrv->dev);
>>> +}
>>> +
>>>int exynos_drm_device_register(struct d
[RFC PATCH 7/7] drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready
On Mon, Aug 20, 2012 at 04:36:40PM +0100, Matthew Garrett wrote: > On Mon, Aug 20, 2012 at 10:31:04AM -0500, Seth Forshee wrote: > > + /* > > +* For secondary graphics devices shouldn't be initialized > > +* until the handler and primary graphics device have been > > +* registered with vga_switcheroo. > > +* > > +* FIXME: Is vga_default_device() reliable enough for this > > +* purpose? > > +* > > +* FIXME: If vga_switcheroo is disabled secondary devices > > +* never gets initialized. Is this okay? Maybe it is, since > > +* we can't switch to the secondary GPU anyway. > > +*/ > > Won't this break the multiple cards with independent outputs case? Yes, if they don't have a switcheroo handler. I only have experience with one such machine, which had optimus graphics. My recollection is that it did have a switcheroo handler, which was only capable of controlling power to the discrete card.
Re: [PATCH] drm/ttm: remove EBUSY handling in ttm_execbuf_util
Hey, Op 20-08-12 17:15, Jerome Glisse schreef: > On Mon, Aug 20, 2012 at 9:42 AM, Maarten Lankhorst > wrote: >> How is this different from just calling with no_wait == false? >> As far as I can tell, both paths end up with the same result.. >> >> Signed-off-by: Maarten Lankhorst > NAK this seriously modify the behavior. The ttm_eu_del_from_lru_locked > part is important. It must happen with lru lock held and without any > dropping of this lock prior to wait for bo unreserve. > You're right, I missed the part where it removed those, causing the later patch to be wrong too. However I still think the code can be made more readable. Wouldn't it be better if it used the unlocked variants instead? It would save a lot of extra list traversals, and you could drop removed, reserved and put_count from ttm_validate_buffer. ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/13] drm/exynos: separated subdrv->probe call and encoder/connector creation.
2012/8/20 Joonyoung Shim :
> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>
>> this patch separates sub driver's probe call and encoder/connector
>> creation
>> so that exynos drm core module can take exception when some operation was
>> failed properly.
>
>
> Which exceptions? I don't know this patch gives any benefit to us.
>
previous code didn't take exception when exynos_drm_encoder_create()
is falied. and for now, exynos_drm_encoder/connector_create functions
was called at exynos_drm_subdrv_probe() so know that this patch is for
code clean by separating them into two parts also.
>
>>
>> Signed-off-by: Inki Dae
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_core.c | 93
>> +-
>> 1 files changed, 65 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
>> b/drivers/gpu/drm/exynos/exynos_drm_core.c
>> index 84dd099..1c8d5fe 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
>> @@ -34,30 +34,15 @@
>> static LIST_HEAD(exynos_drm_subdrv_list);
>> -static int exynos_drm_subdrv_probe(struct drm_device *dev,
>> +static int exynos_drm_create_enc_conn(struct drm_device *dev,
>> struct exynos_drm_subdrv *subdrv)
>> {
>> struct drm_encoder *encoder;
>> struct drm_connector *connector;
>> + int ret;
>> DRM_DEBUG_DRIVER("%s\n", __FILE__);
>> - if (subdrv->probe) {
>> - int ret;
>> -
>> - /*
>> -* this probe callback would be called by sub driver
>> -* after setting of all resources to this sub driver,
>> -* such as clock, irq and register map are done or by
>> load()
>> -* of exynos drm driver.
>> -*
>> -* P.S. note that this driver is considered for
>> modularization.
>> -*/
>> - ret = subdrv->probe(dev, subdrv->dev);
>> - if (ret)
>> - return ret;
>> - }
>> -
>> if (!subdrv->manager)
>> return 0;
>> @@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct drm_device
>> *dev,
>> connector = exynos_drm_connector_create(dev, encoder);
>> if (!connector) {
>> DRM_ERROR("failed to create connector\n");
>> - encoder->funcs->destroy(encoder);
>> - return -EFAULT;
>> + ret = -EFAULT;
>> + goto err_destroy_encoder;
>> }
>> subdrv->encoder = encoder;
>> subdrv->connector = connector;
>> return 0;
>> +
>> +err_destroy_encoder:
>> + encoder->funcs->destroy(encoder);
>> + return ret;
>> }
>> -static void exynos_drm_subdrv_remove(struct drm_device *dev,
>> - struct exynos_drm_subdrv *subdrv)
>> +static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv *subdrv)
>> {
>> - DRM_DEBUG_DRIVER("%s\n", __FILE__);
>> -
>> - if (subdrv->remove)
>> - subdrv->remove(dev);
>> -
>> if (subdrv->encoder) {
>> struct drm_encoder *encoder = subdrv->encoder;
>> encoder->funcs->destroy(encoder);
>> @@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct drm_device
>> *dev,
>> }
>> }
>> +static int exynos_drm_subdrv_probe(struct drm_device *dev,
>> + struct exynos_drm_subdrv *subdrv)
>> +{
>> + if (subdrv->probe) {
>> + int ret;
>> +
>> + subdrv->drm_dev = dev;
>> +
>> + /*
>> +* this probe callback would be called by sub driver
>> +* after setting of all resources to this sub driver,
>> +* such as clock, irq and register map are done or by
>> load()
>> +* of exynos drm driver.
>> +*
>> +* P.S. note that this driver is considered for
>> modularization.
>> +*/
>> + ret = subdrv->probe(dev, subdrv->dev);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + if (!subdrv->manager)
>> + return -EINVAL;
>> +
>> + subdrv->manager->dev = subdrv->dev;
>> +
>> + return 0;
>> +}
>> +
>> +static void exynos_drm_subdrv_remove(struct drm_device *dev,
>> + struct exynos_drm_subdrv *subdrv)
>> +{
>> + DRM_DEBUG_DRIVER("%s\n", __FILE__);
>> +
>> + if (subdrv->remove)
>> + subdrv->remove(dev, subdrv->dev);
>> +}
>> +
>> int exynos_drm_device_register(struct drm_device *dev)
>> {
>> struct exynos_drm_subdrv *subdrv, *n;
>> + unsigned int fine_cnt = 0;
>> int err;
>> DRM_DEBUG_DRIVER("%s\n", __FILE__);
>> @@ -120,14 +142,27 @@ int exynos_drm_device_register(struct drm_device
>> *
[PATCH V3 2/2] video: drm: exynos: Add device tree support
On 08/17/2012 06:37 PM, Leela Krishna Amudala wrote:
> Hello,
>
> On Fri, Aug 17, 2012 at 6:55 AM, Joonyoung Shim wrote:
>> Hi,
>>
>> 2012/8/16 Leela Krishna Amudala :
>>> Add device tree based discovery support for DRM-FIMD driver.
>>>
>>> Signed-off-by: Leela Krishna Amudala
>>> ---
>>> Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 +
>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 95
>>> -
>>> 2 files changed, 173 insertions(+), 2 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt
>>> b/Documentation/devicetree/bindings/fb/drm-fimd.txt
>>> new file mode 100644
>>> index 000..8ad8814
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
>>> @@ -0,0 +1,80 @@
>>> +* Samsung Display Controller using DRM frame work
>>> +
>>> +The display controller is used to transfer image data from memory to an
>>> +external LCD driver interface. It supports various color formats such as
>>> +rgb and yuv.
>>> +
>>> +Required properties:
>>> + - compatible: Should be "samsung,exynos5-drm" for fimd using DRM frame
>>> work.
>> Just use "samsung,exynos5-fb" and add to support exynos4-fb
>>
> In the first version of this patch set I used "samsung,exynos5-fb",
> but as per Kyungmin Park's suggestion changed it to exynos5-drm.
OK, but this doesn't mean drm device so it is right to use exynos5-fimd.
Add "exynos5-fimd" compatible and also use exynos5-fb, it is used in
s3c-fb driver.
>>> + - reg: physical base address of the controller and length of memory
>>> + mapped region.
>>> + - interrupts: Three interrupts should be specified. The interrupts should
>>> be
>>> + specified in the following order.
>>> + - VSYNC interrupt
>>> + - FIFO level interrupt
>>> + - FIMD System Interrupt
>>> +
>>> + - samsung,fimd-display: This property should specify the phandle of the
>>> + display device node which holds the video interface timing with the
>>> + below mentioned properties.
>>> +
>>> + - lcd-htiming: Specifies the horizontal timing for the overlay. The
>>> + horizontal timing includes four parameters in the following order.
>>> +
>>> + - horizontal back porch (in number of lcd clocks)
>>> + - horizontal front porch (in number of lcd clocks)
>>> + - hsync pulse width (in number of lcd clocks)
>>> + - Display panels X resolution.
>>> +
>>> + - lcd-vtiming: Specifies the vertical timing for the overlay. The
>>> + vertical timing includes four parameters in the following order.
>>> +
>>> + - vertical back porch (in number of lcd lines)
>>> + - vertical front porch (in number of lcd lines)
>>> + - vsync pulse width (in number of lcd clocks)
>>> + - Display panels Y resolution.
>>> +
>>> +
>>> + - samsung,default-window: Specifies the default window number of the fimd
>>> controller.
>>> +
>>> + - samsung,fimd-win-bpp: Specifies the bits per pixel.
>>> +
>>> +Optional properties:
>>> + - supports-mipi-panel: Specifies the lcd is mipi panel type
>> How is this property used?
>>
> As this driver can be interfaced through MIPI or eDP, Arch side code
> will check whether this property is available or not, if it is
> available then it assumes mipi panel is connected and certain clock
> rate will be set to fimd clock, otherwise assumes other panel is
> connected and other clock rate will be set at arch side.
But it is not used currently in the driver.
>
>>> + - samsung,fimd-vidout-rgb: Video output format is RGB.
>>> + - samsung,fimd-inv-vclk: invert video clock polarity.
>>> + - samsung,fimd-frame-rate: Number of video frames per second.
>>> +
>>> +Example:
>>> +
>>> + The following is an example for the fimd controller is split into
>>> + two portions. The SoC specific portion can be specified in the SoC
>>> + specific dts file. The board specific portion can be specified in
>>> the
>>> + board specific dts file.
>>> +
>>> + - SoC Specific portion
>>> +
>>> + fimd {
>>> + compatible = "samsung,exynos5-drm";
>>> + interrupt-parent = <&combiner>;
>>> + reg = <0x1440 0x4>;
>>> + interrupts = <18 5>, <18 4>, <18 6>;
>>> + };
>>> +
>>> + - Board Specific portion
>>> +
>>> + lcd_fimd0: lcd_panel0 {
>>> + lcd-htiming = <4 4 4 480>;
>>> + lcd-vtiming = <4 4 4 320>;
>>> + supports-mipi-panel;
>>> + };
>>> +
>>> + fimd {
>>> + samsung,fimd-display = <&lcd_fimd0>;
>>> + samsung,fimd-vidout-rgb;
>>> + samsung,fimd-inv-vclk;
>>> + samsung,fimd-frame-rate = <60>;
>>> + samsung,default-window = <0>;
>>> + samsung,fimd-win-bpp = <32>;
>>> + };
>>> +
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> b/dr
