[PATCH v3] drm/exynos: let drm handle edid allocations
There's no need to allocate edid twice and do a memcpy when drm helpers
exist to do just that. This patch cleans that interaction up, and
doesn't keep the edid hanging around in the connector.
v3:
- removed MAX_EDID as it is not used anymore.
v2:
- changed vidi_get_edid callback inside vidi driver.
Signed-off-by: Sean Paul
Signed-off-by: Rahul Sharma
Signed-off-by: Seung-Woo Kim
---
This patch is based on branch "exynos-drm-next" at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git
drivers/gpu/drm/exynos/exynos_drm_connector.c | 37 ++-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 +--
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 9 +++
drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 4 +--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 19 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 25 --
6 files changed, 50 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index ab37437..221ec72 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -18,7 +18,6 @@
#include "exynos_drm_drv.h"
#include "exynos_drm_encoder.h"
-#define MAX_EDID 256
#define to_exynos_connector(x) container_of(x, struct exynos_drm_connector,\
drm_connector)
@@ -96,7 +95,9 @@ static int exynos_drm_connector_get_modes(struct
drm_connector *connector)
to_exynos_connector(connector);
struct exynos_drm_manager *manager = exynos_connector->manager;
struct exynos_drm_display_ops *display_ops = manager->display_ops;
- unsigned int count;
+ unsigned int count = 0;
+ struct edid *edid = NULL;
+ int ret;
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -114,27 +115,25 @@ static int exynos_drm_connector_get_modes(struct
drm_connector *connector)
* because lcd panel has only one mode.
*/
if (display_ops->get_edid) {
- int ret;
- void *edid;
-
- edid = kzalloc(MAX_EDID, GFP_KERNEL);
- if (!edid) {
- DRM_ERROR("failed to allocate edid\n");
- return 0;
+ edid = display_ops->get_edid(manager->dev, connector);
+ if (IS_ERR_OR_NULL(edid)) {
+ ret = PTR_ERR(edid);
+ edid = NULL;
+ DRM_ERROR("Panel operation get_edid failed %d\n", ret);
+ goto out;
}
- ret = display_ops->get_edid(manager->dev, connector,
- edid, MAX_EDID);
- if (ret < 0) {
- DRM_ERROR("failed to get edid data.\n");
- kfree(edid);
- edid = NULL;
- return 0;
+ ret = drm_mode_connector_update_edid_property(connector, edid);
+ if (ret) {
+ DRM_ERROR("update edid property failed(%d)\n", ret);
+ goto out;
}
- drm_mode_connector_update_edid_property(connector, edid);
count = drm_add_edid_modes(connector, edid);
- kfree(edid);
+ if (count < 0) {
+ DRM_ERROR("Add edid modes failed %d\n", count);
+ goto out;
+ }
} else {
struct exynos_drm_panel_info *panel;
struct drm_display_mode *mode = drm_mode_create(connector->dev);
@@ -161,6 +160,8 @@ static int exynos_drm_connector_get_modes(struct
drm_connector *connector)
count = 1;
}
+out:
+ kfree(edid);
return count;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index b9e51bc..4606fac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -148,8 +148,8 @@ struct exynos_drm_overlay {
struct exynos_drm_display_ops {
enum exynos_drm_output_type type;
bool (*is_connected)(struct device *dev);
- int (*get_edid)(struct device *dev, struct drm_connector *connector,
- u8 *edid, int len);
+ struct edid *(*get_edid)(struct device *dev,
+ struct drm_connector *connector);
void *(*get_panel)(struct device *dev);
int (*check_timing)(struct device *dev, void *timing);
int (*power_on)(struct device *dev, int mode);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 55793c4..a17d752 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -108,18 +108,17 @@ static bool drm_hdmi_is_connected(struct device *dev)
ret
[PATCH 0/2] Making Exynos MIPI Complaint with Common Display Framework
From: Vikas Sajjan This patchset contains 2 RFCs, 1st RFC has modiifications in exynos MIPI DSI driver. 2nd RFC has additions done to video source struct as per exynos requirements. I have NOT tested the patch yet, as i am yet recieve the MIPI DSI panel. This based on Tomi's CDF RFC. I am yet to modify s6e8ax0.c as per CDF and I have NOT tested these patches yet, as i am yet recieve the MIPI DSI panel. Vikas Sajjan (2): [RFC] video: exynos mipi dsi: Making Exynos MIPI Complaint with CDF [RFC] video: display: Adding frame related ops to MIPI DSI video source struct drivers/video/exynos/exynos_mipi_dsi.c| 46 ++--- drivers/video/exynos/exynos_mipi_dsi_common.c | 22 drivers/video/exynos/exynos_mipi_dsi_common.h | 12 +++ include/video/display.h |6 include/video/exynos_mipi_dsim.h |5 ++- 5 files changed, 62 insertions(+), 29 deletions(-) -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] [RFC] video: exynos mipi dsi: Making Exynos MIPI Complaint with CDF
From: Vikas Sajjan
Signed-off-by: Vikas Sajjan
---
drivers/video/exynos/exynos_mipi_dsi.c| 46 ++---
drivers/video/exynos/exynos_mipi_dsi_common.c | 22
drivers/video/exynos/exynos_mipi_dsi_common.h | 12 +++
include/video/exynos_mipi_dsim.h |5 ++-
4 files changed, 56 insertions(+), 29 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c
b/drivers/video/exynos/exynos_mipi_dsi.c
index 07d70a3..88b2aa9 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -32,14 +32,13 @@
#include
#include
#include
-
+#include
#include
#include
#include "exynos_mipi_dsi_common.h"
#include "exynos_mipi_dsi_lowlevel.h"
-
struct mipi_dsim_ddi {
int bus_id;
struct list_headlist;
@@ -111,12 +110,13 @@ static void exynos_mipi_update_cfg(struct
mipi_dsim_device *dsim)
exynos_mipi_dsi_stand_by(dsim, 1);
}
-static int exynos_mipi_dsi_early_blank_mode(struct mipi_dsim_device *dsim,
+static int exynos_mipi_dsi_early_blank_mode(struct video_source *video_source,
int power)
{
+ struct mipi_dsim_device *dsim = container_of(video_source,
+ struct mipi_dsim_device, video_source);
struct mipi_dsim_lcd_driver *client_drv = dsim->dsim_lcd_drv;
struct mipi_dsim_lcd_device *client_dev = dsim->dsim_lcd_dev;
-
switch (power) {
case FB_BLANK_POWERDOWN:
if (dsim->suspended)
@@ -139,12 +139,13 @@ static int exynos_mipi_dsi_early_blank_mode(struct
mipi_dsim_device *dsim,
return 0;
}
-static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int power)
+static int exynos_mipi_dsi_blank_mode(struct video_source *video_source, int
power)
{
+ struct mipi_dsim_device *dsim = container_of(video_source,
+ struct mipi_dsim_device, video_source);
struct platform_device *pdev = to_platform_device(dsim->dev);
struct mipi_dsim_lcd_driver *client_drv = dsim->dsim_lcd_drv;
struct mipi_dsim_lcd_device *client_dev = dsim->dsim_lcd_dev;
-
switch (power) {
case FB_BLANK_UNBLANK:
if (!dsim->suspended)
@@ -319,12 +320,19 @@ static struct mipi_dsim_ddi *exynos_mipi_dsi_bind_lcd_ddi(
return NULL;
}
-/* define MIPI-DSI Master operations. */
-static struct mipi_dsim_master_ops master_ops = {
- .cmd_read = exynos_mipi_dsi_rd_data,
- .cmd_write = exynos_mipi_dsi_wr_data,
- .get_dsim_frame_done= exynos_mipi_dsi_get_frame_done_status,
- .clear_dsim_frame_done = exynos_mipi_dsi_clear_frame_done,
+static void panel_dsi_release(struct video_source *src)
+{
+ printk("dsi entity release\n");
+}
+
+static const struct common_video_source_ops dsi_common_ops = {
+};
+
+static const struct dsi_video_source_ops exynos_dsi_ops = {
+ .dcs_read = exynos_mipi_dsi_rd_data,
+ .dcs_write = exynos_mipi_dsi_wr_data,
+ .get_frame_done = exynos_mipi_dsi_get_frame_done_status,
+ .clear_frame_done = exynos_mipi_dsi_clear_frame_done,
.set_early_blank_mode = exynos_mipi_dsi_early_blank_mode,
.set_blank_mode = exynos_mipi_dsi_blank_mode,
};
@@ -362,7 +370,6 @@ static int exynos_mipi_dsi_probe(struct platform_device
*pdev)
}
dsim->dsim_config = dsim_config;
- dsim->master_ops = &master_ops;
mutex_init(&dsim->lock);
@@ -463,6 +470,19 @@ static int exynos_mipi_dsi_probe(struct platform_device
*pdev)
dsim->suspended = false;
+ dsim->video_source.dev = &pdev->dev;
+ dsim->video_source.release = panel_dsi_release;
+ dsim->video_source.common_ops = &dsi_common_ops;
+ dsim->video_source.ops.dsi = &exynos_dsi_ops;
+ dsim->video_source.name = "exynos";
+
+ ret = video_source_register(&dsim->video_source);
+ if (ret < 0) {
+ printk("dsi entity register failed\n");
+ goto err_bind;
+ }
+ printk("dsi entity registered: %p\n", &dsim->video_source);
+ return 0;
done:
platform_set_drvdata(pdev, dsim);
diff --git a/drivers/video/exynos/exynos_mipi_dsi_common.c
b/drivers/video/exynos/exynos_mipi_dsi_common.c
index 3cd29a4..e59911e 100644
--- a/drivers/video/exynos/exynos_mipi_dsi_common.c
+++ b/drivers/video/exynos/exynos_mipi_dsi_common.c
@@ -153,11 +153,12 @@ static void exynos_mipi_dsi_long_data_wr(struct
mipi_dsim_device *dsim,
}
}
}
-
-int exynos_mipi_dsi_wr_data(struct mipi_dsim_device *dsim, unsigned int
data_id,
- const unsigned char *data0, unsigned int data_size)
+int exynos_mipi_dsi_wr_data(struct video_source *video_source, int data_id,
+
[PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct
From: Vikas Sajjan
Signed-off-by: Vikas Sajjan
---
include/video/display.h |6 ++
1 file changed, 6 insertions(+)
diff --git a/include/video/display.h b/include/video/display.h
index b639fd0..fb2f437 100644
--- a/include/video/display.h
+++ b/include/video/display.h
@@ -117,6 +117,12 @@ struct dsi_video_source_ops {
void (*enable_hs)(struct video_source *src, bool enable);
+ /* frame related */
+ int (*get_frame_done)(struct video_source *src);
+ int (*clear_frame_done)(struct video_source *src);
+ int (*set_early_blank_mode)(struct video_source *src, int power);
+ int (*set_blank_mode)(struct video_source *src, int power);
+
/* data transfer */
int (*dcs_write)(struct video_source *src, int channel,
u8 *data, size_t len);
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Resume regression with nouveau 3.8rc1 (bisected)
Hi, Starting with 3.8rc1 I get a black screen when resuming after suspend. The kernel is alive because I can switch to VT1 and reboot with ctrl-alt-delete. I bisected the problem down to this commit: 186ecad21: drm/nv50/disp: move remaining interrupt handling into core Hardware is 8400M GS (10de:0427) in a Dell XPS M1330. Cheers, Pontus Fuchs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/exynos: add display-mode-check operation to exynos_mixer_ops struct
On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma wrote:
> This patch adds the display mode check operation to exynos_mixer_ops
> in drm-common-hdmi. In Exynos SoCs, mixer IP can put certain restrictions
> on the proposed display modes. These restriction needs to be considered
> during mode negotiation, which happens immediately after edid parsing.
>
> Both, mixer check-mode and hdmi check-timing callbacks are called one after
> another and ANDed result is returned back.
>
This looks good, thanks for making the change.
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 12
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 3 +++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> index 55793c4..3a8eea6 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> @@ -125,9 +125,21 @@ static int drm_hdmi_get_edid(struct device *dev,
> static int drm_hdmi_check_timing(struct device *dev, void *timing)
> {
> struct drm_hdmi_context *ctx = to_context(dev);
> + int ret = 0;
>
> DRM_DEBUG_KMS("%s\n", __FILE__);
>
> + /*
> + * Both, mixer and hdmi should be able to handle the requested mode.
> + * If any of the two fails, return mode as BAD.
> + */
> +
> + if (mixer_ops && mixer_ops->check_mode)
> + ret = mixer_ops->check_mode(ctx->mixer_ctx->ctx, timing);
> +
> + if (ret)
> + return ret;
> +
> if (hdmi_ops && hdmi_ops->check_timing)
> return hdmi_ops->check_timing(ctx->hdmi_ctx->ctx, timing);
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> index 784a7e9..ae4b6ae 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> @@ -58,6 +58,9 @@ struct exynos_mixer_ops {
> void (*win_mode_set)(void *ctx, struct exynos_drm_overlay *overlay);
> void (*win_commit)(void *ctx, int zpos);
> void (*win_disable)(void *ctx, int zpos);
> +
> + /* display */
> + int (*check_mode)(void *ctx, void *mode);
Minor nit: I think check_timing would be better here, it's more consistent.
Sean
> };
>
> void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx);
> --
> 1.8.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/exynos: implement display-mode-check callback in mixer driver
On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma wrote:
> This patch adds the implementation of check_mode callback in the mixer
> driver. Based on the mixer version, correct set of restrictions will be
> exposed by the mixer driver. A resolution will be acceptable only if passes
> the criteria set by mixer and hdmi IPs.
>
> Signed-off-by: Rahul Sharma
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 21db895..093b374 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -810,6 +810,33 @@ static void mixer_win_disable(void *ctx, int win)
> mixer_ctx->win_data[win].enabled = false;
> }
>
> +int mixer_check_mode(void *ctx, void *mode)
> +{
> + struct mixer_context *mixer_ctx = ctx;
> + struct fb_videomode *check_mode = mode;
Why not just pass fb_videomode in the first place?
> + unsigned int w, h;
> +
> + w = check_mode->xres;
> + h = check_mode->yres;
> +
> + DRM_DEBUG_KMS("%s : xres=%d, yres=%d, refresh=%d, intl=%d\n",
> + __func__, check_mode->xres, check_mode->yres,
> + check_mode->refresh, (check_mode->vmode &
> + FB_VMODE_INTERLACED) ? true : false);
> +
> + if (mixer_ctx->mxr_ver == MXR_VER_16_0_33_0) {
> + if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
> + (w >= 1024 && w <= 1280 &&
> + h >= 576 && h <= 720) ||
> + (w >= 1664 && w <= 1920 &&
> + h >= 936 && h <= 1080))
> + return 0;
You could eliminate some of this spaghetti by doing:
if (mixer_ctx->mxr_ver != MXR_VER_16_0_33_0)
return 0;
Then remove one level of indent from the big if statement.
Sean
> + } else {
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> static void mixer_wait_for_vblank(void *ctx)
> {
> struct mixer_context *mixer_ctx = ctx;
> @@ -947,6 +974,9 @@ static struct exynos_mixer_ops mixer_ops = {
> .win_mode_set = mixer_win_mode_set,
> .win_commit = mixer_win_commit,
> .win_disable= mixer_win_disable,
> +
> + /* display */
> + .check_mode = mixer_check_mode,
> };
>
> /* for pageflip event */
> --
> 1.8.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/exynos: mixer: set correct mode for range of resolutions
On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma wrote: > With this patch, mixer driver find the correct resolution mode for > the range of resolutions, upto 1080 vertical lines. Resolution will > be categorized to NTSC SD, PAL SD or HD and the correct mode is > set to the mixer configuration register. > > Signed-off-by: Rahul Sharma > Signed-off-by: Sean Paul > --- > drivers/gpu/drm/exynos/exynos_mixer.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c > b/drivers/gpu/drm/exynos/exynos_mixer.c > index 093b374..8ef0e71 100644 > --- a/drivers/gpu/drm/exynos/exynos_mixer.c > +++ b/drivers/gpu/drm/exynos/exynos_mixer.c > @@ -283,13 +283,13 @@ static void mixer_cfg_scan(struct mixer_context *ctx, > unsigned int height) > MXR_CFG_SCAN_PROGRASSIVE); > > /* choosing between porper HD and SD mode */ > - if (height == 480) > + if (height <= 480) > val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD; > - else if (height == 576) > + else if (height <= 576) > val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD; > - else if (height == 720) > + else if (height <= 720) > val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD; > - else if (height == 1080) > + else if (height <= 1080) > val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD; > else > val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD; It doesn't make sense to have these checks separate from the code you added in the last patch. IMO, you should consolidate those checks in one function so you only need to update them once in the future. Sean > -- > 1.8.0 > ___ 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 Wed, Jan 2, 2013 at 4:37 PM, Alex Deucher wrote: > On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf > wrote: >> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: >>> Please affected people can you test if patch : >>> http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch >>> >>> Fix the issue, you need to make sure you don't have the patch that >>> disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c >>> is : >>> .copy = &r600_copy_dma, >>> .copy_ring_index = R600_RING_TYPE_DMA_INDEX, >> >> It fixes the issue for me. Thanks. > > The count is actually the count, not count - 1. The real fix seems to > be that r6xx requires 2 dw aligned transfers. The attached patch > fixes the issue for me. > Catching up with this thread. I reverted the drm/radeon: use async dma for ttm buffer moves on 6xx-SI commit id: 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 Do I need to apply this patch without reverting 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2? Thanks, -- Shuah ___ 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 Wed, Jan 2, 2013 at 4:59 PM, Alex Deucher wrote: >>> >> >> Catching up with this thread. I reverted the >> >> drm/radeon: use async dma for ttm buffer moves on 6xx-SI >> commit id: 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 >> >> Do I need to apply this patch without reverting >> 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2? > > Correct. Don't revert anything. Just apply this patch. > > Alex Alex, Your patch fixed the problem I was seeing. -- Shuah ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] [RFC] video: exynos mipi dsi: Making Exynos MIPI Complaint with CDF
Hi Vikas,
Some nitpicks inline
Subject: s/Complaint/Compliant
On 2 January 2013 18:47, Vikas C Sajjan wrote:
> From: Vikas Sajjan
>
Please add some description about this patch here.
> Signed-off-by: Vikas Sajjan
> ---
> drivers/video/exynos/exynos_mipi_dsi.c| 46
> ++---
> drivers/video/exynos/exynos_mipi_dsi_common.c | 22
> drivers/video/exynos/exynos_mipi_dsi_common.h | 12 +++
> include/video/exynos_mipi_dsim.h |5 ++-
> 4 files changed, 56 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c
> b/drivers/video/exynos/exynos_mipi_dsi.c
> index 07d70a3..88b2aa9 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
> @@ -32,14 +32,13 @@
> #include
> #include
> #include
> -
> +#include
> #include
>
> #include
>
> #include "exynos_mipi_dsi_common.h"
> #include "exynos_mipi_dsi_lowlevel.h"
> -
> struct mipi_dsim_ddi {
> int bus_id;
> struct list_headlist;
> @@ -111,12 +110,13 @@ static void exynos_mipi_update_cfg(struct
> mipi_dsim_device *dsim)
> exynos_mipi_dsi_stand_by(dsim, 1);
> }
>
> -static int exynos_mipi_dsi_early_blank_mode(struct mipi_dsim_device *dsim,
> +static int exynos_mipi_dsi_early_blank_mode(struct video_source
> *video_source,
> int power)
> {
> + struct mipi_dsim_device *dsim = container_of(video_source,
> + struct mipi_dsim_device,
> video_source);
> struct mipi_dsim_lcd_driver *client_drv = dsim->dsim_lcd_drv;
> struct mipi_dsim_lcd_device *client_dev = dsim->dsim_lcd_dev;
> -
> switch (power) {
> case FB_BLANK_POWERDOWN:
> if (dsim->suspended)
> @@ -139,12 +139,13 @@ static int exynos_mipi_dsi_early_blank_mode(struct
> mipi_dsim_device *dsim,
> return 0;
> }
>
> -static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int
> power)
> +static int exynos_mipi_dsi_blank_mode(struct video_source *video_source, int
> power)
> {
> + struct mipi_dsim_device *dsim = container_of(video_source,
> + struct mipi_dsim_device,
> video_source);
> struct platform_device *pdev = to_platform_device(dsim->dev);
> struct mipi_dsim_lcd_driver *client_drv = dsim->dsim_lcd_drv;
> struct mipi_dsim_lcd_device *client_dev = dsim->dsim_lcd_dev;
> -
> switch (power) {
> case FB_BLANK_UNBLANK:
> if (!dsim->suspended)
> @@ -319,12 +320,19 @@ static struct mipi_dsim_ddi
> *exynos_mipi_dsi_bind_lcd_ddi(
> return NULL;
> }
>
> -/* define MIPI-DSI Master operations. */
> -static struct mipi_dsim_master_ops master_ops = {
> - .cmd_read = exynos_mipi_dsi_rd_data,
> - .cmd_write = exynos_mipi_dsi_wr_data,
> - .get_dsim_frame_done=
> exynos_mipi_dsi_get_frame_done_status,
> - .clear_dsim_frame_done = exynos_mipi_dsi_clear_frame_done,
>
+static void panel_dsi_release(struct video_source *src)
How about exynos_dsi_panel_release in line with other function names?
> +{
> + printk("dsi entity release\n");
Please use pr_* function here (instead of printk).
> +}
> +
> +static const struct common_video_source_ops dsi_common_ops = {
Some comments for this place holder would be good.
> +};
> +
> +static const struct dsi_video_source_ops exynos_dsi_ops = {
> + .dcs_read = exynos_mipi_dsi_rd_data,
> + .dcs_write = exynos_mipi_dsi_wr_data,
> + .get_frame_done =
> exynos_mipi_dsi_get_frame_done_status,
> + .clear_frame_done = exynos_mipi_dsi_clear_frame_done,
> .set_early_blank_mode = exynos_mipi_dsi_early_blank_mode,
> .set_blank_mode = exynos_mipi_dsi_blank_mode,
> };
> @@ -362,7 +370,6 @@ static int exynos_mipi_dsi_probe(struct platform_device
> *pdev)
> }
>
> dsim->dsim_config = dsim_config;
> - dsim->master_ops = &master_ops;
>
> mutex_init(&dsim->lock);
>
> @@ -463,6 +470,19 @@ static int exynos_mipi_dsi_probe(struct platform_device
> *pdev)
>
> dsim->suspended = false;
>
> + dsim->video_source.dev = &pdev->dev;
> + dsim->video_source.release = panel_dsi_release;
> + dsim->video_source.common_ops = &dsi_common_ops;
> + dsim->video_source.ops.dsi = &exynos_dsi_ops;
> + dsim->video_source.name = "exynos";
Can't we get this from pdev?
> +
> + ret = video_source_register(&dsim->video_source);
> + if (ret < 0) {
> + printk("dsi entity register failed\n");
Please use pr_* function here (instead of printk).
> + goto err_bind;
> + }
> + printk("dsi entity registered: %p\n", &dsim->video_sour
Re: [PATCH 1/2] [RFC] video: exynos mipi dsi: Making Exynos MIPI Complaint with CDF
Hi Sachin,
Thanks for the comments.
On Thu, Jan 3, 2013 at 11:14 AM, Sachin Kamat wrote:
> Hi Vikas,
>
> Some nitpicks inline
>
> Subject: s/Complaint/Compliant
>
Oops, nice catch.
> On 2 January 2013 18:47, Vikas C Sajjan wrote:
>> From: Vikas Sajjan
>>
>
> Please add some description about this patch here.
>
sure.
>> Signed-off-by: Vikas Sajjan
>> ---
>> drivers/video/exynos/exynos_mipi_dsi.c| 46
>> ++---
>> drivers/video/exynos/exynos_mipi_dsi_common.c | 22
>> drivers/video/exynos/exynos_mipi_dsi_common.h | 12 +++
>> include/video/exynos_mipi_dsim.h |5 ++-
>> 4 files changed, 56 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c
>> b/drivers/video/exynos/exynos_mipi_dsi.c
>> index 07d70a3..88b2aa9 100644
>> --- a/drivers/video/exynos/exynos_mipi_dsi.c
>> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
>> @@ -32,14 +32,13 @@
>> #include
>> #include
>> #include
>> -
>> +#include
>> #include
>>
>> #include
>>
>> #include "exynos_mipi_dsi_common.h"
>> #include "exynos_mipi_dsi_lowlevel.h"
>> -
>> struct mipi_dsim_ddi {
>> int bus_id;
>> struct list_headlist;
>> @@ -111,12 +110,13 @@ static void exynos_mipi_update_cfg(struct
>> mipi_dsim_device *dsim)
>> exynos_mipi_dsi_stand_by(dsim, 1);
>> }
>>
>> -static int exynos_mipi_dsi_early_blank_mode(struct mipi_dsim_device *dsim,
>> +static int exynos_mipi_dsi_early_blank_mode(struct video_source
>> *video_source,
>> int power)
>> {
>> + struct mipi_dsim_device *dsim = container_of(video_source,
>> + struct mipi_dsim_device,
>> video_source);
>> struct mipi_dsim_lcd_driver *client_drv = dsim->dsim_lcd_drv;
>> struct mipi_dsim_lcd_device *client_dev = dsim->dsim_lcd_dev;
>> -
>> switch (power) {
>> case FB_BLANK_POWERDOWN:
>> if (dsim->suspended)
>> @@ -139,12 +139,13 @@ static int exynos_mipi_dsi_early_blank_mode(struct
>> mipi_dsim_device *dsim,
>> return 0;
>> }
>>
>> -static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int
>> power)
>> +static int exynos_mipi_dsi_blank_mode(struct video_source *video_source,
>> int power)
>> {
>> + struct mipi_dsim_device *dsim = container_of(video_source,
>> + struct mipi_dsim_device,
>> video_source);
>> struct platform_device *pdev = to_platform_device(dsim->dev);
>> struct mipi_dsim_lcd_driver *client_drv = dsim->dsim_lcd_drv;
>> struct mipi_dsim_lcd_device *client_dev = dsim->dsim_lcd_dev;
>> -
>> switch (power) {
>> case FB_BLANK_UNBLANK:
>> if (!dsim->suspended)
>> @@ -319,12 +320,19 @@ static struct mipi_dsim_ddi
>> *exynos_mipi_dsi_bind_lcd_ddi(
>> return NULL;
>> }
>>
>> -/* define MIPI-DSI Master operations. */
>> -static struct mipi_dsim_master_ops master_ops = {
>> - .cmd_read = exynos_mipi_dsi_rd_data,
>> - .cmd_write = exynos_mipi_dsi_wr_data,
>> - .get_dsim_frame_done=
>> exynos_mipi_dsi_get_frame_done_status,
>> - .clear_dsim_frame_done = exynos_mipi_dsi_clear_frame_done,
>>
>
> +static void panel_dsi_release(struct video_source *src)
>
> How about exynos_dsi_panel_release in line with other function names?
>
will modify.
>> +{
>> + printk("dsi entity release\n");
>
> Please use pr_* function here (instead of printk).
>
Sure.
>> +}
>> +
>> +static const struct common_video_source_ops dsi_common_ops = {
>
> Some comments for this place holder would be good.
>
>> +};
>> +
>> +static const struct dsi_video_source_ops exynos_dsi_ops = {
>> + .dcs_read = exynos_mipi_dsi_rd_data,
>> + .dcs_write = exynos_mipi_dsi_wr_data,
>> + .get_frame_done =
>> exynos_mipi_dsi_get_frame_done_status,
>> + .clear_frame_done = exynos_mipi_dsi_clear_frame_done,
>> .set_early_blank_mode = exynos_mipi_dsi_early_blank_mode,
>> .set_blank_mode = exynos_mipi_dsi_blank_mode,
>> };
>> @@ -362,7 +370,6 @@ static int exynos_mipi_dsi_probe(struct platform_device
>> *pdev)
>> }
>>
>> dsim->dsim_config = dsim_config;
>> - dsim->master_ops = &master_ops;
>>
>> mutex_init(&dsim->lock);
>>
>> @@ -463,6 +470,19 @@ static int exynos_mipi_dsi_probe(struct platform_device
>> *pdev)
>>
>> dsim->suspended = false;
>>
>> + dsim->video_source.dev = &pdev->dev;
>> + dsim->video_source.release = panel_dsi_release;
>> + dsim->video_source.common_ops = &dsi_common_ops;
>> + dsim->video_source.ops.dsi = &exynos_dsi_ops;
>> + dsim->video_source.name = "exynos";
>
> Can't we get this from pdev?
>
right, will change ac
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On 2013.01.02 at 18:37 -0500, Alex Deucher wrote: > On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf > wrote: > > On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: > >> Please affected people can you test if patch : > >> http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch > >> > >> Fix the issue, you need to make sure you don't have the patch that > >> disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c > >> is : > >> .copy = &r600_copy_dma, > >> .copy_ring_index = R600_RING_TYPE_DMA_INDEX, > > > > It fixes the issue for me. Thanks. > > The count is actually the count, not count - 1. The real fix seems to > be that r6xx requires 2 dw aligned transfers. The attached patch > fixes the issue for me. Yes, this one also works for me. Thanks. -- Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58914] Cannot start Radeon driver: "drmOpenByBusid: drmGetBusid reports " no bus ID
https://bugs.freedesktop.org/show_bug.cgi?id=58914 --- Comment #5 from Michel Dänzer --- (In reply to comment #4) > But if you can suggest a version to test I can start. I haven't seen any other similar reports, so if it happens with 3.7 kernels, it's probably not a (recent) kernel regression. > I have seen other people running the Intel drivers reporting this same sort > of error (the missing busID in the drmGetBusid call), and they thought it > was a race condition That seems unlikely in your case, given the timestamps in the log snippets you've provided. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct
Hi Vikas,
On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote:
> From: Vikas Sajjan
>
> Signed-off-by: Vikas Sajjan
> ---
> include/video/display.h |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/video/display.h b/include/video/display.h
> index b639fd0..fb2f437 100644
> --- a/include/video/display.h
> +++ b/include/video/display.h
> @@ -117,6 +117,12 @@ struct dsi_video_source_ops {
>
> void (*enable_hs)(struct video_source *src, bool enable);
>
> + /* frame related */
> + int (*get_frame_done)(struct video_source *src);
> + int (*clear_frame_done)(struct video_source *src);
> + int (*set_early_blank_mode)(struct video_source *src, int power);
> + int (*set_blank_mode)(struct video_source *src, int power);
> +
I'm not sure if all those extra ops are needed in any way.
Looking and Exynos MIPI DSIM driver, set_blank_mode is handling only
FB_BLANK_UNBLANK status, which basically equals to the already existing
enable operation, while set_early_blank mode handles only
FB_BLANK_POWERDOWN, being equal to disable callback.
Both get_frame_done and clear_frame_done do not look at anything used at
the moment and if frame done status monitoring will be ever needed, I
think a better way should be implemented.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
___
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 #14 from Andy Furniss --- (In reply to comment #13) > (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? FWIW I tried current drm-next + patch - 0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch And I still fail with etqw after about 10 secs, but do get more info. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: Failed to allocate a buffer: radeon:size : 7168 bytes radeon:alignment : 256 bytes radeon:domains : 2 EE r600_texture.c:697 r600_texture_transfer_map - failed to create temporary texture to hold untiled copy Mesa: User error: GL_OUT_OF_MEMORY in glTexSubImage radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. double fault: 'Segmentation fault', bailing out shutdown terminal support /home/andy/bin/etqw: line 1: 2472 Segmentation fault /usr/local/games/etqw/etqw dmesg - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (8192, 2, 4096, -12) [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! etqw.x86[2472]: segfault at 0 ip af5292ad sp bfbe3250 error 4 in gamex86.so[af254000+948000] -- 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
2013-01-03 00:37 keltezéssel, Alex Deucher írta: On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf wrote: On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: Please affected people can you test if patch : http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch Fix the issue, you need to make sure you don't have the patch that disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c is : .copy = &r600_copy_dma, .copy_ring_index = R600_RING_TYPE_DMA_INDEX, It fixes the issue for me. Thanks. The count is actually the count, not count - 1. The real fix seems to be that r6xx requires 2 dw aligned transfers. The attached patch fixes the issue for me. Alex I tried this patch over kernel 3.8.0-rc2 but the GDM screen is mostly garbage. Only some text, like "Not on the list?" below the users and small icons are visible but many user names are not rendered. http://tinypic.com/r/33xihit/6 I am on Fedora 18/x86_64, Radeon HD6570. Best regards, Zoltán Böszörményi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36522] Caught 16-bit read from uninitialized memory in drm_fb_helper_setcmap
https://bugzilla.kernel.org/show_bug.cgi?id=36522 --- Comment #11 from Christian Casteyde 2013-01-03 12:55:07 --- Udpate: Still present in 3.8-rc2 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/8] drm/exynos: fimd: add complete_scanout function
On Wed, Jan 2, 2013 at 10:24 PM, Sean Paul wrote:
> On Wed, Dec 26, 2012 at 6:27 AM, Prathyush K
> wrote:
> > The wait_for_vblank interface is modified to the complete_scanout
> > function in fimd. This patch adds the fimd_complete_scanout function
> >
> > Inside fimd_complete_scanout, we read the shadow register for each
> > window and compare it with the dma address of the framebuffer. If
> > the dma_address is in the shadow register, then the function waits
> > for the next vblank and returns.
> >
> > Signed-off-by: Prathyush K
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 32
> +++-
> > include/video/samsung_fimd.h | 1 +
> > 2 files changed, 32 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > index 3aeedf5..190ffde9 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > @@ -46,6 +46,7 @@
> > #define VIDOSD_D(win) (VIDOSD_BASE + 0x0C + (win) * 16)
> >
> > #define VIDWx_BUF_START(win, buf) (VIDW_BUF_START(buf) + (win) * 8)
> > +#define VIDWx_BUF_START_S(win, buf)(VIDW_BUF_START_S(buf) + (win) *
> 8)
> > #define VIDWx_BUF_END(win, buf)(VIDW_BUF_END(buf) +
> (win) * 8)
> > #define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4)
> >
> > @@ -363,13 +364,42 @@ static void fimd_wait_for_vblank(struct device
> *dev)
> > fimd_disable_vblank(dev);
> > }
> >
> > +static void fimd_complete_scanout(struct device *dev, dma_addr_t
> dma_addr,
> > + unsigned long size)
> > +{
> > + struct fimd_context *ctx = get_fimd_context(dev);
> > + int win;
> > + bool in_use = false;
> > +
> > + if (ctx->suspended)
> > + return;
> > +
>
> Is this really possible? If it is, I think there's potential for
> trouble. It seems possible that an fb is current, but we're suspended.
> If we exit early here, the fb will be freed and we'll be sad when we
> come out of suspend.
>
> Hi Sean,
Before suspend, we disable all the windows (and wait for vsync) and keep
track of which windows need to be resumed.
If a fb is being removed during suspend, and if that fb was previously set
to fimd, we modify the resume flag
so that the window will not be resumed during fimd_resume.
> > + for (win = 0; win < WINDOWS_NR; win++) {
> > + dma_addr_t dma_addr_in_use;
> > +
> > + if (!ctx->win_data[win].enabled)
> > + continue;
> > +
> > + dma_addr_in_use = readl(ctx->regs +
> VIDWx_BUF_START_S(win, 0));
> > + if (dma_addr_in_use >= dma_addr &&
> > + dma_addr_in_use < (dma_addr + size)) {
> > + in_use = true;
> > + break;
> > + }
>
> I think this has the opposite problem as your mixer patch. You're
> checking if the framebuffer is in the shadow register, but I don't
> think this code will wait if the fb is currently being scanned out. I
> hope I'm just missing something :)
>
> Right, I do not check for the base register here. This is because I also
consider the disable_crtc
function.
Consider the following two cases:
1>
fb1 set to fimd and fimd is reading from fb1 (so both base register and
shadow register have fb1's dma addr)
call remove fb1
since crtc->fb == fb1, the "exynos_drm_crtc_disable" gets called. This will
disable the window and also turn off fimd with DPMS_OFF.
fimd dpms off will ensure that the window actually gets disabled by waiting
for vblank.
Now before removing fb1, we call complete_scanout. Since fimd is already
suspended, this will just return. No issue.
2>
fb1 set to fimd, fimd reading from fb1.
fb2 set to fimd
call remove fb1
(now base register has fb2, shadow register has fb1)
since crtc->fb == fb2, crtc_disable wont be called.
In complete scanout, we check only shadow register (which has fb1).
So we wait for vsync, so that next dma starts from fb2 and then we go ahead
and remove fb1.
I tried to apply the same logic for mixer:
In mixer, it is slightly more complex, since we have layer updates.
Consider the following cases for mixer:
1> fb1 set to mixer (base register has fb1) - also fb1 gets queued with a
layer update.
mixer is reading from fb1 (shadow register has fb1).
remove fb1
crtc->fb == fb1, so win_disable gets called followed by crtc off. This will
wait for vsync.
complete_scanout will just return. remove fb1. no issue.
2> mixer reading from fb1
fb2 set to mixer (layer update)
remove fb1
In this case, base has fb2, shadow has fb1.
crtc->fb == fb2, so no win_disable.
complete scanout will wait for vsync and ensure dma is from fb2. remove
fb1. no issue.
3> mixer reading from fb1. shadow reg has fb1
fb2 set to mixer (layer update - base reg has fb2)
fb3 set to mixer (since layer update is
Re: [PATCH 7/8] drm/exynos: hdmi: add complete_scanout function
On Wed, Jan 2, 2013 at 10:12 PM, Sean Paul wrote:
> On Wed, Dec 26, 2012 at 6:27 AM, Prathyush K
> wrote:
> > The wait_for_vblank interface is modified to the complete_scanout
> > function in hdmi. This inturn calls the complete_scanout mixer op.
> > This patch also adds the mixer_complete_scanout function.
> >
> > Inside mixer_complete_scanout, we read the base register and shadow
> > register for each window and compare it with the dma address of the
> > framebuffer. If the dma_address is in the base register, the mixer
> > window is disabled. If the dma_address is in the shadow register,
> > then the function waits for the next vblank and returns.
> >
> > Signed-off-by: Prathyush K
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 11 ++
> > drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 3 ++-
> > drivers/gpu/drm/exynos/exynos_mixer.c| 37
> +++-
> > 3 files changed, 45 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> > index d8ae47e..e32eb1c 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> > @@ -177,14 +177,17 @@ static void drm_hdmi_disable_vblank(struct device
> *subdrv_dev)
> > return mixer_ops->disable_vblank(ctx->mixer_ctx->ctx);
> > }
> >
> > -static void drm_hdmi_wait_for_vblank(struct device *subdrv_dev)
> > +static void drm_hdmi_complete_scanout(struct device *subdrv_dev,
> > + dma_addr_t dma_addr,
> > + unsigned long size)
> > {
> > struct drm_hdmi_context *ctx = to_context(subdrv_dev);
> >
> > DRM_DEBUG_KMS("%s\n", __FILE__);
> >
> > - if (mixer_ops && mixer_ops->wait_for_vblank)
> > - mixer_ops->wait_for_vblank(ctx->mixer_ctx->ctx);
> > + if (mixer_ops && mixer_ops->complete_scanout)
> > + mixer_ops->complete_scanout(ctx->mixer_ctx->ctx,
> > + dma_addr, size);
> > }
> >
> > static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
> > @@ -263,7 +266,7 @@ static struct exynos_drm_manager_ops
> drm_hdmi_manager_ops = {
> > .apply = drm_hdmi_apply,
> > .enable_vblank = drm_hdmi_enable_vblank,
> > .disable_vblank = drm_hdmi_disable_vblank,
> > - .wait_for_vblank = drm_hdmi_wait_for_vblank,
> > + .complete_scanout = drm_hdmi_complete_scanout,
> > .mode_fixup = drm_hdmi_mode_fixup,
> > .mode_set = drm_hdmi_mode_set,
> > .get_max_resol = drm_hdmi_get_max_resol,
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> > index 4fad00c..7d5bf00 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> > @@ -51,7 +51,8 @@ struct exynos_mixer_ops {
> > int (*iommu_on)(void *ctx, bool enable);
> > int (*enable_vblank)(void *ctx, int pipe);
> > void (*disable_vblank)(void *ctx);
> > - void (*wait_for_vblank)(void *ctx);
> > + void (*complete_scanout)(void *ctx, dma_addr_t dma_addr,
> > + unsigned long size);
> > void (*dpms)(void *ctx, int mode);
> >
> > /* overlay */
> > diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> > index 3369d57..151e13f 100644
> > --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> > +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> > @@ -861,6 +861,41 @@ static void mixer_wait_for_vblank(void *ctx)
> > DRM_DEBUG_KMS("vblank wait timed out.\n");
> > }
> >
> > +static void mixer_complete_scanout(void *ctx, dma_addr_t dma_addr,
> > + unsigned long size)
> > +{
> > + struct mixer_context *mixer_ctx = ctx;
> > + struct mixer_resources *res = &mixer_ctx->mixer_res;
> > + int win;
> > + bool in_use = false;
> > + bool in_use_s = false;
> > +
> > + if (!mixer_ctx->powered)
>
> Accesses to mixer_ctx->powered are always protected by mixer_mutex,
> this should probably stay consistent (either way).
>
>
Hi Sean,
Right, thanks for pointing that out. I'll update in next patch set.
> > + return;
> > +
> > + for (win = 0; win < MIXER_WIN_NR; win++) {
> > + dma_addr_t dma_addr_in_use;
> > +
> > + if (!mixer_ctx->win_data[win].enabled)
> > + continue;
> > +
> > + dma_addr_in_use = mixer_reg_read(res,
> MXR_GRAPHIC_BASE(win));
> > + if (dma_addr_in_use >= dma_addr &&
> > + dma_addr_in_use < (dma_addr + size)) {
> > + mixer_win_disable(ctx, win);
> > + in_use = true;
> > + }
> > +
> > + dma_addr_in_use = mixer_reg_read(res,
> M
Re: Resume regression with nouveau 3.8rc1 (bisected)
On Wed, Jan 02, 2013 at 04:19:35PM +0100, Pontus Fuchs wrote: > Hi, > > Starting with 3.8rc1 I get a black screen when resuming after suspend. > The kernel is alive because I can switch to VT1 and reboot with > ctrl-alt-delete. > > I bisected the problem down to this commit: > > 186ecad21: drm/nv50/disp: move remaining interrupt handling into core > > Hardware is 8400M GS (10de:0427) in a Dell XPS M1330. There's already open bug report for that: https://bugs.freedesktop.org/show_bug.cgi?id=58729 And my nv92 does not resume too, with similar symptoms, since nouveau display rework hit the tree. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 52231] New: possible circular locking dependency detected in radeon driver
https://bugzilla.kernel.org/show_bug.cgi?id=52231
Summary: possible circular locking dependency detected in
radeon driver
Product: Drivers
Version: 2.5
Kernel Version: 3.8-rc2
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: casteyde.christ...@free.fr
Regression: Yes
Kernel 3.8-rc2
Slackware64 14
Core i7, 6 GB RAM, 64 bit mode
Since kernel 3.8-rc2 with kmemcheck and lockdep hacking options turned on, I
get the following lockdep warning:
EXT4-fs (sda3): re-mounted. Opts: discard,commit=0
==
[ INFO: possible circular locking dependency detected ]
3.8.0-rc2 #21 Not tainted
---
99video/2835 is trying to acquire lock:
((fb_notifier_list).rwsem){.+.+.+}, at: []
__blocking_notifier_call_chain+0x54/0xd0
but task is already holding lock:
(console_lock){+.+.+.}, at: [] store_fbstate+0x55/0x80
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (console_lock){+.+.+.}:
[] lock_acquire+0x5a/0x70
[] console_lock+0x57/0x60
[] register_con_driver+0x34/0x140
[] take_over_console+0x29/0x60
[] fbcon_takeover+0x5b/0xb0
[] fbcon_event_notify+0x72d/0x830
[] notifier_call_chain+0x5e/0x150
[] __blocking_notifier_call_chain+0x6d/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] register_framebuffer+0x1bd/0x2f0
[] drm_fb_helper_single_fb_probe+0x1d3/0x2f0
[] drm_fb_helper_initial_config+0x1d1/0x240
[] radeon_fbdev_init+0xba/0x110
[] radeon_modeset_init+0x501/0xb60
[] radeon_driver_load_kms+0xe0/0x150
[] drm_get_pci_dev+0x17e/0x2b0
[] radeon_pci_probe+0xaa/0xe0
[] local_pci_probe+0x46/0x80
[] pci_device_probe+0x101/0x110
[] driver_probe_device+0x76/0x220
[] __driver_attach+0xa3/0xb0
[] bus_for_each_dev+0x4d/0x90
[] driver_attach+0x19/0x20
[] bus_add_driver+0x1a0/0x270
[] driver_register+0x72/0x170
[] __pci_register_driver+0x5f/0x70
[] drm_pci_init+0x115/0x130
[] radeon_init+0xe7/0xe9
[] do_one_initcall+0x11a/0x170
[] kernel_init+0x11c/0x290
[] ret_from_fork+0x7c/0xb0
-> #0 ((fb_notifier_list).rwsem){.+.+.+}:
[] __lock_acquire+0x1a20/0x1ca0
[] lock_acquire+0x5a/0x70
[] down_read+0x39/0x8c
[] __blocking_notifier_call_chain+0x54/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] fb_set_suspend+0x46/0x60
[] store_fbstate+0x60/0x80
[] dev_attr_store+0x13/0x20
[] sysfs_write_file+0xdb/0x150
[] vfs_write+0xa6/0x160
[] sys_write+0x50/0xa0
[] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(console_lock);
lock((fb_notifier_list).rwsem);
lock(console_lock);
lock((fb_notifier_list).rwsem);
*** DEADLOCK ***
4 locks held by 99video/2835:
#0: (&buffer->mutex){+.+.+.}, at: []
sysfs_write_file+0x43/0x150
#1: (s_active#124){.+.+.+}, at: []
sysfs_write_file+0xc3/0x150
#2: (&fb_info->lock){+.+.+.}, at: [] lock_fb_info+0x21/0x60
#3: (console_lock){+.+.+.}, at: [] store_fbstate+0x55/0x80
stack backtrace:
Pid: 2835, comm: 99video Not tainted 3.8.0-rc2 #21
Call Trace:
[] print_circular_bug+0x28e/0x29f
[] __lock_acquire+0x1a20/0x1ca0
[] lock_acquire+0x5a/0x70
[] ? __blocking_notifier_call_chain+0x54/0xd0
[] ? __lock_is_held+0x5f/0x90
[] down_read+0x39/0x8c
[] ? __blocking_notifier_call_chain+0x54/0xd0
[] __blocking_notifier_call_chain+0x54/0xd0
[] __blocking_notifier_call_chain+0x54/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] fb_set_suspend+0x46/0x60
[] ? console_lock+0x57/0x60
[] ? store_fbstate+0x55/0x80
[] store_fbstate+0x60/0x80
[] dev_attr_store+0x13/0x20
[] sysfs_write_file+0xdb/0x150
[] vfs_write+0xa6/0x160
[] sys_write+0x50/0xa0
[] system_call_fastpath+0x16/0x1b
PM: Syncing filesystems ... done.
WARNING: kmemcheck: Caught 16-bit read from uninitialized memory
(8801c52bbc20)
01000100b0bb2bc50188
u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u
^
Pid: 2256, comm: X Not tainted 3.8.0-rc2 #21 Acer Aspire 7750G/JE70_HR
RIP: 0010:[] []
drm_fb_helper_setcmap+0x111/0x400
RSP: 0018:8801c0c35978 EFLAGS: 00010206
RAX: 8801c52bbc00 RBX: 8801c476e800 RCX:
RDX: 000
[Bug 52231] possible circular locking dependency detected in radeon driver
https://bugzilla.kernel.org/show_bug.cgi?id=52231 Alan changed: What|Removed |Added CC||a...@lxorguk.ukuu.org.uk Component|Video(DRI - non Intel) |Console/Framebuffers AssignedTo|drivers_video-dri@kernel-bu |jsimm...@infradead.org |gs.osdl.org | --- Comment #1 from Alan 2013-01-03 13:08:55 --- Fix was posted 7th December, no idea why it still doesn't seem to have been applied. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/12] drm/radeon: remove unecessary assignment
For the series:
Reviewed-by: Marek Olšák
Marek
On Thu, Jan 3, 2013 at 12:27 AM, Ilija Hadzic
wrote:
> length_dw field was assigned twice. While at it, move user_ptr
> assignment together with all other assignments to p->chunks[i]
> structure to make the code more readable.
>
> Signed-off-by: Ilija Hadzic
> ---
> drivers/gpu/drm/radeon/radeon_cs.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index 396baba0..4be64e0 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -203,7 +203,7 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
> void *data)
> p->chunks[i].length_dw = user_chunk.length_dw;
> p->chunks[i].kdata = NULL;
> p->chunks[i].chunk_id = user_chunk.chunk_id;
> -
> + p->chunks[i].user_ptr = (void __user *)(unsigned
> long)user_chunk.chunk_data;
> if (p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) {
> p->chunk_relocs_idx = i;
> }
> @@ -226,9 +226,6 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
> void *data)
> return -EINVAL;
> }
>
> - p->chunks[i].length_dw = user_chunk.length_dw;
> - p->chunks[i].user_ptr = (void __user *)(unsigned
> long)user_chunk.chunk_data;
> -
> cdata = (uint32_t *)(unsigned long)user_chunk.chunk_data;
> if ((p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) ||
> (p->chunks[i].chunk_id == RADEON_CHUNK_ID_FLAGS)) {
> --
> 1.7.12
>
> ___
> 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 57842] r200: Culling is broken when rendering to an FBO
https://bugs.freedesktop.org/show_bug.cgi?id=57842 --- Comment #16 from Stefan Dösinger --- Commit it to Git and use git send-email to send it to mesa-...@lists.freedesktop.org . Google finds many tutorials on how to do this. -- 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
> -Original Message- > From: Boszormenyi Zoltan [mailto:zbos...@pr.hu] > Sent: Thursday, January 03, 2013 6:37 AM > To: Alex Deucher > Cc: Markus Trippelsdorf; lkml; dri-devel@lists.freedesktop.org; Deucher, > Alexander; Borislav Petkov; Shuah Khan > Subject: Re: radeon :02:00.0: GPU lockup CP stall for more than > 1msec > > 2013-01-03 00:37 keltezéssel, Alex Deucher írta: > > On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf > > wrote: > >> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: > >>> Please affected people can you test if patch : > >>> http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy- > on-r6xx-r7xx-evergen-ni-si-g.patch > >>> > >>> Fix the issue, you need to make sure you don't have the patch that > >>> disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c > >>> is : > >>> .copy = &r600_copy_dma, > >>> .copy_ring_index = R600_RING_TYPE_DMA_INDEX, > >> It fixes the issue for me. Thanks. > > The count is actually the count, not count - 1. The real fix seems to > > be that r6xx requires 2 dw aligned transfers. The attached patch > > fixes the issue for me. > > > > Alex > > I tried this patch over kernel 3.8.0-rc2 but the GDM screen is mostly garbage. > Only some text, like "Not on the list?" below the users and small icons are > visible > but many user names are not rendered. http://tinypic.com/r/33xihit/6 > I am on Fedora 18/x86_64, Radeon HD6570. I don't think the issue you are seeing is related to this one. Looks similar to: https://bugs.freedesktop.org/show_bug.cgi?id=55574 Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #50 from Alex Deucher --- (In reply to comment #49) > > Is the BusID line in the intel device section not needed? What is needed for > X to automatically detect multiple GPUs properly and show some video output > from the correct card? You'll need to use vga-switcheroo to select the card you want to use. Then you should be able to start X without any config and it will start on the one selected by vga-switcheroo. Having two device sections as your config does will force X to try and start on both devices. -- 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 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #51 from Anonymous Helper --- (In reply to comment #50) > You'll need to use vga-switcheroo to select the card you want to use. Then > you should be able to start X without any config and it will start on the > one selected by vga-switcheroo. Having two device sections as your config > does will force X to try and start on both devices. I tried without the BusID but all I got was a black screen. For some reason when I switch to the intel GPU I get a black screen also, though it did work when I booted from grub-efi earlier with the well documented outb commands to disable AMD (no BIOS from EFI w/o efistub). Not sure if it's an issue with vga-switcheroo, intel driver or something else. I don't know if it's a problem, but both cards are powered on at boot. I can switch back and forth between the GPUs (though it's tricky doing so blind when on intel graphics). Any other suggestions? Thanks. -- 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 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #52 from Alex Deucher --- (In reply to comment #51) > Any other suggestions? Thanks. You might ask on the dri-devel mailing list. This is getting off topic for 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
[PATCH 1/2] drm/radeon: print dma status reg on lockup (v2)
From: Jerome Glisse
To help debug dma related lockup.
v2: agd5f: update SI as well
Signed-off-by: Jerome Glisse
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |4
drivers/gpu/drm/radeon/evergreend.h |3 +++
drivers/gpu/drm/radeon/ni.c |4
drivers/gpu/drm/radeon/nid.h|1 -
drivers/gpu/drm/radeon/r600.c |4
drivers/gpu/drm/radeon/si.c |9 +
drivers/gpu/drm/radeon/sid.h|2 ++
7 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index f95d7fc..6dc9ee7 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2331,6 +2331,8 @@ static int evergreen_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
evergreen_mc_stop(rdev, &save);
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
@@ -2376,6 +2378,8 @@ static int evergreen_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
evergreen_mc_resume(rdev, &save);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/evergreend.h
b/drivers/gpu/drm/radeon/evergreend.h
index cb9baaa..f82f98a 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -2027,4 +2027,7 @@
/* cayman packet3 addition */
#defineCAYMAN_PACKET3_DEALLOC_STATE0x14
+/* DMA regs common on r6xx/r7xx/evergreen/ni */
+#define DMA_STATUS_REG0xd034
+
#endif
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 7bdbcb0..6dae387 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1331,6 +1331,8 @@ static int cayman_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
dev_info(rdev->dev, " VM_CONTEXT0_PROTECTION_FAULT_ADDR 0x%08X\n",
RREG32(0x14F8));
dev_info(rdev->dev, " VM_CONTEXT0_PROTECTION_FAULT_STATUS 0x%08X\n",
@@ -1387,6 +1389,8 @@ static int cayman_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
evergreen_mc_resume(rdev, &save);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
index b93186b..22a62c6 100644
--- a/drivers/gpu/drm/radeon/nid.h
+++ b/drivers/gpu/drm/radeon/nid.h
@@ -675,4 +675,3 @@
#defineDMA_PACKET_NOP0xf
#endif
-
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 9f4ce5e..252067b 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1297,6 +1297,8 @@ static int r600_gpu_soft_reset(struct radeon_device *rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
rv515_mc_stop(rdev, &save);
if (r600_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
@@ -1348,6 +1350,8 @@ static int r600_gpu_soft_reset(struct radeon_device *rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
rv515_mc_resume(rdev, &save);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index ef68365..74d3845 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2145,6 +2145,13 @@ static int si_gpu_soft_reset(struct radeon_device *rdev)
RREG32(GRBM_STATUS_SE1));
dev_info(rdev->dev, " SRBM_STATUS=0x%08X\n",
RREG32(SRBM_STATUS));
+ dev_info(rdev->dev, " DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STAT
[PATCH 2/2] drm/radeon: reset dma engine on gpu reset (v2)
From: Jerome Glisse
This try to reset the dma engine when performing gpu reset. Hopefully
bringing back the gpu dma engine in sane state.
v2: agd5f: fix dma reset on cayman/TN, add support for SI
Signed-off-by: Jerome Glisse
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 30 +-
drivers/gpu/drm/radeon/evergreend.h | 10 +-
drivers/gpu/drm/radeon/ni.c | 35 ++-
drivers/gpu/drm/radeon/nid.h|2 +-
drivers/gpu/drm/radeon/r600.c | 28 ++--
drivers/gpu/drm/radeon/si.c | 18 +-
drivers/gpu/drm/radeon/sid.h| 16
7 files changed, 112 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 6dc9ee7..f92f6bb 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2309,19 +2309,19 @@ bool evergreen_gpu_is_lockup(struct radeon_device
*rdev, struct radeon_ring *rin
static int evergreen_gpu_soft_reset(struct radeon_device *rdev)
{
struct evergreen_mc_save save;
- u32 grbm_reset = 0;
+ u32 grbm_reset = 0, tmp;
if (!(RREG32(GRBM_STATUS) & GUI_ACTIVE))
return 0;
dev_info(rdev->dev, "GPU softreset \n");
- dev_info(rdev->dev, " GRBM_STATUS=0x%08X\n",
+ dev_info(rdev->dev, " GRBM_STATUS = 0x%08X\n",
RREG32(GRBM_STATUS));
- dev_info(rdev->dev, " GRBM_STATUS_SE0=0x%08X\n",
+ dev_info(rdev->dev, " GRBM_STATUS_SE0 = 0x%08X\n",
RREG32(GRBM_STATUS_SE0));
- dev_info(rdev->dev, " GRBM_STATUS_SE1=0x%08X\n",
+ dev_info(rdev->dev, " GRBM_STATUS_SE1 = 0x%08X\n",
RREG32(GRBM_STATUS_SE1));
- dev_info(rdev->dev, " SRBM_STATUS=0x%08X\n",
+ dev_info(rdev->dev, " SRBM_STATUS = 0x%08X\n",
RREG32(SRBM_STATUS));
dev_info(rdev->dev, " R_008674_CP_STALLED_STAT1 = 0x%08X\n",
RREG32(CP_STALLED_STAT1));
@@ -2337,9 +2337,21 @@ static int evergreen_gpu_soft_reset(struct radeon_device
*rdev)
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
}
+
/* Disable CP parsing/prefetching */
WREG32(CP_ME_CNTL, CP_ME_HALT | CP_PFP_HALT);
+ /* Disable DMA */
+ tmp = RREG32(DMA_RB_CNTL);
+ tmp &= ~DMA_RB_ENABLE;
+ WREG32(DMA_RB_CNTL, tmp);
+
+ /* Reset dma */
+ WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA);
+ RREG32(SRBM_SOFT_RESET);
+ udelay(50);
+ WREG32(SRBM_SOFT_RESET, 0);
+
/* reset all the gfx blocks */
grbm_reset = (SOFT_RESET_CP |
SOFT_RESET_CB |
@@ -2362,13 +2374,13 @@ static int evergreen_gpu_soft_reset(struct
radeon_device *rdev)
(void)RREG32(GRBM_SOFT_RESET);
/* Wait a little for things to settle down */
udelay(50);
- dev_info(rdev->dev, " GRBM_STATUS=0x%08X\n",
+ dev_info(rdev->dev, " GRBM_STATUS = 0x%08X\n",
RREG32(GRBM_STATUS));
- dev_info(rdev->dev, " GRBM_STATUS_SE0=0x%08X\n",
+ dev_info(rdev->dev, " GRBM_STATUS_SE0 = 0x%08X\n",
RREG32(GRBM_STATUS_SE0));
- dev_info(rdev->dev, " GRBM_STATUS_SE1=0x%08X\n",
+ dev_info(rdev->dev, " GRBM_STATUS_SE1 = 0x%08X\n",
RREG32(GRBM_STATUS_SE1));
- dev_info(rdev->dev, " SRBM_STATUS=0x%08X\n",
+ dev_info(rdev->dev, " SRBM_STATUS = 0x%08X\n",
RREG32(SRBM_STATUS));
dev_info(rdev->dev, " R_008674_CP_STALLED_STAT1 = 0x%08X\n",
RREG32(CP_STALLED_STAT1));
diff --git a/drivers/gpu/drm/radeon/evergreend.h
b/drivers/gpu/drm/radeon/evergreend.h
index f82f98a..5786a32 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -742,8 +742,9 @@
#defineSOFT_RESET_ROM (1 << 14)
#defineSOFT_RESET_SEM (1 << 15)
#defineSOFT_RESET_VMC (1 << 17)
+#defineSOFT_RESET_DMA (1 << 20)
#defineSOFT_RESET_TST (1 << 21)
-#defineSOFT_RESET_REGBB(1 << 22)
+#defineSOFT_RESET_REGBB(1 << 22)
#defineSOFT_RESET_ORB (1 << 23)
/* display watermarks */
@@ -2028,6 +2029,13 @@
#defineCAYMAN_PACKET3_DEALLOC_STATE0x14
/* DMA regs common on r6xx/r7xx/evergreen/ni */
+#define DMA_RB_CNTL 0xd000
+# define DMA_RB_ENABLE (1 << 0)
+# define DMA_RB_SIZE
Re: [PATCH 8/8] drm/exynos: fimd: add complete_scanout function
On Thu, Jan 3, 2013 at 7:56 AM, Prathyush K wrote:
>
>
>
> On Wed, Jan 2, 2013 at 10:24 PM, Sean Paul wrote:
>>
>> On Wed, Dec 26, 2012 at 6:27 AM, Prathyush K
>> wrote:
>> > The wait_for_vblank interface is modified to the complete_scanout
>> > function in fimd. This patch adds the fimd_complete_scanout function
>> >
>> > Inside fimd_complete_scanout, we read the shadow register for each
>> > window and compare it with the dma address of the framebuffer. If
>> > the dma_address is in the shadow register, then the function waits
>> > for the next vblank and returns.
>> >
>> > Signed-off-by: Prathyush K
>> > ---
>> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 32
>> > +++-
>> > include/video/samsung_fimd.h | 1 +
>> > 2 files changed, 32 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > index 3aeedf5..190ffde9 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > @@ -46,6 +46,7 @@
>> > #define VIDOSD_D(win) (VIDOSD_BASE + 0x0C + (win) * 16)
>> >
>> > #define VIDWx_BUF_START(win, buf) (VIDW_BUF_START(buf) + (win) *
>> > 8)
>> > +#define VIDWx_BUF_START_S(win, buf)(VIDW_BUF_START_S(buf) + (win) *
>> > 8)
>> > #define VIDWx_BUF_END(win, buf)(VIDW_BUF_END(buf) +
>> > (win) * 8)
>> > #define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4)
>> >
>> > @@ -363,13 +364,42 @@ static void fimd_wait_for_vblank(struct device
>> > *dev)
>> > fimd_disable_vblank(dev);
>> > }
>> >
>> > +static void fimd_complete_scanout(struct device *dev, dma_addr_t
>> > dma_addr,
>> > + unsigned long size)
>> > +{
>> > + struct fimd_context *ctx = get_fimd_context(dev);
>> > + int win;
>> > + bool in_use = false;
>> > +
>> > + if (ctx->suspended)
>> > + return;
>> > +
>>
>> Is this really possible? If it is, I think there's potential for
>> trouble. It seems possible that an fb is current, but we're suspended.
>> If we exit early here, the fb will be freed and we'll be sad when we
>> come out of suspend.
>>
> Hi Sean,
>
> Before suspend, we disable all the windows (and wait for vsync) and keep
> track of which windows need to be resumed.
>
> If a fb is being removed during suspend, and if that fb was previously set
> to fimd, we modify the resume flag
> so that the window will not be resumed during fimd_resume.
>
>
>>
>> > + for (win = 0; win < WINDOWS_NR; win++) {
>> > + dma_addr_t dma_addr_in_use;
>> > +
>> > + if (!ctx->win_data[win].enabled)
>> > + continue;
>> > +
>> > + dma_addr_in_use = readl(ctx->regs +
>> > VIDWx_BUF_START_S(win, 0));
>> > + if (dma_addr_in_use >= dma_addr &&
>> > + dma_addr_in_use < (dma_addr + size)) {
>> > + in_use = true;
>> > + break;
>> > + }
>>
>> I think this has the opposite problem as your mixer patch. You're
>> checking if the framebuffer is in the shadow register, but I don't
>> think this code will wait if the fb is currently being scanned out. I
>> hope I'm just missing something :)
>>
> Right, I do not check for the base register here. This is because I also
> consider the disable_crtc
> function.
>
> Consider the following two cases:
>
> 1>
> fb1 set to fimd and fimd is reading from fb1 (so both base register and
> shadow register have fb1's dma addr)
> call remove fb1
>
> since crtc->fb == fb1, the "exynos_drm_crtc_disable" gets called. This will
> disable the window and also turn off fimd with DPMS_OFF.
>
> fimd dpms off will ensure that the window actually gets disabled by waiting
> for vblank.
>
> Now before removing fb1, we call complete_scanout. Since fimd is already
> suspended, this will just return. No issue.
>
I see the code path you're talking about. I think I was confused by
the "suspended" name, it also covers the disabled/off case.
> 2>
> fb1 set to fimd, fimd reading from fb1.
> fb2 set to fimd
> call remove fb1
> (now base register has fb2, shadow register has fb1)
>
> since crtc->fb == fb2, crtc_disable wont be called.
>
> In complete scanout, we check only shadow register (which has fb1).
> So we wait for vsync, so that next dma starts from fb2 and then we go ahead
> and remove fb1.
>
Ok, I think I've straightened out my mental model of how this works.
Thanks for the explanation
> I tried to apply the same logic for mixer:
> In mixer, it is slightly more complex, since we have layer updates.
>
> Consider the following cases for mixer:
>
> 1> fb1 set to mixer (base register has fb1) - also fb1 gets queued with a
> layer update.
> mixer is reading from fb1 (shadow register has fb1).
> remove fb1
>
> crtc->fb == fb1, so win_disable gets called followed by
Re: [PATCH 7/8] drm/exynos: hdmi: add complete_scanout function
On Thu, Jan 3, 2013 at 7:58 AM, Prathyush K wrote:
>
>
>
> On Wed, Jan 2, 2013 at 10:12 PM, Sean Paul wrote:
>>
>> On Wed, Dec 26, 2012 at 6:27 AM, Prathyush K
>> wrote:
>> > The wait_for_vblank interface is modified to the complete_scanout
>> > function in hdmi. This inturn calls the complete_scanout mixer op.
>> > This patch also adds the mixer_complete_scanout function.
>> >
>> > Inside mixer_complete_scanout, we read the base register and shadow
>> > register for each window and compare it with the dma address of the
>> > framebuffer. If the dma_address is in the base register, the mixer
>> > window is disabled. If the dma_address is in the shadow register,
>> > then the function waits for the next vblank and returns.
>> >
>> > Signed-off-by: Prathyush K
>> > ---
>> > drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 11 ++
>> > drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 3 ++-
>> > drivers/gpu/drm/exynos/exynos_mixer.c| 37
>> > +++-
>> > 3 files changed, 45 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> > b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> > index d8ae47e..e32eb1c 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> > @@ -177,14 +177,17 @@ static void drm_hdmi_disable_vblank(struct device
>> > *subdrv_dev)
>> > return mixer_ops->disable_vblank(ctx->mixer_ctx->ctx);
>> > }
>> >
>> > -static void drm_hdmi_wait_for_vblank(struct device *subdrv_dev)
>> > +static void drm_hdmi_complete_scanout(struct device *subdrv_dev,
>> > + dma_addr_t dma_addr,
>> > + unsigned long size)
>> > {
>> > struct drm_hdmi_context *ctx = to_context(subdrv_dev);
>> >
>> > DRM_DEBUG_KMS("%s\n", __FILE__);
>> >
>> > - if (mixer_ops && mixer_ops->wait_for_vblank)
>> > - mixer_ops->wait_for_vblank(ctx->mixer_ctx->ctx);
>> > + if (mixer_ops && mixer_ops->complete_scanout)
>> > + mixer_ops->complete_scanout(ctx->mixer_ctx->ctx,
>> > + dma_addr, size);
>> > }
>> >
>> > static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
>> > @@ -263,7 +266,7 @@ static struct exynos_drm_manager_ops
>> > drm_hdmi_manager_ops = {
>> > .apply = drm_hdmi_apply,
>> > .enable_vblank = drm_hdmi_enable_vblank,
>> > .disable_vblank = drm_hdmi_disable_vblank,
>> > - .wait_for_vblank = drm_hdmi_wait_for_vblank,
>> > + .complete_scanout = drm_hdmi_complete_scanout,
>> > .mode_fixup = drm_hdmi_mode_fixup,
>> > .mode_set = drm_hdmi_mode_set,
>> > .get_max_resol = drm_hdmi_get_max_resol,
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> > b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> > index 4fad00c..7d5bf00 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> > @@ -51,7 +51,8 @@ struct exynos_mixer_ops {
>> > int (*iommu_on)(void *ctx, bool enable);
>> > int (*enable_vblank)(void *ctx, int pipe);
>> > void (*disable_vblank)(void *ctx);
>> > - void (*wait_for_vblank)(void *ctx);
>> > + void (*complete_scanout)(void *ctx, dma_addr_t dma_addr,
>> > + unsigned long size);
>> > void (*dpms)(void *ctx, int mode);
>> >
>> > /* overlay */
>> > diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
>> > b/drivers/gpu/drm/exynos/exynos_mixer.c
>> > index 3369d57..151e13f 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> > @@ -861,6 +861,41 @@ static void mixer_wait_for_vblank(void *ctx)
>> > DRM_DEBUG_KMS("vblank wait timed out.\n");
>> > }
>> >
>> > +static void mixer_complete_scanout(void *ctx, dma_addr_t dma_addr,
>> > + unsigned long size)
>> > +{
>> > + struct mixer_context *mixer_ctx = ctx;
>> > + struct mixer_resources *res = &mixer_ctx->mixer_res;
>> > + int win;
>> > + bool in_use = false;
>> > + bool in_use_s = false;
>> > +
>> > + if (!mixer_ctx->powered)
>>
>> Accesses to mixer_ctx->powered are always protected by mixer_mutex,
>> this should probably stay consistent (either way).
>>
>
> Hi Sean,
>
> Right, thanks for pointing that out. I'll update in next patch set.
>
>
>>
>> > + return;
>> > +
>> > + for (win = 0; win < MIXER_WIN_NR; win++) {
>> > + dma_addr_t dma_addr_in_use;
>> > +
>> > + if (!mixer_ctx->win_data[win].enabled)
>> > + continue;
>> > +
>> > + dma_addr_in_use = mixer_reg_read(res,
>> > MXR_GRAPHIC_BASE(win));
>> > + if (dma_addr_in_use >= dma_addr &&
>> > + dma_addr_in_use < (dma_addr + size)) {
>> > +
Re: [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 void tegra_drm_close(struct drm_device *drm, struct drm_file *filp)
>> +{
>> +
>> +}
>> +
>
> This can be removed, right?
Yes, done.
>
>> +static struct platform_driver tegra_drm_platform_driver = {
>> +.driver = {
>> +.name = "tegradrm",
>
> This should be "tegra-drm" to match the module name.
Done.
>> -struct host1x_client;
>> +struct tegra_drm_client;
>
> I don't see the point in renaming this. All of the devices are still
> host1x clients, right? This patch would be a whole shorter if we didn't
> rename these. None of these symbols are exported either so there's not
> much chance for them to clash with anything.
Yep, we renamed it back to make the patch smaller.
>> diff --git a/include/drm/tegra_drm.h b/include/drm/tegra_drm.h
>> new file mode 100644
>> index 000..8632f49
>> --- /dev/null
>> +++ b/include/drm/tegra_drm.h
>> @@ -0,0 +1,20 @@
>> +/*
>> + * Copyright (c) 2012, NVIDIA CORPORATION. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope 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, see
[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board
https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #13 from Konrad Rzeszutek Wilk 2013-01-03 18:04:34 --- So is it safe to safe that it does not work without Xen? Or do you see stuff on the screen in baremetal mode? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/radeon: add GPU reset flags
From: Alex Deucher The idea here is to move to a finer grained reset. In some cases we may not need reset every block, and in other cases we may not need to re-init the entire asic. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 9b9422c..34e5230 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -132,6 +132,11 @@ extern int radeon_lockup_timeout; #define RADEON_VA_RESERVED_SIZE(8 << 20) #define RADEON_IB_VM_MAX_SIZE (64 << 10) +/* reset flags */ +#define RADEON_RESET_GFX (1 << 0) +#define RADEON_RESET_COMPUTE (1 << 1) +#define RADEON_RESET_DMA (1 << 2) + /* * Errata workarounds. */ -- 1.7.7.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/radeon: switch to a finer grained reset for r6xx/7xx
From: Alex Deucher
No change in functionality as we currently set all the reset
flags.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c | 85 -
1 files changed, 58 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 721b5af..923f936 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1258,9 +1258,8 @@ void r600_vram_scratch_fini(struct radeon_device *rdev)
* reset, it's up to the caller to determine if the GPU needs one. We
* might add an helper function to check that.
*/
-static int r600_gpu_soft_reset(struct radeon_device *rdev)
+static void r600_gpu_soft_reset_gfx(struct radeon_device *rdev)
{
- struct rv515_mc_save save;
u32 grbm_busy_mask = S_008010_VC_BUSY(1) | S_008010_VGT_BUSY_NO_DMA(1) |
S_008010_VGT_BUSY(1) | S_008010_TA03_BUSY(1) |
S_008010_TC_BUSY(1) | S_008010_SX_BUSY(1) |
@@ -1280,9 +1279,8 @@ static int r600_gpu_soft_reset(struct radeon_device *rdev)
u32 tmp;
if (!(RREG32(GRBM_STATUS) & GUI_ACTIVE))
- return 0;
+ return;
- dev_info(rdev->dev, "GPU softreset \n");
dev_info(rdev->dev, " R_008010_GRBM_STATUS = 0x%08X\n",
RREG32(R_008010_GRBM_STATUS));
dev_info(rdev->dev, " R_008014_GRBM_STATUS2 = 0x%08X\n",
@@ -1297,30 +1295,10 @@ static int r600_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
- dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
- RREG32(DMA_STATUS_REG));
- rv515_mc_stop(rdev, &save);
- if (r600_mc_wait_for_idle(rdev)) {
- dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
- }
/* Disable CP parsing/prefetching */
WREG32(R_0086D8_CP_ME_CNTL, S_0086D8_CP_ME_HALT(1));
- /* Disable DMA */
- tmp = RREG32(DMA_RB_CNTL);
- tmp &= ~DMA_RB_ENABLE;
- WREG32(DMA_RB_CNTL, tmp);
-
- /* Reset dma */
- if (rdev->family >= CHIP_RV770)
- WREG32(SRBM_SOFT_RESET, RV770_SOFT_RESET_DMA);
- else
- WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA);
- RREG32(SRBM_SOFT_RESET);
- udelay(50);
- WREG32(SRBM_SOFT_RESET, 0);
-
/* Check if any of the rendering block is busy and reset it */
if ((RREG32(R_008010_GRBM_STATUS) & grbm_busy_mask) ||
(RREG32(R_008014_GRBM_STATUS2) & grbm2_busy_mask)) {
@@ -1350,8 +1328,7 @@ static int r600_gpu_soft_reset(struct radeon_device *rdev)
RREG32(R_008020_GRBM_SOFT_RESET);
mdelay(15);
WREG32(R_008020_GRBM_SOFT_RESET, 0);
- /* Wait a little for things to settle down */
- mdelay(1);
+
dev_info(rdev->dev, " R_008010_GRBM_STATUS = 0x%08X\n",
RREG32(R_008010_GRBM_STATUS));
dev_info(rdev->dev, " R_008014_GRBM_STATUS2 = 0x%08X\n",
@@ -1366,8 +1343,60 @@ static int r600_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+
+}
+
+static void r600_gpu_soft_reset_dma(struct radeon_device *rdev)
+{
+ u32 tmp;
+
+ if (RREG32(DMA_STATUS_REG) & DMA_IDLE)
+ return;
+
dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
RREG32(DMA_STATUS_REG));
+
+ /* Disable DMA */
+ tmp = RREG32(DMA_RB_CNTL);
+ tmp &= ~DMA_RB_ENABLE;
+ WREG32(DMA_RB_CNTL, tmp);
+
+ /* Reset dma */
+ if (rdev->family >= CHIP_RV770)
+ WREG32(SRBM_SOFT_RESET, RV770_SOFT_RESET_DMA);
+ else
+ WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA);
+ RREG32(SRBM_SOFT_RESET);
+ udelay(50);
+ WREG32(SRBM_SOFT_RESET, 0);
+
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
+}
+
+static int r600_gpu_soft_reset(struct radeon_device *rdev, u32 reset_mask)
+{
+ struct rv515_mc_save save;
+
+ if (reset_mask == 0)
+ return 0;
+
+ dev_info(rdev->dev, "GPU softreset: 0x%08X\n", reset_mask);
+
+ rv515_mc_stop(rdev, &save);
+ if (r600_mc_wait_for_idle(rdev)) {
+ dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
+ }
+
+ if (reset_mask & (RADEON_RESET_GFX | RADEON_RESET_COMPUTE))
+ r600_gpu_soft_reset_gfx(rdev);
+
+ if (reset_mask & RADEON_RESET_DMA)
+ r600_gpu_soft_reset_dma(rdev);
+
+ /* Wait a little for things to settle down */
+ mdelay(1);
+
rv515_mc_resume(rdev, &save);
return 0;
}
@@ -1415,7 +1444,9 @@ bool r600_dma_is_lockup(struct radeon_device *rde
[PATCH 3/5] drm/radeon: switch to a finer grained reset for evergreen
From: Alex Deucher
No change in functionality as we currently set all the reset
flags.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 80 ---
drivers/gpu/drm/radeon/evergreend.h |1 +
2 files changed, 56 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index f92f6bb..58dbf01 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2306,15 +2306,13 @@ bool evergreen_gpu_is_lockup(struct radeon_device
*rdev, struct radeon_ring *rin
return radeon_ring_test_lockup(rdev, ring);
}
-static int evergreen_gpu_soft_reset(struct radeon_device *rdev)
+static void evergreen_gpu_soft_reset_gfx(struct radeon_device *rdev)
{
- struct evergreen_mc_save save;
- u32 grbm_reset = 0, tmp;
+ u32 grbm_reset = 0;
if (!(RREG32(GRBM_STATUS) & GUI_ACTIVE))
- return 0;
+ return;
- dev_info(rdev->dev, "GPU softreset \n");
dev_info(rdev->dev, " GRBM_STATUS = 0x%08X\n",
RREG32(GRBM_STATUS));
dev_info(rdev->dev, " GRBM_STATUS_SE0 = 0x%08X\n",
@@ -2331,27 +2329,10 @@ static int evergreen_gpu_soft_reset(struct
radeon_device *rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
- dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
- RREG32(DMA_STATUS_REG));
- evergreen_mc_stop(rdev, &save);
- if (evergreen_mc_wait_for_idle(rdev)) {
- dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
- }
/* Disable CP parsing/prefetching */
WREG32(CP_ME_CNTL, CP_ME_HALT | CP_PFP_HALT);
- /* Disable DMA */
- tmp = RREG32(DMA_RB_CNTL);
- tmp &= ~DMA_RB_ENABLE;
- WREG32(DMA_RB_CNTL, tmp);
-
- /* Reset dma */
- WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA);
- RREG32(SRBM_SOFT_RESET);
- udelay(50);
- WREG32(SRBM_SOFT_RESET, 0);
-
/* reset all the gfx blocks */
grbm_reset = (SOFT_RESET_CP |
SOFT_RESET_CB |
@@ -2372,8 +2353,7 @@ static int evergreen_gpu_soft_reset(struct radeon_device
*rdev)
udelay(50);
WREG32(GRBM_SOFT_RESET, 0);
(void)RREG32(GRBM_SOFT_RESET);
- /* Wait a little for things to settle down */
- udelay(50);
+
dev_info(rdev->dev, " GRBM_STATUS = 0x%08X\n",
RREG32(GRBM_STATUS));
dev_info(rdev->dev, " GRBM_STATUS_SE0 = 0x%08X\n",
@@ -2390,15 +2370,65 @@ static int evergreen_gpu_soft_reset(struct
radeon_device *rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+}
+
+static void evergreen_gpu_soft_reset_dma(struct radeon_device *rdev)
+{
+ u32 tmp;
+
+ if (RREG32(DMA_STATUS_REG) & DMA_IDLE)
+ return;
+
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
+
+ /* Disable DMA */
+ tmp = RREG32(DMA_RB_CNTL);
+ tmp &= ~DMA_RB_ENABLE;
+ WREG32(DMA_RB_CNTL, tmp);
+
+ /* Reset dma */
+ WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA);
+ RREG32(SRBM_SOFT_RESET);
+ udelay(50);
+ WREG32(SRBM_SOFT_RESET, 0);
+
dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
RREG32(DMA_STATUS_REG));
+}
+
+static int evergreen_gpu_soft_reset(struct radeon_device *rdev, u32 reset_mask)
+{
+ struct evergreen_mc_save save;
+
+ if (reset_mask == 0)
+ return 0;
+
+ dev_info(rdev->dev, "GPU softreset: 0x%08X\n", reset_mask);
+
+ evergreen_mc_stop(rdev, &save);
+ if (evergreen_mc_wait_for_idle(rdev)) {
+ dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
+ }
+
+ if (reset_mask & (RADEON_RESET_GFX | RADEON_RESET_COMPUTE))
+ evergreen_gpu_soft_reset_gfx(rdev);
+
+ if (reset_mask & RADEON_RESET_DMA)
+ evergreen_gpu_soft_reset_dma(rdev);
+
+ /* Wait a little for things to settle down */
+ udelay(50);
+
evergreen_mc_resume(rdev, &save);
return 0;
}
int evergreen_asic_reset(struct radeon_device *rdev)
{
- return evergreen_gpu_soft_reset(rdev);
+ return evergreen_gpu_soft_reset(rdev, (RADEON_RESET_GFX |
+ RADEON_RESET_COMPUTE |
+ RADEON_RESET_DMA));
}
/* Interrupts */
diff --git a/drivers/gpu/drm/radeon/evergreend.h
b/drivers/gpu/drm/radeon/evergreend.h
index 5786a32..0bfd0e9 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -2037,5 +2037,6 @@
# define DMA_RPTR_WRITEBACK_SWAP_ENABLE
[PATCH 4/5] drm/radeon: switch to a finer grained reset for cayman/TN
From: Alex Deucher
No change in functionality as we currently set all the reset
flags.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/ni.c | 109 +++---
1 files changed, 70 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 8a9a75d..896f1cb 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1306,15 +1306,13 @@ void cayman_dma_fini(struct radeon_device *rdev)
radeon_ring_fini(rdev, &rdev->ring[CAYMAN_RING_TYPE_DMA1_INDEX]);
}
-static int cayman_gpu_soft_reset(struct radeon_device *rdev)
+static void cayman_gpu_soft_reset_gfx(struct radeon_device *rdev)
{
- struct evergreen_mc_save save;
- u32 grbm_reset = 0, tmp;
+ u32 grbm_reset = 0;
if (!(RREG32(GRBM_STATUS) & GUI_ACTIVE))
- return 0;
+ return;
- dev_info(rdev->dev, "GPU softreset \n");
dev_info(rdev->dev, " GRBM_STATUS = 0x%08X\n",
RREG32(GRBM_STATUS));
dev_info(rdev->dev, " GRBM_STATUS_SE0 = 0x%08X\n",
@@ -1331,41 +1329,10 @@ static int cayman_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
- dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
- RREG32(DMA_STATUS_REG));
- dev_info(rdev->dev, " VM_CONTEXT0_PROTECTION_FAULT_ADDR 0x%08X\n",
-RREG32(0x14F8));
- dev_info(rdev->dev, " VM_CONTEXT0_PROTECTION_FAULT_STATUS 0x%08X\n",
-RREG32(0x14D8));
- dev_info(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x%08X\n",
-RREG32(0x14FC));
- dev_info(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x%08X\n",
-RREG32(0x14DC));
-
- evergreen_mc_stop(rdev, &save);
- if (evergreen_mc_wait_for_idle(rdev)) {
- dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
- }
/* Disable CP parsing/prefetching */
WREG32(CP_ME_CNTL, CP_ME_HALT | CP_PFP_HALT);
- /* dma0 */
- tmp = RREG32(DMA_RB_CNTL + DMA0_REGISTER_OFFSET);
- tmp &= ~DMA_RB_ENABLE;
- WREG32(DMA_RB_CNTL + DMA0_REGISTER_OFFSET, tmp);
-
- /* dma1 */
- tmp = RREG32(DMA_RB_CNTL + DMA1_REGISTER_OFFSET);
- tmp &= ~DMA_RB_ENABLE;
- WREG32(DMA_RB_CNTL + DMA1_REGISTER_OFFSET, tmp);
-
- /* Reset dma */
- WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA | SOFT_RESET_DMA1);
- RREG32(SRBM_SOFT_RESET);
- udelay(50);
- WREG32(SRBM_SOFT_RESET, 0);
-
/* reset all the gfx blocks */
grbm_reset = (SOFT_RESET_CP |
SOFT_RESET_CB |
@@ -1387,8 +1354,6 @@ static int cayman_gpu_soft_reset(struct radeon_device
*rdev)
udelay(50);
WREG32(GRBM_SOFT_RESET, 0);
(void)RREG32(GRBM_SOFT_RESET);
- /* Wait a little for things to settle down */
- udelay(50);
dev_info(rdev->dev, " GRBM_STATUS = 0x%08X\n",
RREG32(GRBM_STATUS));
@@ -1406,15 +1371,81 @@ static int cayman_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+
+}
+
+static void cayman_gpu_soft_reset_dma(struct radeon_device *rdev)
+{
+ u32 tmp;
+
+ if (RREG32(DMA_STATUS_REG) & DMA_IDLE)
+ return;
+
dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
RREG32(DMA_STATUS_REG));
+
+ /* dma0 */
+ tmp = RREG32(DMA_RB_CNTL + DMA0_REGISTER_OFFSET);
+ tmp &= ~DMA_RB_ENABLE;
+ WREG32(DMA_RB_CNTL + DMA0_REGISTER_OFFSET, tmp);
+
+ /* dma1 */
+ tmp = RREG32(DMA_RB_CNTL + DMA1_REGISTER_OFFSET);
+ tmp &= ~DMA_RB_ENABLE;
+ WREG32(DMA_RB_CNTL + DMA1_REGISTER_OFFSET, tmp);
+
+ /* Reset dma */
+ WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA | SOFT_RESET_DMA1);
+ RREG32(SRBM_SOFT_RESET);
+ udelay(50);
+ WREG32(SRBM_SOFT_RESET, 0);
+
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
+
+}
+
+static int cayman_gpu_soft_reset(struct radeon_device *rdev, u32 reset_mask)
+{
+ struct evergreen_mc_save save;
+
+ if (reset_mask == 0)
+ return 0;
+
+ dev_info(rdev->dev, "GPU softreset: 0x%08X\n", reset_mask);
+
+ dev_info(rdev->dev, " VM_CONTEXT0_PROTECTION_FAULT_ADDR 0x%08X\n",
+RREG32(0x14F8));
+ dev_info(rdev->dev, " VM_CONTEXT0_PROTECTION_FAULT_STATUS 0x%08X\n",
+RREG32(0x14D8));
+ dev_info(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x%08X\n",
+RREG32(0x14FC));
+ dev_info(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x%08X\n"
[PATCH 5/5] drm/radeon: switch to a finer grained reset for SI
From: Alex Deucher
No change in functionality as we currently set all the reset
flags.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/si.c | 98 ---
1 files changed, 64 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 4bf1733..d4aae43 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2126,15 +2126,13 @@ bool si_gpu_is_lockup(struct radeon_device *rdev,
struct radeon_ring *ring)
return radeon_ring_test_lockup(rdev, ring);
}
-static int si_gpu_soft_reset(struct radeon_device *rdev)
+static void si_gpu_soft_reset_gfx(struct radeon_device *rdev)
{
- struct evergreen_mc_save save;
- u32 grbm_reset = 0, tmp;
+ u32 grbm_reset = 0;
if (!(RREG32(GRBM_STATUS) & GUI_ACTIVE))
- return 0;
+ return;
- dev_info(rdev->dev, "GPU softreset \n");
dev_info(rdev->dev, " GRBM_STATUS=0x%08X\n",
RREG32(GRBM_STATUS));
dev_info(rdev->dev, " GRBM_STATUS2=0x%08X\n",
@@ -2145,36 +2143,10 @@ static int si_gpu_soft_reset(struct radeon_device *rdev)
RREG32(GRBM_STATUS_SE1));
dev_info(rdev->dev, " SRBM_STATUS=0x%08X\n",
RREG32(SRBM_STATUS));
- dev_info(rdev->dev, " DMA_STATUS_REG = 0x%08X\n",
- RREG32(DMA_STATUS_REG));
- dev_info(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x%08X\n",
-RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR));
- dev_info(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x%08X\n",
-RREG32(VM_CONTEXT1_PROTECTION_FAULT_STATUS));
- evergreen_mc_stop(rdev, &save);
- if (radeon_mc_wait_for_idle(rdev)) {
- dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
- }
/* Disable CP parsing/prefetching */
WREG32(CP_ME_CNTL, CP_ME_HALT | CP_PFP_HALT | CP_CE_HALT);
- /* dma0 */
- tmp = RREG32(DMA_RB_CNTL + DMA0_REGISTER_OFFSET);
- tmp &= ~DMA_RB_ENABLE;
- WREG32(DMA_RB_CNTL + DMA0_REGISTER_OFFSET, tmp);
-
- /* dma1 */
- tmp = RREG32(DMA_RB_CNTL + DMA1_REGISTER_OFFSET);
- tmp &= ~DMA_RB_ENABLE;
- WREG32(DMA_RB_CNTL + DMA1_REGISTER_OFFSET, tmp);
-
- /* Reset dma */
- WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA | SOFT_RESET_DMA1);
- RREG32(SRBM_SOFT_RESET);
- udelay(50);
- WREG32(SRBM_SOFT_RESET, 0);
-
/* reset all the gfx blocks */
grbm_reset = (SOFT_RESET_CP |
SOFT_RESET_CB |
@@ -2196,8 +2168,7 @@ static int si_gpu_soft_reset(struct radeon_device *rdev)
udelay(50);
WREG32(GRBM_SOFT_RESET, 0);
(void)RREG32(GRBM_SOFT_RESET);
- /* Wait a little for things to settle down */
- udelay(50);
+
dev_info(rdev->dev, " GRBM_STATUS=0x%08X\n",
RREG32(GRBM_STATUS));
dev_info(rdev->dev, " GRBM_STATUS2=0x%08X\n",
@@ -2208,15 +2179,74 @@ static int si_gpu_soft_reset(struct radeon_device *rdev)
RREG32(GRBM_STATUS_SE1));
dev_info(rdev->dev, " SRBM_STATUS=0x%08X\n",
RREG32(SRBM_STATUS));
+}
+
+static void si_gpu_soft_reset_dma(struct radeon_device *rdev)
+{
+ u32 tmp;
+
+ if (RREG32(DMA_STATUS_REG) & DMA_IDLE)
+ return;
+
+ dev_info(rdev->dev, " DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
+
+ /* dma0 */
+ tmp = RREG32(DMA_RB_CNTL + DMA0_REGISTER_OFFSET);
+ tmp &= ~DMA_RB_ENABLE;
+ WREG32(DMA_RB_CNTL + DMA0_REGISTER_OFFSET, tmp);
+
+ /* dma1 */
+ tmp = RREG32(DMA_RB_CNTL + DMA1_REGISTER_OFFSET);
+ tmp &= ~DMA_RB_ENABLE;
+ WREG32(DMA_RB_CNTL + DMA1_REGISTER_OFFSET, tmp);
+
+ /* Reset dma */
+ WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA | SOFT_RESET_DMA1);
+ RREG32(SRBM_SOFT_RESET);
+ udelay(50);
+ WREG32(SRBM_SOFT_RESET, 0);
+
dev_info(rdev->dev, " DMA_STATUS_REG = 0x%08X\n",
RREG32(DMA_STATUS_REG));
+}
+
+static int si_gpu_soft_reset(struct radeon_device *rdev, u32 reset_mask)
+{
+ struct evergreen_mc_save save;
+
+ if (reset_mask == 0)
+ return 0;
+
+ dev_info(rdev->dev, "GPU softreset: 0x%08X\n");
+ dev_info(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x%08X\n",
+RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR));
+ dev_info(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x%08X\n",
+RREG32(VM_CONTEXT1_PROTECTION_FAULT_STATUS));
+
+ evergreen_mc_stop(rdev, &save);
+ if (radeon_mc_wait_for_idle(rdev)) {
+ dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
+ }
+
+ if (reset_mask & (RADEON_RESET_GFX | RADEON_RESET_COMPUTE))
+ si_gpu_soft_reset_gfx(rdev);
+
+ if (reset_mask & RADEON_RESET_DMA)
+ si_gpu_soft_reset_dma(rdev);
[Bug 57842] r200: Culling is broken when rendering to an FBO
https://bugs.freedesktop.org/show_bug.cgi?id=57842 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Alex Deucher --- pushed: http://cgit.freedesktop.org/mesa/mesa/commit/?id=5bf357db89836d0f4e4b8a4cb559755d4734b81b thanks! -- 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: Resume regression with nouveau 3.8rc1 (bisected)
On Thu, Jan 03, 2013 at 01:58:10PM +0100, Marcin Slusarz wrote: > On Wed, Jan 02, 2013 at 04:19:35PM +0100, Pontus Fuchs wrote: > > Hi, > > > > Starting with 3.8rc1 I get a black screen when resuming after suspend. > > The kernel is alive because I can switch to VT1 and reboot with > > ctrl-alt-delete. > > > > I bisected the problem down to this commit: > > > > 186ecad21: drm/nv50/disp: move remaining interrupt handling into core > > > > Hardware is 8400M GS (10de:0427) in a Dell XPS M1330. > > There's already open bug report for that: > https://bugs.freedesktop.org/show_bug.cgi?id=58729 Yay, a bug fix was just posted there ;). Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon CS parser refactoring
> The following set of patches refactor the CS-parser logic > in an effort to consolidate the code that is repeated across > ASIC-specific files. All patches except #8 are function-neutral, > that is they preserve the existing functionality of the driver. > Patch #8 adds one extra check for WAIT_REG_MEM packet that I > believe should be there. > > I have been running with these patches for about a month on several > machines with Evergreen and NI GPUs without noticing any regressions. > I also ran quick tests on all Radeon GPUs that I had around, which > range from R300 through NI cards. Did you run these with pre-kms userspace etc to make sure it doesn't cause regressions there? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon CS parser refactoring
On Fri, 4 Jan 2013, Dave Airlie wrote: Did you run these with pre-kms userspace etc to make sure it doesn't cause regressions there? No, I didn't, but I can give it a quick whirl. I think I still have one or two machines with 6.14.x DDX that I can put in UMS mode and see what happens. Haven't used UMS for at least 2-3 years. My bet is that it is more likely that I will hit a few unrelated UMS problems that are there even without my patches, but I'll let you know the result when I have it. -- Ilija ___ 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 #11 from Alexandre Demers --- I know there is a CS error, I see a message in the terminal just when the lock happens. This is where I should check in dmesg. This is the only thing I can confirm for now because of bug 58667 which floods my logs. -- 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 Alexandre Demers changed: What|Removed |Added Blocks||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 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 Alexandre Demers changed: What|Removed |Added Depends on||58667 -- 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 #22 from Alexandre Demers ---
(In reply to comment #5)
> 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.
"Is this a regression? Does it happen with older versions of mesa or kernel?"
Yes. Previous kernel 3.7 doesn't show this problem.
--
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 52121] mgag200 driver does not work properly with Xen in new Intel Server Board
https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #14 from Fernando Chaves 2013-01-03 22:13:05 --- I have recorded this video: http://www.youtube.com/watch?v=T0qHBxla5f8 Note the frame rate of the movie after reboot, with xen loaded. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/radeon: add GPU reset flags
On Thu, Jan 3, 2013 at 1:16 PM, wrote: > From: Alex Deucher > > The idea here is to move to a finer grained reset. > In some cases we may not need reset every block, and > in other cases we may not need to re-init the entire > asic. > > Signed-off-by: Alex Deucher for the serie Reviewed-by: Jerome Glisse > --- > drivers/gpu/drm/radeon/radeon.h |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h > index 9b9422c..34e5230 100644 > --- a/drivers/gpu/drm/radeon/radeon.h > +++ b/drivers/gpu/drm/radeon/radeon.h > @@ -132,6 +132,11 @@ extern int radeon_lockup_timeout; > #define RADEON_VA_RESERVED_SIZE(8 << 20) > #define RADEON_IB_VM_MAX_SIZE (64 << 10) > > +/* reset flags */ > +#define RADEON_RESET_GFX (1 << 0) > +#define RADEON_RESET_COMPUTE (1 << 1) > +#define RADEON_RESET_DMA (1 << 2) > + > /* > * Errata workarounds. > */ > -- > 1.7.7.5 > > ___ > 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
[pull] radeon drm-fixes-3.8
From: Alex Deucher Hi Dave, A few fixes for radeon: - fix the crashes related to DMA on r6xx - properly reset DMA on GPU reset - fix monitor probing with some DP bridges - misc small bug fixes The following changes since commit d5757dbe79870d825d0dec30074d48683e1d7e9a: Revert "drm: tegra: protect DC register access with mutex" (2012-12-30 21:58:20 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.8 Alex Deucher (8): drm/radeon: add connector table for Mac G4 Silver drm/radeon/r6xx: fix DMA engine for ttm bo transfers drm/radeon: fix typo in evergreen dma fence drm/radeon: add GPU reset flags drm/radeon: switch to a finer grained reset for r6xx/7xx drm/radeon: switch to a finer grained reset for evergreen drm/radeon: switch to a finer grained reset for cayman/TN drm/radeon: switch to a finer grained reset for SI (v2) Jerome Glisse (4): drm/radeon: add debugfs file for dma rings drm/radeon: improve ring debugfs printing drm/radeon: print dma status reg on lockup (v2) drm/radeon: reset dma engine on gpu reset (v2) Niels Ole Salscheider (1): drm/radeon: Properly handle DDC probe for DP bridges drivers/gpu/drm/radeon/evergreen.c | 86 +- drivers/gpu/drm/radeon/evergreend.h| 14 - drivers/gpu/drm/radeon/ni.c| 106 +--- drivers/gpu/drm/radeon/nid.h |3 +- drivers/gpu/drm/radeon/r600.c | 89 ++- drivers/gpu/drm/radeon/radeon.h|5 ++ drivers/gpu/drm/radeon/radeon_combios.c| 51 + drivers/gpu/drm/radeon/radeon_connectors.c | 10 ++- drivers/gpu/drm/radeon/radeon_display.c| 13 +++- drivers/gpu/drm/radeon/radeon_i2c.c| 10 ++- drivers/gpu/drm/radeon/radeon_mode.h |5 +- drivers/gpu/drm/radeon/radeon_ring.c | 24 +-- drivers/gpu/drm/radeon/si.c| 78 +--- drivers/gpu/drm/radeon/sid.h | 18 + 14 files changed, 413 insertions(+), 99 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH] drm/nouveau: fix init with agpgart-uninorth
On Tue, Jan 1, 2013 at 11:21 AM, Marcin Slusarz wrote: > On Mon, Dec 31, 2012 at 03:34:59AM +0200, Aaro Koskinen wrote: >> Check that the AGP aperture can be mapped. This follows a similar change >> done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if >> the aperture can be mapped by the CPU.). >> >> The patch fixes the following error seen on G5 iMac: >> >> nouveau E[ DRM] failed to create kernel channel, -12 >> >> Reviewed-by: Michel Dänzer >> Signed-off-by: Aaro Koskinen >> --- > > This patch fixes https://bugs.freedesktop.org/show_bug.cgi?id=58806. > For some (weird) reason Nouveau worked on this configuration on 3.6 kernel, > so cc'ing stable@vger seems to be appropriate. Cool I've picked this up and applied it for stable into fixes now. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] radeon and minor nouveau fixes
Hi Linus, Just a radeon pull from Alex, fixes a few regressions since 3.7 and reworks some of the reset handling, and two minor nouveau fixes I found on the list, Ben will be back next week to take care of the couple of larger nouveau patches that I see outstanding. Dave. The following changes since commit d5757dbe79870d825d0dec30074d48683e1d7e9a: Revert "drm: tegra: protect DC register access with mutex" (2012-12-30 21:58:20 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-next for you to fetch changes up to eda85d6ad490923152544fba0473798b6cc0edf6: drm/nouveau: fix init with agpgart-uninorth (2013-01-04 16:04:33 +1000) Aaro Koskinen (1): drm/nouveau: fix init with agpgart-uninorth Alex Deucher (8): drm/radeon: add connector table for Mac G4 Silver drm/radeon/r6xx: fix DMA engine for ttm bo transfers drm/radeon: fix typo in evergreen dma fence drm/radeon: add GPU reset flags drm/radeon: switch to a finer grained reset for r6xx/7xx drm/radeon: switch to a finer grained reset for evergreen drm/radeon: switch to a finer grained reset for cayman/TN drm/radeon: switch to a finer grained reset for SI (v2) Dave Airlie (1): Merge branch 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux into drm-next Guenter Roeck (1): drm: nouveau: Fix build warning seen if HWMON is undefined Jerome Glisse (4): drm/radeon: add debugfs file for dma rings drm/radeon: improve ring debugfs printing drm/radeon: print dma status reg on lockup (v2) drm/radeon: reset dma engine on gpu reset (v2) Niels Ole Salscheider (1): drm/radeon: Properly handle DDC probe for DP bridges drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +- drivers/gpu/drm/nouveau/nouveau_pm.c | 4 +- drivers/gpu/drm/radeon/evergreen.c | 86 +-- drivers/gpu/drm/radeon/evergreend.h| 14 +++- drivers/gpu/drm/radeon/ni.c| 106 + drivers/gpu/drm/radeon/nid.h | 3 +- drivers/gpu/drm/radeon/r600.c | 89 ++-- drivers/gpu/drm/radeon/radeon.h| 5 ++ drivers/gpu/drm/radeon/radeon_combios.c| 51 ++ drivers/gpu/drm/radeon/radeon_connectors.c | 10 +-- drivers/gpu/drm/radeon/radeon_display.c| 13 ++-- drivers/gpu/drm/radeon/radeon_i2c.c| 10 ++- drivers/gpu/drm/radeon/radeon_mode.h | 5 +- drivers/gpu/drm/radeon/radeon_ring.c | 24 +-- drivers/gpu/drm/radeon/si.c| 78 ++--- drivers/gpu/drm/radeon/sid.h | 18 + 16 files changed, 416 insertions(+), 102 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/exynos: let drm handle edid allocations
Hi Rahul,
With this patch, I got a error like below,
# echo 1 > /sys/devices/vidi.5/connection
[ 149.485000] [drm:exynos_drm_connector_get_modes] *ERROR* update
edid property failed(-22)
There is something wrong. Please check it out again.
2013/1/2 Rahul Sharma :
> There's no need to allocate edid twice and do a memcpy when drm helpers
> exist to do just that. This patch cleans that interaction up, and
> doesn't keep the edid hanging around in the connector.
>
> v3:
> - removed MAX_EDID as it is not used anymore.
>
> v2:
> - changed vidi_get_edid callback inside vidi driver.
>
> Signed-off-by: Sean Paul
> Signed-off-by: Rahul Sharma
> Signed-off-by: Seung-Woo Kim
> ---
> This patch is based on branch "exynos-drm-next" at
> http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git
>
> drivers/gpu/drm/exynos/exynos_drm_connector.c | 37
> ++-
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 +--
> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 9 +++
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 4 +--
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 19 +-
> drivers/gpu/drm/exynos/exynos_hdmi.c | 25 --
> 6 files changed, 50 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> index ab37437..221ec72 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> @@ -18,7 +18,6 @@
> #include "exynos_drm_drv.h"
> #include "exynos_drm_encoder.h"
>
> -#define MAX_EDID 256
> #define to_exynos_connector(x) container_of(x, struct exynos_drm_connector,\
> drm_connector)
>
> @@ -96,7 +95,9 @@ static int exynos_drm_connector_get_modes(struct
> drm_connector *connector)
> to_exynos_connector(connector);
> struct exynos_drm_manager *manager = exynos_connector->manager;
> struct exynos_drm_display_ops *display_ops = manager->display_ops;
> - unsigned int count;
> + unsigned int count = 0;
> + struct edid *edid = NULL;
> + int ret;
>
> DRM_DEBUG_KMS("%s\n", __FILE__);
>
> @@ -114,27 +115,25 @@ static int exynos_drm_connector_get_modes(struct
> drm_connector *connector)
> * because lcd panel has only one mode.
> */
> if (display_ops->get_edid) {
> - int ret;
> - void *edid;
> -
> - edid = kzalloc(MAX_EDID, GFP_KERNEL);
> - if (!edid) {
> - DRM_ERROR("failed to allocate edid\n");
> - return 0;
> + edid = display_ops->get_edid(manager->dev, connector);
> + if (IS_ERR_OR_NULL(edid)) {
> + ret = PTR_ERR(edid);
> + edid = NULL;
> + DRM_ERROR("Panel operation get_edid failed %d\n",
> ret);
> + goto out;
> }
>
> - ret = display_ops->get_edid(manager->dev, connector,
> - edid, MAX_EDID);
> - if (ret < 0) {
> - DRM_ERROR("failed to get edid data.\n");
> - kfree(edid);
> - edid = NULL;
> - return 0;
> + ret = drm_mode_connector_update_edid_property(connector,
> edid);
> + if (ret) {
> + DRM_ERROR("update edid property failed(%d)\n", ret);
> + goto out;
> }
>
> - drm_mode_connector_update_edid_property(connector, edid);
> count = drm_add_edid_modes(connector, edid);
> - kfree(edid);
> + if (count < 0) {
> + DRM_ERROR("Add edid modes failed %d\n", count);
> + goto out;
> + }
> } else {
> struct exynos_drm_panel_info *panel;
> struct drm_display_mode *mode =
> drm_mode_create(connector->dev);
> @@ -161,6 +160,8 @@ static int exynos_drm_connector_get_modes(struct
> drm_connector *connector)
> count = 1;
> }
>
> +out:
> + kfree(edid);
> return count;
> }
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index b9e51bc..4606fac 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -148,8 +148,8 @@ struct exynos_drm_overlay {
> struct exynos_drm_display_ops {
> enum exynos_drm_output_type type;
> bool (*is_connected)(struct device *dev);
> - int (*get_edid)(struct device *dev, struct drm_connector *connector,
> - u8 *edid, int len);
> + struct edid *(*get_edid)(struct device *dev,
> + struct drm_connec
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:
> From: Alex Deucher
> Date: Wed, 2 Jan 2013 18:30:21 -0500
> Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers
>
> count must be a multiple of 2.
>
> Cc: Borislav Petkov
> Cc: Markus Trippelsdorf
> Signed-off-by: Alex Deucher
Thanks, will run it on the box in question next week when I have access.
Btw, you could add the note about count needing to be a multiple of 2 as
a comment in the code below, for future reference.
> ---
> drivers/gpu/drm/radeon/r600.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 2aaf147..9f4ce5e 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -2636,8 +2636,8 @@ int r600_copy_dma(struct radeon_device *rdev,
>
> for (i = 0; i < num_loops; i++) {
> cur_size_in_dw = size_in_dw;
> - if (cur_size_in_dw > 0x)
> - cur_size_in_dw = 0x;
> + if (cur_size_in_dw > 0xFFFE)
> + cur_size_in_dw = 0xFFFE;
> size_in_dw -= cur_size_in_dw;
> radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0, 0,
> cur_size_in_dw));
> radeon_ring_write(ring, dst_offset & 0xfffc);
> --
> 1.7.7.5
--
Regards/Gruss,
Boris.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58959] kernel 3.6.4 and r600_dri.so from mesa 8.0.5 are incompatible
https://bugs.freedesktop.org/show_bug.cgi?id=58959 almos changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #2 from almos --- Oh, in that case I guess normal debian users are safe from this problem, because in 6.14.4 it is off by default. Closing as PEBKAC. -- 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/20130103/033addc2/attachment.html>
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On 01/03/2013 01:59 AM, Alex Deucher wrote: > On Wed, Jan 2, 2013 at 6:58 PM, Shuah Khan wrote: >> On Wed, Jan 2, 2013 at 4:37 PM, Alex Deucher >> wrote: >>> On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf >>> wrote: On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: > Please affected people can you test if patch : > http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch > > Fix the issue, you need to make sure you don't have the patch that > disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c > is : > .copy = &r600_copy_dma, > .copy_ring_index = R600_RING_TYPE_DMA_INDEX, It fixes the issue for me. Thanks. >>> >>> The count is actually the count, not count - 1. The real fix seems to >>> be that r6xx requires 2 dw aligned transfers. The attached patch >>> fixes the issue for me. >>> >> >> Catching up with this thread. I reverted the >> >> drm/radeon: use async dma for ttm buffer moves on 6xx-SI >> commit id: 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 >> >> Do I need to apply this patch without reverting >> 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2? > > Correct. Don't revert anything. Just apply this patch. Tested, it is working. I didn't revert anything, just added that latest patch. regards Antti -- http://palosaari.fi/
[PATCHv4 0/8] Support for Tegra 2D hardware
On 01/02/2013 05:25 PM, Terje Bergstr?m wrote:
> On 26.12.2012 11:42, Mark Zhang wrote:
[...]
>
>>
>> if (!de)
>> diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
>> index 07e8813..01ed10d 100644
>> --- a/drivers/gpu/host1x/dev.c
>> +++ b/drivers/gpu/host1x/dev.c
>> @@ -38,6 +38,7 @@
>>
>> struct host1x *host1x;
>>
>> +/* Called by drm unlocked ioctl function. So do we need a lock here? */
>> void host1x_syncpt_incr_byid(u32 id)
>
> No, host1x_syncpt_incr_byid is SMP safe.
Correct. Lock is unnecessary.
>
>> {
>> struct host1x_syncpt *sp = host1x->syncpt + id;
>> @@ -52,6 +53,7 @@ u32 host1x_syncpt_read_byid(u32 id)
>> }
>> EXPORT_SYMBOL(host1x_syncpt_read_byid);
>>
>> +/* Called by drm unlocked ioctl function. So do we need a lock here? */
>> int host1x_syncpt_wait_byid(u32 id, u32 thresh, long timeout, u32 *value)
>
> Same here, SMP safe.
>
>> {
>> struct host1x_syncpt *sp = host1x->syncpt + id;
>> @@ -161,6 +163,8 @@ static int host1x_probe(struct platform_device *dev)
>>
>> err = host1x_alloc_resources(host);
>> if (err) {
>> + /* We don't have chip_ops right now, so here the
>> + error message is somewhat improper */
>> dev_err(&dev->dev, "failed to init chip support\n");
>> goto fail;
>> }
>
> Actually, alloc_resources only allocates intr->syncpt, so I the code to
> host1x_intr_init().
>
>> @@ -175,6 +179,14 @@ static int host1x_probe(struct platform_device *dev)
>> if (!host->syncpt)
>> goto fail;
>>
>> + /* I suggest create a dedicate function for initializing nop sp.
>> + First this "_host1x_syncpt_alloc" looks like an internal/static
>> + function.
>> + Then actually "host1x_syncpt_alloc" & "_host1x_syncpt_alloc" all
>> + serve host1x client(e.g: gr2d) so it's not suitable to use them
>> + for nop sp.
>> + Just create a wrapper function to call _host1x_syncpt_alloc is OK.
>> + This will make the code more readable. */
>> host->nop_sp = _host1x_syncpt_alloc(host, NULL, 0);
>
> _host1x_syncpt_alloc is an internal function, not exported.
> host1x_syncpt_alloc is exported. I think it's even better if I just move
> allocation of nop_sp to happen in host1x_syncpt_init.
>
Agree.
>> if (!host->nop_sp)
>> goto fail;
[...]
>
>> diff --git a/drivers/gpu/host1x/intr.c b/drivers/gpu/host1x/intr.c
>> index efcb9be..e112001 100644
>> --- a/drivers/gpu/host1x/intr.c
>> +++ b/drivers/gpu/host1x/intr.c
>> @@ -329,8 +329,13 @@ void host1x_intr_deinit(struct host1x_intr *intr)
>> void host1x_intr_start(struct host1x_intr *intr, u32 hz)
>> {
>> struct host1x *host1x = intr_to_host1x(intr);
>> +
>> + /* Why we need to lock here? Seems like this function is
>> + called by host1x's probe only. */
>> mutex_lock(&intr->mutex);
>>
>> + /* "init_host_sync" has already been called in function
>> + host1x_intr_init. Remove this line. */
>> host1x->intr_op.init_host_sync(intr);
>> host1x->intr_op.set_host_clocks_per_usec(intr,
>> DIV_ROUND_UP(hz, 100));
>
> In future, we'll call host1x_intr_start() whenever host1x is turned on.
> Thus we need locking.
>
> init_host_sync() should actually be called from host1x_intr_start(), not
> _init().
>
Got it. Thanks for explanation.
>> diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
>> index 07cbca5..9a234ad 100644
>> --- a/drivers/gpu/host1x/syncpt.c
>> +++ b/drivers/gpu/host1x/syncpt.c
>> @@ -309,6 +309,8 @@ struct host1x_syncpt *host1x_syncpt_init(struct
>> host1x *host)
>> struct host1x_syncpt *syncpt, *sp;
>> int i;
>>
>> + /* Consider devm_kzalloc here. Then you can forget the release
>> + stuffs about this "syncpt". */
>> syncpt = sp = kzalloc(sizeof(struct host1x_syncpt) *
>> host->info.nb_pts,
>> GFP_KERNEL);
>> if (!syncpt)
>
> Will do.
>
> Thanks!
>
> Terje
>
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #49 from Anonymous Helper --- (In reply to comment #48) > What do you mean by "make sure you add the PCI IDs to the xorg for both > cards"? The driver should autodetect the cards fine. However for systems > with multiple VGA cards, you may have to manually specify which ones you > want to start X on. Currently my xorg.conf.d directory contains the following config: $ cat /etc/X11/xorg.conf.d/* Section "Device" Identifier "Radeon Graphics" BusID "PCI:1:0:0" EndSection Section "Device" Identifier "Intel Graphics" BusID "PCI:0:2:0" Driver "intel" Option "AccelMethod" "sna" #Option "AccelMethod" "uxa" #Option "AccelMethod" "xaa" EndSection Is the BusID line in the intel device section not needed? What is needed for X to automatically detect multiple GPUs properly and show some video output from the correct card? -- 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/20130103/ec9282af/attachment.html>
[PATCH 1/4] drm/exynos: add display-mode-check operation to exynos_mixer_ops struct
On Wed, Jan 2, 2013 at 10:37 PM, Sean Paul wrote:
> On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma
> wrote:
>> This patch adds the display mode check operation to exynos_mixer_ops
>> in drm-common-hdmi. In Exynos SoCs, mixer IP can put certain restrictions
>> on the proposed display modes. These restriction needs to be considered
>> during mode negotiation, which happens immediately after edid parsing.
>>
>> Both, mixer check-mode and hdmi check-timing callbacks are called one after
>> another and ANDed result is returned back.
>>
>
> This looks good, thanks for making the change.
>
>> Signed-off-by: Rahul Sharma
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 12
>> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 3 +++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> index 55793c4..3a8eea6 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> @@ -125,9 +125,21 @@ static int drm_hdmi_get_edid(struct device *dev,
>> static int drm_hdmi_check_timing(struct device *dev, void *timing)
>> {
>> struct drm_hdmi_context *ctx = to_context(dev);
>> + int ret = 0;
>>
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>
>> + /*
>> + * Both, mixer and hdmi should be able to handle the requested mode.
>> + * If any of the two fails, return mode as BAD.
>> + */
>> +
>> + if (mixer_ops && mixer_ops->check_mode)
>> + ret = mixer_ops->check_mode(ctx->mixer_ctx->ctx, timing);
>> +
>> + if (ret)
>> + return ret;
>> +
>> if (hdmi_ops && hdmi_ops->check_timing)
>> return hdmi_ops->check_timing(ctx->hdmi_ctx->ctx, timing);
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> index 784a7e9..ae4b6ae 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> @@ -58,6 +58,9 @@ struct exynos_mixer_ops {
>> void (*win_mode_set)(void *ctx, struct exynos_drm_overlay *overlay);
>> void (*win_commit)(void *ctx, int zpos);
>> void (*win_disable)(void *ctx, int zpos);
>> +
>> + /* display */
>> + int (*check_mode)(void *ctx, void *mode);
>
> Minor nit: I think check_timing would be better here, it's more consistent.
ok. I will change to check_timing in v2.
regards,
Rahul Sharma.
>
> Sean
>
>> };
>>
>> void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx);
>> --
>> 1.8.0
>>
[Bug 58914] Cannot start Radeon driver: "drmOpenByBusid: drmGetBusid reports " no bus ID
https://bugs.freedesktop.org/show_bug.cgi?id=58914 --- Comment #4 from David Hagood --- I cannot say with rigor that it did work with older kernels, as prior to upgrading to Ubuntu 12.4 I was running the non-Free fglrx drivers (forgive me RMS for I have sinned) Bisecting is hard, because I am using many of the features of the newer kernel now, and backtracking would be difficult. But if you can suggest a version to test I can start. I have seen other people running the Intel drivers reporting this same sort of error (the missing busID in the drmGetBusid call), and they thought it was a race condition (hence putting the driver into the initrd, which the Intel driver folks said fixed their problem). -- 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/20130103/c3df8ff9/attachment.html>
[PATCHv4 0/8] Support for Tegra 2D hardware
On 01/02/2013 05:42 PM, Terje Bergstr?m wrote:
> On 28.12.2012 11:14, Mark Zhang wrote:
>> diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
>> index a936902..c3ded60 100644
>> --- a/drivers/gpu/drm/tegra/gr2d.c
>> +++ b/drivers/gpu/drm/tegra/gr2d.c
>> @@ -131,6 +131,14 @@ static int gr2d_submit(struct tegra_drm_context
>> *context,
>> if (err)
>> goto fail;
>>
>> + /* We define CMA as an temporary solution in host1x driver.
>> + That's also why we have a CMA kernel config in it.
>> + But seems here, in tegradrm, we hardcode the CMA here.
>> + So what do you do when host1x change to IOMMU?
>> + Do we also need to define a CMA config in tegradrm
>> driver,
>> + then after host1x changes to IOMMU, we add another IOMMU
>> + config in tegradrm? Or we should invent another more
>> + generic wrapper layer here? */
>> cmdbuf.mem = handle_cma_to_host1x(drm, file_priv,
>> cmdbuf.mem);
>
> Lucas is working on host1x allocator, so let's defer this comment until
> we have Lucas' code.
>
OK.
>> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
>> index cc8ca2f..0867b72 100644
>> --- a/drivers/gpu/host1x/job.c
>> +++ b/drivers/gpu/host1x/job.c
>> @@ -82,6 +82,26 @@ struct host1x_job *host1x_job_alloc(struct
>> host1x_channel *ch,
>> mem += num_unpins * sizeof(dma_addr_t);
>> job->pin_ids = num_unpins ? mem : NULL;
>>
>> + /* I think this is a somewhat ugly design.
>> + Actually "addr_phys" is consisted by "reloc_addr_phys" and
>> + "gather_addr_phys".
>> + Why don't we just declare "reloc_addr_phys" and
>> "gather_addr_phys"?
>> + In current design, let's say if one nvhost newbie changes the
>> order
>> + of these 2 blocks of code in function "pin_job_mem":
>> +
>> + for (i = 0; i < job->num_relocs; i++) {
>> + struct host1x_reloc *reloc = &job->relocarray[i];
>> + job->pin_ids[count] = reloc->target;
>> + count++;
>> + }
>> +
>> + for (i = 0; i < job->num_gathers; i++) {
>> + struct host1x_job_gather *g = &job->gathers[i];
>> + job->pin_ids[count] = g->mem_id;
>> + count++;
>> + }
>> +
>> + Then likely something weird occurs... */
>
> We do this because this way we can implement batch pinning of memory
> handles. This way we can decrease memory handle management a lot as we
> need to do locking only once per submit.
>
Sorry I didn't get it. Yes, in current design, you can pin all mem
handles in one time but I haven't found anything related with "locking
only once per submit".
My idea is:
- remove "job->addr_phys"
- assign "job->reloc_addr_phys" & "job->gather_addr_phys" separately
- In "pin_job_mem", just call "host1x_memmgr_pin_array_ids" twice to
fill the "reloc_addr_phy" & "gather_addr_phys".
Anything I misunderstood?
> Decreasing memory management overhead is really important, because in
> complex graphics cases, there are might be a hundreds of buffer
> references per submit, and several submits per frame. Any extra overhead
> relates directly to reduced performance.
>
>> job->reloc_addr_phys = job->addr_phys;
>> job->gather_addr_phys = &job->addr_phys[num_relocs];
>>
>> @@ -252,6 +272,10 @@ static int do_relocs(struct host1x_job *job,
>> }
>> }
>>
>> + /* I have question here. Does this mean the address info
>> + which need to be relocated(according to the libdrm codes,
>> + seems this address is "0xDEADBEEF") always staying at the
>> + beginning of a page? */
>> __raw_writel(
>> (job->reloc_addr_phys[i] +
>> reloc->target_offset) >> reloc->shift,
>
> No - the slot can be anywhere. That's why we have cmdbuf_offset in the
> reloc struct.
>
Yes. Sorry I must misread the code before.
>> @@ -565,6 +589,7 @@ int host1x_job_pin(struct host1x_job *job, struct
>> platform_device *pdev)
>> }
>> }
>>
>> + /* if (host1x_firewall && !err) { */
>> if (host1x_firewall) {
>> err = copy_gathers(job, pdev);
>> if (err) {
>
> Will add.
>
>> @@ -573,6 +598,9 @@ int host1x_job_pin(struct host1x_job *job, struct
>> platform_device *pdev)
>> }
>> }
>>
>> +/* Rename this label to "out" or something else.
>> + Because if everything goes right, the codes under this label also
>> + get executed. */
>> fail:
>> wmb();
>
> Will do.
>
>>
>> diff --git a/drivers/gpu/host1x/memmgr.c b/drivers/gpu/host1x/memmgr.c
>> index f3954f7..bb5763d 100644
>> --- a/drivers/gpu/host1x/memmgr.c
>> +++ b/drivers/gpu/host1x/memmgr.
[PATCH 4/8] drm/exynos: fimd: clear channel before enabling iommu
On Thu, Jan 3, 2013 at 2:33 AM, St?phane Marchesin <
stephane.marchesin at gmail.com> wrote:
> On Wed, Dec 26, 2012 at 3:27 AM, Prathyush K
> wrote:
> > From: Akshu Agrawal
> >
> > If any fimd channel was already active, initializing iommu will result
> > in a PAGE FAULT (e.g. u-boot could have turned on the display and
> > not disabled it before the kernel starts). This patch checks if any
> > channel is active before initializing iommu and disables it.
> >
>
> Will that work if another drm exynos platform driver (let's say hdmi)
> starts before fimd and enables the iommu?
>
> St?phane
>
>
How can hdmi enable fimd's iommu?
iommu initialization has two parts in drm.
A common mapping gets created first. This mapping is common to all devices
of drm - fimd, mixer, exynos-drm etc.
Then each device - calls attach_device to turn on its own iommu. so even if
hdmi starts before fimd, hdmi will turn on its own iommu and will not
affect fimd.
Hope that clears your doubt.
Regards,
Prathyush
> > Signed-off-by: Akshu Agrawal
> > Signed-off-by: Prathyush K
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 31
> +--
> > 1 file changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > index f88eaa4..3aeedf5 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > @@ -733,6 +733,28 @@ out:
> > return IRQ_HANDLED;
> > }
> >
> > +static void fimd_clear_channel(struct device *dev)
> > +{
> > + struct fimd_context *ctx = get_fimd_context(dev);
> > + int win, ch_enabled = 0;
> > +
> > + DRM_DEBUG_KMS("%s\n", __FILE__);
> > +
> > + /* Check if any channel is enabled */
> > + for (win = 0; win < WINDOWS_NR; win++) {
> > + u32 val = readl(ctx->regs + SHADOWCON);
> > + if (val & SHADOWCON_CHx_ENABLE(win)) {
> > + val &= ~SHADOWCON_CHx_ENABLE(win);
> > + writel(val, ctx->regs + SHADOWCON);
> > + ch_enabled = 1;
> > + }
> > + }
> > +
> > + /* Wait for vsync, as disable channel takes effect at next vsync
> */
> > + if (ch_enabled)
> > + fimd_wait_for_vblank(dev);
> > +}
> > +
> > static int fimd_subdrv_probe(struct drm_device *drm_dev, struct device
> *dev)
> > {
> > DRM_DEBUG_KMS("%s\n", __FILE__);
> > @@ -755,9 +777,14 @@ static int fimd_subdrv_probe(struct drm_device
> *drm_dev, struct device *dev)
> > drm_dev->vblank_disable_allowed = 1;
> >
> > /* attach this sub driver to iommu mapping if supported. */
> > - if (is_drm_iommu_supported(drm_dev))
> > + if (is_drm_iommu_supported(drm_dev)) {
> > + /*
> > +* If any channel is already active, iommu will throw
> > +* a PAGE FAULT when enabled. So clear any channel if
> enabled.
> > +*/
> > + fimd_clear_channel(dev);
> > drm_iommu_attach_device(drm_dev, dev);
> > -
> > + }
> > return 0;
> > }
> >
> > --
> > 1.8.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> 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/20130103/56505ab7/attachment-0001.html>
[PATCH 2/4] drm/exynos: implement display-mode-check callback in mixer driver
On Wed, Jan 2, 2013 at 10:45 PM, Sean Paul wrote:
> On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma
> wrote:
>> This patch adds the implementation of check_mode callback in the mixer
>> driver. Based on the mixer version, correct set of restrictions will be
>> exposed by the mixer driver. A resolution will be acceptable only if passes
>> the criteria set by mixer and hdmi IPs.
>>
>> Signed-off-by: Rahul Sharma
>> Signed-off-by: Sean Paul
>> ---
>> drivers/gpu/drm/exynos/exynos_mixer.c | 30 ++
>> 1 file changed, 30 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 21db895..093b374 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -810,6 +810,33 @@ static void mixer_win_disable(void *ctx, int win)
>> mixer_ctx->win_data[win].enabled = false;
>> }
>>
>> +int mixer_check_mode(void *ctx, void *mode)
>> +{
>> + struct mixer_context *mixer_ctx = ctx;
>> + struct fb_videomode *check_mode = mode;
>
> Why not just pass fb_videomode in the first place?
I kept the prototype same with check_timing in exynos_hdmi_ops or I
should change in
both the places.
>
>> + unsigned int w, h;
>> +
>> + w = check_mode->xres;
>> + h = check_mode->yres;
>> +
>> + DRM_DEBUG_KMS("%s : xres=%d, yres=%d, refresh=%d, intl=%d\n",
>> + __func__, check_mode->xres, check_mode->yres,
>> + check_mode->refresh, (check_mode->vmode &
>> + FB_VMODE_INTERLACED) ? true : false);
>> +
>> + if (mixer_ctx->mxr_ver == MXR_VER_16_0_33_0) {
>> + if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
>> + (w >= 1024 && w <= 1280 &&
>> + h >= 576 && h <= 720) ||
>> + (w >= 1664 && w <= 1920 &&
>> + h >= 936 && h <= 1080))
>> + return 0;
>
> You could eliminate some of this spaghetti by doing:
>if (mixer_ctx->mxr_ver != MXR_VER_16_0_33_0)
> return 0;
>
I will do that.
I have also added checks for min vertical lines (h >= 936, h >= 576,
..) which was
not present in original patches. Due to this, 1920x540P was getting
selected which
is actually not supported by exy5 mixer.
Above values are calculated by Min Horz lines *9 / 16.
Please verify this part.
regards,
Rahul Sharma.
> Then remove one level of indent from the big if statement.
>
> Sean
>
>> + } else {
>> + return 0;
>> + }
>> +
>> + return -EINVAL;
>> +}
>> static void mixer_wait_for_vblank(void *ctx)
>> {
>> struct mixer_context *mixer_ctx = ctx;
>> @@ -947,6 +974,9 @@ static struct exynos_mixer_ops mixer_ops = {
>> .win_mode_set = mixer_win_mode_set,
>> .win_commit = mixer_win_commit,
>> .win_disable= mixer_win_disable,
>> +
>> + /* display */
>> + .check_mode = mixer_check_mode,
>> };
>>
>> /* for pageflip event */
>> --
>> 1.8.0
>>
[PATCH 3/4] drm/exynos: mixer: set correct mode for range of resolutions
On Wed, Jan 2, 2013 at 10:46 PM, Sean Paul wrote: > On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma > wrote: >> With this patch, mixer driver find the correct resolution mode for >> the range of resolutions, upto 1080 vertical lines. Resolution will >> be categorized to NTSC SD, PAL SD or HD and the correct mode is >> set to the mixer configuration register. >> >> Signed-off-by: Rahul Sharma >> Signed-off-by: Sean Paul >> --- >> drivers/gpu/drm/exynos/exynos_mixer.c | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c >> b/drivers/gpu/drm/exynos/exynos_mixer.c >> index 093b374..8ef0e71 100644 >> --- a/drivers/gpu/drm/exynos/exynos_mixer.c >> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c >> @@ -283,13 +283,13 @@ static void mixer_cfg_scan(struct mixer_context *ctx, >> unsigned int height) >> MXR_CFG_SCAN_PROGRASSIVE); >> >> /* choosing between porper HD and SD mode */ >> - if (height == 480) >> + if (height <= 480) >> val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD; >> - else if (height == 576) >> + else if (height <= 576) >> val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD; >> - else if (height == 720) >> + else if (height <= 720) >> val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD; >> - else if (height == 1080) >> + else if (height <= 1080) >> val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD; >> else >> val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD; > > It doesn't make sense to have these checks separate from the code you > added in the last patch. IMO, you should consolidate those checks in > one function so you only need to update them once in the future. > > Sean > Above function is independent of mixer versions / their limitations. It is to categorize a give resolution to SD/HD/NTSC/PAL and set bits to MXR_CFG register. It is same for exynos4 and exynos5 mixers and most likely, it will be same in future. While check_timing has purely to do with the resolution negotiation. Both serve different purpose. Its is possible to put them in one place, but IMHO, this looks cleaner and logical. regards, Rahul Sharma. >> -- >> 1.8.0 >>
[Bug 57842] r200: Culling is broken when rendering to an FBO
https://bugs.freedesktop.org/show_bug.cgi?id=57842 --- Comment #15 from smoki --- Feel free to send it Stefan. Shame on me :( i don't know how to make proper mesa patch nor how to send 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/20130103/51b63689/attachment.html>
[PATCH v2] drm/exynos: consider buffer allocation without iommu
This patch fixes the issue that when buffer allocation is requested
without iommu, the allocation is failed.
Without iommu, dma_alloc_attrs function allocates some memory region
and returns cpu address so this patch makes the cpu address to be set
to buf->kvaddr correctly.
Changelog v2:
- fix buffer free
. Without iommu, dma_free_attrs function requires kernel space address
as argument. So it changes the argument, buf->pages to buf->kvaddr.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_buf.c | 55 +++
1 files changed, 48 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 13a8489..b7937a6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -15,6 +15,7 @@
#include "exynos_drm_drv.h"
#include "exynos_drm_gem.h"
#include "exynos_drm_buf.h"
+#include "exynos_drm_iommu.h"
static int lowlevel_buffer_allocate(struct drm_device *dev,
unsigned int flags, struct exynos_drm_gem_buf *buf)
@@ -52,14 +53,45 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
dma_set_attr(attr, &buf->dma_attrs);
dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &buf->dma_attrs);
- buf->pages = dma_alloc_attrs(dev->dev, buf->size,
- &buf->dma_addr, GFP_KERNEL, &buf->dma_attrs);
- if (!buf->pages) {
- DRM_ERROR("failed to allocate buffer.\n");
- return -ENOMEM;
+ nr_pages = buf->size >> PAGE_SHIFT;
+
+ if (!is_drm_iommu_supported(dev)) {
+ dma_addr_t start_addr;
+ unsigned int i = 0;
+
+ buf->pages = kzalloc(sizeof(struct page) * nr_pages,
+ GFP_KERNEL);
+ if (!buf->pages) {
+ DRM_ERROR("failed to allocate pages.\n");
+ return -ENOMEM;
+ }
+
+ buf->kvaddr = dma_alloc_attrs(dev->dev, buf->size,
+ &buf->dma_addr, GFP_KERNEL,
+ &buf->dma_attrs);
+ if (!buf->kvaddr) {
+ DRM_ERROR("failed to allocate buffer.\n");
+ kfree(buf->pages);
+ return -ENOMEM;
+ }
+
+ start_addr = buf->dma_addr;
+ while (i < nr_pages) {
+ buf->pages[i] = phys_to_page(start_addr);
+ start_addr += PAGE_SIZE;
+ i++;
+ }
+ } else {
+
+ buf->pages = dma_alloc_attrs(dev->dev, buf->size,
+ &buf->dma_addr, GFP_KERNEL,
+ &buf->dma_attrs);
+ if (!buf->pages) {
+ DRM_ERROR("failed to allocate buffer.\n");
+ return -ENOMEM;
+ }
}
- nr_pages = buf->size >> PAGE_SHIFT;
buf->sgt = drm_prime_pages_to_sg(buf->pages, nr_pages);
if (!buf->sgt) {
DRM_ERROR("failed to get sg table.\n");
@@ -78,6 +110,9 @@ err_free_attrs:
(dma_addr_t)buf->dma_addr, &buf->dma_attrs);
buf->dma_addr = (dma_addr_t)NULL;
+ if (!is_drm_iommu_supported(dev))
+ kfree(buf->pages);
+
return ret;
}
@@ -100,8 +135,14 @@ static void lowlevel_buffer_deallocate(struct drm_device
*dev,
kfree(buf->sgt);
buf->sgt = NULL;
- dma_free_attrs(dev->dev, buf->size, buf->pages,
+ if (!is_drm_iommu_supported(dev)) {
+ dma_free_attrs(dev->dev, buf->size, buf->kvaddr,
(dma_addr_t)buf->dma_addr, &buf->dma_attrs);
+ kfree(buf->pages);
+ } else
+ dma_free_attrs(dev->dev, buf->size, buf->pages,
+ (dma_addr_t)buf->dma_addr, &buf->dma_attrs);
+
buf->dma_addr = (dma_addr_t)NULL;
}
--
1.7.4.1
[PATCHv4 0/8] Support for Tegra 2D hardware
On 03.01.2013 05:31, Mark Zhang wrote: > Sorry I didn't get it. Yes, in current design, you can pin all mem > handles in one time but I haven't found anything related with "locking > only once per submit". > > My idea is: > - remove "job->addr_phys" > - assign "job->reloc_addr_phys" & "job->gather_addr_phys" separately > - In "pin_job_mem", just call "host1x_memmgr_pin_array_ids" twice to > fill the "reloc_addr_phy" & "gather_addr_phys". > > Anything I misunderstood? The current design uses CMA, which makes pinning basically a no-op. When we have IOMMU support, pinning requires calling into IOMMU. Updating SMMU tables requires locking, and probably maintenance before SMMU code also requires its own locked data tables. For example, preventing duplicate pinning might require a global table of handles. Putting all of the handles in one table allows doing duplicate detection across cmdbuf and reloc tables. This allows pinning each buffer exactly once, which reduces number of calls to IOMMU. > "host1x_cma_pin_array_ids" doesn't return negative value right now, so > maybe you need to take a look at it. True, and also a consequence of using CMA: pinning can never fail. With IOMMU, pinning can fail. Terje
[PATCHv4 0/8] Support for Tegra 2D hardware
On 01/03/2013 01:50 PM, Terje Bergstr?m wrote: > On 03.01.2013 05:31, Mark Zhang wrote: >> Sorry I didn't get it. Yes, in current design, you can pin all mem >> handles in one time but I haven't found anything related with "locking >> only once per submit". >> >> My idea is: >> - remove "job->addr_phys" >> - assign "job->reloc_addr_phys" & "job->gather_addr_phys" separately >> - In "pin_job_mem", just call "host1x_memmgr_pin_array_ids" twice to >> fill the "reloc_addr_phy" & "gather_addr_phys". >> >> Anything I misunderstood? > > The current design uses CMA, which makes pinning basically a no-op. When > we have IOMMU support, pinning requires calling into IOMMU. Updating > SMMU tables requires locking, and probably maintenance before SMMU code > also requires its own locked data tables. For example, preventing > duplicate pinning might require a global table of handles. > > Putting all of the handles in one table allows doing duplicate detection > across cmdbuf and reloc tables. This allows pinning each buffer exactly > once, which reduces number of calls to IOMMU. > Thanks Terje. Yes, I understand IOMMU will bring in more operations. But I'm not convinced that separating 2 arrays have lots of overheads than putting them into one array. But it doesn't matter, after the IOMMU support version released, I can read this part of codes again. Let's talk about this at that time. >> "host1x_cma_pin_array_ids" doesn't return negative value right now, so >> maybe you need to take a look at it. > > True, and also a consequence of using CMA: pinning can never fail. With > IOMMU, pinning can fail. Got it. Agree. > > Terje >
[PATCHv4 0/8] Support for Tegra 2D hardware
On 21.12.2012 15:50, Lucas Stach wrote:
> Am Freitag, den 21.12.2012, 13:39 +0200 schrieb Terje Bergstrom:
>> Some of the issues left open:
>> * Register definitions still use static inline. There has been a
>>debate about code style versus ability to use compiler type
>>checking and code coverage analysis. There was no conclusion, so
>>I left it as was.
> This has to be resolved before merging. Personally I'm in favour of
> keeping reg access patterns close to what is done in other parts of the
> kernel.
How about if I define inline functions, and #defines to proxy to them?
Something like:
static inline u32 host1x_sync_cfpeek_ctrl_r(void)
{
return 0x74c;
}
#define HOST1X_SYNC_CFPEEK_CTRL \
host1x_sync_cfpeek_ctrl_r()
static inline u32 host1x_sync_cfpeek_ctrl_cfpeek_ena_f(u32 v)
{
return (v & 0x1) << 31;
}
#define HOST1X_SYNC_CFPEEK_CTRL_CFPEEK_ENA_F(v) \
host1x_sync_cfpeek_ctrl_cfpeek_ena_f(v)
I'd use the macros in .c files. That way the references will look
familiar to reader of .c files, but we can still get the benefits of
compiler processing (type checking, better error codes etc) and gcov
coverage tracking.
Terje
[PATCH 1/2] [RFC] video: exynos mipi dsi: Making Exynos MIPI Complaint with CDF
Hi Vikas,
Some nitpicks inline
Subject: s/Complaint/Compliant
On 2 January 2013 18:47, Vikas C Sajjan wrote:
> From: Vikas Sajjan
>
Please add some description about this patch here.
> Signed-off-by: Vikas Sajjan
> ---
> drivers/video/exynos/exynos_mipi_dsi.c| 46
> ++---
> drivers/video/exynos/exynos_mipi_dsi_common.c | 22
> drivers/video/exynos/exynos_mipi_dsi_common.h | 12 +++
> include/video/exynos_mipi_dsim.h |5 ++-
> 4 files changed, 56 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c
> b/drivers/video/exynos/exynos_mipi_dsi.c
> index 07d70a3..88b2aa9 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
> @@ -32,14 +32,13 @@
> #include
> #include
> #include
> -
> +#include
> #include
>
> #include
>
> #include "exynos_mipi_dsi_common.h"
> #include "exynos_mipi_dsi_lowlevel.h"
> -
> struct mipi_dsim_ddi {
> int bus_id;
> struct list_headlist;
> @@ -111,12 +110,13 @@ static void exynos_mipi_update_cfg(struct
> mipi_dsim_device *dsim)
> exynos_mipi_dsi_stand_by(dsim, 1);
> }
>
> -static int exynos_mipi_dsi_early_blank_mode(struct mipi_dsim_device *dsim,
> +static int exynos_mipi_dsi_early_blank_mode(struct video_source
> *video_source,
> int power)
> {
> + struct mipi_dsim_device *dsim = container_of(video_source,
> + struct mipi_dsim_device,
> video_source);
> struct mipi_dsim_lcd_driver *client_drv = dsim->dsim_lcd_drv;
> struct mipi_dsim_lcd_device *client_dev = dsim->dsim_lcd_dev;
> -
> switch (power) {
> case FB_BLANK_POWERDOWN:
> if (dsim->suspended)
> @@ -139,12 +139,13 @@ static int exynos_mipi_dsi_early_blank_mode(struct
> mipi_dsim_device *dsim,
> return 0;
> }
>
> -static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int
> power)
> +static int exynos_mipi_dsi_blank_mode(struct video_source *video_source, int
> power)
> {
> + struct mipi_dsim_device *dsim = container_of(video_source,
> + struct mipi_dsim_device,
> video_source);
> struct platform_device *pdev = to_platform_device(dsim->dev);
> struct mipi_dsim_lcd_driver *client_drv = dsim->dsim_lcd_drv;
> struct mipi_dsim_lcd_device *client_dev = dsim->dsim_lcd_dev;
> -
> switch (power) {
> case FB_BLANK_UNBLANK:
> if (!dsim->suspended)
> @@ -319,12 +320,19 @@ static struct mipi_dsim_ddi
> *exynos_mipi_dsi_bind_lcd_ddi(
> return NULL;
> }
>
> -/* define MIPI-DSI Master operations. */
> -static struct mipi_dsim_master_ops master_ops = {
> - .cmd_read = exynos_mipi_dsi_rd_data,
> - .cmd_write = exynos_mipi_dsi_wr_data,
> - .get_dsim_frame_done=
> exynos_mipi_dsi_get_frame_done_status,
> - .clear_dsim_frame_done = exynos_mipi_dsi_clear_frame_done,
>
+static void panel_dsi_release(struct video_source *src)
How about exynos_dsi_panel_release in line with other function names?
> +{
> + printk("dsi entity release\n");
Please use pr_* function here (instead of printk).
> +}
> +
> +static const struct common_video_source_ops dsi_common_ops = {
Some comments for this place holder would be good.
> +};
> +
> +static const struct dsi_video_source_ops exynos_dsi_ops = {
> + .dcs_read = exynos_mipi_dsi_rd_data,
> + .dcs_write = exynos_mipi_dsi_wr_data,
> + .get_frame_done =
> exynos_mipi_dsi_get_frame_done_status,
> + .clear_frame_done = exynos_mipi_dsi_clear_frame_done,
> .set_early_blank_mode = exynos_mipi_dsi_early_blank_mode,
> .set_blank_mode = exynos_mipi_dsi_blank_mode,
> };
> @@ -362,7 +370,6 @@ static int exynos_mipi_dsi_probe(struct platform_device
> *pdev)
> }
>
> dsim->dsim_config = dsim_config;
> - dsim->master_ops = &master_ops;
>
> mutex_init(&dsim->lock);
>
> @@ -463,6 +470,19 @@ static int exynos_mipi_dsi_probe(struct platform_device
> *pdev)
>
> dsim->suspended = false;
>
> + dsim->video_source.dev = &pdev->dev;
> + dsim->video_source.release = panel_dsi_release;
> + dsim->video_source.common_ops = &dsi_common_ops;
> + dsim->video_source.ops.dsi = &exynos_dsi_ops;
> + dsim->video_source.name = "exynos";
Can't we get this from pdev?
> +
> + ret = video_source_register(&dsim->video_source);
> + if (ret < 0) {
> + printk("dsi entity register failed\n");
Please use pr_* function here (instead of printk).
> + goto err_bind;
> + }
> + printk("dsi entity registered: %p\n", &dsim->video_sour
[PATCH 1/2] [RFC] video: exynos mipi dsi: Making Exynos MIPI Complaint with CDF
Hi Sachin,
Thanks for the comments.
On Thu, Jan 3, 2013 at 11:14 AM, Sachin Kamat
wrote:
> Hi Vikas,
>
> Some nitpicks inline
>
> Subject: s/Complaint/Compliant
>
Oops, nice catch.
> On 2 January 2013 18:47, Vikas C Sajjan wrote:
>> From: Vikas Sajjan
>>
>
> Please add some description about this patch here.
>
sure.
>> Signed-off-by: Vikas Sajjan
>> ---
>> drivers/video/exynos/exynos_mipi_dsi.c| 46
>> ++---
>> drivers/video/exynos/exynos_mipi_dsi_common.c | 22
>> drivers/video/exynos/exynos_mipi_dsi_common.h | 12 +++
>> include/video/exynos_mipi_dsim.h |5 ++-
>> 4 files changed, 56 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c
>> b/drivers/video/exynos/exynos_mipi_dsi.c
>> index 07d70a3..88b2aa9 100644
>> --- a/drivers/video/exynos/exynos_mipi_dsi.c
>> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
>> @@ -32,14 +32,13 @@
>> #include
>> #include
>> #include
>> -
>> +#include
>> #include
>>
>> #include
>>
>> #include "exynos_mipi_dsi_common.h"
>> #include "exynos_mipi_dsi_lowlevel.h"
>> -
>> struct mipi_dsim_ddi {
>> int bus_id;
>> struct list_headlist;
>> @@ -111,12 +110,13 @@ static void exynos_mipi_update_cfg(struct
>> mipi_dsim_device *dsim)
>> exynos_mipi_dsi_stand_by(dsim, 1);
>> }
>>
>> -static int exynos_mipi_dsi_early_blank_mode(struct mipi_dsim_device *dsim,
>> +static int exynos_mipi_dsi_early_blank_mode(struct video_source
>> *video_source,
>> int power)
>> {
>> + struct mipi_dsim_device *dsim = container_of(video_source,
>> + struct mipi_dsim_device,
>> video_source);
>> struct mipi_dsim_lcd_driver *client_drv = dsim->dsim_lcd_drv;
>> struct mipi_dsim_lcd_device *client_dev = dsim->dsim_lcd_dev;
>> -
>> switch (power) {
>> case FB_BLANK_POWERDOWN:
>> if (dsim->suspended)
>> @@ -139,12 +139,13 @@ static int exynos_mipi_dsi_early_blank_mode(struct
>> mipi_dsim_device *dsim,
>> return 0;
>> }
>>
>> -static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int
>> power)
>> +static int exynos_mipi_dsi_blank_mode(struct video_source *video_source,
>> int power)
>> {
>> + struct mipi_dsim_device *dsim = container_of(video_source,
>> + struct mipi_dsim_device,
>> video_source);
>> struct platform_device *pdev = to_platform_device(dsim->dev);
>> struct mipi_dsim_lcd_driver *client_drv = dsim->dsim_lcd_drv;
>> struct mipi_dsim_lcd_device *client_dev = dsim->dsim_lcd_dev;
>> -
>> switch (power) {
>> case FB_BLANK_UNBLANK:
>> if (!dsim->suspended)
>> @@ -319,12 +320,19 @@ static struct mipi_dsim_ddi
>> *exynos_mipi_dsi_bind_lcd_ddi(
>> return NULL;
>> }
>>
>> -/* define MIPI-DSI Master operations. */
>> -static struct mipi_dsim_master_ops master_ops = {
>> - .cmd_read = exynos_mipi_dsi_rd_data,
>> - .cmd_write = exynos_mipi_dsi_wr_data,
>> - .get_dsim_frame_done=
>> exynos_mipi_dsi_get_frame_done_status,
>> - .clear_dsim_frame_done = exynos_mipi_dsi_clear_frame_done,
>>
>
> +static void panel_dsi_release(struct video_source *src)
>
> How about exynos_dsi_panel_release in line with other function names?
>
will modify.
>> +{
>> + printk("dsi entity release\n");
>
> Please use pr_* function here (instead of printk).
>
Sure.
>> +}
>> +
>> +static const struct common_video_source_ops dsi_common_ops = {
>
> Some comments for this place holder would be good.
>
>> +};
>> +
>> +static const struct dsi_video_source_ops exynos_dsi_ops = {
>> + .dcs_read = exynos_mipi_dsi_rd_data,
>> + .dcs_write = exynos_mipi_dsi_wr_data,
>> + .get_frame_done =
>> exynos_mipi_dsi_get_frame_done_status,
>> + .clear_frame_done = exynos_mipi_dsi_clear_frame_done,
>> .set_early_blank_mode = exynos_mipi_dsi_early_blank_mode,
>> .set_blank_mode = exynos_mipi_dsi_blank_mode,
>> };
>> @@ -362,7 +370,6 @@ static int exynos_mipi_dsi_probe(struct platform_device
>> *pdev)
>> }
>>
>> dsim->dsim_config = dsim_config;
>> - dsim->master_ops = &master_ops;
>>
>> mutex_init(&dsim->lock);
>>
>> @@ -463,6 +470,19 @@ static int exynos_mipi_dsi_probe(struct platform_device
>> *pdev)
>>
>> dsim->suspended = false;
>>
>> + dsim->video_source.dev = &pdev->dev;
>> + dsim->video_source.release = panel_dsi_release;
>> + dsim->video_source.common_ops = &dsi_common_ops;
>> + dsim->video_source.ops.dsi = &exynos_dsi_ops;
>> + dsim->video_source.name = "exynos";
>
> Can't we get this from pdev?
>
right, will change a
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On 2013.01.02 at 18:37 -0500, Alex Deucher wrote: > On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf > wrote: > > On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: > >> Please affected people can you test if patch : > >> http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch > >> > >> Fix the issue, you need to make sure you don't have the patch that > >> disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c > >> is : > >> .copy = &r600_copy_dma, > >> .copy_ring_index = R600_RING_TYPE_DMA_INDEX, > > > > It fixes the issue for me. Thanks. > > The count is actually the count, not count - 1. The real fix seems to > be that r6xx requires 2 dw aligned transfers. The attached patch > fixes the issue for me. Yes, this one also works for me. Thanks. -- Markus
[Bug 58914] Cannot start Radeon driver: "drmOpenByBusid: drmGetBusid reports " no bus ID
https://bugs.freedesktop.org/show_bug.cgi?id=58914 --- Comment #5 from Michel D?nzer --- (In reply to comment #4) > But if you can suggest a version to test I can start. I haven't seen any other similar reports, so if it happens with 3.7 kernels, it's probably not a (recent) kernel regression. > I have seen other people running the Intel drivers reporting this same sort > of error (the missing busID in the drmGetBusid call), and they thought it > was a race condition That seems unlikely in your case, given the timestamps in the log snippets you've provided. -- 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/20130103/cd65444f/attachment.html>
[PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct
Hi Vikas,
On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote:
> From: Vikas Sajjan
>
> Signed-off-by: Vikas Sajjan
> ---
> include/video/display.h |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/video/display.h b/include/video/display.h
> index b639fd0..fb2f437 100644
> --- a/include/video/display.h
> +++ b/include/video/display.h
> @@ -117,6 +117,12 @@ struct dsi_video_source_ops {
>
> void (*enable_hs)(struct video_source *src, bool enable);
>
> + /* frame related */
> + int (*get_frame_done)(struct video_source *src);
> + int (*clear_frame_done)(struct video_source *src);
> + int (*set_early_blank_mode)(struct video_source *src, int power);
> + int (*set_blank_mode)(struct video_source *src, int power);
> +
I'm not sure if all those extra ops are needed in any way.
Looking and Exynos MIPI DSIM driver, set_blank_mode is handling only
FB_BLANK_UNBLANK status, which basically equals to the already existing
enable operation, while set_early_blank mode handles only
FB_BLANK_POWERDOWN, being equal to disable callback.
Both get_frame_done and clear_frame_done do not look at anything used at
the moment and if frame done status monitoring will be ever needed, I
think a better way should be implemented.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
[Bug 58272] Rv670 AGP drm-next ttm errors
https://bugs.freedesktop.org/show_bug.cgi?id=58272 --- Comment #14 from Andy Furniss --- (In reply to comment #13) > (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? FWIW I tried current drm-next + patch - 0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch And I still fail with etqw after about 10 secs, but do get more info. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: Failed to allocate a buffer: radeon:size : 7168 bytes radeon:alignment : 256 bytes radeon:domains : 2 EE r600_texture.c:697 r600_texture_transfer_map - failed to create temporary texture to hold untiled copy Mesa: User error: GL_OUT_OF_MEMORY in glTexSubImage radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. double fault: 'Segmentation fault', bailing out shutdown terminal support /home/andy/bin/etqw: line 1: 2472 Segmentation fault /usr/local/games/etqw/etqw dmesg - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (8192, 2, 4096, -12) [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! etqw.x86[2472]: segfault at 0 ip af5292ad sp bfbe3250 error 4 in gamex86.so[af254000+948000] -- 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/20130103/c263157e/attachment.html>
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
2013-01-03 00:37 keltez?ssel, Alex Deucher ?rta: > On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf > wrote: >> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: >>> Please affected people can you test if patch : >>> http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch >>> >>> Fix the issue, you need to make sure you don't have the patch that >>> disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c >>> is : >>> .copy = &r600_copy_dma, >>> .copy_ring_index = R600_RING_TYPE_DMA_INDEX, >> It fixes the issue for me. Thanks. > The count is actually the count, not count - 1. The real fix seems to > be that r6xx requires 2 dw aligned transfers. The attached patch > fixes the issue for me. > > Alex I tried this patch over kernel 3.8.0-rc2 but the GDM screen is mostly garbage. Only some text, like "Not on the list?" below the users and small icons are visible but many user names are not rendered. http://tinypic.com/r/33xihit/6 I am on Fedora 18/x86_64, Radeon HD6570. Best regards, Zolt?n B?sz?rm?nyi
[Bug 36522] Caught 16-bit read from uninitialized memory in drm_fb_helper_setcmap
https://bugzilla.kernel.org/show_bug.cgi?id=36522 --- Comment #11 from Christian Casteyde 2013-01-03 12:55:07 --- Udpate: Still present in 3.8-rc2 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH 8/8] drm/exynos: fimd: add complete_scanout function
crtc off. This will
wait for vsync.
complete_scanout will just return. remove fb1. no issue.
2> mixer reading from fb1
fb2 set to mixer (layer update)
remove fb1
In this case, base has fb2, shadow has fb1.
crtc->fb == fb2, so no win_disable.
complete scanout will wait for vsync and ensure dma is from fb2. remove
fb1. no issue.
3> mixer reading from fb1. shadow reg has fb1
fb2 set to mixer (layer update - base reg has fb2)
fb3 set to mixer (since layer update is pending, win_commit returns)
remove fb2
crtc->fb == fb3, so no win_disable
complete scanout: base == fb2 so win_disable and then wait for vsync.
remove fb1. no issue
Hope this answers your question. If there is any additional scenario which
I missed, do let me know :)
With the above approach, there is no crash in either fimd or hdmi after
quite a few attempts at multiple scenarios.
I am working on a patch set v2 which I'll post tomorrow with a couple of
additional fixes.
Regards,
Prathyush
> Sean
>
>
>
> > + }
> > +
> > + if (in_use)
> > + fimd_wait_for_vblank(dev);
> > + return;
> > +}
> > +
> > static struct exynos_drm_manager_ops fimd_manager_ops = {
> > .dpms = fimd_dpms,
> > .apply = fimd_apply,
> > .commit = fimd_commit,
> > .enable_vblank = fimd_enable_vblank,
> > .disable_vblank = fimd_disable_vblank,
> > - .wait_for_vblank = fimd_wait_for_vblank,
> > + .complete_scanout = fimd_complete_scanout,
> > };
> >
> > static void fimd_win_mode_set(struct device *dev,
> > diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> > index 7ae6c07..382eaec 100644
> > --- a/include/video/samsung_fimd.h
> > +++ b/include/video/samsung_fimd.h
> > @@ -274,6 +274,7 @@
> >
> > /* Video buffer addresses */
> > #define VIDW_BUF_START(_buff) (0xA0 + ((_buff) * 8))
> > +#define VIDW_BUF_START_S(_buff)(0x40A0 +
> ((_buff) * 8))
> > #define VIDW_BUF_START1(_buff) (0xA4 + ((_buff) * 8))
> > #define VIDW_BUF_END(_buff)(0xD0 + ((_buff) * 8))
> > #define VIDW_BUF_END1(_buff) (0xD4 + ((_buff) * 8))
> > --
> > 1.8.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> 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/20130103/8bd0cb88/attachment-0001.html>
[PATCH 7/8] drm/exynos: hdmi: add complete_scanout function
turn;
> > +
> > + for (win = 0; win < MIXER_WIN_NR; win++) {
> > + dma_addr_t dma_addr_in_use;
> > +
> > + if (!mixer_ctx->win_data[win].enabled)
> > + continue;
> > +
> > + dma_addr_in_use = mixer_reg_read(res,
> MXR_GRAPHIC_BASE(win));
> > + if (dma_addr_in_use >= dma_addr &&
> > + dma_addr_in_use < (dma_addr + size)) {
> > + mixer_win_disable(ctx, win);
> > + in_use = true;
> > + }
> > +
> > + dma_addr_in_use = mixer_reg_read(res,
> MXR_GRAPHIC_BASE_S(win));
> > + if (dma_addr_in_use >= dma_addr &&
> > + dma_addr_in_use < (dma_addr + size))
> > + in_use_s = true;
>
> You don't use this anywhere in the code. I think bad things will
> happen if the framebuffer is in a shadow register and we free it.
>
> I don't get your point here. What is not used anywhere in the code?
Please check the comments on the fimd patch.
> I also wonder if you should wrap this all with mixer_vsync_set_update
> so things don't change while you're doing this.
>
> Haven't thought of that. Will definitely consider that for next patch set.
Thanks for reviewing,
Regards,
Prathyush
> Sean
>
>
> > + }
> > +
> > + if (in_use)
> > + mixer_wait_for_vblank(ctx);
> > +}
> > +
> > static void mixer_window_suspend(struct mixer_context *ctx)
> > {
> > struct hdmi_win_data *win_data;
> > @@ -969,7 +1004,7 @@ static struct exynos_mixer_ops mixer_ops = {
> > .iommu_on = mixer_iommu_on,
> > .enable_vblank = mixer_enable_vblank,
> > .disable_vblank = mixer_disable_vblank,
> > - .wait_for_vblank= mixer_wait_for_vblank,
> > + .complete_scanout = mixer_complete_scanout,
> > .dpms = mixer_dpms,
> >
> > /* overlay */
> > --
> > 1.8.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> 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/20130103/29ea8dd8/attachment.html>
Resume regression with nouveau 3.8rc1 (bisected)
On Wed, Jan 02, 2013 at 04:19:35PM +0100, Pontus Fuchs wrote: > Hi, > > Starting with 3.8rc1 I get a black screen when resuming after suspend. > The kernel is alive because I can switch to VT1 and reboot with > ctrl-alt-delete. > > I bisected the problem down to this commit: > > 186ecad21: drm/nv50/disp: move remaining interrupt handling into core > > Hardware is 8400M GS (10de:0427) in a Dell XPS M1330. There's already open bug report for that: https://bugs.freedesktop.org/show_bug.cgi?id=58729 And my nv92 does not resume too, with similar symptoms, since nouveau display rework hit the tree. Marcin
[Bug 52231] New: possible circular locking dependency detected in radeon driver
https://bugzilla.kernel.org/show_bug.cgi?id=52231
Summary: possible circular locking dependency detected in
radeon driver
Product: Drivers
Version: 2.5
Kernel Version: 3.8-rc2
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: casteyde.christian at free.fr
Regression: Yes
Kernel 3.8-rc2
Slackware64 14
Core i7, 6 GB RAM, 64 bit mode
Since kernel 3.8-rc2 with kmemcheck and lockdep hacking options turned on, I
get the following lockdep warning:
EXT4-fs (sda3): re-mounted. Opts: discard,commit=0
==
[ INFO: possible circular locking dependency detected ]
3.8.0-rc2 #21 Not tainted
---
99video/2835 is trying to acquire lock:
((fb_notifier_list).rwsem){.+.+.+}, at: []
__blocking_notifier_call_chain+0x54/0xd0
but task is already holding lock:
(console_lock){+.+.+.}, at: [] store_fbstate+0x55/0x80
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (console_lock){+.+.+.}:
[] lock_acquire+0x5a/0x70
[] console_lock+0x57/0x60
[] register_con_driver+0x34/0x140
[] take_over_console+0x29/0x60
[] fbcon_takeover+0x5b/0xb0
[] fbcon_event_notify+0x72d/0x830
[] notifier_call_chain+0x5e/0x150
[] __blocking_notifier_call_chain+0x6d/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] register_framebuffer+0x1bd/0x2f0
[] drm_fb_helper_single_fb_probe+0x1d3/0x2f0
[] drm_fb_helper_initial_config+0x1d1/0x240
[] radeon_fbdev_init+0xba/0x110
[] radeon_modeset_init+0x501/0xb60
[] radeon_driver_load_kms+0xe0/0x150
[] drm_get_pci_dev+0x17e/0x2b0
[] radeon_pci_probe+0xaa/0xe0
[] local_pci_probe+0x46/0x80
[] pci_device_probe+0x101/0x110
[] driver_probe_device+0x76/0x220
[] __driver_attach+0xa3/0xb0
[] bus_for_each_dev+0x4d/0x90
[] driver_attach+0x19/0x20
[] bus_add_driver+0x1a0/0x270
[] driver_register+0x72/0x170
[] __pci_register_driver+0x5f/0x70
[] drm_pci_init+0x115/0x130
[] radeon_init+0xe7/0xe9
[] do_one_initcall+0x11a/0x170
[] kernel_init+0x11c/0x290
[] ret_from_fork+0x7c/0xb0
-> #0 ((fb_notifier_list).rwsem){.+.+.+}:
[] __lock_acquire+0x1a20/0x1ca0
[] lock_acquire+0x5a/0x70
[] down_read+0x39/0x8c
[] __blocking_notifier_call_chain+0x54/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] fb_set_suspend+0x46/0x60
[] store_fbstate+0x60/0x80
[] dev_attr_store+0x13/0x20
[] sysfs_write_file+0xdb/0x150
[] vfs_write+0xa6/0x160
[] sys_write+0x50/0xa0
[] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(console_lock);
lock((fb_notifier_list).rwsem);
lock(console_lock);
lock((fb_notifier_list).rwsem);
*** DEADLOCK ***
4 locks held by 99video/2835:
#0: (&buffer->mutex){+.+.+.}, at: []
sysfs_write_file+0x43/0x150
#1: (s_active#124){.+.+.+}, at: []
sysfs_write_file+0xc3/0x150
#2: (&fb_info->lock){+.+.+.}, at: [] lock_fb_info+0x21/0x60
#3: (console_lock){+.+.+.}, at: [] store_fbstate+0x55/0x80
stack backtrace:
Pid: 2835, comm: 99video Not tainted 3.8.0-rc2 #21
Call Trace:
[] print_circular_bug+0x28e/0x29f
[] __lock_acquire+0x1a20/0x1ca0
[] lock_acquire+0x5a/0x70
[] ? __blocking_notifier_call_chain+0x54/0xd0
[] ? __lock_is_held+0x5f/0x90
[] down_read+0x39/0x8c
[] ? __blocking_notifier_call_chain+0x54/0xd0
[] __blocking_notifier_call_chain+0x54/0xd0
[] __blocking_notifier_call_chain+0x54/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] fb_set_suspend+0x46/0x60
[] ? console_lock+0x57/0x60
[] ? store_fbstate+0x55/0x80
[] store_fbstate+0x60/0x80
[] dev_attr_store+0x13/0x20
[] sysfs_write_file+0xdb/0x150
[] vfs_write+0xa6/0x160
[] sys_write+0x50/0xa0
[] system_call_fastpath+0x16/0x1b
PM: Syncing filesystems ... done.
WARNING: kmemcheck: Caught 16-bit read from uninitialized memory
(8801c52bbc20)
01000100b0bb2bc50188
u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u
^
Pid: 2256, comm: X Not tainted 3.8.0-rc2 #21 Acer Aspire 7750G/JE70_HR
RIP: 0010:[] []
drm_fb_helper_setcmap+0x111/0x400
RSP: 0018:8801c0c35978 EFLAGS: 00010206
RAX: 8801c52bbc00 RBX: 8801c476e800 RCX:
RD
[Bug 52231] possible circular locking dependency detected in radeon driver
https://bugzilla.kernel.org/show_bug.cgi?id=52231 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|Video(DRI - non Intel) |Console/Framebuffers AssignedTo|drivers_video-dri at kernel-bu |jsimmons at infradead.org |gs.osdl.org | --- Comment #1 from Alan 2013-01-03 13:08:55 --- Fix was posted 7th December, no idea why it still doesn't seem to have been applied. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH 01/12] drm/radeon: remove unecessary assignment
For the series:
Reviewed-by: Marek Ol??k
Marek
On Thu, Jan 3, 2013 at 12:27 AM, Ilija Hadzic
wrote:
> length_dw field was assigned twice. While at it, move user_ptr
> assignment together with all other assignments to p->chunks[i]
> structure to make the code more readable.
>
> Signed-off-by: Ilija Hadzic
> ---
> drivers/gpu/drm/radeon/radeon_cs.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index 396baba0..4be64e0 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -203,7 +203,7 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
> void *data)
> p->chunks[i].length_dw = user_chunk.length_dw;
> p->chunks[i].kdata = NULL;
> p->chunks[i].chunk_id = user_chunk.chunk_id;
> -
> + p->chunks[i].user_ptr = (void __user *)(unsigned
> long)user_chunk.chunk_data;
> if (p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) {
> p->chunk_relocs_idx = i;
> }
> @@ -226,9 +226,6 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
> void *data)
> return -EINVAL;
> }
>
> - p->chunks[i].length_dw = user_chunk.length_dw;
> - p->chunks[i].user_ptr = (void __user *)(unsigned
> long)user_chunk.chunk_data;
> -
> cdata = (uint32_t *)(unsigned long)user_chunk.chunk_data;
> if ((p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) ||
> (p->chunks[i].chunk_id == RADEON_CHUNK_ID_FLAGS)) {
> --
> 1.7.12
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57842] r200: Culling is broken when rendering to an FBO
https://bugs.freedesktop.org/show_bug.cgi?id=57842 --- Comment #16 from Stefan D?singer --- Commit it to Git and use git send-email to send it to mesa-dev at lists.freedesktop.org . Google finds many tutorials on how to do this. -- 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/20130103/84410183/attachment.html>
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
> -Original Message- > From: Boszormenyi Zoltan [mailto:zboszor at pr.hu] > Sent: Thursday, January 03, 2013 6:37 AM > To: Alex Deucher > Cc: Markus Trippelsdorf; lkml; dri-devel at lists.freedesktop.org; Deucher, > Alexander; Borislav Petkov; Shuah Khan > Subject: Re: radeon :02:00.0: GPU lockup CP stall for more than > 1msec > > 2013-01-03 00:37 keltez?ssel, Alex Deucher ?rta: > > On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf > > wrote: > >> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: > >>> Please affected people can you test if patch : > >>> http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy- > on-r6xx-r7xx-evergen-ni-si-g.patch > >>> > >>> Fix the issue, you need to make sure you don't have the patch that > >>> disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c > >>> is : > >>> .copy = &r600_copy_dma, > >>> .copy_ring_index = R600_RING_TYPE_DMA_INDEX, > >> It fixes the issue for me. Thanks. > > The count is actually the count, not count - 1. The real fix seems to > > be that r6xx requires 2 dw aligned transfers. The attached patch > > fixes the issue for me. > > > > Alex > > I tried this patch over kernel 3.8.0-rc2 but the GDM screen is mostly garbage. > Only some text, like "Not on the list?" below the users and small icons are > visible > but many user names are not rendered. http://tinypic.com/r/33xihit/6 > I am on Fedora 18/x86_64, Radeon HD6570. I don't think the issue you are seeing is related to this one. Looks similar to: https://bugs.freedesktop.org/show_bug.cgi?id=55574 Alex
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #50 from Alex Deucher --- (In reply to comment #49) > > Is the BusID line in the intel device section not needed? What is needed for > X to automatically detect multiple GPUs properly and show some video output > from the correct card? You'll need to use vga-switcheroo to select the card you want to use. Then you should be able to start X without any config and it will start on the one selected by vga-switcheroo. Having two device sections as your config does will force X to try and start on both devices. -- 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/20130103/51a6dab5/attachment.html>
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #51 from Anonymous Helper --- (In reply to comment #50) > You'll need to use vga-switcheroo to select the card you want to use. Then > you should be able to start X without any config and it will start on the > one selected by vga-switcheroo. Having two device sections as your config > does will force X to try and start on both devices. I tried without the BusID but all I got was a black screen. For some reason when I switch to the intel GPU I get a black screen also, though it did work when I booted from grub-efi earlier with the well documented outb commands to disable AMD (no BIOS from EFI w/o efistub). Not sure if it's an issue with vga-switcheroo, intel driver or something else. I don't know if it's a problem, but both cards are powered on at boot. I can switch back and forth between the GPUs (though it's tricky doing so blind when on intel graphics). Any other suggestions? Thanks. -- 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/20130103/c2788955/attachment.html>
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #52 from Alex Deucher --- (In reply to comment #51) > Any other suggestions? Thanks. You might ask on the dri-devel mailing list. This is getting off topic for 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/20130103/10a066f2/attachment-0001.html>
[PATCH 1/2] drm/radeon: print dma status reg on lockup (v2)
From: Jerome Glisse
To help debug dma related lockup.
v2: agd5f: update SI as well
Signed-off-by: Jerome Glisse
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |4
drivers/gpu/drm/radeon/evergreend.h |3 +++
drivers/gpu/drm/radeon/ni.c |4
drivers/gpu/drm/radeon/nid.h|1 -
drivers/gpu/drm/radeon/r600.c |4
drivers/gpu/drm/radeon/si.c |9 +
drivers/gpu/drm/radeon/sid.h|2 ++
7 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index f95d7fc..6dc9ee7 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2331,6 +2331,8 @@ static int evergreen_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
evergreen_mc_stop(rdev, &save);
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
@@ -2376,6 +2378,8 @@ static int evergreen_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
evergreen_mc_resume(rdev, &save);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/evergreend.h
b/drivers/gpu/drm/radeon/evergreend.h
index cb9baaa..f82f98a 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -2027,4 +2027,7 @@
/* cayman packet3 addition */
#defineCAYMAN_PACKET3_DEALLOC_STATE0x14
+/* DMA regs common on r6xx/r7xx/evergreen/ni */
+#define DMA_STATUS_REG0xd034
+
#endif
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 7bdbcb0..6dae387 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1331,6 +1331,8 @@ static int cayman_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
dev_info(rdev->dev, " VM_CONTEXT0_PROTECTION_FAULT_ADDR 0x%08X\n",
RREG32(0x14F8));
dev_info(rdev->dev, " VM_CONTEXT0_PROTECTION_FAULT_STATUS 0x%08X\n",
@@ -1387,6 +1389,8 @@ static int cayman_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
evergreen_mc_resume(rdev, &save);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
index b93186b..22a62c6 100644
--- a/drivers/gpu/drm/radeon/nid.h
+++ b/drivers/gpu/drm/radeon/nid.h
@@ -675,4 +675,3 @@
#defineDMA_PACKET_NOP0xf
#endif
-
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 9f4ce5e..252067b 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1297,6 +1297,8 @@ static int r600_gpu_soft_reset(struct radeon_device *rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
rv515_mc_stop(rdev, &save);
if (r600_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
@@ -1348,6 +1350,8 @@ static int r600_gpu_soft_reset(struct radeon_device *rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
rv515_mc_resume(rdev, &save);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index ef68365..74d3845 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2145,6 +2145,13 @@ static int si_gpu_soft_reset(struct radeon_device *rdev)
RREG32(GRBM_STATUS_SE1));
dev_info(rdev->dev, " SRBM_STATUS=0x%08X\n",
RREG32(SRBM_STATUS));
+ dev_info(rdev->dev, " DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS
[PATCH 2/2] drm/radeon: reset dma engine on gpu reset (v2)
From: Jerome Glisse
This try to reset the dma engine when performing gpu reset. Hopefully
bringing back the gpu dma engine in sane state.
v2: agd5f: fix dma reset on cayman/TN, add support for SI
Signed-off-by: Jerome Glisse
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 30 +-
drivers/gpu/drm/radeon/evergreend.h | 10 +-
drivers/gpu/drm/radeon/ni.c | 35 ++-
drivers/gpu/drm/radeon/nid.h|2 +-
drivers/gpu/drm/radeon/r600.c | 28 ++--
drivers/gpu/drm/radeon/si.c | 18 +-
drivers/gpu/drm/radeon/sid.h| 16
7 files changed, 112 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 6dc9ee7..f92f6bb 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2309,19 +2309,19 @@ bool evergreen_gpu_is_lockup(struct radeon_device
*rdev, struct radeon_ring *rin
static int evergreen_gpu_soft_reset(struct radeon_device *rdev)
{
struct evergreen_mc_save save;
- u32 grbm_reset = 0;
+ u32 grbm_reset = 0, tmp;
if (!(RREG32(GRBM_STATUS) & GUI_ACTIVE))
return 0;
dev_info(rdev->dev, "GPU softreset \n");
- dev_info(rdev->dev, " GRBM_STATUS=0x%08X\n",
+ dev_info(rdev->dev, " GRBM_STATUS = 0x%08X\n",
RREG32(GRBM_STATUS));
- dev_info(rdev->dev, " GRBM_STATUS_SE0=0x%08X\n",
+ dev_info(rdev->dev, " GRBM_STATUS_SE0 = 0x%08X\n",
RREG32(GRBM_STATUS_SE0));
- dev_info(rdev->dev, " GRBM_STATUS_SE1=0x%08X\n",
+ dev_info(rdev->dev, " GRBM_STATUS_SE1 = 0x%08X\n",
RREG32(GRBM_STATUS_SE1));
- dev_info(rdev->dev, " SRBM_STATUS=0x%08X\n",
+ dev_info(rdev->dev, " SRBM_STATUS = 0x%08X\n",
RREG32(SRBM_STATUS));
dev_info(rdev->dev, " R_008674_CP_STALLED_STAT1 = 0x%08X\n",
RREG32(CP_STALLED_STAT1));
@@ -2337,9 +2337,21 @@ static int evergreen_gpu_soft_reset(struct radeon_device
*rdev)
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
}
+
/* Disable CP parsing/prefetching */
WREG32(CP_ME_CNTL, CP_ME_HALT | CP_PFP_HALT);
+ /* Disable DMA */
+ tmp = RREG32(DMA_RB_CNTL);
+ tmp &= ~DMA_RB_ENABLE;
+ WREG32(DMA_RB_CNTL, tmp);
+
+ /* Reset dma */
+ WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA);
+ RREG32(SRBM_SOFT_RESET);
+ udelay(50);
+ WREG32(SRBM_SOFT_RESET, 0);
+
/* reset all the gfx blocks */
grbm_reset = (SOFT_RESET_CP |
SOFT_RESET_CB |
@@ -2362,13 +2374,13 @@ static int evergreen_gpu_soft_reset(struct
radeon_device *rdev)
(void)RREG32(GRBM_SOFT_RESET);
/* Wait a little for things to settle down */
udelay(50);
- dev_info(rdev->dev, " GRBM_STATUS=0x%08X\n",
+ dev_info(rdev->dev, " GRBM_STATUS = 0x%08X\n",
RREG32(GRBM_STATUS));
- dev_info(rdev->dev, " GRBM_STATUS_SE0=0x%08X\n",
+ dev_info(rdev->dev, " GRBM_STATUS_SE0 = 0x%08X\n",
RREG32(GRBM_STATUS_SE0));
- dev_info(rdev->dev, " GRBM_STATUS_SE1=0x%08X\n",
+ dev_info(rdev->dev, " GRBM_STATUS_SE1 = 0x%08X\n",
RREG32(GRBM_STATUS_SE1));
- dev_info(rdev->dev, " SRBM_STATUS=0x%08X\n",
+ dev_info(rdev->dev, " SRBM_STATUS = 0x%08X\n",
RREG32(SRBM_STATUS));
dev_info(rdev->dev, " R_008674_CP_STALLED_STAT1 = 0x%08X\n",
RREG32(CP_STALLED_STAT1));
diff --git a/drivers/gpu/drm/radeon/evergreend.h
b/drivers/gpu/drm/radeon/evergreend.h
index f82f98a..5786a32 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -742,8 +742,9 @@
#defineSOFT_RESET_ROM (1 << 14)
#defineSOFT_RESET_SEM (1 << 15)
#defineSOFT_RESET_VMC (1 << 17)
+#defineSOFT_RESET_DMA (1 << 20)
#defineSOFT_RESET_TST (1 << 21)
-#defineSOFT_RESET_REGBB(1 << 22)
+#defineSOFT_RESET_REGBB(1 << 22)
#defineSOFT_RESET_ORB (1 << 23)
/* display watermarks */
@@ -2028,6 +2029,13 @@
#defineCAYMAN_PACKET3_DEALLOC_STATE0x14
/* DMA regs common on r6xx/r7xx/evergreen/ni */
+#define DMA_RB_CNTL 0xd000
+# define DMA_RB_ENABLE (1 << 0)
+# define DMA_RB_SIZE(x)
[PATCH 8/8] drm/exynos: fimd: add complete_scanout function
On Thu, Jan 3, 2013 at 7:56 AM, Prathyush K wrote:
>
>
>
> On Wed, Jan 2, 2013 at 10:24 PM, Sean Paul wrote:
>>
>> On Wed, Dec 26, 2012 at 6:27 AM, Prathyush K
>> wrote:
>> > The wait_for_vblank interface is modified to the complete_scanout
>> > function in fimd. This patch adds the fimd_complete_scanout function
>> >
>> > Inside fimd_complete_scanout, we read the shadow register for each
>> > window and compare it with the dma address of the framebuffer. If
>> > the dma_address is in the shadow register, then the function waits
>> > for the next vblank and returns.
>> >
>> > Signed-off-by: Prathyush K
>> > ---
>> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 32
>> > +++-
>> > include/video/samsung_fimd.h | 1 +
>> > 2 files changed, 32 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > index 3aeedf5..190ffde9 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > @@ -46,6 +46,7 @@
>> > #define VIDOSD_D(win) (VIDOSD_BASE + 0x0C + (win) * 16)
>> >
>> > #define VIDWx_BUF_START(win, buf) (VIDW_BUF_START(buf) + (win) *
>> > 8)
>> > +#define VIDWx_BUF_START_S(win, buf)(VIDW_BUF_START_S(buf) + (win) *
>> > 8)
>> > #define VIDWx_BUF_END(win, buf)(VIDW_BUF_END(buf) +
>> > (win) * 8)
>> > #define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4)
>> >
>> > @@ -363,13 +364,42 @@ static void fimd_wait_for_vblank(struct device
>> > *dev)
>> > fimd_disable_vblank(dev);
>> > }
>> >
>> > +static void fimd_complete_scanout(struct device *dev, dma_addr_t
>> > dma_addr,
>> > + unsigned long size)
>> > +{
>> > + struct fimd_context *ctx = get_fimd_context(dev);
>> > + int win;
>> > + bool in_use = false;
>> > +
>> > + if (ctx->suspended)
>> > + return;
>> > +
>>
>> Is this really possible? If it is, I think there's potential for
>> trouble. It seems possible that an fb is current, but we're suspended.
>> If we exit early here, the fb will be freed and we'll be sad when we
>> come out of suspend.
>>
> Hi Sean,
>
> Before suspend, we disable all the windows (and wait for vsync) and keep
> track of which windows need to be resumed.
>
> If a fb is being removed during suspend, and if that fb was previously set
> to fimd, we modify the resume flag
> so that the window will not be resumed during fimd_resume.
>
>
>>
>> > + for (win = 0; win < WINDOWS_NR; win++) {
>> > + dma_addr_t dma_addr_in_use;
>> > +
>> > + if (!ctx->win_data[win].enabled)
>> > + continue;
>> > +
>> > + dma_addr_in_use = readl(ctx->regs +
>> > VIDWx_BUF_START_S(win, 0));
>> > + if (dma_addr_in_use >= dma_addr &&
>> > + dma_addr_in_use < (dma_addr + size)) {
>> > + in_use = true;
>> > + break;
>> > + }
>>
>> I think this has the opposite problem as your mixer patch. You're
>> checking if the framebuffer is in the shadow register, but I don't
>> think this code will wait if the fb is currently being scanned out. I
>> hope I'm just missing something :)
>>
> Right, I do not check for the base register here. This is because I also
> consider the disable_crtc
> function.
>
> Consider the following two cases:
>
> 1>
> fb1 set to fimd and fimd is reading from fb1 (so both base register and
> shadow register have fb1's dma addr)
> call remove fb1
>
> since crtc->fb == fb1, the "exynos_drm_crtc_disable" gets called. This will
> disable the window and also turn off fimd with DPMS_OFF.
>
> fimd dpms off will ensure that the window actually gets disabled by waiting
> for vblank.
>
> Now before removing fb1, we call complete_scanout. Since fimd is already
> suspended, this will just return. No issue.
>
I see the code path you're talking about. I think I was confused by
the "suspended" name, it also covers the disabled/off case.
> 2>
> fb1 set to fimd, fimd reading from fb1.
> fb2 set to fimd
> call remove fb1
> (now base register has fb2, shadow register has fb1)
>
> since crtc->fb == fb2, crtc_disable wont be called.
>
> In complete scanout, we check only shadow register (which has fb1).
> So we wait for vsync, so that next dma starts from fb2 and then we go ahead
> and remove fb1.
>
Ok, I think I've straightened out my mental model of how this works.
Thanks for the explanation
> I tried to apply the same logic for mixer:
> In mixer, it is slightly more complex, since we have layer updates.
>
> Consider the following cases for mixer:
>
> 1> fb1 set to mixer (base register has fb1) - also fb1 gets queued with a
> layer update.
> mixer is reading from fb1 (shadow register has fb1).
> remove fb1
>
> crtc->fb == fb1, so win_disable gets called followed by
[PATCH 7/8] drm/exynos: hdmi: add complete_scanout function
On Thu, Jan 3, 2013 at 7:58 AM, Prathyush K wrote:
>
>
>
> On Wed, Jan 2, 2013 at 10:12 PM, Sean Paul wrote:
>>
>> On Wed, Dec 26, 2012 at 6:27 AM, Prathyush K
>> wrote:
>> > The wait_for_vblank interface is modified to the complete_scanout
>> > function in hdmi. This inturn calls the complete_scanout mixer op.
>> > This patch also adds the mixer_complete_scanout function.
>> >
>> > Inside mixer_complete_scanout, we read the base register and shadow
>> > register for each window and compare it with the dma address of the
>> > framebuffer. If the dma_address is in the base register, the mixer
>> > window is disabled. If the dma_address is in the shadow register,
>> > then the function waits for the next vblank and returns.
>> >
>> > Signed-off-by: Prathyush K
>> > ---
>> > drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 11 ++
>> > drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 3 ++-
>> > drivers/gpu/drm/exynos/exynos_mixer.c| 37
>> > +++-
>> > 3 files changed, 45 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> > b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> > index d8ae47e..e32eb1c 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> > @@ -177,14 +177,17 @@ static void drm_hdmi_disable_vblank(struct device
>> > *subdrv_dev)
>> > return mixer_ops->disable_vblank(ctx->mixer_ctx->ctx);
>> > }
>> >
>> > -static void drm_hdmi_wait_for_vblank(struct device *subdrv_dev)
>> > +static void drm_hdmi_complete_scanout(struct device *subdrv_dev,
>> > + dma_addr_t dma_addr,
>> > + unsigned long size)
>> > {
>> > struct drm_hdmi_context *ctx = to_context(subdrv_dev);
>> >
>> > DRM_DEBUG_KMS("%s\n", __FILE__);
>> >
>> > - if (mixer_ops && mixer_ops->wait_for_vblank)
>> > - mixer_ops->wait_for_vblank(ctx->mixer_ctx->ctx);
>> > + if (mixer_ops && mixer_ops->complete_scanout)
>> > + mixer_ops->complete_scanout(ctx->mixer_ctx->ctx,
>> > + dma_addr, size);
>> > }
>> >
>> > static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
>> > @@ -263,7 +266,7 @@ static struct exynos_drm_manager_ops
>> > drm_hdmi_manager_ops = {
>> > .apply = drm_hdmi_apply,
>> > .enable_vblank = drm_hdmi_enable_vblank,
>> > .disable_vblank = drm_hdmi_disable_vblank,
>> > - .wait_for_vblank = drm_hdmi_wait_for_vblank,
>> > + .complete_scanout = drm_hdmi_complete_scanout,
>> > .mode_fixup = drm_hdmi_mode_fixup,
>> > .mode_set = drm_hdmi_mode_set,
>> > .get_max_resol = drm_hdmi_get_max_resol,
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> > b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> > index 4fad00c..7d5bf00 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> > @@ -51,7 +51,8 @@ struct exynos_mixer_ops {
>> > int (*iommu_on)(void *ctx, bool enable);
>> > int (*enable_vblank)(void *ctx, int pipe);
>> > void (*disable_vblank)(void *ctx);
>> > - void (*wait_for_vblank)(void *ctx);
>> > + void (*complete_scanout)(void *ctx, dma_addr_t dma_addr,
>> > + unsigned long size);
>> > void (*dpms)(void *ctx, int mode);
>> >
>> > /* overlay */
>> > diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
>> > b/drivers/gpu/drm/exynos/exynos_mixer.c
>> > index 3369d57..151e13f 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> > @@ -861,6 +861,41 @@ static void mixer_wait_for_vblank(void *ctx)
>> > DRM_DEBUG_KMS("vblank wait timed out.\n");
>> > }
>> >
>> > +static void mixer_complete_scanout(void *ctx, dma_addr_t dma_addr,
>> > + unsigned long size)
>> > +{
>> > + struct mixer_context *mixer_ctx = ctx;
>> > + struct mixer_resources *res = &mixer_ctx->mixer_res;
>> > + int win;
>> > + bool in_use = false;
>> > + bool in_use_s = false;
>> > +
>> > + if (!mixer_ctx->powered)
>>
>> Accesses to mixer_ctx->powered are always protected by mixer_mutex,
>> this should probably stay consistent (either way).
>>
>
> Hi Sean,
>
> Right, thanks for pointing that out. I'll update in next patch set.
>
>
>>
>> > + return;
>> > +
>> > + for (win = 0; win < MIXER_WIN_NR; win++) {
>> > + dma_addr_t dma_addr_in_use;
>> > +
>> > + if (!mixer_ctx->win_data[win].enabled)
>> > + continue;
>> > +
>> > + dma_addr_in_use = mixer_reg_read(res,
>> > MXR_GRAPHIC_BASE(win));
>> > + if (dma_addr_in_use >= dma_addr &&
>> > + dma_addr_in_use < (dma_addr + size)) {
>> > +
[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 void tegra_drm_close(struct drm_device *drm, struct drm_file *filp)
>> +{
>> +
>> +}
>> +
>
> This can be removed, right?
Yes, done.
>
>> +static struct platform_driver tegra_drm_platform_driver = {
>> +.driver = {
>> +.name = "tegradrm",
>
> This should be "tegra-drm" to match the module name.
Done.
>> -struct host1x_client;
>> +struct tegra_drm_client;
>
> I don't see the point in renaming this. All of the devices are still
> host1x clients, right? This patch would be a whole shorter if we didn't
> rename these. None of these symbols are exported either so there's not
> much chance for them to clash with anything.
Yep, we renamed it back to make the patch smaller.
>> diff --git a/include/drm/tegra_drm.h b/include/drm/tegra_drm.h
>> new file mode 100644
>> index 000..8632f49
>> --- /dev/null
>> +++ b/include/drm/tegra_drm.h
>> @@ -0,0 +1,20 @@
>> +/*
>> + * Copyright (c) 2012, NVIDIA CORPORATION. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope 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, see
[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board
https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #13 from Konrad Rzeszutek Wilk 2013-01-03 18:04:34 --- So is it safe to safe that it does not work without Xen? Or do you see stuff on the screen in baremetal mode? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH 1/5] drm/radeon: add GPU reset flags
From: Alex Deucher The idea here is to move to a finer grained reset. In some cases we may not need reset every block, and in other cases we may not need to re-init the entire asic. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 9b9422c..34e5230 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -132,6 +132,11 @@ extern int radeon_lockup_timeout; #define RADEON_VA_RESERVED_SIZE(8 << 20) #define RADEON_IB_VM_MAX_SIZE (64 << 10) +/* reset flags */ +#define RADEON_RESET_GFX (1 << 0) +#define RADEON_RESET_COMPUTE (1 << 1) +#define RADEON_RESET_DMA (1 << 2) + /* * Errata workarounds. */ -- 1.7.7.5
[PATCH 2/5] drm/radeon: switch to a finer grained reset for r6xx/7xx
From: Alex Deucher
No change in functionality as we currently set all the reset
flags.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c | 85 -
1 files changed, 58 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 721b5af..923f936 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1258,9 +1258,8 @@ void r600_vram_scratch_fini(struct radeon_device *rdev)
* reset, it's up to the caller to determine if the GPU needs one. We
* might add an helper function to check that.
*/
-static int r600_gpu_soft_reset(struct radeon_device *rdev)
+static void r600_gpu_soft_reset_gfx(struct radeon_device *rdev)
{
- struct rv515_mc_save save;
u32 grbm_busy_mask = S_008010_VC_BUSY(1) | S_008010_VGT_BUSY_NO_DMA(1) |
S_008010_VGT_BUSY(1) | S_008010_TA03_BUSY(1) |
S_008010_TC_BUSY(1) | S_008010_SX_BUSY(1) |
@@ -1280,9 +1279,8 @@ static int r600_gpu_soft_reset(struct radeon_device *rdev)
u32 tmp;
if (!(RREG32(GRBM_STATUS) & GUI_ACTIVE))
- return 0;
+ return;
- dev_info(rdev->dev, "GPU softreset \n");
dev_info(rdev->dev, " R_008010_GRBM_STATUS = 0x%08X\n",
RREG32(R_008010_GRBM_STATUS));
dev_info(rdev->dev, " R_008014_GRBM_STATUS2 = 0x%08X\n",
@@ -1297,30 +1295,10 @@ static int r600_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
- dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
- RREG32(DMA_STATUS_REG));
- rv515_mc_stop(rdev, &save);
- if (r600_mc_wait_for_idle(rdev)) {
- dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
- }
/* Disable CP parsing/prefetching */
WREG32(R_0086D8_CP_ME_CNTL, S_0086D8_CP_ME_HALT(1));
- /* Disable DMA */
- tmp = RREG32(DMA_RB_CNTL);
- tmp &= ~DMA_RB_ENABLE;
- WREG32(DMA_RB_CNTL, tmp);
-
- /* Reset dma */
- if (rdev->family >= CHIP_RV770)
- WREG32(SRBM_SOFT_RESET, RV770_SOFT_RESET_DMA);
- else
- WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA);
- RREG32(SRBM_SOFT_RESET);
- udelay(50);
- WREG32(SRBM_SOFT_RESET, 0);
-
/* Check if any of the rendering block is busy and reset it */
if ((RREG32(R_008010_GRBM_STATUS) & grbm_busy_mask) ||
(RREG32(R_008014_GRBM_STATUS2) & grbm2_busy_mask)) {
@@ -1350,8 +1328,7 @@ static int r600_gpu_soft_reset(struct radeon_device *rdev)
RREG32(R_008020_GRBM_SOFT_RESET);
mdelay(15);
WREG32(R_008020_GRBM_SOFT_RESET, 0);
- /* Wait a little for things to settle down */
- mdelay(1);
+
dev_info(rdev->dev, " R_008010_GRBM_STATUS = 0x%08X\n",
RREG32(R_008010_GRBM_STATUS));
dev_info(rdev->dev, " R_008014_GRBM_STATUS2 = 0x%08X\n",
@@ -1366,8 +1343,60 @@ static int r600_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+
+}
+
+static void r600_gpu_soft_reset_dma(struct radeon_device *rdev)
+{
+ u32 tmp;
+
+ if (RREG32(DMA_STATUS_REG) & DMA_IDLE)
+ return;
+
dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
RREG32(DMA_STATUS_REG));
+
+ /* Disable DMA */
+ tmp = RREG32(DMA_RB_CNTL);
+ tmp &= ~DMA_RB_ENABLE;
+ WREG32(DMA_RB_CNTL, tmp);
+
+ /* Reset dma */
+ if (rdev->family >= CHIP_RV770)
+ WREG32(SRBM_SOFT_RESET, RV770_SOFT_RESET_DMA);
+ else
+ WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA);
+ RREG32(SRBM_SOFT_RESET);
+ udelay(50);
+ WREG32(SRBM_SOFT_RESET, 0);
+
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
+}
+
+static int r600_gpu_soft_reset(struct radeon_device *rdev, u32 reset_mask)
+{
+ struct rv515_mc_save save;
+
+ if (reset_mask == 0)
+ return 0;
+
+ dev_info(rdev->dev, "GPU softreset: 0x%08X\n", reset_mask);
+
+ rv515_mc_stop(rdev, &save);
+ if (r600_mc_wait_for_idle(rdev)) {
+ dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
+ }
+
+ if (reset_mask & (RADEON_RESET_GFX | RADEON_RESET_COMPUTE))
+ r600_gpu_soft_reset_gfx(rdev);
+
+ if (reset_mask & RADEON_RESET_DMA)
+ r600_gpu_soft_reset_dma(rdev);
+
+ /* Wait a little for things to settle down */
+ mdelay(1);
+
rv515_mc_resume(rdev, &save);
return 0;
}
@@ -1415,7 +1444,9 @@ bool r600_dma_is_lockup(struct radeon_device *rdev,
[PATCH 3/5] drm/radeon: switch to a finer grained reset for evergreen
From: Alex Deucher
No change in functionality as we currently set all the reset
flags.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 80 ---
drivers/gpu/drm/radeon/evergreend.h |1 +
2 files changed, 56 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index f92f6bb..58dbf01 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2306,15 +2306,13 @@ bool evergreen_gpu_is_lockup(struct radeon_device
*rdev, struct radeon_ring *rin
return radeon_ring_test_lockup(rdev, ring);
}
-static int evergreen_gpu_soft_reset(struct radeon_device *rdev)
+static void evergreen_gpu_soft_reset_gfx(struct radeon_device *rdev)
{
- struct evergreen_mc_save save;
- u32 grbm_reset = 0, tmp;
+ u32 grbm_reset = 0;
if (!(RREG32(GRBM_STATUS) & GUI_ACTIVE))
- return 0;
+ return;
- dev_info(rdev->dev, "GPU softreset \n");
dev_info(rdev->dev, " GRBM_STATUS = 0x%08X\n",
RREG32(GRBM_STATUS));
dev_info(rdev->dev, " GRBM_STATUS_SE0 = 0x%08X\n",
@@ -2331,27 +2329,10 @@ static int evergreen_gpu_soft_reset(struct
radeon_device *rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
- dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
- RREG32(DMA_STATUS_REG));
- evergreen_mc_stop(rdev, &save);
- if (evergreen_mc_wait_for_idle(rdev)) {
- dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
- }
/* Disable CP parsing/prefetching */
WREG32(CP_ME_CNTL, CP_ME_HALT | CP_PFP_HALT);
- /* Disable DMA */
- tmp = RREG32(DMA_RB_CNTL);
- tmp &= ~DMA_RB_ENABLE;
- WREG32(DMA_RB_CNTL, tmp);
-
- /* Reset dma */
- WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA);
- RREG32(SRBM_SOFT_RESET);
- udelay(50);
- WREG32(SRBM_SOFT_RESET, 0);
-
/* reset all the gfx blocks */
grbm_reset = (SOFT_RESET_CP |
SOFT_RESET_CB |
@@ -2372,8 +2353,7 @@ static int evergreen_gpu_soft_reset(struct radeon_device
*rdev)
udelay(50);
WREG32(GRBM_SOFT_RESET, 0);
(void)RREG32(GRBM_SOFT_RESET);
- /* Wait a little for things to settle down */
- udelay(50);
+
dev_info(rdev->dev, " GRBM_STATUS = 0x%08X\n",
RREG32(GRBM_STATUS));
dev_info(rdev->dev, " GRBM_STATUS_SE0 = 0x%08X\n",
@@ -2390,15 +2370,65 @@ static int evergreen_gpu_soft_reset(struct
radeon_device *rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+}
+
+static void evergreen_gpu_soft_reset_dma(struct radeon_device *rdev)
+{
+ u32 tmp;
+
+ if (RREG32(DMA_STATUS_REG) & DMA_IDLE)
+ return;
+
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
+
+ /* Disable DMA */
+ tmp = RREG32(DMA_RB_CNTL);
+ tmp &= ~DMA_RB_ENABLE;
+ WREG32(DMA_RB_CNTL, tmp);
+
+ /* Reset dma */
+ WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA);
+ RREG32(SRBM_SOFT_RESET);
+ udelay(50);
+ WREG32(SRBM_SOFT_RESET, 0);
+
dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
RREG32(DMA_STATUS_REG));
+}
+
+static int evergreen_gpu_soft_reset(struct radeon_device *rdev, u32 reset_mask)
+{
+ struct evergreen_mc_save save;
+
+ if (reset_mask == 0)
+ return 0;
+
+ dev_info(rdev->dev, "GPU softreset: 0x%08X\n", reset_mask);
+
+ evergreen_mc_stop(rdev, &save);
+ if (evergreen_mc_wait_for_idle(rdev)) {
+ dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
+ }
+
+ if (reset_mask & (RADEON_RESET_GFX | RADEON_RESET_COMPUTE))
+ evergreen_gpu_soft_reset_gfx(rdev);
+
+ if (reset_mask & RADEON_RESET_DMA)
+ evergreen_gpu_soft_reset_dma(rdev);
+
+ /* Wait a little for things to settle down */
+ udelay(50);
+
evergreen_mc_resume(rdev, &save);
return 0;
}
int evergreen_asic_reset(struct radeon_device *rdev)
{
- return evergreen_gpu_soft_reset(rdev);
+ return evergreen_gpu_soft_reset(rdev, (RADEON_RESET_GFX |
+ RADEON_RESET_COMPUTE |
+ RADEON_RESET_DMA));
}
/* Interrupts */
diff --git a/drivers/gpu/drm/radeon/evergreend.h
b/drivers/gpu/drm/radeon/evergreend.h
index 5786a32..0bfd0e9 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -2037,5 +2037,6 @@
# define DMA_RPTR_WRITEBACK_SWAP_ENABLE
[PATCH 4/5] drm/radeon: switch to a finer grained reset for cayman/TN
From: Alex Deucher
No change in functionality as we currently set all the reset
flags.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/ni.c | 109 +++---
1 files changed, 70 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 8a9a75d..896f1cb 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1306,15 +1306,13 @@ void cayman_dma_fini(struct radeon_device *rdev)
radeon_ring_fini(rdev, &rdev->ring[CAYMAN_RING_TYPE_DMA1_INDEX]);
}
-static int cayman_gpu_soft_reset(struct radeon_device *rdev)
+static void cayman_gpu_soft_reset_gfx(struct radeon_device *rdev)
{
- struct evergreen_mc_save save;
- u32 grbm_reset = 0, tmp;
+ u32 grbm_reset = 0;
if (!(RREG32(GRBM_STATUS) & GUI_ACTIVE))
- return 0;
+ return;
- dev_info(rdev->dev, "GPU softreset \n");
dev_info(rdev->dev, " GRBM_STATUS = 0x%08X\n",
RREG32(GRBM_STATUS));
dev_info(rdev->dev, " GRBM_STATUS_SE0 = 0x%08X\n",
@@ -1331,41 +1329,10 @@ static int cayman_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
- dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
- RREG32(DMA_STATUS_REG));
- dev_info(rdev->dev, " VM_CONTEXT0_PROTECTION_FAULT_ADDR 0x%08X\n",
-RREG32(0x14F8));
- dev_info(rdev->dev, " VM_CONTEXT0_PROTECTION_FAULT_STATUS 0x%08X\n",
-RREG32(0x14D8));
- dev_info(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x%08X\n",
-RREG32(0x14FC));
- dev_info(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x%08X\n",
-RREG32(0x14DC));
-
- evergreen_mc_stop(rdev, &save);
- if (evergreen_mc_wait_for_idle(rdev)) {
- dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
- }
/* Disable CP parsing/prefetching */
WREG32(CP_ME_CNTL, CP_ME_HALT | CP_PFP_HALT);
- /* dma0 */
- tmp = RREG32(DMA_RB_CNTL + DMA0_REGISTER_OFFSET);
- tmp &= ~DMA_RB_ENABLE;
- WREG32(DMA_RB_CNTL + DMA0_REGISTER_OFFSET, tmp);
-
- /* dma1 */
- tmp = RREG32(DMA_RB_CNTL + DMA1_REGISTER_OFFSET);
- tmp &= ~DMA_RB_ENABLE;
- WREG32(DMA_RB_CNTL + DMA1_REGISTER_OFFSET, tmp);
-
- /* Reset dma */
- WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA | SOFT_RESET_DMA1);
- RREG32(SRBM_SOFT_RESET);
- udelay(50);
- WREG32(SRBM_SOFT_RESET, 0);
-
/* reset all the gfx blocks */
grbm_reset = (SOFT_RESET_CP |
SOFT_RESET_CB |
@@ -1387,8 +1354,6 @@ static int cayman_gpu_soft_reset(struct radeon_device
*rdev)
udelay(50);
WREG32(GRBM_SOFT_RESET, 0);
(void)RREG32(GRBM_SOFT_RESET);
- /* Wait a little for things to settle down */
- udelay(50);
dev_info(rdev->dev, " GRBM_STATUS = 0x%08X\n",
RREG32(GRBM_STATUS));
@@ -1406,15 +1371,81 @@ static int cayman_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(CP_BUSY_STAT));
dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
RREG32(CP_STAT));
+
+}
+
+static void cayman_gpu_soft_reset_dma(struct radeon_device *rdev)
+{
+ u32 tmp;
+
+ if (RREG32(DMA_STATUS_REG) & DMA_IDLE)
+ return;
+
dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
RREG32(DMA_STATUS_REG));
+
+ /* dma0 */
+ tmp = RREG32(DMA_RB_CNTL + DMA0_REGISTER_OFFSET);
+ tmp &= ~DMA_RB_ENABLE;
+ WREG32(DMA_RB_CNTL + DMA0_REGISTER_OFFSET, tmp);
+
+ /* dma1 */
+ tmp = RREG32(DMA_RB_CNTL + DMA1_REGISTER_OFFSET);
+ tmp &= ~DMA_RB_ENABLE;
+ WREG32(DMA_RB_CNTL + DMA1_REGISTER_OFFSET, tmp);
+
+ /* Reset dma */
+ WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA | SOFT_RESET_DMA1);
+ RREG32(SRBM_SOFT_RESET);
+ udelay(50);
+ WREG32(SRBM_SOFT_RESET, 0);
+
+ dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
+
+}
+
+static int cayman_gpu_soft_reset(struct radeon_device *rdev, u32 reset_mask)
+{
+ struct evergreen_mc_save save;
+
+ if (reset_mask == 0)
+ return 0;
+
+ dev_info(rdev->dev, "GPU softreset: 0x%08X\n", reset_mask);
+
+ dev_info(rdev->dev, " VM_CONTEXT0_PROTECTION_FAULT_ADDR 0x%08X\n",
+RREG32(0x14F8));
+ dev_info(rdev->dev, " VM_CONTEXT0_PROTECTION_FAULT_STATUS 0x%08X\n",
+RREG32(0x14D8));
+ dev_info(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x%08X\n",
+RREG32(0x14FC));
+ dev_info(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x%08X\n",
+
[PATCH 5/5] drm/radeon: switch to a finer grained reset for SI
From: Alex Deucher
No change in functionality as we currently set all the reset
flags.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/si.c | 98 ---
1 files changed, 64 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 4bf1733..d4aae43 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2126,15 +2126,13 @@ bool si_gpu_is_lockup(struct radeon_device *rdev,
struct radeon_ring *ring)
return radeon_ring_test_lockup(rdev, ring);
}
-static int si_gpu_soft_reset(struct radeon_device *rdev)
+static void si_gpu_soft_reset_gfx(struct radeon_device *rdev)
{
- struct evergreen_mc_save save;
- u32 grbm_reset = 0, tmp;
+ u32 grbm_reset = 0;
if (!(RREG32(GRBM_STATUS) & GUI_ACTIVE))
- return 0;
+ return;
- dev_info(rdev->dev, "GPU softreset \n");
dev_info(rdev->dev, " GRBM_STATUS=0x%08X\n",
RREG32(GRBM_STATUS));
dev_info(rdev->dev, " GRBM_STATUS2=0x%08X\n",
@@ -2145,36 +2143,10 @@ static int si_gpu_soft_reset(struct radeon_device *rdev)
RREG32(GRBM_STATUS_SE1));
dev_info(rdev->dev, " SRBM_STATUS=0x%08X\n",
RREG32(SRBM_STATUS));
- dev_info(rdev->dev, " DMA_STATUS_REG = 0x%08X\n",
- RREG32(DMA_STATUS_REG));
- dev_info(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x%08X\n",
-RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR));
- dev_info(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x%08X\n",
-RREG32(VM_CONTEXT1_PROTECTION_FAULT_STATUS));
- evergreen_mc_stop(rdev, &save);
- if (radeon_mc_wait_for_idle(rdev)) {
- dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
- }
/* Disable CP parsing/prefetching */
WREG32(CP_ME_CNTL, CP_ME_HALT | CP_PFP_HALT | CP_CE_HALT);
- /* dma0 */
- tmp = RREG32(DMA_RB_CNTL + DMA0_REGISTER_OFFSET);
- tmp &= ~DMA_RB_ENABLE;
- WREG32(DMA_RB_CNTL + DMA0_REGISTER_OFFSET, tmp);
-
- /* dma1 */
- tmp = RREG32(DMA_RB_CNTL + DMA1_REGISTER_OFFSET);
- tmp &= ~DMA_RB_ENABLE;
- WREG32(DMA_RB_CNTL + DMA1_REGISTER_OFFSET, tmp);
-
- /* Reset dma */
- WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA | SOFT_RESET_DMA1);
- RREG32(SRBM_SOFT_RESET);
- udelay(50);
- WREG32(SRBM_SOFT_RESET, 0);
-
/* reset all the gfx blocks */
grbm_reset = (SOFT_RESET_CP |
SOFT_RESET_CB |
@@ -2196,8 +2168,7 @@ static int si_gpu_soft_reset(struct radeon_device *rdev)
udelay(50);
WREG32(GRBM_SOFT_RESET, 0);
(void)RREG32(GRBM_SOFT_RESET);
- /* Wait a little for things to settle down */
- udelay(50);
+
dev_info(rdev->dev, " GRBM_STATUS=0x%08X\n",
RREG32(GRBM_STATUS));
dev_info(rdev->dev, " GRBM_STATUS2=0x%08X\n",
@@ -2208,15 +2179,74 @@ static int si_gpu_soft_reset(struct radeon_device *rdev)
RREG32(GRBM_STATUS_SE1));
dev_info(rdev->dev, " SRBM_STATUS=0x%08X\n",
RREG32(SRBM_STATUS));
+}
+
+static void si_gpu_soft_reset_dma(struct radeon_device *rdev)
+{
+ u32 tmp;
+
+ if (RREG32(DMA_STATUS_REG) & DMA_IDLE)
+ return;
+
+ dev_info(rdev->dev, " DMA_STATUS_REG = 0x%08X\n",
+ RREG32(DMA_STATUS_REG));
+
+ /* dma0 */
+ tmp = RREG32(DMA_RB_CNTL + DMA0_REGISTER_OFFSET);
+ tmp &= ~DMA_RB_ENABLE;
+ WREG32(DMA_RB_CNTL + DMA0_REGISTER_OFFSET, tmp);
+
+ /* dma1 */
+ tmp = RREG32(DMA_RB_CNTL + DMA1_REGISTER_OFFSET);
+ tmp &= ~DMA_RB_ENABLE;
+ WREG32(DMA_RB_CNTL + DMA1_REGISTER_OFFSET, tmp);
+
+ /* Reset dma */
+ WREG32(SRBM_SOFT_RESET, SOFT_RESET_DMA | SOFT_RESET_DMA1);
+ RREG32(SRBM_SOFT_RESET);
+ udelay(50);
+ WREG32(SRBM_SOFT_RESET, 0);
+
dev_info(rdev->dev, " DMA_STATUS_REG = 0x%08X\n",
RREG32(DMA_STATUS_REG));
+}
+
+static int si_gpu_soft_reset(struct radeon_device *rdev, u32 reset_mask)
+{
+ struct evergreen_mc_save save;
+
+ if (reset_mask == 0)
+ return 0;
+
+ dev_info(rdev->dev, "GPU softreset: 0x%08X\n");
+ dev_info(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x%08X\n",
+RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR));
+ dev_info(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x%08X\n",
+RREG32(VM_CONTEXT1_PROTECTION_FAULT_STATUS));
+
+ evergreen_mc_stop(rdev, &save);
+ if (radeon_mc_wait_for_idle(rdev)) {
+ dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
+ }
+
+ if (reset_mask & (RADEON_RESET_GFX | RADEON_RESET_COMPUTE))
+ si_gpu_soft_reset_gfx(rdev);
+
+ if (reset_mask & RADEON_RESET_DMA)
+ si_gpu_soft_reset_dma(rdev);
+
+
