[Bug 59015] New: Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 Priority: medium Bug ID: 59015 Assignee: dri-devel@lists.freedesktop.org Summary: Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages Severity: major Classification: Unclassified OS: Linux (All) Reporter: adam.jorgensen...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 9.0 Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 72495 --> https://bugs.freedesktop.org/attachment.cgi?id=72495&action=edit Major Graphical Corruption Occurring in Windows that are not Maximised I am participating in the Steam Linux Beta and am experiencing graphical corruption as captured in the screenshots attached to this ticket. By starting Steam from the command-line I was able to observe logging messages and noticed that every time a graphical corruption artifact occurs the application outputs the message: "radeon: The kernel rejected CS, see dmesg for more information." An examination of dmesg reveals messages as follows: " [ 2491.179581] radeon :02:00.0: r600_cs_track_validate_cb invalid tiling 6 for 0 (0x08110668) [ 2491.179588] radeon :02:00.0: r600_packet3_check:1913 invalid cmd stream 566 [ 2491.179592] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! " Relevant system info: 1.6ghz Core i7 CPU 8gb DDR3 RAM Radeon HD 4570 with 512mb DDR2 VRAM using open-source XF86 ATI 7.0.0 drivers 10gb free on root, 30+gb free on home Kernel 3.6, X.org 1.12.4, KDE 4.9.4 running with OpenGL Compositing Primary display is 1440x900 laptop LCD, secondary is 24" 1920x1080 LCD -- 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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #1 from Adam Jorgensen --- Created attachment 72496 --> https://bugs.freedesktop.org/attachment.cgi?id=72496&action=edit Less corruption when Steam Windows are maximised When a window is maximised the corruption is a lot less (Since the latest version of the Steam Linux client is gone, except for drop-down menus and pop-out windows (Like the Friend List) which are ALWAYS corrupt) -- 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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #2 from Adam Jorgensen --- Created attachment 72497 --> https://bugs.freedesktop.org/attachment.cgi?id=72497&action=edit Big Screen Mode works perfectly but is slow The Big Screen mode seems to work fine, possibly because it functions as a pure OpenGL application? -- 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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #3 from Adam Jorgensen --- Created attachment 72498 --> https://bugs.freedesktop.org/attachment.cgi?id=72498&action=edit Current Status as of 04/01/2013 The Main Steam Window is now displayed perfectly, but drop-down menus and pop-out windows are ALWAYS corrupt, even when maximised. -- 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] drm/exynos: move finish page flip to a common place
This patch implements the exynos_drm_crtc_finish_pageflip in
exynos_drm_crtc.c. This avoids the duplication of same code
in mixer, fimd and vidi.
Signed-off-by: Rahul Sharma
---
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_crtc.c | 32 +++
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 30 +
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 30 +
drivers/gpu/drm/exynos/exynos_mixer.c| 33 +++-
5 files changed, 38 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index d59a03a..e29f262 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -393,3 +393,35 @@ void exynos_drm_crtc_disable_vblank(struct drm_device
*dev, int crtc)
exynos_drm_fn_encoder(private->crtc[crtc], &crtc,
exynos_drm_disable_vblank);
}
+
+void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int crtc)
+{
+ struct exynos_drm_private *dev_priv = dev->dev_private;
+ struct drm_pending_vblank_event *e, *t;
+ struct timeval now;
+ unsigned long flags;
+
+ DRM_DEBUG_KMS("%s\n", __FILE__);
+
+ spin_lock_irqsave(&dev->event_lock, flags);
+
+ list_for_each_entry_safe(e, t, &dev_priv->pageflip_event_list,
+ base.link) {
+ /* if event's pipe isn't same as crtc then ignore it. */
+ if (crtc != e->pipe)
+ continue;
+
+ do_gettimeofday(&now);
+ e->event.sequence = 0;
+ e->event.tv_sec = now.tv_sec;
+ e->event.tv_usec = now.tv_usec;
+
+ list_move_tail(&e->base.link, &e->base.file_priv->event_list);
+ wake_up_interruptible(&e->base.file_priv->event_wait);
+ drm_vblank_put(dev, crtc);
+ }
+
+ spin_unlock_irqrestore(&dev->event_lock, flags);
+}
+
+
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 8ac3969..3e197e6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -18,5 +18,6 @@
int exynos_drm_crtc_create(struct drm_device *dev, unsigned int nr);
int exynos_drm_crtc_enable_vblank(struct drm_device *dev, int crtc);
void exynos_drm_crtc_disable_vblank(struct drm_device *dev, int crtc);
+void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int crtc);
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bf0d9ba..6dda825 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -663,34 +663,6 @@ static struct exynos_drm_manager fimd_manager = {
.display_ops= &fimd_display_ops,
};
-static void fimd_finish_pageflip(struct drm_device *drm_dev, int crtc)
-{
- struct exynos_drm_private *dev_priv = drm_dev->dev_private;
- struct drm_pending_vblank_event *e, *t;
- struct timeval now;
- unsigned long flags;
-
- spin_lock_irqsave(&drm_dev->event_lock, flags);
-
- list_for_each_entry_safe(e, t, &dev_priv->pageflip_event_list,
- base.link) {
- /* if event's pipe isn't same as crtc then ignore it. */
- if (crtc != e->pipe)
- continue;
-
- do_gettimeofday(&now);
- e->event.sequence = 0;
- e->event.tv_sec = now.tv_sec;
- e->event.tv_usec = now.tv_usec;
-
- list_move_tail(&e->base.link, &e->base.file_priv->event_list);
- wake_up_interruptible(&e->base.file_priv->event_wait);
- drm_vblank_put(drm_dev, crtc);
- }
-
- spin_unlock_irqrestore(&drm_dev->event_lock, flags);
-}
-
static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
{
struct fimd_context *ctx = (struct fimd_context *)dev_id;
@@ -710,7 +682,7 @@ static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
goto out;
drm_handle_vblank(drm_dev, manager->pipe);
- fimd_finish_pageflip(drm_dev, manager->pipe);
+ exynos_drm_crtc_finish_pageflip(drm_dev, manager->pipe);
/* set wait vsync event to zero and wake up queue. */
if (atomic_read(&ctx->wait_vsync_event)) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 3260035..b192308 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -379,34 +379,6 @@ static struct exynos_drm_manager vidi_manager = {
.display_ops= &vidi_display_ops,
};
-static void vidi_finish_pageflip(struct drm_device *drm_dev, i
[PATCH] drm/exynos: move finish page flip to a common place
This patch implements the exynos_drm_crtc_finish_pageflip in
exynos_drm_crtc.c. This avoids the duplication of same code
in mixer, fimd and vidi.
Signed-off-by: Rahul Sharma
Signed-off-by: Stephane Marchesin
---
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_crtc.c | 30 +
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 30 +
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 30 +
drivers/gpu/drm/exynos/exynos_mixer.c| 33 +++-
5 files changed, 36 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index d59a03a..e8894bc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -393,3 +393,33 @@ void exynos_drm_crtc_disable_vblank(struct drm_device
*dev, int crtc)
exynos_drm_fn_encoder(private->crtc[crtc], &crtc,
exynos_drm_disable_vblank);
}
+
+void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int crtc)
+{
+ struct exynos_drm_private *dev_priv = dev->dev_private;
+ struct drm_pending_vblank_event *e, *t;
+ struct timeval now;
+ unsigned long flags;
+
+ DRM_DEBUG_KMS("%s\n", __FILE__);
+
+ spin_lock_irqsave(&dev->event_lock, flags);
+
+ list_for_each_entry_safe(e, t, &dev_priv->pageflip_event_list,
+ base.link) {
+ /* if event's pipe isn't same as crtc then ignore it. */
+ if (crtc != e->pipe)
+ continue;
+
+ do_gettimeofday(&now);
+ e->event.sequence = 0;
+ e->event.tv_sec = now.tv_sec;
+ e->event.tv_usec = now.tv_usec;
+
+ list_move_tail(&e->base.link, &e->base.file_priv->event_list);
+ wake_up_interruptible(&e->base.file_priv->event_wait);
+ drm_vblank_put(dev, crtc);
+ }
+
+ spin_unlock_irqrestore(&dev->event_lock, flags);
+}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 8ac3969..3e197e6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -18,5 +18,6 @@
int exynos_drm_crtc_create(struct drm_device *dev, unsigned int nr);
int exynos_drm_crtc_enable_vblank(struct drm_device *dev, int crtc);
void exynos_drm_crtc_disable_vblank(struct drm_device *dev, int crtc);
+void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int crtc);
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bf0d9ba..6dda825 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -663,34 +663,6 @@ static struct exynos_drm_manager fimd_manager = {
.display_ops= &fimd_display_ops,
};
-static void fimd_finish_pageflip(struct drm_device *drm_dev, int crtc)
-{
- struct exynos_drm_private *dev_priv = drm_dev->dev_private;
- struct drm_pending_vblank_event *e, *t;
- struct timeval now;
- unsigned long flags;
-
- spin_lock_irqsave(&drm_dev->event_lock, flags);
-
- list_for_each_entry_safe(e, t, &dev_priv->pageflip_event_list,
- base.link) {
- /* if event's pipe isn't same as crtc then ignore it. */
- if (crtc != e->pipe)
- continue;
-
- do_gettimeofday(&now);
- e->event.sequence = 0;
- e->event.tv_sec = now.tv_sec;
- e->event.tv_usec = now.tv_usec;
-
- list_move_tail(&e->base.link, &e->base.file_priv->event_list);
- wake_up_interruptible(&e->base.file_priv->event_wait);
- drm_vblank_put(drm_dev, crtc);
- }
-
- spin_unlock_irqrestore(&drm_dev->event_lock, flags);
-}
-
static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
{
struct fimd_context *ctx = (struct fimd_context *)dev_id;
@@ -710,7 +682,7 @@ static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
goto out;
drm_handle_vblank(drm_dev, manager->pipe);
- fimd_finish_pageflip(drm_dev, manager->pipe);
+ exynos_drm_crtc_finish_pageflip(drm_dev, manager->pipe);
/* set wait vsync event to zero and wake up queue. */
if (atomic_read(&ctx->wait_vsync_event)) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 3260035..b192308 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -379,34 +379,6 @@ static struct exynos_drm_manager vidi_manager = {
.display_ops= &vidi_display_ops,
};
-static void vidi_finish_pageflip(
Re: [PATCH] drm/exynos: Add device tree based discovery support for Exynos G2D
Hi Olof,
On Sun, Dec 30, 2012 at 11:57 AM, Olof Johansson wrote:
> Hi,
>
> On Thu, Dec 27, 2012 at 8:00 PM, Ajay Kumar wrote:
>> This patch adds device tree match table for Exynos G2D controller.
>>
>> Signed-off-by: Ajay Kumar
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> index 6ffa076..aa3d2e4 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> @@ -19,6 +19,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -1240,6 +1241,14 @@ static int g2d_resume(struct device *dev)
>>
>> static SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume);
>>
>> +#ifdef CONFIG_OF
>> +static const struct of_device_id exynos_g2d_match[] = {
>> + { .compatible = "samsung,exynos-g2d-41" },
>
> What does -41 signify here?
This driver only supports G2D 4.1 version and not any lower versions of G2D!
>
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, exynos_g2d_match);
>> +#endif
>> +
>> struct platform_driver g2d_driver = {
>> .probe = g2d_probe,
>> .remove = __devexit_p(g2d_remove),
>> @@ -1247,5 +1256,6 @@ struct platform_driver g2d_driver = {
>> .name = "s5p-g2d",
>> .owner = THIS_MODULE,
>> .pm = &g2d_pm_ops,
>> + .of_match_table = of_match_ptr(exynos_g2d_match),
>
> Please provide bindings update, and cc devicetree-discuss for these
> kind of patches.
Ok. I will update with the Documentation for bindings, soon.
>
> -Olof
Thanks and Regards,
Ajay
___
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 Wed, Jan 2, 2013 at 10:37 PM, Rahul Sharma wrote:
> 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.
Yeah, I think it should change in both places. The type doesn't need
to be opaque, IMO.
>>
>>> + 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.
>
Yeah, I noticed that. I had assumed that the mixer could generate any
number of vertical lines from 0 to N where N is an upper bound defined
by the horizontal columns (from the HDMI Resolution Restriction
document). It's surprising to me that it can't generate that
resolution.
At any rate, you must have some information I don't, so it is what it is :)
Sean
> 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
>>>
___
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 Thu, Jan 3, 2013 at 7:12 AM, Deucher, Alexander wrote: >> -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 > Tested the patch on 3.8-rc2 and didn't see any problems. -- Shuah ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
"Hangcheck timer elapsed... GPU hung" in 3.8.0-rc2
I got a crash after a few minutes of running 3.8.0-rc2, was able to switch to a vt and look at dmesg: [ 490.962545] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [ 490.963019] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state [ 492.961446] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [ 492.965613] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged! [ 492.965621] [drm:i915_reset] *ERROR* Failed to reset chip. Previously I was on 3.6.10-2.fc17.x86_64, which didn't have any such problem. dmesg, config, and i915_error_state available from: http://fieldses.org/~bfields/3.8-hang/ --b. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: "Hangcheck timer elapsed... GPU hung" in 3.8.0-rc2
On Thu, Jan 3, 2013 at 3:46 PM, J. Bruce Fields wrote: > I got a crash after a few minutes of running 3.8.0-rc2, was able to > switch to a vt and look at dmesg: > > [ 490.962545] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... > GPU hung > [ 490.963019] [drm] capturing error event; look for more information in > /debug/dri/0/i915_error_state > [ 492.961446] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... > GPU hung > [ 492.965613] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring > wedged! > [ 492.965621] [drm:i915_reset] *ERROR* Failed to reset chip. > > Previously I was on 3.6.10-2.fc17.x86_64, which didn't have any such > problem. I'm not questioning that you haven't seen that error in F17, but we have had quite a few bug reports with similar error messages for a while now. Apparently there are lots of ways GPUs can get hung, so they might be different from what you're seeing. Just wanted to point out that it might not be a new 3.8 change that caused it. josh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: "Hangcheck timer elapsed... GPU hung" in 3.8.0-rc2
On Thu, Jan 03, 2013 at 04:16:24PM -0500, Josh Boyer wrote: > On Thu, Jan 3, 2013 at 3:46 PM, J. Bruce Fields wrote: > > I got a crash after a few minutes of running 3.8.0-rc2, was able to > > switch to a vt and look at dmesg: > > > > [ 490.962545] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer > > elapsed... GPU hung > > [ 490.963019] [drm] capturing error event; look for more information in > > /debug/dri/0/i915_error_state > > [ 492.961446] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer > > elapsed... GPU hung > > [ 492.965613] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring > > wedged! > > [ 492.965621] [drm:i915_reset] *ERROR* Failed to reset chip. > > > > Previously I was on 3.6.10-2.fc17.x86_64, which didn't have any such > > problem. > > I'm not questioning that you haven't seen that error in F17, but we have > had quite a few bug reports with similar error messages for a while now. > Apparently there are lots of ways GPUs can get hung, so they might be > different from what you're seeing. Just wanted to point out that it > might not be a new 3.8 change that caused it. OK, sure. It reproduced very quickly after the upgrade, so I assumed it was a regression. I'm running 3.7.0 now which hasn't shown any problem. I'll try a newer kernel again to see if it's really that easy for me to reproduce. --b. ___ 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 Mr. Figa,
Thanks for reviewing.
On 3 January 2013 16:29, Tomasz Figa wrote:
> 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.
>
Right, exynos_mipi_dsi_blank_mode() only supports FB_BLANK_UNBLANK as
of now, but FB_BLANK_NORMAL will be supported in future.
If not for Exynos, i think it will be need for other SoCs which
support FB_BLANK_UNBLANK and FB_BLANK_NORMAL.
> 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.
>
You are right, as of now Exynos MIPI DSI Panels are NOT using these
callbacks, but as you mentioned we will need frame done status
monitoring anyways, so i included these callbacks here. Will check, if
we can implement any better method.
> Best regards,
> --
> Tomasz Figa
> Samsung Poland R&D Center
> SW Solution Development, Linux Platform
>
--
Thanks and Regards
Vikas Sajjan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x
On 21.12.2012 23:19, Stephen Warren wrote: > I see the situation more like: > > * There's host1x hardware. > > * There's a low-level driver just for host1x itself; the host1x driver. > > * There's a high-level driver for the entire host1x complex of devices. > That is tegradrm. There may be more high-level drivers in the future > (e.g. v4l2 camera driver if it needs to aggregate a bunch of host1x > sub-devices liek tegradrm does). > > * The presence of the host1x DT node logically implies that both the two > drivers in the previous two points should be instantiated. > > * Linux instantiates a single device per DT node. > > * So, it's host1x's responsibility to instantiate the other device(s). I > think it's reasonable for the host1x driver to know exactly what > features the host1x HW complex supports; raw host1x access being one, > and the higher level concept of a tegradrm being another. So, it's > reasonable for host1x to trigger the instantiation of tegradrm. > > * If DRM core didn't stomp on the device object's drvdata (or whichever > field it is), I would recommend not creating a dummy device at all, but > rather having the host1x driver directly implement multiple driver > interfaces. There are many examples like this already in the kernel, > e.g. combined GPIO+IRQ driver, combined GPIO+IRQ+pinctrl driver, etc. We had a phone call with Stephen yesterday, and I finally understood why unbroken chain from DT to tegra-drm is important. The goals are to be able to modprobe tegra-drm without ill effects, and to auto-load tegra-drm module. I had been chasing a totally different goal. Sorry about all the churn. I think we have now two ways to go forward with cons and pros: 1) Keep host1x and tegra-drm as separate driver + Code almost done - we need dummy device and dummy driver - extra code and API when host1x creates dummy device and its passed to tegra-drm - tegra-drm device would need to be a child of host1x device. Having virtual and real devices as host1x children sounds weird. 2) Merge host1x and tegra-drm into one module. drm is a subcomponent, and whatever other personalities we wish would also be subcomponents of host1x. host1x calls tegra-drm directly to handle preparation for drm initialization. As they're in the same module, circular dependency is ok. + Simpler conceptually (no dummy device/driver) + Less code - Proposal doesn't yet exist Thierry, what do you think? I'd prefer option 2, as that keeps things simple and still fulfills the requirements. We probably would redo the patch "Remove redundant host1x" to actually move drm under host1x, and adds calls from host1x to parse_dt() directly. We'd probably leave the code otherwise mostly as it is now, so we'll drop whatever modifications we've done so far in my proposals. You can later pick up some things from our proposals if you want, but it's then up to you. We could also later think about generalizing some of the list management to belong to host1x, but that'd be a follow-up and we can decide that later. Terje ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: fimd: modify condition in fimd resume
Hi,
Please review this patch.
Regards,
Prathyush
On Thu, Dec 27, 2012 at 5:10 PM, Prathyush K wrote:
> If fimd is runtime suspended (by DPMS OFF), fimd_suspend does not
> call fimd_activate(false) and just returns. Similarily the check in
> fimd_resume should not resume if previously runtime_suspended.
> Instead the existing check does the opposite. So if fimd was not
> runtime suspended, suspend will turn off fimd but resume will not turn
> it on. This patch fixes this issue by reversing the condition.
>
> Signed-off-by: Prathyush K
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bf0d9ba..9accd466 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -1046,7 +1046,7 @@ static int fimd_resume(struct device *dev)
> * of pm runtime would still be 1 so in this case, fimd driver
> * should be on directly not drawing on pm runtime interface.
> */
> - if (pm_runtime_suspended(dev)) {
> + if (!pm_runtime_suspended(dev)) {
> int ret;
>
> ret = fimd_activate(ctx, true);
> --
> 1.8.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
2013-01-04 08:40 keltezéssel, Borislav Petkov írta:
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;
How about any other odd numbers? Like 0xFFFB, or 0x0003?
They will get passed as is after this change, no? Shouldn't they
be also fixed? Something like this below?
if (cur_size_in_dw & 0x0001)
cur_size_in_dw &= ~1;
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
Dear Paul, On Tue, 01 Jan 2013 04:43:39 +0100 Paul Menzel wrote: > So if nobody has a great idea, the roadmap looks as follows. Revert the > patch, find out why the graphics driver chokes on the reduced blanking > (report a bug) and commit the patch again. I reported a bug at: https://bugzilla.kernel.org/show_bug.cgi?id=52281 Regards, Flo signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 Andreas Boll changed: What|Removed |Added Attachment #72495|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 Andreas Boll changed: What|Removed |Added Attachment #72497|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 Andreas Boll changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Drivers/Gallium/r600 --- Comment #4 from Andreas Boll --- Please attach your xorg log and the outputs from dmesg and glxinfo. -- 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 0/2] drm/exynos: add support for more resolutions to exynos5
Please Abandon this patch set. Same code is posted under new patch set at http://comments.gmane.org/gmane.comp.video.dri.devel/78392 regards, Rahul Sharma On Tue, Dec 18, 2012 at 7:42 PM, Rahul Sharma wrote: > This patch set adds support for more resolutions and refresh rates to Samsung > Exynos5 SoC series which contains hdmi transmitter (hdmi v1.4a compliant). > > Given resoltuion will be supported or not, is decided by two factors: > 1) Corresponding pixel clock is supported by hdmi PHY. > 2) Mixer can generate the correspoding video timing. > > All standard resolutions and pixel rate combinations are verified for the > above > limitations and are listed in hdmi driver. Any standard resolution supported > by > the monitor/tv will be comapared against this list. > > We got 640x480, 720x576 and 1680x1050 and few more refresh rates enabled as a > result to this exercise. > > Rahul Sharma (2): > drm/exynos: hdmi: add support for extra permissable resolutions > drm/exynos: mixer: add support for extra resolutions > > drivers/gpu/drm/exynos/exynos_hdmi.c | 1004 > - > drivers/gpu/drm/exynos/exynos_mixer.c |8 +- > 2 files changed, 358 insertions(+), 654 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #5 from Alex Deucher --- I'm assuming you are using mesa 9.x or newer based on the version info in the bug header. Can you confirm? xf86-video-ati 7.0.0 requires mesa 9.x. Also, if the steam client is a 32-bit application and you are running a 64-bit distro, you will need to make sure your 32-bit 3D driver is up to date. I suspect you have an out of date 32-bit 3D driver. -- 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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #6 from Adam Jorgensen --- Created attachment 72509 --> https://bugs.freedesktop.org/attachment.cgi?id=72509&action=edit X.org log My X.org log file -- 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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #7 from Adam Jorgensen --- Created attachment 72510 --> https://bugs.freedesktop.org/attachment.cgi?id=72510&action=edit dmesg output Output from dmesg after running Steam and triggering corruption -- 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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #8 from Adam Jorgensen --- Created attachment 72511 --> https://bugs.freedesktop.org/attachment.cgi?id=72511&action=edit glxinfo output Output from glxinfo -- 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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #9 from Adam Jorgensen --- (In reply to comment #5) > I'm assuming you are using mesa 9.x or newer based on the version info in > the bug header. Can you confirm? xf86-video-ati 7.0.0 requires mesa 9.x. > Also, if the steam client is a 32-bit application and you are running a > 64-bit distro, you will need to make sure your 32-bit 3D driver is up to > date. I suspect you have an out of date 32-bit 3D driver. I can confirm that I am using Mesa 9.0.1 in conjunction with xf86-video-ati 7.0.0. I *thought* I was running Steam as a 64-bit application but based on the lack of an "ubuntu12_64" directory in my ~/.local/share/Steam directory it seems likely that my Steam installation is actually a 32-bit one. I am using the latest emul-x86 libs (I'm running Sabayon Linux) but I also have a separate 32-bit chroot for work purposes. I will try updating the chroot environment (Since it's set up with the same distro) and installing Steam their and testing it in that environment... -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Fri, Jan 4, 2013 at 6:16 AM, Boszormenyi Zoltan wrote:
> 2013-01-04 08:40 keltezéssel, Borislav Petkov írta:
>
>> 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;
>
>
> How about any other odd numbers? Like 0xFFFB, or 0x0003?
> They will get passed as is after this change, no? Shouldn't they
> be also fixed? Something like this below?
>
> if (cur_size_in_dw & 0x0001)
>cur_size_in_dw &= ~1;
This function only deals with pages so they will always be even.
Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: split r6xx and r7xx copy_dma functions
From: Alex Deucher
- r6xx actually uses a slightly different packet format,
although both formats seem to work ok.
- r7xx doesn't have the count multiple of 2 limitation.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c| 10 ++--
drivers/gpu/drm/radeon/radeon_asic.c |4 +-
drivers/gpu/drm/radeon/radeon_asic.h |4 ++
drivers/gpu/drm/radeon/rv770.c | 74 ++
4 files changed, 85 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 923f936..537e259 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2646,7 +2646,7 @@ int r600_copy_blit(struct radeon_device *rdev,
* @num_gpu_pages: number of GPU pages to xfer
* @fence: radeon fence object
*
- * Copy GPU paging using the DMA engine (r6xx-r7xx).
+ * Copy GPU paging using the DMA engine (r6xx).
* Used by the radeon ttm implementation to move pages if
* registered as the asic copy callback.
*/
@@ -2669,8 +2669,8 @@ int r600_copy_dma(struct radeon_device *rdev,
}
size_in_dw = (num_gpu_pages << RADEON_GPU_PAGE_SHIFT) / 4;
- num_loops = DIV_ROUND_UP(size_in_dw, 0x);
- r = radeon_ring_lock(rdev, ring, num_loops * 5 + 8);
+ num_loops = DIV_ROUND_UP(size_in_dw, 0xFFFE);
+ r = radeon_ring_lock(rdev, ring, num_loops * 4 + 8);
if (r) {
DRM_ERROR("radeon: moving bo (%d).\n", r);
radeon_semaphore_free(rdev, &sem, NULL);
@@ -2693,8 +2693,8 @@ int r600_copy_dma(struct radeon_device *rdev,
radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0, 0,
cur_size_in_dw));
radeon_ring_write(ring, dst_offset & 0xfffc);
radeon_ring_write(ring, src_offset & 0xfffc);
- radeon_ring_write(ring, upper_32_bits(dst_offset) & 0xff);
- radeon_ring_write(ring, upper_32_bits(src_offset) & 0xff);
+ radeon_ring_write(ring, (((upper_32_bits(dst_offset) & 0xff) <<
16) |
+(upper_32_bits(src_offset) & 0xff)));
src_offset += cur_size_in_dw * 4;
dst_offset += cur_size_in_dw * 4;
}
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 596bcbe..9056faf 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1140,9 +1140,9 @@ static struct radeon_asic rv770_asic = {
.copy = {
.blit = &r600_copy_blit,
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
- .dma = &r600_copy_dma,
+ .dma = &rv770_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
+ .copy = &rv770_copy_dma,
.copy_ring_index = R600_RING_TYPE_DMA_INDEX,
},
.surface = {
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 5f4882c..15d70e6 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -403,6 +403,10 @@ u32 rv770_page_flip(struct radeon_device *rdev, int crtc,
u64 crtc_base);
void r700_vram_gtt_location(struct radeon_device *rdev, struct radeon_mc *mc);
void r700_cp_stop(struct radeon_device *rdev);
void r700_cp_fini(struct radeon_device *rdev);
+int rv770_copy_dma(struct radeon_device *rdev,
+ uint64_t src_offset, uint64_t dst_offset,
+ unsigned num_gpu_pages,
+ struct radeon_fence **fence);
/*
* evergreen
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 87c979c..1b2444f 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -887,6 +887,80 @@ static int rv770_mc_init(struct radeon_device *rdev)
return 0;
}
+/**
+ * rv770_copy_dma - copy pages using the DMA engine
+ *
+ * @rdev: radeon_device pointer
+ * @src_offset: src GPU address
+ * @dst_offset: dst GPU address
+ * @num_gpu_pages: number of GPU pages to xfer
+ * @fence: radeon fence object
+ *
+ * Copy GPU paging using the DMA engine (r7xx).
+ * Used by the radeon ttm implementation to move pages if
+ * registered as the asic copy callback.
+ */
+int rv770_copy_dma(struct radeon_device *rdev,
+ uint64_t src_offset, uint64_t dst_offset,
+ unsigned num_gpu_pages,
+ struct radeon_fence **fence)
+{
+ struct radeon_semaphore *sem = NULL;
+ int ring_index = rdev->asic->copy.dma_ring_index;
+ struct radeon_ring *ring = &rdev->ring[ring_index];
+ u32 size_in_dw, cur_size_in_dw;
+ int i, num_loops;
+ int r = 0;
+
+ r = radeon_semaphore_create(rdev, &sem);
+ if (r) {
+ DRM_ERROR("radeon: moving bo (%d).\n", r);
+ return r;
+ }
+
+ size_in_dw = (num_gpu_pages << RADEON_GPU_PAGE
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #23 from Alex Deucher --- (In reply to comment #22) > "Is this a regression? Does it happen with older versions of mesa or > kernel?" > Yes. Previous kernel 3.7 doesn't show this problem. Can you bisect? Is it the same commit Thomas landed on or another one? -- 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: [RFC PATCH] drm/radeon: increase d3 delay to 20 ms during switcheroo poweron
On Wed, Jan 2, 2013 at 10:38 AM, Maarten Lankhorst
wrote:
> vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI
> configuration space is not restored correctly, resulting in MSI not working
> after switch.
>
> Only useful item in dmesg is:
>
> [ 33.922807] radeon :01:00.0: Refused to change power state, currently
> in D3
>
> I did some testing, dumping the difference in ms between first succesful
> switch
> from D3 to D0, and it seems that there is slightly more than 20 ms difference
> when
> the device is re-enabled through vga-switcheroo.
>
> So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not
> working
> on my system after switcheroo-ing.
I guess if it fixes it... Has anyone seen similar problems on non-mac
systems? What is the delay normally set to? It seems pretty
innocuous other than potentially adding a little extra latency. Do
you think it makes sense to make it more like a quirk and only apply
it to problematic systems or just apply across the board?
Alex
>
> Signed-off-by: Maarten Lankhorst
>
> ---
>
> This is a RFC patch since I feel what I'm doing is done in a hackish way,
> but it seems only the D3->D0 transition during switcheroo enable is affected,
> other transitions like suspend/resume and switcheroo poweroff seem unaffected.
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 5515921..8816958 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -910,10 +910,19 @@ static void radeon_switcheroo_set_state(struct pci_dev
> *pdev, enum vga_switchero
> struct drm_device *dev = pci_get_drvdata(pdev);
> pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
> if (state == VGA_SWITCHEROO_ON) {
> + unsigned d3_delay = dev->pdev->d3_delay;
> +
> printk(KERN_INFO "radeon: switched on\n");
> /* don't suspend or resume card normally */
> dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
> +
> + if (dev->pdev->d3_delay < 20)
> + dev->pdev->d3_delay = 20;
> +
> radeon_resume_kms(dev);
> +
> + dev->pdev->d3_delay = d3_delay;
> +
> dev->switch_power_state = DRM_SWITCH_POWER_ON;
> drm_kms_helper_poll_enable(dev);
> } else {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon CS parser refactoring
On Wed, Jan 2, 2013 at 6:27 PM, Ilija Hadzic wrote: > 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. > > The patches have been rebased to the current state of Dave's drm-next > branch. Looks good to me. Nice clean up. As long as there are no regressions with UMS, consider them applied. Thanks! Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/exynos: implement display-mode-check callback in mixer driver
On Fri, Jan 4, 2013 at 8:53 AM, Rahul Sharma wrote:
> This patch adds the implementation of check_mode callback in the mixer
s/check_mode/check_timing/
> 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 | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 21db895..c1f2e7a 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -810,6 +810,29 @@ static void mixer_win_disable(void *ctx, int win)
> mixer_ctx->win_data[win].enabled = false;
> }
>
> +int mixer_check_timing(void *ctx, struct fb_videomode *timing)
> +{
> + struct mixer_context *mixer_ctx = ctx;
> + unsigned int w, h;
xres and yres are defined as u32 in fb_videomode
> +
> + w = timing->xres;
> + h = timing->yres;
> +
> + DRM_DEBUG_KMS("%s : xres=%d, yres=%d, refresh=%d, intl=%d\n",
> + __func__, timing->xres, timing->yres,
> + timing->refresh, (timing->vmode &
> + FB_VMODE_INTERLACED) ? true : false);
> +
> + if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16)
> + return 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;
> +
> + return -EINVAL;
> +}
> static void mixer_wait_for_vblank(void *ctx)
> {
> struct mixer_context *mixer_ctx = ctx;
> @@ -947,6 +970,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_timing = mixer_check_timing,
> };
>
> /* for pageflip event */
> --
> 1.8.0
>
___
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 #15 from Konrad Rzeszutek Wilk 2013-01-04 16:00:10 --- Let me ask again: Does it work properly under baremetal? -- 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: [RFC PATCH] drm/radeon: increase d3 delay to 20 ms during switcheroo poweron
Op 04-01-13 16:34, Alex Deucher schreef:
> On Wed, Jan 2, 2013 at 10:38 AM, Maarten Lankhorst
> wrote:
>> vga-switcheroo with apple-gmux does not switch correctly on my system. The
>> PCI
>> configuration space is not restored correctly, resulting in MSI not working
>> after switch.
>>
>> Only useful item in dmesg is:
>>
>> [ 33.922807] radeon :01:00.0: Refused to change power state, currently
>> in D3
>>
>> I did some testing, dumping the difference in ms between first succesful
>> switch
>> from D3 to D0, and it seems that there is slightly more than 20 ms
>> difference when
>> the device is re-enabled through vga-switcheroo.
>>
>> So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not
>> working
>> on my system after switcheroo-ing.
> I guess if it fixes it... Has anyone seen similar problems on non-mac
> systems? What is the delay normally set to? It seems pretty
It's normally set to PCI_PM_D3_WAIT, 10 ms.
> innocuous other than potentially adding a little extra latency. Do
> you think it makes sense to make it more like a quirk and only apply
> it to problematic systems or just apply across the board?
Quirking would be fine. Since there is a message in dmesg it would
be easy to identify when others hit the same issue, in which case
we could enable it all the time.
>> Signed-off-by: Maarten Lankhorst
>>
>> ---
>>
>> This is a RFC patch since I feel what I'm doing is done in a hackish way,
>> but it seems only the D3->D0 transition during switcheroo enable is affected,
>> other transitions like suspend/resume and switcheroo poweroff seem
>> unaffected.
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
>> b/drivers/gpu/drm/radeon/radeon_device.c
>> index 5515921..8816958 100644
>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>> @@ -910,10 +910,19 @@ static void radeon_switcheroo_set_state(struct pci_dev
>> *pdev, enum vga_switchero
>> struct drm_device *dev = pci_get_drvdata(pdev);
>> pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
>> if (state == VGA_SWITCHEROO_ON) {
>> + unsigned d3_delay = dev->pdev->d3_delay;
>> +
>> printk(KERN_INFO "radeon: switched on\n");
>> /* don't suspend or resume card normally */
>> dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
>> +
>> + if (dev->pdev->d3_delay < 20)
>> + dev->pdev->d3_delay = 20;
>> +
>> radeon_resume_kms(dev);
>> +
>> + dev->pdev->d3_delay = d3_delay;
>> +
>> dev->switch_power_state = DRM_SWITCH_POWER_ON;
>> drm_kms_helper_poll_enable(dev);
>> } else {
>>
___
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 #16 from Fernando Chaves 2013-01-04 16:35:55 --- I'm sorry Konrad, but I don't know exactly what you mean when you say "run on bare metal". -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42162] Display not enabled on resume (HP DV6)
https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #8 from Johan Brannlund --- Resume still doesn't work with kernel 3.8-rc2. However, I now get a hard lockup on resume. Log attached. -- 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 42162] Display not enabled on resume (HP DV6)
https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #9 from Johan Brannlund --- Created attachment 72514 --> https://bugs.freedesktop.org/attachment.cgi?id=72514&action=edit Suspend/resume log, kernel 3.8-rc2 -- 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 42162] Display not enabled on resume (HP DV6)
https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #10 from Alex Deucher --- (In reply to comment #8) > Resume still doesn't work with kernel 3.8-rc2. However, I now get a hard > lockup on resume. Log attached. Can you bisect to see what caused the hard lock? -- 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 42162] Display not enabled on resume (HP DV6)
https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #11 from Johan Brannlund --- I'll try bisecting when I have some spare time, but it's probably going to be a few weeks. -- 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 42162] Display not enabled on resume (HP DV6)
https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #12 from Johan Brannlund --- Correction: it's *not* a hard lockup - the laptop still responds to ping. It may just be that the keyboard is not working after resume (or even that I mistyped something when trying to reboot it by typing blind). -- 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] drm/radeon: fix DMA CS parser for r6xx linear copy packet
From: Alex Deucher
Was using the r7xx format.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600_cs.c | 31 ++-
1 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 9ea13d0..03191a5 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2677,16 +2677,29 @@ int r600_dma_cs_parse(struct radeon_cs_parser *p)
}
p->idx += 7;
} else {
- src_offset = ib[idx+2];
- src_offset |= ((u64)(ib[idx+4] & 0xff)) << 32;
- dst_offset = ib[idx+1];
- dst_offset |= ((u64)(ib[idx+3] & 0xff)) << 32;
+ if (p->family >= CHIP_RV770) {
+ src_offset = ib[idx+2];
+ src_offset |= ((u64)(ib[idx+4] & 0xff))
<< 32;
+ dst_offset = ib[idx+1];
+ dst_offset |= ((u64)(ib[idx+3] & 0xff))
<< 32;
- ib[idx+1] += (u32)(dst_reloc->lobj.gpu_offset &
0xfffc);
- ib[idx+2] += (u32)(src_reloc->lobj.gpu_offset &
0xfffc);
- ib[idx+3] +=
upper_32_bits(dst_reloc->lobj.gpu_offset) & 0xff;
- ib[idx+4] +=
upper_32_bits(src_reloc->lobj.gpu_offset) & 0xff;
- p->idx += 5;
+ ib[idx+1] +=
(u32)(dst_reloc->lobj.gpu_offset & 0xfffc);
+ ib[idx+2] +=
(u32)(src_reloc->lobj.gpu_offset & 0xfffc);
+ ib[idx+3] +=
upper_32_bits(dst_reloc->lobj.gpu_offset) & 0xff;
+ ib[idx+4] +=
upper_32_bits(src_reloc->lobj.gpu_offset) & 0xff;
+ p->idx += 5;
+ } else {
+ src_offset = ib[idx+2];
+ src_offset |= ((u64)(ib[idx+3] & 0xff))
<< 32;
+ dst_offset = ib[idx+1];
+ dst_offset |= ((u64)(ib[idx+3] &
0xff)) << 16;
+
+ ib[idx+1] +=
(u32)(dst_reloc->lobj.gpu_offset & 0xfffc);
+ ib[idx+2] +=
(u32)(src_reloc->lobj.gpu_offset & 0xfffc);
+ ib[idx+3] +=
upper_32_bits(src_reloc->lobj.gpu_offset) & 0xff;
+ ib[idx+3] +=
(upper_32_bits(dst_reloc->lobj.gpu_offset) & 0xff) << 16;
+ p->idx += 4;
+ }
}
if ((src_offset + (count * 4)) >
radeon_bo_size(src_reloc->robj)) {
dev_warn(p->dev, "DMA copy src buffer too small
(%llu %lu)\n",
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50941] Kernel does not compile
https://bugzilla.kernel.org/show_bug.cgi?id=50941 --- Comment #3 from JP Pozzi 2013-01-04 17:56:28 --- Hello, I try it but ACPI_VIDEO is reset to "m" whenever you "make menuconfig" or compile the kernel. I can't find what other parameters are to be set to "y". At least the kernel compile but I have some problems, after one or two hours the screen (or keyboard ?) get stuck and I have to connect from another machine to stop properly the system. I get the same kind of "screen blocked" with the 3.7.1 kernel. I try it but ACPI_VIDEO is reset to "m" whenever you "make menuconfig" or compile the kernel. I can't find what other parameters are to be set to "y". It is the same for 3.7.1 kernel. Regards JP P -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56405] Distorted graphics on Radeon HD 6620G
https://bugs.freedesktop.org/show_bug.cgi?id=56405 Michael Dressel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #54 from Michael Dressel --- The patch works for me, as alread reported. I have not tried a kernel including the patch. But I still think this bug is fixed. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm_pcie_get_speed_cap_mask() cleanups
These are minor cleanups for drm_pcie_get_speed_cap_mask() to use standard #defines and PCIe capability accessors. They depend on a pci_regs.h change (130f1b8f35) that appeared in v3.8-rc2. They don't address the issue of DRM devices directly below a host bridge that doesn't appear as a PCI device (the issue Lucas has been working on). I'm a little skeptical about the premise of drm_pcie_get_speed_cap_mask() to begin with. Link speed seems like something fairly generic that should be handled in the core, not in individual drivers. Sec 6.11, "Link Speed Management", in the PCIe 3.0 spec seems relevant and suggests that the hardware should automatically use the highest speed supported by both ends of the link unless software sets a lower maximum via Target Link Speed. But I can't match up the code, e.g., evergreen_pcie_gen2_enable(), to anything in the generic PCIe specs, so maybe this driver code is essentially quirks for misbehaving hardware? --- Bjorn Helgaas (3): drm/pci: Use the standard #defines for PCIe Link Capability bits drm/pci: Set all supported speeds in speed cap mask for pre-3.0 devices drm/pci: Use PCI Express Capability accessors drivers/gpu/drm/drm_pci.c | 27 --- 1 files changed, 8 insertions(+), 19 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/pci: Use the standard #defines for PCIe Link Capability bits
Use the standard #defines rather than bare numbers for the PCIe Link
Capabilities speed bits.
Signed-off-by: Bjorn Helgaas
---
drivers/gpu/drm/drm_pci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 754bc96..11c8add 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -504,9 +504,9 @@ int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32
*mask)
if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
*mask |= DRM_PCIE_SPEED_80;
} else {
- if (lnkcap & 1)
+ if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
*mask |= DRM_PCIE_SPEED_25;
- if (lnkcap & 2)
+ if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
*mask |= DRM_PCIE_SPEED_50;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/pci: Set all supported speeds in speed cap mask for pre-3.0 devices
For devices that conform to PCIe r3.0 and have a Link Capabilities 2
register, we test and report every bit in the Supported Link Speeds Vector
field. For a device that supports both 2.5GT/s and 5.0GT/s, we set both
DRM_PCIE_SPEED_25 and DRM_PCIE_SPEED_50 in the returned mask.
For pre-r3.0 devices, the Link Capabilities 0010b encoding
(PCI_EXP_LNKCAP_SLS_5_0GB) means that both 5.0GT/s and 2.5GT/s are
supported, so set both DRM_PCIE_SPEED_25 and DRM_PCIE_SPEED_50 in this
case as well.
Signed-off-by: Bjorn Helgaas
---
drivers/gpu/drm/drm_pci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 11c8add..50e26f2 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -507,7 +507,7 @@ int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32
*mask)
if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
*mask |= DRM_PCIE_SPEED_25;
if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
- *mask |= DRM_PCIE_SPEED_50;
+ *mask |= (DRM_PCIE_SPEED_25 | DRM_PCIE_SPEED_50);
}
DRM_INFO("probing gen 2 caps for device %x:%x = %x/%x\n", root->vendor,
root->device, lnkcap, lnkcap2);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/pci: Use PCI Express Capability accessors
Use PCI Express Capability access functions to simplify this code a bit.
For non-PCIe devices or pre-PCIe 3.0 devices that don't implement the Link
Capabilities 2 register, pcie_capability_read_dword() reads a zero.
Since we're only testing whether the bits we care about are set, there's no
need to mask out the other bits we *don't* care about.
Signed-off-by: Bjorn Helgaas
---
drivers/gpu/drm/drm_pci.c | 21 +
1 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 50e26f2..86102a0 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -469,41 +469,30 @@ EXPORT_SYMBOL(drm_pci_exit);
int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 *mask)
{
struct pci_dev *root;
- int pos;
- u32 lnkcap = 0, lnkcap2 = 0;
+ u32 lnkcap, lnkcap2;
*mask = 0;
if (!dev->pdev)
return -EINVAL;
- if (!pci_is_pcie(dev->pdev))
- return -EINVAL;
-
root = dev->pdev->bus->self;
- pos = pci_pcie_cap(root);
- if (!pos)
- return -EINVAL;
-
/* we've been informed via and serverworks don't make the cut */
if (root->vendor == PCI_VENDOR_ID_VIA ||
root->vendor == PCI_VENDOR_ID_SERVERWORKS)
return -EINVAL;
- pci_read_config_dword(root, pos + PCI_EXP_LNKCAP, &lnkcap);
- pci_read_config_dword(root, pos + PCI_EXP_LNKCAP2, &lnkcap2);
-
- lnkcap &= PCI_EXP_LNKCAP_SLS;
- lnkcap2 &= 0xfe;
+ pcie_capability_read_dword(root, PCI_EXP_LNKCAP, &lnkcap);
+ pcie_capability_read_dword(root, PCI_EXP_LNKCAP2, &lnkcap2);
- if (lnkcap2) { /* PCIE GEN 3.0 */
+ if (lnkcap2) { /* PCIe r3.0-compliant */
if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_2_5GB)
*mask |= DRM_PCIE_SPEED_25;
if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_5_0GB)
*mask |= DRM_PCIE_SPEED_50;
if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
*mask |= DRM_PCIE_SPEED_80;
- } else {
+ } else {/* pre-r3.0 */
if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
*mask |= DRM_PCIE_SPEED_25;
if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm_pcie_get_speed_cap_mask() cleanups
On Fri, Jan 4, 2013 at 2:10 PM, Bjorn Helgaas wrote: > These are minor cleanups for drm_pcie_get_speed_cap_mask() to use > standard #defines and PCIe capability accessors. They depend on > a pci_regs.h change (130f1b8f35) that appeared in v3.8-rc2. > > They don't address the issue of DRM devices directly below a host > bridge that doesn't appear as a PCI device (the issue Lucas has > been working on). > > I'm a little skeptical about the premise of drm_pcie_get_speed_cap_mask() > to begin with. Link speed seems like something fairly generic that should > be handled in the core, not in individual drivers. Sec 6.11, "Link Speed > Management", in the PCIe 3.0 spec seems relevant and suggests that the > hardware should automatically use the highest speed supported by both ends > of the link unless software sets a lower maximum via Target Link Speed. > > But I can't match up the code, e.g., evergreen_pcie_gen2_enable(), to > anything in the generic PCIe specs, so maybe this driver code is > essentially quirks for misbehaving hardware? At least for radeon, there is an asic specific sequence required to change the PCIE gen link speed at runtime. Depending on the bios, the board may come up in the highest mode supported by either side or something lower. If it comes up at a lower speed than the hardware is capable of, we can increase it in the driver to improve performance. Additionally, you can select a lower link speed to save power. I don't know if there is a generic non-asic specific way to change the link speed of a device at runtime, but I'm not really a PCI expert. Alex ___ 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 #17 from Konrad Rzeszutek Wilk 2013-01-04 19:26:35 --- (In reply to comment #16) > I'm sorry Konrad, but I don't know exactly what you mean when you say "run on > bare metal". without Xen. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board
https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #18 from Fernando Chaves 2013-01-04 19:34:06 --- Yes, everything works at 100% without Xen, both CLI and Xorg, even in CentOS. -- 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: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x
On 01/04/2013 03:09 AM, Terje Bergström wrote: ... > I think we have now two ways to go forward with cons and pros: > 1) Keep host1x and tegra-drm as separate driver >+ Code almost done >- we need dummy device and dummy driver >- extra code and API when host1x creates dummy device and its passed > to tegra-drm Just to play devil's advocate: I suspect that's only a few lines of code. >- tegra-drm device would need to be a child of host1x device. Having > virtual and real devices as host1x children sounds weird. And I doubt that would cause problems. > 2) Merge host1x and tegra-drm into one module. drm is a subcomponent, > and whatever other personalities we wish would also be subcomponents of > host1x. host1x calls tegra-drm directly to handle preparation for drm > initialization. As they're in the same module, circular dependency is ok. >+ Simpler conceptually (no dummy device/driver) >+ Less code >- Proposal doesn't yet exist But that said, I agree this approach would be very reasonable; it seems to me that host1x really is the main HW behind a DRM driver or a V4L2 driver or ... As such, it seems quite reasonable for a single struct device to exist that represents host1x, and for the driver for that device to register both a DRM and a V4L2 driver etc. The code could physically be organized into separate modules, and under different Kconfig options for configurability etc. But either way, I'll let you (Thierry and Terje) work out which way to go. ___ 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? I did some tests with UMS and shuffled a number of cards. As I feared, I ran into a number of unrelated problems, but in each case I have seen identical beahvior between the kernel with my patches and without. So as far as I can tell, my patches do not introduce regressions in legacy modes, althugh I am not sure about the coverage. Also, in one test, I think I have hit a genuine bug in ATI DDX (explained below). Below I describe what I saw with each card family. Maybe for some test cases I am missing some "magic" option in xorg.conf or maybe what I am seeing (mostly reduced feature set) is expected in UMS. * With an NI card (TURKS, HD6570 card), Xorg just plain tells me that the card is supported in KMS only mode. So, I guess, that's it for that card. * A test with Evergreen (CEDAR) card works in UMS mode, but I can't get 3D acceleration. I see these messages in Xorg log file: [37.024] (II) RADEON(0): No DRI yet on Evergreen . . [37.364] (II) AIGLX: Screen 0 is not DRI2 capable [37.364] (II) AIGLX: Screen 0 is not DRI capable [37.664] (II) AIGLX: Loaded and initialized swrast [37.664] (II) GLX: Initialized DRISWRAST GL provider for screen 0 Sounds like just a "property" of UMS to me, but I am not sure. Nevertheless, the behavior with and without my kernel patches is identical. Still, 2D copying should still be exercising the CS parser, so there is some test coverage here. * A test with an R7xx card (RV730, E4690 card) results in a segfault in DDX. Again, this is irrespective of my kernel patches, so I believe that the bug has been there for a while and that it's in userland. The crash occurs in r600_set_render_target() function and what causes it is corrupted cb_conf->surface pointer. When the crash occurs it has a value of 0x1, which doesn't look like something that would live in .bss, .data or come from the heap. I didn't try other R6xx cards, but I suspect that they may have the same problem because they share the code in DDX. I don't know if UMS DDX will be maintained going forward, so I don't know if it makes sense to open a bug for this. BTW, DDX I am testing this with is 6.14.6 * A test with R300 card (Radeon X300 card) works (again identically with and without my patches), but again without 3D acceleration. So it's similar result and comment as with the Evergreen test, though relevant messages in Xorg log file are slightly different: [35.630] (EE) AIGLX error: r300 does not export required DRI extension [35.630] (EE) AIGLX: reverting to software rendering [35.915] (II) AIGLX: Loaded and initialized swrast [35.915] (II) GLX: Initialized DRISWRAST GL provider for screen 0 Again, I don't know if this is just the way things are in UMS mode or if there is some configuration magic I need to do. So at this point I'd say that I have not seen anything that would indicate a regression in legacy mode, although the limitations I have hit make the tests more limited that I thought they would be (and KMS I tested quite a bit, so I am confident there). thanks, Ilija ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon CS parser refactoring
On Fri, Jan 4, 2013 at 5:57 PM, Ilija Hadzic wrote: > > 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? >> > > I did some tests with UMS and shuffled a number of cards. As I feared, I ran > into a number of unrelated problems, but in each case I have seen identical > beahvior between the kernel with my patches and without. So as far as I can > tell, my patches do not introduce regressions in legacy modes, althugh I am > not sure about the coverage. > > Also, in one test, I think I have hit a genuine bug in ATI DDX (explained > below). > > Below I describe what I saw with each card family. Maybe for some test cases > I am missing some "magic" option in xorg.conf or maybe what I am seeing > (mostly reduced feature set) is expected in UMS. > > * With an NI card (TURKS, HD6570 card), Xorg just plain tells me that the > card is supported in KMS only mode. So, I guess, that's it for that > card. Evergreen was the last set of hardware supported by UMS. > > * A test with Evergreen (CEDAR) card works in UMS mode, but I can't > get 3D acceleration. I see these messages in Xorg log file: > > [37.024] (II) RADEON(0): No DRI yet on Evergreen UMS support for evergreen is modesetting only. No accel. > . > . > [37.364] (II) AIGLX: Screen 0 is not DRI2 capable > [37.364] (II) AIGLX: Screen 0 is not DRI capable > [37.664] (II) AIGLX: Loaded and initialized swrast > [37.664] (II) GLX: Initialized DRISWRAST GL provider for screen 0 > > Sounds like just a "property" of UMS to me, but I am not sure. > Nevertheless, the behavior with and without my kernel patches is > identical. Still, 2D copying should still be exercising the CS > parser, so there is some test coverage here. > > * A test with an R7xx card (RV730, E4690 card) results in a segfault in > DDX. Again, this is irrespective of my kernel patches, so I believe > that the bug has been there for a while and that it's in userland. > The crash occurs in r600_set_render_target() function and what causes > it is corrupted cb_conf->surface pointer. When the crash occurs it > has a value of 0x1, which doesn't look like something that would live > in .bss, .data or come from the heap. I didn't try other R6xx cards, > but I suspect that they may have the same problem because they share > the code in DDX. I don't know if UMS DDX will be maintained going > forward, so I don't know if it makes sense to open a bug for this. > BTW, DDX I am testing this with is 6.14.6 R6xx and r7xx are really all you need to worry about in this case. R1xx-r5xx UMS uses a different kernel interface for command submission and evergreen and later don't have UMS drm support. UMS r6xx/r7xx support used the same kernel interface for command submission but the kernel side was much simpler. Additionally, UMS requires the old non-gallium 3D drivers. It sounds like some other change in the ddx broke UMS support for r6xx/r7xx. UMS support was dropped for xf86-video-ati 7.0.0, so we mostly want to try and avoid breaking things for users with ancient userspace stacks and a new kernel. That said, I'm not sure there are that many UMS users left. Alex > > * A test with R300 card (Radeon X300 card) works (again identically > with and without my patches), but again without 3D acceleration. > So it's similar result and comment as with the Evergreen test, though > relevant messages in Xorg log file are slightly different: > > [35.630] (EE) AIGLX error: r300 does not export required DRI extension > [35.630] (EE) AIGLX: reverting to software rendering > [35.915] (II) AIGLX: Loaded and initialized swrast > [35.915] (II) GLX: Initialized DRISWRAST GL provider for screen 0 > > Again, I don't know if this is just the way things are in UMS mode or if > there is some configuration magic I need to do. > > So at this point I'd say that I have not seen anything that would indicate a > regression in legacy mode, although the limitations I have hit make the > tests more limited that I thought they would be (and KMS I tested quite a > bit, so I am confident there). > > thanks, > > Ilija > > > ___ > 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 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #10 from Adam Jorgensen --- Okay, so I updated the 32-bit sabayon I use for performing chroot work stuff, installed Steam and then ran the application via the 32-bit chroot and the application works perfectly. I guess it is thus likely that the sabayon multilibs are currently running a bit behind. -- 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 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #45 from Alexandre Demers --- If I had a virtual machine, would it help debug? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
radeon 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.
[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 at vger seems to be appropriate. Cool I've picked this up and applied it for stable into fixes now. Dave.
[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(-)
[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
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.
[Bug 59015] New: Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 Priority: medium Bug ID: 59015 Assignee: dri-devel at lists.freedesktop.org Summary: Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages Severity: major Classification: Unclassified OS: Linux (All) Reporter: adam.jorgensen.za at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 9.0 Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 72495 --> https://bugs.freedesktop.org/attachment.cgi?id=72495&action=edit Major Graphical Corruption Occurring in Windows that are not Maximised I am participating in the Steam Linux Beta and am experiencing graphical corruption as captured in the screenshots attached to this ticket. By starting Steam from the command-line I was able to observe logging messages and noticed that every time a graphical corruption artifact occurs the application outputs the message: "radeon: The kernel rejected CS, see dmesg for more information." An examination of dmesg reveals messages as follows: " [ 2491.179581] radeon :02:00.0: r600_cs_track_validate_cb invalid tiling 6 for 0 (0x08110668) [ 2491.179588] radeon :02:00.0: r600_packet3_check:1913 invalid cmd stream 566 [ 2491.179592] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! " Relevant system info: 1.6ghz Core i7 CPU 8gb DDR3 RAM Radeon HD 4570 with 512mb DDR2 VRAM using open-source XF86 ATI 7.0.0 drivers 10gb free on root, 30+gb free on home Kernel 3.6, X.org 1.12.4, KDE 4.9.4 running with OpenGL Compositing Primary display is 1440x900 laptop LCD, secondary is 24" 1920x1080 LCD -- 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/20130104/b1934b3f/attachment-0001.html>
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #1 from Adam Jorgensen --- Created attachment 72496 --> https://bugs.freedesktop.org/attachment.cgi?id=72496&action=edit Less corruption when Steam Windows are maximised When a window is maximised the corruption is a lot less (Since the latest version of the Steam Linux client is gone, except for drop-down menus and pop-out windows (Like the Friend List) which are ALWAYS corrupt) -- 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/20130104/56e57f73/attachment.html>
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #2 from Adam Jorgensen --- Created attachment 72497 --> https://bugs.freedesktop.org/attachment.cgi?id=72497&action=edit Big Screen Mode works perfectly but is slow The Big Screen mode seems to work fine, possibly because it functions as a pure OpenGL application? -- 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/20130104/6d2460de/attachment.html>
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #3 from Adam Jorgensen --- Created attachment 72498 --> https://bugs.freedesktop.org/attachment.cgi?id=72498&action=edit Current Status as of 04/01/2013 The Main Steam Window is now displayed perfectly, but drop-down menus and pop-out windows are ALWAYS corrupt, even when maximised. -- 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/20130104/8eb1e636/attachment.html>
[PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct
Hi Mr. Figa,
Thanks for reviewing.
On 3 January 2013 16:29, Tomasz Figa wrote:
> 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.
>
Right, exynos_mipi_dsi_blank_mode() only supports FB_BLANK_UNBLANK as
of now, but FB_BLANK_NORMAL will be supported in future.
If not for Exynos, i think it will be need for other SoCs which
support FB_BLANK_UNBLANK and FB_BLANK_NORMAL.
> 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.
>
You are right, as of now Exynos MIPI DSI Panels are NOT using these
callbacks, but as you mentioned we will need frame done status
monitoring anyways, so i included these callbacks here. Will check, if
we can implement any better method.
> Best regards,
> --
> Tomasz Figa
> Samsung Poland R&D Center
> SW Solution Development, Linux Platform
>
--
Thanks and Regards
Vikas Sajjan
[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x
On 21.12.2012 23:19, Stephen Warren wrote: > I see the situation more like: > > * There's host1x hardware. > > * There's a low-level driver just for host1x itself; the host1x driver. > > * There's a high-level driver for the entire host1x complex of devices. > That is tegradrm. There may be more high-level drivers in the future > (e.g. v4l2 camera driver if it needs to aggregate a bunch of host1x > sub-devices liek tegradrm does). > > * The presence of the host1x DT node logically implies that both the two > drivers in the previous two points should be instantiated. > > * Linux instantiates a single device per DT node. > > * So, it's host1x's responsibility to instantiate the other device(s). I > think it's reasonable for the host1x driver to know exactly what > features the host1x HW complex supports; raw host1x access being one, > and the higher level concept of a tegradrm being another. So, it's > reasonable for host1x to trigger the instantiation of tegradrm. > > * If DRM core didn't stomp on the device object's drvdata (or whichever > field it is), I would recommend not creating a dummy device at all, but > rather having the host1x driver directly implement multiple driver > interfaces. There are many examples like this already in the kernel, > e.g. combined GPIO+IRQ driver, combined GPIO+IRQ+pinctrl driver, etc. We had a phone call with Stephen yesterday, and I finally understood why unbroken chain from DT to tegra-drm is important. The goals are to be able to modprobe tegra-drm without ill effects, and to auto-load tegra-drm module. I had been chasing a totally different goal. Sorry about all the churn. I think we have now two ways to go forward with cons and pros: 1) Keep host1x and tegra-drm as separate driver + Code almost done - we need dummy device and dummy driver - extra code and API when host1x creates dummy device and its passed to tegra-drm - tegra-drm device would need to be a child of host1x device. Having virtual and real devices as host1x children sounds weird. 2) Merge host1x and tegra-drm into one module. drm is a subcomponent, and whatever other personalities we wish would also be subcomponents of host1x. host1x calls tegra-drm directly to handle preparation for drm initialization. As they're in the same module, circular dependency is ok. + Simpler conceptually (no dummy device/driver) + Less code - Proposal doesn't yet exist Thierry, what do you think? I'd prefer option 2, as that keeps things simple and still fulfills the requirements. We probably would redo the patch "Remove redundant host1x" to actually move drm under host1x, and adds calls from host1x to parse_dt() directly. We'd probably leave the code otherwise mostly as it is now, so we'll drop whatever modifications we've done so far in my proposals. You can later pick up some things from our proposals if you want, but it's then up to you. We could also later think about generalizing some of the list management to belong to host1x, but that'd be a follow-up and we can decide that later. Terje
[PATCH] drm/exynos: fimd: modify condition in fimd resume
Hi,
Please review this patch.
Regards,
Prathyush
On Thu, Dec 27, 2012 at 5:10 PM, Prathyush K wrote:
> If fimd is runtime suspended (by DPMS OFF), fimd_suspend does not
> call fimd_activate(false) and just returns. Similarily the check in
> fimd_resume should not resume if previously runtime_suspended.
> Instead the existing check does the opposite. So if fimd was not
> runtime suspended, suspend will turn off fimd but resume will not turn
> it on. This patch fixes this issue by reversing the condition.
>
> Signed-off-by: Prathyush K
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bf0d9ba..9accd466 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -1046,7 +1046,7 @@ static int fimd_resume(struct device *dev)
> * of pm runtime would still be 1 so in this case, fimd driver
> * should be on directly not drawing on pm runtime interface.
> */
> - if (pm_runtime_suspended(dev)) {
> + if (!pm_runtime_suspended(dev)) {
> int ret;
>
> ret = fimd_activate(ctx, true);
> --
> 1.8.0
>
> ___
> 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/20130104/d66c8a92/attachment.html>
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
2013-01-04 08:40 keltez?ssel, Borislav Petkov ?rta:
> 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;
How about any other odd numbers? Like 0xFFFB, or 0x0003?
They will get passed as is after this change, no? Shouldn't they
be also fixed? Something like this below?
if (cur_size_in_dw & 0x0001)
cur_size_in_dw &= ~1;
>> 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
[PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
Dear Paul, On Tue, 01 Jan 2013 04:43:39 +0100 Paul Menzel wrote: > So if nobody has a great idea, the roadmap looks as follows. Revert the > patch, find out why the graphics driver chokes on the reduced blanking > (report a bug) and commit the patch again. I reported a bug at: https://bugzilla.kernel.org/show_bug.cgi?id=52281 Regards, Flo -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130104/f11928cb/attachment.pgp>
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 Andreas Boll changed: What|Removed |Added Attachment #72495|text/plain |image/png mime type|| -- 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/20130104/ca55aebc/attachment.html>
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 Andreas Boll changed: What|Removed |Added Attachment #72497|text/plain |image/png mime type|| -- 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/20130104/4835b05d/attachment.html>
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 Andreas Boll changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Drivers/Gallium/r600 --- Comment #4 from Andreas Boll --- Please attach your xorg log and the outputs from dmesg and glxinfo. -- 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/20130104/6345e658/attachment-0001.html>
[PATCH 0/2] drm/exynos: add support for more resolutions to exynos5
Please Abandon this patch set. Same code is posted under new patch set at http://comments.gmane.org/gmane.comp.video.dri.devel/78392 regards, Rahul Sharma On Tue, Dec 18, 2012 at 7:42 PM, Rahul Sharma wrote: > This patch set adds support for more resolutions and refresh rates to Samsung > Exynos5 SoC series which contains hdmi transmitter (hdmi v1.4a compliant). > > Given resoltuion will be supported or not, is decided by two factors: > 1) Corresponding pixel clock is supported by hdmi PHY. > 2) Mixer can generate the correspoding video timing. > > All standard resolutions and pixel rate combinations are verified for the > above > limitations and are listed in hdmi driver. Any standard resolution supported > by > the monitor/tv will be comapared against this list. > > We got 640x480, 720x576 and 1680x1050 and few more refresh rates enabled as a > result to this exercise. > > Rahul Sharma (2): > drm/exynos: hdmi: add support for extra permissable resolutions > drm/exynos: mixer: add support for extra resolutions > > drivers/gpu/drm/exynos/exynos_hdmi.c | 1004 > - > drivers/gpu/drm/exynos/exynos_mixer.c |8 +- > 2 files changed, 358 insertions(+), 654 deletions(-) >
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #5 from Alex Deucher --- I'm assuming you are using mesa 9.x or newer based on the version info in the bug header. Can you confirm? xf86-video-ati 7.0.0 requires mesa 9.x. Also, if the steam client is a 32-bit application and you are running a 64-bit distro, you will need to make sure your 32-bit 3D driver is up to date. I suspect you have an out of date 32-bit 3D driver. -- 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/20130104/8757ba52/attachment.html>
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #6 from Adam Jorgensen --- Created attachment 72509 --> https://bugs.freedesktop.org/attachment.cgi?id=72509&action=edit X.org log My X.org log file -- 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/20130104/5ad131b6/attachment.html>
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #7 from Adam Jorgensen --- Created attachment 72510 --> https://bugs.freedesktop.org/attachment.cgi?id=72510&action=edit dmesg output Output from dmesg after running Steam and triggering corruption -- 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/20130104/956fb689/attachment.html>
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #8 from Adam Jorgensen --- Created attachment 72511 --> https://bugs.freedesktop.org/attachment.cgi?id=72511&action=edit glxinfo output Output from glxinfo -- 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/20130104/83f45be9/attachment.html>
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #9 from Adam Jorgensen --- (In reply to comment #5) > I'm assuming you are using mesa 9.x or newer based on the version info in > the bug header. Can you confirm? xf86-video-ati 7.0.0 requires mesa 9.x. > Also, if the steam client is a 32-bit application and you are running a > 64-bit distro, you will need to make sure your 32-bit 3D driver is up to > date. I suspect you have an out of date 32-bit 3D driver. I can confirm that I am using Mesa 9.0.1 in conjunction with xf86-video-ati 7.0.0. I *thought* I was running Steam as a 64-bit application but based on the lack of an "ubuntu12_64" directory in my ~/.local/share/Steam directory it seems likely that my Steam installation is actually a 32-bit one. I am using the latest emul-x86 libs (I'm running Sabayon Linux) but I also have a separate 32-bit chroot for work purposes. I will try updating the chroot environment (Since it's set up with the same distro) and installing Steam their and testing it in that environment... -- 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/20130104/c92172a4/attachment.html>
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Fri, Jan 4, 2013 at 6:16 AM, Boszormenyi Zoltan wrote:
> 2013-01-04 08:40 keltez?ssel, Borislav Petkov ?rta:
>
>> 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;
>
>
> How about any other odd numbers? Like 0xFFFB, or 0x0003?
> They will get passed as is after this change, no? Shouldn't they
> be also fixed? Something like this below?
>
> if (cur_size_in_dw & 0x0001)
>cur_size_in_dw &= ~1;
This function only deals with pages so they will always be even.
Alex
[PATCH] drm/radeon: split r6xx and r7xx copy_dma functions
From: Alex Deucher
- r6xx actually uses a slightly different packet format,
although both formats seem to work ok.
- r7xx doesn't have the count multiple of 2 limitation.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c| 10 ++--
drivers/gpu/drm/radeon/radeon_asic.c |4 +-
drivers/gpu/drm/radeon/radeon_asic.h |4 ++
drivers/gpu/drm/radeon/rv770.c | 74 ++
4 files changed, 85 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 923f936..537e259 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2646,7 +2646,7 @@ int r600_copy_blit(struct radeon_device *rdev,
* @num_gpu_pages: number of GPU pages to xfer
* @fence: radeon fence object
*
- * Copy GPU paging using the DMA engine (r6xx-r7xx).
+ * Copy GPU paging using the DMA engine (r6xx).
* Used by the radeon ttm implementation to move pages if
* registered as the asic copy callback.
*/
@@ -2669,8 +2669,8 @@ int r600_copy_dma(struct radeon_device *rdev,
}
size_in_dw = (num_gpu_pages << RADEON_GPU_PAGE_SHIFT) / 4;
- num_loops = DIV_ROUND_UP(size_in_dw, 0x);
- r = radeon_ring_lock(rdev, ring, num_loops * 5 + 8);
+ num_loops = DIV_ROUND_UP(size_in_dw, 0xFFFE);
+ r = radeon_ring_lock(rdev, ring, num_loops * 4 + 8);
if (r) {
DRM_ERROR("radeon: moving bo (%d).\n", r);
radeon_semaphore_free(rdev, &sem, NULL);
@@ -2693,8 +2693,8 @@ int r600_copy_dma(struct radeon_device *rdev,
radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0, 0,
cur_size_in_dw));
radeon_ring_write(ring, dst_offset & 0xfffc);
radeon_ring_write(ring, src_offset & 0xfffc);
- radeon_ring_write(ring, upper_32_bits(dst_offset) & 0xff);
- radeon_ring_write(ring, upper_32_bits(src_offset) & 0xff);
+ radeon_ring_write(ring, (((upper_32_bits(dst_offset) & 0xff) <<
16) |
+(upper_32_bits(src_offset) & 0xff)));
src_offset += cur_size_in_dw * 4;
dst_offset += cur_size_in_dw * 4;
}
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 596bcbe..9056faf 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1140,9 +1140,9 @@ static struct radeon_asic rv770_asic = {
.copy = {
.blit = &r600_copy_blit,
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
- .dma = &r600_copy_dma,
+ .dma = &rv770_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
+ .copy = &rv770_copy_dma,
.copy_ring_index = R600_RING_TYPE_DMA_INDEX,
},
.surface = {
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 5f4882c..15d70e6 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -403,6 +403,10 @@ u32 rv770_page_flip(struct radeon_device *rdev, int crtc,
u64 crtc_base);
void r700_vram_gtt_location(struct radeon_device *rdev, struct radeon_mc *mc);
void r700_cp_stop(struct radeon_device *rdev);
void r700_cp_fini(struct radeon_device *rdev);
+int rv770_copy_dma(struct radeon_device *rdev,
+ uint64_t src_offset, uint64_t dst_offset,
+ unsigned num_gpu_pages,
+ struct radeon_fence **fence);
/*
* evergreen
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 87c979c..1b2444f 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -887,6 +887,80 @@ static int rv770_mc_init(struct radeon_device *rdev)
return 0;
}
+/**
+ * rv770_copy_dma - copy pages using the DMA engine
+ *
+ * @rdev: radeon_device pointer
+ * @src_offset: src GPU address
+ * @dst_offset: dst GPU address
+ * @num_gpu_pages: number of GPU pages to xfer
+ * @fence: radeon fence object
+ *
+ * Copy GPU paging using the DMA engine (r7xx).
+ * Used by the radeon ttm implementation to move pages if
+ * registered as the asic copy callback.
+ */
+int rv770_copy_dma(struct radeon_device *rdev,
+ uint64_t src_offset, uint64_t dst_offset,
+ unsigned num_gpu_pages,
+ struct radeon_fence **fence)
+{
+ struct radeon_semaphore *sem = NULL;
+ int ring_index = rdev->asic->copy.dma_ring_index;
+ struct radeon_ring *ring = &rdev->ring[ring_index];
+ u32 size_in_dw, cur_size_in_dw;
+ int i, num_loops;
+ int r = 0;
+
+ r = radeon_semaphore_create(rdev, &sem);
+ if (r) {
+ DRM_ERROR("radeon: moving bo (%d).\n", r);
+ return r;
+ }
+
+ size_in_dw = (num_gpu_pages << RADEON_GPU_PAGE_SH
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #23 from Alex Deucher --- (In reply to comment #22) > "Is this a regression? Does it happen with older versions of mesa or > kernel?" > Yes. Previous kernel 3.7 doesn't show this problem. Can you bisect? Is it the same commit Thomas landed on or another one? -- 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/20130104/144659c5/attachment.html>
[RFC PATCH] drm/radeon: increase d3 delay to 20 ms during switcheroo poweron
On Wed, Jan 2, 2013 at 10:38 AM, Maarten Lankhorst
wrote:
> vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI
> configuration space is not restored correctly, resulting in MSI not working
> after switch.
>
> Only useful item in dmesg is:
>
> [ 33.922807] radeon :01:00.0: Refused to change power state, currently
> in D3
>
> I did some testing, dumping the difference in ms between first succesful
> switch
> from D3 to D0, and it seems that there is slightly more than 20 ms difference
> when
> the device is re-enabled through vga-switcheroo.
>
> So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not
> working
> on my system after switcheroo-ing.
I guess if it fixes it... Has anyone seen similar problems on non-mac
systems? What is the delay normally set to? It seems pretty
innocuous other than potentially adding a little extra latency. Do
you think it makes sense to make it more like a quirk and only apply
it to problematic systems or just apply across the board?
Alex
>
> Signed-off-by: Maarten Lankhorst
>
> ---
>
> This is a RFC patch since I feel what I'm doing is done in a hackish way,
> but it seems only the D3->D0 transition during switcheroo enable is affected,
> other transitions like suspend/resume and switcheroo poweroff seem unaffected.
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 5515921..8816958 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -910,10 +910,19 @@ static void radeon_switcheroo_set_state(struct pci_dev
> *pdev, enum vga_switchero
> struct drm_device *dev = pci_get_drvdata(pdev);
> pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
> if (state == VGA_SWITCHEROO_ON) {
> + unsigned d3_delay = dev->pdev->d3_delay;
> +
> printk(KERN_INFO "radeon: switched on\n");
> /* don't suspend or resume card normally */
> dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
> +
> + if (dev->pdev->d3_delay < 20)
> + dev->pdev->d3_delay = 20;
> +
> radeon_resume_kms(dev);
> +
> + dev->pdev->d3_delay = d3_delay;
> +
> dev->switch_power_state = DRM_SWITCH_POWER_ON;
> drm_kms_helper_poll_enable(dev);
> } else {
>
radeon CS parser refactoring
On Wed, Jan 2, 2013 at 6:27 PM, Ilija Hadzic wrote: > 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. > > The patches have been rebased to the current state of Dave's drm-next > branch. Looks good to me. Nice clean up. As long as there are no regressions with UMS, consider them applied. Thanks! Alex
[PATCH v2 2/4] drm/exynos: implement display-mode-check callback in mixer driver
On Fri, Jan 4, 2013 at 8:53 AM, Rahul Sharma
wrote:
> This patch adds the implementation of check_mode callback in the mixer
s/check_mode/check_timing/
> 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 | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 21db895..c1f2e7a 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -810,6 +810,29 @@ static void mixer_win_disable(void *ctx, int win)
> mixer_ctx->win_data[win].enabled = false;
> }
>
> +int mixer_check_timing(void *ctx, struct fb_videomode *timing)
> +{
> + struct mixer_context *mixer_ctx = ctx;
> + unsigned int w, h;
xres and yres are defined as u32 in fb_videomode
> +
> + w = timing->xres;
> + h = timing->yres;
> +
> + DRM_DEBUG_KMS("%s : xres=%d, yres=%d, refresh=%d, intl=%d\n",
> + __func__, timing->xres, timing->yres,
> + timing->refresh, (timing->vmode &
> + FB_VMODE_INTERLACED) ? true : false);
> +
> + if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16)
> + return 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;
> +
> + return -EINVAL;
> +}
> static void mixer_wait_for_vblank(void *ctx)
> {
> struct mixer_context *mixer_ctx = ctx;
> @@ -947,6 +970,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_timing = mixer_check_timing,
> };
>
> /* for pageflip event */
> --
> 1.8.0
>
[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 #15 from Konrad Rzeszutek Wilk 2013-01-04 16:00:10 --- Let me ask again: Does it work properly under baremetal? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[RFC PATCH] drm/radeon: increase d3 delay to 20 ms during switcheroo poweron
Op 04-01-13 16:34, Alex Deucher schreef:
> On Wed, Jan 2, 2013 at 10:38 AM, Maarten Lankhorst
> wrote:
>> vga-switcheroo with apple-gmux does not switch correctly on my system. The
>> PCI
>> configuration space is not restored correctly, resulting in MSI not working
>> after switch.
>>
>> Only useful item in dmesg is:
>>
>> [ 33.922807] radeon :01:00.0: Refused to change power state, currently
>> in D3
>>
>> I did some testing, dumping the difference in ms between first succesful
>> switch
>> from D3 to D0, and it seems that there is slightly more than 20 ms
>> difference when
>> the device is re-enabled through vga-switcheroo.
>>
>> So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not
>> working
>> on my system after switcheroo-ing.
> I guess if it fixes it... Has anyone seen similar problems on non-mac
> systems? What is the delay normally set to? It seems pretty
It's normally set to PCI_PM_D3_WAIT, 10 ms.
> innocuous other than potentially adding a little extra latency. Do
> you think it makes sense to make it more like a quirk and only apply
> it to problematic systems or just apply across the board?
Quirking would be fine. Since there is a message in dmesg it would
be easy to identify when others hit the same issue, in which case
we could enable it all the time.
>> Signed-off-by: Maarten Lankhorst
>>
>> ---
>>
>> This is a RFC patch since I feel what I'm doing is done in a hackish way,
>> but it seems only the D3->D0 transition during switcheroo enable is affected,
>> other transitions like suspend/resume and switcheroo poweroff seem
>> unaffected.
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
>> b/drivers/gpu/drm/radeon/radeon_device.c
>> index 5515921..8816958 100644
>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>> @@ -910,10 +910,19 @@ static void radeon_switcheroo_set_state(struct pci_dev
>> *pdev, enum vga_switchero
>> struct drm_device *dev = pci_get_drvdata(pdev);
>> pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
>> if (state == VGA_SWITCHEROO_ON) {
>> + unsigned d3_delay = dev->pdev->d3_delay;
>> +
>> printk(KERN_INFO "radeon: switched on\n");
>> /* don't suspend or resume card normally */
>> dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
>> +
>> + if (dev->pdev->d3_delay < 20)
>> + dev->pdev->d3_delay = 20;
>> +
>> radeon_resume_kms(dev);
>> +
>> + dev->pdev->d3_delay = d3_delay;
>> +
>> dev->switch_power_state = DRM_SWITCH_POWER_ON;
>> drm_kms_helper_poll_enable(dev);
>> } else {
>>
[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 #16 from Fernando Chaves 2013-01-04 16:35:55 --- I'm sorry Konrad, but I don't know exactly what you mean when you say "run on bare metal". -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 42162] Display not enabled on resume (HP DV6)
https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #8 from Johan Brannlund --- Resume still doesn't work with kernel 3.8-rc2. However, I now get a hard lockup on resume. Log attached. -- 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/20130104/317f88ef/attachment.html>
[Bug 42162] Display not enabled on resume (HP DV6)
https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #9 from Johan Brannlund --- Created attachment 72514 --> https://bugs.freedesktop.org/attachment.cgi?id=72514&action=edit Suspend/resume log, kernel 3.8-rc2 -- 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/20130104/0b156482/attachment.html>
[Bug 42162] Display not enabled on resume (HP DV6)
https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #10 from Alex Deucher --- (In reply to comment #8) > Resume still doesn't work with kernel 3.8-rc2. However, I now get a hard > lockup on resume. Log attached. Can you bisect to see what caused the hard lock? -- 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/20130104/af4058bc/attachment.html>
[Bug 42162] Display not enabled on resume (HP DV6)
https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #11 from Johan Brannlund --- I'll try bisecting when I have some spare time, but it's probably going to be a few weeks. -- 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/20130104/d7241368/attachment.html>
[Bug 42162] Display not enabled on resume (HP DV6)
https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #12 from Johan Brannlund --- Correction: it's *not* a hard lockup - the laptop still responds to ping. It may just be that the keyboard is not working after resume (or even that I mistyped something when trying to reboot it by typing blind). -- 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/20130104/9d5a4249/attachment.html>
[PATCH] drm/radeon: fix DMA CS parser for r6xx linear copy packet
From: Alex Deucher
Was using the r7xx format.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600_cs.c | 31 ++-
1 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 9ea13d0..03191a5 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2677,16 +2677,29 @@ int r600_dma_cs_parse(struct radeon_cs_parser *p)
}
p->idx += 7;
} else {
- src_offset = ib[idx+2];
- src_offset |= ((u64)(ib[idx+4] & 0xff)) << 32;
- dst_offset = ib[idx+1];
- dst_offset |= ((u64)(ib[idx+3] & 0xff)) << 32;
+ if (p->family >= CHIP_RV770) {
+ src_offset = ib[idx+2];
+ src_offset |= ((u64)(ib[idx+4] & 0xff))
<< 32;
+ dst_offset = ib[idx+1];
+ dst_offset |= ((u64)(ib[idx+3] & 0xff))
<< 32;
- ib[idx+1] += (u32)(dst_reloc->lobj.gpu_offset &
0xfffc);
- ib[idx+2] += (u32)(src_reloc->lobj.gpu_offset &
0xfffc);
- ib[idx+3] +=
upper_32_bits(dst_reloc->lobj.gpu_offset) & 0xff;
- ib[idx+4] +=
upper_32_bits(src_reloc->lobj.gpu_offset) & 0xff;
- p->idx += 5;
+ ib[idx+1] +=
(u32)(dst_reloc->lobj.gpu_offset & 0xfffc);
+ ib[idx+2] +=
(u32)(src_reloc->lobj.gpu_offset & 0xfffc);
+ ib[idx+3] +=
upper_32_bits(dst_reloc->lobj.gpu_offset) & 0xff;
+ ib[idx+4] +=
upper_32_bits(src_reloc->lobj.gpu_offset) & 0xff;
+ p->idx += 5;
+ } else {
+ src_offset = ib[idx+2];
+ src_offset |= ((u64)(ib[idx+3] & 0xff))
<< 32;
+ dst_offset = ib[idx+1];
+ dst_offset |= ((u64)(ib[idx+3] &
0xff)) << 16;
+
+ ib[idx+1] +=
(u32)(dst_reloc->lobj.gpu_offset & 0xfffc);
+ ib[idx+2] +=
(u32)(src_reloc->lobj.gpu_offset & 0xfffc);
+ ib[idx+3] +=
upper_32_bits(src_reloc->lobj.gpu_offset) & 0xff;
+ ib[idx+3] +=
(upper_32_bits(dst_reloc->lobj.gpu_offset) & 0xff) << 16;
+ p->idx += 4;
+ }
}
if ((src_offset + (count * 4)) >
radeon_bo_size(src_reloc->robj)) {
dev_warn(p->dev, "DMA copy src buffer too small
(%llu %lu)\n",
--
1.7.7.5
[Bug 50941] Kernel does not compile
https://bugzilla.kernel.org/show_bug.cgi?id=50941 --- Comment #3 from JP Pozzi 2013-01-04 17:56:28 --- Hello, I try it but ACPI_VIDEO is reset to "m" whenever you "make menuconfig" or compile the kernel. I can't find what other parameters are to be set to "y". At least the kernel compile but I have some problems, after one or two hours the screen (or keyboard ?) get stuck and I have to connect from another machine to stop properly the system. I get the same kind of "screen blocked" with the 3.7.1 kernel. I try it but ACPI_VIDEO is reset to "m" whenever you "make menuconfig" or compile the kernel. I can't find what other parameters are to be set to "y". It is the same for 3.7.1 kernel. Regards JP P -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 56405] Distorted graphics on Radeon HD 6620G
https://bugs.freedesktop.org/show_bug.cgi?id=56405 Michael Dressel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #54 from Michael Dressel --- The patch works for me, as alread reported. I have not tried a kernel including the patch. But I still think this bug is fixed. -- 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/20130104/83152fcc/attachment.html>
[PATCH 0/3] drm_pcie_get_speed_cap_mask() cleanups
These are minor cleanups for drm_pcie_get_speed_cap_mask() to use standard #defines and PCIe capability accessors. They depend on a pci_regs.h change (130f1b8f35) that appeared in v3.8-rc2. They don't address the issue of DRM devices directly below a host bridge that doesn't appear as a PCI device (the issue Lucas has been working on). I'm a little skeptical about the premise of drm_pcie_get_speed_cap_mask() to begin with. Link speed seems like something fairly generic that should be handled in the core, not in individual drivers. Sec 6.11, "Link Speed Management", in the PCIe 3.0 spec seems relevant and suggests that the hardware should automatically use the highest speed supported by both ends of the link unless software sets a lower maximum via Target Link Speed. But I can't match up the code, e.g., evergreen_pcie_gen2_enable(), to anything in the generic PCIe specs, so maybe this driver code is essentially quirks for misbehaving hardware? --- Bjorn Helgaas (3): drm/pci: Use the standard #defines for PCIe Link Capability bits drm/pci: Set all supported speeds in speed cap mask for pre-3.0 devices drm/pci: Use PCI Express Capability accessors drivers/gpu/drm/drm_pci.c | 27 --- 1 files changed, 8 insertions(+), 19 deletions(-)
[PATCH 1/3] drm/pci: Use the standard #defines for PCIe Link Capability bits
Use the standard #defines rather than bare numbers for the PCIe Link
Capabilities speed bits.
Signed-off-by: Bjorn Helgaas
---
drivers/gpu/drm/drm_pci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 754bc96..11c8add 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -504,9 +504,9 @@ int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32
*mask)
if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
*mask |= DRM_PCIE_SPEED_80;
} else {
- if (lnkcap & 1)
+ if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
*mask |= DRM_PCIE_SPEED_25;
- if (lnkcap & 2)
+ if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
*mask |= DRM_PCIE_SPEED_50;
}
[PATCH 2/3] drm/pci: Set all supported speeds in speed cap mask for pre-3.0 devices
For devices that conform to PCIe r3.0 and have a Link Capabilities 2
register, we test and report every bit in the Supported Link Speeds Vector
field. For a device that supports both 2.5GT/s and 5.0GT/s, we set both
DRM_PCIE_SPEED_25 and DRM_PCIE_SPEED_50 in the returned mask.
For pre-r3.0 devices, the Link Capabilities 0010b encoding
(PCI_EXP_LNKCAP_SLS_5_0GB) means that both 5.0GT/s and 2.5GT/s are
supported, so set both DRM_PCIE_SPEED_25 and DRM_PCIE_SPEED_50 in this
case as well.
Signed-off-by: Bjorn Helgaas
---
drivers/gpu/drm/drm_pci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 11c8add..50e26f2 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -507,7 +507,7 @@ int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32
*mask)
if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
*mask |= DRM_PCIE_SPEED_25;
if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
- *mask |= DRM_PCIE_SPEED_50;
+ *mask |= (DRM_PCIE_SPEED_25 | DRM_PCIE_SPEED_50);
}
DRM_INFO("probing gen 2 caps for device %x:%x = %x/%x\n", root->vendor,
root->device, lnkcap, lnkcap2);
[PATCH 3/3] drm/pci: Use PCI Express Capability accessors
Use PCI Express Capability access functions to simplify this code a bit.
For non-PCIe devices or pre-PCIe 3.0 devices that don't implement the Link
Capabilities 2 register, pcie_capability_read_dword() reads a zero.
Since we're only testing whether the bits we care about are set, there's no
need to mask out the other bits we *don't* care about.
Signed-off-by: Bjorn Helgaas
---
drivers/gpu/drm/drm_pci.c | 21 +
1 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 50e26f2..86102a0 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -469,41 +469,30 @@ EXPORT_SYMBOL(drm_pci_exit);
int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 *mask)
{
struct pci_dev *root;
- int pos;
- u32 lnkcap = 0, lnkcap2 = 0;
+ u32 lnkcap, lnkcap2;
*mask = 0;
if (!dev->pdev)
return -EINVAL;
- if (!pci_is_pcie(dev->pdev))
- return -EINVAL;
-
root = dev->pdev->bus->self;
- pos = pci_pcie_cap(root);
- if (!pos)
- return -EINVAL;
-
/* we've been informed via and serverworks don't make the cut */
if (root->vendor == PCI_VENDOR_ID_VIA ||
root->vendor == PCI_VENDOR_ID_SERVERWORKS)
return -EINVAL;
- pci_read_config_dword(root, pos + PCI_EXP_LNKCAP, &lnkcap);
- pci_read_config_dword(root, pos + PCI_EXP_LNKCAP2, &lnkcap2);
-
- lnkcap &= PCI_EXP_LNKCAP_SLS;
- lnkcap2 &= 0xfe;
+ pcie_capability_read_dword(root, PCI_EXP_LNKCAP, &lnkcap);
+ pcie_capability_read_dword(root, PCI_EXP_LNKCAP2, &lnkcap2);
- if (lnkcap2) { /* PCIE GEN 3.0 */
+ if (lnkcap2) { /* PCIe r3.0-compliant */
if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_2_5GB)
*mask |= DRM_PCIE_SPEED_25;
if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_5_0GB)
*mask |= DRM_PCIE_SPEED_50;
if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
*mask |= DRM_PCIE_SPEED_80;
- } else {
+ } else {/* pre-r3.0 */
if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
*mask |= DRM_PCIE_SPEED_25;
if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
[PATCH 0/3] drm_pcie_get_speed_cap_mask() cleanups
On Fri, Jan 4, 2013 at 2:10 PM, Bjorn Helgaas wrote: > These are minor cleanups for drm_pcie_get_speed_cap_mask() to use > standard #defines and PCIe capability accessors. They depend on > a pci_regs.h change (130f1b8f35) that appeared in v3.8-rc2. > > They don't address the issue of DRM devices directly below a host > bridge that doesn't appear as a PCI device (the issue Lucas has > been working on). > > I'm a little skeptical about the premise of drm_pcie_get_speed_cap_mask() > to begin with. Link speed seems like something fairly generic that should > be handled in the core, not in individual drivers. Sec 6.11, "Link Speed > Management", in the PCIe 3.0 spec seems relevant and suggests that the > hardware should automatically use the highest speed supported by both ends > of the link unless software sets a lower maximum via Target Link Speed. > > But I can't match up the code, e.g., evergreen_pcie_gen2_enable(), to > anything in the generic PCIe specs, so maybe this driver code is > essentially quirks for misbehaving hardware? At least for radeon, there is an asic specific sequence required to change the PCIE gen link speed at runtime. Depending on the bios, the board may come up in the highest mode supported by either side or something lower. If it comes up at a lower speed than the hardware is capable of, we can increase it in the driver to improve performance. Additionally, you can select a lower link speed to save power. I don't know if there is a generic non-asic specific way to change the link speed of a device at runtime, but I'm not really a PCI expert. Alex
