[PATCH v3 2/8] drm/exynos: remove needless error handling to property.
This patch removes property error handling. because property couldn't be NULL.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 12
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 12
drivers/gpu/drm/exynos/exynos_drm_ipp.c |5 -
3 files changed, 0 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 7a3e460..5dc0251 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -705,10 +705,6 @@ static int fimc_src_set_addr(struct device *dev,
}
property = &c_node->property;
- if (!property) {
- DRM_ERROR("failed to get property.\n");
- return -EINVAL;
- }
DRM_DEBUG_KMS("%s:prop_id[%d]buf_id[%d]buf_type[%d]\n", __func__,
property->prop_id, buf_id, buf_type);
@@ -1241,10 +1237,6 @@ static int fimc_dst_set_addr(struct device *dev,
}
property = &c_node->property;
- if (!property) {
- DRM_ERROR("failed to get property.\n");
- return -EINVAL;
- }
DRM_DEBUG_KMS("%s:prop_id[%d]buf_id[%d]buf_type[%d]\n", __func__,
property->prop_id, buf_id, buf_type);
@@ -1573,10 +1565,6 @@ static int fimc_ippdrv_start(struct device *dev, enum
drm_exynos_ipp_cmd cmd)
}
property = &c_node->property;
- if (!property) {
- DRM_ERROR("failed to get property.\n");
- return -EINVAL;
- }
fimc_handle_irq(ctx, true, false, true);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index c443c3b..ba5fefd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -720,10 +720,6 @@ static int gsc_src_set_addr(struct device *dev,
}
property = &c_node->property;
- if (!property) {
- DRM_ERROR("failed to get property.\n");
- return -EFAULT;
- }
DRM_DEBUG_KMS("%s:prop_id[%d]buf_id[%d]buf_type[%d]\n", __func__,
property->prop_id, buf_id, buf_type);
@@ -1180,10 +1176,6 @@ static int gsc_dst_set_addr(struct device *dev,
}
property = &c_node->property;
- if (!property) {
- DRM_ERROR("failed to get property.\n");
- return -EFAULT;
- }
DRM_DEBUG_KMS("%s:prop_id[%d]buf_id[%d]buf_type[%d]\n", __func__,
property->prop_id, buf_id, buf_type);
@@ -1565,10 +1557,6 @@ static int gsc_ippdrv_start(struct device *dev, enum
drm_exynos_ipp_cmd cmd)
}
property = &c_node->property;
- if (!property) {
- DRM_ERROR("failed to get property.\n");
- return -EINVAL;
- }
gsc_handle_irq(ctx, true, false, true);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index ba45f9a..cac94fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1487,11 +1487,6 @@ void ipp_sched_cmd(struct work_struct *work)
mutex_lock(&c_node->cmd_lock);
property = &c_node->property;
- if (!property) {
- DRM_ERROR("failed to get property:prop_id[%d]\n",
- c_node->property.prop_id);
- goto err_unlock;
- }
switch (cmd_work->ctrl) {
case IPP_CTRL_PLAY:
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/8] drm/exynos: fix and cleanup ipp subsystem drivers
Hi All. This patch fix some issue and cleanup code. please check my commit and let me know about your comment. Changelog v3: - Subject clean like bellow: * change all subject name from Inki.Dae Changelog v2: - This patch set fixes the following: * consider both case of vflip and hflip: we use vflip, hflip set at the same time for 180 degree supporting. so, we add FLIP_BOTH for fixing warnning. Changelog v1: - This patch set fixes the following: * consider both case of vflip and hflip: we use vflip, hflip set at the same time for 180 degree supporting. so, we add this case. * fix build warning: we don't use directly readl, but this code remained. so, we change it. * fix incorrect interrupt induced by m2m operation : m2m operation call reset function at every time. but we don't disable dma start. so, we add dma stop and capture stop operation. - And code clean like bellow: * change memory variable name : we use 'cmd' in property structure and so on. so, this naming make some confusion. we change 'cmd' to 'c_node' to avoid confusion. * remove needless error handling to property : property could't be NULL. so, we remove error handling about NULL. * correct some comments to abbreviation : we change comments for right grammar. * remove needless parenthesis : we misse changing of fimc side. so, I added it. * remove color bar pattern operation : we don't use color display at writeback. so, remove it. Thank's BR Eunchul Kim Eunchul Kim (6): drm/exynos: change member variable name. drm/exynos: remove needless error handling to property. drm/exynos: consider both case of vflip and hflip. drm/exynos: fix build warning. drm/exynos: correct some comments to abbreviation. drm/exynos: remove needless parenthesis. Jinyoung Jeon (1): drm/exynos: fix incorrect interrupt induced by m2m operation. JoongMock Shin (1): drm/exynos: remove color bar pattern operation. drivers/gpu/drm/exynos/exynos_drm_fimc.c| 47 +-- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 26 --- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 13 ++- drivers/gpu/drm/exynos/exynos_drm_ipp.h |4 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c |3 +- include/uapi/drm/exynos_drm.h |2 + 6 files changed, 40 insertions(+), 55 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/8] drm/exynos: change member variable name.
This patch change current command name from cmd to c_node.
because we are using the member name, 'cmd', for command control ioctl in
another structure.
so, this patch changes it to c_node to avoid such confusing.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c|8
drivers/gpu/drm/exynos/exynos_drm_gsc.c |8
drivers/gpu/drm/exynos/exynos_drm_ipp.c |6 +++---
drivers/gpu/drm/exynos/exynos_drm_ipp.h |4 ++--
drivers/gpu/drm/exynos/exynos_drm_rotator.c |2 +-
5 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 61ea242..7a3e460 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -695,7 +695,7 @@ static int fimc_src_set_addr(struct device *dev,
{
struct fimc_context *ctx = get_fimc_context(dev);
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+ struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;
struct drm_exynos_ipp_config *config;
@@ -1231,7 +1231,7 @@ static int fimc_dst_set_addr(struct device *dev,
{
struct fimc_context *ctx = get_fimc_context(dev);
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+ struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;
struct drm_exynos_ipp_config *config;
@@ -1317,7 +1317,7 @@ static irqreturn_t fimc_irq_handler(int irq, void *dev_id)
{
struct fimc_context *ctx = dev_id;
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+ struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_event_work *event_work =
c_node->event_work;
int buf_id;
@@ -1557,7 +1557,7 @@ static int fimc_ippdrv_start(struct device *dev, enum
drm_exynos_ipp_cmd cmd)
{
struct fimc_context *ctx = get_fimc_context(dev);
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+ struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;
struct drm_exynos_ipp_config *config;
struct drm_exynos_pos img_pos[EXYNOS_DRM_OPS_MAX];
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 5639353..c443c3b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -711,7 +711,7 @@ static int gsc_src_set_addr(struct device *dev,
{
struct gsc_context *ctx = get_gsc_context(dev);
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+ struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;
if (!c_node) {
@@ -1171,7 +1171,7 @@ static int gsc_dst_set_addr(struct device *dev,
{
struct gsc_context *ctx = get_gsc_context(dev);
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+ struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;
if (!c_node) {
@@ -1312,7 +1312,7 @@ static irqreturn_t gsc_irq_handler(int irq, void *dev_id)
{
struct gsc_context *ctx = dev_id;
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+ struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_event_work *event_work =
c_node->event_work;
u32 status;
@@ -1549,7 +1549,7 @@ static int gsc_ippdrv_start(struct device *dev, enum
drm_exynos_ipp_cmd cmd)
{
struct gsc_context *ctx = get_gsc_context(dev);
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+ struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;
struct drm_exynos_ipp_config *config;
struct drm_exynos_pos img_pos[EXYNOS_DRM_OPS_MAX];
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 49eebe9..ba45f9a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1292,7 +1292,7 @@ static int ipp_start_property(struct exynos_drm_ippdrv
*ippdrv,
DRM_DEBUG_KMS("%s:prop_id[%d]\n", __func__, property->prop_id);
/* store command info in ippdrv */
- ippdrv->cmd = c_node;
+ ippdrv->c_node = c_node;
if (!ipp_check_mem_list(c_
[PATCH v3 3/8] drm/exynos: consider both case of vflip and hflip.
This patch considers both case of vflip and hflip.
If we want that the contents in buffer to be rotated to 180 degree,
then we can use h,vflip or 180 degree.
Changelog v2:
- added EXYNOS_DRM_FLIP_BOTH enum value to avoid build warnning.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c|1 +
drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 +-
drivers/gpu/drm/exynos/exynos_drm_rotator.c |1 +
include/uapi/drm/exynos_drm.h |2 ++
4 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 5dc0251..abfff9e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1387,6 +1387,7 @@ static inline bool fimc_check_drm_flip(enum
drm_exynos_flip flip)
case EXYNOS_DRM_FLIP_NONE:
case EXYNOS_DRM_FLIP_VERTICAL:
case EXYNOS_DRM_FLIP_HORIZONTAL:
+ case EXYNOS_DRM_FLIP_BOTH:
return true;
default:
DRM_DEBUG_KMS("%s:invalid flip\n", __func__);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index ba5fefd..3e5b456 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1391,7 +1391,7 @@ static inline bool gsc_check_drm_flip(enum
drm_exynos_flip flip)
case EXYNOS_DRM_FLIP_NONE:
case EXYNOS_DRM_FLIP_VERTICAL:
case EXYNOS_DRM_FLIP_HORIZONTAL:
- case EXYNOS_DRM_FLIP_VERTICAL | EXYNOS_DRM_FLIP_HORIZONTAL:
+ case EXYNOS_DRM_FLIP_BOTH:
return true;
default:
DRM_DEBUG_KMS("%s:invalid flip\n", __func__);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 17e4474..8bf9c50 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -513,6 +513,7 @@ static inline bool rotator_check_drm_flip(enum
drm_exynos_flip flip)
case EXYNOS_DRM_FLIP_NONE:
case EXYNOS_DRM_FLIP_VERTICAL:
case EXYNOS_DRM_FLIP_HORIZONTAL:
+ case EXYNOS_DRM_FLIP_BOTH:
return true;
default:
DRM_DEBUG_KMS("%s:invalid flip\n", __func__);
diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
index e7f52c3..7ed11b2 100644
--- a/include/uapi/drm/exynos_drm.h
+++ b/include/uapi/drm/exynos_drm.h
@@ -185,6 +185,8 @@ enum drm_exynos_flip {
EXYNOS_DRM_FLIP_NONE = (0 << 0),
EXYNOS_DRM_FLIP_VERTICAL = (1 << 0),
EXYNOS_DRM_FLIP_HORIZONTAL = (1 << 1),
+ EXYNOS_DRM_FLIP_BOTH = EXYNOS_DRM_FLIP_VERTICAL |
+ EXYNOS_DRM_FLIP_HORIZONTAL,
};
enum drm_exynos_degree {
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/8] drm/exynos: fix build warning.
This patch fixes erroneous register read. reall function needs register base address + offset but exynos_drm_gsc module used only offset to read a register. so this patch uses gsc_read function instead of readl. Signed-off-by: Eunchul Kim --- drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c b/drivers/gpu/drm/exynos/exynos_drm_gsc.c index 3e5b456..410175a 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c @@ -1592,7 +1592,7 @@ static int gsc_ippdrv_start(struct device *dev, enum drm_exynos_ipp_cmd cmd) exynos_drm_ippnb_send_event(IPP_SET_WRITEBACK, (void *)&set_wb); /* src local path */ - cfg = readl(GSC_IN_CON); + cfg = gsc_read(GSC_IN_CON); cfg &= ~(GSC_IN_PATH_MASK | GSC_IN_LOCAL_SEL_MASK); cfg |= (GSC_IN_PATH_LOCAL | GSC_IN_LOCAL_FIMD_WB); gsc_write(cfg, GSC_IN_CON); -- 1.7.0.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/8] drm/exynos: correct some comments to abbreviation.
This patch cleanup corrects some comments to abbreviation. We would like to prevent it stands misunderstood. Signed-off-by: Eunchul Kim --- drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 +- drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 +- drivers/gpu/drm/exynos/exynos_drm_ipp.c |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c b/drivers/gpu/drm/exynos/exynos_drm_fimc.c index abfff9e..8cfc5a9 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c @@ -25,7 +25,7 @@ #include "exynos_drm_fimc.h" /* - * FIMC is stand for Fully Interactive Mobile Camera and + * FIMC stands for Fully Interactive Mobile Camera and * supports image scaler/rotator and input/output DMA operations. * input DMA reads image data from the memory. * output DMA writes image data to memory. diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c b/drivers/gpu/drm/exynos/exynos_drm_gsc.c index 410175a..509f2f8 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c @@ -25,7 +25,7 @@ #include "exynos_drm_gsc.h" /* - * GSC is stand for General SCaler and + * GSC stands for General SCaler and * supports image scaler/rotator and input/output DMA operations. * input DMA reads image data from the memory. * output DMA writes image data to memory. diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c b/drivers/gpu/drm/exynos/exynos_drm_ipp.c index cac94fe..63bcf92 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c @@ -27,7 +27,7 @@ #include "exynos_drm_iommu.h" /* - * IPP is stand for Image Post Processing and + * IPP stands for Image Post Processing and * supports image scaler/rotator and input/output DMA operations. * using FIMC, GSC, Rotator, so on. * IPP is integration device driver of same attribute h/w -- 1.7.0.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/8] drm/exynos: remove color bar pattern operation.
From: JoongMock Shin
This patch removes color bar pattern register because we don't use the register
anymore.
because it doesn't support color bar feature for writeback operation.
camera driver only supports color bar feature. but IPP doesn't support camera
driver.
Signed-off-by: JoongMock Shin
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 8cfc5a9..a99ceef 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -163,17 +163,14 @@ struct fimc_context {
boolsuspended;
};
-static void fimc_sw_reset(struct fimc_context *ctx, bool pattern)
+static void fimc_sw_reset(struct fimc_context *ctx)
{
u32 cfg;
- DRM_DEBUG_KMS("%s:pattern[%d]\n", __func__, pattern);
+ DRM_DEBUG_KMS("%s\n", __func__);
cfg = fimc_read(EXYNOS_CISRCFMT);
cfg |= EXYNOS_CISRCFMT_ITU601_8BIT;
- if (pattern)
- cfg |= EXYNOS_CIGCTRL_TESTPATTERN_COLOR_BAR;
-
fimc_write(cfg, EXYNOS_CISRCFMT);
/* s/w reset */
@@ -1536,7 +1533,7 @@ static int fimc_ippdrv_reset(struct device *dev)
DRM_DEBUG_KMS("%s\n", __func__);
/* reset h/w block */
- fimc_sw_reset(ctx, false);
+ fimc_sw_reset(ctx);
/* reset scaler capability */
memset(&ctx->sc, 0x0, sizeof(ctx->sc));
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 7/8] drm/exynos: fix incorrect interrupt induced by m2m operation.
From: Jinyoung Jeon
This patch fixes incorrect interrupt induced by m2m operation.
the m2m operation calls s/w reset every frame but there is the case that
the interrupt to m2m operation occures after s/w reset sometimes.
So this patch makes dma and capture operations stop at s/w reset
to avoid incorrect interrupt.
Signed-off-by: Jinyoung Jeon
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index a99ceef..9f52b7f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -169,10 +169,23 @@ static void fimc_sw_reset(struct fimc_context *ctx)
DRM_DEBUG_KMS("%s\n", __func__);
+ /* stop dma operation */
+ cfg = fimc_read(EXYNOS_CISTATUS);
+ if (EXYNOS_CISTATUS_GET_ENVID_STATUS(cfg)) {
+ cfg = fimc_read(EXYNOS_MSCTRL);
+ cfg &= ~EXYNOS_MSCTRL_ENVID;
+ fimc_write(cfg, EXYNOS_MSCTRL);
+ }
+
cfg = fimc_read(EXYNOS_CISRCFMT);
cfg |= EXYNOS_CISRCFMT_ITU601_8BIT;
fimc_write(cfg, EXYNOS_CISRCFMT);
+ /* disable image capture */
+ cfg = fimc_read(EXYNOS_CIIMGCPT);
+ cfg &= ~(EXYNOS_CIIMGCPT_IMGCPTEN_SC | EXYNOS_CIIMGCPT_IMGCPTEN);
+ fimc_write(cfg, EXYNOS_CIIMGCPT);
+
/* s/w reset */
cfg = fimc_read(EXYNOS_CIGCTRL);
cfg |= (EXYNOS_CIGCTRL_SWRST);
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 8/8] drm/exynos: remove needless parenthesis.
This patch removes needless parenthesis. This was pointed out but in case of fimc side. we missed it. Signed-off-by: Eunchul Kim --- drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c b/drivers/gpu/drm/exynos/exynos_drm_fimc.c index 9f52b7f..2c03ffa 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c @@ -1212,7 +1212,7 @@ static int fimc_dst_set_buf_seq(struct fimc_context *ctx, u32 buf_id, } /* sequence id */ - cfg &= (~mask); + cfg &= ~mask; cfg |= (enable << buf_id); fimc_write(cfg, EXYNOS_CIFCNTSEQ); -- 1.7.0.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56405] Distorted graphics on Radeon HD 6620G
https://bugs.freedesktop.org/show_bug.cgi?id=56405 Florian Mickler changed: What|Removed |Added CC||flor...@mickler.org --- Comment #51 from Florian Mickler --- A patch referencing this bug report has been merged in Linux v3.8-rc1: commit bd25f0783dc3fb72e1e2779c2b99b2d34b67fa8a Author: Jerome Glisse Date: Tue Dec 11 11:56:52 2012 -0500 drm/radeon: fix amd afusion gpu setup aka sumo v2 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58166] RV670 AGP regression between drm-fixes and drm-next - no display.
https://bugs.freedesktop.org/show_bug.cgi?id=58166 Florian Mickler changed: What|Removed |Added CC||flor...@mickler.org --- Comment #9 from Florian Mickler --- A patch referencing this bug report has been merged in Linux v3.8-rc1: commit 86a1881d08f65a42c17071a59c0088dbe2870246 Author: Jerome Glisse Date: Wed Dec 12 16:43:15 2012 -0500 drm/radeon: fix fence driver for dma ring when wb is disabled -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58272] Rv670 AGP drm-next ttm errors
https://bugs.freedesktop.org/show_bug.cgi?id=58272 Florian Mickler changed: What|Removed |Added CC||flor...@mickler.org --- Comment #11 from Florian Mickler --- A patch referencing this bug report has been merged in Linux v3.8-rc1: commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb Author: Dave Airlie Date: Fri Dec 14 21:04:46 2012 +1000 radeon: fix regression with eviction since evict caching changes -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv4 3/8] gpu: host1x: Add channel support
On Fri, 2012-12-21 at 13:39 +0200, Terje Bergstrom wrote:
> diff --git a/include/trace/events/host1x.h b/include/trace/events/host1x.h
> index d98d74c..e087910 100644
> --- a/include/trace/events/host1x.h
> +++ b/include/trace/events/host1x.h
> @@ -37,6 +37,214 @@ DECLARE_EVENT_CLASS(host1x,
> TP_printk("name=%s", __entry->name)
> );
>
> +DEFINE_EVENT(host1x, host1x_channel_open,
> + TP_PROTO(const char *name),
> + TP_ARGS(name)
> +);
> +
> +DEFINE_EVENT(host1x, host1x_channel_release,
> + TP_PROTO(const char *name),
> + TP_ARGS(name)
> +);
> +
> +TRACE_EVENT(host1x_cdma_begin,
> + TP_PROTO(const char *name),
> +
> + TP_ARGS(name),
> +
> + TP_STRUCT__entry(
> + __field(const char *, name)
> + ),
> +
> + TP_fast_assign(
> + __entry->name = name;
> + ),
> +
> + TP_printk("name=%s",
> + __entry->name)
> +);
> +
> +TRACE_EVENT(host1x_cdma_end,
> + TP_PROTO(const char *name),
> +
> + TP_ARGS(name),
> +
> + TP_STRUCT__entry(
> + __field(const char *, name)
> + ),
> +
> + TP_fast_assign(
> + __entry->name = name;
> + ),
> +
> + TP_printk("name=%s",
> + __entry->name)
> +);
The above two should be combined into a DECLARE_EVENT_CLASS() and
DEFINE_EVENT()s. Saves text and data space that way.
> +
> +TRACE_EVENT(host1x_cdma_flush,
> + TP_PROTO(const char *name, int timeout),
> +
> + TP_ARGS(name, timeout),
> +
> + TP_STRUCT__entry(
> + __field(const char *, name)
> + __field(int, timeout)
> + ),
> +
> + TP_fast_assign(
> + __entry->name = name;
> + __entry->timeout = timeout;
> + ),
> +
> + TP_printk("name=%s, timeout=%d",
> + __entry->name, __entry->timeout)
> +);
> +
> +TRACE_EVENT(host1x_cdma_push,
> + TP_PROTO(const char *name, u32 op1, u32 op2),
> +
> + TP_ARGS(name, op1, op2),
> +
> + TP_STRUCT__entry(
> + __field(const char *, name)
> + __field(u32, op1)
> + __field(u32, op2)
> + ),
> +
> + TP_fast_assign(
> + __entry->name = name;
> + __entry->op1 = op1;
> + __entry->op2 = op2;
> + ),
> +
> + TP_printk("name=%s, op1=%08x, op2=%08x",
> + __entry->name, __entry->op1, __entry->op2)
> +);
> +
> +TRACE_EVENT(host1x_cdma_push_gather,
> + TP_PROTO(const char *name, u32 mem_id,
> + u32 words, u32 offset, void *cmdbuf),
> +
> + TP_ARGS(name, mem_id, words, offset, cmdbuf),
> +
> + TP_STRUCT__entry(
> + __field(const char *, name)
> + __field(u32, mem_id)
> + __field(u32, words)
> + __field(u32, offset)
> + __field(bool, cmdbuf)
> + __dynamic_array(u32, cmdbuf, words)
> + ),
> +
> + TP_fast_assign(
> + if (cmdbuf) {
> + memcpy(__get_dynamic_array(cmdbuf), cmdbuf+offset,
> + words * sizeof(u32));
> + }
> + __entry->cmdbuf = cmdbuf;
> + __entry->name = name;
> + __entry->mem_id = mem_id;
> + __entry->words = words;
> + __entry->offset = offset;
> + ),
> +
> + TP_printk("name=%s, mem_id=%08x, words=%u, offset=%d, contents=[%s]",
> + __entry->name, __entry->mem_id,
> + __entry->words, __entry->offset,
> + __print_hex(__get_dynamic_array(cmdbuf),
> + __entry->cmdbuf ? __entry->words * 4 : 0))
> +);
> +
> +TRACE_EVENT(host1x_channel_submit,
> + TP_PROTO(const char *name, u32 cmdbufs, u32 relocs, u32 waitchks,
> + u32 syncpt_id, u32 syncpt_incrs),
> +
> + TP_ARGS(name, cmdbufs, relocs, waitchks, syncpt_id, syncpt_incrs),
> +
> + TP_STRUCT__entry(
> + __field(const char *, name)
> + __field(u32, cmdbufs)
> + __field(u32, relocs)
> + __field(u32, waitchks)
> + __field(u32, syncpt_id)
> + __field(u32, syncpt_incrs)
> + ),
> +
> + TP_fast_assign(
> + __entry->name = name;
> + __entry->cmdbufs = cmdbufs;
> + __entry->relocs = relocs;
> + __entry->waitchks = waitchks;
> + __entry->syncpt_id = syncpt_id;
> + __entry->syncpt_incrs = syncpt_incrs;
> + ),
> +
> + TP_printk("name=%s, cmdbufs=%u, relocs=%u, waitchks=%d,"
> + "syncpt_id=%u, syncpt_incrs=%u",
> + __entry->name, __entry->cmdbufs, __entry->relocs, __entry->waitchks,
> + __entry->syncpt_id, __entry->syncpt_incrs)
> +);
> +
> +TRACE_EVENT(host1x_channel_submitted,
> + TP_PROTO(const char *name, u32 syncpt_base, u32 syncpt_max),
> +
> + TP_ARGS(name, syncpt_base, syncpt_max),
> +
> + TP_STRUCT__entry(
> + __field(const char *, name)
> + __field(u32, syncpt_base)
> + __field(u32, sync
[Bug 58272] Rv670 AGP drm-next ttm errors
https://bugs.freedesktop.org/show_bug.cgi?id=58272 --- Comment #12 from Alex Deucher --- Make sure your kernel has this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=0953e76e91f4b6206cef50bd680696dc6bf1ef99 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58655] New: Screen totally corrupted on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58655 Priority: medium Bug ID: 58655 Assignee: dri-devel@lists.freedesktop.org Summary: Screen totally corrupted on CAYMAN Severity: blocker Classification: Unclassified OS: All Reporter: v10la...@myway.de Hardware: Other Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI This is caused by this mesa commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a and kernel 3.8-rc1. I would love if this could be fixed fast as I have another, more important bug that I need to test against newest mesa git, which isn't possible as I can't go above the commit. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58372 --- Comment #9 from Alexandre Demers --- (In reply to comment #8) > (In reply to comment #7) > > Created attachment 71883 [details] > > dmesg with drm-fixes-3.8 > > > > The dmesg message changed after merging in drm-fixes-3.8: > > > > [drm:evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS > > That's a different bug. Please file a new one for that. what you are > seeing is due to a change in mesa: > http://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a Opening it, I'm hitting the same bug. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58656] New: [drm : evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS
https://bugs.freedesktop.org/show_bug.cgi?id=58656 Priority: medium Bug ID: 58656 Assignee: dri-devel@lists.freedesktop.org Summary: [drm : evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS Severity: major Classification: Unclassified OS: All Reporter: alexandre.f.dem...@gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa On cayman, 6950, receiving this error in dmesg and in terminal console. Also, screen is messed up and frozen. I'll be attaching dmesg soon. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58656] [drm : evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS
https://bugs.freedesktop.org/show_bug.cgi?id=58656 --- Comment #1 from Alexandre Demers --- @commit a585b8f3a6681d1138ed1a33ed4c3195a53c2a73 Make IsVertexArray... -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58656] [drm : evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS
https://bugs.freedesktop.org/show_bug.cgi?id=58656 Alexandre Demers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Alexandre Demers --- *** This bug has been marked as a duplicate of bug 58655 *** -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58655] Screen totally corrupted on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58655 Alexandre Demers changed: What|Removed |Added CC||alexandre.f.dem...@gmail.co ||m --- Comment #1 from Alexandre Demers --- *** Bug 58656 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58655] Screen totally corrupted on CAYMAN, [drm : evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS
https://bugs.freedesktop.org/show_bug.cgi?id=58655 Alexandre Demers changed: What|Removed |Added Summary|Screen totally corrupted on |Screen totally corrupted on |CAYMAN |CAYMAN, [drm : ||evergreen_vm_reg_valid] ||*ERROR* Invalid register ||0x8040 in CS -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58655] Screen totally corrupted on CAYMAN, [drm : evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS
https://bugs.freedesktop.org/show_bug.cgi?id=58655 --- Comment #2 from Alex Deucher --- Mesa hadn't previously emitted that register for cayman so the kernel wasn't expecting it. Fixed with this patch: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.8&id=668bbc81baf0f34df832d8aca5c7d5e19a493c68 Which should show up in 3.8 and stable soon. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58655] Screen totally corrupted on CAYMAN, [drm : evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS
https://bugs.freedesktop.org/show_bug.cgi?id=58655 Thomas Rohloff changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Thomas Rohloff --- Thanks, that small patch fixes it. :) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58658] New: Minecraft menu broken on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58658 Priority: medium Bug ID: 58658 Assignee: dri-devel@lists.freedesktop.org Summary: Minecraft menu broken on CAYMAN Severity: normal Classification: Unclassified OS: All Reporter: v10la...@myway.de Hardware: Other Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI Created attachment 71997 --> https://bugs.freedesktop.org/attachment.cgi?id=71997&action=edit Screenshot of the broken menu. This is on newest mesa from git with kernel 3.8-rc1 (+ this patch: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.8&id=668bbc81baf0f34df832d8aca5c7d5e19a493c68 ) When the Mojang loading screen should stop and the menu should be rendered all that happens is that the menus background is rendered in one edge, see attachment. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58658] Minecraft menu broken on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58658 --- Comment #1 from Thomas Rohloff --- Sorry for the wrong mime-type. The screenshot is image/png, not text/plain. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58658] Minecraft menu broken on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58658 Thomas Rohloff changed: What|Removed |Added Attachment #71997|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58659] New: With latest kernel 3.8-rc1, compiz crashes after boot
https://bugs.freedesktop.org/show_bug.cgi?id=58659 Priority: medium Bug ID: 58659 Assignee: dri-devel@lists.freedesktop.org Summary: With latest kernel 3.8-rc1, compiz crashes after boot Severity: normal Classification: Unclassified OS: All Reporter: bryanquig...@ubuntu.com Hardware: Other Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI Created attachment 71998 --> https://bugs.freedesktop.org/attachment.cgi?id=71998&action=edit syslog The bug was introduced in drm-next between 12/06 and 12/11 according to ubuntu's kernel builds here: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/2012-12-11-raring/ Error messages from syslog attached. 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV670 [Radeon HD 3870] I am using Xorg-Edgers mesa/Xorg, but the crash also appears when I go back to stable mesa/Xorg. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58660] New: Radeon HD 6950 completely broken.
https://bugs.freedesktop.org/show_bug.cgi?id=58660 Priority: medium Bug ID: 58660 Assignee: dri-devel@lists.freedesktop.org Summary: Radeon HD 6950 completely broken. Severity: normal Classification: Unclassified OS: All Reporter: v10la...@myway.de Hardware: Other Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI I own a Sapphire Radeon HD 6950. This card has a dual-bios where one of them has unlocked shaders (Radeon HD 6970). This is not a modded BIOS, it's made by Sapphire and fully supported by them. Now my problem is that with the Radeon HD 6950 BIOS (locked shaders) the GPU seems to hang as soon as compiz starts. With the unlocked BIOS it starts just fine. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58660] Radeon HD 6950 completely broken.
https://bugs.freedesktop.org/show_bug.cgi?id=58660 --- Comment #1 from Thomas Rohloff --- Forget to say: This is on newest mesa from git with kernel 3.8-rc1 (+ this patch: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.8&id=668bbc81baf0f34df832d8aca5c7d5e19a493c68 ) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58661] New: Chat text and other things flashing in Minecraft on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58661 Priority: medium Bug ID: 58661 Assignee: dri-devel@lists.freedesktop.org Summary: Chat text and other things flashing in Minecraft on CAYMAN Severity: normal Classification: Unclassified OS: All Reporter: v10la...@myway.de Hardware: Other Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI This is on newest mesa from git with kernel 3.8-rc1 (+ this patch: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.8&id=668bbc81baf0f34df832d8aca5c7d5e19a493c68 ) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58661] Chat text and other things flashing in Minecraft on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58661 --- Comment #1 from Thomas Rohloff --- As it is to large for a attachment here a link to a video showing the issue: https://www.dropbox.com/s/981hzit2ittwgyz/out-85.ogv -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
Hi Alex, got the sickest bug on 3.8-rc1, see below. The GPU locks up somewhere down radeon_fence_wait_seq, judging by the error messages. And this doesn't happen with 3.7, of course. Let me know if you need any more info, thanks. [16273.668350] radeon :02:00.0: GPU lockup CP stall for more than 1msec [16273.668361] radeon :02:00.0: GPU lockup (waiting for 0x002b last fence id 0x002a) [16273.882550] plugin-containe[11435]: segfault at 7f1f0a66cc08 ip 7f1f13289bdb sp 7f1f0a2fe9e0 error 4 in libflashplayer.so[7f1f130c5000+117b000] [16274.502807] [ cut here ] [16274.502845] WARNING: at lib/list_debug.c:53 __list_del_entry+0x63/0xd0() [16274.502880] Hardware name: [16274.502897] list_del corruption, 8802216a3f10->next is LIST_POISON1 (dead00100100) [16274.502939] Modules linked in: nls_iso8859_15 nls_cp437 acpi_cpufreq mperf cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats binfmt_misc dm_crypt dm_mod ipv6 vfat fat fuse kvm_amd kvm radeon drm_kms_helper ttm edac_core microcode cfbfillrect cfbimgblt cfbcopyarea k10temp [16274.503141] Pid: 17386, comm: Xorg Not tainted 3.8.0-rc1 #13 [16274.503172] Call Trace: [16274.503190] [] ? __list_del_entry+0x60/0xd0 [16274.503224] [] warn_slowpath_common+0x7f/0xc0 [16274.503257] [] warn_slowpath_fmt+0x46/0x50 [16274.503289] [] __list_del_entry+0x63/0xd0 [16274.503320] [] list_del+0x11/0x40 [16274.503348] [] drm_mm_remove_node+0x9e/0xd0 [16274.503383] [] drm_mm_put_block+0x25/0x70 [16274.503422] [] ? ttm_bo_man_put_node+0x31/0x60 [ttm] [16274.503464] [] ttm_bo_man_put_node+0x39/0x60 [ttm] [16274.503503] [] ttm_bo_cleanup_memtype_use+0x80/0xb0 [ttm] [16274.503545] [] ttm_bo_release+0x1fb/0x270 [ttm] [16274.503585] [] ttm_bo_unref+0x31/0x40 [ttm] [16274.503656] [] radeon_bo_unref+0x47/0x80 [radeon] [16274.503707] [] radeon_gem_object_free+0x39/0x40 [radeon] [16274.503748] [] drm_gem_object_free+0x29/0x30 [16274.503781] [] drm_gem_object_release_handle+0xb8/0xd0 [16274.503819] [] idr_for_each+0xdd/0x180 [16274.503850] [] ? drm_gem_handle_create+0x100/0x100 [16274.503887] [] ? trace_hardirqs_on+0xd/0x10 [16274.503920] [] drm_gem_release+0x24/0x40 [16274.503952] [] drm_release+0x54a/0x5e0 [16274.503984] [] ? lg_local_unlock+0x42/0x70 [16274.504016] [] __fput+0xb2/0x240 [16274.504044] [] fput+0xe/0x10 [16274.504073] [] task_work_run+0xb5/0xd0 [16274.504105] [] do_exit+0x23a/0xac0 [16274.504135] [] do_group_exit+0x4c/0xc0 [16274.504167] [] get_signal_to_deliver+0x22d/0x960 [16274.504202] [] do_signal+0x3f/0x5a0 [16274.504233] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [16274.504269] [] do_notify_resume+0x5d/0x90 [16274.504300] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [16274.504337] [] int_signal+0x12/0x17 [16274.504366] ---[ end trace 4aad5b52e5533e3e ]--- -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Bisected regression on RV610
Hello, Alex! Thank you for your reply! Quoting Alex Deucher : That patch only affects SI chips which yours is not, so it's probably not what's causing problems for you. OK, maybe. Bisection can lead to a wrong commit if the problem is not 100% reproducible. This looks like a duplicate of this issue: http://lists.freedesktop.org/archives/dri-devel/2012-December/032139.html http://lists.freedesktop.org/archives/dri-devel/2012-December/032291.html Some of the ttm changes in 3.8 seem problematic. I'm away wrong that system until Wednesday. I'll try that patch. If it doesn't help, I'll repeat the bisection. -- Regards, Pavel Roskin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm: Added ppc64 root device getter
On 12/13/2012 09:31 PM, Bjorn Helgaas wrote:
[+cc Betty]
On Thu, Dec 13, 2012 at 4:04 PM, Lucas Kannebley Tavares
wrote:
On architectures such as ppc64, there is no root bus device (it belongs
to the hypervisor). DRM attempted to get one, causing a null-pointer
dereference.
In addition to ppc64, at least ia64 and parisc have the same situation
of the PCI host bridge not appearing as a PCI device itself.
Signed-off-by: Lucas Kannebley Tavares
--
diff --git a/arch/powerpc/platforms/pseries/Makefile
b/arch/powerpc/platforms/pseries/Makefile
index 890622b..ddfdda8 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -1,6 +1,8 @@
ccflags-$(CONFIG_PPC64):= -mno-minimal-toc
ccflags-$(CONFIG_PPC_PSERIES_DEBUG)+= -DDEBUG
+drm-y += drm_pci.o
+
obj-y := lpar.o hvCall.o nvram.o reconfig.o \
setup.o iommu.o event_sources.o ras.o \
firmware.o power.o dlpar.o mobility.o
diff --git a/arch/powerpc/platforms/pseries/drm_pci.c
b/arch/powerpc/platforms/pseries/drm_pci.c
new file mode 100644
index 000..da6675e
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/drm_pci.c
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2012 Lucas Kannebley Tavares, IBM Corporation
+ *
+ * pSeries specific routines for DRM.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+inline struct pci_device *drm_get_parent_device(struct drm_device *dev) {
+ return (dev->pdev->bus->self == NULL) ? dev->pdev :
dev->pdev->bus->self;
So for DRM devices on a root bus, the parent is the DRM device itself,
while for DRM devices deeper in the hierarchy, the parent is the
upstream P2P bridge? That doesn't really make sense to me. If the
caller operates on the DRM device in some cases and on the bridge in
other cases, it's going to need to know the difference, so hiding the
difference in this wrapper seems counterproductive.
+}
+
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index eb37466..5a8a4f5 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -466,6 +466,10 @@ void drm_pci_exit(struct drm_driver *driver, struct
pci_driver *pdriver)
}
EXPORT_SYMBOL(drm_pci_exit);
+inline __weak struct pci_device *drm_get_parent_device(struct drm_device
*dev) {
+ return dev->pdev->bus->self;
+}
+
int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 *mask)
{
struct pci_dev *root;
@@ -479,7 +483,7 @@ int drm_pcie_get_speed_cap_mask(struct drm_device *dev,
u32 *mask)
return -EINVAL;
// find PCI device for capabilities
- root = dev->pdev->bus->self;
+ root = drm_get_parent_device(dev);
// some architectures might not have host bridges as PCI devices
if (root == NULL)
What tree does this apply to? Upstream doesn't have the "if (root ==
NULL)" check yet. That check looks like the sort of thing you'd need
to avoid the null pointer dereference. So maybe adding that check and
the associated code is enough to fix the problem, even without adding
drm_get_parent_device().
With the code in the tree, it looks like you'd dereference a null
pointer in pci_pcie_cap(root), so I assume that's what you tripped
over.
I'm not really sure that code outside the PCI core should be looking
at capabilities of upstream devices like this. It seems like the sort
of thing where the core might need to provide better interfaces.
Bjorn
Ok Bjorn, thanks for the comments, indeed I had a dirty tree here and
didn't realize it, sorry. Either way I'm then sending the "if (root ==
NULL)" patch as a reply to this. I'm sending it along with another
independent patch (they are NOT a series) that changes
pci_read_config_dword calls to pci_capability_read_dword ones on the drm
driver. There were only a couple of those to start with.
--
Lucas Kannebley Tavares
Software Engineer
IBM Linux Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: fixed access to PCI host bridges
During the process of obtaining the speed cap for the device, it attempts go get the PCI Host bus. However on architectures such as PPC or IA64, those do not appear as devices. Signed-off-by: Lucas Kannebley Tavares --- drivers/gpu/drm/drm_pci.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c index 754bc96..ea41234 100644 --- a/drivers/gpu/drm/drm_pci.c +++ b/drivers/gpu/drm/drm_pci.c @@ -479,8 +479,13 @@ int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 *mask) if (!pci_is_pcie(dev->pdev)) return -EINVAL; + // find PCI device for capabilities root = dev->pdev->bus->self; + // some architectures might not have host bridges as PCI devices + if (root == NULL) + root = dev->pdev; + pos = pci_pcie_cap(root); if (!pos) return -EINVAL; -- Lucas Kannebley Tavares Software Engineer IBM Linux Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: change pci_read_config_dword calls to pcie_capability_read_dword ones
Replacing these calls avoids compatibility problems with PCIe v1/v2 Capability structures. Signed-off-by: Lucas Kannebley Tavares --- drivers/gpu/drm/drm_pci.c |8 ++-- 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c index ea41234..b824d4c 100644 --- a/drivers/gpu/drm/drm_pci.c +++ b/drivers/gpu/drm/drm_pci.c @@ -486,17 +486,13 @@ int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 *mask) if (root == NULL) root = dev->pdev; - pos = pci_pcie_cap(root); - if (!pos) - return -EINVAL; - /* we've been informed via and serverworks don't make the cut */ if (root->vendor == PCI_VENDOR_ID_VIA || root->vendor == PCI_VENDOR_ID_SERVERWORKS) return -EINVAL; - pci_read_config_dword(root, pos + PCI_EXP_LNKCAP, &lnkcap); - pci_read_config_dword(root, pos + PCI_EXP_LNKCAP2, &lnkcap2); + pcie_capability_read_dword(root, PCI_EXP_LNKCAP, &lnkcap); + pcie_capability_read_dword(root, PCI_EXP_LNKCAP, &lnkcap2); lnkcap &= PCI_EXP_LNKCAP_SLS; lnkcap2 &= 0xfe; -- Lucas Kannebley Tavares Software Engineer IBM Linux Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[regression v3.7] Xorg slow and studdering on Thinkpad X300 (GMA 965)
Hi! I've noticed a regression using 3.7 on my Thinkpad X300. In Cinnamon and in KDE with Desktop Effects, all graphics are slow and studdering. Moving a window results in about 5 frames per second. glxgears achieves about 14 fps, versus ~60 in unaffected kernels. X is from Debian unstable: X.Org X Server 1.12.4 Release Date: 2012-08-27 (II) intel(0): Integrated Graphics Chipset: Intel(R) 965GM (--) intel(0): Chipset: "965GM" I did a bisect on this: f047e395ddc9da6c307a10629a237502e627ed85 is the first bad commit. a7b9761d0a2ded58170ffb4d423ff3d7228103f4 is "good". If you need more information, please ask. Regards, Bernhard ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58272] Rv670 AGP drm-next ttm errors
https://bugs.freedesktop.org/show_bug.cgi?id=58272 --- Comment #13 from Andy Furniss --- (In reply to comment #12) > Make sure your kernel has this patch: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff; > h=0953e76e91f4b6206cef50bd680696dc6bf1ef99 I tested drm-next head when that went in and got the same results. I've just rebuilt it to be sure and with etqw I get a segfault after about 10 secs and in dmesg - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! I've also managed to reproduce the GPU lock + oops I reported earlier - this time with nexuiz on current drm-next head. I am not getting ttm errors any more so I guess this bug should be closed? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58166] RV670 AGP regression between drm-fixes and drm-next - no display.
https://bugs.freedesktop.org/show_bug.cgi?id=58166 Andy Furniss changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58372 --- Comment #10 from Serkan Hosca --- (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > Created attachment 71883 [details] > > > dmesg with drm-fixes-3.8 > > > > > > The dmesg message changed after merging in drm-fixes-3.8: > > > > > > [drm:evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS > > > > That's a different bug. Please file a new one for that. what you are > > seeing is due to a change in mesa: > > http://cgit.freedesktop.org/mesa/mesa/commit/ > > ?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a > > Opening it, I'm hitting the same bug. You need this: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.8&id=668bbc81baf0f34df832d8aca5c7d5e19a493c68 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58658] Minecraft menu broken on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58658 --- Comment #2 from Alex Deucher --- I suspect this is a mesa 3D driver issue rather than a kernel issue. Was this working in the past? Can you bisect? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot
https://bugs.freedesktop.org/show_bug.cgi?id=58659 --- Comment #1 from Alex Deucher --- Make sure your kernel has this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=0953e76e91f4b6206cef50bd680696dc6bf1ef99 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58666] New: rv670 + llvm = errors.
https://bugs.freedesktop.org/show_bug.cgi?id=58666 Priority: medium Bug ID: 58666 Assignee: dri-devel@lists.freedesktop.org Summary: rv670 + llvm = errors. Severity: normal Classification: Unclassified OS: Linux (All) Reporter: li...@andyfurniss.entadsl.com Hardware: x86 (IA32) Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa I've only just tested this AGP HD3850 card with tstellar LLVM (or any llvm) as it's been out of the PC since Feb. Both last week and now with updated llvm/mesa gits, running anything eg. gears will just flood - EE r600_asm.c:122 r600_bytecode_get_num_operands - Need instruction operand number for 0xc. Works OK with R600_LLVM=0 This was tested with drm-fixes kernel. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58660] Radeon HD 6950 completely broken with sapphire unlocked vbios
https://bugs.freedesktop.org/show_bug.cgi?id=58660 Alex Deucher changed: What|Removed |Added Summary|Radeon HD 6950 completely |Radeon HD 6950 completely |broken. |broken with sapphire ||unlocked vbios --- Comment #2 from Alex Deucher --- Please attach the dmesg output when booting with both video bioses. Also, please attach both video bioses. To dump the video bios: (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/ echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58661] Chat text and other things flashing in Minecraft on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58661 --- Comment #2 from Alex Deucher --- I suspect this is a mesa 3D driver issue rather than a kernel issue. Was this working in the past? Can you bisect? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sat, Dec 22, 2012 at 3:35 PM, Borislav Petkov wrote: > Hi Alex, > > got the sickest bug on 3.8-rc1, see below. The GPU locks up somewhere > down radeon_fence_wait_seq, judging by the error messages. > > And this doesn't happen with 3.7, of course. > > Let me know if you need any more info, thanks. What chip is this? Alex > > [16273.668350] radeon :02:00.0: GPU lockup CP stall for more than > 1msec > [16273.668361] radeon :02:00.0: GPU lockup (waiting for > 0x002b last fence id 0x002a) > [16273.882550] plugin-containe[11435]: segfault at 7f1f0a66cc08 ip > 7f1f13289bdb sp 7f1f0a2fe9e0 error 4 in > libflashplayer.so[7f1f130c5000+117b000] > [16274.502807] [ cut here ] > [16274.502845] WARNING: at lib/list_debug.c:53 __list_del_entry+0x63/0xd0() > [16274.502880] Hardware name: > [16274.502897] list_del corruption, 8802216a3f10->next is LIST_POISON1 > (dead00100100) > [16274.502939] Modules linked in: nls_iso8859_15 nls_cp437 acpi_cpufreq mperf > cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats > binfmt_misc dm_crypt dm_mod ipv6 vfat fat fuse kvm_amd kvm radeon > drm_kms_helper ttm edac_core microcode cfbfillrect cfbimgblt cfbcopyarea > k10temp > [16274.503141] Pid: 17386, comm: Xorg Not tainted 3.8.0-rc1 #13 > [16274.503172] Call Trace: > [16274.503190] [] ? __list_del_entry+0x60/0xd0 > [16274.503224] [] warn_slowpath_common+0x7f/0xc0 > [16274.503257] [] warn_slowpath_fmt+0x46/0x50 > [16274.503289] [] __list_del_entry+0x63/0xd0 > [16274.503320] [] list_del+0x11/0x40 > [16274.503348] [] drm_mm_remove_node+0x9e/0xd0 > [16274.503383] [] drm_mm_put_block+0x25/0x70 > [16274.503422] [] ? ttm_bo_man_put_node+0x31/0x60 [ttm] > [16274.503464] [] ttm_bo_man_put_node+0x39/0x60 [ttm] > [16274.503503] [] ttm_bo_cleanup_memtype_use+0x80/0xb0 > [ttm] > [16274.503545] [] ttm_bo_release+0x1fb/0x270 [ttm] > [16274.503585] [] ttm_bo_unref+0x31/0x40 [ttm] > [16274.503656] [] radeon_bo_unref+0x47/0x80 [radeon] > [16274.503707] [] radeon_gem_object_free+0x39/0x40 [radeon] > [16274.503748] [] drm_gem_object_free+0x29/0x30 > [16274.503781] [] drm_gem_object_release_handle+0xb8/0xd0 > [16274.503819] [] idr_for_each+0xdd/0x180 > [16274.503850] [] ? drm_gem_handle_create+0x100/0x100 > [16274.503887] [] ? trace_hardirqs_on+0xd/0x10 > [16274.503920] [] drm_gem_release+0x24/0x40 > [16274.503952] [] drm_release+0x54a/0x5e0 > [16274.503984] [] ? lg_local_unlock+0x42/0x70 > [16274.504016] [] __fput+0xb2/0x240 > [16274.504044] [] fput+0xe/0x10 > [16274.504073] [] task_work_run+0xb5/0xd0 > [16274.504105] [] do_exit+0x23a/0xac0 > [16274.504135] [] do_group_exit+0x4c/0xc0 > [16274.504167] [] get_signal_to_deliver+0x22d/0x960 > [16274.504202] [] do_signal+0x3f/0x5a0 > [16274.504233] [] ? trace_hardirqs_on_thunk+0x3a/0x3f > [16274.504269] [] do_notify_resume+0x5d/0x90 > [16274.504300] [] ? trace_hardirqs_on_thunk+0x3a/0x3f > [16274.504337] [] int_signal+0x12/0x17 > [16274.504366] ---[ end trace 4aad5b52e5533e3e ]--- > > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] New: Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 Priority: medium Bug ID: 58667 Assignee: dri-devel@lists.freedesktop.org Summary: Random crashes on CAYMAN Severity: normal Classification: Unclassified OS: All Reporter: v10la...@myway.de Hardware: Other Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI This is with newest mesa from git with kernel 3.8-rc1 (+ this patch: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.8&id=668bbc81baf0f34df832d8aca5c7d5e19a493c68 ) The screen first freezes (mouse still movable, keyboard not responding, not even to MagSysRQ), then the monitor goes off (standby) and back on with only garbage on the screen. Not sure if this has anything to do with it (but it should get fixed anyway) but dmesg gets spammed with this: [ 533.928472] radeon :03:00.0: GPU fault detected: 146 0x00335514 [ 533.928477] radeon :03:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 533.928483] radeon :03:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x where the address isn't always the same, example: [ 533.928374] radeon :03:00.0: GPU fault detected: 146 0x0033ed14 [ 533.928379] radeon :03:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 533.928385] radeon :03:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #1 from Thomas Rohloff --- Created attachment 72006 --> https://bugs.freedesktop.org/attachment.cgi?id=72006&action=edit Full dmesg output -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #2 from Alex Deucher --- Is this a regression? Does it happen with older versions of mesa or kernel? If it's a regression can you identify which component (mesa or kernel) and bisect? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #3 from Alex Deucher --- Can you get the dmesg output when the lockup happens? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #3 from Alex Deucher --- May also be related to bug 58354. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58660] Radeon HD 6950 completely broken with sapphire unlocked vbios
https://bugs.freedesktop.org/show_bug.cgi?id=58660 --- Comment #3 from Thomas Rohloff --- The thing is that I can't access dmesg after the crash. Not even SysMagRQ works. See my dmesg with the other BIOS here: https://bugs.freedesktop.org/attachment.cgi?id=72006 I have the BIOSes still lying around somewhere. Let me search real quick. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58660] Radeon HD 6950 completely broken with sapphire unlocked vbios
https://bugs.freedesktop.org/show_bug.cgi?id=58660 --- Comment #4 from Thomas Rohloff --- Created attachment 72008 --> https://bugs.freedesktop.org/attachment.cgi?id=72008&action=edit BIOS 0 (locked shaders) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58660] Radeon HD 6950 completely broken with sapphire unlocked vbios
https://bugs.freedesktop.org/show_bug.cgi?id=58660 --- Comment #5 from Thomas Rohloff --- Created attachment 72009 --> https://bugs.freedesktop.org/attachment.cgi?id=72009&action=edit BIOS 1 (unlocked shaders) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58658] Minecraft menu broken on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58658 --- Comment #3 from Thomas Rohloff --- I'm not sure if it's mesa or kernel. Yes, it was working before last update (updated mesa + kernel). I might be able to bisect later but atm my time is limited and as I don't even know what to bisect (kernel or mesa) it may take some time. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sat, Dec 22, 2012 at 07:01:31PM -0500, Alex Deucher wrote: > What chip is this? I think it is RV635. Here's the whole 3.8-rc1 dmesg. [0.00] Linux version 3.8.0-rc1 (boris@liondog) (gcc version 4.7.2 (Debian 4.7.2-4) ) #13 SMP PREEMPT Sat Dec 22 11:48:54 CET 2012 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1 root=/dev/sda1 ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend ignore_loglevel hpet=force [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009f7ff] usable [0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcffe] usable [0.00] BIOS-e820: [mem 0xcfff-0xcfff2fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcfff3000-0xcfff] ACPI data [0.00] BIOS-e820: [mem 0xd000-0xdfff] reserved [0.00] BIOS-e820: [mem 0xf000-0xf7ff] reserved [0.00] BIOS-e820: [mem 0xfec0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00022fff] usable [0.00] debug: ignoring loglevel setting. [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.3 present. [0.00] DMI:/M57SLI-S4, BIOS FF 01/24/2008 [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 = 0x23 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-C7FFF write-protect [0.00] C8000-E uncachable [0.00] F-F write-through [0.00] MTRR variable ranges enabled: [0.00] 0 base mask 8000 write-back [0.00] 1 base 8000 mask C000 write-back [0.00] 2 base C000 mask F000 write-back [0.00] 3 base 0001 mask write-back [0.00] 4 base 0002 mask E000 write-back [0.00] 5 base 00022000 mask F000 write-back [0.00] 6 disabled [0.00] 7 disabled [0.00] TOM2: 00023000 aka 8960M [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: update [mem 0xd000-0x] usable ==> reserved [0.00] e820: last_pfn = 0xcfff0 max_arch_pfn = 0x4 [0.00] initial memory mapped: [mem 0x-0x1fff] [0.00] Base memory trampoline at [88099000] 99000 size 24576 [0.00] Using GB pages for direct mapping [0.00] init_memory_mapping: [mem 0x-0xcffe] [0.00] [mem 0x-0xbfff] page 1G [0.00] [mem 0xc000-0xcfdf] page 2M [0.00] [mem 0xcfe0-0xcffe] page 4k [0.00] kernel direct mapping tables up to 0xcffe @ [mem 0x1fffd000-0x1fff] [0.00] init_memory_mapping: [mem 0x1-0x22fff] [0.00] [mem 0x1-0x1] page 1G [0.00] [mem 0x2-0x22fff] page 2M [0.00] kernel direct mapping tables up to 0x22fff @ [mem 0xcffee000-0xcffe] [0.00] ACPI: RSDP 000f6620 00014 (v00 GBT ) [0.00] ACPI: RSDT cfff3000 00038 (v01 GBTNVDAACPI 42302E31 NVDA 01010101) [0.00] ACPI: FACP cfff3040 00074 (v01 GBTNVDAACPI 42302E31 NVDA 01010101) [0.00] ACPI: DSDT cfff30c0 04C8E (v01 GBTNVDAACPI 1000 MSFT 010C) [0.00] ACPI: FACS cfff 00040 [0.00] ACPI: SSDT cfff7e40 004CE (v01 PTLTD POWERNOW 0001 LTP 0001) [0.00] ACPI: HPET cfff8340 00038 (v01 GBTNVDAACPI 42302E31 NVDA 0098) [0.00] ACPI: MCFG cfff8380 0003C (v01 GBTNVDAACPI 42302E31 NVDA 01010101) [0.00] ACPI: APIC cfff7d80 00098 (v01 GBTNVDAACPI 42302E31 NVDA 01010101) [0.00] ACPI: Local APIC address 0xfee0 [0.00] [ea00-ea0008bf] PMD -> [88022760-88022f5f] on node 0 [0.00] Zone ranges: [0.00] DMA [mem 0x0001-0x00ff] [0.00] DMA32[mem 0x0100-0x] [0.00] Normal [mem 0x1-0x22fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x0001-0x0009efff] [0.00] node 0: [mem 0x0010-0xcffe] [0.00] node 0: [mem 0x1-0x22fff] [0.00] On node 0 totalpages: 2097023 [0.00] DMA zo
[Bug 58661] Chat text and other things flashing in Minecraft on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58661 --- Comment #3 from Thomas Rohloff --- I'm not sure if it's mesa or kernel. Yes, it was working before last update (updated mesa + kernel). I might be able to bisect later but atm my time is limited and as I don't even know what to bisect (kernel or mesa) it may take some time. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58661] Chat text and other things flashing in Minecraft on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58661 --- Comment #4 from Thomas Rohloff --- Also I'm not sure about the dmesg output from here: https://bugs.freedesktop.org/show_bug.cgi?id=58667 - It might be connected. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sat, Dec 22, 2012 at 7:25 PM, Borislav Petkov wrote: > On Sat, Dec 22, 2012 at 07:01:31PM -0500, Alex Deucher wrote: >> What chip is this? > > I think it is RV635. Here's the whole 3.8-rc1 dmesg. Does booting with radeon.wb=0 help? Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #4 from Alexandre Demers --- Hitting some other bug right now with bug 58655. I'll apply the proposed patch for the other bug and I'll see what I get then. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667
--- Comment #4 from Thomas Rohloff ---
!Is this a regression? Does it happen with older versions of mesa or kernel?!
Not that I know about.
"May also be related to bug 58354."
Do you have the path noted there ("drm/radeon: use DMA engine for VM page table
updates on cayman/TN") ? I would loce to try to revert this patch and test it,
but I'm unable to google it.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667
--- Comment #5 from Thomas Rohloff ---
I should really read before I click save, sorry. Here again:
"Is this a regression? Does it happen with older versions of mesa or kernel?"
Not that I know about.
"May also be related to bug 58354."
Do you have a link to the patch noted there ("drm/radeon: use DMA engine for VM
page table updates on cayman/TN") ? I would love to try to revert this patch
and test it, but I'm unable to google it.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GPU lockup CP stall for more than 10000msec on latest vanilla git
On Mon, Dec 17, 2012 at 5:25 PM, Markus Trippelsdorf wrote: > On 2012.12.17 at 17:00 -0500, Alex Deucher wrote: >> On Mon, Dec 17, 2012 at 4:48 PM, Markus Trippelsdorf >> wrote: >> > On 2012.12.17 at 16:32 -0500, Alex Deucher wrote: >> >> On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf >> >> wrote: >> >> > As soon as I open the following website: >> >> > http://www.boston.com/bigpicture/2012/12/2012_year_in_pictures_part_i.html >> >> > >> >> > my Radeon RS780 stalls (GPU lockup) leaving the machine unusable: >> >> >> >> Is this a regression? Most likely a 3D driver bug unless you are only >> >> seeing it with specific kernels. What browser are you using and do >> >> you have hw accelerated webgl, etc. enabled? If so, what version of >> >> mesa are you using? >> > >> > This is a regression, because it is caused by yesterdays merge of >> > drm-next by Linus. IOW I only see this bug when running a >> > v3.7-9432-g9360b53 kernel. >> >> Can you bisect? I'm guessing it may be related to the new DMA rings. >> Possibly: >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 > > Yes, the commit above causes the issue. > Does booting with radeon.wb=0 fix the issue? Please make sure your kernel has this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=86a1881d08f65a42c17071a59c0088dbe2870246 Alex > 2d6cc72 GPU lockups > 009ee7a runs fine > > -- > Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #5 from Alex Deucher --- Created attachment 72013 --> https://bugs.freedesktop.org/attachment.cgi?id=72013&action=edit possible fix Does this patch fix the issue? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/radeon: fix VM flush sequence on cayman
From: Alex Deucher
CP changes:
- make sure the new VM base address hits the registers
- wait for the VM invalidate to finish
DMA changes:
- wait for the VM invalidate to finish
May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=58354
https://bugs.freedesktop.org/show_bug.cgi?id=58667
possibly other related issues.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/ni.c | 32 ++--
drivers/gpu/drm/radeon/nid.h |5 +
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 39e8be1..2b10ab6 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1861,12 +1861,25 @@ void cayman_vm_set_page(struct radeon_device *rdev,
uint64_t pe,
void cayman_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm
*vm)
{
struct radeon_ring *ring = &rdev->ring[ridx];
+ u32 vm_reg, vm_addr;
if (vm == NULL)
return;
- radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR +
(vm->id << 2), 0));
- radeon_ring_write(ring, vm->pd_gpu_addr >> 12);
+ vm_reg = VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id << 2);
+ vm_addr = vm->pd_gpu_addr >> 12;
+
+ radeon_ring_write(ring, PACKET0(vm_reg, 0));
+ radeon_ring_write(ring, vm_addr);
+
+ /* wait for the new value to hit the reg */
+ radeon_ring_write(ring, PACKET3(PACKET3_WAIT_REG_MEM, 5));
+ radeon_ring_write(ring, 3); /* == */
+ radeon_ring_write(ring, vm_reg >> 2);
+ radeon_ring_write(ring, 0);
+ radeon_ring_write(ring, vm_addr); /* ref */
+ radeon_ring_write(ring, 0xfff); /* mask */
+ radeon_ring_write(ring, 0x10);
/* flush hdp cache */
radeon_ring_write(ring, PACKET0(HDP_MEM_COHERENCY_FLUSH_CNTL, 0));
@@ -1876,6 +1889,15 @@ void cayman_vm_flush(struct radeon_device *rdev, int
ridx, struct radeon_vm *vm)
radeon_ring_write(ring, PACKET0(VM_INVALIDATE_REQUEST, 0));
radeon_ring_write(ring, 1 << vm->id);
+ /* wait for the request bit to clear */
+ radeon_ring_write(ring, PACKET3(PACKET3_WAIT_REG_MEM, 5));
+ radeon_ring_write(ring, 3); /* == */
+ radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
+ radeon_ring_write(ring, 0);
+ radeon_ring_write(ring, 0); /* ref */
+ radeon_ring_write(ring, 1 << vm->id); /* mask */
+ radeon_ring_write(ring, 0x10);
+
/* sync PFP to ME, otherwise we might get invalid PFP reads */
radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0));
radeon_ring_write(ring, 0x0);
@@ -1901,5 +1923,11 @@ void cayman_dma_vm_flush(struct radeon_device *rdev, int
ridx, struct radeon_vm
radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_SRBM_WRITE, 0, 0, 0));
radeon_ring_write(ring, (0xf << 16) | (VM_INVALIDATE_REQUEST >> 2));
radeon_ring_write(ring, 1 << vm->id);
+
+ /* wait for the request bit to clear */
+ radeon_ring_write(ring, DMA_SRBM_READ_PACKET(DMA_PACKET_SRBM_WRITE, 1,
0));
+ radeon_ring_write(ring, (0xfff << 20) | (VM_INVALIDATE_REQUEST >> 2));
+ radeon_ring_write(ring, 1 << vm->id); /* mask */
+ radeon_ring_write(ring, 0); /* value */
}
diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
index b93186b..f2e73e7 100644
--- a/drivers/gpu/drm/radeon/nid.h
+++ b/drivers/gpu/drm/radeon/nid.h
@@ -663,6 +663,11 @@
(((vmid) & 0xF) << 20) | \
(((n) & 0xF) << 0))
+#define DMA_SRBM_READ_PACKET(cmd, p, n)cmd) & 0xF) << 28) |
\
+(1 << 27) |\
+(((p) & 0x1) << 26) | \
+(((n) & 0xF) << 0))
+
/* async DMA Packet types */
#defineDMA_PACKET_WRITE 0x2
#defineDMA_PACKET_COPY 0x3
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon: fix VM flush sequence on SI
From: Alex Deucher
CP changes:
- make sure the new VM base address hits the registers
- wait for the VM invalidate to finish
DMA changes:
- wait for the VM invalidate to finish
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/si.c | 41 +
drivers/gpu/drm/radeon/sid.h |3 +++
2 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 7e835d9..f1f5d3a 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2959,24 +2959,33 @@ void si_vm_set_page(struct radeon_device *rdev,
uint64_t pe,
void si_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm *vm)
{
struct radeon_ring *ring = &rdev->ring[ridx];
+ u32 vm_reg, vm_addr;
if (vm == NULL)
return;
+ if (vm->id < 8)
+ vm_reg = VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id << 2);
+ else
+ vm_reg = VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + ((vm->id - 8) << 2);
+ vm_addr = vm->pd_gpu_addr >> 12;
+
/* write new base address */
radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(0) |
WRITE_DATA_DST_SEL(0)));
+ radeon_ring_write(ring, vm_reg >> 2);
+ radeon_ring_write(ring, 0);
+ radeon_ring_write(ring, vm_addr);
- if (vm->id < 8) {
- radeon_ring_write(ring,
- (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id
<< 2)) >> 2);
- } else {
- radeon_ring_write(ring,
- (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + ((vm->id
- 8) << 2)) >> 2);
- }
+ /* wait for the new value to hit the reg */
+ radeon_ring_write(ring, PACKET3(PACKET3_WAIT_REG_MEM, 5));
+ radeon_ring_write(ring, 3); /* == */
+ radeon_ring_write(ring, vm_reg >> 2);
radeon_ring_write(ring, 0);
- radeon_ring_write(ring, vm->pd_gpu_addr >> 12);
+ radeon_ring_write(ring, vm_addr); /* ref */
+ radeon_ring_write(ring, 0xfff); /* mask */
+ radeon_ring_write(ring, 0x10);
/* flush hdp cache */
radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
@@ -2994,6 +3003,15 @@ void si_vm_flush(struct radeon_device *rdev, int ridx,
struct radeon_vm *vm)
radeon_ring_write(ring, 0);
radeon_ring_write(ring, 1 << vm->id);
+ /* wait for the request bit to clear */
+ radeon_ring_write(ring, PACKET3(PACKET3_WAIT_REG_MEM, 5));
+ radeon_ring_write(ring, 3); /* == */
+ radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
+ radeon_ring_write(ring, 0);
+ radeon_ring_write(ring, 0); /* ref */
+ radeon_ring_write(ring, 1 << vm->id); /* mask */
+ radeon_ring_write(ring, 0x10);
+
/* sync PFP to ME, otherwise we might get invalid PFP reads */
radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0));
radeon_ring_write(ring, 0x0);
@@ -3023,6 +3041,13 @@ void si_dma_vm_flush(struct radeon_device *rdev, int
ridx, struct radeon_vm *vm)
radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_SRBM_WRITE, 0, 0, 0, 0));
radeon_ring_write(ring, (0xf << 16) | (VM_INVALIDATE_REQUEST >> 2));
radeon_ring_write(ring, 1 << vm->id);
+
+ radeon_ring_write(ring, DMA_POLL_REG_MEM_PACKET(0));
+ radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
+ radeon_ring_write(ring, 0xfff << 16);
+ radeon_ring_write(ring, 1 << vm->id); /* mask */
+ radeon_ring_write(ring, 0); /* value */
+ radeon_ring_write(ring, (3 << 28) | 0x10); /* ==, interval */
}
/*
diff --git a/drivers/gpu/drm/radeon/sid.h b/drivers/gpu/drm/radeon/sid.h
index 62b4621..71d8c40 100644
--- a/drivers/gpu/drm/radeon/sid.h
+++ b/drivers/gpu/drm/radeon/sid.h
@@ -1030,6 +1030,9 @@
(1 << 21) |\
(((n) & 0xF) << 0))
+#define DMA_POLL_REG_MEM_PACKET(m) ((14 << 28) | \
+((m) << 27))
+
/* async DMA Packet types */
#defineDMA_PACKET_WRITE 0x2
#defineDMA_PACKET_COPY 0x3
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #6 from Alexandre Demers --- Created attachment 72014 --> https://bugs.freedesktop.org/attachment.cgi?id=72014&action=edit dmesg after lockup This is the salvaged dmesg retrieved with the help of a ssh connection. Sadly, I don't think there is anything useful in there. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #7 from Alexandre Demers --- Would it help if I was increasing the debug level? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #8 from Alexandre Demers --- (In reply to comment #5) > Created attachment 72013 [details] [review] > possible fix > > Does this patch fix the issue? Testing right away. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #9 from Alexandre Demers --- Doesn't fix it, it locks as before. Sadly, dmesg seems to loose the count because of another bug introduced in 3.8-rc1. Now that I moved to 3.8-rc1, there is a huge amount of messages appearing in errors.log and dmesg (when typed in the terminal): ... [ 6223.054880] radeon :01:00.0: GPU fault detected: 146 0x00239514 [ 6223.054882] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054883] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054885] radeon :01:00.0: GPU fault detected: 146 0x00135514 [ 6223.054887] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054889] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054891] radeon :01:00.0: GPU fault detected: 146 0x00239514 [ 6223.054893] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054895] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054897] radeon :01:00.0: GPU fault detected: 146 0x0033a514 [ 6223.054899] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054900] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054902] radeon :01:00.0: GPU fault detected: 146 0x00136514 [ 6223.054904] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054906] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054908] radeon :01:00.0: GPU fault detected: 146 0x0033a514 [ 6223.054910] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054912] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054914] radeon :01:00.0: GPU fault detected: 146 0x0033a514 [ 6223.054916] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054918] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054920] radeon :01:00.0: GPU fault detected: 146 0x00232514 [ 6223.054922] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054923] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054925] radeon :01:00.0: GPU fault detected: 146 0x00232514 [ 6223.054927] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054930] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054932] radeon :01:00.0: GPU fault detected: 146 0x0033d514 [ 6223.054934] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054936] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054938] radeon :01:00.0: GPU fault detected: 146 0x0033d514 [ 6223.054940] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054942] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054944] radeon :01:00.0: GPU fault detected: 146 0x00235514 [ 6223.054946] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054948] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054950] radeon :01:00.0: GPU fault detected: 146 0x00235514 [ 6223.054952] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054954] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054956] radeon :01:00.0: GPU fault detected: 146 0x0033e514 [ 6223.054958] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054960] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054962] radeon :01:00.0: GPU fault detected: 146 0x0033e514 [ 6223.054963] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054965] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054967] radeon :01:00.0: GPU fault detected: 146 0x00339514 [ 6223.054969] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054971] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054973] radeon :01:00.0: GPU fault detected: 146 0x00339514 [ 6223.054975] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054977] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 6223.054979] radeon :01:00.0: GPU fault detected: 146 0x00236514 [ 6223.054980] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 6223.054982] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x ... I'm sure it is a different bug, can you confirm? dmesg.log stops to be populated when X/Gnome start, but typing dmesg in a terminal outputs tons of the reported messages. Should I open a new bug for it or has it been already reported? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #10 from Alexandre Demers --- (In reply to comment #9) > Doesn't fix it, it locks as before. Sadly, dmesg seems to loose the count > because of another bug introduced in 3.8-rc1. Now that I moved to 3.8-rc1, > there is a huge amount of messages appearing in errors.log and dmesg (when > typed in the terminal): > ... > [ 6223.054880] radeon :01:00.0: GPU fault detected: 146 0x00239514 > [ 6223.054882] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054883] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054885] radeon :01:00.0: GPU fault detected: 146 0x00135514 > [ 6223.054887] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054889] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054891] radeon :01:00.0: GPU fault detected: 146 0x00239514 > [ 6223.054893] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054895] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054897] radeon :01:00.0: GPU fault detected: 146 0x0033a514 > [ 6223.054899] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054900] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054902] radeon :01:00.0: GPU fault detected: 146 0x00136514 > [ 6223.054904] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054906] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054908] radeon :01:00.0: GPU fault detected: 146 0x0033a514 > [ 6223.054910] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054912] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054914] radeon :01:00.0: GPU fault detected: 146 0x0033a514 > [ 6223.054916] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054918] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054920] radeon :01:00.0: GPU fault detected: 146 0x00232514 > [ 6223.054922] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054923] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054925] radeon :01:00.0: GPU fault detected: 146 0x00232514 > [ 6223.054927] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054930] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054932] radeon :01:00.0: GPU fault detected: 146 0x0033d514 > [ 6223.054934] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054936] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054938] radeon :01:00.0: GPU fault detected: 146 0x0033d514 > [ 6223.054940] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054942] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054944] radeon :01:00.0: GPU fault detected: 146 0x00235514 > [ 6223.054946] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054948] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054950] radeon :01:00.0: GPU fault detected: 146 0x00235514 > [ 6223.054952] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054954] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054956] radeon :01:00.0: GPU fault detected: 146 0x0033e514 > [ 6223.054958] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054960] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054962] radeon :01:00.0: GPU fault detected: 146 0x0033e514 > [ 6223.054963] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054965] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054967] radeon :01:00.0: GPU fault detected: 146 0x00339514 > [ 6223.054969] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054971] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054973] radeon :01:00.0: GPU fault detected: 146 0x00339514 > [ 6223.054975] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054977] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > [ 6223.054979] radeon :01:00.0: GPU fault detected: 146 0x00236514 > [ 6223.054980] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054982] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > ... > > I'm sure it is a different bug, can you confirm? dmesg.log stops to be > populated when
[PATCH 1/2] drm/exynos: fix flags in dma buf exporting
Applied. Thanks, Inki Dae 2012/12/20 Seung-Woo Kim > This patch fixes flags passed to dma buf exporting. > > Signed-off-by: Seung-Woo Kim > Signed-off-by: Kyungmin.park > --- > I found exynos drm also sends wrong flag for dma buf exporting. So I send > this > based on drm-fixes branch. > > drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c > b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c > index fae1f2e..8cb8c56 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c > @@ -185,7 +185,7 @@ struct dma_buf *exynos_dmabuf_prime_export(struct > drm_device *drm_dev, > struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj); > > return dma_buf_export(exynos_gem_obj, &exynos_dmabuf_ops, > - exynos_gem_obj->base.size, 0600); > + exynos_gem_obj->base.size, flags); > } > > struct drm_gem_object *exynos_dmabuf_prime_import(struct drm_device > *drm_dev, > -- > 1.7.4.1 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part ------ An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121222/8531f5f4/attachment.html>
[RFC] drm/exynos: added hdcp driver for contents protection.
2012/12/21 Alan Cox > On Fri, 21 Dec 2012 18:47:57 +0900 > Eunchul Kim wrote: > > > HDCP stands for High-bandwidth Digital Content Protection. > > This is a newer form of Digital Rights Management(secure DRM) > > was.. the master key was leaked long ago 8) > > > that was designed to control digital video and audio content. > > Contains an integrated HDCP encryption engine for video/audio content > protection. > > supports version HDCP v1.1. > > Exynos AP supports embedded HDCP key system. > > The HDCP key value is fused during fabrication, based on customer's > request. > > For this code to go into the kernel it must do so in GPL form. Can you > confirm Samsung has the necessary IPR and permissions to grant use of > this to all third parties as the GPL requires not just to specific > customers ? (whether they can use it usefully is a different question as > obviously they need the key. > > I ask this because there are currently a lot of lawyers busy trying to > sue makers of some HDCP aware devices. > > > + > > + dev_info(dev, "drm hdcp registered successfully.\n"); > > This sort of stuff ought to be dev_dbg, minor item > > > > diff --git a/drivers/gpu/drm/exynos/exynos_hdcp.h > b/drivers/gpu/drm/exynos/exynos_hdcp.h > > new file mode 100644 > > index 000..86d0c79 > > --- /dev/null > > +++ b/drivers/gpu/drm/exynos/exynos_hdcp.h > > @@ -0,0 +1,47 @@ > > +/* > > + * Copyright (c) 2012 Samsung Electronics Co., Ltd. > > + * > > + * Authors: > > + * Eunchul Kim > > + * > > + * Permission is hereby granted, free of charge, to any person > obtaining a > > + * copy of this software and associated documentation files (the > "Software"), > > + * to deal in the Software without restriction, including without > limitation > > + * the rights to use, copy, modify, merge, publish, distribute, > sublicense, > > + * and/or sell copies of the Software, and to permit persons to whom the > > + * Software is furnished to do so, subject to the following conditions: > > + * > > + * The above copyright notice and this permission notice (including the > next > > + * paragraph) shall be included in all copies or substantial portions > of the > > + * Software. > > + * > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > EXPRESS OR > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > MERCHANTABILITY, > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT > SHALL > > + * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, > DAMAGES OR > > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > > + * OTHER DEALINGS IN THE SOFTWARE. > > + */ > > > Two things strike me here - firstly kernel code is GPLv2 or later (or > dual licensed) as per the Signed-off-by: certification. I don't see any > problem in the above but to be sure you realise. > > Secondly - VA Linux systems ??? has this been copied from some random > file and not updated correctly or does the old VA Linux Systems really > own bits of this code. > > And also I found out that other exynos files also haven't been updated correctly. Definitely this was our mistakes. Thanks, Inki Dae > Other questions I'll look at later - in particular > - I don't see how the work queue is locked against the main thread of > execution within the driver > - There is a general DRI question here about HDCP and interfaces - > several out of tree drivers do HDCP and perhaps a common API would be > sensible ? > > Alan > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121222/e8a8b2fa/attachment-0001.html>
Fan control in nouveau driver with geforce 9600gt
On 21/12/2012 13:04, Ozan ?a?layan wrote: >> Of course it is, but why would you disable automatic fan management? >> >> You are supposed to activate it and let it activated at all time. > It's not me but someone inexperienced playing with sysfs tunables for example > :) Ah, sure. Well, there is documentation. And it isn't more dangerous than the current situation (always disabled). We will be waiting a until one kernel is released before activating fan management by default.
[Bug 56405] Distorted graphics on Radeon HD 6620G
https://bugs.freedesktop.org/show_bug.cgi?id=56405 Alex Deucher changed: What|Removed |Added CC||adamreichold at myopera.com --- Comment #50 from Alex Deucher --- *** Bug 58634 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121222/4ae14ff2/attachment.html>
[RFC] drm/exynos: added hdcp driver for contents protection.
Thank's for your advice. Your opinion is very helpful to me. I will consider your comments, and then I resend it. Thank's BR Eunchul Kim On 12/21/2012 08:53 PM, Alan Cox wrote: > On Fri, 21 Dec 2012 18:47:57 +0900 > Eunchul Kim wrote: > >> HDCP stands for High-bandwidth Digital Content Protection. >> This is a newer form of Digital Rights Management(secure DRM) > > was.. the master key was leaked long ago 8) - Okay, I will change description. :) > >> that was designed to control digital video and audio content. >> Contains an integrated HDCP encryption engine for video/audio content >> protection. >> supports version HDCP v1.1. >> Exynos AP supports embedded HDCP key system. >> The HDCP key value is fused during fabrication, based on customer's request. > > For this code to go into the kernel it must do so in GPL form. Can you > confirm Samsung has the necessary IPR and permissions to grant use of > this to all third parties as the GPL requires not just to specific > customers ? (whether they can use it usefully is a different question as > obviously they need the key. > > I ask this because there are currently a lot of lawyers busy trying to > sue makers of some HDCP aware devices. - I will check about your comments. thank's > >> + >> +dev_info(dev, "drm hdcp registered successfully.\n"); > > This sort of stuff ought to be dev_dbg, minor item - changed it. > > >> diff --git a/drivers/gpu/drm/exynos/exynos_hdcp.h >> b/drivers/gpu/drm/exynos/exynos_hdcp.h >> new file mode 100644 >> index 000..86d0c79 >> --- /dev/null >> +++ b/drivers/gpu/drm/exynos/exynos_hdcp.h >> @@ -0,0 +1,47 @@ >> +/* >> + * Copyright (c) 2012 Samsung Electronics Co., Ltd. >> + * >> + * Authors: >> + * Eunchul Kim >> + * >> + * Permission is hereby granted, free of charge, to any person obtaining a >> + * copy of this software and associated documentation files (the >> "Software"), >> + * to deal in the Software without restriction, including without limitation >> + * the rights to use, copy, modify, merge, publish, distribute, sublicense, >> + * and/or sell copies of the Software, and to permit persons to whom the >> + * Software is furnished to do so, subject to the following conditions: >> + * >> + * The above copyright notice and this permission notice (including the next >> + * paragraph) shall be included in all copies or substantial portions of the >> + * Software. >> + * >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS >> OR >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL >> + * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR >> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, >> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR >> + * OTHER DEALINGS IN THE SOFTWARE. >> + */ > > > Two things strike me here - firstly kernel code is GPLv2 or later (or > dual licensed) as per the Signed-off-by: certification. I don't see any > problem in the above but to be sure you realise. > > Secondly - VA Linux systems ??? has this been copied from some random > file and not updated correctly or does the old VA Linux Systems really > own bits of this code. > - changed it. > Other questions I'll look at later - in particular > - I don't see how the work queue is locked against the main thread of >execution within the driver - I want to avoid that main thread is locked by I2C operation with peer device. The performance deteriorated when i used callback. so, I used workqueue. I designed two kind of mechanism about this. first one is based on workqueue. second one is based on callback. I will consider one more time between synchronization and performance. > - There is a general DRI question here about HDCP and interfaces - >several out of tree drivers do HDCP and perhaps a common API would be >sensible ? - I agree with your opinion. So, I discussed with our X video driver engineer for common API internally. I think, If we provide connector property for HDCP, then DRI can control HDCP generally. I didn't fully implemented yet. > > Alan >
[PATCHv4 5/8] drm: tegra: Remove redundant host1x
On 21.12.2012 16:36, Thierry Reding wrote:
> On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote:
>> +static struct platform_driver tegra_drm_platform_driver = {
>> +.driver = {
>> +.name = "tegradrm",
>
> This should be "tegra-drm" to match the module name.
We've actually created two problems.
First is that the device name should match driver name which should
match module name. But host1x doesn't know the module name of tegradrm.
Second problem is that host1x driver creates tegradrm device even if
tegradrm isn't loaded to system.
These mean that the device has to be created in tegra-drm module to have
access to the module name. So instead of just getter, we need a getter
and a setter.
Terje
[RFC] drm/exynos: added hdcp driver for contents protection.
Dear Sean Paul. Thank's for your comment. I am in charge of Display Part in Samsung TN. and I also use exynos drm and I contributed some part to dri-devel(e.g IPPs). Your comment is very helpful to me. I answer to your comment. please check my answer. Thank's BR Eunchul Kim On 12/22/2012 04:29 AM, Sean Paul wrote: > On Fri, Dec 21, 2012 at 4:47 AM, Eunchul Kim > wrote: >> HDCP stands for High-bandwidth Digital Content Protection. >> This is a newer form of Digital Rights Management(secure DRM) >> that was designed to control digital video and audio content. >> Contains an integrated HDCP encryption engine for video/audio content >> protection. >> supports version HDCP v1.1. >> Exynos AP supports embedded HDCP key system. >> The HDCP key value is fused during fabrication, based on customer's request. >> >> Exynos HDCP scenario. >> - start encryption. >> - receive Bcaps, Bksv from peer device. >> - check repeater caps from Bcaps. >> - send An, Aksv to peer device. >> - receive Rj from peer device. >> - compare Ri,Rj. If same and not repeater, then start encryption. >> - If not same, retry. If repeater, then start second authentication. >> - stop encryption. >> >> Signed-off-by: Eunchul Kim >> --- > > Hey Eunchul, > Through some unfortunate duplication of work, I've also been working > on HDCP for exynos drm. - Look's good news. because we can upgrade exynos drm together. > > I uploaded my patch a couple of days ago > https://gerrit.chromium.org/gerrit/#/c/39960. - I didn't subscribe chromium.org. so, I didn't see your patch. I will check your patch for understanding your design about HDCP. How can i subscribe your gerrit for the future? because we have very many changes in HDMI, FIMD side in our local git. I want to synchronize from yours to avoid duplication work. I am in charge of all Display Part H/W IP in exynos DRM. please refer it. > > A few high level comments on your patch: > > - Why implement a new driver? You're using the irq and registers from - Yes your are right in some part. I think you didn't see the connection with HDMI driver and HDCP driver. so, you got the question. IMO, HDMI driver is very big currently, so, If we add HDCP code directly in HDMI driver. I can't handle HDCP driver on/off using configuration(defconfig). so, I designed different file and make some ops(callback). I will check one more time between in-side and out-side with our team. > the hdmi IP block, seems to make more sense to do it right in the hdmi > driver. There's a fair bit of code gymnastics that you're doing to > make hdcp visible to hdmi that just wouldn't be necessary if it was > all included. - I understood what your mean. I will consider about your comment. > - I'm not sure what your interface to userspace is. I think it makes > most sense to implement this as a connector property. Here's a patch I > uploaded a couple weeks ago > https://gerrit.chromium.org/gerrit/#/c/38845/ - connector property is good idea. I also think that.(currently we always enable this) I will check your patch. thank's. It's good information. > > A couple more comments inline. > >> drivers/gpu/drm/exynos/Kconfig |6 + >> drivers/gpu/drm/exynos/Makefile |1 + >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 + >> drivers/gpu/drm/exynos/exynos_drm_drv.h |1 + >> drivers/gpu/drm/exynos/exynos_hdcp.c| 1164 >> +++ >> drivers/gpu/drm/exynos/exynos_hdcp.h| 47 ++ >> drivers/gpu/drm/exynos/exynos_hdmi.c| 11 + >> drivers/gpu/drm/exynos/exynos_hdmi.h|7 + >> drivers/gpu/drm/exynos/regs-hdmi.h | 177 + >> 9 files changed, 1426 insertions(+), 0 deletions(-) >> create mode 100644 drivers/gpu/drm/exynos/exynos_hdcp.c >> create mode 100644 drivers/gpu/drm/exynos/exynos_hdcp.h >> >> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig >> index 1d1f1e5..93c2f00 100644 >> --- a/drivers/gpu/drm/exynos/Kconfig >> +++ b/drivers/gpu/drm/exynos/Kconfig >> @@ -34,6 +34,12 @@ config DRM_EXYNOS_HDMI >> help >>Choose this option if you want to use Exynos HDMI for DRM. >> >> +config DRM_EXYNOS_HDCP >> + bool "Exynos DRM HDCP" >> + depends on DRM_EXYNOS_HDMI >> + help >> + Choose this option if you want to use Exynos HDCP in HDMI for DRM. >> + >> config DRM_EXYNOS_VIDI >> bool "Exynos DRM Virtual Display" >> depends on DRM_EXYNOS >> diff --git a/drivers/gpu/drm/exynos/Makefile >> b/drivers/gpu/drm/exynos/Makefile >> index 639b49e..58d8fb7 100644 >> --- a/drivers/gpu/drm/exynos/Makefile >> +++ b/drivers/gpu/drm/exynos/Makefile >> @@ -14,6 +14,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD) += exynos_drm_fimd.o >> exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \ >> exynos_ddc.o exynos_hdmiphy.o \ >> exynos
[PATCH v3 2/8] drm/exynos: remove needless error handling to property.
This patch removes property error handling. because property couldn't be NULL.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 12
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 12
drivers/gpu/drm/exynos/exynos_drm_ipp.c |5 -
3 files changed, 0 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 7a3e460..5dc0251 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -705,10 +705,6 @@ static int fimc_src_set_addr(struct device *dev,
}
property = &c_node->property;
- if (!property) {
- DRM_ERROR("failed to get property.\n");
- return -EINVAL;
- }
DRM_DEBUG_KMS("%s:prop_id[%d]buf_id[%d]buf_type[%d]\n", __func__,
property->prop_id, buf_id, buf_type);
@@ -1241,10 +1237,6 @@ static int fimc_dst_set_addr(struct device *dev,
}
property = &c_node->property;
- if (!property) {
- DRM_ERROR("failed to get property.\n");
- return -EINVAL;
- }
DRM_DEBUG_KMS("%s:prop_id[%d]buf_id[%d]buf_type[%d]\n", __func__,
property->prop_id, buf_id, buf_type);
@@ -1573,10 +1565,6 @@ static int fimc_ippdrv_start(struct device *dev, enum
drm_exynos_ipp_cmd cmd)
}
property = &c_node->property;
- if (!property) {
- DRM_ERROR("failed to get property.\n");
- return -EINVAL;
- }
fimc_handle_irq(ctx, true, false, true);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index c443c3b..ba5fefd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -720,10 +720,6 @@ static int gsc_src_set_addr(struct device *dev,
}
property = &c_node->property;
- if (!property) {
- DRM_ERROR("failed to get property.\n");
- return -EFAULT;
- }
DRM_DEBUG_KMS("%s:prop_id[%d]buf_id[%d]buf_type[%d]\n", __func__,
property->prop_id, buf_id, buf_type);
@@ -1180,10 +1176,6 @@ static int gsc_dst_set_addr(struct device *dev,
}
property = &c_node->property;
- if (!property) {
- DRM_ERROR("failed to get property.\n");
- return -EFAULT;
- }
DRM_DEBUG_KMS("%s:prop_id[%d]buf_id[%d]buf_type[%d]\n", __func__,
property->prop_id, buf_id, buf_type);
@@ -1565,10 +1557,6 @@ static int gsc_ippdrv_start(struct device *dev, enum
drm_exynos_ipp_cmd cmd)
}
property = &c_node->property;
- if (!property) {
- DRM_ERROR("failed to get property.\n");
- return -EINVAL;
- }
gsc_handle_irq(ctx, true, false, true);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index ba45f9a..cac94fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1487,11 +1487,6 @@ void ipp_sched_cmd(struct work_struct *work)
mutex_lock(&c_node->cmd_lock);
property = &c_node->property;
- if (!property) {
- DRM_ERROR("failed to get property:prop_id[%d]\n",
- c_node->property.prop_id);
- goto err_unlock;
- }
switch (cmd_work->ctrl) {
case IPP_CTRL_PLAY:
--
1.7.0.4
[PATCH v3 0/8] drm/exynos: fix and cleanup ipp subsystem drivers
Hi All. This patch fix some issue and cleanup code. please check my commit and let me know about your comment. Changelog v3: - Subject clean like bellow: * change all subject name from Inki.Dae Changelog v2: - This patch set fixes the following: * consider both case of vflip and hflip: we use vflip, hflip set at the same time for 180 degree supporting. so, we add FLIP_BOTH for fixing warnning. Changelog v1: - This patch set fixes the following: * consider both case of vflip and hflip: we use vflip, hflip set at the same time for 180 degree supporting. so, we add this case. * fix build warning: we don't use directly readl, but this code remained. so, we change it. * fix incorrect interrupt induced by m2m operation : m2m operation call reset function at every time. but we don't disable dma start. so, we add dma stop and capture stop operation. - And code clean like bellow: * change memory variable name : we use 'cmd' in property structure and so on. so, this naming make some confusion. we change 'cmd' to 'c_node' to avoid confusion. * remove needless error handling to property : property could't be NULL. so, we remove error handling about NULL. * correct some comments to abbreviation : we change comments for right grammar. * remove needless parenthesis : we misse changing of fimc side. so, I added it. * remove color bar pattern operation : we don't use color display at writeback. so, remove it. Thank's BR Eunchul Kim Eunchul Kim (6): drm/exynos: change member variable name. drm/exynos: remove needless error handling to property. drm/exynos: consider both case of vflip and hflip. drm/exynos: fix build warning. drm/exynos: correct some comments to abbreviation. drm/exynos: remove needless parenthesis. Jinyoung Jeon (1): drm/exynos: fix incorrect interrupt induced by m2m operation. JoongMock Shin (1): drm/exynos: remove color bar pattern operation. drivers/gpu/drm/exynos/exynos_drm_fimc.c| 47 +-- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 26 --- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 13 ++- drivers/gpu/drm/exynos/exynos_drm_ipp.h |4 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c |3 +- include/uapi/drm/exynos_drm.h |2 + 6 files changed, 40 insertions(+), 55 deletions(-)
[PATCH v3 1/8] drm/exynos: change member variable name.
This patch change current command name from cmd to c_node.
because we are using the member name, 'cmd', for command control ioctl in
another structure.
so, this patch changes it to c_node to avoid such confusing.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c|8
drivers/gpu/drm/exynos/exynos_drm_gsc.c |8
drivers/gpu/drm/exynos/exynos_drm_ipp.c |6 +++---
drivers/gpu/drm/exynos/exynos_drm_ipp.h |4 ++--
drivers/gpu/drm/exynos/exynos_drm_rotator.c |2 +-
5 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 61ea242..7a3e460 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -695,7 +695,7 @@ static int fimc_src_set_addr(struct device *dev,
{
struct fimc_context *ctx = get_fimc_context(dev);
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+ struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;
struct drm_exynos_ipp_config *config;
@@ -1231,7 +1231,7 @@ static int fimc_dst_set_addr(struct device *dev,
{
struct fimc_context *ctx = get_fimc_context(dev);
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+ struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;
struct drm_exynos_ipp_config *config;
@@ -1317,7 +1317,7 @@ static irqreturn_t fimc_irq_handler(int irq, void *dev_id)
{
struct fimc_context *ctx = dev_id;
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+ struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_event_work *event_work =
c_node->event_work;
int buf_id;
@@ -1557,7 +1557,7 @@ static int fimc_ippdrv_start(struct device *dev, enum
drm_exynos_ipp_cmd cmd)
{
struct fimc_context *ctx = get_fimc_context(dev);
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+ struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;
struct drm_exynos_ipp_config *config;
struct drm_exynos_pos img_pos[EXYNOS_DRM_OPS_MAX];
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 5639353..c443c3b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -711,7 +711,7 @@ static int gsc_src_set_addr(struct device *dev,
{
struct gsc_context *ctx = get_gsc_context(dev);
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+ struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;
if (!c_node) {
@@ -1171,7 +1171,7 @@ static int gsc_dst_set_addr(struct device *dev,
{
struct gsc_context *ctx = get_gsc_context(dev);
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+ struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;
if (!c_node) {
@@ -1312,7 +1312,7 @@ static irqreturn_t gsc_irq_handler(int irq, void *dev_id)
{
struct gsc_context *ctx = dev_id;
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+ struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_event_work *event_work =
c_node->event_work;
u32 status;
@@ -1549,7 +1549,7 @@ static int gsc_ippdrv_start(struct device *dev, enum
drm_exynos_ipp_cmd cmd)
{
struct gsc_context *ctx = get_gsc_context(dev);
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node = ippdrv->cmd;
+ struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
struct drm_exynos_ipp_property *property;
struct drm_exynos_ipp_config *config;
struct drm_exynos_pos img_pos[EXYNOS_DRM_OPS_MAX];
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 49eebe9..ba45f9a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1292,7 +1292,7 @@ static int ipp_start_property(struct exynos_drm_ippdrv
*ippdrv,
DRM_DEBUG_KMS("%s:prop_id[%d]\n", __func__, property->prop_id);
/* store command info in ippdrv */
- ippdrv->cmd = c_node;
+ ippdrv->c_node = c_node;
if (!ipp_check_mem_list(c_node))
[PATCH v3 3/8] drm/exynos: consider both case of vflip and hflip.
This patch considers both case of vflip and hflip.
If we want that the contents in buffer to be rotated to 180 degree,
then we can use h,vflip or 180 degree.
Changelog v2:
- added EXYNOS_DRM_FLIP_BOTH enum value to avoid build warnning.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c|1 +
drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 +-
drivers/gpu/drm/exynos/exynos_drm_rotator.c |1 +
include/uapi/drm/exynos_drm.h |2 ++
4 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 5dc0251..abfff9e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1387,6 +1387,7 @@ static inline bool fimc_check_drm_flip(enum
drm_exynos_flip flip)
case EXYNOS_DRM_FLIP_NONE:
case EXYNOS_DRM_FLIP_VERTICAL:
case EXYNOS_DRM_FLIP_HORIZONTAL:
+ case EXYNOS_DRM_FLIP_BOTH:
return true;
default:
DRM_DEBUG_KMS("%s:invalid flip\n", __func__);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index ba5fefd..3e5b456 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1391,7 +1391,7 @@ static inline bool gsc_check_drm_flip(enum
drm_exynos_flip flip)
case EXYNOS_DRM_FLIP_NONE:
case EXYNOS_DRM_FLIP_VERTICAL:
case EXYNOS_DRM_FLIP_HORIZONTAL:
- case EXYNOS_DRM_FLIP_VERTICAL | EXYNOS_DRM_FLIP_HORIZONTAL:
+ case EXYNOS_DRM_FLIP_BOTH:
return true;
default:
DRM_DEBUG_KMS("%s:invalid flip\n", __func__);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 17e4474..8bf9c50 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -513,6 +513,7 @@ static inline bool rotator_check_drm_flip(enum
drm_exynos_flip flip)
case EXYNOS_DRM_FLIP_NONE:
case EXYNOS_DRM_FLIP_VERTICAL:
case EXYNOS_DRM_FLIP_HORIZONTAL:
+ case EXYNOS_DRM_FLIP_BOTH:
return true;
default:
DRM_DEBUG_KMS("%s:invalid flip\n", __func__);
diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
index e7f52c3..7ed11b2 100644
--- a/include/uapi/drm/exynos_drm.h
+++ b/include/uapi/drm/exynos_drm.h
@@ -185,6 +185,8 @@ enum drm_exynos_flip {
EXYNOS_DRM_FLIP_NONE = (0 << 0),
EXYNOS_DRM_FLIP_VERTICAL = (1 << 0),
EXYNOS_DRM_FLIP_HORIZONTAL = (1 << 1),
+ EXYNOS_DRM_FLIP_BOTH = EXYNOS_DRM_FLIP_VERTICAL |
+ EXYNOS_DRM_FLIP_HORIZONTAL,
};
enum drm_exynos_degree {
--
1.7.0.4
[PATCH v3 4/8] drm/exynos: fix build warning.
This patch fixes erroneous register read. reall function needs register base address + offset but exynos_drm_gsc module used only offset to read a register. so this patch uses gsc_read function instead of readl. Signed-off-by: Eunchul Kim --- drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c b/drivers/gpu/drm/exynos/exynos_drm_gsc.c index 3e5b456..410175a 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c @@ -1592,7 +1592,7 @@ static int gsc_ippdrv_start(struct device *dev, enum drm_exynos_ipp_cmd cmd) exynos_drm_ippnb_send_event(IPP_SET_WRITEBACK, (void *)&set_wb); /* src local path */ - cfg = readl(GSC_IN_CON); + cfg = gsc_read(GSC_IN_CON); cfg &= ~(GSC_IN_PATH_MASK | GSC_IN_LOCAL_SEL_MASK); cfg |= (GSC_IN_PATH_LOCAL | GSC_IN_LOCAL_FIMD_WB); gsc_write(cfg, GSC_IN_CON); -- 1.7.0.4
[PATCH v3 5/8] drm/exynos: correct some comments to abbreviation.
This patch cleanup corrects some comments to abbreviation. We would like to prevent it stands misunderstood. Signed-off-by: Eunchul Kim --- drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 +- drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 +- drivers/gpu/drm/exynos/exynos_drm_ipp.c |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c b/drivers/gpu/drm/exynos/exynos_drm_fimc.c index abfff9e..8cfc5a9 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c @@ -25,7 +25,7 @@ #include "exynos_drm_fimc.h" /* - * FIMC is stand for Fully Interactive Mobile Camera and + * FIMC stands for Fully Interactive Mobile Camera and * supports image scaler/rotator and input/output DMA operations. * input DMA reads image data from the memory. * output DMA writes image data to memory. diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c b/drivers/gpu/drm/exynos/exynos_drm_gsc.c index 410175a..509f2f8 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c @@ -25,7 +25,7 @@ #include "exynos_drm_gsc.h" /* - * GSC is stand for General SCaler and + * GSC stands for General SCaler and * supports image scaler/rotator and input/output DMA operations. * input DMA reads image data from the memory. * output DMA writes image data to memory. diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c b/drivers/gpu/drm/exynos/exynos_drm_ipp.c index cac94fe..63bcf92 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c @@ -27,7 +27,7 @@ #include "exynos_drm_iommu.h" /* - * IPP is stand for Image Post Processing and + * IPP stands for Image Post Processing and * supports image scaler/rotator and input/output DMA operations. * using FIMC, GSC, Rotator, so on. * IPP is integration device driver of same attribute h/w -- 1.7.0.4
[PATCH v3 6/8] drm/exynos: remove color bar pattern operation.
From: JoongMock Shin
This patch removes color bar pattern register because we don't use the register
anymore.
because it doesn't support color bar feature for writeback operation.
camera driver only supports color bar feature. but IPP doesn't support camera
driver.
Signed-off-by: JoongMock Shin
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 8cfc5a9..a99ceef 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -163,17 +163,14 @@ struct fimc_context {
boolsuspended;
};
-static void fimc_sw_reset(struct fimc_context *ctx, bool pattern)
+static void fimc_sw_reset(struct fimc_context *ctx)
{
u32 cfg;
- DRM_DEBUG_KMS("%s:pattern[%d]\n", __func__, pattern);
+ DRM_DEBUG_KMS("%s\n", __func__);
cfg = fimc_read(EXYNOS_CISRCFMT);
cfg |= EXYNOS_CISRCFMT_ITU601_8BIT;
- if (pattern)
- cfg |= EXYNOS_CIGCTRL_TESTPATTERN_COLOR_BAR;
-
fimc_write(cfg, EXYNOS_CISRCFMT);
/* s/w reset */
@@ -1536,7 +1533,7 @@ static int fimc_ippdrv_reset(struct device *dev)
DRM_DEBUG_KMS("%s\n", __func__);
/* reset h/w block */
- fimc_sw_reset(ctx, false);
+ fimc_sw_reset(ctx);
/* reset scaler capability */
memset(&ctx->sc, 0x0, sizeof(ctx->sc));
--
1.7.0.4
[PATCH v3 7/8] drm/exynos: fix incorrect interrupt induced by m2m operation.
From: Jinyoung Jeon
This patch fixes incorrect interrupt induced by m2m operation.
the m2m operation calls s/w reset every frame but there is the case that
the interrupt to m2m operation occures after s/w reset sometimes.
So this patch makes dma and capture operations stop at s/w reset
to avoid incorrect interrupt.
Signed-off-by: Jinyoung Jeon
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index a99ceef..9f52b7f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -169,10 +169,23 @@ static void fimc_sw_reset(struct fimc_context *ctx)
DRM_DEBUG_KMS("%s\n", __func__);
+ /* stop dma operation */
+ cfg = fimc_read(EXYNOS_CISTATUS);
+ if (EXYNOS_CISTATUS_GET_ENVID_STATUS(cfg)) {
+ cfg = fimc_read(EXYNOS_MSCTRL);
+ cfg &= ~EXYNOS_MSCTRL_ENVID;
+ fimc_write(cfg, EXYNOS_MSCTRL);
+ }
+
cfg = fimc_read(EXYNOS_CISRCFMT);
cfg |= EXYNOS_CISRCFMT_ITU601_8BIT;
fimc_write(cfg, EXYNOS_CISRCFMT);
+ /* disable image capture */
+ cfg = fimc_read(EXYNOS_CIIMGCPT);
+ cfg &= ~(EXYNOS_CIIMGCPT_IMGCPTEN_SC | EXYNOS_CIIMGCPT_IMGCPTEN);
+ fimc_write(cfg, EXYNOS_CIIMGCPT);
+
/* s/w reset */
cfg = fimc_read(EXYNOS_CIGCTRL);
cfg |= (EXYNOS_CIGCTRL_SWRST);
--
1.7.0.4
[PATCH v3 8/8] drm/exynos: remove needless parenthesis.
This patch removes needless parenthesis. This was pointed out but in case of fimc side. we missed it. Signed-off-by: Eunchul Kim --- drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c b/drivers/gpu/drm/exynos/exynos_drm_fimc.c index 9f52b7f..2c03ffa 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c @@ -1212,7 +1212,7 @@ static int fimc_dst_set_buf_seq(struct fimc_context *ctx, u32 buf_id, } /* sequence id */ - cfg &= (~mask); + cfg &= ~mask; cfg |= (enable << buf_id); fimc_write(cfg, EXYNOS_CIFCNTSEQ); -- 1.7.0.4
[Bug 56405] Distorted graphics on Radeon HD 6620G
https://bugs.freedesktop.org/show_bug.cgi?id=56405 Florian Mickler changed: What|Removed |Added CC||florian at mickler.org --- Comment #51 from Florian Mickler --- A patch referencing this bug report has been merged in Linux v3.8-rc1: commit bd25f0783dc3fb72e1e2779c2b99b2d34b67fa8a Author: Jerome Glisse Date: Tue Dec 11 11:56:52 2012 -0500 drm/radeon: fix amd afusion gpu setup aka sumo v2 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121222/ea0fee5a/attachment-0001.html>
[Bug 58166] RV670 AGP regression between drm-fixes and drm-next - no display.
https://bugs.freedesktop.org/show_bug.cgi?id=58166 Florian Mickler changed: What|Removed |Added CC||florian at mickler.org --- Comment #9 from Florian Mickler --- A patch referencing this bug report has been merged in Linux v3.8-rc1: commit 86a1881d08f65a42c17071a59c0088dbe2870246 Author: Jerome Glisse Date: Wed Dec 12 16:43:15 2012 -0500 drm/radeon: fix fence driver for dma ring when wb is disabled -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121222/0e18fd82/attachment.html>
[Bug 58272] Rv670 AGP drm-next ttm errors
https://bugs.freedesktop.org/show_bug.cgi?id=58272 Florian Mickler changed: What|Removed |Added CC||florian at mickler.org --- Comment #11 from Florian Mickler --- A patch referencing this bug report has been merged in Linux v3.8-rc1: commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb Author: Dave Airlie Date: Fri Dec 14 21:04:46 2012 +1000 radeon: fix regression with eviction since evict caching changes -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121222/1b3f4be0/attachment.html>
[Bug 58272] Rv670 AGP drm-next ttm errors
https://bugs.freedesktop.org/show_bug.cgi?id=58272 --- Comment #12 from Alex Deucher --- Make sure your kernel has this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=0953e76e91f4b6206cef50bd680696dc6bf1ef99 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121222/8efb5727/attachment.html>
[Bug 58655] New: Screen totally corrupted on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58655 Priority: medium Bug ID: 58655 Assignee: dri-devel at lists.freedesktop.org Summary: Screen totally corrupted on CAYMAN Severity: blocker Classification: Unclassified OS: All Reporter: v10lator at myway.de Hardware: Other Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI This is caused by this mesa commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a and kernel 3.8-rc1. I would love if this could be fixed fast as I have another, more important bug that I need to test against newest mesa git, which isn't possible as I can't go above the commit. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121222/eaa673cc/attachment.html>
[Bug 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=58372 --- Comment #9 from Alexandre Demers --- (In reply to comment #8) > (In reply to comment #7) > > Created attachment 71883 [details] > > dmesg with drm-fixes-3.8 > > > > The dmesg message changed after merging in drm-fixes-3.8: > > > > [drm:evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS > > That's a different bug. Please file a new one for that. what you are > seeing is due to a change in mesa: > http://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a Opening it, I'm hitting the same bug. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121222/32abf593/attachment-0001.html>
[Bug 58656] New: [drm : evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS
https://bugs.freedesktop.org/show_bug.cgi?id=58656 Priority: medium Bug ID: 58656 Assignee: dri-devel at lists.freedesktop.org Summary: [drm : evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS Severity: major Classification: Unclassified OS: All Reporter: alexandre.f.demers at gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa On cayman, 6950, receiving this error in dmesg and in terminal console. Also, screen is messed up and frozen. I'll be attaching dmesg soon. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121222/5e76a80b/attachment.html>
[Bug 58656] [drm : evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS
https://bugs.freedesktop.org/show_bug.cgi?id=58656 --- Comment #1 from Alexandre Demers --- @commit a585b8f3a6681d1138ed1a33ed4c3195a53c2a73 Make IsVertexArray... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121222/071ad1b7/attachment.html>
[Bug 58656] [drm : evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS
https://bugs.freedesktop.org/show_bug.cgi?id=58656 Alexandre Demers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Alexandre Demers --- *** This bug has been marked as a duplicate of bug 58655 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121222/5a26aa77/attachment.html>
[Bug 58655] Screen totally corrupted on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58655 Alexandre Demers changed: What|Removed |Added CC||alexandre.f.demers at gmail.co ||m --- Comment #1 from Alexandre Demers --- *** Bug 58656 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121222/eb683c17/attachment.html>
[Bug 58655] Screen totally corrupted on CAYMAN, [drm : evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS
https://bugs.freedesktop.org/show_bug.cgi?id=58655 Alexandre Demers changed: What|Removed |Added Summary|Screen totally corrupted on |Screen totally corrupted on |CAYMAN |CAYMAN, [drm : ||evergreen_vm_reg_valid] ||*ERROR* Invalid register ||0x8040 in CS -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121222/5782c190/attachment.html>
[Bug 58655] Screen totally corrupted on CAYMAN, [drm : evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS
https://bugs.freedesktop.org/show_bug.cgi?id=58655 --- Comment #2 from Alex Deucher --- Mesa hadn't previously emitted that register for cayman so the kernel wasn't expecting it. Fixed with this patch: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.8&id=668bbc81baf0f34df832d8aca5c7d5e19a493c68 Which should show up in 3.8 and stable soon. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121222/fd85261a/attachment.html>
[Bug 58655] Screen totally corrupted on CAYMAN, [drm : evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 in CS
https://bugs.freedesktop.org/show_bug.cgi?id=58655 Thomas Rohloff changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Thomas Rohloff --- Thanks, that small patch fixes it. :) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121222/173d62b7/attachment.html>
