[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #76 from jackdachef at gmail.com --- Created attachment 103776 --> https://bugs.freedesktop.org/attachment.cgi?id=103776&action=edit DVD watching (150 minutes) on fluxbox with only konsole & smplayer with vdpau running so obviously vdpau is *NOT* the problem here the whole movie played fine and the whole box didn't lockup without any suspicious messages, data or behavior on dmesg -- 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/20140801/23e72ed4/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #77 from jackdachef at gmail.com --- Created attachment 103777 --> https://bugs.freedesktop.org/attachment.cgi?id=103777&action=edit output of Xorg.0.log during uvd-test with DVD watching in fluxbox via smplayer mark the "extra" explicitely set settings: [ 253.915] (**) RADEON(0): Option "EnablePageFlip" "off" [ 253.915] (**) RADEON(0): Option "ColorTiling" "on" [ 253.915] (**) RADEON(0): Option "AccelMethod" "Glamor" [ 253.915] (**) RADEON(0): Option "EXAVSync" "off" [ 253.915] (**) RADEON(0): Option "EXAPixmaps" "on" [ 253.915] (**) RADEON(0): Option "SwapbuffersWait" "on" I read about commits from 3.14 to 3.16-rc* that mentioned pageflipping changes but disabling that didn't make a change *before* watching the DVD I did another test and accidentally watched a short portion of a HTML video on youtube with chromium (actually only had intended to read lkml, but there was a reference link and didn't mention that it was a video /facepalm), did some browsing, had gnote running (and some more which I currently don't remember) adobe flash was explicitely turned *off* via about:plugins and X hardlocked while playing music (and mp3, via audacious) & browsing via chromium so at least in my case more and more signs seem to lead towards bug 81644 (https://bugs.freedesktop.org/show_bug.cgi?id=81644) and that chromium + html video; or chromium and all sorts of video (vdpau doesn't apply here ?!) triggers instability & (hard)locks -- 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/20140801/a4b6c179/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #23 from jackdachef at gmail.com --- @Aaron: try reading into Magic SYSRQ key: http://en.wikipedia.org/wiki/Magic_SysRq_key next time when X seems to freeze - first do a Magic SYSRQ + R, then try to imitate a "secure attention key" == Magic SYSRQ + k whether that unlocks it or if X doesn't show any change anymore but the system still seems to be alive: Magic SYSRQ Key + r then Magic SYSRQ Key + w (what tasks or kernel threads, etc. is stuck) then the rest of "REISUB" (Magic SYSRQ Key + e, i, s, u, b) after the next start you can look through the contents of the kernel messages in /var/log/kern.log via tail -n 3500 /var/log/kern.log | less (keyboard cursor up & down, quit via "q") if the messages are too much try via tail -n 7500 /var/log/kern.log | less or higher sudo may be needed, if not using root privileges logging may be disabled, so it first might have to be enabled hope this helps ... -- 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/20140801/800eeaa7/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #78 from jackdachef at gmail.com --- just saw that there are new updates in http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.17-wip & http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.17-rebased-on-fixes hopefully the changes make a difference, will try out the new drm-next-3.17-rebased-on-fixes in approximately a day or later thanks guys ! -- 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/20140801/f03175bc/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #24 from Aaron B --- Created attachment 103786 --> https://bugs.freedesktop.org/attachment.cgi?id=103786&action=edit DMesg of multile flash crashes. I don't think it'll help much, it's more of the same from a dmesg, but this crash was like the other I experienced, pooped me out to a command prompt after some time. It stalled on some new rings other than 0, which is "nice" I guess. But this was caused by Chromium, just refreshing a page or switching tabs, one of those. When it happened, Counter Strike Source was murdered, so it affected it too in some way. But, my steam log shows nothing with the output directed to it. I guess it shut down too quick to flush anything to it. I don't really know what else to do, I've been reading up the posts from Agd5f (Drazner?) posts and I mean, I'm a programmer and do lots of assembly and it makes sense. I just don't know where to start debugging such a lower level kernel problem. I believe it's out of my realm too much so to try anything else besides post logs. :/ -- 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/20140801/f13e988c/attachment.html>
[Bug 81991] New: X page allocation errors referencing radeon_vm_get_bos
2 fb,fbcon ahci 23419 0 r8169 55423 0 firewire_ohci 30581 0 libahci20828 1 ahci firewire_core 49708 1 firewire_ohci snd43711 21 snd_usb_audio,snd_ctxfi,snd_hwdep,snd_timer,snd_pcm,snd_rawmidi,snd_usbmidi_lib,snd_seq_device serio_raw 4289 0 i2c_piix4 8488 0 i2c_core 20478 7 drm,i2c_dev,i2c_piix4,drm_kms_helper,i2c_algo_bit,radeon,videodev soundcore864 1 snd mii 3819 1 r8169 pata_jmicron2443 0 crc_itu_t 1283 1 firewire_core hwmon 2834 3 asus_atk0110,k10temp,radeon acpi_cpufreq6471 1 wmi 8011 0 loop 18568 0 -- 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/20140801/b6b4d109/attachment-0001.html>
[Bug 81444] [drm:radeon_uvd_free_handles] *ERROR* Error destroying UVD (-22)!
https://bugs.freedesktop.org/show_bug.cgi?id=81444 --- Comment #3 from Harald Judt --- I believe the playback issues may not be related to the -22 error. I've downgraded ffmpeg from 2.3 to 2.2.5, and the choppiness and issues both with xv and vdpau seem solved, so this was very likely a software problem (long-time test still pending). I will try to reproduce the -22 error in one or two weeks, using kdenlive with mlt (with vdpau support) seemed to have been a certain way to make it happen pretty fast. -- 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/20140801/22f3294d/attachment.html>
[PATCH] drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM
From: Michel D?nzer
The HDP cache only applies to CPU access to VRAM.
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_gem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index a350cf9..8f2cb58 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -359,15 +359,17 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev,
void *data,
struct drm_gem_object *gobj;
struct radeon_bo *robj;
int r;
+ uint32_t cur_placement = 0;
gobj = drm_gem_object_lookup(dev, filp, args->handle);
if (gobj == NULL) {
return -ENOENT;
}
robj = gem_to_radeon_bo(gobj);
- r = radeon_bo_wait(robj, NULL, false);
+ r = radeon_bo_wait(robj, &cur_placement, false);
/* Flush HDP cache via MMIO if necessary */
- if (rdev->asic->mmio_hdp_flush)
+ if (rdev->asic->mmio_hdp_flush &&
+ radeon_mem_type_to_domain(cur_placement) == RADEON_GEM_DOMAIN_VRAM)
robj->rdev->asic->mmio_hdp_flush(rdev);
drm_gem_object_unreference_unlocked(gobj);
r = radeon_gem_handle_lockup(rdev, r);
--
2.0.1
[PATCH 17/19] drm/radeon: use rcu waits in some ioctls
On 01.08.2014 00:34, Maarten Lankhorst wrote:
>
> @@ -357,14 +360,20 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev,
> void *data,
> struct drm_radeon_gem_wait_idle *args = data;
> struct drm_gem_object *gobj;
> struct radeon_bo *robj;
> - int r;
> + int r = 0;
> + long ret;
>
> gobj = drm_gem_object_lookup(dev, filp, args->handle);
> if (gobj == NULL) {
> return -ENOENT;
> }
> robj = gem_to_radeon_bo(gobj);
> - r = radeon_bo_wait(robj, NULL, false);
> + ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true,
> 30 * HZ);
> + if (ret == 0)
> + r = -EBUSY;
> + else if (ret < 0)
> + r = ret;
> +
> /* callback hw specific functions if any */
> if (rdev->asic->ioctl_wait_idle)
> robj->rdev->asic->ioctl_wait_idle(rdev, robj);
Heads up, this conflicts with
http://lists.freedesktop.org/archives/dri-devel/2014-August/065255.html
which passes a non-NULL second argument to radeon_bo_wait() to get the
BO's current domain.
--
Earthling Michel D?nzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
[PATCH] drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM
Am 01.08.2014 um 10:22 schrieb Michel D?nzer:
> From: Michel D?nzer
>
> The HDP cache only applies to CPU access to VRAM.
>
> Signed-off-by: Michel D?nzer
Wanted to suggest the same thing already, looks like a valid
optimization to me.
Patch is Reviewed-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/radeon_gem.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index a350cf9..8f2cb58 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -359,15 +359,17 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev,
> void *data,
> struct drm_gem_object *gobj;
> struct radeon_bo *robj;
> int r;
> + uint32_t cur_placement = 0;
>
> gobj = drm_gem_object_lookup(dev, filp, args->handle);
> if (gobj == NULL) {
> return -ENOENT;
> }
> robj = gem_to_radeon_bo(gobj);
> - r = radeon_bo_wait(robj, NULL, false);
> + r = radeon_bo_wait(robj, &cur_placement, false);
> /* Flush HDP cache via MMIO if necessary */
> - if (rdev->asic->mmio_hdp_flush)
> + if (rdev->asic->mmio_hdp_flush &&
> + radeon_mem_type_to_domain(cur_placement) == RADEON_GEM_DOMAIN_VRAM)
> robj->rdev->asic->mmio_hdp_flush(rdev);
> drm_gem_object_unreference_unlocked(gobj);
> r = radeon_gem_handle_lockup(rdev, r);
[Bug 81444] [drm:radeon_uvd_free_handles] *ERROR* Error destroying UVD (-22)!
https://bugs.freedesktop.org/show_bug.cgi?id=81444 --- Comment #4 from Christian K?nig --- Well, radeon_uvd_free_handles is only called if an application crashed or didn't cleaned up the VDPAU driver correctly. (e.g. the kernel needs to manually tell the hardware that a decoder isn't needed any more because the application failed to do so). So it's definately some kind of userspace problem involved here. But neverless there is also something wrong with the kernel function, otherwise you won't get -22 (-EINVAL) in your dmesg. -- 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/20140801/d0f22efd/attachment.html>
[Bug 81444] [drm:radeon_uvd_free_handles] *ERROR* Error destroying UVD (-22)!
https://bugs.freedesktop.org/show_bug.cgi?id=81444 Harald Judt changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #5 from Harald Judt --- Yes, there must be something else wrong (I guess in kernel) because VDPAU stops working when the error has occurred. I'll try to find a scenario which is easy to reproduce. -- 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/20140801/c8c981a9/attachment.html>
[PATCH 06/15] drm/exynos: dpi: Add support for panel prepare and unprepare routines
On Thu, Jul 31, 2014 at 11:12:05PM +0530, Ajay Kumar wrote: > Modify exynos_dpi driver to support the new panel calls: > prepare and unprepare. > > Signed-off-by: Ajay Kumar > --- > drivers/gpu/drm/exynos/exynos_drm_dpi.c |8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) Looks good to me. Inki, can I have your Acked-by to take this through the panel tree? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/3a0e4615/attachment.sig>
[PATCH 07/15] drm/exynos: dsi: Add support for panel prepare and unprepare routines
On Thu, Jul 31, 2014 at 11:12:06PM +0530, Ajay Kumar wrote: > Modify exynos_dsi driver to support the new panel calls: > prepare and unprepare. > > Signed-off-by: Ajay Kumar > --- > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) And this one as well. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/f004fc2b/attachment.sig>
[PATCH 15/15] drm/exynos: dp: Modify driver to support drm_panel
On Thu, Jul 31, 2014 at 11:12:14PM +0530, Ajay Kumar wrote: > Add drm_panel controls to support powerup/down of the > eDP panel, if one is present at the sink side. > > Signed-off-by: Ajay Kumar > --- > drivers/gpu/drm/exynos/Kconfig |1 + > drivers/gpu/drm/exynos/exynos_dp_core.c | 88 > --- > drivers/gpu/drm/exynos/exynos_dp_core.h |3 +- > 3 files changed, 71 insertions(+), 21 deletions(-) Inki, I'll need an Acked-by from you on this one as well. It has a build time dependency on earlier patches in this series, so taking it through the panel tree along with the rest is probably easiest. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/59050a65/attachment-0001.sig>
[PATCH 14/15] drm/exynos: Move DP setup into commit()
On Thu, Jul 31, 2014 at 11:12:13PM +0530, Ajay Kumar wrote:
> Add commit callback for exynos_dp, and move the DP link training,
> video configuration code from the hotplug handler into commit().
>
> Signed-off-by: Sean Paul
> Signed-off-by: Ajay Kumar
> ---
> drivers/gpu/drm/exynos/exynos_dp_core.c | 24 +++-
> 1 file changed, 19 insertions(+), 5 deletions(-)
This is not related to the other patches in the series, so it can be
applied independently.
Sean, this looks like a back-/forward-port of the patch you linked to in
reply to an earlier version of the series, does this still correspond to
what you think it should be doing? (hence not trimming the quote)
Thierry
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 31c3de9..347dec9 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -875,10 +875,18 @@ static irqreturn_t exynos_dp_irq_handler(int irq, void
> *arg)
> static void exynos_dp_hotplug(struct work_struct *work)
> {
> struct exynos_dp_device *dp;
> - int ret;
>
> dp = container_of(work, struct exynos_dp_device, hotplug_work);
>
> + if (dp->drm_dev)
> + drm_helper_hpd_irq_event(dp->drm_dev);
> +}
> +
> +static void exynos_dp_commit(struct exynos_drm_display *display)
> +{
> + struct exynos_dp_device *dp = display->ctx;
> + int ret;
> +
> ret = exynos_dp_detect_hpd(dp);
> if (ret) {
> /* Cable has been disconnected, we're done */
> @@ -1050,8 +1058,10 @@ static void exynos_dp_phy_exit(struct exynos_dp_device
> *dp)
> }
> }
>
> -static void exynos_dp_poweron(struct exynos_dp_device *dp)
> +static void exynos_dp_poweron(struct exynos_drm_display *display)
> {
> + struct exynos_dp_device *dp = display->ctx;
> +
> if (dp->dpms_mode == DRM_MODE_DPMS_ON)
> return;
>
> @@ -1059,10 +1069,13 @@ static void exynos_dp_poweron(struct exynos_dp_device
> *dp)
> exynos_dp_phy_init(dp);
> exynos_dp_init_dp(dp);
> enable_irq(dp->irq);
> + exynos_dp_commit(display);
> }
>
> -static void exynos_dp_poweroff(struct exynos_dp_device *dp)
> +static void exynos_dp_poweroff(struct exynos_drm_display *display)
> {
> + struct exynos_dp_device *dp = display->ctx;
> +
> if (dp->dpms_mode != DRM_MODE_DPMS_ON)
> return;
>
> @@ -1078,12 +1091,12 @@ static void exynos_dp_dpms(struct exynos_drm_display
> *display, int mode)
>
> switch (mode) {
> case DRM_MODE_DPMS_ON:
> - exynos_dp_poweron(dp);
> + exynos_dp_poweron(display);
> break;
> case DRM_MODE_DPMS_STANDBY:
> case DRM_MODE_DPMS_SUSPEND:
> case DRM_MODE_DPMS_OFF:
> - exynos_dp_poweroff(dp);
> + exynos_dp_poweroff(display);
> break;
> default:
> break;
> @@ -1094,6 +1107,7 @@ static void exynos_dp_dpms(struct exynos_drm_display
> *display, int mode)
> static struct exynos_drm_display_ops exynos_dp_display_ops = {
> .create_connector = exynos_dp_create_connector,
> .dpms = exynos_dp_dpms,
> + .commit = exynos_dp_commit,
> };
>
> static struct exynos_drm_display exynos_dp_display = {
> --
> 1.7.9.5
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/9c6d98ce/attachment.sig>
[PATCH 06/15] drm/exynos: dpi: Add support for panel prepare and unprepare routines
On 2014? 08? 01? 18:04, Thierry Reding wrote: > On Thu, Jul 31, 2014 at 11:12:05PM +0530, Ajay Kumar wrote: >> Modify exynos_dpi driver to support the new panel calls: >> prepare and unprepare. >> >> Signed-off-by: Ajay Kumar >> --- >> drivers/gpu/drm/exynos/exynos_drm_dpi.c |8 ++-- >> 1 file changed, 6 insertions(+), 2 deletions(-) > > Looks good to me. Inki, can I have your Acked-by to take this through > the panel tree? Of course. Acked-by: Inki Dae Thanks, Inki Dae > > Thierry >
[PATCH 15/15] drm/exynos: dp: Modify driver to support drm_panel
On 2014? 08? 01? 18:09, Thierry Reding wrote: > On Thu, Jul 31, 2014 at 11:12:14PM +0530, Ajay Kumar wrote: >> Add drm_panel controls to support powerup/down of the >> eDP panel, if one is present at the sink side. >> >> Signed-off-by: Ajay Kumar >> --- >> drivers/gpu/drm/exynos/Kconfig |1 + >> drivers/gpu/drm/exynos/exynos_dp_core.c | 88 >> --- >> drivers/gpu/drm/exynos/exynos_dp_core.h |3 +- >> 3 files changed, 71 insertions(+), 21 deletions(-) > > Inki, I'll need an Acked-by from you on this one as well. It has a build > time dependency on earlier patches in this series, so taking it through > the panel tree along with the rest is probably easiest. Acked-by: Inki Dae Thanks, Inki Dae > > Thierry >
[PATCH 14/15] drm/exynos: Move DP setup into commit()
On Fri, Aug 1, 2014 at 2:48 PM, Thierry Reding
wrote:
> On Thu, Jul 31, 2014 at 11:12:13PM +0530, Ajay Kumar wrote:
>> Add commit callback for exynos_dp, and move the DP link training,
>> video configuration code from the hotplug handler into commit().
>>
>> Signed-off-by: Sean Paul
>> Signed-off-by: Ajay Kumar
>> ---
>> drivers/gpu/drm/exynos/exynos_dp_core.c | 24 +++-
>> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> This is not related to the other patches in the series, so it can be
> applied independently.
This patch should go in this series only.
[PATCH 15/15] has dependency on this because it modifies exynos_dp_commit().
> Sean, this looks like a back-/forward-port of the patch you linked to in
> reply to an earlier version of the series, does this still correspond to
> what you think it should be doing? (hence not trimming the quote)
Sean said one of his test app fails since exynos_dp_commit was missing
in previous version of this patch.
Now, I have added exynos_dp_commit as he suggested, and the side effect
because of this addition (video reconfiguration glitch) is taken care by the
panel calls in the next patch [PATCH 15/15].
Ajay
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 31c3de9..347dec9 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -875,10 +875,18 @@ static irqreturn_t exynos_dp_irq_handler(int irq, void
>> *arg)
>> static void exynos_dp_hotplug(struct work_struct *work)
>> {
>> struct exynos_dp_device *dp;
>> - int ret;
>>
>> dp = container_of(work, struct exynos_dp_device, hotplug_work);
>>
>> + if (dp->drm_dev)
>> + drm_helper_hpd_irq_event(dp->drm_dev);
>> +}
>> +
>> +static void exynos_dp_commit(struct exynos_drm_display *display)
>> +{
>> + struct exynos_dp_device *dp = display->ctx;
>> + int ret;
>> +
>> ret = exynos_dp_detect_hpd(dp);
>> if (ret) {
>> /* Cable has been disconnected, we're done */
>> @@ -1050,8 +1058,10 @@ static void exynos_dp_phy_exit(struct
>> exynos_dp_device *dp)
>> }
>> }
>>
>> -static void exynos_dp_poweron(struct exynos_dp_device *dp)
>> +static void exynos_dp_poweron(struct exynos_drm_display *display)
>> {
>> + struct exynos_dp_device *dp = display->ctx;
>> +
>> if (dp->dpms_mode == DRM_MODE_DPMS_ON)
>> return;
>>
>> @@ -1059,10 +1069,13 @@ static void exynos_dp_poweron(struct
>> exynos_dp_device *dp)
>> exynos_dp_phy_init(dp);
>> exynos_dp_init_dp(dp);
>> enable_irq(dp->irq);
>> + exynos_dp_commit(display);
>> }
>>
>> -static void exynos_dp_poweroff(struct exynos_dp_device *dp)
>> +static void exynos_dp_poweroff(struct exynos_drm_display *display)
>> {
>> + struct exynos_dp_device *dp = display->ctx;
>> +
>> if (dp->dpms_mode != DRM_MODE_DPMS_ON)
>> return;
>>
>> @@ -1078,12 +1091,12 @@ static void exynos_dp_dpms(struct exynos_drm_display
>> *display, int mode)
>>
>> switch (mode) {
>> case DRM_MODE_DPMS_ON:
>> - exynos_dp_poweron(dp);
>> + exynos_dp_poweron(display);
>> break;
>> case DRM_MODE_DPMS_STANDBY:
>> case DRM_MODE_DPMS_SUSPEND:
>> case DRM_MODE_DPMS_OFF:
>> - exynos_dp_poweroff(dp);
>> + exynos_dp_poweroff(display);
>> break;
>> default:
>> break;
>> @@ -1094,6 +1107,7 @@ static void exynos_dp_dpms(struct exynos_drm_display
>> *display, int mode)
>> static struct exynos_drm_display_ops exynos_dp_display_ops = {
>> .create_connector = exynos_dp_create_connector,
>> .dpms = exynos_dp_dpms,
>> + .commit = exynos_dp_commit,
>> };
>>
>> static struct exynos_drm_display exynos_dp_display = {
>> --
>> 1.7.9.5
>>
[PATCH V2] drm/tegra: add MODULE_DEVICE_TABLEs
On Wed, Jul 23, 2014 at 01:29:32PM -0600, Stephen Warren wrote: > On 06/18/2014 04:21 PM, Stephen Warren wrote: > > From: Stephen Warren > > > > When tegra-drm.ko is built as a module, these MODULE_DEVICE_TABLEs allow > > the module to be auto-loaded since the module will match the devices > > instantiated from device tree. > > > > (Notes for stable: in 3.14+, just git rm any conflicting file, since they > > are added in later kernels. For 3.13 and below, manual merging will be > > needed) > > > > Cc: > > Signed-off-by: Stephen Warren > > --- > > v2: Remove change to drm.c, since the match table there isn't used for > > probing. > > Thierry, I think this patch got lost? It doesn't appear in next-20140721 > anyway. Applied, sorry for the delay. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/0b8acfed/attachment.sig>
[PATCH 17/19] drm/radeon: use rcu waits in some ioctls
Hey,
On 01-08-14 10:27, Michel D?nzer wrote:
> On 01.08.2014 00:34, Maarten Lankhorst wrote:
>>
>> @@ -357,14 +360,20 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev,
>> void *data,
>> struct drm_radeon_gem_wait_idle *args = data;
>> struct drm_gem_object *gobj;
>> struct radeon_bo *robj;
>> -int r;
>> +int r = 0;
>> +long ret;
>>
>> gobj = drm_gem_object_lookup(dev, filp, args->handle);
>> if (gobj == NULL) {
>> return -ENOENT;
>> }
>> robj = gem_to_radeon_bo(gobj);
>> -r = radeon_bo_wait(robj, NULL, false);
>> +ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true,
>> 30 * HZ);
>> +if (ret == 0)
>> +r = -EBUSY;
>> +else if (ret < 0)
>> +r = ret;
>> +
>> /* callback hw specific functions if any */
>> if (rdev->asic->ioctl_wait_idle)
>> robj->rdev->asic->ioctl_wait_idle(rdev, robj);
>
> Heads up, this conflicts with
> http://lists.freedesktop.org/archives/dri-devel/2014-August/065255.html
> which passes a non-NULL second argument to radeon_bo_wait() to get the
> BO's current domain.
Ok, I will fix it up and resend it later.
Does it matter if I grab the current domain without grabbing the lock here?
Because it doesn't matter if it sees the old or new domain, it could have been
changed after returning too.
~Maarten
[PATCH 14/15] drm/exynos: Move DP setup into commit()
On Fri, Aug 01, 2014 at 03:11:37PM +0530, Ajay kumar wrote: > On Fri, Aug 1, 2014 at 2:48 PM, Thierry Reding > wrote: > > On Thu, Jul 31, 2014 at 11:12:13PM +0530, Ajay Kumar wrote: > >> Add commit callback for exynos_dp, and move the DP link training, > >> video configuration code from the hotplug handler into commit(). > >> > >> Signed-off-by: Sean Paul > >> Signed-off-by: Ajay Kumar > >> --- > >> drivers/gpu/drm/exynos/exynos_dp_core.c | 24 +++- > >> 1 file changed, 19 insertions(+), 5 deletions(-) > > > > This is not related to the other patches in the series, so it can be > > applied independently. > This patch should go in this series only. > [PATCH 15/15] has dependency on this because it modifies exynos_dp_commit(). Okay, I'll apply it to the panel tree. Inki, can I assume your Acked-by from patch 06/15 applies to this one as well? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/f00ba7d5/attachment.sig>
[PATCH 06/15] drm/exynos: dpi: Add support for panel prepare and unprepare routines
On Fri, Aug 01, 2014 at 06:24:42PM +0900, Inki Dae wrote: > On 2014? 08? 01? 18:04, Thierry Reding wrote: > > On Thu, Jul 31, 2014 at 11:12:05PM +0530, Ajay Kumar wrote: > >> Modify exynos_dpi driver to support the new panel calls: > >> prepare and unprepare. > >> > >> Signed-off-by: Ajay Kumar > >> --- > >> drivers/gpu/drm/exynos/exynos_drm_dpi.c |8 ++-- > >> 1 file changed, 6 insertions(+), 2 deletions(-) > > > > Looks good to me. Inki, can I have your Acked-by to take this through > > the panel tree? > > Of course. > > Acked-by: Inki Dae I'll take it that this Acked-by applies also to patch 07/15? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/d8ecb8ce/attachment.sig>
[Bug 81907] Unreal Engine "Effects Cave" Demo crashes with SIGBUS in __memcpy_sse2_unaligned
https://bugs.freedesktop.org/show_bug.cgi?id=81907 --- Comment #1 from Christoph Haag --- Some information in case someone tries to reproduce it. I applied this patch additionally to the revert: https://bugs.freedesktop.org/show_bug.cgi?id=80880#c10 Many demos work now. But the Cave Demo does not work, it hangs the GPU. I can not reproduce the original bug I posted here anymore with the patch, just the hang. It looks like this: ring 0 stalled for more than 10146msec GPU lockup (waiting for 0xa921 last fence id 0xa920 on ring 0) failed to get a new IB (-35) Saved 205 dwords of commands on ring 0. GPU softreset: 0x004D GRBM_STATUS = 0xE7DE5028 GRBM_STATUS_SE0 = 0xEF82 GRBM_STATUS_SE1 = 0xEFC2 SRBM_STATUS = 0x20C0 SRBM_STATUS2 = 0x R_008674_CP_STALLED_STAT1 = 0x R_008678_CP_STALLED_STAT2 = 0x00010800 R_00867C_CP_BUSY_STAT = 0x00408006 R_008680_CP_STAT = 0x84038647 R_00D034_DMA_STATUS_REG = 0x44C83146 R_00D834_DMA_STATUS_REG = 0x44C83D57 VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x GRBM_SOFT_RESET=0xDDFF SRBM_SOFT_RESET=0x00100100 GRBM_STATUS = 0x3028 GRBM_STATUS_SE0 = 0x0006 GRBM_STATUS_SE1 = 0x0006 SRBM_STATUS = 0x20C0 SRBM_STATUS2 = 0x R_008674_CP_STALLED_STAT1 = 0x R_008678_CP_STALLED_STAT2 = 0x R_00867C_CP_BUSY_STAT = 0x R_008680_CP_STAT = 0x R_00D034_DMA_STATUS_REG = 0x44C83D57 R_00D834_DMA_STATUS_REG = 0x44C83D57 GPU reset succeeded, trying to resume I'll leave this bug report open, because I have no idea if this bug will reappear once the hang 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/20140801/262f2832/attachment.html>
[PATCH 00/15] drm/panel: Add prepare and unprepare routines
On Thu, Jul 31, 2014 at 11:11:59PM +0530, Ajay Kumar wrote: > This series is based on exynos-drm-next branch of Inki Dae's tree at: > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > This is originally a part of the bridge chip series: > http://www.spinics.net/lists/linux-samsung-soc/msg34826.html > > But, since we can handle panel and bridge chips seperately, > I thought of seperating them. > > This patchset basically extends the drm panel framework > to accomodate wider range of panels with strict timing > sequence for enabling panel power, backlight enable, etc. > > I have tested this patchset on exynos5800-peach-pi board. > > Thierry: > As discussed, I have seperated patches such that they > won't break the compilation in between. Also, I have > incorporated all the comments given by you for panel patches. > I assume you have already taken [PATCH 01/15] and hence > it can be dropped from this patchset. > > Ajay Kumar (15): > [PATCH 01/15] drm/panel: add prepare and unprepare routines > [PATCH 02/15] drm/panel: Add get_modes helper > [PATCH 03/15] drm/panel: ld9040: Add dummy prepare and unprepare routines > [PATCH 04/15] drm/panel: s6e8aa0: Add dummy prepare and unprepare routines > [PATCH 05/15] drm/panel: simple: Add dummy prepare and unprepare routines > [PATCH 06/15] drm/exynos: dpi: Add support for panel prepare and unprepare > routines > [PATCH 07/15] drm/exynos: dsi: Add support for panel prepare and unprepare > routines > [PATCH 08/15] drm/tegra: Add support for panel prepare and unprepare > routines > [PATCH 09/15] drm/panel: ld9040: Add proper definition for prepare and > unprepare > [PATCH 10/15] drm/panel: s6e8aa0: Add proper definition for prepare and > unprepare > [PATCH 11/15] drm/panel: simple: Add proper definition for prepare and > unprepare > [PATCH 12/15] drm/panel: simple: Support usage of delays in panel functions > [PATCH 13/15] drm/panel: simple: Add support for auo_b133htn01 panel > [PATCH 14/15] drm/exynos: Move DP setup into commit() > [PATCH 15/15] drm/exynos: dp: Modify driver to support drm_panel I already had patches 01/15 and 02/15, but I've applied the rest of the series. I went out on a limb and applied Inki's Acked-by to all Exynos- related patches, assuming that was the intention. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/4e785e46/attachment.sig>
Re: [Radeon RV280] radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion »boi->space_accounted« failed, core dumped
Not in this case. You added a fail path to a function which isn't supposed to fail under these circumstances. No wonder Mesa couldn't cope with it. It really has nothing to do with your original issue. Marek On Fri, Aug 1, 2014 at 9:25 AM, Jochen Rollwagen wrote: > I've built the latest libdrm and replaced the assertion in radeon_cs_gem.c. > with > > if (!boi->space_accounted) return -EINVAL; > > I now get the following crash in the cutscene: > > > CS section size missmatch start at (r200_state_init.c,ctx_emit_cs,487) 28 vs > 24 > CS section end at (r200_state_init.c,ctx_emit_cs,520) > CS section size missmatch start at (r200_state_init.c,tex_emit_mm,572) 13 vs > 11 > CS section end at (r200_state_init.c,tex_emit_mm,588) > drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. > See dmesg for more info. > > > dmesg output is: > > [ 1232.744676] [drm:radeon_cs_packet_next_reloc] *ERROR* No packet3 for > relocati > on for packet at 34. > [ 1232.744691] [drm] ib[34]=0x0712 > [ 1232.744694] [drm] ib[35]=0x00010340 > [ 1232.744698] [drm:r200_packet0_check] *ERROR* No reloc for ib[33]=0x1C40 > [ 1232.744701] [drm] ib[32]=0x0710 > [ 1232.744704] [drm] ib[33]=0x > [ 1232.744707] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! > > So it's really a mesa bug :-( > > > > Am 27.07.2014 um 14:47 schrieb Marek Ol??k: >> >> I think the problem is the driver hasn't called >> >> radeon_cs_space_add_persistent_bo. >> >> Marek >> >> On Fri, Jul 25, 2014 at 6:32 PM, Jochen Rollwagen >> wrote: >>> >>> I've recently ported the peopsxgl OpenGL-GPU-Plugin for the pcsx >>> Playstation1 Emulator to the Powerpc-architecture. When running certain >>> games (for instance "Vagrant Stories") during longer cut-scenes i get a >>> reproducible crash of the radeon drm driver (i.e. it always crashes at >>> certain points in the scene) with the following message (in german): >>> >>> pcsx: radeon_cs_gem.c:181: cs_gem_write_reloc: Zusicherung >>> ?boi->space_accounted? nicht erf?llt. >>> Abgebrochen (Speicherabzug geschrieben) >>> >>> This happens with all the latest 3.10, 3.12 and 3.14 kernels. >>> >>> Other than that i'm running the latest xorg-ati driver, libdrm and mesa >>> from >>> git on a Mac Mini G4 (PowerPC). >>> >>> OpenGL vendor string: Mesa Project >>> OpenGL renderer string: Mesa DRI R200 (RV280 5962) TCL DRI2 >>> OpenGL version string: 1.3 Mesa 10.1.6 (git-42f86ef) >>> >>> I guess the issue is memory/vm/swap-related since the machine only has 1 >>> gb >>> RAM. The GPU has 64 MB VRAM. >>> >>> Any ideas what i could do to avoid these crashes ? >>> >>> >>> >>> >>> >>> ___ >>> dri-devel mailing list >>> dri-devel at lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/dri-devel > >
Re: [Radeon RV280] radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion »boi->space_accounted« failed, core dumped
Does the attached libdrm patch fix the issue for you? Marek On Fri, Aug 1, 2014 at 1:16 PM, Marek Ol??k wrote: > Not in this case. You added a fail path to a function which isn't > supposed to fail under these circumstances. No wonder Mesa couldn't > cope with it. It really has nothing to do with your original issue. > > Marek > > On Fri, Aug 1, 2014 at 9:25 AM, Jochen Rollwagen > wrote: >> I've built the latest libdrm and replaced the assertion in radeon_cs_gem.c. >> with >> >> if (!boi->space_accounted) return -EINVAL; >> >> I now get the following crash in the cutscene: >> >> >> CS section size missmatch start at (r200_state_init.c,ctx_emit_cs,487) 28 vs >> 24 >> CS section end at (r200_state_init.c,ctx_emit_cs,520) >> CS section size missmatch start at (r200_state_init.c,tex_emit_mm,572) 13 vs >> 11 >> CS section end at (r200_state_init.c,tex_emit_mm,588) >> drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. >> See dmesg for more info. >> >> >> dmesg output is: >> >> [ 1232.744676] [drm:radeon_cs_packet_next_reloc] *ERROR* No packet3 for >> relocati >> on for packet at 34. >> [ 1232.744691] [drm] ib[34]=0x0712 >> [ 1232.744694] [drm] ib[35]=0x00010340 >> [ 1232.744698] [drm:r200_packet0_check] *ERROR* No reloc for ib[33]=0x1C40 >> [ 1232.744701] [drm] ib[32]=0x0710 >> [ 1232.744704] [drm] ib[33]=0x >> [ 1232.744707] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! >> >> So it's really a mesa bug :-( >> >> >> >> Am 27.07.2014 um 14:47 schrieb Marek Ol??k: >>> >>> I think the problem is the driver hasn't called >>> >>> radeon_cs_space_add_persistent_bo. >>> >>> Marek >>> >>> On Fri, Jul 25, 2014 at 6:32 PM, Jochen Rollwagen >>> wrote: >>>> >>>> I've recently ported the peopsxgl OpenGL-GPU-Plugin for the pcsx >>>> Playstation1 Emulator to the Powerpc-architecture. When running certain >>>> games (for instance "Vagrant Stories") during longer cut-scenes i get a >>>> reproducible crash of the radeon drm driver (i.e. it always crashes at >>>> certain points in the scene) with the following message (in german): >>>> >>>> pcsx: radeon_cs_gem.c:181: cs_gem_write_reloc: Zusicherung >>>> ?boi->space_accounted? nicht erf?llt. >>>> Abgebrochen (Speicherabzug geschrieben) >>>> >>>> This happens with all the latest 3.10, 3.12 and 3.14 kernels. >>>> >>>> Other than that i'm running the latest xorg-ati driver, libdrm and mesa >>>> from >>>> git on a Mac Mini G4 (PowerPC). >>>> >>>> OpenGL vendor string: Mesa Project >>>> OpenGL renderer string: Mesa DRI R200 (RV280 5962) TCL DRI2 >>>> OpenGL version string: 1.3 Mesa 10.1.6 (git-42f86ef) >>>> >>>> I guess the issue is memory/vm/swap-related since the machine only has 1 >>>> gb >>>> RAM. The GPU has 64 MB VRAM. >>>> >>>> Any ideas what i could do to avoid these crashes ? >>>> >>>> >>>> >>>> >>>> >>>> ___ >>>> dri-devel mailing list >>>> dri-devel at lists.freedesktop.org >>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> -- next part -- A non-text attachment was scrubbed... Name: 0001-radeon-allow-write_reloc-with-unaccounted-buffers-to.patch Type: text/x-patch Size: 952 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/e7e40346/attachment-0001.bin>
[PATCH 16/19] drm/atomic-helpers: document how to implement async commit
On Sun, Jul 27, 2014 at 5:41 PM, Daniel Vetter wrote: > No helper function to do it all yet provided since no driver has > support for driver core fences yet. Which we'd need to make the > implementation really generic. > > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_atomic_helper.c | 37 > + > 1 file changed, 37 insertions(+) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index 9f7c45b91fe2..423f6bcec362 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -716,6 +716,43 @@ int drm_atomic_helper_commit(struct drm_device *dev, > EXPORT_SYMBOL(drm_atomic_helper_commit); > > /** > + * DOC: Implementing async commit > + * > + * For now the atomic helpers don't support async commit directly. If there > is > + * real need it could be added though, using the dma-buf fence infrastructure > + * for generic synchronization with outstanding rendering. > + * > + * For now drivers have to implement async commit themselves, with the > following > + * sequence being the recommened one: > + * > + * 1. Run drm_atomic_helper_prepare_planes() first. This is the only function > + * which commit needs to call which can fail, so we want to run it first and > + * synchronously. Without some converted driver to look at for reference, I wasn't completely sure whether prepare_fb/cleanup_fb was intended to do some refcnt'ing, etc. Or just driver internal pin/unpin? > + * 2. Synchronize with any outstanding async commit worker threads which > might > + * affect the new state update. This can be done by either cancelling or > + * flushing the work items, depending upon whether the driver can deal with > + * cancelled updates. Note that it is important to ensure that the > framebuffer > + * cleanup is still done when cancelling. maybe just an issue of wording.. but if an async update was writing the state object, then we'd need to block earlier than commit. I don't think that is what you meant, because the state object data structure synchronization you have relies on read-only access from the async commit. Which would make me expect it would be sufficient to move the synchronization part into the async commit worker (ie. it would only need to sync w/ other workers, ie if you had multiple work-queues)? > + * > + * For sufficient parallelism it is recommended to have a work item per crtc > + * (for updates which don't touch global state) and a global one. Then we > only > + * need to synchronize with the crtc work items for changed crtcs and the > global > + * work item, which allows nice concurrent updates on disjoint sets of crtcs. s/work item/work queue/? > + * 3. The software state is updated synchronously with > + * drm_atomic_helper_swap_state. Doing this under the protection of all > modeset > + * locks means concurrent callers never see inconsistent state. And doing > this > + * while it's guranateed that no relevant async worker runs means that async > + * workers do not need grab any locks. Actually they must not grab locks, for > + * otherwise the work flushing will deadlock. > + * > + * 4. Schedule a work item to do all subsequent steps, using the split-out > + * commit helpers: a) pre-plane commit b) plane commit c) post-plane commit > and > + * then cleaning up the framebuffers after one vblank has passed. the *old* framebuffers.. I assume the atomic helpers don't really care how the driver does it, as long as it does. Somehow or another the driver would want to schedule cleanup on the vblank of the *old* crtc, I guess. BR, -R > + */ > + > +/** > * drm_atomic_helper_prepare_planes - prepare plane resources after commit > * @dev: DRM device > * @state: atomic state object with old state structures > -- > 2.0.1 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #139 from Marek Ol??k --- (In reply to comment #137) > You might try the patches I posted on bug 74250. Sorry, they don't help. -- 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/20140801/b6130b12/attachment.html>
[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers
Hi Randy, On Thursday 31 July 2014 15:16:21 Randy Dunlap wrote: > On 05/12/14 11:04, Randy Dunlap wrote: > > On 05/12/2014 08:54 AM, Daniel Vetter wrote: > >> On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote: > >>> On 05/12/2014 01:58 AM, Daniel Vetter wrote: > On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: > >>> If we decide to go for property documentation inside the source code > >>> then I believe we'll have to create our own format, as creating a > >>> properties table from kerneldoc information extracted from comments > >>> is probably not possible. > >> > >> Can comeone pick up the ball here and figure out what needs to be > >> done? > >> > >> The reason why I want a central place for the documentation is to > >> force people to collaborate outside their own sandbox when adding > >> properties. Whether that's docbook or some text file I don't care so > >> much at this point. The fact that it's a central place should mandate > >> that the patches changing it will go through dri-devel and so > >> everyone should se them, and when adding new properties it would make > >> the patch author more likely to look around a bit before adding > >> another slighty incompatible version of the same property. If someone > >> has a better suggestion how to encforce this I'm all ears. > >> > >> Of course this idea can still fail if our esteemed maintainer merges > >> stuff without checking for violations of this policy. Dave, any > >> thoughts on the subject? > > > > Yeah I'm happy to block merging stuff, if we can spot new properties > > when stuff is posted on dri-devel, so much the better, > > > > most drivers still send everything via dri-devel anyways, its only > > really Intel I have to worry about so far, > > I'll enforce that all prop stuff gets cc: dri-devel and that it has > updates for the prop docs. > > > But we should definitely add it to the new driver review checklist as > > well. > > > > I'm also on the side of this patch is ugly and makes my eyes burn, > > please please get a plan to use something else ASAP, I'm willing to > > merge this but I'm tempted to give it a lifetime of a kernel or two > > before I burn it. > > Ok, I'll try to move "make kerneldoc suck less" up the task list and > maybe find someone to do it for me internally ;-) > >>> > >>> I certainly have no objections to making kerneldoc suck less. > >>> There was already an attempt to use asciidoc (like git uses) for > >>> kernel-doc (a few years ago, by Sam Ravnborg). I support(ed) that > >>> effort. > >> > >> Hm, do you have pointers to those? My google-fu seems lacking ... > > > > I googled for /kernel doc asciidoc ravnborg/ and found several hits for > > them. > > > >> Ok, let's move this to the top and start discussions. The past few months > >> I've written piles of kerneldoc comments for the DRM DocBook (all pulled > >> in as kerneldoc, docbook .tmpl has just the chapter structure). DOC: > >> sections are really useful to pull all the actual documentation out of > >> the docbook xml into kerneldoc. > >> > >> But I've also done piles of docs for intel-gpu-tools, which is using > >> gtkdoc. And there are some clear deficiencies: > >> > >> - No markdown for inline coments. Lack of lists and tables is hurting > >> especially badly. If we add this (and I don't care one iota whether > >> it's > > > > Yes, I've tried to add lists to kernel-doc notation but have failed so > > far. > > > >> markdown or asciidoc or something else as long as it's readable plain > >> text in comments) we should be able to move all the existing docbook > >> xml paragraphs/lists/tables into kerneldoc comments. > >> > >> - Automatic cross-referencing of functions. If you place e.g. function() > >> or #struct anywhere in a documentation comment gtk-doc automatically > >> inserts a hyperlink to the relevant documentation page across the > >> entire project. Really powerful and makes overview sections much more > >> useful entry points for beginners since they can easily jump back&forth > >> betweeen the high-level overview and low-level per-function > >> documentation. > > > > That's a nice-to-have IMO, but a really nice one. > > > >> - In a really perfect world it would help if kerneldoc could collect > >> structure member kerneldoc from per-member comments. Especially for > >> large structures with lots of comments this would bring the kerneldoc > >> and struct member much closer together. > >> > >> So that's my wishlist. > >> > >>> OTOH, I would only want to add another way to do kernel-doc if it can be > >>> a full replacement for all of our docbook usage, i.e., it should provide > >>> a way that we can eliminate docbook and stop using it completely. > >> > >> Hm, I don't mind docbook at all, as long as all the
[Bug 81991] X page allocation errors referencing radeon_vm_get_bos
https://bugs.freedesktop.org/show_bug.cgi?id=81991 --- Comment #1 from Alex Deucher --- This is a kernel out of memory error not a driver bug. The driver is not able to allocate the memory it needs. -- 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/20140801/c9e226d0/attachment.html>
[PATCH] drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM
On Fri, Aug 1, 2014 at 4:22 AM, Michel D?nzer wrote:
> From: Michel D?nzer
>
> The HDP cache only applies to CPU access to VRAM.
>
> Signed-off-by: Michel D?nzer
Applied to my 3.17 branch.
Thanks!
> ---
> drivers/gpu/drm/radeon/radeon_gem.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index a350cf9..8f2cb58 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -359,15 +359,17 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev,
> void *data,
> struct drm_gem_object *gobj;
> struct radeon_bo *robj;
> int r;
> + uint32_t cur_placement = 0;
>
> gobj = drm_gem_object_lookup(dev, filp, args->handle);
> if (gobj == NULL) {
> return -ENOENT;
> }
> robj = gem_to_radeon_bo(gobj);
> - r = radeon_bo_wait(robj, NULL, false);
> + r = radeon_bo_wait(robj, &cur_placement, false);
> /* Flush HDP cache via MMIO if necessary */
> - if (rdev->asic->mmio_hdp_flush)
> + if (rdev->asic->mmio_hdp_flush &&
> + radeon_mem_type_to_domain(cur_placement) ==
> RADEON_GEM_DOMAIN_VRAM)
> robj->rdev->asic->mmio_hdp_flush(rdev);
> drm_gem_object_unreference_unlocked(gobj);
> r = radeon_gem_handle_lockup(rdev, r);
> --
> 2.0.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] radeon: allow write_reloc with unaccounted buffers to cope with Mesa R200 bug
From: Marek Ol??k
---
I'm not really interested in studying the R200 driver to fix it.
This has to suffice.
radeon/radeon_cs_gem.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c
index b87c6b1..bcfa05b 100644
--- a/radeon/radeon_cs_gem.c
+++ b/radeon/radeon_cs_gem.c
@@ -178,6 +178,15 @@ static int cs_gem_write_reloc(struct radeon_cs_int *cs,
uint32_t idx;
unsigned i;
+if (!boi->space_accounted) {
+struct radeon_cs *rcs = (struct radeon_cs*)cs;
+int r;
+
+radeon_cs_space_add_persistent_bo(rcs, bo, read_domain, write_domain);
+r = radeon_cs_space_check(rcs);
+if (r)
+return r;
+}
assert(boi->space_accounted);
/* check domains */
--
1.9.1
[PATCH 17/19] drm/radeon: use rcu waits in some ioctls
On 01.08.2014 19:12, Maarten Lankhorst wrote:
> Hey,
>
> On 01-08-14 10:27, Michel D?nzer wrote:
>> On 01.08.2014 00:34, Maarten Lankhorst wrote:
>>>
>>> @@ -357,14 +360,20 @@ int radeon_gem_wait_idle_ioctl(struct drm_device
>>> *dev, void *data,
>>> struct drm_radeon_gem_wait_idle *args = data;
>>> struct drm_gem_object *gobj;
>>> struct radeon_bo *robj;
>>> - int r;
>>> + int r = 0;
>>> + long ret;
>>>
>>> gobj = drm_gem_object_lookup(dev, filp, args->handle);
>>> if (gobj == NULL) {
>>> return -ENOENT;
>>> }
>>> robj = gem_to_radeon_bo(gobj);
>>> - r = radeon_bo_wait(robj, NULL, false);
>>> + ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true,
>>> 30 * HZ);
>>> + if (ret == 0)
>>> + r = -EBUSY;
>>> + else if (ret < 0)
>>> + r = ret;
>>> +
>>> /* callback hw specific functions if any */
>>> if (rdev->asic->ioctl_wait_idle)
>>> robj->rdev->asic->ioctl_wait_idle(rdev, robj);
>>
>> Heads up, this conflicts with
>> http://lists.freedesktop.org/archives/dri-devel/2014-August/065255.html
>> which passes a non-NULL second argument to radeon_bo_wait() to get the
>> BO's current domain.
> Ok, I will fix it up and resend it later.
>
> Does it matter if I grab the current domain without grabbing the lock
> here? Because it doesn't matter if it sees the old or new domain, it
> could have been changed after returning too.
It should be the domain where the BO is located when the fence we are
waiting for here signals.
--
Earthling Michel D?nzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #79 from Andy Furniss --- Created attachment 103818 --> https://bugs.freedesktop.org/attachment.cgi?id=103818&action=edit Oops on fbcon load drm-next-3.17-rebased-on-fixex -- 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/20140801/413f443e/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #80 from Andy Furniss --- (In reply to comment #78) > just saw that there are new updates in > > http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.17-wip & > > http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.17-rebased-on- > fixes > > > > hopefully the changes make a difference, will try out the new > drm-next-3.17-rebased-on-fixes in approximately a day or later > > thanks guys ! Well I just tried drm-next-3.17-rebased-on-fixes and it died as soon as fbcon loaded. Screen full junk and an oops logged. I have got the new firmware (unless there's an even newer one) and have booted into the other 3.17 before - but it eventually crashed due to missing fixes. -- 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/20140801/1e65927e/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #81 from Michel D?nzer --- (In reply to comment #80) > Well I just tried drm-next-3.17-rebased-on-fixes and it died as soon as > fbcon loaded. Screen full junk and an oops logged. Please file a new report for that, it's nothing to do with random crashes in X. -- 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/20140801/eaf1e550/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #82 from Alex Deucher --- (In reply to comment #80) > > I have got the new firmware (unless there's an even newer one) and have > booted into the other 3.17 before - but it eventually crashed due to missing > fixes. When did you download it? The header format changed last week and I uploaded a new version. -- 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/20140801/d2446a21/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #83 from Andy Furniss --- (In reply to comment #82) > (In reply to comment #80) > > > > I have got the new firmware (unless there's an even newer one) and have > > booted into the other 3.17 before - but it eventually crashed due to missing > > fixes. > > When did you download it? The header format changed last week and I > uploaded a new version. Ahh, it was longer ago that that, will try newer. -- 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/20140801/f77a5afa/attachment.html>
[Bug 81991] X page allocation errors referencing radeon_vm_get_bos
https://bugs.freedesktop.org/show_bug.cgi?id=81991 --- Comment #2 from Michel D?nzer --- (In reply to comment #1) > This is a kernel out of memory error not a driver bug. The driver is not > able to allocate the memory it needs. That may be technically true, but order 4 means 16 physically contiguous pages IIUC, which may be difficult for the kernel to provide. We can avoid this by making radeon_vm_get_bos() allocate each list node separately instead of a single large array for all of them. -- 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/20140801/82cf47ec/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 Andy Furniss changed: What|Removed |Added Attachment #103818|0 |1 is obsolete|| -- 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/20140801/e32422e0/attachment-0001.html>
[Bug 81907] Unreal Engine "Effects Cave" Demo crashes with SIGBUS in __memcpy_sse2_unaligned
https://bugs.freedesktop.org/show_bug.cgi?id=81907 --- Comment #2 from Michel D?nzer --- (In reply to comment #1) > Many demos work now. But the Cave Demo does not work, it hangs the GPU. Hmm, that one works for me. Only the Elemental and Sci-Fi Hallway demos run into shader compiler failures and corresponding GPU VM faults for me, no hangs though. > I'll leave this bug report open, because I have no idea if this bug will > reappear once the hang is fixed. Right, they're probably separate problems and need to be tracked separately. -- 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/20140801/ee34c4ce/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #84 from Andy Furniss --- (In reply to comment #83) > (In reply to comment #82) > > (In reply to comment #80) > > > > > > I have got the new firmware (unless there's an even newer one) and have > > > booted into the other 3.17 before - but it eventually crashed due to > > > missing > > > fixes. > > > > When did you download it? The header format changed last week and I > > uploaded a new version. > > Ahh, it was longer ago that that, will try newer. Booting OK with new firmware. -- 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/20140801/afd0459a/attachment.html>
[Bug 81907] Unreal Engine "Effects Cave" Demo crashes with SIGBUS in __memcpy_sse2_unaligned
https://bugs.freedesktop.org/show_bug.cgi?id=81907 --- Comment #3 from Christoph Haag --- Oh, the hang in comment 1 may have been my fault for running it with hyperz. But without hyperz it hangs too, just less verbosely: radeon :01:00.0: ring 3 stalled for more than 10016msec radeon :01:00.0: GPU lockup (waiting for 0x00011c4a last fence id 0x00011b2a on ring 3) [TTM] Buffer eviction failed -- 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/20140801/74a75317/attachment.html>
[Bug 74250] [HAWAII][DPM] New Version 3.1 for ASIC_ProfilingInfo / ci_upload_dpm_level_enable_mask failed
https://bugs.freedesktop.org/show_bug.cgi?id=74250 --- Comment #6 from Luzipher --- (In reply to comment #4) > Please try the attached patches. Yay, those help ! Thanks a lot, Alex ! :-) With all three patches (attachements #93015, #103772, #103773) I get working DPM and none of the error messages above. I used the drm-next-3.17-wip kernel from yesterday with the patches applied manually (noticed you committed them just after I started the build). I think you didn't commit #93015 ? I also tried without attachment #93015, but I can't really explain the results. I expected to see the "*ERROR* Unknown table version 3, 1" message, but it didn't show up. Still dpm didn't work and I did get the "*ERROR* ci_upload_dpm_level_enable_mask failed" message. DPM also seems to work quite correcty, the card goes up to over 1GHz (1040MHz should be max for my card) on sclk, mclk always stays the same (but is different than without dpm): # cat /sys/kernel/debug/dri/0/radeon_pm_info power level avgsclk: 100120 mclk: 13 Without the patches, I always got: power level avgsclk: 3 mclk: 15000 Half-Life 2 now runs more or less constantly at 60fps with hig details and 8x MSAA :-) Metro Last Light is only at 20-30fps, but that's still great. What I don't really understand is that Metro didn't feel much slower when dpm didn't work (HL2 certainly did). I guess sclk stands for "shader clock" and mclk is for "memory clock" ? On Windows I believe I also have different memory clocks between the desktop and in games - is memory clocking not dynamic yet ? -- 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/20140801/b867c387/attachment.html>
[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2
Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
> Signed-off-by: Maarten Lankhorst
> ---
> V1 had a nasty bug breaking gpu lockup recovery. The fix is not
> allowing radeon_fence_driver_check_lockup to take exclusive_lock,
> and kill it during lockup recovery instead.
That looks like the delayed work starts running as soon as we submit a
fence, and not when it's needed for waiting.
Since it's a backup for failing IRQs I would rather put it into
radeon_irq_kms.c and start/stop it when the IRQs are started/stoped.
Christian.
> ---
> drivers/gpu/drm/radeon/radeon.h|3 +
> drivers/gpu/drm/radeon/radeon_device.c |5 +
> drivers/gpu/drm/radeon/radeon_fence.c | 124
> ++--
> drivers/gpu/drm/radeon/radeon_ring.c |1
> 4 files changed, 77 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 60c47f829122..b01d88fc10cb 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -347,6 +347,8 @@ struct radeon_fence_driver {
> uint64_tsync_seq[RADEON_NUM_RINGS];
> atomic64_t last_seq;
> boolinitialized;
> + struct delayed_work fence_check_work;
> + struct radeon_device*rdev;
> };
>
> struct radeon_fence {
> @@ -360,6 +362,7 @@ struct radeon_fence {
>
> int radeon_fence_driver_start_ring(struct radeon_device *rdev, int ring);
> int radeon_fence_driver_init(struct radeon_device *rdev);
> +void radeon_fence_cancel_delayed_check(struct radeon_device *rdev, int ring);
> void radeon_fence_driver_fini(struct radeon_device *rdev);
> void radeon_fence_driver_force_completion(struct radeon_device *rdev);
> int radeon_fence_emit(struct radeon_device *rdev, struct radeon_fence
> **fence, int ring);
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 697add2cd4e3..21efd32d07ee 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1637,6 +1637,11 @@ int radeon_gpu_reset(struct radeon_device *rdev)
> radeon_save_bios_scratch_regs(rdev);
> /* block TTM */
> resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev);
> +
> + /* kill all the hangcheck tests too */
> + for (i = 0; i < RADEON_NUM_RINGS; ++i)
> + radeon_fence_cancel_delayed_check(rdev, i);
> +
> radeon_pm_suspend(rdev);
> radeon_suspend(rdev);
>
> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
> b/drivers/gpu/drm/radeon/radeon_fence.c
> index 913787085dfa..c055acc3a271 100644
> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> @@ -125,16 +125,7 @@ int radeon_fence_emit(struct radeon_device *rdev,
> return 0;
> }
>
> -/**
> - * radeon_fence_process - process a fence
> - *
> - * @rdev: radeon_device pointer
> - * @ring: ring index the fence is associated with
> - *
> - * Checks the current fence value and wakes the fence queue
> - * if the sequence number has increased (all asics).
> - */
> -void radeon_fence_process(struct radeon_device *rdev, int ring)
> +static bool __radeon_fence_process(struct radeon_device *rdev, int ring)
> {
> uint64_t seq, last_seq, last_emitted;
> unsigned count_loop = 0;
> @@ -190,7 +181,51 @@ void radeon_fence_process(struct radeon_device *rdev,
> int ring)
> }
> } while (atomic64_xchg(&rdev->fence_drv[ring].last_seq, seq) > seq);
>
> - if (wake)
> + if (seq < last_emitted)
> + mod_delayed_work(system_power_efficient_wq,
> + &rdev->fence_drv[ring].fence_check_work,
> + RADEON_FENCE_JIFFIES_TIMEOUT);
> +
> + return wake;
> +}
> +
> +static void radeon_fence_driver_check_lockup(struct work_struct *work)
> +{
> + struct radeon_fence_driver *fence_drv;
> + struct radeon_device *rdev;
> + unsigned long iring;
> +
> + fence_drv = container_of(work, struct radeon_fence_driver,
> fence_check_work.work);
> + rdev = fence_drv->rdev;
> + iring = fence_drv - &rdev->fence_drv[0];
> +
> + if (__radeon_fence_process(rdev, iring))
> + wake_up_all(&rdev->fence_queue);
> + else if (radeon_ring_is_lockup(rdev, iring, &rdev->ring[iring])) {
> + /* good news we believe it's a lockup */
> + dev_warn(rdev->dev, "GPU lockup (current fence id "
> + "0x%016llx last fence id 0x%016llx on ring %ld)\n",
> + (uint64_t)atomic64_read(&fence_drv->last_seq),
> + fence_drv->sync_seq[iring], iring);
> +
> + /* remember that we need an reset */
> + rdev->needs_reset = true;
> + wake_up_all(&rdev->fence_queue);
> + }
> +}
> +
> +/**
> + * radeon_fence_process - process a fence
> + *
> + * @rde
[Bug 74250] [HAWAII][DPM] New Version 3.1 for ASIC_ProfilingInfo / ci_upload_dpm_level_enable_mask failed
https://bugs.freedesktop.org/show_bug.cgi?id=74250 --- Comment #7 from Alex Deucher --- (In reply to comment #6) > (In reply to comment #4) > > Please try the attached patches. > > Yay, those help ! Thanks a lot, Alex ! :-) > With all three patches (attachements #93015, #103772, #103773) I get working > DPM and none of the error messages above. > I used the drm-next-3.17-wip kernel from yesterday with the patches applied > manually (noticed you committed them just after I started the build). I > think you didn't commit #93015 ? It's irrelevant with the other patches applied. > DPM also seems to work quite correcty, the card goes up to over 1GHz > (1040MHz should be max for my card) on sclk, mclk always stays the same (but > is different than without dpm): > # cat /sys/kernel/debug/dri/0/radeon_pm_info > power level avgsclk: 100120 mclk: 13 > > Without the patches, I always got: > power level avgsclk: 3 mclk: 15000 > > Half-Life 2 now runs more or less constantly at 60fps with hig details and > 8x MSAA :-) Metro Last Light is only at 20-30fps, but that's still great. > What I don't really understand is that Metro didn't feel much slower when > dpm didn't work (HL2 certainly did). > > > I guess sclk stands for "shader clock" and mclk is for "memory clock" ? On > Windows I believe I also have different memory clocks between the desktop > and in games - is memory clocking not dynamic yet ? sclk (system clock) is the engine clock and mclk is the memory clock. It should be dynamic. With no GPU tasks running you should see power level avgsclk: 3 mclk: 15000 and both should be higher when there is GPU load. Can you attach your dmesg and xorg log with the patches applied? Also are you using multiple monitors? If so can you try again with a single monitor? -- 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/20140801/573d4f1b/attachment.html>
Re: [Radeon RV280] radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion »boi->space_accounted« failed, core dumped
I've built the latest libdrm and replaced the assertion in radeon_cs_gem.c. with if (!boi->space_accounted) return -EINVAL; I now get the following crash in the cutscene: CS section size missmatch start at (r200_state_init.c,ctx_emit_cs,487) 28 vs 24 CS section end at (r200_state_init.c,ctx_emit_cs,520) CS section size missmatch start at (r200_state_init.c,tex_emit_mm,572) 13 vs 11 CS section end at (r200_state_init.c,tex_emit_mm,588) drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info. dmesg output is: [ 1232.744676] [drm:radeon_cs_packet_next_reloc] *ERROR* No packet3 for relocati on for packet at 34. [ 1232.744691] [drm] ib[34]=0x0712 [ 1232.744694] [drm] ib[35]=0x00010340 [ 1232.744698] [drm:r200_packet0_check] *ERROR* No reloc for ib[33]=0x1C40 [ 1232.744701] [drm] ib[32]=0x0710 [ 1232.744704] [drm] ib[33]=0x [ 1232.744707] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! So it's really a mesa bug :-( Am 27.07.2014 um 14:47 schrieb Marek Ol??k: > I think the problem is the driver hasn't called > radeon_cs_space_add_persistent_bo. > > Marek > > On Fri, Jul 25, 2014 at 6:32 PM, Jochen Rollwagen > wrote: >> I've recently ported the peopsxgl OpenGL-GPU-Plugin for the pcsx >> Playstation1 Emulator to the Powerpc-architecture. When running certain >> games (for instance "Vagrant Stories") during longer cut-scenes i get a >> reproducible crash of the radeon drm driver (i.e. it always crashes at >> certain points in the scene) with the following message (in german): >> >> pcsx: radeon_cs_gem.c:181: cs_gem_write_reloc: Zusicherung >> ?boi->space_accounted? nicht erf?llt. >> Abgebrochen (Speicherabzug geschrieben) >> >> This happens with all the latest 3.10, 3.12 and 3.14 kernels. >> >> Other than that i'm running the latest xorg-ati driver, libdrm and mesa from >> git on a Mac Mini G4 (PowerPC). >> >> OpenGL vendor string: Mesa Project >> OpenGL renderer string: Mesa DRI R200 (RV280 5962) TCL DRI2 >> OpenGL version string: 1.3 Mesa 10.1.6 (git-42f86ef) >> >> I guess the issue is memory/vm/swap-related since the machine only has 1 gb >> RAM. The GPU has 64 MB VRAM. >> >> Any ideas what i could do to avoid these crashes ? >> >> >> >> >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Ajay, Am 01.08.2014 09:02, schrieb Ajay kumar: > On Thu, Jul 31, 2014 at 7:52 PM, Andreas F?rber wrote: >> So, with simplefb reverted in U-Boot and ... >> >> * with just the v6 applied (...~2), I get only a black screen from >> Linux, no penguins, but the backlight seems on. System comes up okay, >> ssh available, and nothing stands out in dmesg. >> >> * with the two iommu patches on top, something breaks badly, no >> backlight, no USB/network, system inaccessible. >> I.e. U-Boot had no noticeable impact on these symptoms. >> >> * with the iommu patches, but dp-controller, ps8622, panel commented >> out, I do get backlight but USB/network not working, system inaccessible. >> >> With simplefb support in U-Boot and with just v6 applied, but >> dp-controller, ps8622, panel commented out, things work as well as >> before, i.e. this series has no bad side effects. Note that I never >> claimed Ajay's series were broken, just reported that things regressed >> for me from v4, which may well be DT-related. >> >> The iommu patches interfere with my USB somehow (none or not all devices >> powered; with v4, plugging my wifi dongle led to oops but ethernet >> dongle worked, so not entirely new symptom), which is bad since my >> rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet, >> so USB based network is my only alternative to a working display once we >> reach userspace. > Well, there are 2 variants here: > 1) Bootloader > 2) config > > Type of the bootloader should not matter unless its switching on > FET1 and FET6 of tps65090 for you. > > But, config can be different! > I have attached a config i used to get display with your latest > spring-bridge.v6. > Uncomment the DT nodes for DP and bridge chip and you should > be able to get display and also the login. > > I think that you have not selected all the configs needed for IOMMU to > work properly. When I deselected few IOMMU configs, I could see system > crashing when FIMD + DP path was being initialized. May be, that is why your > USB stops working. Even I have root file system on USB drive. Find attached a diff between our configs. The following stand out: * I have LPAE enabled * you don't have DMA enabled * I have CMA enabled (like in the new defconfigs) * I have the arch timer disabled (which you suggested earlier for delay) * I have more devices enabled (SPI, PWM, cpufreq, watchdog, ...) Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg ------ next part -- A non-text attachment was scrubbed... Name: config-ajay.diff Type: text/x-patch Size: 27283 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140801/cfcd4f80/attachment-0001.bin>
Re: [Radeon RV280] radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion »boi->space_accounted« failed, core dumped
The patch does indeed fix the crashes. The cutscenes run through now without problems. Thank you very much. Am 01.08.2014 um 13:36 schrieb Marek Ol??k: > Does the attached libdrm patch fix the issue for you? > > Marek > > On Fri, Aug 1, 2014 at 1:16 PM, Marek Ol??k wrote: >> Not in this case. You added a fail path to a function which isn't >> supposed to fail under these circumstances. No wonder Mesa couldn't >> cope with it. It really has nothing to do with your original issue. >> >> Marek >> >> On Fri, Aug 1, 2014 at 9:25 AM, Jochen Rollwagen >> wrote: >>> I've built the latest libdrm and replaced the assertion in radeon_cs_gem.c. >>> with >>> >>> if (!boi->space_accounted) return -EINVAL; >>> >>> I now get the following crash in the cutscene: >>> >>> >>> CS section size missmatch start at (r200_state_init.c,ctx_emit_cs,487) 28 vs >>> 24 >>> CS section end at (r200_state_init.c,ctx_emit_cs,520) >>> CS section size missmatch start at (r200_state_init.c,tex_emit_mm,572) 13 vs >>> 11 >>> CS section end at (r200_state_init.c,tex_emit_mm,588) >>> drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. >>> See dmesg for more info. >>> >>> >>> dmesg output is: >>> >>> [ 1232.744676] [drm:radeon_cs_packet_next_reloc] *ERROR* No packet3 for >>> relocati >>> on for packet at 34. >>> [ 1232.744691] [drm] ib[34]=0x0712 >>> [ 1232.744694] [drm] ib[35]=0x00010340 >>> [ 1232.744698] [drm:r200_packet0_check] *ERROR* No reloc for ib[33]=0x1C40 >>> [ 1232.744701] [drm] ib[32]=0x0710 >>> [ 1232.744704] [drm] ib[33]=0x >>> [ 1232.744707] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! >>> >>> So it's really a mesa bug :-( >>> >>> >>> >>> Am 27.07.2014 um 14:47 schrieb Marek Ol??k: I think the problem is the driver hasn't called radeon_cs_space_add_persistent_bo. Marek On Fri, Jul 25, 2014 at 6:32 PM, Jochen Rollwagen >>> t-online.de> wrote: > I've recently ported the peopsxgl OpenGL-GPU-Plugin for the pcsx > Playstation1 Emulator to the Powerpc-architecture. When running certain > games (for instance "Vagrant Stories") during longer cut-scenes i get a > reproducible crash of the radeon drm driver (i.e. it always crashes at > certain points in the scene) with the following message (in german): > > pcsx: radeon_cs_gem.c:181: cs_gem_write_reloc: Zusicherung > ?boi->space_accounted? nicht erf?llt. > Abgebrochen (Speicherabzug geschrieben) > > This happens with all the latest 3.10, 3.12 and 3.14 kernels. > > Other than that i'm running the latest xorg-ati driver, libdrm and mesa > from > git on a Mac Mini G4 (PowerPC). > > OpenGL vendor string: Mesa Project > OpenGL renderer string: Mesa DRI R200 (RV280 5962) TCL DRI2 > OpenGL version string: 1.3 Mesa 10.1.6 (git-42f86ef) > > I guess the issue is memory/vm/swap-related since the machine only has 1 > gb > RAM. The GPU has 64 MB VRAM. > > Any ideas what i could do to avoid these crashes ? > > > > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >>>
[GIT PULL] TDA998x I2C driver updates
David, Please incorporate the latest TDA998x I2C driver updates, which can be found at: git://ftp.arm.linux.org.uk/~rmk/linux-cubox.git tda998x-devel with SHA1 c707c3619ca81f499a5ce032021405e989a96ff0. This builds upon the previous set of fixes which were pulled on 6th July. Included in this set are: - an update from Jean-Francois to add the missing reg documentation entry to the device tree documentation. - conversion of the tda998x driver to the component helpers. This will update the following files: .../devicetree/bindings/drm/i2c/tda998x.txt| 2 + drivers/gpu/drm/i2c/tda998x_drv.c | 387 - 2 files changed, 308 insertions(+), 81 deletions(-) through these changes: Jean-Francois Moine (1): drm/i2c: tda998x: fix lack of required reg in DT documentation Russell King (2): drm/i2c: tda998x: allow re-use of tda998x support code drm/i2c: tda998x: add component support Many thanks.
[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Ajay, Am 01.08.2014 09:02, schrieb Ajay kumar: > On Thu, Jul 31, 2014 at 7:52 PM, Andreas F?rber wrote: >> Am 31.07.2014 12:23, schrieb Thierry Reding: >>> On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas F?rber wrote: Am 31.07.2014 10:38, schrieb Ajay kumar: > With just the spring-bridge.v6 branch of your own tree, I am able to see > bootup logo on Skate(a variant of spring which also contains ps8622). > I have tried both exynos_defconfig and multi_v7_defconfig. > I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU > in configs. >> [...] >>> If you have something like simplefb enabled in addition to a DRM driver, >>> then perhaps the DRM driver isn't properly taking over the framebuffer >>> console. >> >> So, with simplefb reverted in U-Boot and ... >> >> * with just the v6 applied (...~2), I get only a black screen from >> Linux, no penguins, but the backlight seems on. System comes up okay, >> ssh available, and nothing stands out in dmesg. >> >> * with the two iommu patches on top, something breaks badly, no >> backlight, no USB/network, system inaccessible. >> I.e. U-Boot had no noticeable impact on these symptoms. >> >> * with the iommu patches, but dp-controller, ps8622, panel commented >> out, I do get backlight but USB/network not working, system inaccessible. >> >> With simplefb support in U-Boot and with just v6 applied, but >> dp-controller, ps8622, panel commented out, things work as well as >> before, i.e. this series has no bad side effects. Note that I never >> claimed Ajay's series were broken, just reported that things regressed >> for me from v4, which may well be DT-related. >> >> The iommu patches interfere with my USB somehow (none or not all devices >> powered; with v4, plugging my wifi dongle led to oops but ethernet >> dongle worked, so not entirely new symptom), which is bad since my >> rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet, >> so USB based network is my only alternative to a working display once we >> reach userspace. > Well, there are 2 variants here: > 1) Bootloader > 2) config Unfortunately your config doesn't work for me either, on my latest spring-bridge.v6 branch. > Type of the bootloader should not matter unless its switching on > FET1 and FET6 of tps65090 for you. It does switch them on, if I'm reading correctly: https://github.com/afaerber/u-boot/blob/spring/board/samsung/smdk5250/smdk5250.c#L599 https://github.com/afaerber/u-boot/blob/spring/board/samsung/smdk5250/smdk5250.c#L907 Another observation I made is that sometimes in my testing (didn't spot a pattern yet) after reboot or power-off/power-on the initial white screen with the warning did not come up (no backlight), but Ctrl+U worked fine and chain-loaded nv u-boot came up on screen okay. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
[PATCH 17/19] drm/radeon: use rcu waits in some ioctls
On 01-08-14 16:13, Michel D?nzer wrote:
> On 01.08.2014 19:12, Maarten Lankhorst wrote:
>> Hey,
>>
>> On 01-08-14 10:27, Michel D?nzer wrote:
>>> On 01.08.2014 00:34, Maarten Lankhorst wrote:
@@ -357,14 +360,20 @@ int radeon_gem_wait_idle_ioctl(struct drm_device
*dev, void *data,
struct drm_radeon_gem_wait_idle *args = data;
struct drm_gem_object *gobj;
struct radeon_bo *robj;
- int r;
+ int r = 0;
+ long ret;
gobj = drm_gem_object_lookup(dev, filp, args->handle);
if (gobj == NULL) {
return -ENOENT;
}
robj = gem_to_radeon_bo(gobj);
- r = radeon_bo_wait(robj, NULL, false);
+ ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true,
30 * HZ);
+ if (ret == 0)
+ r = -EBUSY;
+ else if (ret < 0)
+ r = ret;
+
/* callback hw specific functions if any */
if (rdev->asic->ioctl_wait_idle)
robj->rdev->asic->ioctl_wait_idle(rdev, robj);
>>>
>>> Heads up, this conflicts with
>>> http://lists.freedesktop.org/archives/dri-devel/2014-August/065255.html
>>> which passes a non-NULL second argument to radeon_bo_wait() to get the
>>> BO's current domain.
>> Ok, I will fix it up and resend it later.
>>
>> Does it matter if I grab the current domain without grabbing the lock
>> here? Because it doesn't matter if it sees the old or new domain, it
>> could have been changed after returning too.
>
> It should be the domain where the BO is located when the fence we are
> waiting for here signals.
Could we compare domain before and after the rcu wait, and retry waiting if
they're different, and the new one is VRAM? (eg eviction happened) That should
prevent needing to lock the bo.
~Maarten
[Bug 82019] New: Unreal Engine Effects Cave demo lockup HD 7970M
https://bugs.freedesktop.org/show_bug.cgi?id=82019 Priority: medium Bug ID: 82019 Assignee: dri-devel at lists.freedesktop.org Summary: Unreal Engine Effects Cave demo lockup HD 7970M Severity: normal Classification: Unclassified OS: All Reporter: haagch at frickel.club Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 103826 --> https://bugs.freedesktop.org/attachment.cgi?id=103826&action=edit full dmesg with lockup On my ivy bridge/HD 7970M hybrid laptop, started with DRI_PRIME=1 GALLIUM_HUD="fps,VRAM-usage+GTT-usage" ./Effects so no hyperz. mesa git with f4b0ab7afd83c811329211eae8167c9bf238870c reverted because of bug 81834 and with 0001-glsl-support-unsigned-increment-in-ir_loop.patch from https://bugs.freedesktop.org/show_bug.cgi?id=80880#c10 On reddit someone with a HD 7790 said it works (http://www.reddit.com/r/linux_gaming/comments/2cbspp/unreal_engine_4_starts_working_on_the_radeonsi/cjdzh2v) For me with my HD 7970M it produces this hang on both 3.16-rc7 and agd5f/drm-next-3.17-rebased-on-fixes: ring 3 stalled for more than 10296msec GPU lockup (waiting for 0x0cdc last fence id 0x0cdb on ring 3) scheduling IB failed (-35). Saved 525 dwords of commands on ring 0. GPU softreset: 0x004D GRBM_STATUS = 0xE7DE5028 GRBM_STATUS_SE0 = 0xEF82 GRBM_STATUS_SE1 = 0xEFC2 SRBM_STATUS = 0x20C0 SRBM_STATUS2 = 0x R_008674_CP_STALLED_STAT1 = 0x R_008678_CP_STALLED_STAT2 = 0x00010800 R_00867C_CP_BUSY_STAT = 0x00408006 R_008680_CP_STAT = 0x84038647 R_00D034_DMA_STATUS_REG = 0x45483106 R_00D834_DMA_STATUS_REG = 0x44C83D57 VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x GRBM_SOFT_RESET=0xDDFF SRBM_SOFT_RESET=0x00100100 GRBM_STATUS = 0x3028 GRBM_STATUS_SE0 = 0x0006 GRBM_STATUS_SE1 = 0x0006 SRBM_STATUS = 0x20C0 SRBM_STATUS2 = 0x R_008674_CP_STALLED_STAT1 = 0x R_008678_CP_STALLED_STAT2 = 0x R_00867C_CP_BUSY_STAT = 0x R_008680_CP_STAT = 0x R_00D034_DMA_STATUS_REG = 0x44C83D57 R_00D834_DMA_STATUS_REG = 0x44C83D57 GPU reset succeeded, trying to resume -- 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/20140801/498c3d0a/attachment.html>
[Bug 82019] Unreal Engine Effects Cave demo lockup HD 7970M
https://bugs.freedesktop.org/show_bug.cgi?id=82019 --- Comment #1 from Alex Deucher --- Does setting env var RADEON_DEBUG=nodma help? -- 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/20140801/d13d169d/attachment.html>
[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2
On 01-08-14 18:35, Christian K?nig wrote: > Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst: >> Signed-off-by: Maarten Lankhorst >> --- >> V1 had a nasty bug breaking gpu lockup recovery. The fix is not >> allowing radeon_fence_driver_check_lockup to take exclusive_lock, >> and kill it during lockup recovery instead. > > That looks like the delayed work starts running as soon as we submit a fence, > and not when it's needed for waiting. > > Since it's a backup for failing IRQs I would rather put it into > radeon_irq_kms.c and start/stop it when the IRQs are started/stoped. The delayed work is not just for failing irq's, it's also the handler that's used to detect lockups, which is why I trigger after processing fences, and reset the timer after processing. Specifically what happened was this scenario: - lock up occurs - write lock taken by gpu_reset - delayed work runs, tries to acquire read lock, blocks - gpu_reset tries to cancel delayed work synchronously - has to wait for delayed work to finish -> deadlock ~Maarten
[Bug 82019] Unreal Engine Effects Cave demo lockup HD 7970M
https://bugs.freedesktop.org/show_bug.cgi?id=82019 --- Comment #2 from Christoph Haag --- Created attachment 103827 --> https://bugs.freedesktop.org/attachment.cgi?id=103827&action=edit another dmesg with 3.16-rc7 and nodma Tried with: DRI_PRIME=1 GALLIUM_HUD="fps,VRAM-usage+GTT-usage" RADEON_DEBUG=nodma ./Effects I didn't see much of a difference. -- 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/20140801/2c89874e/attachment-0001.html>
[PATCH 1/4] drm/radeon: use packet2 for nop on hawaii with old firmware
From: Alex Deucher
Older firmware didn't support the new nop packet.
v2 (Andreas Boll):
- Drop usage of packet3 for new firmware
Signed-off-by: Alex Deucher
Reviewed-by: Christian K?nig (v1)
Signed-off-by: Andreas Boll
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index c0ea661..e5985d5 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7900,6 +7900,7 @@ restart_ih:
static int cik_startup(struct radeon_device *rdev)
{
struct radeon_ring *ring;
+ u32 nop;
int r;
/* enable pcie gen2/3 link */
@@ -8033,9 +8034,15 @@ static int cik_startup(struct radeon_device *rdev)
}
cik_irq_set(rdev);
+ if (rdev->family == CHIP_HAWAII) {
+ nop = RADEON_CP_PACKET2;
+ } else {
+ nop = PACKET3(PACKET3_NOP, 0x3FFF);
+ }
+
ring = &rdev->ring[RADEON_RING_TYPE_GFX_INDEX];
r = radeon_ring_init(rdev, ring, ring->ring_size,
RADEON_WB_CP_RPTR_OFFSET,
-PACKET3(PACKET3_NOP, 0x3FFF));
+nop);
if (r)
return r;
@@ -8043,7 +8050,7 @@ static int cik_startup(struct radeon_device *rdev)
/* type-2 packets are deprecated on MEC, use type-3 instead */
ring = &rdev->ring[CAYMAN_RING_TYPE_CP1_INDEX];
r = radeon_ring_init(rdev, ring, ring->ring_size,
RADEON_WB_CP1_RPTR_OFFSET,
-PACKET3(PACKET3_NOP, 0x3FFF));
+nop);
if (r)
return r;
ring->me = 1; /* first MEC */
@@ -8054,7 +8061,7 @@ static int cik_startup(struct radeon_device *rdev)
/* type-2 packets are deprecated on MEC, use type-3 instead */
ring = &rdev->ring[CAYMAN_RING_TYPE_CP2_INDEX];
r = radeon_ring_init(rdev, ring, ring->ring_size,
RADEON_WB_CP2_RPTR_OFFSET,
-PACKET3(PACKET3_NOP, 0x3FFF));
+nop);
if (r)
return r;
/* dGPU only have 1 MEC */
--
2.0.1
[PATCH 2/4] drm/radeon: tweak ACCEL_WORKING2 query for hawaii
From: Alex Deucher
Return 2 so we can be sure the kernel has the necessary
changes for acceleration to work.
Note: This patch depends on these two commits:
- drm/radeon: fix cut and paste issue for hawaii.
- drm/radeon: use packet2 for nop on hawaii with old firmware
Signed-off-by: Alex Deucher
Signed-off-by: Andreas Boll
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_kms.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index d25ae6a..c1a206d 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -254,7 +254,14 @@ static int radeon_info_ioctl(struct drm_device *dev, void
*data, struct drm_file
}
break;
case RADEON_INFO_ACCEL_WORKING2:
- *value = rdev->accel_working;
+ if (rdev->family == CHIP_HAWAII) {
+ if (rdev->accel_working)
+ *value = 2;
+ else
+ *value = 0;
+ } else {
+ *value = rdev->accel_working;
+ }
break;
case RADEON_INFO_TILING_CONFIG:
if (rdev->family >= CHIP_BONAIRE)
--
2.0.1
[PATCH 3/4] drm/radeon: use packet3 for nop on hawaii with new firmware
From: Alex Deucher
Older firmware didn't support the new nop packet.
Signed-off-by: Alex Deucher
Signed-off-by: Andreas Boll
---
drivers/gpu/drm/radeon/cik.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index e5985d5..8b580dc 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -8035,7 +8035,10 @@ static int cik_startup(struct radeon_device *rdev)
cik_irq_set(rdev);
if (rdev->family == CHIP_HAWAII) {
- nop = RADEON_CP_PACKET2;
+ if (rdev->new_fw)
+ nop = PACKET3(PACKET3_NOP, 0x3FFF);
+ else
+ nop = RADEON_CP_PACKET2;
} else {
nop = PACKET3(PACKET3_NOP, 0x3FFF);
}
--
2.0.1
[PATCH 4/4] drm/radeon: tweak ACCEL_WORKING2 query for the new firmware for hawaii
Adjust the previous tweak for hawaii to return 3 if the new firmware is used.
Signed-off-by: Andreas Boll
---
drivers/gpu/drm/radeon/radeon_kms.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index c1a206d..eb7164d 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -255,10 +255,14 @@ static int radeon_info_ioctl(struct drm_device *dev, void
*data, struct drm_file
break;
case RADEON_INFO_ACCEL_WORKING2:
if (rdev->family == CHIP_HAWAII) {
- if (rdev->accel_working)
- *value = 2;
- else
+ if (rdev->accel_working) {
+ if (rdev->new_fw)
+ *value = 3;
+ else
+ *value = 2;
+ } else {
*value = 0;
+ }
} else {
*value = rdev->accel_working;
}
--
2.0.1
[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers
On 08/01/14 05:58, Laurent Pinchart wrote: > Hi Randy, > > On Thursday 31 July 2014 15:16:21 Randy Dunlap wrote: >> On 05/12/14 11:04, Randy Dunlap wrote: >>> On 05/12/2014 08:54 AM, Daniel Vetter wrote: On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote: > On 05/12/2014 01:58 AM, Daniel Vetter wrote: >> On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: > If we decide to go for property documentation inside the source code > then I believe we'll have to create our own format, as creating a > properties table from kerneldoc information extracted from comments > is probably not possible. Can comeone pick up the ball here and figure out what needs to be done? The reason why I want a central place for the documentation is to force people to collaborate outside their own sandbox when adding properties. Whether that's docbook or some text file I don't care so much at this point. The fact that it's a central place should mandate that the patches changing it will go through dri-devel and so everyone should se them, and when adding new properties it would make the patch author more likely to look around a bit before adding another slighty incompatible version of the same property. If someone has a better suggestion how to encforce this I'm all ears. Of course this idea can still fail if our esteemed maintainer merges stuff without checking for violations of this policy. Dave, any thoughts on the subject? >>> >>> Yeah I'm happy to block merging stuff, if we can spot new properties >>> when stuff is posted on dri-devel, so much the better, >>> >>> most drivers still send everything via dri-devel anyways, its only >>> really Intel I have to worry about so far, >> >> I'll enforce that all prop stuff gets cc: dri-devel and that it has >> updates for the prop docs. >> >>> But we should definitely add it to the new driver review checklist as >>> well. >>> >>> I'm also on the side of this patch is ugly and makes my eyes burn, >>> please please get a plan to use something else ASAP, I'm willing to >>> merge this but I'm tempted to give it a lifetime of a kernel or two >>> before I burn it. >> >> Ok, I'll try to move "make kerneldoc suck less" up the task list and >> maybe find someone to do it for me internally ;-) > > I certainly have no objections to making kerneldoc suck less. > There was already an attempt to use asciidoc (like git uses) for > kernel-doc (a few years ago, by Sam Ravnborg). I support(ed) that > effort. Hm, do you have pointers to those? My google-fu seems lacking ... >>> >>> I googled for /kernel doc asciidoc ravnborg/ and found several hits for >>> them. >>> Ok, let's move this to the top and start discussions. The past few months I've written piles of kerneldoc comments for the DRM DocBook (all pulled in as kerneldoc, docbook .tmpl has just the chapter structure). DOC: sections are really useful to pull all the actual documentation out of the docbook xml into kerneldoc. But I've also done piles of docs for intel-gpu-tools, which is using gtkdoc. And there are some clear deficiencies: - No markdown for inline coments. Lack of lists and tables is hurting especially badly. If we add this (and I don't care one iota whether it's >>> >>> Yes, I've tried to add lists to kernel-doc notation but have failed so >>> far. >>> markdown or asciidoc or something else as long as it's readable plain text in comments) we should be able to move all the existing docbook xml paragraphs/lists/tables into kerneldoc comments. - Automatic cross-referencing of functions. If you place e.g. function() or #struct anywhere in a documentation comment gtk-doc automatically inserts a hyperlink to the relevant documentation page across the entire project. Really powerful and makes overview sections much more useful entry points for beginners since they can easily jump back&forth betweeen the high-level overview and low-level per-function documentation. >>> >>> That's a nice-to-have IMO, but a really nice one. >>> - In a really perfect world it would help if kerneldoc could collect structure member kerneldoc from per-member comments. Especially for large structures with lots of comments this would bring the kerneldoc and struct member much closer together. So that's my wishlist. > OTOH, I would only want to add another way to do kernel-doc if it can be > a full replacement for all of our docbook usage, i.e., it should provide > a way that we can eliminate docbook and stop using it completely. Hm, I don't mind docboo
[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Andreas, On Thu, Jul 31, 2014 at 7:52 PM, Andreas F?rber wrote: > Am 31.07.2014 12:23, schrieb Thierry Reding: >> On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas F?rber wrote: >>> Am 31.07.2014 10:38, schrieb Ajay kumar: With just the spring-bridge.v6 branch of your own tree, I am able to see bootup logo on Skate(a variant of spring which also contains ps8622). I have tried both exynos_defconfig and multi_v7_defconfig. I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU in configs. > [...] >> If you have something like simplefb enabled in addition to a DRM driver, >> then perhaps the DRM driver isn't properly taking over the framebuffer >> console. > > So, with simplefb reverted in U-Boot and ... > > * with just the v6 applied (...~2), I get only a black screen from > Linux, no penguins, but the backlight seems on. System comes up okay, > ssh available, and nothing stands out in dmesg. > > * with the two iommu patches on top, something breaks badly, no > backlight, no USB/network, system inaccessible. > I.e. U-Boot had no noticeable impact on these symptoms. > > * with the iommu patches, but dp-controller, ps8622, panel commented > out, I do get backlight but USB/network not working, system inaccessible. > > With simplefb support in U-Boot and with just v6 applied, but > dp-controller, ps8622, panel commented out, things work as well as > before, i.e. this series has no bad side effects. Note that I never > claimed Ajay's series were broken, just reported that things regressed > for me from v4, which may well be DT-related. > > The iommu patches interfere with my USB somehow (none or not all devices > powered; with v4, plugging my wifi dongle led to oops but ethernet > dongle worked, so not entirely new symptom), which is bad since my > rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet, > so USB based network is my only alternative to a working display once we > reach userspace. Well, there are 2 variants here: 1) Bootloader 2) config Type of the bootloader should not matter unless its switching on FET1 and FET6 of tps65090 for you. But, config can be different! I have attached a config i used to get display with your latest spring-bridge.v6. Uncomment the DT nodes for DP and bridge chip and you should be able to get display and also the login. I think that you have not selected all the configs needed for IOMMU to work properly. When I deselected few IOMMU configs, I could see system crashing when FIMD + DP path was being initialized. May be, that is why your USB stops working. Even I have root file system on USB drive. Just give a try with this config and let me know your observation. If you still observe the same behavior, may be I need to flash new bootloader onto my board and try. :( Ajay -- next part -- # # Automatically generated file; DO NOT EDIT. # Linux/arm 3.16.0-rc6 Kernel Configuration # CONFIG_ARM=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_ARM_DMA_USE_IOMMU=y CONFIG_ARM_DMA_IOMMU_ALIGNMENT=8 CONFIG_MIGHT_HAVE_PCI=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_PROC_CPU=y CONFIG_NO_IOPORT_MAP=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_BANDGAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_VECTORS_BASE=0x CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y # CONFIG_FHANDLE is not set CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_KTIME_SCALAR=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_ARCH_HAS_TICK_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is n
